Diplomarbeit

 

Bitte kontaktieren Sie den zuständigen Mitarbeiter für nähere Informationen zu den Themenvorschlägen.

Vorgeschlagene Themen

Laufende Arbeiten

1. Der Bearbeiter sollte sich als Leser einen Fachmann, nicht einen Laien vorstellen. Dieser Fachmann bringt die allgemeinen Kenntnisse des Problems mit und ist an einer möglichst kompakten Darstellung der Eigenleistung des Studierenden interessiert.
   Diese Angaben beziehen sich auf Arbeiten mit folgenden Formatierungen: gut lesbare Proportionalschrift (z. B. Arial oder Times New Roman), Schriftgrad 10 bis 12, 1,5-zeilig, Fußnoten nicht kleiner als 9. Bei Verwendung von anderen Formatierungen sind die Angaben entsprechend umzurechnen.
2. Eine besonders kompakte Darstellung erreicht man mit Schemaskizzen, Tabellen, Aufzählungen.
3. Im Text dürfen keine Gemeinplätze erscheinen ("Im Zeichen des zunehmenden Wettbewerbs wird Rationalisierung immer wichtiger", "Ein Unternehmer, der erfolgreich bleiben will, muß mit möglichst niedrigen Kosten arbeiten").
4. Das Inhaltsverzeichnis sollte nicht weiter als bis zur vierten Gliederungsebene gegliedert werden.
5. Die Gliederung soll numerisch sein. Zwischen jeder Zahl ist jeweils ein Punkt (dadurch sind auch Kapitel mit mehr als zehn Unterabschnitten möglich (z. B. 3.12)).
6. Nach dem Inhaltsverzeichnis sollte der Ausarbeitung eine Kurzzusammenfassung (drei bis vier Sätze) vorangestellt werden.
7. Bei Abbildungen bzw. Formeln sind Dimensionsangaben erforderlich.
8. Fügen Sie jedem Exemplar der Arbeit eine beschriftete (Titel und Matr.Nr.) CD/DVD bei auf der die Arbeit sowohl im PDF, als auch im Word (bzw. Tex) Format abgespeichert ist. Die CD befestigen Sie innen Sie in einer handelsüblichen Papier-Schutzhülle stabil auf der Innenseite des hinteren Kartonblattes.

• Die Dokumentation von Softwareentwicklungen muß unter Nutzung von Struktogrammen, Entity-Relationship-Diagrammen bzw. Diagrammen und Notationen der Unified Modeling Language (UML) erfolgen.
• Systemabgrenzung: Die Abgrenzung des entwickelten Systems erfolgt mit Hilfe eines oder mehrerer Use-Case-Diagramme. Dabei sollen typische Anwendungsfälle des Systems dargestellt werden.
• Systemarchitektur: Die bei der Entwicklung erstellten funktionalen Komponenten und das zugrundeliegende Datenmodell sind zu dokumentieren. Bei objektorientiertem Vorgehen sollten die Struktur und Zusammenhang der Klassen in einem Klassendiagramm analog zu nachstehendem Beispiel angegeben werden. Kardinalitäten sind dabei zu ergänzen (z. B. 1..n).
• Systemdynamik: Das dynamische Verhalten wird durch Anwendungsbeispiele (z.B. mit Hilfe von Sequenzdiagrammen und Zustandsdiagrammen der wichtigsten Klassen) verdeutlicht. Algorithmen werden mit Nassi-Shneiderman-Diagrammen dargestellt.
• Bedienungsanleitung: Hinweise zum Start des Systems, Funktionstastenbelegungen sowie besondere Kommandos müssen schriftlich erklärt werden. Nach Möglichkeit ist ein entsprechendes Installationsprogramm mit variabel wählbarem Anfangsverzeichnis mitzuliefern.
• Programminterne Dokumentation: Gerade bei objektorientierter Programmierung ist auf eine gute Dokumentation des Source Codes zu achten.
• Hinweis: Falls eine Dokumentation nach diesen Vorgaben nicht möglich oder nicht sinnvoll erscheint, sollte dies möglichst frühzeitig mit dem Betreuer der Diplomarbeit besprochen werden. Sinn der Dokumentation ist, daß Dritte das erstellte System soweit verstehen können, daß eine Änderung oder Weiterarbeit an den Programmen möglich ist. Soweit dies gewährleistet ist, kann unter Umständen auch auf einzelne Bereiche der hier dargestellten Dokumentation verzichtet werden.

 

