AK aus Software Engineering I - SWEP

Transkript

1 AK aus Software Engineering I - SWEP Software Entwicklungsprozesse Part W Dezember 2005 Thomas Pirngruber swep@inso.tuwien.ac.at INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien

2 Zitat It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. Franklin D. Roosevelt 2

3 Outline Presentation of an extended range of actual software engineering process models (eg. RUP, MSF, XP, PSP, TSP and many more) Process Customizing Process Improvement Tool Support, Unified development platforms Current trends and developments in software engineering process models (e.g. Agility for heavyweight process models, hybrid models) 3

4 Agenda Motivation und Ziele Vorstellung von Prozessmodellen Scrum Extreme Programming (XP) Crystal Clear Object-Oriented Software Process (OOSP) Charakterisierung der Modelle 4

5 Motivation und Ziele DA: Projektorganisatorische Analyse und Klassifizierung von State-of-the-Art Softwareentwicklungs- Prozessmodellen Bedeutung von Prozessmodellen Unmenge an Artikeln und Büchern zu Modellen Keine anerkannte Klassifizierungsmöglichkeit Beschreibung von Modellen (insgesamt 15) Scrum, XP, Crystal Clear, OOSP ( ) V-Modell 97, V-Modell XT, Personal Software Process (PSP), Team Software Process (TSP) ( ) Erarbeitung eines Kategorienmodells Einordnung der Prozessmodelle 5

6 Scrum 1/6 Grundlegendes Geht auf Jeff Sutherland, Ken Schwaber und Mike Beedle zurück Name stammt aus dem Rugby (adaptive, selbstorganisierende Strategie) Wurzeln in der empirischen Prozesssteuerung (Gegensatz: definierte) 6

7 Scrum 2/6 Entwicklungsphilosophie Product-Backlog: ständige Anpassung; Planning Meeting: Sprint-Goal Team: 7 +/- 2 Personen; Daily Scrum: Fortschritt/Hindernisse Sprint Review: Inkrement nehmen (ja/nein) 7

8 Scrum 3/6 Wichtige Elemente 1/2 Sprint Ziele: Potenziell auslieferbares Software-System So schnell wie möglich (Störungen!) Sprint Goal erreichen; Auf welche Art und Weise egal (zusätzliche Prozessmodelle; XBreed) Keine Vorgaben bzgl. Dokumenten oder Methoden (Modelle und Entwürfe sollen nur Verständnis fördern) Abbruch möglich Am wichtigsten: gelieferte Funktionalität Daily Scrum: Immer zur selben Zeit am selben Ort (ca. 15. Minuten) 3 Fragen vom Scrum-Master an jedes Team-Mitglied: Was hast du seit dem letzten Meeting getan bzw. erreicht? Was wirst du bis zum nächsten Meeting tun? Was hindert dich daran deine Arbeit zu tun bzw. deine Ziele zu erreichen? 8

9 Scrum 4/6 Wichtige Elemente 2/2 Product Backlog Von allen Projektbeteiligten jederzeit einsehbar Äußerst dynamisch Wichtig: Lediglich Product Owner kann Änderungen vornehmen Inkrement Software-System entsteht in Inkrementen Spätestens zweiter Sprint sollte lauffähige Version liefern Burndown-Chart Diagramm mit tagesaktuelle Aufwandsschätzungen für akt. Sprint Vom Scrum Master gepflegt Ziel: Möglichst bald Probleme/Hindernisse erkennen 9

10 Scrum 5/6 Wichtige Rollen Product Owner Erstellung/Priorisierung des Product Backlogs Ausschl. Kommunikationskanal zw. Team & Außenstehenden Scrum Team Erreichung des Sprint Goals bzw. Umsetzung des Sprint Backlogs Scrum Master Dynamik von Scrum zur ungestörten Entfaltung zu bringen durch: Achten auf die Umsetzung der Grundsätze und Regeln Team vor äußeren Einflüssen abschotten 10

11 Scrum 6/6 Wesentliche Eigenschaften Hintereinander Sprints (=Iteration, ca. 30 Tage); Inkrementelle Produkterstellung; Sprint Goal unterstützt parallele Tätigkeiten Fokus auf den durchzuführenden Aktivitäten Keine Vorgaben bzgl. Artefakten oder Methoden (Problem!?) Schnelle Reaktion auf sich ändernde Anforderungen möglich Späte Änderungen stellen kein großes Problem dar Verdankt Relevanz seinen Erfindern und den Benutzern Wenige (z.b. Sprint-Länge) bzw. keine (z.b. Auslassen von Meetings) Anpassungsmöglichkeiten vorgesehen Erweiterungen durch Kombination mit anderen SWEPs bei der eigentlichen SW-Entwicklung (Sprint) sinnvoll (XBreed=XP+Scrum) 11

