Software-Engineering II Vorgehensmodelle

Themenübersicht Objektorientierung Aspektorientierung Vorgehensmodelle UML Analyse- & Entwurfsmuster Objektorientiertes Testen Versionsverwaltung Refactoring Labor (Praktischer Teil)

Vorgehensmmodelle Erfolgreich mit Objektorientierung B. Oestreich Oldenbourg 390 Seiten ISBN: 3-4862-5565-7 (Deutsch)

Agile Entwicklung Agile Software-Entwicklung kompakt Carsten Dogs, Timo Klimmer 254 Seiten ISBN: 3-8266-1503-4 (Deutsch)

Scrum Scrum. Produkte zuverlässig und schnell entwickeln Boris Gloger 392 Seiten ISBN: 3-4464-1495-9 (Deutsch)

Test-Driven Development Kent Beck 240 Seiten ISBN: 0-321-1465-30 (Englisch)

Vorgehensmmodelle Untersuchung der Standish Group International Inc. 1995

Vorgehensmodelle Software-Entwicklung ist komplex Gründe für fehlgeschlagene Projekte Unvollständige, ungenaue Anforderungen Mangelnde Einbeziehung von Beteiligten Ressourcenmangel Unrealistische Erwartungen Mangelnde Unterstützung des Managements Sich häufig ändernde Anforderungen Mangelhafte Planung Veraltung des Konzeptes - Wird nicht mehr benötigt ... Vorgehensmodelle Komplexität entfernen Ansätze, die Entwicklung organisiert zu strukturieren Messbarkeit des Fortschrittes

} Phasen Entwicklung wird in Phasen aufgeteilt Planung Analyse Entwurf Implementierung Test Einsatz/Wartung Haben die meisten Vorgehensmodelle gemeinsam

Phasen: Planung Erstellung eines Lastenhefts Projektplanung Projektkalkulation Spezifikation in der (natürlichen) Sprache des Anwenders

Phasen: Analyse Erstellung eines Pflichenhefts Spezifikation der Anforderungen in der Sprache der Informatik Modellierung mit hohem Abstraktionsniveau Zur Kommunikation mit Vorgesetzten und Projektpartnern Als Grundlage für spätere Phasen

Phasen: Entwurf Detaillierte Modellierung der technischen Architektur Als Implementierungsgrundlage Auf Basis der bisher entstandenen Modelle

Phasen: Implementierung Implementierung der Software Anhand der in den in den vorhergehenden Phasen entstandenen Modelle Hier entsteht der Programmcode Physische Repräsentation der Lösung

Phasen: Test Testen des entstandenen Produktes anhand der Programm-Spezifikationen Manuelle Tests Automatisierte Tests Eventuell: Test-Modell, welches die Anwendungsfälle um Testfälle erweitert

Phasen: Einsatz/Wartung Auslieferung des fertigen Produktes zum Kunden Instandhaltung der Software

Modellarten Prozessmodelle können in verschiedene Kategorien eingeordnet werden Linear Nichtlinear Iterativ Evolutionär Inkrementell Nebenläufig

Lineare Prozessmodelle In jeder Phase wird exakt die eine Aufgabe erledigt Nachfolgende Prozessphasen beginnen erst wenn vorhergehende Phasen abgeschlossen sind Analyse Design Coding Testing

Nichtlineare Prozessmodelle Zu Beginn des Projektes sind die Anforderungen Unvollständig Können sich deutlich ändern Annahme: Es ist nicht möglich, eine Phase komplett abzuschließen bevor eine Neue beginnt

Iterativ Software wird in Iterationen erstellt Jede Iteration durchläuft eine, mehrere oder alle Phasen: Analyse, Entwurf, Implementierung, Test, Integration Dabei existiert nach jeder Iteration ein funktionsfähiges Programm Analyse Design Coding Testing Iterationen

Evolutionär Iteratives Prozessmodell, bei dem in jeder Iteration alle Phasen durchlaufen werden Dadurch werden auch die ursprünglichen Ziele wieder angepasst Analyse Design Coding Testing Iterationen

Inkrementell Alle Iterationen bauen auf den Ergebnissen der früheren Iterationen auf Iterationen können unterschiedliche Schwerpunkte besitzen Analyse Design Coding Testing ... Analyse Design Coding Testing

