Softwaretechnik Prozessmodelle

Transkript

1 Softwaretechnik Prozessmodelle Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin Celine: They enjoy the goal but not the process. But the reality of it is that the true work of improving things is in the little achievements of the day. (Before Sunset, 2004) Karsten Weicker, Nicole Weicker 1/ 33

2 Prozessmodelle Erinnerung Definition (Vorgehensmodell) Ein Vorgehensmodell (oder auch Softwareprozess) ist eine Menge von Aktivitäten, die benötigt werden um Softwaresysteme zu entwickeln, sowie deren Anordnung bzw. Abfolge. Beispiele Wasserfall-Modell Prototyping Iterative Software-Entwicklung Inkrementelle Software-Entwicklung Spiral-Modell Karsten Weicker, Nicole Weicker 2/ 33

3 Prozessmodelle Erinnerung Wasserfall-Modell Anforderungsanalyse Anforderungsspezifikation Systementwurf Implementation Test Betrieb Karsten Weicker, Nicole Weicker 3/ 33

4 Prozessmodelle Erweiterung des Vorgehensmodells Definition (Prozessmodell) Ein Prozessmodell enthält neben dem Vorgehensmodell auch Vorgaben zu Organisationsstrukturen, Projektmanagement, Qualitätssicherung, Dokumentation und Konfigurationsverwaltung. Karsten Weicker, Nicole Weicker 4/ 33

5 Prozessmodelle Erweiterung des Vorgehensmodells Definition (Prozessmodell) Ein Prozessmodell enthält neben dem Vorgehensmodell auch Vorgaben zu Organisationsstrukturen, Projektmanagement, Qualitätssicherung, Dokumentation und Konfigurationsverwaltung. Phasenmodelle: Phasen werden durch Meilensteine abgeschlossen keine Zyklen Nacharbeiten laufen unter dem Budget der nachfolgenden Phase(n) Karsten Weicker, Nicole Weicker 4/ 33

6 Rational Unified Process Rational Unified Process (RUP) Geschichte: 1992 Objectory Process von Ivar Jacobson 1998 Rational Unified Process (vorher: Rational Objectory Process) 1999 Unified Process (UP) als Abstraktion Karsten Weicker, Nicole Weicker 5/ 33

7 Rational Unified Process UP/ RUP Eigenschaften: 4 zeitliche Phasen abgeschlossen durch Meilensteine (mehrere) Iterationen innerhalb jeder Phase (interne Meilensteine) vordefinierte Arbeitsabläufen jeweils in allen Phasen in unterschiedlicher Intensität ein Durchlauf aller vier Phasen = Zyklus (internes oder externes) Release inkrementelle Produktentwicklung (event. mehrere Zyklen) basiert auf Use Cases architekturzentriert (frühzeitiger Entwurf) Karsten Weicker, Nicole Weicker 6/ 33

8 Rational Unified Process UP/ RUP: Phasen 1. Inception Verstehen der Produktidee und Anforderungen Use Cases identifizieren, modellieren Risiken bewerten erste Fassung: Architektur, Projektplan erste Prototypen für risikoreiche Aspekte Karsten Weicker, Nicole Weicker 7/ 33

9 Rational Unified Process UP/ RUP: Phasen 1. Inception 2. Elaboration Verstehen der Produktidee und Anforderungen Use Cases identifizieren, modellieren Risiken bewerten erste Fassung: Architektur, Projektplan erste Prototypen für risikoreiche Aspekte Identifikation der fehlenden Anforderungen grundlegende Architekturentscheidungen Systemarchitektur erster Prototyp: Architekturkern und dessen Funktionalität größte Risiken Gegenmaßnahmen Planung der folgenden Phasen Karsten Weicker, Nicole Weicker 7/ 33

10 Rational Unified Process UP/ RUP: Phasen (2) 3. Construction Implementation, Integration und Test Fertigstellen von Dokumenten einsetzbares System in Beta-Version Karsten Weicker, Nicole Weicker 8/ 33

11 Rational Unified Process UP/ RUP: Phasen (2) 3. Construction 4. Transition Implementation, Integration und Test Fertigstellen von Dokumenten einsetzbares System in Beta-Version Ziel: stabiler Zustand des Systems Produktqualität Auslieferung endet, wenn Kunde zufrieden! Karsten Weicker, Nicole Weicker 8/ 33

12 Rational Unified Process UP/ RUP: Arbeitsabläufe Requirements Anforderungen des Systems erheben und bearbeiten Analysis and Design aus den Anforderungen Entwurfsmodell und Systemmodell gewinnen Implementation Teile der Architektur codieren/ integrieren Test Tests verschiedener Art durchführen Karsten Weicker, Nicole Weicker 9/ 33

13 Rational Unified Process RUP: zusätzliche Arbeitsabläufe Business Modelling Strukturen/ Abläufe in der Auftraggeber-Organisation verstehen, gemeinsame Sprache etablieren Deployment System zusammenstellen, geordnet an Auftraggeber übergeben, in Betrieb nehmen Configuration and Change Management erstellte Arbeitsergebnisse systematisch verwalten, Änderungen geordnet durchführen Karsten Weicker, Nicole Weicker 10/ 33

