Aufbau & Gliederung

Eine klare Gliederung ist das Rückgrat eurer Diplomarbeit. Sie hilft euch beim Schreiben und dem Leser beim Verstehen.

Standardgliederung

Diplomarbeit/
├── Titelblatt
├── Eidesstattliche Erklärung
├── Kurzfassung (Deutsch)
├── Abstract (Englisch)
├── Vorwort (optional)
├── Inhaltsverzeichnis
│
├── 1  Einleitung
│   ├── 1.1  Problemstellung
│   ├── 1.2  Zielsetzung
│   └── 1.3  Methodik & Aufbau der Arbeit
│
├── 2  Theoretische Grundlagen
│   ├── 2.1  [Themenbereich A]
│   └── 2.2  [Themenbereich B]
│
├── 3  Praktische Umsetzung (Teammitglied 1)
│   ├── 3.1  Anforderungsanalyse
│   ├── 3.2  Entwurf / Design
│   ├── 3.3  Implementierung
│   └── 3.4  Test & Ergebnisse
│
├── 4  [Bereich Teammitglied 2]
│   └── ...
│
├── 5  [Bereich Teammitglied 3]
│   └── ...
│
├── 6  Zusammenfassung & Ausblick
│
├── Literaturverzeichnis
├── Abbildungsverzeichnis
├── Tabellenverzeichnis
└── Anhang
    ├── A  Quellcode
    ├── B  Schaltpläne / Screenshots
    └── C  Projektdokumentation

Beschreibung der Teile

Einleitung

Die Einleitung führt in das Thema ein. Sie beschreibt das Problem, das gelöst werden soll, die Zielsetzung der Arbeit und gibt einen kurzen Überblick über die Methodik und den Aufbau der einzelnen Kapitel.

Theoretische Grundlagen

Hier erklärt ihr die technischen und theoretischen Grundlagen, die für das Verständnis der Arbeit nötig sind. Wichtig: Nur das erklären, was der Leser wirklich braucht – kein Lehrbuch nachschreiben!

Praktische Kapitel

Jedes Teammitglied schreibt seinen eigenen praktischen Teil. Die typische Struktur folgt dem Software-Engineering-Zyklus:

1. Anforderungen definieren
2. Design/Entwurf beschreiben
3. Implementierung dokumentieren
4. Testen und Ergebnisse auswerten

Zusammenfassung & Ausblick

Wird wieder gemeinsam geschrieben. Fasst die Ergebnisse zusammen und beschreibt mögliche Weiterentwicklungen.

Inhaltsverzeichnis richtig aufbauen

Das Inhaltsverzeichnis ist das Erste, was ein Leser (und euer Betreuer!) sieht. Es muss die Logik eurer Arbeit auf einen Blick erkennbar machen. In LaTeX wird es automatisch aus euren \chapter, \section und \subsection Befehlen generiert.

Praxisbeispiel: Gutes vs. schlechtes Inhaltsverzeichnis

Schlecht – zu flach, nichtssagend:

1  Einleitung
2  Theorie
3  Praxis
4  Ergebnis
5  Fazit

Schlecht – zu tief, unübersichtlich:

3  Backend
  3.1  Technologien
    3.1.1  Node.js
      3.1.1.1  Event Loop
        3.1.1.1.1  Callback Queue

Gut – aussagekräftig, logisch, 2–3 Ebenen:

1  Einleitung
  1.1  Problemstellung
  1.2  Zielsetzung
  1.3  Aufbau der Arbeit

2  Theoretische Grundlagen
  2.1  REST-Architektur
  2.2  Relationale Datenbanken
  2.3  Authentifizierung mit JWT

3  Backend-Entwicklung (Max Mustermann)
  3.1  Anforderungsanalyse
  3.2  Architektur und Entwurf
    3.2.1  Schichtenmodell
    3.2.2  Datenbankschema
  3.3  Implementierung der REST-API
  3.4  Test und Ergebnisse

4  Frontend-Entwicklung (Lisa Huber)
  4.1  Anforderungsanalyse
  4.2  UI/UX-Design
  4.3  Implementierung mit React
  4.4  Test und Ergebnisse

5  Zusammenfassung und Ausblick
  5.1  Zusammenfassung
  5.2  Reflexion
  5.3  Ausblick

Regeln für ein gutes Inhaltsverzeichnis

• Überschriften müssen den Inhalt verraten: „3.3 Implementierung der REST-API“ statt nur „3.3 Implementierung“
• Parallele Struktur: Wenn ein Kapitel „Anforderungsanalyse, Entwurf, Implementierung, Test“ hat, sollten das die anderen Kapitel auch haben
• Keine verwaisten Unterkapitel: Wenn es ein 3.1 gibt, muss es mindestens auch ein 3.2 geben. Ein einzelnes Unterkapitel ist ein Zeichen, dass die Gliederung nicht stimmt.
• Mindestens eine halbe Seite pro Abschnitt: Wenn ein Abschnitt kürzer ist, ist die Gliederung zu fein – zusammenlegen!
• Nicht mehr als 7–8 Einträge auf einer Ebene: Mehr als 8 Unterkapitel sind ein Zeichen dafür, dass eine Zwischenebene fehlt

LaTeX: Inhaltsverzeichnis erzeugen

% Inhaltsverzeichnis ausgeben:
\tableofcontents

% Tiefe steuern (was erscheint im Verzeichnis):
\setcounter{tocdepth}{2}
% 0 = nur \chapter
% 1 = bis \section
% 2 = bis \subsection (empfohlen!)
% 3 = bis \subsubsection