12 XP 1/8 Grundlegendes Wurde von Kent Beck, Ron Jeffries und Ward Cunningham kreiert Als Reaktion auf überregulierte Modelle Name: Anerkannte Prinzipien/Verfahren in extremer Weise einsetzen Vorgesehen für kleine bis mittelgroße Teams (bis 12 Personen) Geeignet bei sich rasch ändernden Anforderungen (Behauptung: Kosten für Änderungen während des gesamten Projekts konstant) Über Werte, Prinzipien, Techniken und Rollen definiert Werte Kommunikation (Verzichten auf Dokumente) Einfachheit ( What is the simplest thing that could possibly work ) Feedback (für Qualität entscheidend; z.b. Komponententests) Mut Zu Abstrakt! Daher: Ableitung von Prinzipien 12

13 XP 2/8 Prinzipien (der Kern) Unmittelbares Feedback Lernerfolg steigern; nicht in falsche Richtung arbeiten Einfachheit anstreben Einfach Lösungen können schneller erstellt/geändert werden Sie sind überdies leichter zu verstehen/zu kommunizieren Inkrementelle Veränderung Risikominimierung im Vergleich zu großen Veränderungen Veränderung wollen Durch Einfachheit öfters Änderungen notwendig Müssen gewollt und dürfen nicht als unerwünscht aufgefasst werden Qualitätsarbeit Ziel für jedes Projektmitglied Eine Vielzahl weiterer Prinzipien 13

14 XP 3/8 Techniken 1/3 Kernstück von XP; Unterstützen die Werte und Prinzipien Wechselwirkungen (verstehen!); 20:80 Regel; kein Alles oder Nichts 14

15 XP 4/8 Techniken 2/3 Kunde vor Ort Stets für auftretende Fragen verfügbar Kann sonst seiner üblichen Arbeit nachgehen Planungsspiel Auf Story-Cards werden Anforderungen des Kunden bestimmt Priorisierte Story-Cards legen Inhalt des nächsten Inkrements fest Metapher Gemeinsame Vision soll Kommunikation und parallele Arbeiten erleichtern Kurze Releasezyklen 1 Tag bis max. 4 Monate Testen Ständig; durch häufige Änderungen besonders wichtig (Testumgebung) Einfaches Design Leichter zu erstellen und zu ändern 15

16 XP 5/8 Techniken 3/3 Refactoring Die Umstrukturierung von Software unter Beibehaltung der Funktionalität Programmieren in Paaren Um Qualität zu erhöhen Um Wissen zu verbreiten Gemeinsame Verantwortlichkeit Jedes Team-Mitglied darf jeglichen Quellcode ändern Fortlaufende Integration Damit geänderte Komponenten anderen so früh wie möglich zur Verfügung stehen Um Integrationsaufwand am Ende zu senken Programmierstandards Um Programmieren in Paaren und Gemeinsame Verantwortlichkeit zu ermöglichen 40-Stunden-Woche Um Kreativität und Einsatz der Entwickler zu fördern 16

17 XP 6/8 Rollen (laut K. Beck nur die ersten 4 zwingend erforderlich) Entwickler/Programmierer Programmieren, Aufwandsschätzungen, Testerstellung Kunde Erstellung/Priorisierung von Anforderungen über Story-Cards XP-Trainer Führung des gesamten Teams und Einhaltung der Prinzipien Verfolger Sammeln von Daten (Projektstatus); Erkennen von Problemen Tester Testdurchführung Berater Unterstützung hinsichtlich spezieller Technologien Big Boss Dem Team Mut und Zuversicht geben 17

18 XP 7/8 Entwicklungsphilosophie Prototyp (Spike) bzgl. Architektur um frühzeitig Probleme zu erkennen Ad Spike: Frederick P. Brooks: The mythical man-month. Kapitel Plan to throw one away. Release Planning: Aufwand für User Stories schätzen; in nächster Iteration umzusetzende Anforderungen priorisieren 18

19 XP 8/8 Wesentliche Eigenschaften Iterative, inkrementelle Vorgehensweise (1 Tag bis max. 4 Monate für einen Zyklus), Parallele Arbeiten werden durch Kommunikation und Metapher unterstützt Fokus auf den durchzuführenden Aktivitäten Wenige Artefakte zwingend; keine Methoden, Tools vorgeschrieben Dokumentation muss nicht erstellt werden Miteinbeziehung des Kunden Schnelle und sich rasch ändernde Anforderungen kein Problem Modell wird mittlerweile von einer breiten Gemeinschaft unterstützt Anpassen über Weglassen von Techniken (40-Stunden Woche, Programmieren in Paaren, Metapher) Erweiterungen sinnvoll bei größeren Projekten (mehr als Entwickler) oder verteilten Entwicklungsstandorten 19

