Dieser Artikel beschreibt eine Variante von Vorgehensmodellen im Sinn des Projektmanagements. Für den Bereich strategisches Marketing siehe Timing-Strategie (länderübergreifend).
Stufen des Wasserfallmodells (Beispiel)
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.
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. 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.
Die erste formale Beschreibung des Wasserfallmodells wird Winston W. Royce zugeschrieben, obwohl dieser in seinem 1970 erschienenen Artikel den Namen Wasserfall nicht verwendete. 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.
„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
Aktivitäten sind in der vorgegebenen Reihenfolge und in der vollen Breite vollständig durchzuführen.
Am Ende jeder Aktivität steht ein fertiggestelltes Dokument, d.h. das Wasserfallmodell ist ein „dokumentgetriebenes“ Modell.
Der Entwicklungsablauf ist sequenziell; d.h. jede Aktivität muss beendet sein, bevor die nächste anfängt.
Es orientiert sich am sogenannten Top-down-Verfahren.
Es ist einfach und verständlich.
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:
12Herbert D. Benington:Production of Large Computer Programs. In: IEEE Educational Activities Department (Hrsg.): IEEE Annals of the History of Computing. Band5, Nr.4, 1.Oktober 1983, S.350–361, doi:10.1109/MAHC.1983.10102 (englisch, sunset.usc.edu (Memento vom 18. Juli 2011 im Internet Archive) [PDF; 210kB; abgerufen am 13.Juni 2013]).
↑United States Navy Mathematical Computing Advisory Panel (Hrsg.):Symposium on advanced programming methods for digital computers. 26.Juni 1956, OCLC10794738 (englisch).
↑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; 1,5MB; abgerufen am 13.Juni 2013]).
