Softwaretechnik. Softwareprozesse und Vorgehensmodelle. Prof. Dr. Matthias Hölzl Joschka Rinke. 21. Januar 2016

Transkript

1 Softwaretechnik Softwareprozesse und Vorgehensmodelle Prof. Dr. Matthias Hölzl Joschka Rinke 21. Januar 2016

2 Prozesse Definition (Prozess) Ein Prozess ist eine Abfolge von definierten Schritten in einer spezifischen Reihenfolge um ein bestimmtes Ziel zu erreichen.

3 Prozesse Den (idealisierten) Prozess kann man von Beschreibungen des Prozesses und vom in Wirklichkeit implementierten Prozess abgrenzen. Prozessmodell/Vorgehensmodell/Entwicklungsmodell Beschreibung eines abstrakten Prozesses, der für verschiedene Projekte einsetzbar ist Prozessspezifikation Beschreibung eines in einem konkreten Projekt verwendeten Prozesses Implementierter Prozess Der Prozess, so wie er wirklich ausgeführt wird Das Verhältnis zwischen Prozess und Prozessspezifikation ist ähnlich dem zwischen ausgeführtem Programm und Quellcode.

4 Softwareprozesse Der Softwareentwicklungsprozess besteht oft aus mehreren Unterprozessen: Produkt-Orientierter-Prozess (Product Engineering Process) Softwareentwicklungs-Prozess Projektmanagement-Prozess Konfigurationsmanagement-Prozess Prozess-Management-Prozess

5 Softwareentwicklungs-Prozess-Modelle Traditionell/schwergewichtig Wasserfall Prototypbasiert Iterativ Spiralmodell... Agil Scrum Extreme Programming...

6 Traditionelle und Agile Vorgehensmodelle Traditionelle Vorgehensmodelle Vorausschauend, prädiktiv Fortschritt wird durch Deliverables dokumentiert (oft sind das Dokumente) Wasserfall-, prototypbasierter, oder iterativer Prozess Agile Vorgehensmodelle Reaktiv, adaptiv Fortschritt wird durch inkrementell ausgelieferte Features gemessen Scrum, Extreme Programming

7 Strikter Wasserfall Der auf den folgenden Folien vorgestellte Strikte Wasserfall- Prozess dient nur zur Illustration und wird in der Praxis nie verwendet!

8 Strikter Wasserfall

9 Strikter Wasserfall

10 Strikter Wasserfall

11 Strikter Wasserfall

12 Strikter Wasserfall

13 Anforderungen: Use Cases Use Case: Erzeuge neuen TODO Eintrag Precondition: Das System ist im Grundzustand Postcondition: Das System ist im Grundzustand, ein neuer TODO Eintrag wurde hinzugefügt 1. Der Benutzer aktiviert die Funktion zum Anlegen eines neuen TODO Eintrags 2. Der Benutzer gibt die zwingend benötigten Daten (Priorität, Text) ein 3. (optional) Der Benutzer gibt ein Zieldatum ein 4. Der Benutzer bestätigt die Daten 5. Der neue Eintrag wird zur Liste hinzugefügt 6. Die Liste aller TODOs wird angezeigt

14 Design: UML Klassendiagramme

15 Wasserfall

16 Wasserfall

17 Wasserfall

18 Wasserfall

19 Wasserfall

20 Wasserfall: Vorteile Festpreisverträge möglich Fortschritt des Projekts kann leicht überwacht werden (theoretisch) Sehr effizient (falls es funktioniert) Leicht zu verstehen

21 Anforderungen vs. Wissen

22 Probleme mit Vorhersagen Annahmen beim Wasserfallprozess Änderungen spät im Entwicklungsprozess sind teuer Detaillierte Anforderungs-/Analyse-/Designdokumente reduzieren Änderungen in späteren Phasen Dokumente enthalten viele Vorhersagen über das System, die in frühen Stadien der Entwicklung gemacht wurden Zu diesem Zeitpunkt wissen Kunden und Entwickler wenig über das System Aber: Große Anzahl von Arbeitsprodukten verwendet diese Annahmen Das verteuert Änderungen in den Annahmen, Änderungen in späteren Phasen werden noch teurer Mehr Planung und Dokumente!...

