Dokumentationsanforderungen

Im Softwareprojekt muss am Ende zusätzlich zum eigentlichen Produkt ein Dokument abgegeben werden, welches im Wesentlichen die folgenden Aspekte enthalten sollte:

• Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
• Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden
• Eine Darstellung der ermittelten Anforderungen.
  • Dies umfasst mindestens die umgesetzten UserStories. Idealerweise werden die UserStories noch durch Anwendungsfälle unterstützt
  • Ggf. eine Darstellung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden
• Darstellung der Realisierung
  • Allgemeine/Übergreifende Konzepte, z.B. wie wurde MVP realisiert
    • Darstellung der Architektur und Aufteilung des Gesamtsystems in Module
  • Für jedes Modul:
    • Allgemeine Beschreibung
    • Im Client ggf. Screenshots
    • Darstellung der Klassen. Hier gerne auch ausschnittsweise um ein besseren Verständnis zu bekommen. Vollständiges Klassendiagramm des Moduls im Anhang
    • Ganz wichtig ist auch die Darstellung der Abläufe (Dynamikdiagramme).
      • Wenn man die Kommunikation zwischen Klassen darstellen möchte à Sequenzdiagramm
      • Wenn man allgemeine Abläufe hat à Aktivitätsdiagramme
      • Wenn man unterschiedliche Zustände durchläuft à Zustandsdiagramm
      • Diagramme müssen erläutert werden. Ein Diagramm ohne Beschreibung ist faktisch nicht vorhanden. Es muss nicht alles im Detail erklärt werden, aber auf spezielle Besonderheiten oder die Verwendung von Pattern hingewiesen werden.
      • Nicht immer ist offensichtlich, warum ein Lösung gewählt wurde. In diesem Fall sollten (Entwurfs-)Entscheidungen begründet/motiviert werden. Es ist grundsätzlich eine gute Idee, Dinge nicht nur „mitzuteilen“, sondern zu „erklären“.
  • Bei Spiel: Regelabweichungen darstellen und begründen
• Darstellung der Tests
  • Nach welchem Vorgehen wurde getestet?
  • Welche Tests gibt es?
  • Wie sieht die Testabdeckung aus?
  • Was wurde nicht automatisiert getestet und wie wurde sichergestellt, dass die Funktionalität trotzdem korrekt ist?
  • Beschreibung des (mindestens einmal) durchgeführten gruppenweiten Codereviews
• Darstellung des durchgeführten Projektmanagements
  • Rollen
  • Arbeitsweise
  • Meilensteine
  • Rückblick über die Sprints/ Projekttagebuch
  • Verwendete Frameworks, Bibliotheken und Tools
• Ausblick: Was könnte man noch machen? Hier auf eine sinnvolle Reihenfolge achten
• Fazit:
  • Rückblick auf das vergangene Jahr.
  • Was hat man gelernt?
  • Was hat gut funktioniert, was weniger gut?
  • Feedback zum Software Projekt allgemein:
    • SWP Retrospektive: „Do More“, „Do Less“, „Keep Doing“, „Start Doing“, „Stop Doing“
• Anhang:
  • Ggf. vollständige Klassendiagramme (Ohne weitere Erläuterung)
  • Protokolle
  • Andere im Laufe der Zeit entstandene Dokumente
• Glossar mit Begriffen des Gegenstandes/Spiels (nicht z.B. was eine Klasse oder ein Interface ist)
• Index  

Zum Produkt selber noch notwendig:

• Eine Spielanleitung: Über die Regeln des Spiels hinausgehende Beschreibung, wie die Bedienung erfolgt
•  Wie erfolgt die Installation und Konfiguration?