Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 WS 2012 Software-Engineering II Vorgehensmodelle.

Ähnliche Präsentationen


Präsentation zum Thema: "1 WS 2012 Software-Engineering II Vorgehensmodelle."—  Präsentation transkript:

1 1 WS 2012 Software-Engineering II Vorgehensmodelle

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

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

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

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

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

7 7 WS 2012 Vorgehensmmodelle »Untersuchung der Standish Group International Inc. 1995

8 8 WS 2012 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 9 WS 2012 Phasen »Entwicklung wird in Phasen aufgeteilt »Planung »Analyse »Entwurf »Implementierung »Test »Einsatz/Wartung } Haben die meisten Vorgehensmodelle gemeinsam

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

11 11 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 12 WS 2012 Phasen: Entwurf »Detaillierte Modellierung der technischen Architektur »Als Implementierungsgrundlage »Auf Basis der bisher entstandenen Modelle

13 13 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 14 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 15 WS 2012 Phasen: Einsatz/Wartung »Auslieferung des fertigen Produktes zum Kunden »Instandhaltung der Software

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

17 17 WS 2012 Lineare Prozessmodelle »In jeder Phase wird exakt die eine Aufgabe erledigt »Nachfolgende Prozessphasen beginnen erst wenn vorhergehende Phasen abgeschlossen sind Analyse DesignCoding Testing

18 18 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 19 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 Analyse DesignCoding Testing Iterationen

20 20 WS 2012 Evolutionär »Iteratives Prozessmodell, bei dem in jeder Iteration alle Phasen durchlaufen werden »Dadurch werden auch die ursprünglichen Ziele wieder angepasst Analyse DesignCoding Testing Iterationen

21 21 WS 2012 Inkrementell »Alle Iterationen bauen auf den Ergebnissen der früheren Iterationen auf »Iterationen können unterschiedliche Schwerpunkte besitzen Analyse DesignCoding Testing Analyse DesignCoding Testing...

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

23 23 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 24 WS 2012 Konkrete Modelle

25 25 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 26 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

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

28 28 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 29 WS 2012 Spiralmodell

30 30 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 31 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 32 WS 2012 Inception »Deutsch: Beginn »Definition des Projektes »Prüfung der Wirtschaftlichkeit »Machbarkeitsstudien »Häufig 1 Iteration

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

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

35 35 WS 2012 Transition »Deutsch: Übergang »Übergabe der Software an den Anwender »Schulung des Support-Personals

36 36 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 37 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 38 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 39 WS 2012 Die agilen Werte »Sollen helfen flexibler gegenüber Änderungen an den Anforderungen zu sein 1.Individuen und Interaktionen 2.Funktionierende Software 3.Zusammenarbeit mit dem Kunden 4.Auf unbekannte Änderungen einstellen

40 40 WS 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 41 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 42 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 43 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 44 WS 2012 Die Agilen Prinzipien »Definieren Strategien zur Einhaltung der Agilen Werte 1.Höchste Priorität: Bedürfnisse des Kunden 2.Begrüße sich ändernde Anforderungen 3.Häufige Auslieferungen der Software an den Kunden 4.Enge Zusammenarbeit zwischen Kunden und Entwickler 5.Mitarbeiter: Motivation und Vertrauen 6.Bester Informationsaustausch: Direkte Kommunikation 7.Funktionierende Software als Maßstab für Fortschritt 8.Reguläre Arbeitszeiten, gleichbleibende Geschwindigkeit 9.Wert auf gute Qualität und ein gutes Design legen 10.Einfachere Lösungen sind bessere 11.Sich selbst organisierende Teams 12.Regelmäßige Selbstreflektion

45 45 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 46 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 Spielkarten Jeder Spieler erhält einen kompletten Satz Karten Online-Version:

47 47 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 48 WS 2012 Test-Driven Development 1.Der Test-Code wird anhand der Spezifikation geschrieben 2.Test-Code compilieren (Nicht kompilierbar, da die Implementierung fehlt) 3.Gerade so viel Quellcode implementieren, dass die Tests compilieren aber fehlschlagen 4.Genau so viel Code entwickeln, dass die Tests erfolgreich sind 5.Duplikaten Code und unschöne Stellen refactoren 6.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 49 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 50 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 51 WS 2012 Phasen Exploration PlanungEntwicklung Freigabe WartungEnde Iterationen

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

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

56 56 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 57 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 58 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 59 WS 2012 Product Owner, Backlog »Hat die Idee für das Projekt »Überarbeitet die Idee und formuliert sie alsProduct 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 Product Owner

60 60 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 61 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 62 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 Product Owner Product Owner Anwender Management Das Team Die Teilnehmer Sprint Planning Meeting I

63 63 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 Planning Meeting II

64 64 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 Daily Scrum – 12.00

65 65 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 Sprint Review

66 66 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 TaskRemaining Effort (h) Optimize Login10 Add new language4 Create new Images4 Implement new Images2 Overall20

67 67 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 Stunden defizit


Herunterladen ppt "1 WS 2012 Software-Engineering II Vorgehensmodelle."

Ähnliche Präsentationen


Google-Anzeigen