14 Rational Unified Process RUP: zusätzliche Arbeitsabläufe (2) Project Management Projekt und Iterationen planen, kontrollieren (einschl. Risikomanagement) Environment Entwicklungsprojekt unterstützen (z.b. durch Auswahl von Entwicklungswerkzeugen, Administration von Rechnern oder Erstellen von Backups) Karsten Weicker, Nicole Weicker 11/ 33

15 Rational Unified Process RUP: Phasen, Iterationen, Arbeitsabläufe Beispiel Karsten Weicker, Nicole Weicker 12/ 33

16 V-Modell XT V-Modell XT Geschichte: 1992 Vorschrift des Bundesministeriums für Verteidigung 1996 auch: ziviler Verwaltungsbereich der Bundesbehörden 2004 V-Modell XT (extreme tailoring) Karsten Weicker, Nicole Weicker 13/ 33

17 V-Modell XT V-Modell XT Eigenschaften des Modells aktivitätsorientiert Kern: Netz von Aktivitäten und Produkten Phasen mit Entscheidungspunkten (Meilensteinen) Integration projektbegleitender Tätigkeiten (QS, Konfigurationsverwaltung, Projektmanagement) unterstützt inkrementelle, komponentenbasierte und auch agile Entwicklung einfach anpassbar und erweiterbar Auftraggeber- oder Arbeitnehmerprojektsicht Karsten Weicker, Nicole Weicker 14/ 33

18 V-Modell XT V-Modell XT Elemente des Modells: 90 Aktivitäten über 100 Produkte 31 Rollen Vorgehensbausteine Zusammenfassung von Aktivitäten, Produkten und Rollen für eine Aufgabe 21 Entscheidungspunkte (Meilensteine) Projektdurchführungsstrategien Menge von Entscheidungspunkten, zeitliche Reihenfolge Karsten Weicker, Nicole Weicker 15/ 33

19 V-Modell XT V-Modell XT Zusammenfassung Projekt = Vorgehensbausteine und Projektdurchführungsstrategien Projektdurchführungsstrategie = Anordnung von Entscheidungspunkten Entscheidungspunkt = definierte Produkte fertig Vorgehensbaustein = Rollen, Produkte, Aktivitäten für zentrale Projektaufgabe mindestens vier Kern-Vorgehensbausteine Projektmanagement Qualitätssicherung Problem- und Änderungsmanagement Konfigurationsmanagement Produkte, Aktivitäten gruppiert, gegliedert; Produkt Ergebnis einer Aktivität Rollen für Produkte verantwortlich Karsten Weicker, Nicole Weicker 16/ 33

20 V-Modell XT V-Modell XT: Grundablauf Zentrale Entscheidungspunkte der Systementwicklung Anforderungen festlegen System spezifizieren System entwerfen Systemelement realisiert Systemintegration Systemtest Feinentwurf Abnahmetest Karsten Weicker, Nicole Weicker 17/ 33

21 V-Modell XT V-Modell XT: Inkrementelle Entwicklung (vereinf.) Anforderungen festlegen Feinentwurf Abnahmetest Iteration geplant System spezifizieren System entwerfen Systemtest Systemintegration Systemelement realisiert Karsten Weicker, Nicole Weicker 18/ 33

22 V-Modell XT V-Modell XT: Komponentenbasierte Entwicklung (vereinf.) Anforderungen festlegen Iteration geplant Feinentwurf Abnahmetest System spezifizieren System entwerfen Systemtest Systemintegration Systemelement realisiert Karsten Weicker, Nicole Weicker 19/ 33

23 Agile Modelle Agile Modelle Gegenbewegung zu den sehr starren, bürokratischen Prozessmodellen The Agile Manifesto 2001 Neuverteilung von Prioritäten Personen, Interaktionen statt Prozesse und Tools funktionierende Software statt ausführliche Dokumentation Zusammenarbeit mit Kunden statt Vertragsverhandlungen Reaktion auf Veränderungen statt Erfüllung eines Plans bekanntester Vertreter: Extreme Programming (XP) Karsten Weicker, Nicole Weicker 20/ 33

24 Agile Modelle Agile Modelle Prinzipien oberste Priorität: Kundenzufriedenheit durch frühe und kontinuierliche Auslieferung von funktionstüchtiger Software Anforderungsänderungen jederzeit willkommen alle paar Wochen/ Monate Auslieferung von Software ständige, enge Zusammenarbeit von Kunde und Entwickler Projekte um motivierte Personen Unterstützung für und Vertrauen in Mitarbeiter! face-to-face Kommunikation funktionierende Software als oberstes Maß Karsten Weicker, Nicole Weicker 21/ 33

25 Agile Modelle Agile Modelle Prinzipien nachhaltige, machbare Entwicklung kontinuierliche Aufmerksamkeit auf technische Exzellenz und gutes Design Einfachheit Verzicht jeden unnötigen Arbeitsschritt selbstorganisierende Teams beste Spezifikationen und Architekturen regelmäßige Gruppenreflexionen Karsten Weicker, Nicole Weicker 22/ 33