• Microsoft Word Vorlage

Eidesstattliche Erklärung

 Ich erkläre hiermit an Eides Statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe angefertigt und alle Abschnitte, die wörtlich oder annähernd wörtlich aus einer Veröffentlichung entnommen sind, als solche kenntlich gemacht habe, ferner, dass die Arbeit noch nicht veröffentlicht und auch keiner Prüfungsbehörde vorgelegt worden ist.

Nürnberg, den ...

In der Folge stellen wir die Fehler zusammen, die in studentischen Arbeiten am häufigsten beobachtet wurden. Wir bitten Sie, Ihre Arbeit vor der Reinschrift auf diese Fehler hin besonders intensiv zu checken:

1. Asymmetrische Gliederung, z. B.:
   
   Dispositionssysteme im Absatzsektor
   5.1 Überblick
   5.2 Ausgewählte Beispiele
   
   Dispositionssysteme im Fertigungsbereich
   6.1 Übersicht
   6.2 Einige Beispiele
2. Einleitung zu langatmig, beginnt mit Gemeinplätzen:
   "Im Wege des immer stärkeren Wettbewerbs wird Rationalisierung stets wichtiger".
3. Literaturangaben nicht einheitlich:
   1) Mertens, Peter, Industrielle Datenverarbeitung, 7. Aufl., Wiesbaden 1988, S. 101 f.
   2) Mertens, P., Simulation, Stuttgart 1982, S. 22 ff.
   3) Kilger, W.: Flexible Plankostenrechnung, 3. Aufl., Köln-Opladen 1987.
   4) Werner Kern, Optimierungsverfahren in der Ablauforganisation
4. Die Sätze sind zu lang und zu verschachtelt:
   "Nach der Übertragung zur zentralen Rechenanlage wird, wenn die zu übertragenden Blöcke richtig empfangen worden sind, was durch spezielle Prüfcodes (Längsprüfung, Blockprüfung) erreicht wird, wobei sich die zyklische Blocksicherung als die wirksamste erwiesen hat, lediglich ein einfaches Zeichen an das Terminal zurückgesandt, das, wenn es nicht richtig empfangen wird, eine nochmalige Übertragung auslöst, und zwar so lange, bis der Operator eingreift."
5. Substantivischer Stil (auch Juristen-, Behörden- oder Karl-Valentin-Stil genannt):
   Cäsars "kam, sah und siegte", läßt sich auch so formulieren: "Nach erfolgter Ankunft und Besichtigung der Verhältnisse war mir die Erringung des Sieges möglich". Wo BILD in eine Richtung übertreibt ("Professor drehte sich nach Rothaariger um - Geld weg"), formuliert der Beamte: "Nach Umdrehung des Professors und Bewunderung der rot-haarigen Dame erfolgte die Stehlung der Geldbörse".
   Symptomatisch für Behördenstil ist, wenn sich viele Genitive und Substantive mit "ung" häufen!
6. Bildliche Sprache
   

   Bildliche Sprache macht einen Text anschaulich und leicht verständlich - wenn sie gekonnt ist. Der Schritt vom Erhabenen zum Lächerlichen ist aber hier besonders kurz, deshalb Vorsicht:
   Die Frankfurter Allgemeine Zeitung in einem Bericht über Silberspekulationen:
   "Man hält es für denkbar, daß Broker und Banken noch die eine oder andere "Silberleiche im Keller" haben, die sie im ureigenen Interesse über Wasser halten müssen."
   
   oder

   a) "Mit dem Messer der Kritik hineinleuchten"
   b) "Ein zweischneidiges Schwert, das nach hinten losgeht"
   c) "... wurde von den Unternehmen mit gemischten Gefühlen aufgenommen"
   d) "... sind Unternehmen auf den Bauch gefallen"

