3. Vorgehensmethoden/Prozessmodelle

Größe: px

Ab Seite anzeigen:

Download "3. Vorgehensmethoden/Prozessmodelle"

Edmund Küchler
vor 8 Jahren
Abrufe

1 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

Projektes für eine effektive und zielgerichtete

2 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

Implementierung Debuggen Testen Verifikation,Validierung Quellcode, Dokumentation

3 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

Prototyp-Entwicklung im Rahmen des 'software life cycles' parallel zu

4 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.

gewählt, Design ist stimmig, Fehler nur in der Realisierung).

5 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

Evolutionärer 2. Prototyp Prototyp 1. Prototyp 3.

6 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.

Wie lange soll die nächste Phase dauern?

7 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...

Funktions-getrieben Explorativ: System wird ständig erweitert Prototypen: Systeme

8 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?

.. Über-Analyse ( analysis paralysis )? hohe Kosten für späte Änderungen?

9 3.2 Agile Softwareentwicklung

10 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, : Untersuchung von Forrester Research Nordamerika u. Europa: 14% aller Projekte.

Programming explained Ab 2000 weitere agile Methoden XP, SCRUM, ASD,

11 3.2 Agile SE: das C3-Projekt Chrysler Comprehensive Companion (C3) Gehaltsabrechnung für Mitarbeiter Vorher 4 getrennte Systeme (4 Gruppen) hourly system ( Mitarbeiter, pro Woche) salary system ( Mitarbeiter, pro Woche) executive system ( 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 ]

000 Mitarbeiter, pro Woche) executive system (10.000 Mitarbeiter, pro Monat) incentive compansation system (1.

12 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

Eingabe der Daten Keine Dokumentation mehr auf Papier/Microfiche Mehr automatisierte Abläufe Bessere

13 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 Mitarbeitern ( executive system ). Okt. 1998: Mitarbeiter ( salary system ) sollen zusätzlich über C3-System bezahlt werden. Mitte 1999: Plan für weitere Mitarbeiter DaimlerChrysler stoppte das Projekt Feb

programming). Mai 1997: C3-System geht an Start mit 10.000 Mitarbeitern ( executive system ). Okt. 1998: 16.

14 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.)

von XP Erfolg wird unterschiedlich bewertet (DaimlerChrysler nahm danach erstmal Abstand

15 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.

System ist fehlerhaft, Anforderungen wurden verfehlt, Anforderungen ändern sich,

16 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

Zeit meistens vom Auftraggeber fest vorgegeben Qualität

17 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.

Agile Sicht: Kosten steigen mit Projektfortschritt nur wenig an.

18 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)

Tages (im 2er-Team) Identifizieren der Testfälle Design des neuen Testfalls

19 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

.. kann wechseln) Während der Implementierung, Identifikation und Implementierung weiterer

20 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.

21 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

22 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

23 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)

24 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

25 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

26 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

27 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

28 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)?

Ähnliche Dokumente

Agile Softwareprozess-Modelle

Agile Softwareprozess-Modelle Steffen Pingel Regionale Fachgruppe IT-Projektmanagement 2003-07-03 Beweglich, Lebhaft, Wendig Was bedeutet Agil? Andere Bezeichnung: Leichtgewichtiger Prozess Manifesto for