20 Crystal Clear 1/6 Grundlegendes Wurde von Alistair Cockburn und Jim Highsmith kreiert/spezifiziert Teil einer Familie von Prozessmodellen (Crystal Family) Unterschiedliche Projekte benötigen völlig unterschiedliche Prozesse X-Achse: Teamgröße Y-Achse: Kritikalität (Auswirkung eines Fehlers) Je kleiner Teamgröße desto weniger Dokumente Je kritischer das Projekt desto formaler die Dokumente 20

21 Crystal Clear 2/6 Zentrale Aspekte Fähigkeiten der Mitarbeiter, Kommunikation und Gemeinschaft wichtiger als das Verfolgen von Prozessen Tools und Artefakte dienen lediglich als Unterstützung Team selbst entscheidet über zu verwendende Methoden und zu erzeugende Dokumente (lediglich Empfehlungen) Light on work products, strong on communications Nicht der beste, sondern lediglich ausreichender Weg um SW zu erstellen Legt 7 Properties fest CC fordert nur die ersten 3 (je mehr desto erfolgreicher) Einzig zwingende Vorgabe Strategien/Techniken für leichteren Einstieg in Crystal (z.b. Side-by- Side Programming, Daily Stand-up Meetings, ) 8 Rollen vorgesehen (Lead Designer die wichtigste) 21

22 Crystal Clear 3/6 7 Properties Frequent Delivery Alle 1 bis max. 4 Monate (Vorteile: Feedback, Reagieren auf Änderungen) Reflective Improvement Analysieren, Diskutieren, Vorschlagen (mind. 1 Stunde pro Monat) Osmotic Communication (nur CC; sonst Close C.) Alle Team-Mitglieder im selben Raum; können Gespräche mithören Personal Safety Keine Angst vor Meinungsäußerungen (Pläne, Designs, ) Focus Ziel muss klar sein Easy Access to Expert Users Antwort innerhalb weniger Stunden A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration CM am wichtigsten 22

23 Crystal Clear 4/6 Entwicklungsphilosophie Project Charter (Teambildung, Anpassungen, ); Wrapup (Rückblick) Delivery Deliver (Auslieferung an einen User), Reflect (Rückblick) Iteration Plan, Reflect & Celebrate 23

24 Crystal Clear 5/6 Crystal Clear in einem Satz: The lead designer and two to seven other developers in a large room or adjacent rooms, using information radiators such as whiteboards and flip charts, having easy access to expert users, distractions kept away, deliver running tested, usable code to the users every month or two (quarterly at worst), reflecting and adjusting their working conventions periodically. 24

25 Crystal Clear 6/6 Wesentliche Eigenschaften Iterative, inkrementelle Software-Erstellung (ca. 1 bis max. 4 Monate für eine Iteration), Häufige Kommunikation unterstützt parallele Entwicklungsarbeiten Durch durchzuführende Aktivitäten geprägt Lediglich Richtlinien (properties) werden gegeben Keine Strategien/Techniken, Methoden od. Dokumente explizit vorgeschrieben (lediglich Vorgaben) Häufiges Ausliefern, Kundenkontakt; Mensch/Kommunikation im Mittelpunkt Wird von Modell-Entwicklern und Anwendern geprägt (keine Tools) Anpassung über Hinzunahme (von properties); stretch to fit instead of shrink to fit Erweiterungen durch Kombination mit andere Modellen (z.b. XP, RUP, Scrum) 25

26 OOSP 1/4 Grundlegendes Geht auf Scott W. Ambler zurück Auf die Entwicklung von large-scale, mission-critical applications ausgerichtet wird über Process Patterns beschrieben PP: Sammlung allgemeingültiger Techniken, Aktivitäten & Methoden Beschreiben eine Lösung für die SW-Entwicklung, geben aber keine Implementierungsdetails vor -> dem Anwender überlassen 3 Arten von Process Patterns Phase PP (Phasen; z.b. Construct) Stage PP (Etappen; z.b. Model (der Phase Construct)) Task PP (Schritte; z.b. Durchführen eines technischen Reviews) Patterns sind Basis für Anpassungen/Erweiterungen Unterstützt CMM-Level 5 (Umfang) Einführung aller möglichen PP dauert mehrere Jahre (Umfang) 26

