1 tit10aik @ ws 2012 software-engineering ii vorgehensmodelle

1 TIT10AIK @ WS 2012

Software-Engineering II

Vorgehensmodelle


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


VorgehensmmodelleErfolgreich mit Objektorientierung

B. OestreichOldenbourg

390 Seiten

ISBN: 3-4862-5565-7 (Deutsch)


Agile EntwicklungAgile Software-Entwicklung kompakt

Carsten Dogs, Timo Klimmer

254 Seiten

ISBN: 3-8266-1503-4 (Deutsch)


ScrumScrum. Produkte zuverlässig und schnell entwickeln

Boris Gloger

392 Seiten

ISBN: 3-4464-1495-9 (Deutsch)


Test-Driven Development

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

10 TIT10AIK @ WS 2012

Phasen: Planung

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

11 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Phasen: Entwurf

» Detaillierte Modellierung der technischen Architektur» Als Implementierungsgrundlage» Auf Basis der bisher entstandenen Modelle

13 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Phasen: Einsatz/Wartung

» Auslieferung des fertigen Produktes zum Kunden

» Instandhaltung der Software

16 TIT10AIK @ WS 2012

Modellarten

» Prozessmodelle können in verschiedene Kategorien eingeordnet werden» Linear» Nichtlinear

»Iterativ»Evolutionär»Inkrementell»Nebenläufig

17 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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


Iterationen

20 TIT10AIK @ WS 2012

Evolutionär

» Iteratives Prozessmodell, bei dem in jeder Iteration alle Phasen durchlaufen werden

» Dadurch werden auch die ursprünglichen Ziele wieder angepasst


Iterationen

21 TIT10AIK @ WS 2012

Inkrementell

» Alle Iterationen bauen auf den Ergebnissen der früheren Iterationen auf

» Iterationen können unterschiedliche Schwerpunkte besitzen



...

22 TIT10AIK @ WS 2012

Nebenläufig

» Es wird an mehreren Phasen gleichzeitig gearbeitet

Analyse

Design

Coding

Testing

Einsatz

23 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Konkrete Modelle

25 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Wasserfallmodell

Analyse

Design

Implementierung

Test

Am Ende jeder Phase wird durch ein Review entschieden, ob die Ziele der Phase erreicht wurden

Erst wenn eine Phase erfolgreich abgeschlossen ist, kann der Übergang zur nächsten erfolgen

Lineares Modell

Lineares Modell

27 TIT10AIK @ WS 2012

Erweitertes Wasserfallmodell

Analyse

Design

Implementierung

Test

Zurückkehren in eine frühere Phase bei zu spät erkannten Fehlern möglich

28 TIT10AIK @ WS 2012

Wasserfallmodell

» Vorteile:» 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 TIT10AIK @ WS 2012

Spiralmodell

30 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Inception

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

33 TIT10AIK @ WS 2012

Elaboration

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

34 TIT10AIK @ WS 2012

Construction

» Deutsch: „Errichtung“» Funktionsumfang des Produktes wird evolutionär entwickelt

» Ende der Phase:» Fertiges Produkt, das ausgeliefert werden kann

35 TIT10AIK @ WS 2012

Transition

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

36 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Bewertung RUP» positiv:

» 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 TIT10AIK @ WS 2012

Agile Entwicklung

» Anforderungen an Software ändern sich kontinuierlich

» Agile Entwicklung versucht dies zu akzeptieren

» Definiert» Vier Werte» Zwölf Prinzipien» Praktiken» Methodiken

39 TIT10AIK @ WS 2012

Die agilen Werte

» Sollen helfen flexibler gegenüber Änderungen an den Anforderungen zu sein1. Individuen und Interaktionen

2. Funktionierende Software

3. Zusammenarbeit mit dem Kunden

4. Auf unbekannte Änderungen einstellen

40 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

„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

2. Funktionierende Software

42 TIT10AIK @ WS 2012

„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

3.Zusammenarbeit mit dem Kunden

43 TIT10AIK @ WS 2012

„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

4. Auf unbekannte Änderungen einstellen

44 TIT10AIK @ WS 2012

Die Agilen Prinzipien

» Definieren Strategien zur Einhaltung der Agilen Werte

1. Höchste Priorität: Bedürfnisse des Kunden2. Begrüße sich ändernde Anforderungen3. Häufige Auslieferungen der Software an den Kunden4. Enge Zusammenarbeit zwischen Kunden und Entwickler5. Mitarbeiter: Motivation und Vertrauen6. Bester Informationsaustausch: Direkte Kommunikation7. Funktionierende Software als Maßstab für Fortschritt8. Reguläre Arbeitszeiten, gleichbleibende Geschwindigkeit9. Wert auf gute Qualität und ein gutes Design legen10. Einfachere Lösungen sind bessere11. Sich selbst organisierende Teams12. Regelmäßige Selbstreflektion

45 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 SpielkartenJeder Spieler erhält einen kompletten Satz Karten

Online-Version:www.planningpoker.com

47 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Test-Driven Development1. Der Test-Code wird anhand der Spezifikation

geschrieben2. Test-Code compilieren (Nicht kompilierbar, da die

Implementierung fehlt)3. Gerade so viel Quellcode implementieren, dass die

Tests compilieren aber fehlschlagen4. Genau so viel Code entwickeln, dass die Tests

erfolgreich sind5. Duplikaten Code und unschöne Stellen refactoren6. 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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

PhasenExploration

Planung Entwicklung

Freigabe

Wartung Ende

Iterationen

52 TIT10AIK @ WS 2012

Exploration

» Einweisung des Kunden in eXtreme Programming

» Mit den Werkzeugen vertraut machen

» Verschiedene Ansätze probieren» Dauer: 2 Wochen bis 2 Monate

53 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

Entwicklungsphase

» Zu Beginn» 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

55 TIT10AIK @ WS 2012

Freigabephase

» Software wird in den Echtbetrieb übernommen

» Kunde prüft letztes Mal Software auf Mängel

» Letzte Performanceoptimierungen» Freischaltung des Systems

56 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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 TIT10AIK @ WS 2012

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!Vision!

Backlog

ProductOwnerProductOwner

60 TIT10AIK @ WS 2012

Zeitschätzung, Scrum-Team

» 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

Scrum-Team

Backlog

61 TIT10AIK @ WS 2012

Iterationen: der Sprint» Iterationen

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

62 TIT10AIK @ WS 2012

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

ProductOwnerProductOwner

AnwenderAnwender

ManagementManagement

Das TeamDas Team

Die TeilnehmerDie Teilnehmer

Sprint Plannin

g Meetin

g I

63 TIT10AIK @ WS 2012

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 Plannin

g Meetin

g II

64 TIT10AIK @ WS 2012

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“

DailyScrum11.45

–12.00

65 TIT10AIK @ WS 2012

Sprint Review

» Nach Ende des Sprints» Demo

» 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

SprintReview

66 TIT10AIK @ WS 2012

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 4

Implement new Images 2

Overall 20

67 TIT10AIK @ WS 2012

Burndown-Chart

» 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 Stundendefizit

1 tit10aik @ ws 2012 software-engineering ii vorgehensmodelle

Documents