2. Projektphasen und Vorgehensmodelle

Transkript

1 2. Projektphasen und Vorgehensmodelle Compendio: Kapitel 2, Seiten SWE-IPM 1

2 Inhalt Definition, Allgemeine Projektphasen Arbeiten nach Checkliste Anordnung & Vergleich der Phasen bei agiler / klassischer Vorgehensweise Das magische Dreieck: Produktqualität vs. Projektqualität Fixed / Estameted bei Plan-driven & Value-driven Planung, Meilensteine Sequentielle Vorgehensmodelle: Wasserfall, V-Modell und Varianten, V-Modell XT und Varianten, Hermes 2003, Hermes 5 Inkrementelle, iterative Vorgehensmodelle: Spiralmodell, RUP Adaptive, evolutionäre Vorgehensweisen: Agile, XP, Scrum SWE-IPM 2

3 Vorgehensmodelle Definitionen Ein Vorgehensmodell/Prozessmodell ist ein Mix von aufeinander abgestimmten Prozessen, Methoden, Techniken und Werkzeugen (Quelle: Compendio) Ein Plan, der den Entwicklungsprozess in überschaubare, zeitlich und inhaltlich begrenze Phasen unterteilt (Quellle: Wikipedia) Grundsätzliche Unterscheidung der Vorgehensmodelle in Sequentielle Vorgehensmodelle Iterative, Inkrementelle Vorgehensmodelle Empirische, adaptive Vorgehensmodelle SWE-IPM 3

4 Allgemeine Projektphasen und Systementwicklung Compendio 2.1 Von der Idee zum Projekt SWE-IPM 4

5 Tätigkeiten in den allgemeinen Projektphasen Compendio SWE-IPM 5

6 Quelle: startup euregio Management GmbH Arbeiten nach Checkliste Quelle: startup euregio Management GmbH SWE-IPM 6

7 Quelle: Takeuchi / Nonaka, 1986 Klassische vs. Agile Projektvorgehensweise Anordnung der Phasen Typ A: Sequentielle Phasen (gesehen bei NASA) Typ B: Rugby-Ansatz, überlappend an den Phasenenden (gesehen bei Fuji-Xerox) Rugby-Ansatz: Die Phasenanordung sieht ähnlich aus wie die Scrum-Aufstellung in Rugby, Teams sind autonom, agieren agil und selbstorganisiert Typ C: Sashimi-Ansatz, überlappend über alle Phasen (gesehen bei Honda und Canon) Sashimi: Scheiben von rohem Fisch, auf einer Platte angerichtet SWE-IPM 7

8 Klassische vs. Agile Projektvorgehensweise Vergleich der Phasen Initialisieren Planen Durchführen (1) Durchführen (n) Abschliessen SWE-IPM 8

9 Quelle: O.Bürgi Das magische Dreieck des Projekterfolgs Lösungsumfang - - Kosten Termine SWE-IPM 9

10 Quelle: O.Bürgi Produktqualität vs. Projektqualität - Produkt- Qualität Kosten - Termine Lösungsumfang Projekt- Qualität SWE-IPM 10

11 Klassisches vs. Agiles Projektmanagement Quelle: Agiles IT-Management in großen Unternehmen, ISBN Lösungs -umfang Kosten Termine Kosten Termine Lösungs -umfang SWE-IPM 11

12 Quelle: startup euregio Management GmbH Planung im Projektmanagement Prozess «Plans are nothing, Planning is everything!» SWE-IPM 12

13 Quelle: H.P. Korn Planung im Projektmanagement Prozess Ein Projekt beginnt mit der ersten Version einer übergeordneten Rahmenplanung als Basis für die weiteren Detailplanungen und Realisierungsarbeiten. Die Projektplanung auf allen Detaillierungsstufen ist ein kontinuierlicher Prozess, wobei die Planungsintensität in der Initialisierung und Rahmenplanung am höchsten ist. Danach ist weiterhin eine laufende bzw. rollende, begleitende Planung und Anpassung der Rahmenplanung erforderlich. Stichwort: «Plans are nothing, Planning is everything!» Die im Tagesgeschäft üblichen Vorgehensweisen eignen sich daher kaum für die Projektarbeit SWE-IPM 13

14 Definition Meilenstein Compendio 2.5 Meilensteine kennzeichnen das Ende einer Abfolge von Arbeitspaketen, die notwendig sind um die nächste Phase zu beginnen. Definition nach DIN 69901: «Ein Meilenstein ist ein Ereignis von besonderer Bedeutung» SWE-IPM 14