26 Agile Modelle Agile Modelle Eigenschaften: iterativ, Zyklen 3 Monate kleine Gruppen, 6 8 Personen in einem Raum starke Einschränkung der Dokumentation Präsenz des Kunden Ablehnung dogmatischer Regeln Karsten Weicker, Nicole Weicker 23/ 33

27 Agile Modelle Agile Modelle: Extreme Programming Werte des XP Einfachheit einfache Lösungen und Prozesse Feedback vom Anwender, auch vom Team Kommunikation persönlich und direkt Mut Voraussetzung für XP Karsten Weicker, Nicole Weicker 24/ 33

28 Agile Modelle Agile Modelle: Extreme Programming Managementkonzepte integrales Team Kunde immer verfügbar Planungsspiel Planung des nächsten Schritts in der inkrementellen Entwicklung kurze Release-Zyklen wenige Wochen Standup-Meeting täglich, kurz (15 min) Rückblick Karsten Weicker, Nicole Weicker 25/ 33

29 Agile Modelle Agile Modelle: Extreme Programming Teamkonzepte gemeinsame Verantwortung für den Code Refactoring Codierrichtlinien erträgliche Arbeitsbelastung keine Überstunden! laufende Integration auf Integrationsrechner Karsten Weicker, Nicole Weicker 26/ 33

30 Agile Modelle Agile Modelle: Extreme Programming Programmierkonzepte testgetriebene Entwicklung Testen vor Implementieren Refactoring Strukturverbesserungen vor neuen Funktionen einfacher Entwurf inkrementelle Erweiterung des Entwurfs Paar-Programmierung einer codiert, der andere schaut zu, überprüft, hinterfragt; wechselnde Rollen, wechselnde Paare Qualitätsverbesserung, Verteilung des Wissens Karsten Weicker, Nicole Weicker 27/ 33

31 Agile Modelle Agile Modelle Bewertung gut geeignet für schnelle Entwicklung schnelle Reaktion auf Wünsche von Auftraggeber oder Markt geringe Risiken durch Software-Fehler kleine Entwicklerteams (bis 20 Mitarbeiter) eingesetzt im Internet Mobiltelefon Karsten Weicker, Nicole Weicker 28/ 33

32 Cleanroom Development Cleanroom Development Process (CDP) 1987 von Mills, Dyer, Linger auch aktuelle Literatur dazu Idee: ähnlich zur Chipherstellung: Verunreinigungen vermeiden statt Fehler machen und beseitigen Fehler vermeiden Karsten Weicker, Nicole Weicker 29/ 33

33 Cleanroom Development CDP Fakten (belegt in 70er Jahren) kleine Projekte bessere Chancen gründliche Analyse und Spezifikation wichtiges Voraussetzung für Erfolg Inpektionen zur Fehlerfindung (Reviews, Lesen von Code) syntaktische Fehler semantische Probleme Nachbesserungen hohe Kosten, Risiken Testdaten von Hand Zuverlässigkeit des Systems Karsten Weicker, Nicole Weicker 30/ 33

34 Cleanroom Development CDP Cleanroom Konzepte große Projekte inkrementell Serie kleiner Projekte je 5 8 Entwickler, wenige Monate Analyse, Spezifikation hoher Aufwand, gründliche Inspektion Entwickler dürfen nicht (!) Code compilieren testen kein Komponententest Integration dann Systemtest (statistischer Test) kaum Fehlerakzeptanz: Komponente mit vielen Fehler Neuimplementation Karsten Weicker, Nicole Weicker 31/ 33

35 Cleanroom Development CDP statistischer Test Ziele: nicht zum Debugging Ziel: Zertifizierung der Qualität sonst: Neuimplementation Prognosen über Zuverlässigkeit (mean time between failure) Voraussetzungen Zufallstestdaten (viele Tausende) Testdaten realistisch verteilt (Benutzungsprofile) Karsten Weicker, Nicole Weicker 32/ 33

36 Cleanroom Development CDP statistischer Test Ziele: nicht zum Debugging Ziel: Zertifizierung der Qualität sonst: Neuimplementation Prognosen über Zuverlässigkeit (mean time between failure) Voraussetzungen Zufallstestdaten (viele Tausende) Testdaten realistisch verteilt (Benutzungsprofile) umstrittenste Idee des Cleanroom-Ansatzes kein Beleg, dass Tests so besser Zufallstestdaten Problem: Soll-Resultate nicht, nur vage bekannt Karsten Weicker, Nicole Weicker 32/ 33

37 Cleanroom Development CDP Bewertung Vorteile durch rigide, auch mathematische Modellierung, Verifikation und statistische Tests ungewöhnlich fehlerarme Systeme, Zuverlässigkeit prognostiziert Prozessverbesserung durch statistische Kontrolle Probleme (schwer erfüllbare Voraussetzungen) hohe Anforderungen an Entwickler nur Spezifiziertes kann entwickelt werden stabile Randbedingungen notwendig Karsten Weicker, Nicole Weicker 33/ 33