fit 2002 > Softwareentwicklungsmodelle > SpiralModel > Konzepte und Techniken

Überblick


Konzepte und Techniken

Im Spiralmodell wird der Softwareentwicklungsprozeß als iterativer Prozeß verstanden. Jede Windung der Spirale enthält die Aktivitäten
" Festlegung von Zielen, Alternativen und Rahmenbedingungen;
" Evaluierung der Alternativen, Erkennen und Reduzieren von Risiken;
" Realisierung und Überprüfung des Zwischenprodukts und
" Planung der Projektfortsetzung.
Am Ende jeder Windung steht ein Review, bei dem der aktuelle Projektfortschritt bewertet wird. Anschließend werden die Pläne für die nächste Windung verabschiedet sowie die dabei verfügbaren Ressourcen festgelegt oder aber die Entwicklung abgebrochen.
Die radiale Dimension repräsentiert die kumulativen Kosten, die die einzelnen Schritte mit sich ziehen; die winkelförmige Dimension stellt den gemachten Fortschritt, beim Beenden jedes Umlaufs der Spirale, dar.


Ein typischer Umlauf der Spirale

Jeder Umlauf der Spirale beginnt mit der Indentifikation von:


Ziele, Alternativen und Rahmenbedingungen.

Am Beginn jedes Zyklus werden inhaltliche Vorgaben an das zu entwickelnde Teilprodukt festgelegt, (z.B. Funktionalität, Qualitätskriterien, Nutzung von Bibliotheken zur Wiederverwendung) und alternative Vorgehensweisen herausgearbeitet (z.B. unterschiedliche Analyse- oder Entwurfstechniken, Einsatz von Werkzeugen, "make or buy"-Entscheidung). Als Rahmenbedingungen werden Einschränkungen bzgl. Zeit, Personal, Kosten, Hard- und Softwareumgebungen festgelegt.


Evaluierung der Alternativen bezüglich Zielen und Randbedingungen - Reduktion der Risiken.

In der zweiten Phase der aktuellen Windung werden die Alternativen hinsichtlich der festgelegten Ziele und Einschränkungen untersucht und bewertet. Es tauchen in der Regel Fragen, Unschärfen und Unwägbarkeiten auf, die jede Entscheidung für oder wider eine Alternative (bzw. die Verwerfung aller Alternativen) zu einer unsicheren Entscheidung machen. Unsichere Entscheidungen sind aber Risikoquellen des Projekts. Der Grad der Unsicherheit bzw. das Risiko sollte daher (immer unter Berücksichtigung der zugehörigen Kosten) soweit wie möglich reduziert werden. Dazu können so unterschiedliche Techniken wie z.B. Prototyping, Simulation, Datenmodellierung, Benchmark-Tests, Marktforschung mittels Umfragen oder Literaturrecherchen eingesetzt werden. Die weitere Projektarbeit im Allgemeinen und die Entscheidung für die Aktivitäten der dritten Stufe der aktuellen Windung im besonderen gründen sich nun auf das verbliebene Restrisiko. Dabei steht stets die Minimierung des Restrisikos im Mittelpunkt des weiteren Vorgehens.


Realisierung und Überprüfung.

Im dritten Schritt der aktuellen Windung wird die gewählte Alternative unter Einhaltung der Ziel- und Ressourcenvorgaben realisiert und getestet. Methodisch kann unter Berücksichtigung des Restrisikos flexibel und unter Einsatz des gesamten Software Engineering-Repertoires (von evolutionärem Vorgehen über transformationelle Entwicklung bis zur verstärkten Orientierung auf Wiederverwendung) vorgegangen werden. Die Entscheidung für eine Methode bzw. eine sinnvolle Kombination mehrerer Vorgehensweisen erfolgt ausschließlich risikoorientiert und exklusiv für die aktuelle Windung.


Planung, Review und Planungskonsens.


Zum Abschluß der aktuellen Windung wird auf der Grundlage des aktuellen Projektstands die nächste Spiralwindung inhaltlich und organisatorisch geplant. Die Planung muß nicht auf die unmittelbar folgende Phase beschränkt bleiben. Sie kann vielmehr mehrere Windungen betreffen. Erlaubt ist auch die Aufteilung des Projekts in Weitgehend unabhängige Teilprojekte, die von verschiedenn Entwicklungsteams parallel durchgeführt und erst zu einem späteren Zeitpunkt integriert werden.


Nach diesen Vorarbeiten greift der Kontrollmechanismus des Spiralmodells: In einem Review werden die Projektfortschritte und alle entwickelten Produkte des letzten Zyklus analysiert, die Ergebnisse bewertet und die Projektperspektiven diskutiert, bis unter allen beteiligten Parteien Konsens über die Situation im Projekt besteht. Sind z.B. die technischen oder wirtschaftlichen Risiken einer Projektfortsetzung (immer betrachtet vor dem Hintergrund der Anfangshypothese) zu hoch, so endet die Spirale (und das Projekt an diesem Punkt). Erfolgt kein vorzeitiger Projektabbruch, so liegt am Ende der letzten Windung die neue oder modifizierte Software vor und im letzten Review erfolgt ein abschließender Test der Anfangshypothese auf Basis des realen Ablaufs.

Initialisieren und Beenden der Spirale.
Initialisieren und Beenden der Spirale.
Einige fundamentale Fragen stellen Sich bei dieser Repräsentation des Spiralmodells:

1. Wie wird die Spirale jemals gestartet?

Die Spirale wird durch das Aufstellen der Hypothese, daß ein spezifischer Ablauf (im eigenen Unternehmen oder beim Kunden) durch eine Softwarelösung zu verbessern ist, initialisiert. Die Formulierung dieses Ziels und die Entwicklung konkreter Lösungsvorschlägen bilden den Beginn des ersten Spiralzyklus.


2. Wie endet die Spirale, wenn es angebracht ist das Projekt vorzeitig zu unterbrechen?

Falls die Hypothese den Test nicht besteht, endet die Spirale abrupt. Sonst endet die Spirale bei der Installation der neuen oder modifizierten Software, und die Hypothese wird getestet durch Beobachten der Software während des Einsatzes. Häufig führt dieses zu der Erstellung neuer Hypothesen , die zur Verbesserung der Software führen sollen und eine neue Wartungsspirale wird initialisiert um die Hypothesen zu testen.

Fazit

Zusammenfassend sind die wichtigsten Vorteile des Spiralmodells die unabhängige Planung und Budgetierung der einzelnen Spiralzyklen und die flexible, rein risikoorientierte und denoch kontrollierte Reaktion auf den momentanen Projektstand. Jedem Zyklus liegt eine eigene Entscheidung des unmittelbar betroffenen Personenkreises zugrunde, die auf Grundlage der aktuellen Situation und nicht wie beim Phasenmodell a piori am Projektanfang getroffen wird.

 

kurz betrachtet: Das V-Modell

Das V-Modell ([Müll99] oder [Bröh93]) gliedert den softwareentwicklungsprozess in sechs Phasen:

  • Anforderungsanalyse
  • Systementwurf
  • Entwurf und Implementierung der Module
  • Modultest
  • Systemintegration
  • Systemabnahme

Letztere drei Phasen bilden die Tests für die Produkte der ersten drei Phasen. Der Modultest testet die Module, welche aus Entwurf und Implementierung hervorgegangen sind und den hösten Detaillierungsgrad aller im Laufe der Softwareentwicklung entstandenen Produkte aufweisen. Die Systemintegration überprüft die Korrektheit des Systementwurfs. Die Systemabnahme zeigt die Richtigkeit der anfangs erstellten Anforderungen.


Aus der Anordnung nach diesen Sichten ergibt sich das für dieses Modell namengebende "V".

Die Produkte der ersten drei Phasen zusammen mit den Tests, welche diese überprüfen, werden als Modell bezeichnet.

  • Anwendermodell: besteht aus Anforderungsanalyse, Systemspezifikation und abgenommenen System.
  • Architekturmodell: besteht aus technischer Spezifikation, Teilsystem-Spezifikation, getestetem Teilsystem und getestetem System.
  • Implementierungsmodell: besteht aus Modul-Spezifikation und getesteten Modulen.

Das V-Modell strukturiert den Softwareentwicklungsprozess ähnlich dem Wasserfallmodell in einer sequentiellen Abfolge von Phasen. Als wesentlicher Fortschritt betont es die Zusammengehörigkeit von Produkten und diese überprüfenden Tests. Jedoch ist es ebenso wie das Wasserfallmodell für Fehler in frühen Phasen sehr anfällig, welche bei später Entdeckung zu einem beträchtlichenm Aufwand für deren Korrektur führen können.

 

Weiterführende Informationen


[Müll99] Müller-Etttrich Gunter: Objektorientierte Prozeßmodelle: UML einsehen mit OOTC, V-Modell, Objectory; Bonn: Addison-Wesley, 1999

[Bröh93] Bröhl A.-P., Dröschel W.: Das V-Modell: Der Standard für die Softwareentwicklung mit Praxisleitfaden; München, Wien: Oldenburg, 1993

Boehm Barry W: A Spiral Model of Software Development and Enhancement; TRW Defense Systems Group, 1993

Verweise auf Arbeiten anderer Gruppen


> Wasserfallmodell@SoftwareEntwicklungsmodelle FIT2002 Softwareentwicklungsmodelle: Das Wasserfall Modell
> Extreme Programming@Produktionsverhältnisse FIT2002 Hier wird eine ähnliche Variante des Spiralmodells verwendet.
>Requirement Engineering@Konzepte und Techniken@Wissensakquisition FIT2002 Requirements Elicitation, Requirements Modelling, Requirements Specification, Requirements Validation, Requirements Management

>Entstehungskontext | Konzepte und Techniken | Entwicklung und Auswirkungen | Praxis | Bewertung


Für den Inhalt verantwortlich:
De Stefani Andreas, Fischer Gerald, Rohner Martin, Strnad Thomas, Winkler Thomas