15 Quelle: Vortrag von Winston W. Royce 1970 Sequentielle Prozessmodelle Das Wasserfallmodell Winston W. Royce ( ) beschäftigte sich am Lockheed Software Technology Center mit der Planung, Steuerung und Analyse von Raumfahrtmissionen 1970 beschrieb er ein inkrementelles(!) Prozessmodell, welches eine Simulation des Endprodukts beinhaltet und den Kunden einbezieht. In der Herleitung beschrieb er (als erster!) das Wasserfallmodell und erklärte, wieso dieses nicht funktionieren könne. Er machte konkrete Verbesserungsvorschläge, welche viele Gemeinsamkeiten mit den heutigen iterativen und agilen Prozessmodellen haben SWE-IPM 15

16 Quelle: Vortrag von Winston W. Royce 1970 MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS (I) Grundsätzlich gibt es nur zwei elementare Schritte in der Entwicklung von Software: Analyse Codierung «This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it» Diese werden typischerweise beim Programmieren für den internen Gebrauch befolgt( ) und für diese Schritte ist der Kunde auch bereit zu bezahlen, weil sie echt kreativ sind SWE-IPM 16

17 Quelle: Vortrag von Winston W. Royce 1970 MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS (II) Ansätze für Grosssysteme: Trennen von Analyse und Codierung durch eine Design Phase Vor der Analyse werden die Anforderungen erhoben «Hopefully, the iterative interaction between the various phases is confined to successive steps.» Nach dem Codieren folgt eine Testphase SWE-IPM 17

18 Quelle: Vortrag von Winston W. Royce 1970 MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS (III) «Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.» «This concept is risky and invites failure. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. «In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.» SWE-IPM 18

19 Quelle: Vortrag von Winston W. Royce 1970 Empfehlungen von Royce für die SW-Entwicklung «The first result provides an early simulation of the final product» Complete program design before analysis(!) and coding begins Documentation must be current and complete Do the job twice if possible. Testing must be planned, controlled and monitored Involve the customer SWE-IPM 19

20 Quelle: Vortrag von Winston W. Royce 1970 Fazit Vieles was wir heute als neue Erkenntnisse betrachten, schlug bereits Royce vor: Einen vorausgehenden Programmdesign vor Beginn der Analyse (vergl. Architekturvision in Scrum) Plane von Anfang an zwei Iterationen ein, wobei erst die zweite Version beim Kunden produktiv eingesetzt wird. Die erste Iteration (1/3 der gesamten Entwicklungszeit!) wird zur Simulation verwendet. Die Schlüsselhypothesen werden überprüft und der Programm Design allenfalls angepasst. (vergl. Elaboration Phase in RUP) Der Kunde wird kontinuierlich und tiefgehend in den SW- Entwicklungsprozess einbezogen (vergl. Kunde vor Ort in Scrum) SWE-IPM 20

21 Compendio 2.8 Sequentielle Prozessmodelle V-Modell 97 Das V-Modell basiert auf dem Wasserfall und wurde 1979 von Barry W. Boehm vorgeschlagen. Seit 1997 nicht mehr weiterentwickelt. Nachfolger ist das V-Modell XT SWE-IPM 21

22 V-Modell bei Postfinance Zielbild IT-Innovationsprozess Quelle: Postfinace Programm- Leiter Programm PL - Anforderungen verwalten Requirements Management & Testing - Partner-Abnahmetest - Regressionstest PL Marktangebots/Unternehmenssicht PLI Business Analyst Testmanager Testdesigner Testautomatisierer Requirements Engineering & Testing - Stakeholder analysieren - Anforderungskatalog und Lastenheft erstellen - Testkonzept, Testplan, Testdesign erstellen Vorhabenssicht Lastenheft - Systemtest - Integrationstest - ORT Business Analyst Tester Testmanager Techn. Analyst / AV SW-Entwickler Testmanager Testdesigner Testautomatisierer Applikationssicht Pflichtenheft Software Delivery - Design erstellen - Pflichtenheft erstellen - SW entwickeln/integrieren - Testkonzept, Testplan, Testdesign erstellen - Komponententest - ORT Tester Testmanager SWE-IPM 22

23 V-Modell bei Postfinance Funktionsweise Quelle: Postfinace Die gesamte IT-Innovation lehnt sich an das V-Modell (nicht nur Testing) Die 3 Prozesse richten sich horizontal auf drei Ebenen über das V aus, statt entlang dem V. Nur so sind die Vorteile vom V-Modells auch in den Prozessen spürbar Es gibt Hauptdisziplinen, die gemeinsam in den 3 Prozessen arbeiten: Requirements Engineering, Entwicklung und Testing Agilität wird innerhalb der einzelnen der IT-Prozesse gefördert und genutzt SWE-IPM 23

