Software-Engineering II

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: 3-4862-5565-7 (Deutsch)

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

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

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

7. Untersuchung der Standish Group International Inc. 1995 Vorgehensmmodelle

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. Entwicklung wird in Phasen aufgeteilt Planung Analyse Entwurf Implementierung Test Einsatz/Wartung Phasen } 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: • 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: • 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: • www.planningpoker.com

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. 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 Test-Driven Development

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