Kapitel 16Kapitel 16 . Softwareentwicklungsprozessmodelle · 2018-02-08 · Überblick zDieser...

Vorlesung Softwaretechnologie 2007/8Dr. Günter Kniesel R O O T SDr. Günter Kniesel

Kapitel 16Kapitel 16. Softwareentwicklungsprozessmodelle

Einordnung

Bisher (Kap. 3-4): Womit arbeiten wir?nur ein paar besonders wichtige Arbeitsmittel vorgezogen vorgestellt: CVS/SVN, OOP, UML, OOM

Bisher (Kap 5 11): Was tun wir? AktivitätenBisher (Kap. 5-11): Was tun wir? AktivitätenAnforderungen erfassen, entwerfen, implementieren, testen, ...Qualitätssicherung, Versionsverwaltung, Projektmanagement, ...

Nun (Kap. 16-17): Wie tun wir es?Wie passt das alles zusammen?Was ist ein Softwareentwicklungsprozessmodell?

Vorlesung Softwaretechnologie, Wintersemester 2007/8 16-2 R O O T S

Überblick

Dieser Foliensatz (Kapitel 16): Software ProzessmodelleDas Wasserfallmodell und seine ProblemeIterative und inkrementelle Prozessmodelle

Nächster Foliensatz (Kapitel 17):Nächster Foliensatz (Kapitel 17): Agile ProzessmodelleExtreme Programmingg g


Typische Fragen zum Software-Lebenszyklus

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?Hängt das Systemdesign von der Analyse ab?Hä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? Können Analyse und Design parallel ablaufen?Können Analyse und Design parallel ablaufen?Sollten sie iterativ ablaufen?


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?


Wartung Sind Verbesserungen notwendig?

Rollen und Teilprozesse

Software EntwicklungEntwicklung

<<include>> <<include>><<include>> <<include>>

<<include>>

Problem-definition

System-entwicklung

Systembetrieb


Kunde Projektmanager Entwickler Administrator Endnutzer

Produkte

Software Entwicklung

Lauffähiges SystemProblem Statement

Requirements AnalysisDocument Testhandbuch

System DesignDocument

Object DesignDocument


IEEE Standard 1074: Standard für den Software-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


Processes> Software Quality

ManagementAllocation > Implementation> Documentation

> Training

Modellierung von Abhängigkeiten in einem Software-Lebenszyklusy

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


Verschiedene Modelle des Lebenszyklus

Vorlesung Softwaretechnologie 2007/8Kapitel 16: Softwareentwicklungsprozessmodelle R O O T Sap te 6 So t a ee t c u gsp o ess ode e

Wassserfallmodell

Das detaillierte Wasserfallmodell des Software Lebenszyklus

Projekt Initiierung

des Software-LebenszyklusConcept

Exploration

System Allocation

Anforderungs-Anforderungsanalyse

Design g

Implementierung

Verifikation& Validation

Installation

B t i b &


Betrieb & Support

Für und Wider des Wasserfallmodells

Manager lieben WasserfallmodelleNette MeilensteineK i Rü kbli k öti (li S t ) j d it i Akti itätKein Rückblick nötig (lineares System), jederzeit nur eine AktivitätFortschritt leicht zu prüfen : 90% codiert, 20% getestet

Aber, ...Softwareentwicklung ist iterativ

Während des Designs werden Probleme mit den Anforderungen festgestelltWährend der Implementierung werden Design- und Anforderungsprobleme p g g g pfestgestelltWährend des Testens werden Implementierungs-, Design-, und Anforderungsfehler gefundenAnforderungsfehler gefunden

SpiralmodellSystementwicklung ist nicht-linear


Problem-orientiertes Modell


Spiralmodell

Das Spiralmodell (Boehm) befasst sich mit Iteration

Identifiziere die Risiken

Gib den Risiken Prioritäten

E t i kl d t t i R ih P t t fü di i lEntwickle und teste eine Reihe von Prototypen für die einzelnen Risiken… in der Reihenfolge fallenden Risikos bzw. fallender Prioritätg

Nutze das Wasserfallmodell zur Entwicklung jedes Prototyps (“Zyklus”)

