Umsetzung dokumentieren

Die Umsetzung (oder „Realisierung") ist das mit Abstand größte Kapitel deiner Doku – 3–4 Seiten, das sind 25–35 % des Hauptteils. Hier zeigst du, wie du das Soll-Konzept in die Praxis umgesetzt hast. Genau hier passieren auch die häufigsten Stilfehler: zu viel Code, zu wenig Erklärung; zu viele Screenshots, zu wenig Struktur; zu detailliert oder zu oberflächlich.

Diese Lektion zeigt dir, wie du Code und Konfigurationen dokumentierst, welche Screenshots wirklich gehören, wie du Entscheidungen während der Umsetzung festhältst, und wie du die richtige Detail­tiefe findest. Wer dieses Kapitel gut beherrscht, holt aus der 30-%-„fachliche Lösung"-Bewertung das Maximum heraus.

1) Was in das Umsetzungs­kapitel gehört

Das Umsetzungs­kapitel beschreibt den tatsächlich durchgeführten Weg von der geplanten Lösung bis zum funktionierenden Ergebnis. Es ist kein Tagebuch („Montag 9 Uhr habe ich angefangen") und auch kein Vollabdruck aller Konfigurationen, sondern eine strukturierte, begründete Darstellung der wichtigen Schritte und Entscheidungen.

• Vorgehen pro Realisierungs­phase: was wurde wann gemacht, in welcher Reihenfolge
• Begründete Entscheidungen: warum so und nicht anders, falls Wahl­situationen aufkamen
• Code- und Konfigurations­auszüge: die wichtigen Stellen, nicht alles
• Screenshots: vorher/nachher, kritische Konfigurations­schritte, fertige Oberflächen
• Abweichungen vom Plan: was hat sich gegenüber dem Soll-Konzept geändert, warum
• Probleme und Lösungen: was lief schief, wie wurde es behoben

2) Aufteilung in Realisierungs­phasen

Statt das Umsetzungs­kapitel als 3-Seiten-Block zu schreiben, gliederst du es in 3–6 Unter­phasen. Das macht es lesbar und erleichtert dem Prüfer das Folgen. Die Unter­phasen orientieren sich am PSP aus der Projektplanung.

3) Code und Konfigurationen sinnvoll einbinden

Code und Konfigurations­schnipsel sind in der Doku willkommen – aber nur die relevanten Stellen. Eine 20-Zeilen-Konfiguration zur Erklärung der Verschlüsselungs­einstellung ist gut. Ein 200-Zeilen-Vollabdruck einer Konfiguration ist es nicht.

# Neuer Backup-Job mit Verschlüsselung
Add-VBRJob -Name "Daily-Fileserver" `
    -BackupRepository "NAS-Primary" `
    -RetentionPolicy 90 `
    -EncryptionKey "ProjBackup2026!" `
    -Schedule "02:00" -DaysOfWeek "Mon-Sun"

# Off-Site-Kopie zur Cloud
Add-VBRBackupCopyJob -SourceJob "Daily-Fileserver" `
    -TargetRepository "Cloud-EU-West" `
    -RetentionDays 365

Drei Regeln für Code in der Doku:

1. Nur die relevanten Zeilen: lange Konfigurationen kürzen, die wichtigen Stellen mit „…" oder Auslassungs­punkten markieren
2. Mit Erläuterung: jeder Code-Block hat einen Erklär-Text drunter, der sagt, was er tut und warum diese Einstellung
3. Lesbar formatieren: Monospace-Schrift, eingerückt, ggf. Syntax-Hervorhebung. Eine Wand aus unformatiertem Code wirkt unprofessionell

4) Was rein, was raus – Detail­tiefe

Eines der häufigsten Probleme: zu viel oder zu wenig Detail. Die richtige Tiefe lässt sich mit zwei Fragen prüfen:

• Fachperson kann nachvollziehen: würde eine fachkundige Person den Schritt nachstellen können? Wenn nein: zu wenig Detail. Wenn die Person aber gelangweilt wäre („das ist Standard, das weiß jeder"): zu viel Detail
• Begründung erkennbar: ist die Wahl der Einstellung begründet, oder nur die Tatsache, dass sie existiert?

5) Screenshots richtig einsetzen

Screenshots sind kraftvoll, wenn sie sparsam und sinnvoll eingesetzt werden. Zu viele Screenshots verstopfen die Doku; zu wenige machen sie trocken. Faustregel: einer pro 1–2 Seiten. Vier Regeln:

6) Vorher/Nachher-Darstellung

Ein besonders starkes Mittel ist die Vorher/Nachher-Darstellung. Sie macht in einem Bild klar, was sich geändert hat – und zeigt sofort den Mehrwert des Projekts:

Vorher/Nachher-Bilder werden in der Doku besonders gerne in der Übergangs­zone zwischen Umsetzung und Test eingesetzt. Sie liefern dort die emotionale Bestätigung („es hat funktioniert"), die Prüfende motiviert. Aber: nur mit echtem Inhalt, nicht erfunden.

7) Entscheidungen während der Umsetzung dokumentieren

Während der Realisierung treten oft Situationen auf, in denen du eine konkrete Entscheidung treffen musst – meist nicht im Soll-Konzept vorgesehen. Diese Entscheidungen zu dokumentieren wirkt sehr professionell und zeigt methodisches Denken.

Du musst nicht jede Mikro-Entscheidung loggen – aber 3–5 zentrale Entscheidungen aus der Realisierung sollten dokumentiert sein. Die Doku zeigt damit, dass du nicht blind nach Plan gearbeitet hast, sondern unterwegs reflektierte Wahlen getroffen hast.

8) Abweichungen vom Plan

Manchmal läuft etwas anders als im Soll-Konzept beschrieben. Vielleicht war die geplante Hardware nicht verfügbar, vielleicht hat ein Test eine Anforderungs­änderung gebracht. Abweichungen zu verschweigen ist gefährlich – sie kommen meist im Fachgespräch hoch. Stattdessen:

• Klar benennen: „Vom ursprünglichen Plan abweichend wurde …"
• Begründen: warum die Änderung sinnvoll oder unumgänglich war
• Auswirkungen darstellen: was bedeutet das für Zeitplan, Kosten, Ergebnis?
• Bewerten: war die Änderung positiv oder negativ?

Eine professionelle Formulierung sieht z. B. so aus: „Vom ursprünglich geplanten NAS-Modell QNAP TS-453D wurde aufgrund Liefer­engpasses auf das gleichwertige Synology DS920+ ausgewichen. Die technische Spezifikation ist vergleichbar (4 Bays, 4 GB RAM), die Konfigurations­oberfläche unterscheidet sich. Dies führte zu ca. 1,5 h Mehrarbeit für Einarbeitung in das DSM-Betriebssystem, ohne Auswirkung auf das Projekt­ergebnis."

9) Probleme und Lösungen einbauen

Aus der Bewerter-Perspektive: ein perfektes Projekt ohne jegliche Probleme wirkt unrealistisch. Echte Probleme mit ihren Lösungen sind dagegen wertvolle Doku-Inhalte, weil sie Lösungs­kompetenz zeigen.

Eine solche Problem-Lösungs-Sequenz bringt mehrere positive Signale: Tool-Kenntnis (Wireshark), Diagnose-Fähigkeit (Ursache identifiziert), Lösungs­kompetenz (Anpassung umgesetzt) und Doku-Disziplin (Konfigurations­handbuch aktualisiert).

10) Häufige Fehler in der Umsetzungs­doku