23 Wasserfall: Nachteile Alle Anforderungen müssen eingefroren werden, bevor das Design beginnt (incl. Hardware, etc.) Begünstigt aufgeblasene Anforderungen: jede möglicherweise benötigte Funktionalität muss in den Anforderungen enthalten sein. Abstrakte Beschreibung von Anforderungen oft schwierig für Kunden Falls das Budget nicht ausreicht oder gekürzt wird, wird nichts ausgeliefert Die Anwender wissen erst am Ende des Projekts, welche Software sie bekommen Dokumentenzentriert, nicht softwarezentriert Lernen erfolgt erst am Ende des Projekts

24 Prototypbasiert Beim prototypbasierten Prozess wird ein Prototyp der Software entwickelt bevor mit einem Wasserfallprozess begonnen wird Die Entwicklung des Prototyps soll so schnell und billig wie möglich erfolgen Der Prototyp wird verworfen und nicht in die Produktentwicklung übernommen

25 Prototypbasiert

26 Prototypbasiert: Vorteile Anforderungen können besser verstanden und zwischen Kunden und Entwicklern besprochen werden Sonstige Vorteile ähnlich zum Wasserfall Festpreisverträge möglich Fortschritt des Projekts kann leicht überwacht werden (theoretisch) Leicht zu verstehen

27 Prototypbasiert: Nachteile Druck den Prototyp als Produktivsystem zu verwenden Fehlerbehaftet, schlechte Performanz Schlechte Architektur, schlecht Wartbar Prototyp führt oft zur Unterschätzung der Kosten durch Management Kosten für Prototyp Sonstige Nachteile ähnlich zum Wasserfall

28 Iterativ

29 Iterativ: Vorteile Jedes Inkrement liefert wertvolle Funktionalität an den Kunden aus Scheitern des kompletten Projekts weniger wahrscheinlich und billiger Änderungen während des ganzen Prozesses möglich Wichtige Features werden im Produktiveinsatz getestet bevor die Entwicklung beendet wird Die ersten Inkremente bieten ähnliche Vorteile wie ein Prototyp

30 Iterativ: Nachteile Identifikation von mehrfach genutzten Features und gemeinsamer Infrastruktur schwieriger Spezifikation wird mit der Software zusammen entwickelt; das erschwert möglicherweise Verträge Möglicherweise Anpassung bereits implementierter Features nötig

31 Spiralmodell Spezialisierung des iterativen Modells Vier Quadranten, die spiralförmig durchlaufen werden Festlegung von Zielen, Identifikation von Alternativen, Rahmenbedingungen Evaluieren von Alternativen, Risikoabschätzung Realisierung des Zwischenprodukts Planung des nächsten Zyklus Risikobetrachtung in Prozess integriert

32 Spiralmodell

33 Manifest für Agile Softwareentwicklung Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans

34 Scrum Fokus auf Wert für Kunden Kunde setzt Prioritäten fest Entwickler schätzen Kosten für Implementierung ab und können frei entscheiden, wie sie die am höchsten priorisierten Features entwickeln Drei Phasen Überblicksplanung Sprints (iteriert) Projektabschluss

35 Rollen in Scrum Produktinhaber Entwicklungsteam Scrum-Master

36 Produktinhaber Entscheidet welche Features entwickelt werden in welcher Reihenfolge die Features entwickelt werden Beantwortet dem Entwicklungsteam Fragen zum Produkt Verantwortlich für Produktvision

37 Entwicklungsteam Verantwortlich für Software Dokumentation Testen Organisiert sich selbst 5 9 Entwickler

