Kapitel 14 14. Softwareentwicklungsprozessmodelle · IEEE Standard 1074: Standard für den...

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


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?


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


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


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 &


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


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


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


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


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


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”)



„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


Beispiel: Projekt mit nach Aktivitäten gruppierten Issues

Analyse-Issues

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


Issues im Wasserfallmodell: Analysephase

Analyse-Issues

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


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

fertig!

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


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

© 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


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


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


model model

Zusammenfassung

Softwareentwicklungsprozess

Softwareentwicklungsprozess-Modell

Wasserfall

Spiral

Issue BasedIssue-Based

Unified


Weiter mit Foliensatz „Agile Softwareentwicklung“

Kapitel 14 14. Softwareentwicklungsprozessmodelle · IEEE Standard 1074: Standard für den...

Documents

Transcript of Kapitel 14 14. Softwareentwicklungsprozessmodelle · IEEE Standard 1074: Standard für den...