Wenn ein Risiko erfolgreich beseitigt wurde, bewerte das Ergebnis des Zyklus und plane die nächste RundeZyklus und plane die nächste Runde

Wenn ein bestimmtes Risiko nicht beseitigt werden kann, beende das


Projekt sofort

Spiralmodell

Determine objectives,alternatives, & constraints

Evaluate alternatives,identify & resolve risks

Riskanalysis

Riskanalysis

Riskanalysis

y

y

Prototype1Prototype2

Prototype3P1

Requirementsplan Software System

Product

Concept ofoperation

RequirementsDesign Detailed

Design

D l & if

Development

Integration

planRequirements

Design

validation

Code

Unit Test

Design

P2

Develop & ver ifynext level productPlan next phase

gplan

gvalidation Unit Test

Integration & TestAcceptance

Test


Aktivitäten (“Runden”) in Boehm’s Spiralmodell

Die folgenden Aktivitäten verteilen sich über die Zyklen der Spirale

Gehe in jedem Zyklus diese Schritte

der SpiraleConcept of OperationsSoftware Requirements

Bestimme Ziele, Alternativen, NebenbedingungenBewerte Alternativen, identifiziere

Software Product DesignDetailiertes DesignCode

,und löse RisikenEntwickle und verifiziere den Prototyp

Unit TestIntegration und TestAkzeptanztest

PrototypPlane den nächsten Zyklus

AkzeptanztestImplementierung

Frühere Aktivitäten geschehen in den inneren/initialen Zyklenin den inneren/initialen Zyklen, spätere in den äußeren Zyklen

Siehe Spirale auf der Seite zuvor


zuvor

Typen von Prototypen beim Spiralmodell

Illustrativer PrototypEntwickle 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 Kunden

Funktionaler PrototypImplementiere und liefere ein lauffähiges System mit minimalerImplementiere und liefere ein lauffähiges System mit minimaler FunktionalitätDann füge Funktionalität hinzuDas jeweilige Risiko bestimmt die ReihenfolgeDas jeweilige Risiko bestimmt die Reihenfolge

Explorations-Prototyp ("Hacken")I l ti i T il d S t h üb di A f dImplementiere einen Teil des Systems, um mehr über die Anforderungen zu lernen. Gut für Brüche im Denkmuster


Typen des Prototyping (fortgesetzt)

Revolutionäres PrototypingAuch “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 inNachteil: 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 PrototypingD P t t i t B i fü di I l ti d fi l S tDer Prototyp ist Basis für die Implementierung des finalen SystemsVorteil: Kurze FertigstellungszeitNachteil: Kann nur benutzt werden, wenn das Zielsystem in der Sprache y pdes Prototypen konstruiert werden kann


Die Grenzen des Wasserfall- und Spiralmodells

Keines von beiden befasst sich mit häufigen ÄnderungenDas 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 Phaseg

Was tun, wenn Änderungen häufiger erfolgen? (“Das einzig konstante ist die Änderung”)ist die Änderung )



„Issue-Based Development“

Issue-Based Development

Ein System wird durch eine Sammlung von Problemen beschriebenProbleme sind offen oder geschlossenA_I2 A_I2

Geschlossene Probleme haben eine LösungGeschlossene Probleme können wieder geöffnet werden (Iteration!)

Probleme haben AbhängigkeitenProbleme 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


Beispiel: Projekt mit nach Aktivitäten gruppierten Issues

Analyse-Issues

Design-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


Issues im Wasserfallmodell: Analysephase

Analyse-Issues

Design-Issues


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


Issues im Wasserfallmodell: Designphase

Analyse-Issues

Design-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


Wasserfall

Design

Analyse


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



100-0% Offene Implem.-Issues

Wasserfall

Design

Analyse


Implementierung

Issues im Wasserfallmodell: Projekt fertig!

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




Wasserfall

Design

Analyse


Implementierung


Bisher: Issue-basierte llustration eines WasserfallsWasserfalls

Nun: „Richtiges“ Issue-Based DevelopmentNun: „Richtiges Issue Based Development

Wirklich problemorientiertes „Issue-Based Development“Analyse-Issues Design-Issues Implem.-Issues

A_I1

