Vorlesung „Softwaretechnologie“Wintersemester 2008 R O O T Ste se este 008
Kapitel 14 Kapitel 14. Softwareentwicklungsprozessmodelle
Einordnung
Bisher (Kap. 3-4): Womit arbeiten wir?i b d i hti A b it itt l t lltnur ein paar besonders wichtige Arbeitsmittel vorgezogen vorgestellt:
CVS/SVN, OOP, UML, OOM
Bisher (Kap. 5-11): Was tun wir? AktivitätenAnforderungen erfassen, entwerfen, implementieren, testen, ...Q lität i h V i lt P j kt tQualitätssicherung, Versionsverwaltung, Projektmanagement, ...
Nun (Kap 16-17): Wie tun wir es?Nun (Kap. 16 17): Wie tun wir es?Wie passt das alles zusammen?Was ist ein Softwareentwicklungsprozessmodell?
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-2 R O O T S
Überblick
Dieser Foliensatz (Kapitel 16): Software ProzessmodelleD W f ll d ll d i P blDas Wasserfallmodell und seine ProblemeIterative und inkrementelle Prozessmodelle
Nächster Foliensatz (Kapitel 17): Agile ProzessmodelleExtreme Programming
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-3 R O O T S
Typische Fragen zum Software-LebenszyklusLebenszyklus
Welche Aktivitäten soll ich für das Softwareprojekt auswählen?
Was sind die Produkte der Aktivitäten?
Was sind die Abhängigkeiten zwischen den Aktivitäten? Welche Aktivitäten hängen von welchen Produkten ab?gHängt das Systemdesign von der Analyse ab? Hängt die Analyse vom Design ab?
Wie soll ich die Aktivitäten planen?Soll die Analyse dem Design vorangehen? y g gKönnen Analyse und Design parallel ablaufen?Sollten sie iterativ ablaufen?
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-6 R O O T S
Aktivitäten (Beispiele)
Anforderungsanalyse Was ist das Problem?Anforderungsanalyse Was ist das Problem?
Systementwurf Was ist die Lösung?y
ProgrammentwurfWelche Mechanismen liefern die besteProgrammentwurf beste Lösung?
Implementierung Wie setzt sich die Lösung zusammen?zusammen?
Tests Ist das Problem gelöst?
Auslieferung Kann der Benutzer die Lösung verwenden?
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-7 R O O T S
Wartung Sind Verbesserungen notwendig?
Rollen und Teilprozesse
Software EntwicklungEntwicklung
<<include>> <<include>><<include>> <<include>>
<<include>>
Problem-definition
System-entwicklung
Systembetrieb
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-8 R O O T S
Kunde Projektmanager Entwickler Administrator Endnutzer
Produkte
Software Entwicklung
Lauffähiges SystemProblem Statement
Requirements AnalysisDocument Testhandbuch
System DesignDocument
Object DesignDocument
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-9 R O O T S
IEEE Standard 1074: Standard für den Software-LebenszyklusSoftware Lebenszyklus
IEEE Std 1074
Process Groups
Post-Life Cycle
Project Pre- Cross-
Post-Development
Develop-
Life Cycle Modeling
Management Development Development ment
> Installation> Selection > Operation &
Support> Maintenance> Retirement
of a life cycle model
> Project Initiation> Project Monitoring
& Control> Software Quality
> Concept Exploration
> System Allocation
> RequirementAnalysis
> Design> Implementation
> V & V> Configuration
Management> Documentation
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-10 R O O T S
Processes> Software Quality
ManagementAllocation > Implementation> Documentation
> Training
Modellierung von Abhängigkeiten in einem Software-Lebenszykluseinem Software Lebenszyklus
Problemdefinition Systementwicklung SystembetriebProblemdefinition Systementwicklung Systembetrieb
Markterschliessung Weiterentwicklung
Die Abhängigkeits-Beziehung kann verschiedenes bedeuten:Aktivität B hängt von Aktivität A abAktivität A muss vor Aktivität B erfolgen
Was ist richtig?gVerschiedene AntwortenVerschiedene Modelle von Aktivitäten und deren AbhängigkeitenVerschiedene Modelle des Lebenszyklus
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-13 R O O T S
Verschiedene Modelle des Lebenszyklus
Vorlesung „Softwaretechnologie“Kapitel 15: Softwareentwicklungsprozessmodelle R O O T Sap te 5 So t a ee t c u gsp o ess ode e
Wasserfallmodell
Das detaillierte Wasserfallmodell des
Projekt Initiierung
Software-LebenszyklusConceptExploration
System Allocation
Anforderungs-Anforderungsanalyse
Design g
Implementierung
Verifikation& Validation
Installation
B t i b &
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-15 R O O T S
Betrieb & Support
Für und Wider des Wasserfallmodells
Manager lieben WasserfallmodelleN tt M il t iNette MeilensteineKein Rückblick nötig (lineares System), jederzeit nur eine AktivitätFortschritt leicht zu prüfen : 90% codiert, 20% getestetp g
Aber, ...Softwareentwicklung ist iterativ
Während des Designs werden Probleme mit den Anforderungen festgestelltgWährend der Implementierung werden Design- und Anforderungsprobleme festgestelltWährend des Testens werden Implementierungs- Design- undWährend des Testens werden Implementierungs-, Design-, und Anforderungsfehler gefunden
SpiralmodellS t t i kl i t i ht liSystementwicklung ist nicht-linear
Problem-orientiertes Modell
Vorlesung „Softwaretechnologie“Kapitel 15: Softwareentwicklungsprozessmodelle R O O T Sap te 5 So t a ee t c u gsp o ess ode e
Spiralmodell
Das Spiralmodell (Boehm) befasst sich mit Iterationmit Iteration
Identifiziere die Risiken
Gib den Risiken Prioritäten
Entwickle und teste eine Reihe von Prototypen für die einzelnen Risiken… in der Reihenfolge fallenden Risikos bzw. fallender Priorität
Nutze das Wasserfallmodell zur Entwicklung jedes Prototyps (“Zyklus”)Nutze das Wasserfallmodell zur Entwicklung jedes Prototyps ( Zyklus )
Wenn ein Risiko erfolgreich beseitigt wurde, bewerte das Ergebnis des Zyklus und plane die nächste Runde
Wenn ein bestimmtes Risiko nicht beseitigt werden kann beende dasWenn ein bestimmtes Risiko nicht beseitigt werden kann, beende das Projekt sofort
Spiralmodell
Determine objectives,alternatives, & constraints
Evaluate alternatives,identify & resolve risks
i k
Riskanalysis
Riskanalysis
Riskanalysis
P t t 1Prototype2
Prototype3P1
Requirementsplan Software System
Product
Prototype1
Concept ofoperation
Requirements
Developmentplan
Requirementsvalidation
ProductRequirementsDesign
Code
DetailedDesign
P2
Develop & ver ifynext level productPlan next phase
Integrationplan
Designvalidation Unit Test
Integration & TestAcceptance
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-19 R O O T S
AcceptanceTest
Aktivitäten (“Runden”) in Boehm’s Spiralmodell
Die folgenden Aktivitäten verteilen sich über die Zyklen
Gehe in jedem Zyklus diese Schritte
Spiralmodell
verteilen sich über die Zyklen der Spirale
Concept of OperationsSoftware Requirements
SchritteBestimme Ziele, Alternativen, Nebenbedingungen
Software RequirementsSoftware Product DesignDetailiertes Design
Bewerte Alternativen, identifiziere und löse RisikenEntwickle und verifiziere den
CodeUnit TestIntegration und Test
PrototypPlane den nächsten Zyklus
AkzeptanztestImplementierung
Frühere Aktivitäten geschehenFrühere Aktivitäten geschehen in den inneren/initialen Zyklen, spätere in den äußeren Zyklen
Siehe Spirale auf der Seite
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-20 R O O T S
Siehe Spirale auf der Seite zuvor
Typen von Prototypen beim Spiralmodell
Illustrativer PrototypEntwickle das Userinterface mit einem Satz von AblaufplänenEntwickle das Userinterface mit einem Satz von Ablaufplänen„Implementiere“ ein Mock-Up mit einem UI-Builder (Visual C++, QT-Designer, Papierserviette, Bierdeckel, ...)Gut für den ersten Dialog mit dem KundenGut für den ersten Dialog mit dem Kunden
Funktionaler PrototypImplementiere und liefere ein lauffähiges System mit minimaler FunktionalitätDann füge Funktionalität hinzuDas jeweilige Risiko bestimmt die Reihenfolge
Explorations-Prototyp ("Hacken")Explorations Prototyp ( Hacken )Implementiere einen Teil des Systems, um mehr über die Anforderungen zu lernen. Gut für Brüche im Denkmuster
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-27 R O O T S
Gut für Brüche im Denkmuster
Typen des Prototyping (fortgesetzt)
Revolutionäres PrototypingA h “ ifi ti t t i ” tAuch “specification prototyping” genanntErmittle die Praxis beim Kunden mit einer Wegwerf-Version um die Anforderungen richtig zu bestimmen, dann baue das ganze System
Nachteil: Benutzer müssen einsehen das Funktionen des Prototypen teuer in der Implementierung sindBenutzer kann enttäuscht sein, weil ein Teil der Funktionalität des Prototyps in der späteren Implementierung nicht machbar ist
Evolutionäres Prototypingyp gDer Prototyp ist Basis für die Implementierung des finalen SystemsVorteil: Kurze Fertigstellungszeit
SNachteil: Kann nur benutzt werden, wenn das Zielsystem in der Sprache des Prototypen konstruiert werden kann
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-28 R O O T S
Die Grenzen des Wasserfall- und SpiralmodellsSpiralmodells
Keines von beiden befasst sich mit häufigen ÄnderungenD W f ll t t llt d h i Ph ll P bl i diDas Wasserfall unterstellt, dass nach einer Phase alle Probleme in dieser abgeschlossen sind und nicht wieder geöffnet werden könnenDas Spiralmodell kann mit Änderungen zwischen den Phasen umgehen,
Äaber nicht mit Änderungen während einer Phase
Was tun, wenn Änderungen häufiger erfolgen? (“Das einzig konstanteWas tun, wenn Änderungen häufiger erfolgen? ( Das einzig konstante ist die Änderung”)
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-30 R O O T S
Vorlesung „Softwaretechnologie“Kapitel 15: Softwareentwicklungsprozessmodelle R O O T Sap te 5 So t a ee t c u gsp o ess ode e
„Issue-Based Development“
Issue-Based Development
Ein System wird durch eine Sammlung von Problemen beschriebenP bl i d ff d hlProbleme sind offen oder geschlossenGeschlossene Probleme haben eine LösungGeschlossene Probleme können wieder geöffnet werden (Iteration!)
A_I2 A_I2
g ( )Probleme haben AbhängigkeitenDie geschlossenen Probleme sind die Basis des Systemmodells
Analyse-Issues
Design-Issues
Implementierungs-Issues
A_I1 D_I1
D I2
Impl_I1
Impl_I2
A_I2
A_I3
D_I2
Impl_I3D_I3
Impl_I3
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-32 R O O T S
Beispiel: Projekt mit nach Aktivitäten gruppierten Issues
Analyse-Issues
Design-Issues
Implementierungs-Issues
gruppierten Issues
A_I1
A_I2
D_I1
D_I2
Impl_I1
Impl_I2
A_I3
Impl_I3D_I3
Impl_I3
Legende (auf folgenden Seiten)Rot = offene issues“(noch zu bearbeiten)A I2 Rot „offene issues (noch zu bearbeiten)Grün = „geschlossene issues“(erledigt)
A_I2
A_I2
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-33 R O O T S
Issues im Wasserfallmodell: Analysephase
Analyse-Issues
Design-Issues
Implementierungs-Issues
Analysephase
A_I1
A_I2
D_I1
D_I2
Impl_I1
Impl_I2
A_I3
Impl_I3D_I3
Impl_I3
100-0% Offene Analyse-Issues
100% Offene Design-Issues
100% Offene Implem.-Issues
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-34 R O O T S
Issues im Wasserfallmodell: Designphase
Analyse-Issues
Design-Issues
Implementierungs-Issues
A_I1
A_I2
D_I1
D_I2
Impl_I1
Impl_I2
A_I3
Impl_I3D_I3
Impl_I3
0% Offene Analyse-Issues
100-0% Offene Design-Issues
100% Offene Implem.-Issues
Wasserfall
Design
Analyse
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-35 R O O T S
Issues im Wasserfallmodell: Designphase
Analyse-Issues
Design-Issues
Implemen.-Issues
A_I1
A_I2
D_I1
D_I2
Impl_I1
Impl_I2
A_I3
Impl_I3D_I3
Impl_I3
0% Offene Analyse-Issues
0% Offene Design-Issues
100-0% Offene Implem.-Issues
Wasserfall
Design
Analyse
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-36 R O O T S
Implementierung
Issues im Wasserfallmodell: Projekt fertig!
Analyse-Issues
Design-Issues
Implemen.-Issues
fertig!
A_I1
A_I2
D_I1
D_I2
Impl_I1
Impl_I2
A_I3
Impl_I3D_I3
Impl_I3
0% Offene Analyse-Issues
0% Offene Design-Issues
0% Offene Implem.-Issues
Wasserfall
Design
Analyse
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-37 R O O T S
Implementierung
Vorlesung „Softwaretechnologie“Kapitel 15: Softwareentwicklungsprozessmodelle R O O T Sap te 5 So t a ee t c u gsp o ess ode e
Bisher: Issue-basierte llustration eines Wasserfalls
Nun: „Richtiges“ Issue-Based Development
„Issue-Based Development“Analyse-Issues Design-Issues Implem.-Issues
A_I1 D_I1
D I2
Impl_I1
Impl_I2
y g per
atio
n 1
A_I2
A_I3
D_I2
Impl_I3D_I3
Impl_I3
Ite
A_I1 D_I1 Impl_I1
tion
2
A_I2
A_I3
D_I2Impl_I2
Impl_I3D_I3
I l I3
Itera
t
Impl_I3
A I1 D I1 Impl I13 A_I1 D_I1
D_I2
Impl_I1
Impl_I2
Impl I3
A_I2Itera
tion
A_I3
p _D_I3
Impl_I3
Erläuterungen zur vorherigen Folie
System entsteht Schrittweise durch Iterationen.Iterationen umfassen Issues verschiedener AktivitätenIterationen umfassen Issues verschiedener Aktivitäten.Die Zusammenfassung ist problemorientiert: die zusammengefassten Issues, gehören zu einem „top-level“ Issue.
Jede Iteration produziert einen wohldefinierten neuen ZustandJede Iteration produziert einen wohldefinierten neuen ZustandMöglichst einen, der ein funktionierendes Gesamtsystem ergibt... das für Benutzer einen erkennbaren Mehrwert darstellt.
Interpretation des BeispielsIteration 1 implementiert eine Basisversion der für Issue A_I1 gewählten Lösung.
Dies umfasst die Identifikation, Entscheidung und Umsetzung des Design-Issues D_I1 und der Implementierungs-Issues Impl_1, Impl_3Der identifizierte Design-Issue D_I2 wurde zurückgestellt.
Iteration 2 ergänzt das System um die Lösung und Implementierung von issue D_I2Iteration 3 widmet sich dem zurückgestellten Analyse-Issue A_I2
Dabei wird eine Abhängigkeit zu dem schon geschlossenen Issue D_I2 erkannt. Dieser wird wieder geöffnet, neu abgewogen, entschieden, ...
Wann welches Modell verwenden?
Häufigkeit von Änderungen und Software-Lebenszyklus PT P j kt it ( j t ti )PT = Projektzeit (project time)MTBC = mittlere Zeit zwischen Änderungen (mean time between changes)
Änderungen sehr selten (MTBC >> PT):g ( )WasserfallmodellAlle Probleme einer Phase sind vor der nächsten geschlossen
ÄÄnderungen manchmal (MTBC ≅ PT):Boehm’s SpiralmodellÄnderung während einer Phase kann zur Iteration einer früheren PhaseÄnderung während einer Phase kann zur Iteration einer früheren Phase oder der Beendigung des Projektes führen
Ständige Änderungen (MTBC << PT):I b d D l (C D l M d l)Issue-based Development (Concurrent Development Model)Phasen sind nie beendet, laufen alle parallel
Entscheidung über den Abschluss eines Problems beim Management
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-41 R O O T S
Menge abgeschlossener Probleme ist Basis für das zu entwickelnde System
Vorlesung „Softwaretechnologie“Kapitel 15: Softwareentwicklungsprozessmodelle R O O T Sap te 5 So t a ee t c u gsp o ess ode e
Der „Unified Software Process“
USDP vs. traditionelle Terminologie
USDP Terminologie
Klassische Terminologie
Business Modelling
Geschäftsprozess-Modellierung
Requirements Requirementsanalysis=
g
Analysis
Design
analysis
Design
rkflo
ws“
=tiv
itäte
n „Phase
Implementation ImplementationIntegration
„Wor Akt
en“
Test Test
Deployment Auslieferung
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-43 R O O T SAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Der Unified Software Development Process (USDP)Process (USDP)
Problemorientierte Iterationen der Aktivitäten in jeder PhaseAnteil bestimter Aktivitäten unterschiedlich in den einzelnen
Ivar„The U
preliminaryiteration(s)
Iter.#1
Iter.#n-1
Iter.#n
Iter.#m-1
Iter.#m
Iter.#m+k
Inception Elaboration Construction Transition
Phasen
Iterationen
Anteil bestimter Aktivitäten unterschiedlich in den einzelnen Phasen
... ... ...
r Jacobsen, U
nified Softwiteration(s) #1 #n-1 #n #m-1 #m #m+k
Requirements
Grady B
oocw
are Develop
Analysis
s =
ench, Jam
es Ru
pment Proce
Design
Wor
kflo
ws
Akt
ivitä
teum
baugh:ess“, A
ddiso
Implementation
Test
W on-Wesley, 19
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-44 R O O T S
999.
Der Unified Software Development Process (USDP)Process (USDP)
Problemorientierte Iterationen der Aktivitäten in jeder PhaseAnteil bestimter Aktivitäten unterschiedlich in den einzelnen
Ivar„The U
preliminaryiteration(s)
Iter.#1
Iter.#n-1
Iter.#n
Iter.#m-1
Iter.#m
Iter.#m+k
Inception Elaboration Construction Transition
Phasen
Iterationen
Anteil bestimter Aktivitäten unterschiedlich in den einzelnen Phasen
... ... ...
r Jacobsen, U
nified Softwiteration(s) #1 #n-1 #n #m-1 #m #m+k
Requirements
Aufwand für Anforderungserhebung während Iteration n
Grady B
oocw
are Develop
Analysis
s =
en
während Iteration n ch, James R
upm
ent Proce
Design
Wor
kflo
ws
Akt
ivitä
teum
baugh:ess“, A
ddiso
Implementation
Test
W on-Wesley, 19
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-45 R O O T S
999.
USDP Phasen
Konzeption (‘Inception’)U f d P d kt d d Ei h ft f tlUmfang des Produktes und dessen Eigenschaften festlegenMachbarkeitsstudien aus wirtschaftlicher Sicht abschließenDie größten Risiken ausschließeng
Ausarbeitung (‘Elaboration’)Möglichst viele Anforderungen erfassenE i k l d hi k i h G d iEntwickeln des architektonischen GrundrissesWeitere Risiken ausschließenAbschließend: Kostenschätzung für die nächste Phaseg
Konstruktion (‚Construction’)Komplette Entwicklung des SystemsFertig für die Auslieferung an den Kunden
Inbetriebnahme (‘Transition’)Sicherstellen dass das Produkt an die User ausgeliefert werden kannSicherstellen, dass das Produkt an die User ausgeliefert werden kannUser lernen den Umgang mit dem Produkt
Die sechs USDP-Modelle (Sichten der Anwendung)Anwendung)
Use-case D l tUse-casemodel
Deploymentmodel
Analysismodel
Implementationmodel
Designmodel
Testmodel
© 2000-2008 Dr. G. Kniesel Vorlesung „Softwaretechnologie“ (SWT) Seite 14-47 R O O T S
model model