% Nummerierungstiefe steuern:
\setcounter{secnumdepth}{3}
% Bis zu welcher Ebene Nummern vergeben werden

Nummerierung: Wann nummerieren, wann nicht?

In LaTeX werden \chapter, \section und \subsection automatisch nummeriert. Aber nicht alles soll nummeriert werden. Die Faustregel:

Nummeriert (mit Nummer im Inhaltsverzeichnis)

Alles, was zum inhaltlichen Kern der Arbeit gehört:

• Einleitung (Kapitel 1)
• Theoretische Grundlagen (Kapitel 2)
• Alle praktischen Kapitel (Kapitel 3, 4, 5, ...)
• Zusammenfassung und Ausblick (letztes Kapitel)
• Alle Unterkapitel davon

% Nummerierte Überschriften (Standard):
\chapter{Einleitung}           % 1 Einleitung
\section{Problemstellung}      % 1.1 Problemstellung
\subsection{Hintergrund}       % 1.1.1 Hintergrund

Nicht nummeriert (ohne Nummer, aber im Inhaltsverzeichnis)

Formale Teile, die nicht zum Haupttext gehören:

• Kurzfassung / Abstract
• Vorwort
• Eidesstattliche Erklärung
• Danksagung
• Literaturverzeichnis

% Nicht nummeriert, aber im Inhaltsverzeichnis:
\chapter*{Kurzfassung}
\addcontentsline{toc}{chapter}{Kurzfassung}

\chapter*{Vorwort}
\addcontentsline{toc}{chapter}{Vorwort}

% Nicht nummeriert und NICHT im Inhaltsverzeichnis:
\chapter*{Eidesstattliche Erklärung}
% (ohne \addcontentsline)

Übersicht: Was wird wie behandelt?

% Römische Nummerierung für Frontmatter:
\pagenumbering{roman}

% ... Kurzfassung, Abstract, Verzeichnisse ...

% Arabische Nummerierung ab Einleitung:
\pagenumbering{arabic}

Theorie vs. Praxis: Wie trennt man das?

Eine der häufigsten Fragen bei der Diplomarbeit: „Was kommt in die Theorie, was in die Praxis?“ Die Antwort ist einfacher als man denkt.

Das Prinzip

Der Lackmustest

Stellt euch bei jedem Absatz die Frage:

• „Würde das auch ohne unser Projekt stimmen?“ → Ja = Theorie
• „Bezieht sich das auf unsere konkrete Umsetzung?“ → Ja = Praxis

Praxisbeispiel: REST-API-Diplomarbeit

Typische Aufteilung bei einer IT-Diplomarbeit

THEORIE (Kapitel 2 – gemeinsam oder aufgeteilt)
├── 2.1  Verwendete Technologien
│   ├── Was ist React? (allgemein)
│   ├── Was ist Node.js? (allgemein)
│   └── Was ist PostgreSQL? (allgemein)
├── 2.2  Architekturmuster
│   ├── REST-Architektur (allgemein)
│   ├── MVC-Pattern (allgemein)
│   └── Client-Server-Modell (allgemein)
├── 2.3  Sicherheitskonzepte
│   ├── Authentifizierung vs. Autorisierung
│   └── JWT-Token (allgemein)
└── 2.4  Testmethoden
    ├── Unit-Tests (allgemein)
    └── Integrationstests (allgemein)

PRAXIS (Kapitel 3, 4, 5 – pro Teammitglied)
├── 3  Backend (Max)
│   ├── 3.1  Anforderungen an das Backend
│   ├── 3.2  Architektur-Entwurf
│   │   ├── Schichtenmodell unserer API
│   │   └── Datenbankschema unserer Anwendung
│   ├── 3.3  Implementierung
│   │   ├── Express.js-Setup (unser Code)
│   │   ├── API-Endpunkte (unsere Endpunkte)
│   │   └── JWT-Implementierung (unser Code)
│   └── 3.4  Test & Ergebnisse
│       ├── Testfälle (unsere Tests)
│       └── Performance-Messungen (unsere Daten)
├── 4  Frontend (Lisa) ...
└── 5  Datenbank (Tom) ...

Häufige Fehler bei der Theorie-Praxis-Trennung

Die Verbindung zwischen Theorie und Praxis

Theorie und Praxis dürfen nicht isoliert nebeneinander stehen. Sie müssen sich aufeinander beziehen:

% Im Theorie-Kapitel:
REST definiert sechs Architekturprinzipien, wobei die
Zustandslosigkeit (Statelessness) bedeutet, dass jede
Anfrage alle nötigen Informationen enthält
\parencite[S.~76]{fielding2000}.

% Im Praxis-Kapitel (später):
Basierend auf dem in Abschnitt~\ref{sec:rest} beschriebenen
Zustandslosigkeitsprinzip speichert die API keine
Session-Daten. Stattdessen wird bei jeder Anfrage ein
JWT-Token mitgesendet (siehe Abschnitt~\ref{sec:jwt}).

Wer schreibt die Theorie?

Es gibt zwei gängige Ansätze:

Gliederungstiefe

Seitenumfang & Wörteranzahl

Laut BMBWF-Leitfaden (diplomarbeiten-bbs.at) gilt pro Person: ca. 20–25 Seiten reiner Text bzw. ca. 4.800–6.000 Wörter. Der Grundsatz lautet: „Prägnanz vor Länge“. Verzeichnisse, Anhänge und Deckblatt zählen nicht zum Seitenumfang.