38 Scrum-Master Kommuniziert Scrum Werte, Prinzipien und Praktiken Verantwortlich für Prozess Hilft in der Anpassung des Scrum Prozesses an die Bedürfnisse des Projekts Keine Personalverantwortung, kein Projektmanager

39 Scrum Begriffe Produkt-Backlog Sprint-Backlog Minimal Auslieferbares Produktinkrement (Potentially Shippable Product Increment, PSPI)

40 Sprint Entwicklungs-Iteration Dauer: 1 4 Wochen Liefert PSPI Konstante Zeitdauer (Zeitbox) Keine Verlängerung, falls Ziele nicht erreicht werden Während eines Sprints erfolgt keine Änderung der geplanten Arbeit

41 Sprint

42 Produkt-Backlog Wird vom Produktinhaber verwaltet Geordnete Liste von Einträgen (Items) Wird ständig gepflegt/geändert Pflege (Grooming) Anlegen Verfeinern Abschätzen Priorisieren von Einträgen

43 Produkt-Backlog vs. Anforderungsdokument Anforderungsdokument Wird am Anfang des Entwicklungszyklus erstellt Unveränderlich Enthält alle Anforderungen in detaillierter Form Backlog Wird Just In Time erstellt Wird ständig gepflegt So wenig Details wie möglich (just enough Detail) Einträge sind Erinnerungen, dass eine Anforderung besteht Details werden in Kommunikation zwischen Produkteigentümer und Entwicklern geklärt

44 Sprint-Planung Festlegen der Ziele des Sprints Entwicklungsteam verpflichtet sich Einträge des Produkt-Backlogs zu entwickeln Einträge werden in Arbeitseinheiten (Tasks) verfeinert Ein Sprint-Backlog wird erstellt Die Geschwindigkeit der Sprints soll dauerhaft durchgehalten werden können

45 Sprint-Durchführung Entwicklungsteam führt Arbeitseinheiten aus Am Ende des Sprints sollen alle Einträge des Sprint-Backlogs abgearbeitet sein Daily Scrum Festgelegte Zeitdauer (< 15 min) Moderiert vom Scrum Master Jedes Teammitglied berichtet Was habe ich erreicht? Was plane ich als nächstes? Welche Probleme sind aufgetreten Keine Problemlösungs-Aktivität Kein Status-Meeting Nur das Scrum-Team ist aktiv beteiligt

46 Arten von Unsicherheit Zielunsicherheit (was?) Unsicherheit bezüglich der Features des Endprodukts Mittelunsicherheit (wie?) Unsicherheit bezüglich der verwendeten Technologie-, Architektur-, Design- und Prozessentscheidungen Kundenunsicherheit (wer?)? Unsicherheit bezüglich der potentiellen Kunden

47 Commitment: LRM Die Kosten von getroffenen Entscheidungen sinken im Laufe des Prozesses Die Kosten von verschobenen Entscheidungen steigen im Laufe des Prozesses Es gibt einen Zeitpunkt zu dem das Verschieben einer Entscheidung teurer wird als das treffen: Last Responsible Moment (LRM)

48 Commitment: LRM

49 Gegenüberstellung Traditionell/Agil Traditionell Agil Arbeitsfortschritt Eine Phase Ein/mehrere Feature(s) Unsicherheit Ziel vor Mittel Beide gleichzeitig Entscheidungen Jede in def. Phase Optionen offen halten Anforderungen Am Anfang Bei Bedarf Anf. Details Am Anfang Bei Bedarf Steuerung Vorhersagend Reaktiv Commitment Baldmöglichst Last Responsible Moment

50 Gegenüberstellung Traditionell/Agil Traditionell Agil Änderung Disruptiv: vermeiden Unvermeidbar Unbekanntes Am Anfang vorhergesagt/ Experiment während geplant Entwicklung Annahmen Sind langlebig Werden minimiert Optimierung Auslastung Entwickler Vorhandene Arbeit Fortschritt Deliverables Features Hauptmerkmal Prozesszentriert Wertezentriert Formalität Typischerweise hoch Typischerweise gering