Wasserfallmodell

(c) Paul Hoadley, Paul Smith and Shmuel Csaba Otto Traian, CC BY-SA 3.0

Ein Wasserfallmodell ist ein lineares (nicht iteratives) Vorgehensmodell, das insbesondere für die Softwareentwicklung verwendet wird und das in aufeinanderfolgenden Projektphasen organisiert ist. Wie bei einem Wasserfall mit mehreren Kaskaden „fallen“ die Ergebnisse einer Stufe nach unten in die nächste und sind dort verbindliche Vorgaben.

In einem Wasserfallmodell hat jede Phase vordefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen. Meist beschreibt das Modell auch einzelne Aktivitäten, die zur Herstellung der Ergebnisse durchzuführen sind. Zu bestimmten Meilensteinen und am jeweiligen Phasenende werden die vorgesehenen Entwicklungsdokumente im Rahmen des Projektmanagements verabschiedet.

Der Name Wasserfall kommt von der häufig gewählten grafischen Darstellung der als Kaskade angeordneten Projektphasen. In der betrieblichen Praxis ist es traditionell ein weitverbreitetes Vorgehensmodell, von dem es viele Varianten gibt.

Erweiterungen des einfachen Modells (Wasserfallmodell mit Rücksprung) führen iterative Aspekte ein und erlauben ein schrittweises Aufwärtslaufen der Kaskade. Ein Abweichen vom strengen Vorgänger-Nachfolger-Prinzip wird auch dann erforderlich, wenn in der aktuellen Phase Handlungsbedarf erkennbar wird, der grundsätzlich einer früheren Phase zugeordnet ist, z. B. Anpassungen im Systementwurf oder im Benutzerhandbuch aufgrund von Erkenntnissen beim Testen.

Wasserfallmodelle werden allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen.

Geschichte

Das Wasserfallmodell stammt ursprünglich aus dem Bau- und Produktionsprozess, hochstrukturierte Prozesse für Aufgaben, in denen späte Änderungen prohibitiv teuer oder sogar unmöglich sind. Nachdem zum Zeitpunkt der ersten Beschreibung des Wasserfallmodells kein formaler Softwareentwicklungsprozess existierte, wurden die bei Bau- und Produktion verwendeten Prozesse einfach für Softwareentwicklung adaptiert.^[1]

Die erste bekannte Beschreibung des Wasserfallmodells in der Softwareentwicklung wurde von Herbert D. Benington beim Symposium on advanced programming methods for digital computers am 29. Juni 1956 im Rahmen eines Vortrages über die Entwicklung einer Software für SAGE gegeben.^[2] 1983 wurde der Vortrag neu aufgelegt, mit einem Vorwort von Benington, in dem er beschreibt, dass der Prozess nicht strikt von oben nach unten durchgespielt wurde, sondern auf einem Prototyp basierte.^[3]

Die erste formale Beschreibung des Wasserfallmodells wird Winston W. Royce zugeschrieben, obwohl dieser in seinem 1970 erschienenen Artikel den Namen Wasserfall nicht verwendete.^[4] Er beschrieb das Modell als verbesserungswürdig und schlug folgende Änderungen vor:

• Einfügen einer Designphase, die der Analysephase vorgelagert ist, in der eine frühe Simulation (Prototyp) des schlussendlichen Produktes ebenfalls mittels desselben Modells umgesetzt und dokumentiert wird.
• Planung, Messung und Überwachung des Tests, um sicherzustellen, dass der Test seinen Aufgaben nachkommt.
• Formale und laufende Einbeziehung des Kunden in Form von Reviews.

Phasen

1. Anforderungsanalyse und -spezifikation resultiert im Lastenheft
2. Systemdesign und -spezifikation resultiert in der Softwarearchitektur
3. Programmierung und Modultests resultiert in der eigentlichen Software
4. Integrations- und Systemtest
5. Auslieferung, Einsatz und Softwarewartung

Eine andere Variante macht daraus sechs Schritte:

1. Planung (mit Erstellung des Lastenhefts, Projektkalkulation und Projektplan) (Systems Engineering)
2. Definition (mit Erstellung des Pflichtenhefts, Produktmodell, GUI-Modell und evtl. schon Benutzerhandbuch)
3. Entwurf (UML, Struktogramme) (Design)
4. Implementierung (Programmierung)
5. Testen (Testprotokoll)
6. Einsatz und Wartung (Maintenance)

„Definition und Entwurf“ entsprechen dabei ungefähr dem untergliederten Punkt „Systemdesign und -spezifikation“ in der ersten Variante, während die zweite Variante die zwei möglichen Ebenen des Softwaretestens (auf Modul- und Gesamtsystemebene) zusammenfasst.

Eigenschaften

1. Aktivitäten sind 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 Wasserfallmodell ist ein „dokumentgetriebenes“ 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 und verständlich.
6. Eine Benutzerbeteiligung ist 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.

Vorteile

• Klare Abgrenzung der Phasen
• Einfache Möglichkeiten der Planung und Kontrolle
• Klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen

Probleme und Nachteile

