Inhalte der Projektdokumentation

Da viele Prüflinge Probleme haben, die richtigen (heißt: interessanten und aussagekräftigen) Inhalte für ihre Projektdokumentation zu finden, habe ich im Folgenden meine Vorstellungen von den erwarteten Inhalten aufgelistet.

Anmerkungen

  • Kursive Punkte sind optional bzw. nur bei Bedarf zu erstellen.
  • Die Reihenfolge der Punkte ist nicht fix und es können auch mehrere Punkte zusammengefasst werden.
  • Alle Artefakte (Bilder, Listings, Tabellen usw.) sollten in den Anhang ausgelagert werden, damit die vollen 15 Seiten der Dokumentation für den Text zur Verfügung stehen.
  • Die Vorgaben der IHK bzgl. Seitengestaltung, Seitenzahl usw. sind penibel einzuhalten.
  • Eine „sehr gute“ Dokumentation…
    • ist fehlerfrei hinsichtlich Rechtschreibung/Grammatik/Layout/Verzeichnissen/Verweisen/Literaturangaben etc.
    • erfüllt alle unten angegebenen Punkte.
    • geht aber auch noch darüber hinaus, enthält also ein besonders umfangreiches Projekt mit viel Eigenleistung und außergewöhnlichem Inhalt.

Inhalte

  • Formblatt der entsprechenden IHK
  • Deckblatt mit Informationen zum Projekt
    • Titel des Projekts
    • Name, Kontaktdaten, Geburtsdatum, Ausbildungsberuf des Auszubildenden
    • Name, Kontaktdaten des Ausbildungsbetriebs
  • Verzeichnisse (Inhalt, Abbildungen, Tabellen, Abkürzungen, Quellen (!), Anhang, Listings)
  • Einleitung
    • Projektumfeld: Ausbildungsbetrieb, Auftraggeber/Kunde etc.
    • Projektziel: Was soll erreicht werden? Worum geht es eigentlich?
    • Projektbegründung: Warum ist das Projekt sinnvoll? Was ist die Motivation hinter dem Projekt?
    • Projektschnittstellen: Mit welchen anderen Systemen interagiert die Anwendung? Wer sind die Benutzer der Anwendung?
    • Projektabgrenzung: Was ist explizit nicht Teil des Projekts (insb. bei Teilprojekten)?
  • Projektplanung
    • Projektphasen mit detaillierter Zeitplanung: Beschreibung/Begründung des gewählten Vorgehensmodells
    • Ressourcenplanung: Was wird an Ressourcen benötigt (z.B. Hardware, IDE, Betriebssystem)? Gibt es Einschränkungen?
    • Kostenplanung/-kalkulation: Was kostet das Projekt? Mögliche Kosten: Entwicklung, Einführung/Schulung, Wartung
      • Make-or-buy-Entscheidung
      • Amortisationsrechnung: Ab wann rentiert sich das Projekt? Mögliche Einsparungen: Lizenzen, Arbeitszeitersparnis, Usability, Korrektheit. Break-Even-Punkt grafisch verdeutlichen (Graph mit Schnittpunkten)
    • nicht-monetärer Nutzen/Nutzwertanalyse: z.B. Vorher-/Nachher-Vergleich anhand eines Wirtschaftlichkeitskoeffizienten
      • wichtig: immer den Maßstab für die Gewichtung (warum sind die Kriterien unterschiedlich wichtig?) und die Bewertung (z.B. Punkte von 1 bis 5: was bedeutet das?) angeben
    • Vorgehensmodell beschreiben: Wurde agil entwickelt, vielleicht gar testgetrieben, oder wurde das Wasserfall- oder ein andere Modell eingesetzt?
  • Projektdurchführung: Was wurde genau während des Projekts durch den Auszubildenden gemacht? Wie ist er vorgegangen?
    • Ist-Analyse: Wie ist die bisherige Situation (z.B. bestehende Programme, Wünsche der Mitarbeiter)? Was gilt es zu erstellen/verbessern?
    • Lastenheft erstellen (fachliche Anforderungen)
    • Design/Entwurf
      • Beschreibung des Programms, Ziel der Entwicklung
      • Funktionen des Programms: z.B. mit Use-Case-/Aktivitätsdiagramm, EPK
      • technische Umgebung: Zielplattform (Programmiersprache, Datenbank, Client, Server, Software, Hardware), Benutzer/Zielgruppen
      • Datenbank (ERM, Tabellenmodell) bzw. wenn keine Datenbank verwendet wird, Darstellung der eingesetzten Datenstrukturen (z.B. XML, CSV o.ä.)
      • Geschäftslogik: z.B. Komponenten-/Klassen-/Sequenz-/Datenflussdiagramm, Architekturplanung, EPK
      • Benutzerschnittstelle: z.B. GUI, Webinterface, Entwurf/Gestaltung der Oberflächen/Masken, Corporate Identity, Einbindung in andere Anwendungen
      • Qualitätsmerkmale: z.B. Anforderungen hinsichtlich Performance, Usability, Effizienz etc. (ISO 9126)
      • Qualitätssicherung: Testszenarien, Benutzer-/Entwicklertests, Code-Reviews, statische Codeanalyse
    • Pflichtenheft erstellen (geplante technische Umsetzung)
    • Implementierung/Realisierung
      • Datenbank anlegen
      • Programmierung (interessante Funktionen zeigen, Quelltextbeispiele)
      • Screenshots der Oberfläche
    • Test/Qualitätssicherung: z.B. Test-Reports, Unit-Tests, Code-Reviews
    • Dokumentation: Projektdokumentation, Entwickler- (z.B. JavaDoc) und Benutzerdokumentation („Handbuch“)
    • Einführung/Deployment/Abnahme: z.B. Installation, Benutzerschulung, automatische Builds einrichten
  • Retrospektive: Wie ist das Projekt rückblickend zu bewerten?
    • Begründung von Änderungen zum Projektantrag
    • Soll-/Ist-Vergleich: Wurde das Ziel erreicht? Wurden die Kosten/Zeiten eingehalten?
    • Ausblick: Erweiterungsmöglichkeiten, Anschlussprojekte, Akzeptanz der Benutzer
    • Fazit, Lessons Learned, kritische Bewertung
  • Selbständigkeitserklärung des Auszubildenden
  • Anhänge
    • Lasten-/Pflichtenheft
    • Datenbankentwurf
    • UML-Diagramme, EPKs, Flusspläne, PAPs
    • Entwürfe/Screenshots der Oberflächen
    • Dokumentation (Entwickler/Benutzer)
    • Glossar
    • Quelltexte

