SoED

(1) Dynamische Perspektive: Zeigt Phasen im Laufe der Zeit

(2) Statische Perspektive: Zeigt Prozessaktivitäten

(3) Best Practice Perspektive: Schlägt bewährte Praktiken vor

Pro

• Kosten sind vorsehbar (Voraussetzung ist gute Planung)
• Einfach zu verwenden
• Kontrolle über die Fertigstellungszeit

Contra

• Funktioniert nur gut wenn sich Requirements nicht ändern. Wenn sie sich ändern ist es nicht empfehlenswert
• Fortschritt in den einzelnen Phasen schwer zu erkennen
• Falsche Zeiteinschätzung für die einzelnen Phasen kann grosse Zeitverschiebungen verursachen

Pro

• Zwischenversionen können Kunden gezeigt werden und wenn gefordert, angepasst werden.
• Kostengünstigere Anpassung von Anforderungen
• Debug und Testen ist in kleinen Iterationen viel einfacher

Contra

• Kann sein dass Kunde jeden Tag etwas anderes will. So kommt man nie zu einer finalen Version
• Nicht geeignet wenn Ergebnis schon klar definiert ist. Da ist Waterfall geeigneter.
• Der Projektstatus ist nicht klar ersichtlich

1. Inception (Anwendungsfall für das system definieren (eine analyse))
2. Elaboration (Verständniss der Business umgebung und system architektur)
3. Construction (System designen, programmieren, testen)
4. Transition (System in die Umgebung einbinden)

• Requirements im Dokument festhalten
• Wiederverwendbare Komponenten verwenden
• UML verwenden um Software abzubilden
• Kontrolle über Änderung der Software
• Softwarequalität sicherstellen

• Kunden involvieren (Im Entwicklungsprozess miteinbeziehen)
• Schrittweise Lieferung
• Leute nicht Prozesse (Mitglieder sollten frei sein zu programmieren)
• Veränderungen einbeziehen (Vorbereitet sein auf Systemänderungen)
• Einfachheit beibehalten (Komplexität verhindern im System)

Leute nicht Prozesse: Wenn „Cracks“ freie Hand haben heisst, das noch lange nicht das etwas Gutes dabei herauskommt.

User stories: Kunde wird in Entwicklung eingebunden. User stories oder scenarios als user requirements

Break down: Diese werden dann vom Entwicklerteam zu kleinen Tasks gebrochen

Plan release: Kunde wählt die zu umsetzende Story für den nächsten release

Develop: Keine Requiremets Festhaltung sondern nur Storyboard Implementierung

Evaluate: Feedback vom Kunden