• Abgrenzungsproblem: Klar voneinander abgegrenzte Phasen sind häufig unrealistisch – der Übergang zwischen ihnen ist fließend: Teile eines Systems können sich noch in der Planung befinden, während andere schon in der Ausführung oder im Gebrauch sind.
• Abfolgeproblem: Die einzelnen Phasen laufen in der Theorie nacheinander ab, in der Praxis sind jedoch Rückschritte oft unvermeidlich.
• Unflexibel gegenüber Änderungen und im Vorgehen (Phasen müssen sequenziell abgearbeitet werden)
• Frühes Festschreiben der Anforderungen ist oft problematisch, da es eventuell zu teuren Änderungen führt (mehrmals wiederholtes Durchlaufen des Prozesses bei Änderungen)
• Einführung des Systems sehr spät nach Beginn des Entwicklungszyklus, deshalb ein später Return on Investment
• Durch die Einführung des vollständigen Systems zu einem bestimmten Zeitpunkt (Big Bang) werden Fehler unter Umständen erst spät erkannt und müssen mit erheblichem Aufwand entfernt werden.

Da es schwierig ist, bereits zu Projektbeginn alles endgültig und im Detail festzulegen, besteht das Risiko, dass das letztendlich fertiggestellte Ergebnis (z. B. Software) nicht den tatsächlichen Anforderungen entspricht. Um dem zu begegnen, wird oftmals ein unverhältnismäßig hoher Aufwand in der Analyse- und Konzeptionsphase betrieben. Zudem erlaubt das Wasserfallmodell nicht bzw. nur sehr eingeschränkt, im Laufe des Projekts Änderungen aufzunehmen. Das fertiggestellte Ergebnis bildet folglich nicht den aktuellen, sondern den Anforderungsstand zu Projektbeginn ab. Da größere Softwareprojekte meist auch eine sehr lange Laufzeit haben, kann es vorkommen, dass die neue Software bereits zum Zeitpunkt ihrer Einführung inhaltlich veraltet ist.

Andere Vorgehensmodelle

Wegen der teilweise gravierenden Nachteile des Wasserfallmodells mit teilweise erheblichen wirtschaftlichen Konsequenzen hat die IT-Industrie eine Vielfalt alternativer oder ergänzender Vorgehensweisen, Softwaretechnologien, Vorschläge und Hilfsmittel entwickelt. Beispiele hierfür sind:

• Spiralmodell (Weiterentwicklung)
• Rational Unified Process
• Extreme Programming
• Agile Softwareentwicklung
• Iteratives Prototyping und Evolutionäres Prototyping
• Weitgehende Verwendung von konfigurierbarer Standardsoftware, z. B. für das Workflow-Management oder die Benutzerverwaltung
• Auf die Entwicklungsphase ausgeweitetes Veränderungsmanagement
• Auslagerung weniger priorisierter Teilaufgaben an Power-User, siehe auch unter End-user Computing
• Ausgeprägte Modularisierung, bis hin zum Aufsplitten großer in kleinere, besser überschaubare Projekte mit kurzer Laufzeit
• V-Modell

Siehe auch

• Vorgehensmodell zur Softwareentwicklung
• Liste von Softwareentwicklungsprozessen

Literatur

• Karl Pfetzing, Adolf Rohde: Ganzheitliches Projektmanagement. 5. Auflage. Gießen 2014, ISBN 978-3-921313-90-9. 

Weblinks

• Beschreibung Wasserfallmodell Institut für Gestaltungs- und Wirkungsforschung
• Winston W. Royce: Managing the development of large Software Systems. (PDF; 436 kB)

Einzelnachweise

1. ↑ Herbert D. Benington: Production of Large Computer Programs. In: IEEE Educational Activities Department (Hrsg.): IEEE Annals of the History of Computing. Band 5, Nr. 4, 1. Oktober 1983, S. 350–361, doi:10.1109/MAHC.1983.10102 (englisch, usc.edu [PDF; abgerufen am 13. Juni 2013]).  Production of Large Computer Programs (Memento desOriginals vom 18. Juli 2011 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/sunset.usc.edu
2. ↑ United States Navy Mathematical Computing Advisory Panel (Hrsg.): Symposium on advanced programming methods for digital computers. 26. Juni 1956, OCLC 10794738 (englisch). 
3. ↑ Herbert D. Benington: Production of Large Computer Programs. In: IEEE Annals of the History of Computing. Band 5, Nr. 4. IEEE Educational Activities Department, 1. Oktober 1983, S. 350–361, doi:10.1109/MAHC.1983.10102 (englisch, usc.edu [PDF; abgerufen am 13. Juni 2013]).  Production of Large Computer Programs (Memento desOriginals vom 18. Juli 2011 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/sunset.usc.edu
4. ↑ Winston Royce: Managing the Development of Large Software Systems. Hrsg.: Proceedings, IEEE WESCON. 26. Auflage. Institute of Electrical and Electronics Engineers, August 1970, S. 328–338 (englisch, typepad.com [PDF; abgerufen am 13. Juni 2013]).