L02 Projektdokumentation
- Änderungen
2026-09-21 Initiale Version; als eigenständige Leistung aus der Begleitvorlesung herausgelöst.
Die Projektdokumentation ist ein schriftlicher Beleg, dass der Softwareentwicklungsprozess ordentlich durchgeführt wurde. Behauptungen in diesem Dokument werden durch die Teambegleitungen geprüft.
Das Dokument sollte sich in drei Kapitel unterteilen: Projektbeschreibung, Entwicklungsprozess, Fazit. Abweichungen sind möglich aber unüblich.
Den Hauptteil der Bewertung macht die Beschreibung des Entwicklungsprozesses. Die Projektbeschreibung und das Fazit gehen in den „Gesamteindruck“ des Dokuments ein. Gute Reflexion über das Projekt im Fazit kann andere schwächen in der Gesamtbewertung ausgleichen.
Abgabeformate
Abgaben erfolgen als PDF. Es ist kein Format vorgegeben, wählt etwas das für euer Team einfach zu erstellen ist. Achtet auf allgemeine Leserlichkeit. Seitenangaben rechnen sich um als 1 Seite entspricht 400-500 Worten (dies entspricht typischen Templates, weicht euer Template davon ab Zählt bitte die Wörter damit eure Abgabe nicht zu lang wird). Graphiken sind explizit erwünscht und zählen nicht zum Seitenlimit. Seitenlimits sind ein hartes Maximum. Kürzere Texte, die alles Wichtige enthalten, sind oft besser als das Maximum voll auszunutzen.
Projektbeschreibung (maximal 2 Seiten)
Dient dazu, um einen Überblick über das Projekt zu gewinnen, sodass die Projektdokumentation für die Projektorga verständlich ist ohne das Projekt zu kennen.
Aktualisierte Inhalte der Projektbeschreibung im Spezifikationsdokument
Vision, wenn nötig Domänenbeschreibung, Architekturdiagramm
Liste/Tabelle: Entwickelte Funktionen
Achtet auf Abgrenzung zur Ausgangssituation (falls vorhanden)
Anmerkung: Anzahl/Art der entwickelten Funktionen sind nicht für die Bewertung relevant, und dienen nur um die Zweckdienlichkeit der Qualitätssicherungsmaßnahmen einzuschätzen
Erklärung zur KI Nutzung (zählt nicht zum Seitenlimit)
Bewertungsschema für TBs: Fehlen Teile des Projektes oder sind falsch oder unübersichtlich dargestellt? Wenn nein, keine Beanstandung.
Entwicklungsprozess (maximal 4 Seiten)
Der Entwicklungsprozess ist der Hauptteil eurer Note. Nennt in der Bewertungsliste was ihr geleistet habt. Beschreibt im Fließtext interessante Details, und worauf ihr Stolz seid. Gebt Beispiele, fügt Screenshots ein, helft der Projektorga einen schnellen Überblick über das zu bekommen, was ihr in dem Semester getan habt.
Denkt auch daran einen überblick über euren Prozess zu geben:
Wie waren eure Iterationen strukturiert?
Was war regelmäßig, was eher unregelmäßig?
Wie habt ihr sichergestellt, dass Wissen über die Prozesse nicht verloren geht?
Gab es signifikante Ereignisse, die das Projekt gefährdet haben? Wie seid ihr damit umgegangen?
Bewertungsschema für TBs: Alle in der Bewertungsliste genannten sollte plausibel der Wahrheit entsprechen.
Bewertungsliste
Erstellt eine Liste/Tabelle an von euch geleisteter Arbeit im Entwicklungsprozess. Diese Punkte stellt die Grundlage eurer Bewertung dar. Achtet insbesondere darauf, dass ihr alles was ihr zu den Punkten Anforderungen? und Qualitätssicherungsmaßnahmen? erledigt habt auch in der Liste erwähnt. Eure Teambegleitungen Prüfen, dass ihr alle genannten Punkte durchgeführt habt.
Der Fließtext sollte die Punkte aus der Bewertungsliste aufgreifen, und gegebenenfalls erläutern.
Beispiel für einen Teil einer mögliche Bewertungsliste
Prozess
Anforderungen als Gitlab Issues
Teamkommunikation über Discord
Code Reviews immer vor Merge in den Main Branch
Checkliste vorhanden
Tests automatisch bei Push in Github Actions
Manuelle UI-Test Checkliste
getestet vor AG Meeting
Group Programming immer dienstagnachmittags
…
Arbeitszeit und Planung
Wir erwarten von euch einen Burn-Down-Chart der eure Planung und Schätzungen visualisiert. Beispiele:
In eurem Burndown-Chart sind von links nach rechts (x-Achse) die Iterationen und von oben nach unten (y-Achse) die verbleibenden Story Points (oder Stunden, falls ihr in konkreter Zeit geschätzt habt). Der Punkt ganz links oben zeigt die Gesamtsumme der Story Points aller eurer Anforderungen. Die Optimallinie verläuft dann linear nach rechts unten, bis in der letzten Iteration keine offenen Story Points mehr übrig sein sollten. In der Linie für die tatsächliche Bearbeitung tragt ihr immer ein, wie viele Story Points am Ende der jeweiligen Iteration noch übrig sind. Bei jedem Schritt nach rechts verringert sich die Höhe also um die Story Points, die in dieser Iteration abgeschlossen wurden.
Falls ihr nicht alle Anforderungen abgearbeitet habt, erreicht die Linie nie die 0. Dies kann durchaus normal sein, wenn ihr mehr Anforderungen aufgenommen habt, als ihr im Zeitrahmen bearbeiten konntet.
Desweiteren erwarten wir von euch einen Pie-Chart in dem ihr die Verteilung eurer Arbeitszeit in die verschiedenen Kategorien auflistet. Die Kategorien sind nicht fest vorgegeben. Sinnvolle Kategorien beinhalten: Entwicklung, Dokumentation, Testen, Code Reviews, Pair Programming.
Anforderungen?
Wie wurden Anforderungen gesammelt? (verwendete Software?)
Was war die Art und der Umfang der Anforderungen? Wie sieht eine typische Anforderung im Projekt aus (Beispiele, Screenshots)
Wie war der Prozess zwischen euch und dem AG um Anforderungen zu erstellen?
Wie gute waren eure Zeitschätzungen? Wenn nicht gut, woran lag es?
Konntet ihr mehrere Anforderungen pro Iteration erfüllen? Wenn nein warum nicht?
Konntet ihr nach den wünschen des AG priorisierte Anforderungen bearbeiten?
War das Anforderungsmanagement nützlich für euch? Warum, warum nicht?
Qualitätssicherungsmaßnahmen?
Tests
Was/wie wird getestet?
Erklärt beispielhaft einige relevante Tests
Woher wisst ihr, und wie stellt ihr sicher, dass ihr relevante Dinge testet?
Wie viel Arbeit macht euch die Testsuite?
Werden Fehler gefunden?
Wie wird auf Fehler reagiert?
Codereviews
Wie habt ihr die Reviews durchgeführt? Wie sah ein typisches Review aus?
Was habt ihr in den Reviews geprüft? Checkliste?
Waren die Codereviews den Aufwand wert? Warum, warum nicht?
Pair & Group Programming
Wie habt ihr das Pair Programming durchgeführt?
Welche Arten von Anforderungen wurden in Paaren bearbeitet?
Gab es weitere Qualitätssicherungsmaßnahmen?
Wieso wurden diese gewählt?
Waren sie hilfreich?
Fazit (maximal 1 Seite)
Wie war die Erfahrung für euch?
Reflektiert noch mal über die gesamte Zeit
Was habt ihr als positiv oder negativ wahrgenommen.
am Projekt
an der Projektarbeit
am Team
den Qualitätssicherungsmaßnahmen
Was hat euch geholfen, das Projekt zu entwickeln, was stand euch im Weg?
Was würdet ihr in der Zukunft wieder so oder anders machen?
Bewertungsschema für TBs: Fehlen im Fazit Problemen die Aufgetreten sind (und nicht vorher schon beschrieben wurden)? Ist es klar geschrieben? Falls nein, dann keine Beanstandung.