Meine Vorlage für die Projektdokumentation

Falls euch die obige Liste noch nicht reicht, empfehle ich euch meine Vorlage für die Dokumentation zur betrieblichen Projektarbeit mit Vorstrukturierung und vielen Beispielinhalten.

Weitere Infos zur Projektdokumentation

Du suchst noch mehr Tipps rund um die Projektdokumentation? Dann schau doch mal in diese Artikel- und Podcast-Kategorie: Alle Artikel rund um die Projektdokumentation.

Kennst du schon meine Microsoft Word-/LibreOffice-Vorlage für die Projektdokumentation? Unter dieperfekteprojektdokumentation.de kannst du sie herunterladen.

Und wenn du dich für meinen Newsletter einträgst, kannst du dir jetzt sofort meine Checkliste für die Projektdokumentation herunterladen.

Checkliste für die Projektdokumentation

6 thoughts on “Inhalte der Projektdokumentation

  1. Hallo,

    habe mir Ihre Vorlage angeguckt und festgestellt, dass die Zeit- und Ressourcenplanung vor der IST und Soll Analyse stehen. Ist das vom logischen Ablauf her nicht vertauscht?

    Danke im Voraus
    Falko

  2. Hallo Falko,

    du musst unterscheiden, wie die Reihenfolge in deiner Projektdurchführung tatsächlich abgelaufen ist, und wie du das dann „schön lesbar“ in der Doku darstellst. Irgendeinen Haken gibt es dabei immer. In der Praxis hast du natürlich recht, aber ich (persönlich) finde die Reihenfolge in der Doku unglücklich. Dir steht natürlich frei, das einfach für deine Doku zu ändern.

    Viele Grüße!
    Stefan

  3. Eins der Artefakte das Sie aufzählen ist „Listings“. Ich habe „Listings Projektdokumentation“ gegoogelt, aber was ich dabei finde sind praktisch nur Verweise auf Ihre Seite. Könnten Sie mir vielleicht kurz erklären was damit gemeint ist?

  4. Listings sind Quelltextauszüge, SQL-Scripts, Kommandozeileneingaben usw. Also alles, was du in nicht-proportionaler Schrift als Artefakt in deine Dokumentation einbauen würdest. Da sie sehr lang sind, gehören sie in den Anhang und sollten damit auch nummeriert und in einem Verzeichnis zusammengestellt werden (analog zu Abbildungen und Tabellen).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax