fit 2002 > Softwareentwicklungsmodelle > SpiralModel > Entstehungskontext

Überblick


Die Frage nach der Entstehung setzt sich im folgenden aus 5 Unterpunkten zusammen.


ursprüngliche Frage/Problemstellung:


Was haben sich die Entwickler einer neuen Konzeption gedacht?

Als primäre Funktion eines Softwareentwicklungsmodels wollte man die Möglichkeit die Reihenfolge der einzelnen Stufen zu kontrollieren, und auch die Kriterien für den Übergang zur nächsten Stufe zu kennen bzw. zu bestimmen.

Man wollte 2 wichtige Fragen in einem Software Projekt Model beantwortet haben:

  • Was tun wir als nächstes?
  • Wie lange sollen wir das weiterhin tun?
Man unterschied daraufhin den Unterschied zwischen eine Software Methode und einem Process Model, welches hauptsächlich dem Zweck dient festzustellen, WIE man durch jede einzelne Phase kommt und wie man die Produkte jeder Phase (State Chart, Diagramme, ..) präsentieren kann.

Warum haben sie zu dieser Zeit eine bestimmte Vorstellung entwickelt?

(siehe auch >Vorgeschichte)

In den frühen Tagen der Software Entwicklung war das "Code and Fix Model". Hier wurde einfach mal ein Code geschrieben und anschließend die Fehler und Probleme behoben. Die primären Schwierigkeiten bei diesem Modell waren:

  • nach ein paar "Fixes" wurde der Code unstrukturiert. Dies wies darauf, dass eine Design Phase vor dem Coden notwendig ist.
  • Oft entsprach auch gut entworfene Software nicht den User Wünschen, und musste sehr teuer neu designed werden, oder wurde gleich ganz verworfen. Dies wies darauf hin, dass eine "Bedürfnis Analyse" vor der Design Phase notwendig ist.
  • Der Code war teuer zu reparieren ("fix") weil kaum oder garnicht Vorbereitungen getroffen wurden für Tests oder Modifikationen. Dies wies darauf hin, dass explizit eine Phase für diesen Vorgang notwendig ist.
Danach kam das "Stagewise Model" (1956), das den Entwicklungsprozess in einzelne Phasen einteilte.

Das >Wasserfall Modell hatte 2 Verbesserungen gegenüber dem Stagewise Modell: Feedback zwischen den Phasen und die Verwendung von >prototyping im Software Life Cycle durch einen "build it twice" Schritt, der parallel zur Bedürfnis Analyse und dem Design Schritt lief. Jedoch war der "build it twice" Schritt bei gutem Design nicht notwendig und der reine Top-Down Charakter des >Wasserfall Models wollte durch eine Vorschau verbessert werden.

Diese Überlegungen führten zu der Risiko Management Variante des >Wasserfall Modells! In dieser Variante wurde jeder Schritt um eine Überprüfungsaktivität erweitert, die high-risk Elemente und "Wiederverwendungsüberlegungen" abdecken sollte.

Dennoch gab es bei diesen Modellen immer noch Schwierigkeiten. Daher ergaben sich weitere alternative Modelle:

  • "The Evolutionary Development Model": Hier hat man versucht die Probleme zu beseitigen, dass es nicht immer eine vollkommen eindeutige Vorgabe gibt um die Design Phase völlig abschliessen zu können bevor man an die Programmierung geht. (I can't tell you what I want, but I'll know it when I see it.). Diese Modell passt sich sozusagen während der Entstehung immer wieder neu an.
  • "The Transform Model": Um das Problem des "spaghetti code" zu beseitigen, das entsteht, wenn man im Nachhinein den Entwurf ändert, wurde eine Idee entwickelt (1983), dass man eine formale Spezifikation automatisch in einen Code transformieren kann. Dies war natürlich nur für kleine Projekte in einem limitierten Bereich möglich.
[QUELLE: Software Engineering Project Management, 1988 Richard H. Thayer]

Vorgeschichte:


Auf welche Probleme haben Entwickler reagiert? Welche Konsequenzen haben sie aus dem Scheitern/den Schwächen einer früheren Konzeption gezogen? Was wollten sie besser/anders machen?

Das Spiral-Modell entstand aus der in den 80er Jahren ausgerufenen Softwarekrise. Viele Softwareprojekte wurden zu dieser Zeit durch unzureichende Konzepte entweder gar nicht oder unter immensem finanziellen Aufwand zu Ende geführt.

