3. Vorgehensmethoden/Prozessmodelle Vorgehensmethode/Prozessmodell: Ablauforganisation des Projektes für eine effektive und zielgerichtete Softwareentwicklung Wasserfallmodell Spiralmodell Agiles Vorgehen extreme Programming Unified Process best practices
3.1.1 Wasserfallmodell (Royce, 1970) Zielerforschung Validierung Erhebungsbericht Analyse Design Validierung Validierung Lastenheft, Auftrag Pflichtenheft Implementierung Debuggen Testen Verifikation,Validierung Quellcode, Dokumentation Lieferversion Einführung Inbetriebnahme, Abnahme Endprodukt Betrieb Wartung Betriebsversion
3.1.1 Wasserfallmodell (Royce, 1970) Einteilung in Phasen mit Feedback-Zyklen Dokumenten-getriebenes Vorgehen Initiale Prototyp-Entwicklung im Rahmen des 'software life cycles' parallel zu Anforderungsanalyse/Design build it twice -Ansatz Wurde in 80er Jahren zum Standard in Industrie und Behörden
3.1.1 Wasserfallmodell (Royce, 1970) Warum das Wasserfallmodell falsch ist... Es nimmt an, dass: ein Projekt nur einmal die Phasen durchläuft (Architektur ist exzellent gewählt, Design ist stimmig, Fehler nur in der Realisierung). das Gesamtsystem aus gut testeten Komponenten in einem Zug aufgebaut werden kann. die Anforderungen am Anfang vollständig festgelegt werden können.
3.1.2 Spiralmodell (Boehm 1988) Organisation, Zieladaptierung Risikoanalyse Risikoanalyse Planung Vorgehensmethode Validierung Validierung Risikoanalyse Evolutionärer 2. Prototyp Prototyp 1. Prototyp 3. Prototyp Zielerforschung Analyse Implementierung Validierung Design Testen Überprüfung Betrieb Einführung Durchführung
3.1.2 Spiralmodell (Boehm 1988) Risiko-getriebener Prozess (iteratives Vorgehen) (anstatt Dokumenten-getrieben oder Code-getrieben) Software-Prozessmodell: Was soll als nächstes geschehen? Wie lange soll die nächste Phase dauern? Typische Abfolge von Schritten in jedem Zyklus (Ziele, Risiken, Durchführung, Validierung) Zyklen sind typischer Weise zwischen 6 Monaten und 2 Jahren Bettet andere Vorgehensmodelle ein.
3.1.3 Weitere Prozessmodelle Wasserfall-Modell: Dokumenten-getrieben Spiral-Modell: Risiko-getrieben Code-and-fix: Code-getrieben Evolutionäre Entwicklung: Funktions-getrieben Explorativ: System wird ständig erweitert Prototypen: Systeme werden neu entwickelt wiederverwendbare Komponenten: Tool-getrieben Unified Process: Architektur-getrieben...
3.2 Agile Softwareentwicklung Ziel: bessere Balancierung von Code-/Funktion-/Architektur-getriebenem Vorgehen Wie vermeidet man... Über-Analyse ( analysis paralysis )? hohe Kosten für späte Änderungen? Bürokratisierung des Entwicklungsprozesses? zu hohen Dokumentation-Overhead Zeitverzug von Projekten?
3.2 Agile Softwareentwicklung
3.2 Agile Softwareentwicklung Agil = Flexibilisierung / Verschlankung Anfänge 1990er Jahre 1997 C3-Projekt (Chrysler) 1999: Kent Beck extreme Programming explained Ab 2000 weitere agile Methoden XP, SCRUM, ASD, Crystal,... 2005: Untersuchung von Forrester Research Nordamerika u. Europa: 14% aller Projekte.
3.2 Agile SE: das C3-Projekt Chrysler Comprehensive Companion (C3) Gehaltsabrechnung für 86.000 Mitarbeiter Vorher 4 getrennte Systeme (4 Gruppen) hourly system (60.000 Mitarbeiter, pro Woche) salary system (16.000 Mitarbeiter, pro Woche) executive system (10.000 Mitarbeiter, pro Monat) incentive compansation system (1.500 pro Monat) 2 Verschiedene Abteilungen zuständig Ersten 3 Systeme ca. 20 Jahre alt [C3-Team, Chysler goes to 'Extreme', Distributed Computing, Oct. 1998, pp. 24-28]
3.2 Agile SE: das C3-Projekt Ziel des neuen Systems: ein einheitliches System für die ersten 3 Fälle (kein passendes kommerzielles System erhältlich) Vereinfachter Transfer zwischen den Systemen Vereinfachte Eingabe der Daten Keine Dokumentation mehr auf Papier/Microfiche Mehr automatisierte Abläufe Bessere Unterstützung von Entscheidungsprozessen Vereinfachte externe Inferfaces Erweiterbarkeit/Verbesserung externer Interfaces
3.2 Agile SE: das C3-Projekt Anfang 1990er: Entscheidung über neues System Jan. 1995: Start des C3-Projektes 1996: Projekt gescheitert (nach Wasserfallmodell), Neustart (Kent Beck, extreme programming). Mai 1997: C3-System geht an Start mit 10.000 Mitarbeitern ( executive system ). Okt. 1998: 16.000 Mitarbeiter ( salary system ) sollen zusätzlich über C3-System bezahlt werden. Mitte 1999: Plan für weitere 60.000 Mitarbeiter DaimlerChrysler stoppte das Projekt Feb. 2000.
3.2 Agile SE: das C3-Projekt Bewertung des Projektes Erstes Projekt das agile Methoden gesammelt umsetzt Schnelle Anfangserfolge in ersten 1-2 Jahren Zeigt die Anwendbarkeit von XP Erfolg wird unterschiedlich bewertet (DaimlerChrysler nahm danach erstmal Abstand von XP-Methoden) C3-Team bestand aus 20 Mitarbeitern (darunter Kent Beck, Martin Fowler, u.a.)
3.2 Agile SE: Minimieren von Risiken Risiken in der Softwareentwicklung Zeitplan wird nicht eingehalten, Projekt wird eingestellt, System ist nicht anpassbar, System ist fehlerhaft, Anforderungen wurden verfehlt, Anforderungen ändern sich, Implementierte Feature sind nutzlos, Personalwechsel während der Projektlaufzeit.
3.2 Agile SE: Minimierung von Risiken Risiken und Prozessvariablen Kosten: wenig skalierbar für ein Projekt Zeit meistens vom Auftraggeber fest vorgegeben Qualität Hohe Qualität spart eher Zeit Umfang am ehesten skalierbare Variable
3.2 Agile SE: Anforderungsänderungen Klassische Sicht: Steigt exponentiell mit zunehmendem Fortschritt des Projektes. Agile Sicht: Kosten steigen mit Projektfortschritt nur wenig an. -> Einfaches Design, -> automatisierte Tests, -> genügende Praxis bei Änderungen.
3.3 extreme Programming (Beck 1999) Aus dem Tagebuch eines Programmierers: Stand-up meeting Aufgaben-Karte auswählen (höchste Priorität) Team-Partner suchen Kurzes Review des letzten Tages (im 2er-Team) Identifizieren der Testfälle Design des neuen Testfalls (Wiederverwendung) Refactoring weiterer Testfälle als Aufgabe notieren Implementierung des Testfalls (wenige Minuten)
3.3 extreme Programming (Beck 1999) Tagebuch (Fortsetzung): Beginn der Implementierung der Aufgabe (wer die klarste Idee hat... kann wechseln) Während der Implementierung, Identifikation und Implementierung weiterer Testfälle. Refactoring falls Aufgabe einfacher implementiert werden kann. Durchlauf der Testfälle, optionales Debugging Offene Aufgabenkarten abarbeiten
3.3 extreme Programming (Beck 1999) Tagebuch (Fortsetzung): Letztes Release laden. Laden der implementierten Veränderungen Durchlauf sämtlicher Test-Fälle Optionales Debugging Durchlauf sämtlicher Test-Fälle Release des geänderten Codes.
3.3 extreme Programming (Beck 1999) Eckdaten des XP-Entwicklungszyklus: Kleine Programmier-Einheiten definieren Programmieren in Paaren Test-getrieben: Erst testen, dann coden Jeder analysiert, designt, implementiert, testet Integration nach jedem Entwicklungsschritt
3.3 extreme Programming (Beck 1999) XP als Wertegemeinschaft (4 Werte): Kommunikation: Atmosphäre schaffen die Kommunikation fördert Einfachheit Nicht an morgen denken! Probleme heute lösen! Feedback Don't ask me, ask the system (Testfälle) Feedback auf verschiedenen Zeitskalen Mut Auch größere Designänderungen durchführen
3.3 extreme Programming (Beck 1999) embrace change Prinzipien: Sofortiges Feedback (steilere Lernkurve) Einfachheit (kein design for reuse ) Inkrementell (kleine Schritte machen) Änderung (möglichst viele Optionen offen halten) Qualität (Notwendig zur eigenen Motivation)
3.3 extreme Programming (Beck 1999) Weitere Prinzipien: Lernen lehren Geringe Startinvestition Spiele um zu gewinnen Konkrete Experimente Offene Kommunikation Nicht gegen Instinkte arbeiten Verantwortung akzeptieren Lokales Adaptieren Nur leichtes Gepäck Ehrliche Messung des Fortschritts
3.3 extreme Programming (Beck 1999) Aktivitäten Coden: Ziel, Mittel zur Kommunikation, Lernen Testen: Unit tests (Programmierer) Funtionale Tests (Kunde) Zuhören: Aktives Zuhören (Feedback an Kunden) Designen: Erlaubt das Erweitern des Systems
3.3 extreme Programming (Beck 1999) Praktiken: The Planning Game Small releases Metaphor Simple Design Testing Refactoring Pair programming Collective ownership Continuous integration 40-hour week On-site customer Coding standards
3.3 extreme Programming (Beck 1999) Lifecycle eines (idealen) XP Projektes: Explorieren (1-2 Wochen) Sammlung von 'story cards' Austesten von Technologien und Systemarchitekturen Planen
3.3 extreme Programming: Kritik Kritik und offene Fragen an XP Projekte, die einen festen Umfang, festen Preis und festen Zeitrahmen haben? fixierten externe Interfaces? feste nichtfunktionalen Anforderungen (Sicherheit, Performanz)? Entwicklungsteams an verschiedenen Orten? Integration von off-the-shelf Komponenten? Eignung für große Projekte (>> 10)?