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

Detaillierte Besprechung der Inhalte im Podcast

Meine Vorlage für die Projektdokumentation

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

Literaturempfehlungen

  • Anselm Rohrer - Clevere Tipps für die Projektarbeit – IT-Berufe: Abschlussprüfung Teil A (Affiliate)*
  • Matthias Kalle Dalheimer - LaTeX - kurz & gut*

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

Jetzt anmelden!

Polyglot Clean Code Developer
About the Author
Ausbildungsleiter für Fachinformatiker Anwendungsentwicklung und Systemintegration, IHK-Prüfer und Hochschuldozent für Programmierung und Software-Engineering.

17 comments on “Inhalte der Projektdokumentation

  1. Falko Rüßmann sagt:

    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. Stefan Macke sagt:

    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. pro-grammr sagt:

    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. Stefan Macke sagt:

    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).

  5. Joe91 sagt:

    Soll man ab dem ersten Ausbildungsjahr schon anfangen zu vorbereiten?

  6. Stefan Macke sagt:

    Die Projektdokumentation nicht, aber für die Prüfung kann man nicht früh genug anfangen zu lernen!

  7. F.L. sagt:

    Auf dem Deckblatt das Geburtsdatum? Hier ist sicher das Abgabedatum gemeint? 😀

  8. Stefan Macke sagt:

    Nein, ich meine das Geburtsdatum. Dient der Identifikation des Prüflings. Das Abgabedatum kann aber natürlich auch ergänzt werden.

  9. Sven sagt:

    Der Bereich der Schnittstellen ist mir unklar. In manchen Dokumentation und IHK-Hinweisen werden grundsätzlich nur „personelle Schnittstellen“ aufgeführt. Nur ganz selten – zb hier – wird auch von technischen Schnittstellen gesprochen, also von fremden Systemen, mit denen interagiert wird.
    Wie verhält es sich mit den Schnittstellen?

  10. Frederic Wittmann sagt:

    Hallo Herr Macke,

    bei so einer detaillierten Anforderung an die Projektdokumention wäre man bestimmt allein eine Woche damit beschäftigt, diese auszufüllen. Das Ganze passt doch absolut nicht in den Zeitraum von 70 Stunden? Meine Anwendungsentwicklung Kollegen sagten mir, mit der Vorlage würde man mit Kanonen auf Spatzen schießen. Was sagen Sie dazu?

  11. Stefan Macke sagt:

    Hallo Frederic, das magst du auf den ersten Blick so empfinden, aber letztlich kommen dabei auch nur die (zumindest bei unserer IHK) üblichen 15 Seiten Fließtext raus. Ich kenne deine Vorgaben nicht, aber mit 1-2 Seiten ist es halt beim Abschlussprojekt nicht getan.

    Zur Bearbeitungszeit schau mal bitte hier: Ist die Projektdokumentation Teil der Bearbeitungszeit des IHK-Abschlussprojekts? TL;DR: Bei vielen IHKen gehört das „Ausfüllen“ der Projektdokumentation nicht zu den 70 Stunden Projektbearbeitungszeit.

  12. M.Tabari sagt:

    Hallo Herr Beck,
    ich habe meine Projektdokumentation gemäß der von Ihnen bereitgestellten Seitenstruktur vorbereitet. Allerdings habe ich festgestellt, dass die Vorlage, die Sie zur Verfügung gestellt haben, etwas anders ist. Zum Beispiel ist in Ihrem Dokument die Ist-Analyse unter der Analysephase kategorisiert, während sie auf der hier vorliegenden Seite unter der Projektdurchführung zu finden ist.
    Meine Frage ist, welche Struktur am effektivsten ist und mehr Punkte sammelt. Ich muss meine Projektdokumentation in der kommenden Woche im IHK-Portal hochladen.
    Vielen Dank für Ihre Rückmeldung.

  13. Stefan Macke sagt:

    Ich glaube, du verwechselst mich. Einen Herrn Beck gibt es hier nicht.

    Die optimale Struktur ist die, die deinen Projektablauf am ehrlichsten beschreibt. Meine Vorlage ist nur eine Vorlage. Du musst sie schon selbst mit Leben füllen.

  14. Nope sagt:

    Moin. Ich habe mir einige Dokumentationen angeschaut und mir ist aufgefallen, dass niemand den kompletten Quelltext in den Anhang schreibt. In der Doku habe ich die Datenbank, die wichtigsten Klassen für das Backend und die wichtigsten Komponenten für das Frontend erklärt. Wenn ich aber den kompletten Quelltext in den Anhang stecke sind das viele Dateien. Alleine eine Komponente besteht ja schon aus CSS, HTML und JavaScrip und dann kommen noch mehrere Apex Klassen. Wie soll man da vorgehen?

    Vielen Dank für die Mühe.

  15. Stefan Macke sagt:

    Du sollst deine Dokumentation mit allen sinnvollen/spannenden Artefakten deines Projekts füllen. Code ist nur eines (!) davon. Viele IHKen haben eine Begrenzung bei der Anzahl der Seiten im Anhang und daher muss eine Auswahl getroffen werden, was gezeigt werden soll. Seitenweise Code ist meist nicht sinnvoll, weil der Platz dann für andere wichtige Inhalte fehlt.

  16. Yalcin sagt:

    Hallo Stefan!
    Ich habe einer Frage zu der Wirtschaftlichkeitsanalyse -> Projektkosten. Ich weiß nicht, was mein Ausbilder verdient, der mir bei meinem Projekt geholfen hat. Kann ich seine Personalkosten schätzen? Er muss mir ja sein Stundenlohn nicht verraten, ich würde ihn aber auch ungerne danach fragen. Wie wird das seitens der IHK gehandhabt? Meine zuständige IHK ist übrigens Lübeck.

    LG Yaclin

  17. Stefan Macke sagt:

    Hallo Yalcin, es geht nicht darum, das exakte Gehalt deines Ausbilders zu erfahren. Das würde dir eh nicht helfen, da du den Stundensatz damit alleine eh nicht berechnen kannst. Frag doch einfach in eurer Personalabteilung oder bei deinem Chef, was du für einen ITler veranschlagen sollst.

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