Wasserfall-Modell
Das Wasserfall-Modell ist eine Methode, Software in festen Schritten nacheinander zu entwickeln: erst planen, dann bauen, dann testen, dann ausliefern. Jeder Schritt wird abgeschlossen, bevor der nächste beginnt — das schafft Klarheit, macht spätere Änderungen aber teuer.
Wenn ein Unternehmen ein neues Computerprogramm entwickelt, muss es sich entscheiden, in welcher Reihenfolge gearbeitet wird. Das Wasserfall-Modell ist die älteste verbreitete Antwort auf diese Frage. Es teilt die Arbeit in feste Phasen: Zuerst wird aufgeschrieben, was das Programm können soll. Danach wird geplant, wie es innen aufgebaut ist. Erst dann wird programmiert, anschließend geprüft und zuletzt an die Kunden ausgeliefert. Der Name kommt vom Bild eines Wasserfalls: Das Wasser fließt von einer Stufe zur nächsten nach unten und nie wieder zurück nach oben.
Warum Firmen es geplant und trotzdem gefürchtet haben
Das Wasserfall-Modell macht ein Projekt vorhersagbar. Weil am Anfang alles aufgeschrieben wird, lassen sich Kosten und Termine früh nennen. Auftraggeber mögen das, weil sie einen Vertrag mit klaren Zusagen bekommen. Auch bei Behörden und in der Industrie ist diese Planbarkeit oft Pflicht.
Der Preis dafür ist Starrheit. Ein Fehler in der Planung fällt erst am Ende auf, wenn getestet wird. Dann ist die Arbeit von Monaten schon erledigt, und die Korrektur wird sehr teuer. Eine oft zitierte Faustregel besagt: Je später ein Fehler entdeckt wird, desto teurer ist er — im Extremfall um den Faktor hundert.
Genau daran sind viele große Softwareprojekte gescheitert. Kunden merkten erst bei der Auslieferung, dass sie eigentlich etwas anderes wollten. Als Gegenentwurf entstanden ab den 1990er-Jahren agile Methoden. Dort baut man kleine, benutzbare Teile in kurzen Runden von wenigen Wochen und fragt ständig nach Rückmeldung.
Die Stufen des Wasserfalls im Einzelnen
In der ersten Phase, der Anforderungsanalyse, sammeln Fachleute alle Wünsche des Auftraggebers. Das Ergebnis ist ein Dokument, oft Lastenheft genannt. In der zweiten Phase, dem Entwurf, legen Entwickler fest, aus welchen Bausteinen das Programm bestehen soll und wie diese zusammenarbeiten. Erst in der dritten Phase wird tatsächlich Programmcode geschrieben.
Danach folgt die Testphase. Hier wird geprüft, ob das fertige Programm wirklich das tut, was im ersten Dokument stand. Zum Schluss kommt die Auslieferung und der laufende Betrieb, bei dem Fehler nachträglich behoben werden. Charakteristisch ist, dass jede Phase mit einem schriftlichen Ergebnis endet, das abgenommen wird.
Ein häufiger Irrtum ist, dass Rücksprünge im Wasserfall verboten seien. Schon die frühen Beschreibungen erlaubten den Schritt zurück in die vorherige Phase. In der Praxis sind solche Rücksprünge aber unbeliebt, weil sie Termine und Budgets sprengen. Deshalb wirkt das Modell härter, als es gemeint war.
Wasserfall in Behörden, Autos und KI-Projekten
Man begegnet dem Modell überall dort, wo Fehler gefährlich oder Verträge streng sind. Steuergeräte in Autos, Medizintechnik und Flugzeugsoftware werden oft in dieser Form entwickelt. Auch öffentliche Ausschreibungen verlangen häufig eine vollständige Beschreibung vorab. In Deutschland gibt es dafür sogar einen eigenen Standard, das V-Modell XT.
In Nachrichten taucht der Begriff meist als Kritik auf. Wenn ein IT-Großprojekt Jahre zu spät kommt, heißt es oft, man habe zu lange nach dem Wasserfall-Prinzip gearbeitet. Umgekehrt werben Beratungsfirmen damit, Kunden von Wasserfall auf agile Arbeitsweisen umzustellen.
Bei Projekten mit künstlicher Intelligenz passt das Modell besonders schlecht. Ob ein Modell gut genug wird, weiß man erst, wenn man es mit echten Daten trainiert und ausprobiert hat. Solche Ergebnisse lassen sich nicht vorab in ein Lastenheft schreiben. Deshalb arbeiten KI-Teams fast immer in kurzen Schleifen aus Ausprobieren, Messen und Nachbessern. Viele Unternehmen mischen beides: Der grobe Rahmen wird nach Wasserfall geplant, die eigentliche Entwicklung läuft agil.