24 V-Modell bei Postfinance Vorteile Quelle: Postfinace Klare Unterscheidung zwischen Vorhabens- und Applikationssicht Jeder Prozess beinhaltet die Qualitätssicherung für den Prozess und das Lieferergebnis Klare Verantwortungen der Lieferergebnisse Klare Unterscheidung zwischen Disziplinen und Prozessen Prozessübergang ermöglicht verschiedene Sourcingmodelle v.a. auch Outsourcing Agile Ansätze können einfacher eingesetzt werden, durch den Einbau der QA in den Prozess (z.b. Testdriven Development) SWE-IPM 24

25 Quele: Bundesrepublik Deutschland 2004 Sequentielle Prozessmodelle V-Modell XT (extreme Tailoring) SWE-IPM 25

26 V-Modell XT Teil Auftraggeber SWE-IPM 26

27 Teil Auftragnehmer SWE-IPM 27

28 Agilität im V-Modell XT? Quelle: Technische Universität Kaiserslautern Die Anzahl Iterationen / Projektstufen wird projektspezifisch festgelegt n SWE-IPM 28

29 Quelle: Ingo Zank, IKMT Agilität im V-Modell XT? SWE-IPM 29

30 Agilität im V-Modell XT? Quelle: msg systems SWE-IPM 30

31 Sequentielle Prozessmodelle Hermes 2003 Hermes 2003 wird nicht mehr weiterentwickelt Nachfolger ist Hermes SWE-IPM 31