Nebenläufig Es wird an mehreren Phasen gleichzeitig gearbeitet Analyse Design Testing Coding Einsatz

Wahl des Modells Es gibt keinen idealen Prozess für alle Problemfälle Jede Vorgehensweise besitzt ihre Vor- und Nachteile Es ist wichtig, diese zu kennen Nach der Entscheidung für ein Modell ist es notwendig, es an die Gegebenheiten des Projekts anzupassen („Tayloring“)

Konkrete Modelle

Kein Prozess In vielen Projekten wird kein explizites Vorgehensmodell angewandt Anforderungen an das System wurden mehr oder weniger geklärt Programmierung und Testen in einem Zyklus so lange bis die Software einen akzeptablen Stand erreicht hat Vorteile: Kein Prozessoverhead, da keine Zeit für Design, Dokumentation, Standardisierung verbraucht wurde Keine Vorkenntnisse notwendig Nachteile: Meist kein Profit durch die Verwendung objektorientierten Designs Klassen entstehen bei der tatsächlichen Codierung Schlecht erweiter- und wartbare Systeme Geringe Möglichkeiten der Projektsteuerung (Risikomanagement, Messung des Fortschrittes) Fazit: Ausschließlich bei „Wegwerfprototypen“ und „Proof-Of-Concept“-Implementierungen geeignet

Wasserfallmodell Am Ende jeder Phase wird durch ein Review entschieden, ob die Ziele der Phase erreicht wurden Analyse Design Lineares Modell Implementierung Erst wenn eine Phase erfolgreich abgeschlossen ist, kann der Übergang zur nächsten erfolgen Test

Erweitertes Wasserfallmodell Analyse Design Implementierung Zurückkehren in eine frühere Phase bei zu spät erkannten Fehlern möglich Test

Wasserfallmodell Vorteile: Nachteile: Fazit: Aufgaben aller Phasen klar umrissen Geringer Prozess-Overhead Projektplanung sinnvoll einsetzbar Nachteile: Zurückkehren in frühere Phasen ist aufwendig Später Beginn der Implementierung Verzögertes Erkennen von Problemen Modell „scheitert“ bei verspäteten Änderungsanforderungen Fazit: Gut geeignet für Projekte mit stabilem Projektumfeld

Spiralmodell

Bewertung Spiral-Modell Nichtlinear, Iterativ-Inkrementell Weiterentwicklung von Wasserfall Risikobetrachtung in jeder Iteration Vorteile Flexibles Modell Risiken werden frühzeitig eliminiert Scheitern des Projektes früher erkennbar Nachteile Hoher Managementaufwand Risikien oft nicht einfach abschätzbar (zu geringes Wissen)

Rational Unified Process Vorgehensmodell & UML-Software von IBM Nichtlinear, Iterativ-Inkrementell Nebenläufig Iterationen werden in Phasen aufgeteilt Kurven stehen für Intensität in den Phasen. RUP verwendet stark UML für Planung. Model Driven Development.

Inception Deutsch: „Beginn“ Definition des Projektes Prüfung der Wirtschaftlichkeit Machbarkeitsstudien Häufig 1 Iteration

Elaboration Deutsch: „Ausarbeitung“ Anforderungsanalyse Analysemodell Design einer stabilen Software-Architektur Durchaus mehrere Iterationen bei größeren Projekten

Construction Deutsch: „Errichtung“ Funktionsumfang des Produktes wird evolutionär entwickelt Ende der Phase: Fertiges Produkt, das ausgeliefert werden kann

Transition Deutsch: „Übergang“ Übergabe der Software an den Anwender Schulung des Support-Personals

Iterationen Jede Phase besteht aus 1 oder mehreren Iterationen Anzahl und Dauer hängt von der Größe und Komplexität des Projekts ab Mittleres Projekt: 2-3 Monate pro Iteration Jede Iteration endet mit einem ausführbaren Produkt Schwerpunkte der Iterationen sind unterschiedlich Das Testen verteilt sich gleichmäßig auf die gesamte Projektlaufzeit

Bewertung RUP positiv: Negativ: Hoher Abstraktionsgrad durch Modellierung Risikomanagement: Weil in jeder Iteration alle Phasen durchlaufen werden ist es möglich, früh Probleme in einer Phase zu erkennen Da kontinuierlich getestet wird, wird die Arbeitsauslastung des Test-Teams gleichmäßiger Negativ: Projektaufwand häufig unterschätzt: tatsächliche Entwicklung ist oft doch komplexer Bei großen Projekten erheblicher Initialaufwand

