• Was soll umgesetzt werden? Wie sieht diese Welt aus?
    • Wer sind die Akteure?
    • Welche User-Stories gibt es?
    • Welche nicht funktionalen Anforderungen gibt es?
    • Welche Objekte gibt es: Objektmodell (als Klassendiagramm)
    • Wie interagieren die miteinander (wichtig!): Dynamisches Modell (tyischerweise als Sequenz-, Aktivitäts- oder Zustandsdiagramm)
      • Sequenzdiagramm: Wenn man sehr genau weiß, wie die Abläufe sind
      • Aktivitätsdiagramm und Zustandsdiagramm: Kann erstmal auf einer abstrakten Ebene passieren und später verfeinert werden
  • Dokumentation schrittweise (!) anpassen/erweitern
  • Abgabe:
    • Zwischenpräsentation (siehe dort)
    • zum Ende des Projektes finale Version
    • Dokumentation in einem extra Dokument (nicht auf Jira/Confluence verweisen), aber es kann ein Export aus Confluence erfolgen
  • Beachten: Dokumentationsanforderungen

Achtung!

  • Es ist keine gute Idee mit dem Dokumentieren bis zum Schluss zu warten (wink) Da sich Dinge aber im Laufe der Zeit noch ändern, sollte auch nicht zu viel Text schon vorher entstehen.
  • Diagramme können zwar durch Reengineering gewonnen werden, es ist aber zu Präsentationszwecken keine gute Idee. Dann lieber die Strukturen abstrakter darstellen (nicht jede Methode, jede Klasse und jedes Attribut ist relevant!)
  • Achtung! Wenn Sie Visual Paradigm verwenden, ändern Sie die Version nicht während des Projektes. I.d.R. sind die Modelle nicht beliebig austauschbar.
  • Für die Erstellung von UML-Diagrammen in Confluence kann auch PlantUML verwendet werden.
  • No labels