27 OOSP 2/4 Entwicklungsphilosophie Die Phasen werden hintereinander und die Etappen in den Phasen iterativ durchlaufen Project & Cross-Project Tasks; Inkrementelle Entwicklung (z.b. I-C-D- M-C-D-M) 27

28 OOSP 3/4 Aufbau der Patterns Textuelle und Graphische Beschreibung (hier Bsp: Construct Phase) Schema Entry Conditions to begin the phase/stage/task Solution Exit Conditions to leave the phase/stage/task 28

29 OOSP 4/4 Wesentliche Eigenschaften Die 4 Phasen werden seriell und Etappen innerhalb dieser iterativ durchlaufen; Inkrement nach Abschluss der Phasen (nach längerer Zeit); parallele SW-Entwicklung durch eigenen Pattern unterstützt Situationsbedingte Beschreibung der durchzuführenden Aktivitäten Auf große Projekte ausgerichtet; Bei vollständiger Übernahme viele Artefakte zu erstellen/tätigkeiten durchzuführen (Disziplin) Anforderungen müssen zu Beginn feststehen bzw. dürfen sich nur mehr geringfügig ändern; Mitwirken des Kunden kommt nicht vor Modell lebt von Scott W. Ambler und seinen Anwendern; keine Tools vorgeschrieben Über das Adaptieren der Process Patterns (aufwendig,fachwissen) Erweiterung über zusätzliche Process Patterns möglich 29

30 Erarbeitung eines Kategorienmodells 1/3 Vorgangsweise Prozesssteuerung Ergebnisorientiert Die zu erstellenden Ergebnisse, deren Status und ihre Transformation bestimmen die Vorgangsweise Aktivitätsorientiert Aktivitäten und deren Beziehungen stehen im Mittelpunkt Musterorientiert Durchzuführenden Arbeitsschritte werden über situationsabhängige Bedingungen definiert Gewichtigkeit Komplexität (Umfang, Genauigkeit) Heavy-weighted (schwergewichtig) Vielzahl von Artefakten; genaue Einhaltung von Vorschriften; Genauigkeit, wenig Toleranz bzw. Interpretationsspielraum; hohes Maß an Disziplin und Gewissenhaftigkeit Light-weighted (leichtgewichtig) Anzahl der zu erstellenden Artefakte gering; oftmals nicht verpflichtend bzw. nur für besseres Verständnis von Vorteil; Freiräume für eigene Interpretationen 30

31 Erarbeitung eines Kategorienmodells 2/3 Berechtigungsbasis Relevanz Industrial-driven Unterstützung z.b. aus der Wirtschaft, von Gremien oder Universitäten Modell enthält notwendige Tools (Bindung an Hersteller) Community-driven Lebt von einer Art Gemeinschaft (Vorschläge für Weiterentwicklung) Herstellerunabhängigkeit bzgl. Tools angestrebt Ansatz Anwendung Agil Ergebnisse früh & danach laufend sichtbar (kurze Iterationszeiten) Vage Anforderungen und Änderungen sind kein Problem Produkt, Mensch und Kommunikation stehen im Mittelpunkt Miteinbeziehung des Kunden wird angestrebt Traditionell Späte Ergebnisse Exaktes Verständnis der Anforderungen und somit stabiles Ziel Prozess, Werkzeuge und das Verfolgen eines Plans stehen im Mittelpunkt Direktes Mitwirken des Kunden eher unwahrscheinlich 31

32 Erarbeitung eines Kategorienmodells 3/3 Adaption Flexibilität Tailoring Anpassung an ein Unternehmen bzw. ein Projekt Unterscheidung Streichung/Hinzunehmen Extensions Erweiterung bzgl. verschiedener Gesichtspunkte (da unzureichende Berücksichtigung von gewissen Aspekten oder diese fehlen) Entwicklungsphilosophie Seriell Gewisse Aktionen, Aufgaben und Abschnitte laufen nacheinander ab Iterativ Wiederholen eines Vorganges bzw. einer Sequenz von Aktivitäten um sich schrittweise einem angestrebten Ergebnis zu nähern Mit jeder Iteration wird Qualität verbessert bzw. Umfang erweitert Inkrementell Entwicklung eines Systems in mehreren Schritten; Gesamtfunktionalität nimmt mit jedem Inkrement zu Parallel Zeitgleiches Ausführen zwei oder mehrerer Aktivitäten (um schneller voranzuschreiten); gemeinsame Vision & regelmäßige Kommunikation unumgänglich 32

33 Einordnung der Prozessmodelle 1/9 Vorgangsweise Ergebnisorientiert Aktivitätsorientiert Musterorientiert Musterorientiert Aktivitätsorientiert Ergebnisorientiert Scrum X XP X OOSP X Crystal Clear X 33

