L03 Projektdokumentation

Änderungen

• 2026-09-21 Initiale Version; als eigenständige Leistung aus der Begleitvorlesung herausgelöst.

• 2026-10-20 Umnummeriert (vorher L02)

• 2026-11-04 Burndown-Chart über verbleibende Arbeitszeit mit geplanten Story Points und Velocity; Kategorien für Pie-Chart an D02 angeglichen

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

  • Siehe Projektbeschreibung (maximal 1 Seite)

• 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 sie 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 Punkte sollten plausibel der Wahrheit entsprechen. Die Teams sind verantwortlich den TBs Einsicht in die Prozesse zu geben.

Bewertungsliste

Erstellt eine Liste/Tabelle an von euch geleisteter Arbeit im Entwicklungsprozess. Diese Punkte stellen 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öglichen Bewertungsliste

• Prozess

  • Anforderungen als Gitlab Issues

  • Teamkommunikation über Discord

  • JetBrains Code With Me

• 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 Burndown-Chart, der eure Projektarbeitszeit und eure Velocity visualisiert. Beispiel:

In eurem Burndown-Chart sind von links nach rechts (x-Achse) die Iterationen und von oben nach unten (y-Achse) die verbleibende Arbeitszeit des Teams in Prozent. Der Punkt ganz links oben (100 %) entspricht eurem gesamten Zeitbudget (siehe Arbeitsaufwand, bei 5 Personen also 1350 Stunden). Die Optimallinie verläuft linear nach rechts unten bis 0 % am Projektende. In der Linie für den tatsächlichen Verlauf tragt ihr ein, wie viel des Budgets am Ende der jeweiligen Iteration laut Zeiterfassung noch übrig ist.

Zusätzlich zeigt ihr pro Iteration die geplanten Story Points und eure Velocity (Summe der Story Points der tatsächlich abgeschlossenen Anforderungen), z.B. als Balken. So wird sichtbar, wie gut eure Planung aufgeht und wie sich eure Arbeitsgeschwindigkeit im Verhältnis zur investierten Zeit entwickelt.

Des Weiteren erwarten wir von euch einen Pie-Chart in dem ihr die Verteilung eurer Arbeitszeit auf die Kategorien eurer Zeiterfassung darstellt. Beispiel:

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 gut 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 Probleme, die aufgetreten sind (und nicht vorher schon beschrieben wurden)? Ist es klar geschrieben? Falls nein, dann keine Beanstandung.