• Tagebuch-Stil: „Am Dienstag habe ich angefangen, dann …" – gehört nicht in die Doku
• Code-Wand ohne Erklärung: 50 Zeilen Konfiguration ohne ein Wort dazu. Heilung: jeden Block kommentieren
• Screenshot-Lawine: alle 0,5 Seiten ein Screenshot. Heilung: nur die wichtigsten, mit Erklärung
• Hersteller-Anleitung kopiert: das ist Plagiat. Heilung: eigene Worte, eigene Notizen, ggf. Hersteller­doku als Quelle nennen
• Triviale Schritte erklärt: „Ich habe auf den Installations­assistenten geklickt." Heilung: nur dort vertiefen, wo es nicht trivial ist
• Keine Begründungen: „Ich habe Wert X auf 30 gesetzt." Warum? Heilung: bei jeder Einstellung kurz die Wahl begründen
• Plan und Wirklichkeit verschwiegen: alles tut, als sei nach Plan gelaufen. Heilung: Abweichungen ehrlich nennen
• Keine Probleme dokumentiert: wirkt unrealistisch. Heilung: 1–2 echte Probleme mit Lösung einbauen
• Falsche Reihenfolge: chronologisch statt strukturiert. Heilung: nach Phasen aus dem PSP gliedern
• Sensible Daten drin: echte Passwörter, IP-Adressen, Konfigurations­daten. Heilung: anonymisieren / unkenntlich machen

11) Übergang zum Test­kapitel

Das Umsetzungs­kapitel endet mit einem fließenden Übergang zum Test. Eine bewährte Form: am Ende kurz auflisten, was jetzt zu testen ist. Das macht klar, dass die Test­phase eine bewusste Fortsetzung ist – nicht ein optionaler Anhang. Beispiel: „Mit Abschluss der Realisierungs­phase steht ein voll konfiguriertes Backup-System bereit. Im folgenden Kapitel werden die definierten Anforderungen (F1–F5, N1–N5) durch konkrete Testfälle nachgewiesen, insbesondere die zentrale Anforderung an die Wiederherstellungs­zeit (N1)."

12) Tipps für eine starke Umsetzungs­doku

1. Phasen aus PSP übernehmen: konsistente Struktur, leichter zu lesen
2. Code mit Kontext: keine nackten Schnipsel, immer mit „was" und „warum"
3. Screenshots minimal & markiert: Augen­führung durch rote Pfeile / Rahmen
4. Begründete Entscheidungen 3–5×: zeigt methodisches Denken
5. Abweichungen offen: kein Schönreden, ehrliche Darstellung
6. 1–2 echte Probleme: mit Lösung dokumentieren – wertet auf
7. Vorher/Nachher: visuelle Bestätigung des Mehrwerts
8. Anonymisierung prüfen: vor Druck nochmal durchgehen
9. Lesbarkeit testen: probedrucken, prüfen ob alle Bilder noch lesbar sind
10. Übergang zum Test: am Ende kurz auf das nächste Kapitel verweisen

Zusammenfassung

Das Umsetzungs­kapitel ist mit 3–4 Seiten das größte der Doku und das Herzstück der „fachliche Lösung"-Bewertung. Inhalt: Vorgehen pro Phase (aus PSP übernommen), begründete Entscheidungen, Code- und Konfigurations­auszüge (nur die wichtigen, mit Erklärung), Screenshots (1 pro 1–2 Seiten, zugeschnitten, markiert, beschriftet, anonymisiert), Abweichungen vom Plan (offen kommunizieren), Probleme und Lösungen (echte Beispiele wertvoll). Detail­tiefe: Fachperson muss nachvollziehen können, aber nicht gelangweilt sein. Häufige Fehler: Tagebuch-Stil, Code-Wand ohne Erklärung, Screenshot-Lawine, kopierte Hersteller-Doku, triviale Schritte, fehlende Begründungen, Probleme verschwiegen. Tipps: PSP-Phasen übernehmen, 3–5 begründete Entscheidungen, Vorher/Nachher zeigen, Anonymisierung prüfen, Übergang zum Test setzen, paralleles Arbeits­tagebuch führen.