34 Einordnung der Prozessmodelle 2/9 Gewichtigkeit Heavy-weighted Light-weighted Heavy-weighted Light-weighted Scrum X XP X OOSP X Crystal Clear X 34

35 Einordnung der Prozessmodelle 3/9 Berechtigungsbasis Industrial-driven Community-driven Industrial-driven Community-driven Scrum X XP X OOSP X Crystal Clear X 35

36 Einordnung der Prozessmodelle 4/9 Ansatz Agil Traditionell Agil Traditionell Scrum X XP X OOSP X Crystal Clear X 36

37 Einordnung der Prozessmodelle 5/9 Adaption 1/4 Tailoring Scrum Hinsichtlich der Grund-prinzipien von Scrum bestehen wenig (z.b. Länge eines Sprints) bzw. keine (z.b. Auslassen von Meetings) Freiheiten bezüglich der Anpassung durch das Weglassen von Vorgaben. (jedoch geringe Vorgaben); kein Tool Extensions Können zwar die Einfachheit dieses Vorgehensmodells zunichte machen, bieten sich insbesondere aber bei der Software-Entwicklung selbst an. Hier kombiniert man mittlerweile XP mit Scrum und bezeichnet dieses neue, hybride Prozessmodell mit XBreed. 37

38 Einordnung der Prozessmodelle 6/9 Adaption 2/4 Tailoring XP Hinsichtlich dem Weglassen von gewissen Techniken, herrschen unterschiedliche Meinungen. Einerseits: XP ist nur dann XP wenn alle Techniken verwendet werden Andererseits: es können durchaus gewisse Teile (z.b. 40- Stunden Woche, Programmieren in Paaren, Metapher) ausgelassen werden und trotzdem entsteht ein gewisser Vorteil aus diesem Vorgehensmodell; kein Tool Extensions Sinnvoll z.b. bei größeren Projekten (mehr als Entwickler) bzw. verteilten Entwicklungsstandorten; XP- Techniken selber bieten sich bei anderen Prozessmodellen an 38

39 Einordnung der Prozessmodelle 7/9 Adaption 3/4 Tailoring OOSP Ausgehend von der höchsten Betrachtungsebene (den Phasen), erfolgt eine gezielte Anpassung an explizite Gegebenheiten (durch Modifizieren bzw. Erweitern der Process Patterns) wobei immer mehr ins Detail gegangen wird und die daraus resultierende Vorgehensstrategie inklusive aller dazugehörigen Festlegungen (z.b. Tätigkeiten, Artefakte, Rollen, ) entsprechend dokumentiert werden muss; kein Tool Extensions Über zusätzliche Process Patterns, wobei Anwender angehalten werden ihre entwickelten Patterns für andere zugänglich zu machen; Verwendung eines einheitlichen Beschreibungsschemas 39

40 Einordnung der Prozessmodelle 8/9 Adaption 4/4 Crystal Clear Tailoring Lediglich 3 von 7 Prinzipien müssen eingehalten werden; Je mehr Vorgaben hinzugenommen werden desto wahrscheinlicher ist jedoch ein positiver Abschluss des Projekts, womit die Anpassung eher von einem Kern aus erfolgt; kein Tool Extensions Können durch die geringen Vorgaben relativ leicht und in unterschiedlichen Teilbereichen beigefügt werden, wobei sich Crystal Clear gut für hybride Ansätze, insbesondere in Kombination mit XP, RUP und Scrum, eignet 40

41 Einordnung der Prozessmodelle 9/9 Entwicklungsphilosophie Vorgehensstrategie Scrum XP OOSP Crystal Clear Hintereinander Sprints; Am Ende eines Sprints (=Iteration, ca. 30 Tage) potentiell auslieferbare Version; Inkrementelles Vorgehen; Gemeinsame Vision (Sprint Goal) unterstützt parallele Arbeiten Iterative und inkrementelle Vorgehensweise (1 Tag bis max. 4 Monate für einen Zyklus); Fokussierung auf die Kommunikation fördert paralleles Wirken Die 4 Phasen werden seriell und Etappen innerhalb dieser iterativ durchlaufen; Inkrement nach Abschluss der Phasen; Parallele SW-Entwicklung wird explizit durch eigenen Pattern unterstützt Iterative und inkrementelle Software-Erstellung (ca. 1 bis max. 4 Monate für eine Iteration); Häufige Kommunikation unterstützt parallele Entwicklungsarbeiten 41

42 Ausblick Dienstag V-Modell 97 V-Modell XT Personal Software Process (PSP) Team Software Process (TSP) Einordnung der Prozessmodelle 42