Beispiel-Projektdokumentation (kommentiert)
Diese Abschluss-Lektion bringt alles aus den vorhergehenden neun Lektionen zusammen – am Beispiel einer vollständigen, kommentierten Projektdokumentation. Du siehst, wie eine ordentliche Doku in der Praxis aussieht und welche Aspekte einen guten Eindruck machen. Die Beispiel-Doku stammt aus einem fiktiven, aber realitätsnahen FISI-Projekt: „Konzeption und Einrichtung eines zentralen Backup-Systems für die Müller GmbH". Klick die Kapitel an, um die Beispiel-Passage und die Kommentare aus Prüfer-Sicht zu sehen. Pro Kapitel siehst du eine Roh-Doku-Seite (wie sie wirklich aussehen würde) und darunter eine Kommentar-Box mit zwei Spalten: was funktioniert hier gut und was würde noch verbessern. Die Beispiele sind als „gut bis sehr gut" angelegt – nicht perfekt, denn ein realistisches Vorbild zeigt auch noch Verbesserungs-Potenzial. Das ist die finale Lektion des Kurses K68: alle vorherigen Konzepte in einem zusammenhängenden Bild.
1) Projekt-Steckbrief
2) Die Doku Kapitel für Kapitel
Klicke die einzelnen Bestandteile an, um die Beispiel-Doku und die zugehörigen Kommentare zu öffnen:
ADeckblatt
zentralen Backup-Systems
Auftraggeber: Müller GmbH, Konstanz
Kommentar zum Deckblatt
- Titel prägnant, deckt sich mit Antrag
- Untertitel macht Zweck klar
- Auftraggeber sichtbar
- Alle Pflicht-Angaben (Name, Beruf, Betrieb, IHK, Termin)
- Sauber, ohne Kitsch
- Logo des Ausbildungs-Betriebs (wenn erlaubt) wirkt professioneller
- Eindeutigeres Datums-Format (24.04.2026) statt Wort-Datum vermeidet Übersetzungs-Probleme
1Einleitung
1.1 Projektumfeld
Die Müller GmbH ist ein mittelständischer Logistik-Dienstleister mit 35 Mitarbeitenden und einer IT-Infrastruktur aus 12 produktiven Servern (8 Windows Server 2019/2022, 3 Linux, 1 Speicher-Appliance). Geschäftskritisch sind das ERP-System (Sage), die Lagerverwaltung (eigene Anwendung), das Dateiarchiv und die Postfächer von Microsoft 365.
1.2 Auftrag und Ziele
Der Auftraggeber – Herr Schulz, IT-Leitung – beauftragte die Konzeption und Umsetzung eines neuen Backup-Systems. Die bestehende, dezentrale Bandsicherung wird seit ihrer Einführung 2018 nicht mehr regelmäßig auf Restore-Fähigkeit geprüft, der Wartungs-Aufwand übersteigt zwei Stunden pro Woche, und ein Off-Site-Schutz gegen Ransomware fehlt vollständig.
Folgende Ziele wurden vereinbart (SMART formuliert):
- Z1: Tägliche Sicherung aller 12 produktiven Server bis 03:00 Uhr Lokalzeit (MUST).
- Z2: Recovery Time Objective (RTO) ≤ 4 Stunden für jedes Einzelsystem (MUST).
- Z3: Recovery Point Objective (RPO) ≤ 24 Stunden (MUST).
- Z4: Off-Site-Kopie verschlüsselt in einer EU-Cloud-Region (MUST, DSGVO).
- Z5: Monatlich automatisierter Restore-Test eines zufällig ausgewählten Systems (SHOULD).
1.3 Abgrenzung
Nicht im Scope des Projekts sind: Endgeräte-Backup (separates Folge-Projekt geplant), Backup der externen SaaS-Dienste (M365-Backup wird in einem späteren Sprint adressiert) sowie die Schulung der Endanwender (durch interne Schulungs-Abteilung).
Kommentar zur Einleitung
- Kurz und fokussiert (~ 1 Seite) – keine Firmen-Vorstellung in Hülle und Fülle
- Konkrete Zahlen: 35 MA, 12 Server, 2 h Wartungs-Aufwand
- SMART-Ziele mit MUST/SHOULD-Priorisierung
- Klare Abgrenzung – sagt, was NICHT zum Projekt gehört
- Auftraggeber namentlich benannt
- Risiko-Bewertung des aktuellen Zustands (Was passiert bei Total-Ausfall?) zur Begründung der Dringlichkeit
- Stakeholder-Übersicht als Mini-Tabelle (Geschäftsführung, IT, Datenschutz-Beauftragter) wäre Plus
3Ist-Analyse
Die Ist-Analyse stützt sich auf drei Erhebungs-Methoden: ein strukturiertes Interview mit Herrn Schulz (Anhang A1), eine Sichtung der vorhandenen Wartungs-Doku und Ticket-Statistik 2024-2025 (Anhang A2) sowie eine technische Bestandsaufnahme der bestehenden Bandsicherung am 11.03.2026.
3.1 Bestehende Backup-Lösung
Die aktuelle Lösung besteht aus drei eigenständigen LTO-6-Bandlaufwerken, die jeweils nachts pro Server-Gruppe Vollsicherungen auf wechselnde Bänder schreiben. Die Bänder werden montags-freitags getauscht, ein 14-Tage-Zyklus wird mündlich kommuniziert, aber nicht systematisch dokumentiert. Verschlüsselung der Bänder ist nicht aktiv.
3.2 Identifizierte Schwachstellen
| ID | Schwachstelle | Risiko | Quelle |
|---|---|---|---|
| S1 | Keine geprüfte Restore-Fähigkeit seit > 14 Monaten | hoch | Interview Schulz |
| S2 | Bänder unverschlüsselt – Diebstahl-Risiko | hoch | Bestandsaufnahme |
| S3 | Bänder lagern im selben Brandabschnitt wie Server | mittel | Bestandsaufnahme |
| S4 | Manueller Wartungs-Aufwand ca. 2 h/Woche | mittel | Ticket-Statistik |
| S5 | Keine zentrale Übersicht über Backup-Status | mittel | Interview Schulz |
| S6 | Kein Schutz gegen Ransomware (alle Bänder online erreichbar) | hoch | Bestandsaufnahme |
3.3 Mengen-Gerüst
Gesamtes zu sicherndes Volumen: ca. 4,2 TB (Datenbank-Cluster 1,8 TB, Dateiarchiv 1,5 TB, restliche Server 0,9 TB). Jährliches Wachstum laut Trend-Analyse rund 18 %. Spitzen-Schreibrate beim Vollbackup ca. 280 MB/s (gemessen mit iostat).
Kommentar zur Ist-Analyse
- Mehrere Erhebungs-Methoden kombiniert – nicht nur Interview
- Anlagen referenziert (A1, A2) → Anhang sinnvoll genutzt
- Schwachstellen tabellarisch mit ID, Risiko und Quelle
- Konkrete Zahlen: 4,2 TB, 18 % Wachstum, 280 MB/s
- Anhang A2 enthält Auszug aus Ticket-System als Beleg
- Bestehende Netzwerk-Topologie als Skizze einfügen
- Kostenseite der aktuellen Lösung quantifizieren (Bänder, Strom, Wartungs-Stunden × Stundensatz)
- Hinweis auf Datenschutzbeauftragten / DSGVO als formale Quelle für S2
4Soll-Konzept
4.1 Anforderungen
Aus den identifizierten Schwachstellen (Kap. 3.2) wurden folgende Anforderungen abgeleitet und nach MoSCoW priorisiert (Auszug; vollständige Tabelle Anhang A3):
| ID | Anforderung | Bezug | Prio |
|---|---|---|---|
| A1 | Geprüfte Restore-Fähigkeit aller Systeme | S1 | MUST |
| A2 | Verschlüsselung Backup-Daten ≥ AES-256 | S2 | MUST |
| A3 | Off-Site-Kopie in separatem Brandabschnitt | S3, S6 | MUST |
| A4 | Reduktion Wartungs-Aufwand auf ≤ 1 h/Woche | S4 | SHOULD |
| A5 | Zentrales Dashboard mit Backup-Status | S5 | MUST |
| A6 | Mail-Alarmierung bei fehlgeschlagenen Jobs | S5 | SHOULD |
| A7 | DSGVO-konforme Speicherung (EU-Region) | Z4 | MUST |
| A8 | Self-Service-Restore für Endanwender | — | COULD |
4.2 Lösungs-Varianten
Drei Architektur-Varianten wurden gegenübergestellt:
Variante A: Veeam B&R On-Prem mit NAS + Tape
Lokaler Veeam-Server, primäres Backup auf NAS-Appliance, sekundäre Sicherung auf wöchentliche LTO-9-Bänder. Vorteil: Datenhoheit, schnellster Restore. Nachteil: Bänder weiterhin im Haus, hoher CapEx.
Variante B: Backup-as-a-Service (Cloud)
Vollständig externalisiertes Backup über Anbieter (z. B. Acronis, Backblaze). Vorteil: kein eigener Backup-Server, OpEx statt CapEx. Nachteil: Bandbreite, US-Anbieter-Risiken, langsamerer Restore bei großen Datenmengen.
Variante C: Hybrid (Empfehlung)
Veeam B&R lokal mit primärem Backup auf NAS, zusätzlich verschlüsselte Kopie nach AWS S3 (Region eu-central-1, Frankfurt). Erfüllt sowohl die Anforderung an schnellen lokalen Restore (RTO < 4 h) als auch den Off-Site-Schutz und die DSGVO-Konformität (EU-Region).
4.3 Auswahl-Begründung (Nutzwertanalyse)
Eine Nutzwertanalyse mit sechs gewichteten Kriterien (vollständig Anhang A4) führt zu folgendem Ergebnis: Variante C 7,50 Pkt., Variante A 6,80 Pkt., Variante B 6,35 Pkt. Variante C wird daher zur Umsetzung empfohlen.
4.4 Wirtschaftlichkeit
| Position | Variante A | Variante B | Variante C |
|---|---|---|---|
| CapEx (einmalig) | 14 200 € | 1 200 € | 11 500 € |
| OpEx (jährlich) | 3 100 € | 5 800 € | 4 200 € |
| TCO 5 Jahre | 29 700 € | 30 200 € | 32 500 € |
Quantifizierbarer Nutzen: Reduktion Wartungs-Aufwand um 1 h/Woche × 52 Wo × 65 €/h = 3 380 € p.a. Plus Risiko-Schutz vor Ransomware-Vorfall (BSI-Lagebericht 2024: mittlere Schadenshöhe in vergleichbaren KMU ca. 95 000 €; Eintritts-Wahrscheinlichkeit konservativ 5 % p.a. → erwarteter jährlicher Schaden ca. 4 750 €, der durch die Off-Site-Kopie signifikant reduziert wird).
Kommentar zum Soll-Konzept
- Anforderungen explizit aus Schwachstellen abgeleitet (Spalte „Bezug")
- MoSCoW-Priorisierung sauber genutzt
- Drei echte Architektur-Varianten – keine Schein-Alternativen
- Nutzwertanalyse mit Hinweis auf Detail-Tabelle im Anhang
- Wirtschaftlichkeits-Rechnung mit CapEx + OpEx + TCO + quantifiziertem Risiko-Nutzen
- Externe Quelle (BSI-Lagebericht) als Beleg für Schadens-Annahme
- Architektur-Skizze der gewählten Variante C als Abbildung
- Sensitivitäts-Analyse: Was wenn Ransomware-Wahrscheinlichkeit 2 % oder 10 % wäre?
- Variante B etwas zu schnell verworfen – Detail-Diskussion zu Bandbreite hätte argumentativ geholfen
5Realisierung
5.2 Konfiguration der Backup-Software
Für die Backup-Jobs wurde eine 3-Tier-Strategie umgesetzt: tägliche inkrementelle Sicherungen, wöchentliche synthetische Vollsicherungen und monatliche Archiv-Sicherungen. Die Aufbewahrungs-Zeiten wurden gemäß der mit dem Auftraggeber abgestimmten Anforderung konfiguriert: 30 Tageskopien, 12 Wochenkopien, 7 Jahreskopien. Die Aufbewahrungs-Dauer von 7 Jahren für Archiv-Sicherungen ist steuerrechtlich nach § 147 AO begründet.
Die Backup-Jobs wurden Server-Gruppen-basiert organisiert, um Last-Spitzen zu vermeiden und die maximale Backup-Fenster-Größe von 4 Stunden einzuhalten. Tabelle 5.1 zeigt die Job-Verteilung; die vollständige Job-Definition liegt als Anhang A6 bei.
Verschlüsselung wurde mit AES-256 auf Repository-Ebene aktiviert (Anforderung A2). Der zugehörige Master-Schlüssel wird über das interne Passwort-Management (KeePass mit MFA-geschütztem Master-Passwort) verwaltet. Ein Auszug der zugehörigen Repository-Konfiguration:
# /etc/veeam/repository-prod.conf (Auszug)
repository:
name: REPO-PROD-01
path: /backup/repo-01
encryption: aes-256
immutability: enabled
immutability_period_days: 7
retention:
daily: 30
weekly: 12
yearly: 7
Die Aktivierung der Immutability über 7 Tage stellt sicher, dass auch ein kompromittierter Admin-Account Backup-Dateien innerhalb dieser Frist nicht löschen oder verschlüsseln kann – ein wesentlicher Baustein des Ransomware-Schutzes.
5.6 Aufgetretene Probleme und Lösungen
Problem 1: Während des ersten Vollsicherungs-Laufs brach der Job für den SQL-Server nach ca. 40 % mit der Fehlermeldung VSS error 0x80042308 ab. Eine Analyse mit vssadmin list writers ergab, dass der SqlServerWriter im Status „Failed" stand. Die Lösung bestand in einem Neustart der Dienste SQL Server VSS Writer und Volume Shadow Copy, danach lief der Backup-Job vollständig durch. Als Folge-Maßnahme wurde ein Monitoring der VSS-Writer-Status in das Monitoring-Konzept aufgenommen (vgl. Kap. 5.5).
Problem 2: Die Lizenz-Aktivierung des Cloud-Connectors verzögerte sich beim Hersteller um zwei Werktage. Als Workaround wurde während der Wartezeit die Konfiguration und Verschlüsselungs-Logik der lokalen Repositories vorgezogen. Dadurch konnte der Gesamtverzug auf eine Phase begrenzt werden (vgl. Kap. 2.1, Soll-Ist-Vergleich).
Kommentar zur Realisierung
- Kein Tutorial-Stil – stattdessen begründete Entscheidungen
- Verweis auf rechtliche Grundlage (§ 147 AO) für 7-Jahres-Retention
- Kurzer Konfig-Auszug im Text, vollständige Datei im Anhang A6
- Sicherheits-Aspekt aktiv adressiert (Immutability als Ransomware-Schutz)
- Konkretes Problem mit Fehlernummer, Analyse-Befehl, Lösung und Folge-Maßnahme
- Querverweise zu anderen Kapiteln
- Eine Architektur-Skizze (Datenflüsse Veeam → NAS → S3) am Kapitel-Anfang
- Screenshot des fertigen Veeam-Dashboards als Abbildung – zeigt Ergebnis
- Erwähnung, wie der Master-Schlüssel im Notfall wiederbeschaffbar ist (Key-Escrow-Konzept)
6Test & Qualitätssicherung
6.1 Test-Konzept
Das Test-Konzept deckt alle MUST-Anforderungen (Kap. 4.1) ab. Es kombiniert Funktionstests (Backup-Job läuft durch), Restore-Tests (Wiederherstellung in einer separaten Test-Umgebung), Sicherheits-Tests (Verschlüsselung und Immutability) und einen Last-Test (Vollsicherung mit Produktiv-Datenmenge im Wartungsfenster).
6.3 Test-Fälle (Auszug)
| ID | Test-Fall | Erwartung | Ergebnis |
|---|---|---|---|
| TF-01 | Vollsicherung PROD-01 (180 GB) | Dauer < 4 h, Hash konsistent | 2 h 47 min · OK |
| TF-03 | Datei-Restore aus letzter Tageskopie | < 5 min, Hash identisch | 3 min 12 s · OK |
| TF-04 | Komplett-Restore PROD-01 in Test-Umgebung | Restore < 4 h, Anwendung startbar | 3 h 18 min · OK |
| TF-05 | Repository-Datei ohne Schlüssel öffnen | Zugriff schlägt fehl | fehlgeschlagen wie erwartet · OK |
| TF-06 | Mail-Alarm bei fehlgeschlagenem Job | Mail innerhalb 5 min | initial: keine Mail · FAIL |
| TF-06b | Re-Test nach Smarthost-Korrektur | Mail innerhalb 5 min | 1 min 32 s · OK |
| TF-07 | Cloud-Kopie nach Tagessicherung | Vollständige Kopie < 24 h | 6 h 14 min · OK |
6.4 Auswertung
Von neun durchgeführten Test-Fällen wurden acht initial bestanden, einer (TF-06, Mail-Alarmierung) zeigte einen Konfigurations-Fehler im Mail-Relay auf. Nach Korrektur der Smarthost-Einstellungen (siehe Konfigurations-Auszug Anhang A8) verlief der Re-Test erfolgreich. Alle MUST-Anforderungen sind damit nachweislich erfüllt.
6.5 Abnahme
Die Abnahme erfolgte am 21.04.2026 im Beisein des Auftraggebers (Hr. Schulz), des Ausbildungs-Beauftragten (Hr. Vogel) und der Verfasserin. Geprüft wurden im Live-Test: ein Datei-Restore aus dem Vortags-Backup, der Status der Cloud-Kopie und die Funktion der Mail-Alarmierung. Das unterschriebene Abnahme-Protokoll liegt als Anhang A9 bei.
Kommentar zum Test & QS
- Test-Konzept deckt Funktion, Restore, Sicherheit und Last ab
- Tabelle mit konkreten Erwartungen und Ergebnissen (Zeiten, Status)
- Fehlgeschlagener Test (TF-06) wird ehrlich dokumentiert – mit Re-Test (TF-06b) nach Korrektur
- Abnahme-Termin mit Beteiligten und Live-Demo benannt
- Querverweis zum Übergabe-Protokoll im Anhang
- Test-Pyramide bei diesem Projekt nicht relevant, aber kurzer Hinweis auf Unterschied zu Software-Tests könnte das fachliche Verständnis zeigen
- Eine reproduzierbare Restore-Übung mit fixem Quartals-Termin in den Wartungs-Plan aufnehmen (Übergang zum Fazit)
8Fazit, Reflexion und Ausblick
8.1 Zielerreichung
Alle MUST-Anforderungen aus dem Soll-Konzept (Kap. 4.1) wurden erfüllt: 12 produktive Server werden täglich gesichert, das gemessene RTO im Komplett-Restore-Test (TF-04) liegt mit 3 h 18 min innerhalb der Vorgabe von 4 Stunden, das RPO von 24 Stunden ist durch die tägliche inkrementelle Sicherung gewährleistet, und die Off-Site-Kopie in der AWS-Region eu-central-1 erfüllt die DSGVO-Anforderung. Die SHOULD-Anforderung A4 (Wartungs-Aufwand ≤ 1 h/Woche) konnte sogar deutlich unterboten werden (durchschnittlich 25 min/Woche im ersten Betriebsmonat). Die COULD-Anforderung A8 (Self-Service-Restore) wurde aus Zeitgründen ausgegliedert und ist als Folge-Sprint für Q3/2026 geplant.
8.2 Reflexion und Lessons Learned
Methodisch hat sich die frühe Wirtschaftlichkeits-Betrachtung in Variante C als hilfreich erwiesen – sie ermöglichte ein faktenbasiertes Gespräch mit dem Auftraggeber, der ursprünglich Variante B (rein cloudbasiert) bevorzugt hatte. Im Nachhinein hätte ich die Lizenz-Beschaffung für den Cloud-Connector bereits in der Konzept-Phase abschließen sollen, anstatt parallel zur Realisierung zu starten. Die zweitägige Verzögerung wäre damit vermeidbar gewesen.
Persönlich nehme ich aus dem Projekt zwei zentrale Erkenntnisse mit: Erstens, dass externe Abhängigkeiten (Lizenz-Provider, Cloud-Onboarding, Auftraggeber-Termine) systematisch als Risiko-Position in der Projekt-Steuerung geführt werden müssen – nicht erst, wenn sie zum Problem werden. Für künftige Projekte werde ich eine Abhängigkeits-Matrix als festen Bestandteil der Initialisierungs-Phase einführen. Zweitens hat sich gezeigt, dass ehrlich dokumentierte Fehlschläge (wie der initiale Mail-Alarm-Test TF-06) am Ende den Verbesserungs-Prozess strukturieren – das werde ich auch in den Folge-Projekten als Praxis beibehalten.
8.3 Ausblick
Folgende Schritte sind nach Projekt-Abschluss vorgesehen:
- Q3/2026: Implementierung des Self-Service-Restore-Moduls (offene COULD-Anforderung A8).
- Q4/2026: Erweiterung auf M365-Backup (separates Projekt, Verantwortung intern bei IT-Leitung).
- Ab Q2/2026 quartalsweise: Restore-Übung mit zufällig ausgewähltem System, eingebettet in das bestehende Wartungs-Fenster. Dies adressiert die im Fazit erkannte Gefahr, dass ein eingerichtetes Backup ohne regelmäßige Restore-Übung über die Zeit „blind" wird.
Das Projekt schließt die zu Beginn identifizierten Schwachstellen vollständig (S1–S6) und führt zu einer messbar verbesserten Daten-Sicherheit der Müller GmbH. Die wirtschaftliche Bewertung (vgl. Kap. 4.4) bestätigt die Investition vor allem über den reduzierten Wartungs-Aufwand und das deutlich verringerte Risiko eines Ransomware-Vorfalls.
Kommentar zum Fazit
- Klar gegliederte Drei-Teilung: Zielerreichung – Reflexion – Ausblick
- Konkrete Zahlen (3 h 18 min RTO, 25 min/Woche Wartungs-Aufwand)
- Ehrlich benannte Schwachstelle (Lizenz-Beschaffung) + abgeleitete Maßnahme (Abhängigkeits-Matrix)
- Reflexion erreicht die Warum-Ebene: nicht nur „was passierte", sondern „was lerne ich daraus"
- Ausblick mit konkreten Terminen und Verantwortlichkeiten
- Bezug zurück zu allen Kapitel-Anfangs-Schwachstellen (S1-S6)
- Ein kurzer Hinweis auf die Akzeptanz beim Auftraggeber (Zufriedenheits-Feedback) wäre Plus
- Folge-Projekte mit grobem Aufwand schätzen, nicht nur als Aufzählung
- Mögliche Skalierungs-Grenze des aktuellen Konzepts (z. B. bei welchem Datenwachstum müsste neu konzipiert werden?) andeuten
3) Was die Beispiel-Doku insgesamt richtig macht
- Roter Faden: Jede Anforderung in Kap. 4 hat einen Bezug zu einer Schwachstelle in Kap. 3 (Tabelle „Bezug"-Spalte). Jeder Test in Kap. 6 prüft eine MUST-Anforderung. Das Fazit kommt zu jeder MUST-Anforderung zurück.
- Konkrete Zahlen: Statt „schnell" → „3 h 18 min". Statt „spart Zeit" → „25 min/Woche". Statt „groß" → „4,2 TB". Macht die Doku überprüfbar und glaubwürdig.
- Ehrliche Reflexion: Der TF-06-Fehlschlag und die Lizenz-Verzögerung werden offen genannt – beides als Stärke, nicht als Schwäche. Reife zeigt sich genau darin.
- Querverweise: Kapitel verweisen aufeinander („vgl. Kap. 4.1") und auf den Anhang („Anhang A6") – die Doku liest sich wie ein vernetztes System.
- Begründungs-Kultur: Jede Entscheidung trägt eine kurze Begründung – warum AES-256, warum 7 Jahre, warum Variante C, warum Immutability. Keine Werte ohne Erklärung.
- Sicherheits-Bewusstsein: Verschlüsselung, Immutability, Master-Schlüssel-Verwaltung – Sicherheit ist nicht Beiwerk, sondern integraler Bestandteil.
- Externe Quellen: § 147 AO für Aufbewahrungs-Frist, BSI-Lagebericht für Schadens-Annahme – Behauptungen werden durch externe Quellen unterstützt.
- Anhänge sinnvoll genutzt: Anhang A1 (Interview), A2 (Ticket-Auswertung), A4 (Nutzwertanalyse), A6 (Konfig), A9 (Abnahme-Protokoll) – jeder mit klarem Bezug im Hauptteil.
4) Was du aus dieser Beispiel-Doku mitnehmen kannst
- Schreibe die Doku als zusammenhängendes Argument, nicht als Sammlung von Kapiteln. Jede Anforderung leitet sich aus dem Ist ab, jeder Test prüft eine Anforderung, jedes Fazit kommt zur Anforderung zurück.
- Sei konkret. Zahlen, Tabellen, IDs, Datumsangaben – alles, was den Leser orientiert.
- Sei ehrlich. Ein dokumentierter Fehlschlag mit Korrektur zeigt mehr Kompetenz als ein „lief alles glatt".
- Verbinde Kapitel. „vgl. Kap. X" und „siehe Anhang Y" zeigen, dass du die Doku als Ganzes denkst.
- Trenne klar zwischen Hauptteil und Anhang. Im Hauptteil das, was zur Entscheidung führt; im Anhang die Details, mit denen man bei Detail-Fragen nachprüfen kann.
- Schreib im sachlich-fachlichen Stil – durchgängig. Keine Umgangssprache, keine Werbe-Floskeln, keine Buzzwords.
- Plane parallele Doku ein. Eine Doku in dieser Qualität entsteht nicht am letzten Wochenende, sondern in begleitender Schreibarbeit während der Projekt-Durchführung.
Zusammenfassung
Diese Lektion zeigt eine vollständige Beispiel-Projektdoku für ein Backup-Projekt – mit kommentierten Auszügen aus Deckblatt, Einleitung, Ist-Analyse, Soll-Konzept, Realisierung, Test und Fazit. Jeder Abschnitt wird durch zwei Spalten kommentiert: was funktioniert und was würde noch verbessern. Die Beispiel-Doku zeigt eine Arbeit auf Note 1-2-Niveau – nicht perfekt, aber sehr solide. Kernmerkmale: roter Faden (Schwachstelle → Anforderung → Variante → Auswahl → Realisierung → Test → Fazit), konkrete Zahlen statt Adjektive, ehrliche Reflexion mit benannten Schwachstellen, Querverweise zwischen Kapiteln, begründete Entscheidungen und sinnvoll genutzte Anhänge. Diese Lektion fasst zugleich den Kurs K68 zusammen: alle Konzepte aus den Lektionen 1-9 in einem zusammenhängenden Beispiel anwendbar.
Verwandte Lektionen: Aufbau Doku · Häufige Fehler · Fazit & Anhänge · und mehrWeitere relevante LektionenIHK-AnforderungenProjektantragIst & SollZeitplanungUmsetzungTestberichtKlassisches PM (K01)Warum IT-Doku (K65)