32 Hermes 5 Der Nachfolger von Hermes 2003 Quelle: Informatiksteuerungsorgan des Bundes ISB Zeitlicher Ablauf Offiziell veröffentlicht am Verschlankt, verjüngt, abgespeckt 3 Sichten (Zeitlicher Ablauf, Partner, Hierarchie Szenarien, Module Ergebnisse, Aufgaben, Rollen Partner Hierarchie Intro in die Methode Hermes 5: SWE-IPM 32

33 Hermes 5 Zeitlicher Ablauf Quelle: Informatiksteuerungsorgan des Bundes Das Phasenmodell gliedert den Lebenszyklus des Projekts und schafft die Voraussetzung für das gemeinsame Verständnis der Projektbeteiligten betreffend den Projektablauf Die Sicht des zeitlichen Ablaufs zeigt welche Aufgaben und Ergebnisse in welcher Phase bearbeitet werden welche Meilensteine in welcher Phase liegen und welche Entscheide dabei getroffen werden SWE-IPM 33

34 Hermes 5 Sicht der Partner 3 Projektpartner: Anwender, Ersteller oder Betreiber Eine Rolle ist einem oder mehreren Projektpartnern zugeordnet. Der Rolleninhaber vertritt die Sicht seiner Organisation im Projekt. Aufgrund der Rollenzuteilung weiss er für welche Ergebnisse er verantwortlich ist und wo er mitarbeitet SWE-IPM 34

35 Hermes 5 Sicht der Hierarchieebenen Die Hierarchieebenen regeln die Verantwortung in einem Projekt. Sie unterstützen die Einhaltung der Governance. Die Sicht der Hierarchieebenen zeigt: welche Entscheidungsaufgaben auf welcher Ebene angesiedelt sind welche Ergebnisse auf welcher Ebene anfallen welcher Ebene die Rollen zugeordnet sind SWE-IPM 35

36 Hermes 5 Szenarien 8 Standardszenarien (2 davon agil). Szenarien können angepasst und weitere hinzugefügt werden SWE-IPM 36

37 Module Hermes 5 Module Jedes Szenario ist im Baukastensystem zusammengesetzt aus einzelnen, wiederverwendbaren Standardmodulen. 13 Standardmodule, weitere Module können ergänzt werden Szenario Produkt/Dienstleistung SWE-IPM 37

38 Hermes 5 Entscheidungsprozess In der Projektdurchführung müssen Entscheide getroffen werden. Die Entscheide sind in den Modulen als Aufgaben definiert. Am Ende einer Entscheidungsaufgabe steht ein Meilenstein SWE-IPM 38

39 Hermes 5 Szenarioleitfaden (Beispiel) Ausschnitt aus Leitfaden zu Szenario: «IT-Individualentwicklung_Agil» Modul: «Entwicklung Agil» Ergebnis: «Projektmanagementplan» Module können individuell hinzugefügt ergänzt werden! SWE-IPM 39

40 Hermes 5 Modulbeschreibung (Beispiel) Modul: «Entwicklung Agil» Die Entwicklung agil mit SCRUM steuern Dieses Modul ergänzt das Modul Projektführung Phase: «Konzept» Aufgabe: «Entscheid zu Scrum treffen» SWE-IPM 40

41 Hermes 5 Aufgabenbeschreibung (Beispiel) Aufgabe: «Entscheid zu SCRUM treffen» Der Entscheid schafft die Voraussetzung für die agile Entwicklung mit der Methode SCRUM. Die nötigen Entscheidgrundlagen werden erarbeitet. Grundidee: Die agile Entwicklung mit SCRUM hat Auswirkungen auf Anwender, Ersteller und Betreiber. Deshalb wird der Entscheid mit Einbezug der Betroffenen bewusst gefällt. Verantwortliche Rolle für Aufgabe Ergebnis: «Checkliste» Verantwortliche Rolle für Ergebnis SWE-IPM 41

42 Hermes 5 Ergebnisbeschreibung (Beispiel) Ergebnis: «Checkliste» Checklisten unterstützen bei der systematischen Durchführung von Prüfungen. Entscheidungsaufgaben in HERMES werden mit Checklisten unterstützt. Vor der Prüfung werden die Standardchecklisten mit projektspezifischen Kriterien ergänzt. Inhalt: Standard-Prüfpunkte, projektspezifische Prüfpunkte, Ergebnis der Prüfung SWE-IPM 42

43 Hermes 5 Dokumenten-Vorlagen (Beispiel) Auswahl an Vorlagen für das Szenario «Dienstleistung / Produkt agil» abnahmeprotokoll.docx aenderungsantrag.docx aenderungsstatusliste.docx Arbeitsauftrag.docx checklisten.docx einfuehrungskonzept.docx liste_der_stakeholder.docx pendenzenliste.xlsx Phasenbericht.docx produktkonzept.docx Projektauftrag.docx projektentscheide.docx projekterfahrungen.docx projektinitialisierungsauftrag.docx Projektmanagementplan.docx (Hermes 2003: Projekthandbuch.docx) projektschlussbeurteilung.docx projektstatusbericht.docx protokoll.docx pruefprotokoll.xlsx Testkonzept.docx Testprotokoll.docx SWE-IPM 43

44 Hermes 5 Kombinierbarkeit mit Scrum HERMES und SCRUM bestehen aus ähnlichen Methodenelementen, sodass eine Integration des SCRUM- Frameworks in der HERMES-Methode einfach möglich ist. HERMES bietet zwei Standardszenarien an, welche die agile Steuerung der Entwicklung mit SCRUM beinhalten: IT-Individualanwendung agil Dienstleistung/Produkt agil Im Gegensatz zu HERMES verwendet SCRUM kein Phasenmodell, sondern basiert auf Iterationen (Sprints) SWE-IPM 44

45 Vergleich Hermes 5 - Scrum Schwerpunkt HERMES SCRUM Projekt Lebenszyklus Ergebnisse, Aufgaben, Rollen Hierarchie-Ebenen Partner Ganzer Lebenszyklus des Projekts. (Projektinitialisierungsauftrag bis Projektabschluss) Zeitabschnitt des Projekts, in dem entwickelt wird. SCRUM definiert die für die HERMES definiert alle agile Steuerung der Ergebnisse, Aufgaben und Entwicklung benötigten Rollen für festgelegte Ergebnisse (Artefakte), projektspezifischen Szenarien. Aufgaben (Ereignisse) und HERMES unterscheidet die Ebenen Steuerung, Führung und Ausführung. Die Rollen sind den drei Ebenen zugeordnet. HERMES definiert die Zusammenarbeit zwischen Anwender, Ersteller und Betreiber. Rollen. SCRUM unterscheidet die Ebenen Steuerung und Ausführung. SCRUM definiert die Zusammenarbeit zwischen Anwender (Product Owner) und Entwickler (Rolle Scrum Team) SWE-IPM 45

46 Release 1 Release 2 Release 3 Quelle: O. Bürgi Iterative, Inkrementelle Vorgehensweise Funktionalität [%] Alle Anforderungen erfüllt Phasen: Test Realisation Design Analyse Zeit SWE-IPM 46

47 Iterative, Inkrementelle Prozessmodelle Das Spiralmodell Compendio 2.6 Grundsätzlich risikobasierter Entwicklungsansatz (anstelle von dokumentenbasiertem oder codebasiertem Ansatz) Es wird ein Prototyp erstellt und zum laufen gebracht Weiterentwicklung des Codes vom Prototyp(!) Neue Anforderungen und Erkenntnisse können laufend eingebaut werden Nach jeder Phase wird die nächste Phase geplant (Rollierende Planung) SWE-IPM 47

48 Quellle:Barry W. Boehm: A Spiral Model of Software Development and Enhancement Spiralmodell nach Barry W. Boehm Der SW-Entwicklungs- Zyklus wird in 4 Quadranten unterteilt: Ziele festlegen Alternativen & Risiken beurteilen Prototyp entwickeln & testen Nächsten Zyklus planen SWE-IPM 48

49 Quellle: Boehm, A Spiral Model of Software Development and Enhancement Wofür Boehm das Spiralmodell empfahl Boehm verwendete 1986 das Spiralmodell zur Entwicklung einer integrierten Software-Entwicklungs-Umgebung für die TRW Defense System Group, CA Boehm empfahl das Modell nur für interne Softwareentwicklung weil: Vertragsregelungen für externe Vergaben fehlen (nur Schritt-für-Schritt-Commitments). Weil das Modell darauf vertraut, dass die Softwareentwickler Risiken identifizieren und die Ursachen beheben können. Weil die Schritte des Spiralmodells noch weiter ausgestaltet werden müssten SWE-IPM 49

50 Risikomanagement Plan im Spiralmodell nach Boehm 1. Die Top 10 Projekt-Risiken identifizieren 2. Einen Plan für die Lösung jedes einzelnen Risikos erstellen 3. Die Liste der Top-Risiken monatlich aktualisieren 4. Den Risikostatus der Risikoelemente in monatlichen projekt reviews überprüfen und den zeitlichen Risikoverlauf vergleichen 5. Angemessene Korrektur-Aktivitäten initialisieren Quellle: Boehm, A Spiral Model of Software Development and Enhancement SWE-IPM 50

51 Entwicklung nach dem Spiralmodell Future Combat Systems (FCS) Future Combat Systems (FCS) war das wichtigste Modernisierungsprogramm der USArmy von Boeing und SAIC arbeiteten als Lead System Integratoren von 550 Zulieferern und Subunternehmer in 41 Staten. Quelle: Wikipedia, Future Combat Systems Das Projekt hatte 2-Jahres Iterationen (Spiralen) geplant und hätte bei jeder Spirale einen Prototyp herausbringen sollen. Die technische Feldtests begannen 2008, im Mai 2009 wurde das Programm abgebrochen. The spiral model thus may suit small (up to $3 million) software applications and not a complicated ($3 billion) distributed, interoperable, system of systems. Also it is reasonable to use the spiral model in projects where business goals are unstable but the architecture must be realized well enough to provide high loading and stress ability SWE-IPM 51

52 Iterative, Inkrementelle Prozessmodelle Der Rational Unified Process (RUP) Process Workflows In one iteration, you walk through all workflows Supporting Workflows Workflows group activities logically SWE-IPM 52

53 Workflows im RUP Bsp. Test Workflow Test Designer PlanTest Design Test ImplementTest Evaluate Test Integration Tester Execute Integration Test System Tester Execute System Test Performance Tester Execute Performance Test Designer Design Test Classes and Packages Implementer Implement Test Components and Subsystems SWE-IPM 53

54 Quelle: Wikipedia Empirische, adaptive Vorgehensweise SWE-IPM 54

55 Quelle: Agiles IT-Management in großen Unternehmen: ISBN Die Vorgehensweise (resp. Framework) und die Organisation müssen zusammen passen! SWE-IPM SWE-IPM 55 55

56 Manifesto for Agile Software Development Niedergeschrieben im Jahr 2001 Kent Beck 17 Erstunterzeichner, darunter auch Kent Beck, Martin Fowler, Ken Schwaber, Jeff Sutherland SWE-IPM 56 Martin Fowler

57 Twelve Principles of Agile Software (1-6) 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation SWE-IPM 57

58 Twelve Principles of Agile Software 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity - the art of maximizing the amount of work not done - is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly SWE-IPM 58

59 Empirische, adaptive Extreme Programming XP Compendio 2.12 Darstellung Vorgehen XP nach Compendio SWE-IPM 59

60 Extreme Programming XP Planning/Feedback Loops Darstellung Vorgehen nach Wikipedia SWE-IPM SWE-IPM 60 60

61 Compendio 2.12 Extreme Programming XP Best Practices SWE-IPM 61

62 Agile, adaptive Vorgehensweise Scrum Prozess und Grundsätze SWE-IPM 62