Page History

...

• Eine allgemeine Einleitung für das Dokument. Worum geht es und wie ist das Dokument aufgebaut.
• Grundsätzlich sollte jeder Abschnitt kurz eingeleitet werden und jeden Kapitel sollte eine kurze Zusammenfassung bekommen.
• Quellen müssen angebenen werden, also z.B. nicht einfach Text von einer Web-Seite kopieren. Das kann u.U. als Plagiat ausgelegt werden...
• Eine Darstellung der ermittelten Anforderungen.
  • Dies umfasst mindestens die umgesetzten User-Stories (Sinnvoll: Die Akzeptanzkriterien für eine User-Story mit angeben.). Idealerweise werden die UserStories noch durch Anwendungsfälle unterstützt.
  • Ggf. eine Darstellung/Auflistung nicht umgesetzter User Stories. Die kann noch einmal zeigen, welche kreativen Ideen zeitlich nicht mehr umgesetzt wurden
  • Die Stories sollten möglichst gruppiert (z.B. nach Nutzerverwaltung, Hauptmenue/Lobby, etc.) werden.
• 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 (Lobby, Chat, Game, ...):
    • Allgemeine Beschreibung
    • Im Client ggf. Screenshots
    • Darstellung der Klassen und Zusammenhänge der Klasse. Hier gerne auch ausschnittsweise, um ein besseren Verständnis zu bekommen. Vollständiges Klassendiagramm des Moduls im Anhang
      • Zur Darstellung der Zusammenhänge ist es i.d.R. sehr sinnvoll, Klassendiagramme ohne Attribute und Methoden zu verwenden.
    • 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. Es sollte nicht einfach ein Diagramm an das nächste gehängt werden, sondern z.B. gesagt werden: „In dem Diagramm xy ist zu sehen, wie der grundsätzliche Ablauf eines Spielzugs ist. Dabei wird zunächst...“
      • Nicht immer ist offensichtlich, warum eine 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“.
      • Wenn man komplexere Algorithmen darstellen möchte, kann es besser sein, die Darstellung mit Pseudocode vorzunehmen.
    • Diagramme sollten an den Stellen im Text sein, an denen sie erläutert werden. Es muss vom Text aus auf die Diagramme verwiesen ("siehe Abb. X.Y") werden. Einfach alle im Anhang aufzulisten, macht keinen Sinn.
  • Bei Spiel: Regelabweichungen darstellen und begründen
  • (Java-)Quellcode im Text möglichst vermeiden. Pseudocode kann für die Beschreibung von komplexeren Algorithmen verwendet werden.
  • ACHTUNG! Die Konzepte bitte so darstellen, als wenn sie nicht iterativ entstanden wären. Also keine "Verteilung" des Konzeptes auf Sprints. Wichtig ist, was am Ende herausgekommen ist.
  • Die Konzepte des Servers sollten mehr Aufmerksamkeit bekommen, als die den Clients.
  • Das Spiel ist das wichtigste im SWP, es sollte also im Realisierungskapitel den größen Umfang bekommen.
• Darstellung der Tests
  • Nach welchem Vorgehen wurde getestet?
  • Welche Tests gibt es?
    • Hinweis: Hier nicht jeden einzelnen Unit-Test aufführen, das ist unnötige Arbeit!
  • 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. Aus Gründen der Bewertung ist es u.U. sinnvoll, Pull-Request mit beispielhaften Reviews in Git nicht zu löschen.
• 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 (es geht um die Durchführung der Veranstaltung als solches, d.h. z.B. was kann an der Veranstaltung als solches verbessert werden):
    • SWP Retrospektive: „Do More“, „Do Less“, „Keep Doing“, „Start Doing“, „Stop Doing“
• Anhang:
  • Ggf. vollständige Klassendiagramme (Ohne weitere Erläuterung)
  • Protokolle und andere im Laufe der Zeit entstandene Dokumente in speziellen Ordner hinterlegen. Nicht (mehr) in das Dokument mit aufnehmen, das ist nur unnötige Arbeit.
• Glossar mit Begriffen des Gegenstandes/Spiels
• Index  (Falls Dokument mit LaTeX erstellt, bei Confluence-Export nicht möglich/notwendig)

...