Kurs:Wirtschaftsinformatik SS09/SE1/Lernskript/Wasserfallmodell

Motto: "Wir fangen vorne an und gehen linear weiter bis zum Schluss!"

Das Wasserfallmodell ist ein lineares (nicht-iteratives) Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwicklungsprozess in Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein.

Im Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. In Meilensteinsitzungen am jeweiligen Phasenende werden die Ergebnisdokumente verabschiedet. Zu den wichtigsten Dokumenten zählen dabei das Lastenheft sowie das Pflichtenheft . In der betrieblichen Praxis gibt es viele Varianten des reinen Modells. Es ist aber das traditionell am weitesten verbreitete Vorgehensmodell.

Durch ein Phasenmodell sollten alle wesentlichen Anforderungen (personeller, finanzieller sowie terminlicher Art) planbar und kontrollierbar sein.

Der Name „Wasserfall“ kommt von der häufig gewählten grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen.

Entstehungskontext

Es ist nicht ganz klar, wer der Urheber des Wasserfallmodells war. An der Technischen Universität Wien wird behauptet, dass das Wasserfallmodell eigentlich eine Verbesserung des einfachen Phasenmodells, wie es bereits Herbert D. Benington 1956 vorgestellt hat >[Benington, 1956]. Herbert D. Benington 1956 hat in dem als nine phase stage-wise model den Software Entwicklungsprozess in 9 Phasen eingeteilt.

Ich werde deswegen mit der Zuschreibung an einem geistigen Vater des Wasserfallmodells vorsichtig sein.

Die Ideen für das Wasserfallmodell fanden sich schon in frühen Ansätzen in verschiedenen Publikationen der U.S. Air Force und der Industrie. Beispielsweise Einfluss bei der Entwicklung eines Air Defense Software Systems namens SAGE (semi automated ground environment) in den 50er Jahren.

Grösseren Bekanntheitsgrad erlangte das Wasserfallmodell aber erst durch Dr. Winston W. Royce in den 70ern und Barry Boehm in den 80ern.

Dr. Winston W. Royce (1929 - 1995) war gegen Ende seiner beruflichen Laufbahn Direktor des Lockheed Software Technology Centers. Er war eine der bedeutendsten Persönlichkeiten im Bereich der Software Entwicklung des 20ten Jahrhunderts.

Barry Boehm hat das Wasserfallmodell um den Verifizierungs- und Validierungsaspekt erweitert. Zusätzlich war die Rückkopplung fester Bestandteil des Modells. Barry Boehm hat auch ein wichtiges paper zum Spiralmodell verfasst.

Prämisse für Anwendung des Wasserfallmodells

1. alle wesentlichen Anforderungen der späteren Anwender sind bekannt
2. die Anforderungen werden während des Prozesses nicht wesentlich verändert
3. das System kann in einem Zug vollständig entwickelt werden
4. es handelt sich um eine Neuentwicklung, die nicht durch Modifikation vorhandener Software entsteht

Metapher: Software-Factory & Fliessband

Es steckt die Vorstellung eines Fließbandes für Softwareprodukte hinter diesem Modell, genannt "Software Factory".

Phasen beim Wasserfallmodell

1. Software-Anforderungen (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan)

1. 1. Machbarkeitsstudie

• In dieser Phase: Abschätzen des Gesamtprojekts bezüglich Kosten, Ertrag und Realisierung.
• Problem informell und abstrahiert zu beschreiben und aufbauend darauf mögliche Lösungsansätze zu erarbeiten
• versuchen die Kosten des Softwareentwicklungsprozesses abzuschätzen und ein Angebot (für den Auftraggeber) erstellen.

Das Ergebnis sollte dann sein:

• • ein Lastenheft (enthält grobe Beschreibung der Anforderungen)
  • Projektplan
  • Projektkalkulation
  • Angebot an den Auftraggeber

1. 1. Anforderungsdefinition

• genau definiert werden, was die Software machen soll, wobei aber nicht genauer drauf eingegangen wird wie sie was macht
  • "Ist-Analyse" durchgeführt
  • Ziel der "Ist-Analyse" ist eine Beschreibung von Abläufen und Begriffen des Problembereichs.
  • ein "Soll-Konzept" bestimmt
  • Im "Soll-Konzept" wird hingegen festgelegt wie bestimmte Systemeigenschaften definiert sein müssen und die genau Funktionalität des Softwareprodukts sein soll
  • Leistung, Benutzerschnitstelle und Portierbarkeit genauer beschrieben.
  • geeignete Testfälle erstellen