Agile Entwicklung Anforderungen an Software ändern sich kontinuierlich Agile Entwicklung versucht dies zu akzeptieren Definiert Vier Werte Zwölf Prinzipien Praktiken Methodiken

Die agilen Werte Sollen helfen flexibler gegenüber Änderungen an den Anforderungen zu sein Individuen und Interaktionen Funktionierende Software Zusammenarbeit mit dem Kunden Auf unbekannte Änderungen einstellen

1. Individuen und Interaktionen „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“ Oft sind Prozesse und Werkzeuge im Vordergrund Mensch wird als austauschbare Ressource gesehen Fehleranalyse im Quellcode Mitarbeiter werden unmotiviert Werkzeuge geben eine nötige Struktur Aber: Mitarbeiter und deren Zusammenarbeit sind wichtiger als Werkzeuge Mitarbeiter werden als Experten in ihrem Fach und ihrer Selbstorganisation betrachtet Mitarbeiter können frei arbeiten, so wenige Prozesse wie möglich werden vorgegeben

2. Funktionierende Software „Funktionierende Software ist wichtiger als umfassende Dokumentation.“ Nur funktionierende Software hat einen reellen Wert Theoretische Modelle gewinnen erst an Wert, wenn sie in der Praxis sinnvoll verwendet werden Im Vorfeld keine übertriebenen Design-Dokumente erstellen ohne die Praxis zu kennen Begründung: Dokumente veralten wenn die Software sich verändert Oft ist in der Praxis keine Zeit für die Anpassung aller Dokumente Dokumente die nicht auf dem aktuellsten Stand sind, sind oft wertlos oder irreführend Das Notwendigste dokumentieren Gedankengänge statt Tatsachen darstellen Nicht welche Alternative gewählt wurde und wie sie funktioniert, sondern warum

3.Zusammenarbeit mit dem Kunden „Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.“ Bei Vertragsabschluss sind selten alle Anforderungen klar Der Kunde bemerkt während des Projekts, was er haben möchte Verträge sind oft mehrdeutig definiert Ausgeprägte Zusammenarbeit mit dem Kunden unumgänglich Entwickler und Kunden sollten aufeinander zugehen, die beste Lösung suchen anstatt auf Vertragsklauseln zu beharren

4. Auf unbekannte Änderungen einstellen „Sich auf unbekannte Änderungen einzustellen ist wichtiger als einem Plan zu folgen.“ Prädiktive Vorgehensweise (Wasserfall, ...) Vollständigen Plan ausarbeiten Ausgefeilte Ausweichpläne für spezielle Problemfälle entwerfen Adaptive Vorgehensweise (Agile Entwicklung, ...) Keine Annahmen treffen Vorkehrungen treffen, damit Anpassungen leichter gemacht werden können Abweichungen gehören zum Plan

Die Agilen Prinzipien Definieren Strategien zur Einhaltung der Agilen Werte Höchste Priorität: Bedürfnisse des Kunden Begrüße sich ändernde Anforderungen Häufige Auslieferungen der Software an den Kunden Enge Zusammenarbeit zwischen Kunden und Entwickler Mitarbeiter: Motivation und Vertrauen Bester Informationsaustausch: Direkte Kommunikation Funktionierende Software als Maßstab für Fortschritt Reguläre Arbeitszeiten, gleichbleibende Geschwindigkeit Wert auf gute Qualität und ein gutes Design legen Einfachere Lösungen sind bessere Sich selbst organisierende Teams Regelmäßige Selbstreflektion

Agile Praktiken Aktivitäten, die dabei helfen, die Prinzipien der Agilen Entwicklung umzusetzen Es gibt eine Vielzahl von Praktiken Beispiele Tägliche Stand-Up-Meetings Planning Poker Pair Programming Refactoring Unit Tests Test-Driven Development

Planning Poker Spiel um realistische Aufwandsabschätzungen für Features zu erhalten Alle Teammitglieder spielen mit Die Spieler decken zur gleichen Zeit die Karte mit ihrer Abschätzung auf Bei großen Unterschieden erläutern die jeweiligen Spieler ihre Ansichten Nach einer Diskussion werden die Karten erneut zur Schätzung verwendet Dies wird so lange gemacht, bis sich die Spieler einig sind Eine Sanduhr limitiert Diskussionen auf 2 Minuten Echte Planning Poker Spielkarten Jeder Spieler erhält einen kompletten Satz Karten Online-Version: www.planningpoker.com

Pair Programming Zwei Entwickler sitzen an einem Rechner und schreiben gemeinsam Quellcode Ein Entwickler hat die Tastatur und tippt Code ein, der andere denkt über die nächsten Schritte nach Oft werden auch zwei Tastaturen angeschlossen Die Rollen werden in kurzen Abständen gewechselt Pair Programming Partner werden regelmäßig gewechselt So erfolgt ein gleichmäßiger Wissensaustausch im Team Die Qualität der Software ist meist wesentlich besser

Test-Driven Development Der Test-Code wird anhand der Spezifikation geschrieben Test-Code compilieren (Nicht kompilierbar, da die Implementierung fehlt) Gerade so viel Quellcode implementieren, dass die Tests compilieren aber fehlschlagen Genau so viel Code entwickeln, dass die Tests erfolgreich sind Duplikaten Code und unschöne Stellen refactoren Wieder bei 1. beginnen Folge: Sehr gute Testabdeckung der Software Sicherstellung, dass die Software so funktioniert, wie sie spezifiziert war Vermeidet, dass „zu viel“ entwickelt wird

Agile Methodiken Kombination von Agilen Praktiken in ein Schema Eine Methodik ist agil, wenn sie folgende Eigenschaften besitzt Inkrementell Kooperativ Erfordert das Mitspielen aller Mitarbeiter Erfordert das Mitspielen des Auftraggebers Unkompliziert Leicht erlernbar Adaptiv Auch im letzten Moment sind noch große Änderungen am Produkt möglich

Methodik: eXtreme Programming Nichtlin., Inkrementell-Iterativ (Da agil!) Praktiken rund um die Programmierung und die Einbindung der Kunden Pair Programming Planning Poker Test-Driven Development Kunde vor Ort 40-Stunden-Woche Einsatzgebiete Für kleine Teams (< 10 Entwickler) Guter Informationsaustausch muss vorhanden sein Erfordert hochqualifizierte Mitarbeiter Mitarbeiter müssen die selbe Vision verfolgen

Phasen Iterationen Exploration Planung Entwicklung Freigabe Wartung Ende

Exploration Einweisung des Kunden in eXtreme Programming Mit den Werkzeugen vertraut machen Verschiedene Ansätze probieren Dauer: 2 Wochen bis 2 Monate

Planung Kunde und Entwickler spielen das Planning Game Legen fest, welche Features im nächsten Release sind Legen fest, wann die Features implementiert werden Dauer: 1-2 Tage

Entwicklungsphase Zu Beginn Entwicklung Am Ende Dauer: 1-4 Wochen Grobes Design festlegen Entwicklung Pair Programming Test-Driven Development Erfahrungen fürs nächste Planning Poker sammeln Rückfragen persönlich mit Entwicklern oder mit dem Kunden vor Ort klären Am Ende Prüfung, ob der Kunde mit den Entwicklungen zufrieden ist Falls ja, wechsel in die Freigabephase Falls nein, Change Requests für das nächste Planning Game Dauer: 1-4 Wochen Ca. 8-10 Iterationen

Freigabephase Software wird in den Echtbetrieb übernommen Kunde prüft letztes Mal Software auf Mängel Letzte Performanceoptimierungen Freischaltung des Systems

Wartungsphase Spät entdeckte Fehler werden behoben Neue Anforderungen werden implementiert Vorgehensweise ist die selbe wie in der Entwicklungsphase Erschwerte Bedingungen, da die Software bereits produktiv eingesetzt wird Sind größere Weiterentwicklungen gewünscht, kann wieder in die Planungsphase gewechselt werden

Endphase Kunde hat keine Wünsche mehr 10- bis 15-seitige Dokumentation Funktionen der Software Funktionsweise des Quellcode Ermöglicht nachkommenden Entwicklern die Einarbeitung in das System

