4. Vorgehensmodelle 4.1 Phasen der Software

Transcrição

4. Vorgehensmodelle
Herausforderungen der SW-Entwicklung
4.1
4.1 Phasen der Software-Entwicklung
4.2 Wasserfallmodell
4.3 Prototypische Entwicklung
4.4 Iterative Entwicklung
4.5 Iterativ-inkrementelle Entwicklung
4.6 Allgemeines V-Modell
4.7 Das V-Modell der Bundesrepublik Deutschland
4.8 Rational Unified Process
4.9 Agile Vorgehensmodelle
4.10 Scrum
4.11 Extreme Programming
Software-Engineering Projekt
Prof. Dr. Stephan Kleuker
81
Die Phasen der SW- Entwicklung
Software-Systeme sind heutzutage verteilte
Anwendungen
– Anschluss an existierende Software (z.B. SAP, MS
Office, bestehende Unternehmenssoftware...)
– Integration neuer Komponenten in existierende
Systeme
– Erweiterung existierender Systeme
eigene
Komponenten
neues System
?
?
?
Legacy Systeme
• Erhebung und Festlegung des
Anforderungsanalyse
WAS mit Rahmenbedingungen
Anforderungsanalyse
• Klärung der Funktionalität und
Grobdesign
der Systemarchitektur durch
erste Modelle
• Detaillierte Ausarbeitung der
Feindesign
Komponenten, der Schnittstellen,
Datenstrukturen, des WIE
• Ausprogrammierung der
Implementierung
Programmiervorgaben in der
Zielsprache
• Zusammenbau der Komponenten,
Test und Integration
Nachweis, dass Anforderungen
erfüllt werden, Auslieferung
?
?
Systeme
anderer Anbieter
82
Wasserfallmodell
4.2
Systeme an
anderen Standorten
83
Grobdesign
Feindesign
Implementierung
Merkmale:
Phasen werden von oben nach unten
durchlaufen
Vorteile:
- Plan auch für Nichtexperten verständlich
- einfache Meilensteinplanung
- lange Zeit am häufigsten eingesetzt
Nachteile:
- Anforderungen müssen 100%-ig sein
- späte Entwicklungsrisiken werden spät
erkannt
- Qualität des Design passt sich Zeitplan an
Optimierung:
es ist möglich, in die vorherige Phase zu
springen
84
Prototypische Entwicklung
4.3
Anforderungsanalyse
Anforderungsanalyse
Grobdesign
Grobdesign
Feindesign
Feindesign
Implementierung
Implementierung
Test und
Integration
Prototyp
Iterative Entwicklung
Merkmale:
- potenzielle Probleme frühzeitig
identifiziert,
- Lösungsmöglichkeiten im Prototypen
gefunden, daraus Vorgaben abgeleitet
Vorteile:
- frühzeitige Risikominimierung
- schnelles erstes Projektergebnis
Nachteile:
- Anforderungen müssen fast 100%-tig
sein
- Prototyp (illegal) in die Entwicklung
übernommen
- Kunde erwartet schnell Endergebnis
Optimierung:
es ist möglich, in die vorherige Phase
zu springen
85
Iterativ Inkrementelle Entwicklung (State of the Art)
4.5
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
4.4
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Merkmale:
- Erweiterung der Prototypidee; SW wird in
Iterationen entwickelt
- In jeder Iteration wird System weiter verfeinert
- In ersten Iterationen Schwerpunkt auf Analyse
und Machbarkeit; später auf Realisierung
große Vorteile:
- dynamische Reaktion auf Risiken
- Teilergebnisse mit Kunden diskutierbar
Nachteile im Detail:
- schwierige Projektplanung
- schwierige Vertragssituation
- Kunde erwartet zu schnell Endergebnis
- Kunde sieht Anforderungen als beliebig
änderbar
86
Fertigstellung mit Iterationen
Merkmal:
- Projekt in kleine Teilschritte zerlegt
- pro Schritt neue Funktionalität
(Inkrement) + Überarbeitung
existierender Ergebnisse (Iteration)
- n+1-ter Schritt kann Probleme des nten Schritts lösen
Vorteile:
- siehe „iterativ“
- flexible Reaktion auf neue funktionale
Anforderungen
Nachteile:
- siehe „iterativ“ (etwas verstärkt)
1.
Iterationen
2.
3.
4.
Anforderungsanalyse
Grobdesign
Feindesign
Implementierung
Bsp.: vier Inkremente
Optimierung/Anpassung:
Anforderungsanalyse am Anfang
intensiver durchführen
0%
87
Fertigstellungsgrad
100%
88
Bekanntheit von Vorgehensmodellen
Struktur komplexer Vorgehensmodelle
71
63
19
S p ira lm o de ll
52
26
In kre m e ntelle E n tw icklun g
45
17
E vo lutio nä re s P rototyping
R U P (R a tio n a l U n ified P rocess)
ke in es die se r M o de lle
• Aktuelle Vorgehensmodelle, wie
V-Modell XT des Bundes
(Rational) Unified Process
OEP (Object Engineering Process)
enthalten Aktivitäten (was soll gemacht werden), Rollen (wer ist
wie an Aktivität beteiligt) und Produkte (was wird benötigt; bzw.
ist Ergebnis)
• es gibt Vorschläge für typische Anwendungsszenarien, wie
Aktivitäten zu verknüpfen sind
• Rahmenwerke, am Anfang eines Projekts muss
(werkzeuggestützt) bestimmen, welche Aktivitäten, Rollen,
Produkte und Reihenfolgen von Aktivitäten für das individuelle
Projekt relevant sind (tailoring, d. h. „zurecht schneidern“,
benötigt viel Erfahrung)
24
V -M o d ell
E xtrem e P ro gram m in g
4.6
41
W asse rfallm o d e ll
41
4
39
15
32
g e n u tzte M o d e lle
b e ka n n te M o d e lle
20
11
Quelle: Softwareentwicklung läuft nicht auf Zuruf, Computer Zeitung Nr. 46/05
89
allgemeines V-Modell
90
V-Modell des Bundes
4.7
Validierung
Anforderungsdefinition
manuelle
Prüfung
Validierung
Funktionaler
Systementwurf
manuelle
Prüfung
Validierung
Technischer
Systementwurf
KomponentenSpezifikation
manuelle
Prüfung
Konstruktion
manuelle
Prüfung
• Regelung der Softwarebearbeitung (im Bereich der
Bundeswehr, des Bundes und der Länder)
Abnahmetest
• einheitliche und (vertraglich) verbindliche Vorgabe von
Systemtest
– Aktivitäten und
Integrationstest
– Produkten (Ergebnissen),
• Historie: V-Modell 92 (Wasserfall im Mittelpunkt), Überarbeitung
V-Modell 97 (Anpassung an inkrementelle Ideen (W-Modell);
Forderung nach zu früher Festlegung von Anforderungen)
Validierung Komponenten-
test
• aktuell: V-Modell XT (eXtreme Tailoring), neuer Erstellung mit
Fokus auf Verhältnis von Auftragnehmer und Auftraggeber
(starker akademischer Einfluss bei Entwicklung)
Programmierung
Integration
Anmerkung: wird iterativ / inkrementell
zum W-Modell
91
92
Struktur des V-Modell XT
Produktorientierung im V-Modell XT
http://www.v-modell-xt.de
• Eine Projektdurchführungsstrategie definiert die Reihenfolge
der im Projekt zu erreichenden Projektfortschrittsstufen; nutzt
Entscheidungspunkte (go, no go)
• Produkte stehen im Mittelpunkt, sie sind DIE Projektergebnisse
• Projektdurchführungsstrategien und Entscheidungspunkte
geben die Reihenfolge der Produktfertigstellung und somit die
grundlegende Struktur des Projektverlaufs vor
• Die detaillierte Projektplanung und -steuerung wird auf der
Basis der Bearbeitung und Fertigstellung von Produkten
durchgeführt
• Für jedes Produkt ist eindeutig eine Rolle verantwortlich und im
Projekt dann eine der Rolle zugeordnete Person
• Die Produktqualität ist überprüfbar durch definierte
Anforderungen an das Produkt und explizite Beschreibungen
der Abhängigkeiten zu anderen Produkten
für V-Modell XT-Informationen:
Copyright Reserved © Bundesrepublik Deutschland 2004.
93
Entscheidungspunkte des V-Modells XT
Schnittstelle Auftraggeber / Auftragnehmer
Organisationsspezifisches V-Modell
Systementwicklung
Projekt
definiert
Vorgehensmodell
analysiert
Verbesserung
Vorgehensmodell
konzipiert
Verbesserung
Vorgehensmodell
realisiert
Anforderungen
festgelegt
Geamtprojekt
aufgeteilt
Projekt
ausgeschrieben
94
Angebot
abgegeben
Gesamtfortschritt überprüft
Projektfortschritt überprüft
Projekt
beauftragt
Iteration
geplant
System spezifiziert
System entworfen
Feinentwurf abgeschlossen
Beispiel: Projektdurchführungsplan
relevant für alle V-Modell-Projekte
Projekt
genehmigt
Abnahme
erfolgt
Projekt
abgeschlossen
Lieferung durchgeführt
System integriert
Systemelemente realisiert
(Systementwicklungsprojekt eines Auftraggebers (AG))
95
96
Beispielaktivität: Anforderungen festlegen
Rational Unified Process (RUP)
4.8
Phasen
Disziplinen
Konzeption
Konstruktion
Ausarbeitung
Inbetriebnahme
Geschäftsprozessmodell
Anforderungsanalyse
Design
Implementierung
Test
Installation
Konfigurations- und
Änderungsmanagement
Projektmanagement
Projektumfeld
Start
aus IBM/Rational:
Rational Unified Process
97
Phasen des RUP
Konzeption
Iteration 1
Konzeption Ausarbeitung Ausarbeitung Ausarbeitung Inbetrieb
Iteration 2
Iteration 1
Iteration 2
Iteration n
Iteration 1
Inbetrieb
Iteration 2
Iterationen
98
Struktur des RUP
• inception (Konzeption): Ermittlung zentraler
Anforderungen, Projektumfang definieren, erste
Entwurfs- und Implementierungsansätze,
Identifikation der Projektrisiken und Aufwände
• elaboration (Ausarbeitung): stabile, möglichst
vollständige Anforderungen, Entwurfsspezifikation,
detaillierter Projektplan mit aktivem
Risikomanagement
• construction (Konstruktion): Implementierung,
Integration, auslieferbare Version
• transition (Inbetriebnahme): Beta-Test, Endabnahme,
Inbetriebnahme, Endlieferung
Software
Engineering
Process
bearbeitet
Rolle
strukturiert
durch
Disziplin
beschrieben
in
Arbeitsablauf
erstellt mit Hilfe
von
Ergebnis
Eingabe
verantwortlich für
Hilfsmittel
verfeinert
durch
Aktivität
Checkliste
Arbeitsablaufdetails
Produkt
(Artifact)
Hilfsmittel
Strukturbeschreibung
(Template)
Werkzeuganleitung
Hilfsmittel
Bericht
beschrieben durch
99
100
Kritik an klassischen Vorgehensmodellen
Arten von agilen Prozessen (1/2)
4.9
• generell: Methoden lernen von einander; es gibt
nicht die eine agile Methode
• Es müssen viele Dokumente erzeugt und gepflegt
werden
• Eigene Wissenschaft Modelle wie V-Modelle und
RUP zu verstehen und zurecht zu schneidern
• Prozessbeschreibungen hemmen Kreativität
• Anpassung an neue Randbedingungen, z. B. neue
Technologien (Web-Services) in Prozessen und
benutzten Werkzeugen ist extrem aufwändig
• Variante 1: Beschreibung auf Metaprozessebene
– Grundregeln zur Projektorganisation
– Vorgehensweisen in Projekten werden vom Team
festgelegt
– Beispiele:
• Scrum (u. a. Ken Schwaber, Jeff Sutherland) [s.
Folien]
• Crystal Methodenfamilie (Alistair Cockburn)
• alternativer Ansatz: „Menschen machen Projekte
erfolgreich, traue den Menschen“
=>
agile Prozesse (vorherige Name:
leichtgewichtige Prozesse)
101
Arten von agilen Prozessen (2/2)
102
Agiles Manifest (Februar 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:
• Variante 2: Konkrete Prozessbeschreibungen
– Für verschiedene Phasen der SoftwareEntwicklung werden konkrete Verfahren
vorgeschlagen
– Abhängigkeiten der Verfahren werden
dokumentiert („wer A macht muss auch B
machen“); Möglichkeiten zur individuellen
Optimierung
– Beispiele:
• eXtreme Programming (XP) (u. a. Kent Beck,
Ward Cunningham) [s. Folien]
• Dynamic Systems Development Method
(Konsortium)
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.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick,
Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org
103
104
Scrum (1/2)
Scrum (2/2)
4.10
• Projektplanung: Eng mit dem Kunden werden Hauptaufgaben
identifiziert (Stack mit product backlog)
• Hauptaufgaben können auch Test von Technologien und die
Entwicklung von Prototypen sein
• Scrum Team schätzt Aufwände; wählt mit Kunden aus product
backlog wichtigste nächste Aufgaben für nächste Iteration
(heißt sprint) aus
• Jeder sprint dauert ca. 30 Tage; hat sprint backlog mit
priorisierten Aufgaben; sorgt für nicht unterbrochene
Arbeitsphase des Teams (Scrum Master kann abbrechen)
• Nach jedem sprint Analyse mit dem Kunden, was wurde
erreicht; wie kann Projekt verbessert werden [zurück Planung]
• siehe auch: www.controlchaos.com
• („Scrum“: Gedränge beim Rugby)
• Scrum Teams mit maximal 7 Personen mit unterschiedlichen
Fähigkeiten, einem Leiter (Scrum Master)
• Bei größeren Teams: mehrere Teilteams durch Scrum Master
koordiniert
• Zentrales Steuerungselement: Scrum meetings; jeden Tag 15
Minuten:
– was habe ich seit letztem Meeting gemacht?
– was werde ich bis zum nächsten Meeting machen?
– was hat meine Arbeit behindert?
• Scrum Master ist Koordinator; beseitigt Behinderungen;
kommuniziert im Unternehmen
• Arbeitsablauf im Team wird vom Team selbst geregelt
105
Scrum - Überblick
•
•
Product
backlog
sprint
backlog
Aufgabe 1
Teilaufgabe 1
Arbeitstag
Aufgabe 2
Teilaufgabe 2
...
...
•
Scrum-Meeting
•
•
StatusReview
•
sprint
30 Arbeitstage
•
•
•
106
Ideen des Extreme Programming (XP) (1/3)
4.11
Planung
für sprint
107
Planning
User stories are written
Release planning creates
the schedule
Make frequent small
releases
The Project Velocity is
measured
The project is divided into
iterations
Iteration planning starts
each iteration
Move people around
A stand-up meeting starts
each day
Fix XP when it breaks
Designing
Simplicity
Choose a system metaphor
Use CRC cards for design
sessions
• Create spike solutions to
reduce risk
• No functionality is added
early
• Refactor whenever and
wherever possible
•
•
•
108
•
•
•
•
•
•
•
•
•
Coding
The customer is always
available
Code must be written to
agreed standards
Code the unit test first
All production code is pair
programmed
Only one pair integrates
code at a time
Integrate often
Use collective code
ownership
Leave optimization till last
No overtime
•
•
•
•
Testing
All code must have unit
tests
All code must pass all unit
tests before it can be
released
When a bug is found tests
are created
Acceptance tests are run
often and the score is
published
109
• agile Methoden haben viele Innovationen in verstaubte SWEntwicklungsprozesse gebracht (etwas Neues; viel neu
arrangiertes)
• Einsetzbarkeit hängt stark von technischen und menschlichen
Fähigkeiten des Teams ab
• große Erfolge möglich, wenn Dream-Team gefunden
• Aufpassen bei Beratungs-Hype („XP ist die Zukunft“)
Hamburger Berater: Wir haben agile Methoden erfolgreich in
Versicherung X eingeführt und manifestiert
Projektleiter bei X: Haben neue Ideen zur Optimierung unseres
existierenden Prozesses genutzt; konkret übrig geblieben sind
Stand-Up-Meetings
• Agiles Manifest interessant für alle SW-Entwicklungsprozesse
• Ideen auf andere Ansätze übertragbar
• Überblick mit Kommentaren in Artikeln von J. Coldewey
http://www.coldewey.com/publikationen/Kolumne.html
Generell: Vorgehensmodell muss zum Projekt und den Menschen passen
neue User-Story
geänderte
Randbedingung
User
Stories
Anforderungen
Systemidee
Architekturansatz
Release- ReleaseIteration
plan
Planung
unklare
Annahmen
abgesicherte
Annahmen
Miniprototyp
(Spike)
Fehler
aktuelle
Version
nächste
Iteration
Akzeptanz
-tests
Kundenzustimmung
kleine
Releases
• Quelle der XP-Folien : www.extremeprogramming.org
• Varianten: z. B. in der Nutzung von Dokumentation (keine –
minimal)
Versuch einer Beurteilung von agilen Methoden
Testfälle
111
110

4. Vorgehensmodelle 4.1 Phasen der Software

Transcrição

Documentos relacionados

1.1 Anforderungen an Software

Agiles Vorgehen macht Programme besser

Aufgaben - DHBW Stuttgart

Rückschau - AutomatenMarkt

Software Engineering

Vorlesung „Embedded Software-Engineering im Bereich Automotive“

Einführung in die Programmiersprache C# Kapitel 1: C# Übersicht

Vortragsfolien

Kapitel 1 Einleitung

Grundlagen des Testens Kapitel 1 Einführung

Scheune - PORSCHE Klassik Stammtisch

060216 Audioline Produktlinien

V-Modell XT - Institut für Informatik

( PDF: 167,6 KB )