Ergebnisse:

• • Pflichtheft (=Anforderungsdefintionsdokument, Soll-Konzept)
  • Akzeptanztestplan (Testfälle)
  • Benutzerhandbuch (erste Version)

1. Analyse

• "divide & conquer" Prinzip: Anforderungsdefinition einer Analyse unterzogen, die den Zweck hat, die Anforderungen zu überprüfen, zu verfeinern und anschließend zu zerteilen.
• "divide & conquer" Prinzip: dass die Komplexität des Problems sich vielfach durch Zerlegung in kleinere Teilprobleme verbessern lässt. Danach löst man die Teilprobleme und fügt die Teillösungen zu einer Gesamtlösung zusammen.

Fazit: "Soll-Konzept" der vorhergehenden Phase verfeinert und eine Beschreibung von dem Ablauf und der Struktur des zu erstellenden Systems erstellt.

Ergebnisse:

Analysedokument Benutzerhandbuch (zweite Version)

1. Entwurf (UML, Struktogramme)

Nun wird genau festgelegt, wie was zu realisieren ist:

• ein Bauplan für die Software und die Softwarearchitektur werden entwickelt
• konkrete Softwarebibliotheken, Frameworks und der gleichen werden ausgewählt
• Schnittstellen werden klar definiert und die ersten Algorithmen werden entwickelt bzw. ausgewählt

Ergebnisse:

• Entwurfsdokument mit Softwarebauplan
• detaillierte Testpläne für Module, Klassen und Komponenten

1. Codierung

• konkrete Implementierung des Systems in einer gewählten Programmiersprache
• Einzelne Module, Klassen und Komponenten werden entwickelt

Ergebnisse:

• schrittweise wird der Code getestet und in das Gesamtsystem integriert

Ergebnis:

• Benutzerhandbuch (endgültige Version)
• Technische Dokumentation
• Testprotokolle

1. Testen

• Alpha-Test: Am Ende der Codierung wird dann noch einmal ein Gesamtsystemtest durchgeführt, den man als Alpha-Test bezeichnet.

Ergebnis:

• Fertiges System ("Alpha Version")

1. Betrieb

• Das fertige Produkt an den Kunden liefern werden und in die Zielumgebung integrieren
• Wenn notwendig findet eine Auslieferung und Schulung an alle Benutzer statt.
• Meistens durchläuft das System aber noch eine sogenannte "Beta Testphase", in der das System an ausgewählte Benutzer geliefert wird und in Betrieb genommen wird, um letzte Fehler zu finden.

Ergebnis:

• Fertiges System ("Beta Version")
• Akzeptanztestdokument

Charakteristika

1. Jede Aktivität ist in der vorgegebenen Reihenfolge und in der vollen Breite vollständig durchzuführen.
2. Am Ende jeder Aktivität steht ein fertiggestelltes Dokument, d.h. das Wasserfall-Modell ist ein "dokument-getriebenes" Modell.
3. Der Entwicklungsablauf ist sequenziell, d.h. jede Aktivität muss beendet sein, bevor die nächste anfängt.
4. Es orientiert sich am sogenannten top-down-Verfahren.
5. Es ist einfach, verständlich und benötigt nur wenig Managementaufwand.
6. Eine Benutzerbeteiligung ist nur in der Anfangsphase vorgesehen, anschließend erfolgen der Entwurf und die Implementierung ohne Beteiligung des Benutzers bzw. Auftraggebers. Weitere Änderungen stellen danach Neuaufträge dar.

• dokumentenzentriertes Vorgehen, jede Phase kennt nur die Ergebnisse der vorhergehenden Phase
• an Bedürfnisse des Managements ausgerichtet, klare Ergebnisse nach Phasen, klare Verantwortungen für Phasen
• Trennung der Phasen spiegelt aber nicht die Realität wieder: erkenntnisgetriebene Entwicklung, Entwicklung als Klärung von Anforderungen, Phasenüberlappungen
• durch die fatale Überabstraktion nur als grobe Orientierungshilfe zu verwenden

• detaillierte Phasen
• Phase x kennt nur Ergebnisse von Phase x – 1
• Dokumentzentriert

Vor- und Nachteile des Wasserfallmodells