Methodik: Scrum Nichtlin., Inkrementell-Iterativ (Agil!) Mehr als eine Methodik oder ein Prozessmodell Mittel zur Projektsteuerung Nicht notwendigerweise nur für die IT Ideal: Bis zu 10 Teammitglieder Experten in ihrem Bereich Sehr selbstorganisiert Gemischte Teams (Entwickler, Designer, DB-Experten, IT-Operations, ...) Bietet hohe Transparenz Deckt Schwächen in der Team- und Management-Zusammenarbeit auf

Product Owner, Backlog Hat die Idee für das Projekt Überarbeitet die Idee und formuliert sie als „Product Vision“ Erarbeitet die Liste der Produkt-Funktionalitäten „Product Backlog Items“ Alleine oder zusammen mit dem Team Aus dieser Liste wird das Product Backlog erstellt Die Punkte auf dieser Liste werden sortiert nach dem zu erwartenden Gewinn/Nutzen Vision! Backlog Product Owner

Zeitschätzung, Scrum-Team Personen, die notwendig sind, Backlog Items in „usable software“ zu verwandeln Programmierer Designer Datenbanken-Spezialisten Schätzt den Aufwand für jedes Backlog-Item Die Schätzung wird dem Product Owner mitgeteilt Dadurch weiß der Product Owner, welche Kosten ihn erwarten Alle Beteiligten im Prozess wissen über die geplanten Features Bescheid Backlog Scrum-Team

Iterationen: der Sprint Werden „Sprints“ genannt Zeitlich klar abgegrenzt Dauer: 2-4 Wochen Nach jeder Iteration entsteht eine Version, die funktionsfähig ist „usable code“

Sprint Planning Meeting 1 Wie viele und welche Backlog Items werden entwickelt? Instruktionen geben und Ziele für alle klar setzen Heraus kommt das Selected Product Backlog: Elemente, die tatsächlich entwickelt werden Sprint Planning Meeting I Anwender Das Team Die Teilnehmer Product Owner Management

Sprint Planning Meeting 2 Das Team bespricht, wie die Elemente des Selected Product Backlog umgesetzt werden können Besprechung des Software-Design und der Architektur Ausarbeitung der Backlog Items Es entsteht das Sprint Backlog Liste aller Aufgaben, die erledigt werden müssen um die einzelnen Backlog Items zu erfüllen Sprint Planning Meeting II

Daily Scrum Teammitglieder stimmen täglich die Aufgaben untereinander ab Diskussionspunkte Erreichtes seit dem letzten Daily Scrum Ziele bis zum nächsten Daily Scrum Welche Hindernisse waren mir im Weg? Die Teammitglieder suchen selbst aus, welche Sprint Backlog Items sie abarbeiten wollen Oft werden diese Meetings im Stehen gehalten, um die Mitarbeiter zu zwingen, die Dauer zu begrenzen „Stand-up Meeting“ Daily Scrum 11.45 – 12.00

Sprint Review Nach Ende des Sprints Demo Retrospektive: Fertiggestellte Funktionalität wird anhand von „usable software“ vorgestellt Führt zu neuen Ideen Retrospektive: Optimierung der eigenen Arbeitsprozesse Kontinuiertliches Hinterfragen der Vorgehensweise Ermöglicht das Lernen aus Fehlern Sprint Review

Burndown-Chart Daily Scrum Meeting Jeder Mitarbeiter berichtet den aktuellen Fortschritt Verbleibender Aufwand des Backlog Items = Entwicklungszeit in Stunden Verbleibender Aufwand für den Abschluss des Sprints = Summe der Aufwände aller Backlog Items Kann auch für das komplette Product Backlog angewendet werden Task Remaining Effort (h) Optimize Login 10 Add new language 4 Create new Images Implement new Images 2 Overall 20

Burndown-Chart Scrum macht Probleme frühzeitig deutlich Nach jedem Daily Scrum Meeting wird der verbleibende Aufwand in ein Diagramm aufgetragen Verbindet man den ursprünglichen Aufwand mit dem aktuellen Aufwand zu einer Geraden, ergibt der Wert der Geraden am Tag des Sprint-Endes den voraussichtlichen Sprint-Abschluss Scrum macht Probleme frühzeitig deutlich Die Kurve kann ansteigen, wenn erkannt wird, dass Entwicklungen länger dauern werden als geplant 5 Stunden defizit