A I2

D_I1

D_I2

Impl_I1

Impl_I2

Itera

tion

1

A_I2

A_I3

Impl_I3D_I3

Impl_I3

I

A_I1 D_I1 Impl_I1

Impl I2atio

n 2

A_I2

A_I3

D_I2Impl_I2

Impl_I3D_I3

Impl I3

Itera

p _ 3

A_I1 D_I1 Impl_I1n 3

D_I2Impl_I2

Impl_I3D I3

A_I2Itera

tion


A_I3D_I3

Impl_I3

Erläuterungen zur vorherigen Folie

System entsteht Schrittweise durch Iterationen.Iterationen 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 ZustandMöglichst einen, der ein funktionierendes Gesamtsystem ergibt... das für Benutzer einen erkennbaren Mehrwert darstellt.

Interpretation des BeispielsInterpretation 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-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 g y g p gissue D_I2Iteration 3 widmet sich dem zurückgestellten Analyse-Issue A_I2

Dabei wird eine Abhängigkeit zu dem schon geschlossenen Issue D I2


g g g _erkannt. Dieser wird wieder geöffnet, neu abgewogen, entschieden, ...

Wann welches Modell verwenden?

Häufigkeit von Änderungen und Software-Lebenszyklus PT = Projektzeit (project time)MTBC = mittlere Zeit zwischen Änderungen (mean time between changes)

Änderungen sehr selten (MTBC >> PT):W f ll d llWasserfallmodellAlle Probleme einer Phase sind vor der nächsten geschlossen

Änderungen manchmal (MTBC ≅ PT):g ( )Boehm’s SpiralmodellÄnderung während einer Phase kann zur Iteration einer früheren Phase oder der Beendigung des Projektes führenoder der Beendigung des Projektes führen

Ständige Änderungen (MTBC << PT):Issue-based Development (Concurrent Development Model)p ( p )Phasen sind nie beendet, laufen alle parallel

Entscheidung über den Abschluss eines Problems beim ManagementMenge abgeschlossener Probleme ist Basis für das zu entwickelnde System


Menge abgeschlossener Probleme ist Basis für das zu entwickelnde System


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

Vorlesung Softwaretechnologie, Wintersemester 2007/8 16-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)

Problemorientierte Iterationen der Aktivitäten in jeder PhaseAnteil bestimter Aktivitäten unterschiedlich in den einzelnen Ph

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

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


999.

Der Unified Software Development Process (USDP)

Problemorientierte Iterationen der Aktivitäten in jeder PhaseAnteil bestimter Aktivitäten unterschiedlich in den einzelnen Ph

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

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


999.

USDP Phasen

Konzeption (‘Inception’)Umfang des Produktes und dessen Eigenschaften festlegenMachbarkeitsstudien aus wirtschaftlicher Sicht abschließenDie größten Risiken ausschließen

Ausarbeitung (‘Elaboration’)Ausarbeitung ( Elaboration )Möglichst viele Anforderungen erfassenEntwickeln des architektonischen GrundrissesWeitere Risiken ausschließenAbschließend: Kostenschätzung für die nächste Phase

K t kti ( C t ti ’)Konstruktion (‚Construction’)Komplette Entwicklung des SystemsFertig für die Auslieferung an den KundenFertig für die Auslieferung an den Kunden

Inbetriebnahme (‘Transition’)Sicherstellen, dass das Produkt an die User ausgeliefert werden kann


User lernen den Umgang mit dem Produkt

Die sechs USDP-Modelle (Sichten der Anwendung)

Use-case D l tUse-casemodel

Deploymentmodel

Analysismodel

Implementationmodel

Designmodel

Testmodel


model model

Graphics reproduced with permission from C

Zusammenfassung

Softwareentwicklungsprozess

Softwareentwicklungsprozess-Modell

W f llWasserfall

SpiralSpiral

Issue-Based

Unified


Agile

Kapitel 16Kapitel 16 . Softwareentwicklungsprozessmodelle · 2018-02-08 · Überblick zDieser...

Documents

Transcript of Kapitel 16Kapitel 16 . Softwareentwicklungsprozessmodelle · 2018-02-08 · Überblick zDieser...