Das Waterfall Model verdeutlich obwohl es in die Jahre gekommen ist bereits stark, dass Softwareentwicklung weit mehr als die Programmierung von Software für einen besimmten Zweck ist und das sehr viel Dokumentation notwendig ist um ein Softwareprojekt eindeutig zu beschreiben. (6) Royce spricht hier bei einem Auftragsvolumen von 5 Millionen US Dollar von mindestens 1500 Seiten Dokumentation.

Eine weitere wichtige Erkenntnis des Waterfall Models ist das durch eindeutige Festlegung von Anfoderungen in einer frühen Projektphase spätere Phasen wesentlich leichter und schneller entwickelt werden können.

Ein weiterer Vorteil des Waterfall Models und wahrscheinlich auch ein Grund für seine die häufigen Zitate ist, dass es einfach Strukturiert und sehr einleuchtend ist. Man kann die Schritte leicht nachvollziehen und auch bei der Durchführung ist es leicht zu planen von einem Schritt zum anderen zu gehen.

So macht es zum Beispiel keinerlei Aussagen über Debugging und Wartung. Beim Schreiben von Software spielen diese beiden Gesichtpunkte jedoch eigentlich immer eine Rolle.

Des weiteren geht es davon aus, das sich in den Ergebnissen einmal durchgeführter Schritte keine Veränderungen mehr ergeben können, also dass beispielsweise die Anforderungen an eine Software sich im Softwareprozess nicht ändern. (5 S. 10) Bei großen Softwareprojekten bei denen die Entwicklung sich über Jahre hinzieht können sich in dieser Zeit Anfoderungen sehr wohl ändern.

Allerdings sind Software Systeme heute auch wesentlich benutzerorientierter als in den 1970er Jahren und müssen deswegen schneller auf solche Anforderungen reagieren können. Veränderungen in den Anforderungen sollten kein unerwünschter Einzelfall sein der vermieden werden muss, sondern sie finden immer statt und sollten von vorne herein eingeplant werden.

Es ist einfach nicht möglich einen Schritt des Softwareentwicklungsprozesses komplett korrekt abzuschließen. Dies ist das zentrale Problem des Waterfall Models, da es - hat man eine Ebene einmal verlassen - einem keine Möglichkeit zur Rückkehr in diesen Entwicklungsschritt bietet. (6)

Aspekte des Prototypings werden im Waterfall Model komplett vernachlässigt, somit ist es nicht möglich nach jedem Schritt zu schauen, ob man sich noch auf dem richtigen Weg befindet. Ist der Entwicklungsprozess einmal angestossen, so läuft er ohne größere Veränderungen bis zum Ende ab.

Nachteile

Unbenannte Nachteile

• zu Projektbeginn sind nur ungenaue Kosten- und Ressourcenschätzungen möglich,
• die Problematik späterer Änderungen wird nicht adressiert.
• Es fehlt die Möglichkeit, die äußeren Eigenschaften einer Anwendung frühzeitig auszuprobieren, da *die Implementierung erst sehr spät erfolgt.
• In der Entwurfsphase ist eine Interaktion mit Endbenutzer mangels Prototypen sehr schwierig. Das bedeutet, daß der Benutzer erst dann eine wirkliche Vorstellung von dem Produkt bekommt, wenn es fast fertig ist.

Ein Pflichtenheft kann nie den Umgang mit dem fertigen System ersetzen. Das heißt das gutes Feedback wird erst sehr spät möglich ist.

• Das frühe einfrieren der Anforderung kann bei einem notwendigen Wandel aufgrund technischer, politischer oder organisatorischer Gründe zu großen Problemen führen.
• Änderungswünsche, die über kosmetische Verbesserungen hinausgehen, sind nach der Fertigstellung nur schwer und unter hohen Kosten erfüllbar.

• Das Modell ist nur auf einfache Projekte anwendbar
• Unflexibel gegenüber Änderungen und im Vorgehen (Phasen müssen sequenziell abgearbeitet werden)
• Frühes Festschreiben der Anforderungen ist sehr problematisch → eventuell teure Änderungen (mehrmals wiederholtes Durchlaufen des Prozesses bei Änderungen)
• Einführung des Systems sehr spät nach Beginn des Entwicklungszyklus → später return on investment
• Fehler werden unter Umständen erst spät erkannt (Big Bang) und müssen mit erheblichem Aufwand entfernt werden

• spätere Erkenntnisse fließen nicht ein
• lineare Entwicklung wird angenommen (praxisfern)
• Starre Phasen
• kein paralleles Arbeiten möglich
• keine (späteren) Änderungen
• Dokumentzentriert
• B3N15

ansehen bearbeiten

ansehen bearbeiten

ansehen bearbeiten

Verbesserung des Wasserfallmodells

Das Modell konnte sich ursprünglich nicht durchsetzten. Der Informationsfluss (feedback) war anders in der Praxis als in der Theorie entlang des Penisverlaufs vorgeschrieben.

Winston Royce beschreibt das Wasserfallmodell in seiner Publikation Dr. Winston W. Royce: Managing the developement of large Software Systems (436 KB; PDF-Datei) aus dem Jahr 1970 als fehlerträchtiges und kostenrisikobehaftetes Modell der Softwareentwicklung; dabei bezieht er sich sowohl auf die einfache Variante als auch auf die erweiterte mit schrittweise erfolgenden Rücksprungmöglichkeiten. Stattdessen schlägt Royce in dieser Publikation ein wesentlich um iterative Elemente erweitertes Modell vor. Diese Erweiterung um die Rücksprünge sind der Grund, warum das von Barry Boehm in den 80er Jahren vorgestellte Modell nicht nur großes Interesse und viele Anwender fand, sondern noch heute als das Wasserfall Modell bezeichnet wird.

Dadurch wird das Wasserfallmodell praktikabler, weil der Erkenntnisgewinn (Fehlerdetektion) aus Phase x verwendet werden kann, um den Ursachenherd in Phase x-1 zu beseitigen.

Die Vorgehensweise ist ein wenig vage, weil man nicht genau weiss, wieviele Rücksprünge nötig sind, um die Fehlerursache zu finden, wenn sie etwa nicht in Phase x-1, sondern in Phase x-k, k < x versteckt ist.

Die Dokumentationspraxis wird durch die Rücksprünge erschwert. Das Management wird dabei stärker gefordert.

Detailphasen beim Wasserfallmodell

Rocye zeigte selber gleich eine Reihe von Problemen auf. Insbeseondere: "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed." (1 S. 329) Der Anbau der Testphase am Schluß kann ein komplettes Redesign notwendig machen, weil sich zwischenzeitlich die Anforderungen und der Stand der Technik geändert haben könnte, da in sämtlichen anderen Entwicklungsschritten nie geprüft wird in wie weit das bisher entwickelte auch dem gewünschten Ergebnis entspricht.

Royce fügt fünf weitere Schritte hinzu, um die Nachteile des Waterfall Models zu verbessern und daraus ein iteratives Model zu erstellen.

Datei:Detailphasen Wasserfallmodell.png

Klausurrelevant Folie

Trennung der Phasen spiegelt aber nicht die Natur der Software-Entwicklung wieder, z.B.

• Erkenntnisgetriebene Entwicklung
• Entwicklung als Aktivität der Klärung von Anforderungen
• Phasen überlappen zwangsläufig
• Reviews beanspruchen Zeiträume
• Dekomposition schafft (ab Entwurfsphase) eine Vielzahl

von Ergebnissen, deren gleichzeitige Bereitstellung nicht

Die Erweiterung des Wasserfallmodells um Iterationen (auch zwischen mehreren Phasen) versucht, diese Mängel zu beseitigen. Dies kostet jedoch den Preis, dass initiale und iterierte Aktivitäten nicht sinnvoll unterschieden werden.

EXKURS: "Sashimi" Model

Im Sashimi Model sind die einzelnen Phasen nicht strikt voneinander getrennt sondern überlappen sich zu großen Teilen. Damit soll "Feedback" zwischen den einzelnen Phasen gewährleistet werden. Dadurch können auch während der Phase der Programmierung noch Änderungen am Programmdesign vorgenommen werden. Das Sashimi Model wird Peter DeGrace zugeschrieben.

Lebenszyklus beim Wasserfallmodell

Fazit: Das Wasserfallmodell ist als Lebenszyklusmodell lediglich als ganz grobe Orientierungshilfe zu verwenden. Operativ wirksame Ableitungen sollten auf seiner Basis nicht getroffen werden!

Literaturhinweise

• Wikipedia.de zum Stichwort "Wasserfallmodell"
• Institut für Gestaltungs- und Wirkungsforschung: Beschreibung Wasserfallmodell
• Dr. Winston W. Royce: Managing the developement of large Software Systems (436 KB; PDF-Datei)
• Glossar-Eintrag Wasserfallmodell mit historischen Literaturhinweisen