Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014

Größe: px

Ab Seite anzeigen:

Download "Software Engineering. 4. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2014"

Adolph Reuter
vor 8 Jahren
Abrufe

1 Software Engineering 4. Methodologien Franz-Josef Elmer, Universität Basel, HS 2014

2 Software Engineering: 4. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten Entwerfen Implementieren Spezifizieren Konfigurieren Kommunizieren Planen Installieren Analysieren Testen

3 Software Engineering: 4. Methodologien 3 Softwareentwicklungsmethodologie A framework that is used to structure, plan, and control the process of developing an information system. (Wikipedia, Software development methodology, Stand ) Ein für die Softwareentwicklung angepasstes Vorgehensmodell bei der professionellen ("ingenieursmäßigen") Anwendungsentwicklung. (Wikipedia, Vorgehensmodell zur Softwareentwicklung, Stand ) Beispiele: Wasserfallmodell Spiralmodell Rational Unified Process (RUP) V-Modell extreme Programming (XP) Scrum Crystal Feature Driven Development (FDD)

system. (Wikipedia, Software development methodology, Stand 30.9.

4 Software Engineering: 4. Methodologien 4 Schwer- vs leichtgewichtige Methodologien Schwergewichtige (heavyweight) Methodologien: sind bürokratisch sind prozessorientiert produzieren viele Dokumente planen weit in die Zukunft planen detailliert sind wenig flexible auf Änderungen Beispiele: Wasserfall, Spiralmodell, RUP, V-Modell Leichtgewichtige (lightweight) Methodologien: sind unbürokratisch sind personenorientiert produzieren kaum Dokumente planen nur in die unmittelbare Zukunft betreiben keine detaillierte Planung reagieren schnell auf Änderungen Beispiele: XP, Scrum, RUP, V-Modell XT, FDD, Crystal

produzieren viele Dokumente planen weit in die Zukunft planen detailliert sind wenig flexible auf Änderungen Beispiele: Wasserfall, Spiralmodell, RUP,

5 Software Engineering: 4. Methodologien 5 Wasserfallmodel Ältestes aller Methodologien (Benington, 1956; Royse 1970, Boehm, 1981). Anforderunganalyse Architektur/Design Implementierung Testing Installation/Wartung Jede Stufe produziert genau definierte Ergebnisse (Dokumente, Code, etc.). Jede Stufe wird abgeschlossen bevor die nächste angegangen wird. Milestone: Zeitpunkt der den Übergang von einer Stufe auf die nächste definiert. Andere Stufen (feiner oder gröber) sind möglich.

Anforderunganalyse Architektur/Design Implementierung Testing Installation/Wartung Jede Stufe produziert genau

6 Software Engineering: 4. Methodologien 6 Wasserfallmodell: Nachteile Das Wasserfallmodell hat schwerwiegende Nachteile: 1. Spezifikationen müssen vollständig und logisch konsistent sein. 2. Spezifikationen müssen präzise formuliert werden. 3. Spezifikationen können später nicht mehr geändert werden. 4. Dokumentenlastig. 5. Auftraggeber und Benutzer sehen die Software erst wenn sie fast fertig ist. 6. Technische Hürden bei der Implementierung werden zu spät erkannt. 7. Big Bang Test: Die Software wird erst getestet wenn sie fertig ist. 8. Änderungen nach der Fertigstellung der Software sind oft nur mit sehr grossem Aufwand möglich.

Spezifikationen können später nicht mehr geändert werden. 4. Dokumentenlastig. 5. Auftraggeber und Benutzer sehen die Software erst wenn sie fast fertig ist. 6.

7 Software Engineering: 4. Methodologien 7 Spiralmodell Weiterentwicklung des Wasserfallmodells von Boehm 1986: Quelle: Wikipedia (Stand )

8 Software Engineering: 4. Methodologien 8 V-Modell Für die deutschen Bundesregierung entwickelte Methodologie: Erste Version 1988, weitere Versionen: V-Modell 97 (1997), V-Modell XT (2005) Quelle: Wikipedia (Stand )

9 Software Engineering: 4. Methodologien 9 Rational Unified Process (RUP) Entwickelt von der Firma Rational (heute IBM Rational) ca Quelle: Wikipedia (Stand )

10 Software Engineering: 4. Methodologien 10 Iterative Softwareentwicklung In vielen modernen Methodologien wird eine iterative Entwicklung bevorzugen. Eigenschaften iterativer Softwareentwicklung: Entwicklung in vorab festgelegten zeitlichen Zyklen. Jeder Zyklus (nicht unbedingt die ersten) endet mit einer lauffähigen und auslieferbaren Version der Software. Jede neue Version der Software soll für den Benutzer eine Verbesserung zur vorhergehenden Version sein, d.h. Bugs wurden gefixt, neue Features wurden implementiert.

Eigenschaften iterativer Softwareentwicklung: Entwicklung in vorab festgelegten zeitlichen Zyklen.

11 Software Engineering: 4. Methodologien 11 Agile Methodologien Zugeschnitten für Anforderungen, die sich laufend ändern. So wenig Dokumente wie möglich. Alles steckt im Code. Z.B. statt Tests verbal beschreiben lieber Code für automatische Tests schreiben. Agile Manifesto (2001): We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Beispiele: XP, Scrum, FDD, Crystal

Agile Manifesto (2001): We are uncovering better ways of developing software by doing it and helping others do it.

12 Software Engineering: 4. Methodologien 12 Scrum Begriff dem Rugby entlehnt Entwickelt von Takeuchi und Nonaka 1986 und Schwaber und Sutherland Quelle: Wikipedia (Stand )

13 Software Engineering: 4. Methodologien 13 Scrum Nicht nur für Softwareentwicklung anwendbar Definiert die Rahmenbedingungen für die Arbeit eines Teams Projektmanagement light Drei wichtige Rollen: Product Owner: Erstellt und priorisiert den Product Backlog, eine Liste mit Anforderungen (User Stories), Bug Reports und Change Requests. Entwicklungsteam: Team (der Softwareentwickler) welches diese Liste abarbeitet. Scrum Master: Sorgt dafür, dass das Entwicklungsteam in Ruhe arbeiten kann, und leitet diverse Meetings. Der ganze Entwicklungsprozess ist in Iterationen fester zeitlicher Länge, sogenannte Sprints, unterteilt. Länge eines Sprints: 1-4 Wochen

Rollen: Product Owner: Erstellt und priorisiert den Product Backlog, eine Liste mit Anforderungen (User Stories), Bug Reports und Change Requests.

14 Software Engineering: 4. Methodologien 14 Sprint In jedem Sprint gibt es folgende Meetings: Planning Meeting am Beginn: Das Entwicklungsteam erstellt den Sprint Backlog. Sprint Backlog: Einträge des Product Backlog mit der höchsten Priorität, welche das Team plant im Sprint erfolgreich abarbeiten zu können. Dazu erläutert der Product Owner die Einträge im Sprint Backlog, schätzt das Entwicklungsteam den Zeitaufwand, zerlegt das Team eventuell grössere Einträge in kleinere. Daily Scrum: Jedes Teammitglied informiert die anderen die erreichten Ziele seit dem letzten Daily Scrum, die geplanten Ziele bis zum nächsten Daily Scrum, die Hindernisse, die dabei im Wege stehen. Review Meeting am Ende: Präsentation der erledigten Backlog Einträge. Product Owner entscheidet, ob die Einträge im Backlog wirklich erledigt sind. Retrospective Meeting (nach dem Review Meeting): Reflexion des Sprintverlaufs durch das Entwicklungsteam. Diskussion von möglichen Verbesserungen des Verlaufs.

Dazu erläutert der Product Owner die Einträge im Sprint Backlog, schätzt das Entwicklungsteam den Zeitaufwand, zerlegt das Team eventuell grössere Einträge in kleinere.

15 Software Engineering: 4. Methodologien 15 extreme Programming (XP) Entwickelt von Beck, Cunningham und Jeffries in 90er (erstes Buch 1999). Ähnlich wie Scrum aber mit Konzepte, die spezifisch sind für Softwareentwicklung. Folgende XP Konzepte werden auch in anderen agilen Methodologien benutzt: User Stories Pair programming Collective code ownership Unit Tests Test driven development YAGNI ('You aren't gonna need it') Refactoring On-site customer Kurze Release Zyklen (2-3 Wochen)

Ähnlich wie Scrum aber mit Konzepte, die spezifisch sind für Softwareentwicklung.

16 Software Engineering: 4. Methodologien 16 XP: Stories und Tasks Anforderungen = Stories. Eine Story ist (handgeschriebener) Prosatext passt auf ein Kärtchen kann in einen Akzeptanztest umgesetzt werden ist aufwandsabschätzbar Der Kunde und das Entwicklerteam suchen zu Beginn eines Iterationszyklus eine oder mehrere Stories heraus. Die ausgesuchten Stories werden in Tasks zerlegt. Spezifikation = Tasks. Ein Task ist (handgeschriebener) Prosatext passt auf ein Kärtchen kann in einen Unit Tests umgesetzt werden ist aufwandsabschätzbar

aufwandsabschätzbar Der Kunde und das Entwicklerteam suchen zu Beginn eines Iterationszyklus eine oder mehrere Stories heraus.

17 Software Engineering: 4. Methodologien 17 XP: Pair Programming Code wird zu zweit an einem Computer geschrieben. Einer schreibt, der andere denkt nach und macht Vorschläge. Beide diskutieren Lösungen und wechseln ihre Rollen. Die Zusammensetzung der Paare wechselt laufend. Konsequenzen: Alle kennen den Code gleich gut Collective code ownership Fehler werden früher erkannt Erspart expliziten Code Review Vermeidet Codeduplikation Pair Programming funktioniert wenn alle denselben Coding Standard verwenden, alle Entwickler vergleichbare Fähigkeiten haben, jeder mit jedem kann.

Die Zusammensetzung der Paare wechselt laufend.

18 Software Engineering: 4. Methodologien 18 XP: Testing Automatisches Testen ist zentral in XP: Alle Tests können jederzeit ausgeführt werden Vor dem Release muss die Software alle Tests bestehen Akzeptanz Test (functional test, user test): Black-Box Test Überprüft User Story oft nicht automatisierbar Unit Test: White-Box Test überprüft Task wird von den Programmierern geschrieben Test driven development: 'Code a little, test a little' Nicht mehr implementieren als nötig um die Tests zu bestehen (YAGNI Prinzip)

Release muss die Software alle Tests bestehen Akzeptanz Test (functional test, user test): Black-Box Test Überprüft User Story

19 Software Engineering: 4. Methodologien 19 XP: Refactoring XP kennt Design aber keine Designphase. Refactoring: Design und Code verbessern ohne die Funktionalität zu ändern. Nach dem Refactoring müssen alle automatischen Tests erfolgreich durchlaufen. Refactoring besteht aus vielen kleinen definierten Schritten. Implementierung und Refactoring erfolgen quasi parallel.

Refactoring: Design und Code verbessern ohne die Funktionalität zu ändern.

20 Software Engineering: 4. Methodologien 20 XP: On-Site Customer Der Kunde bzw. ein Mitarbeiter des Kunden ist in das Entwicklungsteam integriert. Dieser Mitarbeiter muss gute Kenntnisse der Sache (Business) haben, die die Software bearbeiten soll. Er kann immer gefragt werden, wenn es Unklarheiten bezüglich der User Story gibt. Er konzipiert Akzeptanztests.

Dieser Mitarbeiter muss gute Kenntnisse der Sache (Business) haben, die die Software

21 Software Engineering: 4. Methodologien 21 XP: Release Release: Lauffähige und getestete Software Am Ende eines Iterationszyklus wird ein Release geliefert. Während eine Zyklus wird täglich (oder häufiger) ein Release gebaut.

22 Software Engineering: 4. Methodologien 22 Links Mehr über Scrum: Mehr über XP: Martin Fowler, The New Methodology ( )

Ähnliche Dokumente

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010

Software Engineering. 2. Methodologien. Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering 2. Methodologien Franz-Josef Elmer, Universität Basel, HS 2010 Software Engineering: 2. Methodologien 2 Wie den Entwicklungsprozess organisieren? Dokumentieren Verwalten Instandhalten