7. Lange Abschnitte sind in sich selbst zu wenig gegliedert, es kommt zu Gedankensprüngen, Informationswiederholungen (Redundanz). Der Text wirkt "heruntergeschrieben", nicht durchkonstruiert.

8. Fußnoten, die sich direkt auf den Inhalt des Satzes beziehen, kommen vor dem Satzzeichen:
   Falsch: Darauf hat schon Schmalenbach hingewiesen.²
   Richtig: Darauf hat schon Schmalenbach hingewiesen².

   Umfangreiche Informationen zum wissenschaftlichen Arbeiten gibt z. B. Theisen, M., Wissenschaftliches Arbeiten, 7. Aufl., München 1993.
   
   

Richten Sie sich bezüglich Zitiertechnik und Quellenangaben bitte nach den Vorgaben der Zeitschrift Wirtschaftsinformatik:

http://www.wirtschaftsinformatik.de//binary/gestaltung%20von%20MS.pdf (Abschnitt Zitierweise)

 

1. Raumverhältnisse auf Teilnehmerzahl abstimmen. Auf wenigen, gut durchdachten Hilfsblättern Überblick vorweg (z. B. Masken-Hierarchien).
2. Bedenken Sie, daß der Zuschauer sich eventuell nur wenig Zeit genommen hat, deshalb müssen die interessantesten Elemente Ihres Systems möglichst am Anfang vorgeführt werden. Bitte vorher eruieren, wieviel Zeit zur Verfügung steht.
3. Versuchen Sie herauszufinden, ob Ihr Partner mehr am betriebswirtschaftlichen Inhalt oder mehr an der informationstechnischen Realisierung interessiert ist, und stellen Sie Ihre Demonstration darauf ab. Zuweilen hat man es mit mehreren, unterschiedlich interessierten Partnern zu tun. In solchen Fällen eventuell zwei "Vorführerinnen/Vorführer": Eine(r) demonstriert am Gerät, die (der) zweite erläutert.
4. Zum Startzeitpunkt soll das System benutzerbereit sein, so daß nicht am Anfang dem Partner viel Geduld für Systemaufruf, Paßwort usw. abverlangt wird.
5. Es ist sicherzustellen, daß in kurzer Zeit einmal durch das Gesamtsystem geschritten und ein Ergebnis erzeugt wird. Hierzu dient ein gut vorbereitetes Beispiel. Es soll möglichst viele interessante Elemente (Punkt 2.) ansteuern, aber nicht durch unnötige Einzelheiten verwirren. Ungünstig sind Beispiele, bei denen nach etlichen Eingaben nur ein kurzes Ergebnis ausgegeben wird.
6. Nicht gleich am Anfang dem Partner erlauben, beliebige Fragen an das System zu richten oder beliebige Parameter zu setzen: Sie riskieren sonst, daß das System in einen Seitenzweig läuft und dort zu lange verharrt, d. h. zuviel von der kurzen Demon-strationszeit verlorengeht.
7. Erst nach Abarbeitung des vorbereiteten Beispiels den Benutzer auffordern, eigene Wünsche zu äußern, damit er nicht den Eindruck gewinnt, das Beispiel sei "getürkt". Vorher gegebenenfalls zugeben, daß bestimmte Details noch nicht implementiert bzw. ausgetestet sind, so daß der Partner nicht sofort durch Schwachstellen überrascht wird ("vorbeugende Selbstkritik").
8. Am Schluß abschätzen, ob der Partner noch an weiteren Details interessiert ist:
   
   • Offenbar gar nicht: Demo beenden, eventuell wenige Sätze darüber verlieren, was man alles sonst noch zeigen könnte, wenn man x Stunden Zeit hätte.
   • Offenbar genug Zeit: Das nächst interessantere Beispiel bzw. Merkmal des Systems demonstrieren.
   • Offenbar noch etwas Zeit: Weitere Systemelemente verbal erläutern, hier und da - wenn möglich ohne längeren Vorlauf - am Bildschirm präsentieren.