Software-Engineering II

Präsentation zum Thema: "Software-Engineering II"—  Präsentation transkript:

1 Software-Engineering II
Vorgehensmodelle

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

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

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

5 Scrum Scrum. Produkte zuverlässig und schnell entwickeln Boris Gloger
392 Seiten ISBN: (Deutsch)

6 Test-Driven Development
Kent Beck 240 Seiten ISBN: (Englisch)

7 Vorgehensmmodelle Untersuchung der Standish Group International Inc. 1995

8 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

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

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

11 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

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

13 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

14 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

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

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

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

18 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

19 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

20 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

21 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

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

23 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“)

24 Konkrete Modelle

25 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

26 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

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

28 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

29 Spiralmodell

30 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)

31 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.

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

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

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

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

36 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

37 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

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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 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: 

47 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

48 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

49 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

50 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

51 Phasen Iterationen Exploration Planung Entwicklung Freigabe Wartung
Ende

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

53 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

54 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 Iterationen

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

56 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

57 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

58 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

59 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

60 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

61 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“

62 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

63 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

64 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

65 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

66 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

67 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