Wasserfallmodell

Das Wasserfallmodell ist das älteste und bekannteste klassische Vorgehensmodell der Softwareentwicklung. Es durchläuft die sieben Phasen des SDLC, von der Planung bis zur Wartung, genau einmal, jeweils vollständig abgeschlossen, bevor die nächste Phase beginnt. Der Name stammt aus dieser Vorstellung: Wie Wasser, das eine Kaskade hinabfließt, geht die Arbeit nur in eine Richtung, von Phase zu Phase, ohne planmäßige Rücksprünge.

Herkunft

Das Wasserfallmodell wird meist auf einen Aufsatz von Winston W. Royce aus dem Jahr 1970 zurückgeführt, „Managing the Development of Large Software Systems“. Interessant dabei: Royce beschrieb dieses rein lineare Vorgehen vor allem, um es zu kritisieren. In seinem Aufsatz empfahl er bereits Rückkopplungsschleifen zwischen benachbarten Phasen und den Einsatz früher Prototypen, weil ein einmaliger, ungebrochener Durchlauf seiner Einschätzung nach bei größeren Projekten zu spät auf Fehler stößt. Übernommen und verbreitet wurde in der Praxis trotzdem vor allem die vereinfachte, rein lineare Lesart, unter anderem weil sie sich gut in Verträge, Meilensteinpläne und Behördenstandards der 1970er und 1980er Jahre einfügte, etwa in frühen Vorgaben des US-Verteidigungsministeriums für Softwareprojekte. Die von Royce selbst vorgeschlagene, aber seltener konsequent umgesetzte Variante mit expliziten Rückkopplungsschleifen zwischen benachbarten Phasen ist unter dem Namen „Iteratives Wasserfallmodell“ bekannt.

Ablauf

Im Wasserfallmodell folgen die SDLC-Phasen strikt aufeinander: Planung, Analyse, Design, Entwicklung, Test, Bereitstellung, Wartung. Jede Phase schließt mit einem verbindlichen Ergebnis ab, das die Grundlage für die nächste bildet, etwa einem Lastenheft aus der Analyse oder einem Architekturdokument aus dem Design. Ein häufig verwendetes Bild dafür ist das Meilenstein- oder Gate-Prinzip: Erst wenn eine Phase formal abgenommen ist, beginnt die nächste. Rücksprünge in eine bereits abgeschlossene Phase sind im Modell selbst nicht vorgesehen, in der Praxis aber natürlich trotzdem nötig, wenn sich etwa im Test grundlegende Fehler im Design zeigen.

Wann das Wasserfallmodell passt

Das Modell eignet sich besonders dort, wo Anforderungen zu Beginn bereits weitgehend feststehen und sich während des Projekts kaum noch ändern. Das ist häufig in folgenden Situationen der Fall:

• Regulierte Umfelder: Wenn eine lückenlose Dokumentation aller Entscheidungen und Übergänge verlangt wird, etwa aus Compliance- oder Zulassungsgründen.
• Festpreis- und Festumfang-Verträge: Wenn Auftraggeber und Auftragnehmer vorab einen klar abgegrenzten Leistungsumfang vereinbaren müssen.
• Sicherheitskritische Systeme: Wenn ein vollständiger Entwurf vor Beginn der Umsetzung geprüft und freigegeben werden muss, statt sich schrittweise anzunähern.
• Gut verstandene Domänen: Wenn ein Team ein Problem bereits aus vergleichbaren Projekten kennt und wenig fachliche Unsicherheit besteht.

Grenzen

Weil Test und Fehlersuche erst am Ende des Durchlaufs stattfinden, werden grundlegende Probleme im Design oder in den Anforderungen häufig erst spät sichtbar, zu einem Zeitpunkt, an dem Änderungen bereits deutlich aufwendiger sind als in einer früheren Phase. Fehlen belastbare Anforderungen zu Projektbeginn oder ändern sich die Rahmenbedingungen während der Laufzeit, gerät das Modell schnell unter Druck, weil es für Rücksprünge nicht konzipiert ist. Diese Schwächen sind ein zentraler Grund dafür, warum sich seit den 1990er-Jahren iterative und agile Vorgehensmodelle wie Scrum verbreitet haben.

Verwandte Modelle

Das V-Modell übernimmt die grundsätzlich lineare Struktur des Wasserfallmodells, stellt aber jeder Entwicklungsphase bewusst eine passende Testphase gegenüber, um Prüfschritte von Anfang an mitzudenken.