Die bedeutendsten Vorgängermodelle des Spiralmodells sind u.a.

  • a) Code & Fix-Modell: Schreiben von Code -< Code-Fixing & Erweiterung. Nachteile: unstrukturierter Code, kein Feedback mit Kunden, Erweiterungen sehr teuer
  • b) >Wasserfall Modell: Strukturierte Vorgesehensweise, Reviews, Feedbacks innerhalb der Entwicklungsstufen. Nachteile: genaue Spezifikation vor Coding-Phase erforderlich (für interaktive Softwareprojekte nicht immer möglich)
  • c) Evolutionäres Entwicklungsmodell: Rapid Development durch einfache Erstellungsmöglichkeiten von Prototypen, keine genaue Spezifikation nötig. Nachteile: Gefahr des unstrukturierten Programmierens durch teilweise fehlende Planungsphasen
  • d) Transformationsmodell: Vermeidung von unstukturiertem Code durch Formalismen zur Umwandlung der Spezifikation in Code, iteratives Vorgehen zur Verbesserung der Performance, Optimierung. Nachteile: nur auf kleine Projekte anwendbar, immenser Aufwand wegen unterschiedlichster Produkte gleicher Funktion aber unterschiedlichster Performance/Kosten-Parameter
Das Ziel des neuen Modells - des Spiralmodells - ist es, sich die Vorteile der einzelnen Modelle anzueignen. Die Besonderheit des Spiralmodells ist, dass es diese Modelle ja nach Bedarf integrieren kann. Dadurch kann auf die Größe des Projektes der Aufwand skaliert werden.

Wichtige Neuerungen sind die Risikoanalyse, Kostenkontrolle und Suche nach Alternativen in jedem Spiralumlauf. Pro Iteration wird geprüft, ob es eine bereits existierende Lösung für das Problem gibt, und daher diese Softwarekomponente wiederwendet werden kann, was die Projektkosten dramatisch senken kann.

Ein wichtiger Punkt ist es, dass zum Ende jedes Umlaufes ein Review mit sämtlichen Beteiligten stattfindet, was die Akzeptanz einer am Ende gefundenen Lösung ermöglicht.

"Weltbild" der Entwickler


Biographie von Barry Boehm

Barry Boehm erhielt seinen B.A. Titel in Harvard im Jahre 1957 und seine M.S. und Ph.D. Titel der UCLA im Jahre 1961 und 1964 alle in Mathematik. Zwischen 1989 und 1992 diente er innerhalb der US-Abteilung der Verteidigung (DoDs) als Direktor der DARPA Informationswissenschaft und des DARPA Technologiebüros und als Direktor des DDR & E Software- und Computertechnologiebüros. Er arbeitete bei TRW von 1973 bis 1989, als Hauptwissenschaftler der Verteidigungssystemgruppe und in der Randcorporation leitete er von 1959 bis 1973 die Informationswissenschaftliche Abteilung. Zwischen 1955 und 1959 arbeitete er bei General Dynamics als Analytiker von Programmierern. Seine gegenwärtigen Forschungsinteressen schließen Softwareprozeßmodellierung ein, Software requirements engineering, Softwarearchitekturen, Softwaremaßsysteme und Kostenmodelle, Softwaretechnikumgebungen und wissensbasierte Softwaretechnik. Seine Beiträge umfassen das konstruktive Kosten Modell (COCOMO), das spiralförmige Modell des Softwareprozesses, die Theorie W (win-win) und zwei fortschrittliche Softwareumgebungen: das TRW Softwareproduktivitätssystem und die Quantensprungumgebung.

Er hat Artikel für mehrere wissenschaftlicher Zeitschriften einschließlich der the IEEE Transactions on Software Engineering, IEEE Computer, IEEE Software, ACM Computing Reviews, Automated Software Engineering, Software Process, and Information and Software Technology verfasst. Er besitzt den Stuhl des AIAA technischen Komitees für Rechnersysteme, Stuhl des IEEE technischen Komitees für Softwaretechnik und als ein Mitglied der IEEE Computergesellschaft gedient. Er besetzt gegenwärtig den Stuhl der Luftwaffe im Bereich der Informationstechnologie und den Stuhl des Rats von Besuchern des wissenschaftlichen Beirats für das CMU Softwaretechnikinstitut. Seine Auszeichnungen und Preise schließen einen als Gastdozenten der UdSSR Akademie der Wissenschaften (1970), the AIAA Information Systems Award (1979), the J.D. Warnier Prize for Excellence in Information Sciences (1984), the ISPA Freiman Award for Parametric Analysis (1988), the NSIA Grace Murray Hopper Award (1989), the Office of the Secretary of Defense Award for Excellence (1992), the ASQC Lifetime Achievement Award (1994), and the ACM Distinguished Research Award in Software Engineering (1997) ein. Er ist ein Mitglied des AIAA , ein Mitglied des ACM, ein Mitglied des IEEE. und ein Mitglied der National Academy of Engineering.

Wie haben sie sich User oder Arbeit vorgestellt?

Das Spiralmodell wurde in der Zeit entwickelt als Barry Boehm beim TRW arbeitete. Die Mitarbeiter dieser Firma galten zur Entwicklungszeit als die eigentlichen User und die Softwareentwicklung bei TRW war die Aufgabenstellung für die dieses Modell entwickelt wurde. Es sollte besonders gut für Projekte mit großem Risiko geeignet sein.

Ideengeschichtliche Einflüsse (z.B. auch militärische Vorstellungen)


Welche Vorbilder gehen in die Konzepte ein?

Das Spiralmodell enthält viele der Stärken anderer Modelle und behebt viele ihrer Schwierigkeiten.

Einige dieser Modelle sind u.a.:

  • a) Code & Fix-Modell:
  • b) >Wasserfall-Modell:
  • c) Evolutionäres Entwicklungsmodell:
  • d) Transformationsmodell:
Vorteile und Nachteile dieser Modelle (siehe auch >Vorgeschichte)

"Die Entwicklung des Spiralmodells wurde vom Iterativen Verfeinerungsmodell und der Prototypentwicklung beeinflußt.

Das Spiralmodell ist als ein Meta-Modell zu verstehen, da sich andere Ausführungsmodelle wie die oben vorgestellten darin integrieren lassen. Es erweitert quasi die anderen Modelle um den Aspekt des Risiko-Managements von Software-Entwicklungen, übernimmt dabei gleichzeitig jedoch die jeweiligen Vor- und Nachteile."

QUELLE: >[www.dfki.uni-kl.de/~klink/Postscript/seminar.pdf]

Welche geistigen Strömungen existieren zu der Zeit?

"Stop the life cycle - I want to get off!"

"Life-cycle Concept Considered Harmful."

"The waterfall model is dead."

"No, it isn't, but it should be."

These statements exemplify the current debate about software life-cycle process models. The topic has recently received a great deal of attention.

The Defense Science Board Task Force Report on Military Software issued in 1987 highlighted the concern that traditional software process models were discouraging more effective approaches to software development such as prototyping and software reuse. The Computer Society has sponsored tutorials and workshops on software process models that have helped clarify many of the issues and stimulated advances in the field (see "Further reading").

[QUELLE: A Spiral Model of Software Development and Enhancement, May 1988 Barry W. Boehm]

Welche traditionellen Anforderungen/Erwartungen gab es?

Einige der Anforderungen / Erwartungen, die an das Spiral Modell gestellt wurden, waren:

  • Optionen, welche die Wiederverwendung der vorhandenen Software mit einbeziehen, sollen schon sehr früh berücksichtigt werden.
  • Vorbereitungen für lifecycle-entwicklung, -wachstum und -änderungen des Software-Produktes sollen angepasst werden.
  • Es soll Mechanismen für "incorporating software quality objectives" in der Software-Produktentwicklung zur Verfügung stellen.
  • Fehler und uninteressante Alternativen sollen möglichst früh beseitigt werden.
  • Für jede der Quellen der Projektaktivität und der Hilfsmittelaufwendung soll es die Schlüsselfrage beantworten: "Wie viel ist genug?".
  • Es sollen keine unterschiedlichen Annäherungen für Software-Entwicklung und Software-Verbesserung (oder Wartung) mit einbezogen werden.
  • Es soll ein entwicklungsfähiger Rahmen für integrierte Hardware-Software System Entwicklung zur Verfügung gestellt werden.
Das Spiralmodell sollte von den Vorteilen anderer Modelle profitieren, indem es sie integriert, aber dabei so viele ihrer Nachteile beheben wie nur möglich.

Umfeld


Barry Boehm entwickelte das Spiralmodell 1986-88. Zu dieser Zeit war er bei TRW Inc., einem Unternehmen, dass sich auf hochentwickelte Produkte und Dienstleistungen für die Luftfahrtindustrie, Informationssystemhersteller und die Automobilmärkte spezialisiert hat.

>[TRW Inc.] besteht seit über hundert Jahren und erzielte 2000 einen Umsatz von 17,2 Milliarden USD. Boehm war zu dieser Zeit der wissenschaftliche Leiter der Gruppe für Verteidigungssysteme. Danach war Boehm beim U.S. Department of Defense (DoD) und setzte seine wissenschaftliche Tätigkeit dort fort.

Einer der Hauptgründe für die Entwicklung des Spiral-Modells war der Wunsch die Softwareentwicklung signifikant zu steigern. Bei TRW selbst wollte man durch die Einführung des Modells die Produktivität innerhalb von fünf Jahren verdoppeln. Weiters sollte das Modell Anwendern leicht verständlich sein und möglichst wenig an Kosten erzeugen.

Weiterführende Informationen


>[http://www.dfki.uni-kl.de/~klink/Postscript/seminar.pdf]

[A Spiral Model of Software Development and Enhancement, May 1988 Barry W. Boehm]

[Software Engineering Project Management, 1988 Richard H. Thayer]

Verweise auf Arbeiten anderer Gruppen


>Factories@Produktionsverhältnisse ausgelöst durch die Software Krise um die 60'er Jahre, gab es zusätzlich (zu den hier vorgestellten Modellen) die Idee von Software Factories.

>Entstehung@wissensaquisitation ein kurzer Überblick darüber, was sich während der Entwicklung der Software Engineering Methoden im Bereich der Datenspeicherung getan hat.

>entwicklung@modelierung Workflow Management, das mit Methoden, die dem Spiralmodel oder dem Lifecycle Model ähnlich sind arbeitet.

>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