Was ist das Wasserfallmodell?

Das Wasserfallmodell ist ein Vorgehensmodell der Softwareentwicklung, bei dem ein Projekt in feste Phasen aufgeteilt wird, die streng nacheinander ablaufen: Anforderungen, Entwurf, Umsetzung, Test, Einführung und Betrieb. Jede Phase endet mit einem geprüften Ergebnis, das die nächste auslöst. Wie Wasser über Stufen fließt die Arbeit nur in eine Richtung.

Obwohl agile Methoden heute verbreiteter sind, begegnet Ihnen das Wasserfallmodell weiterhin: in Ausschreibungen, in regulierten Branchen und überall dort, wo ein Ergebnis vertraglich genau feststehen muss.

Die Phasen des Wasserfallmodells

Die Zahl und Benennung der Phasen variiert je nach Quelle. Üblich ist diese Abfolge:

1. Anforderungsanalyse. Was soll die Software können? Ergebnis ist das Lastenheft des Auftraggebers.
2. Systementwurf. Wie wird es umgesetzt? Der Auftragnehmer beschreibt Lösung und Technik im Pflichtenheft und legt die Softwarearchitektur fest.
3. Implementierung. Die Entwickler setzen den Entwurf in Code um.
4. Test. Die fertige Software wird gegen die Anforderungen geprüft.
5. Einführung. Abnahme, Installation, Schulung, Datenübernahme.
6. Betrieb und Wartung. Fehlerbehebung und kleinere Anpassungen im laufenden Einsatz.

Zwischen den Phasen stehen Meilensteine mit Dokumenten und Freigaben. Erst wenn eine Phase abgeschlossen und abgenommen ist, beginnt die nächste.

Herkunft und das V-Modell

Als Ursprung gilt ein Aufsatz von Winston W. Royce aus dem Jahr 1970. Bemerkenswert: Royce beschrieb das reine Nacheinander als riskant und empfahl Rückkopplungen zwischen den Phasen. In der Praxis setzte sich trotzdem die strenge Variante durch, weil sie sich gut planen und abrechnen ließ.

Eine Weiterentwicklung ist das V-Modell: Jeder Entwurfsphase steht eine Testphase gegenüber, etwa den Anforderungen der Abnahmetest und dem Detailentwurf der Modultest. In Deutschland ist mit dem V-Modell XT eine Fassung verbreitet, die für IT-Projekte des Bundes entwickelt wurde und in öffentlichen Projekten bis heute eine Rolle spielt.

Vor- und Nachteile

Das Kernproblem: Das Modell setzt voraus, dass alle Anforderungen am Anfang bekannt und richtig sind. Bei neuer Software für echte Arbeitsabläufe ist das selten der Fall. Wer seine Anforderungen erst sieht, wenn die Software fertig ist, merkt oft zu spät, dass sie anders gemeint waren.

Wann Wasserfall heute passt – Beispiele

• Gesetzlich vorgegebene Funktionen. Eine Schnittstelle, die Rechnungen im Format XRechnung an eine Behörde übermittelt, folgt einer festen Norm. Die Anforderungen ändern sich während des Projekts kaum.
• Öffentliche Ausschreibungen. Ein Landratsamt vergibt ein Fachverfahren mit ausführlichem Leistungsverzeichnis. Das Vergabeverfahren verlangt einen festen Leistungsumfang vorab.
• Hardwarenahe Projekte. Steuerungssoftware für eine Maschine, deren Mechanik feststeht, lässt sich gut in Phasen planen, weil nachträgliche Änderungen ohnehin teuer wären.
• Kleine, klar umrissene Aufträge. Eine Datenübernahme von System A nach System B mit bekannter Struktur braucht keine iterativen Schleifen.

Wasserfall oder agil?

Die agile Softwareentwicklung kehrt das Prinzip um: kurze Abschnitte, früh nutzbare Zwischenstände, Änderungen als Normalfall. Die Frage ist selten „entweder – oder“. Viele Projekte kombinieren beides: Ziel, Budgetrahmen und Pflichtanforderungen werden vorab festgelegt, die Umsetzung erfolgt in Etappen mit Vorführungen. So bleiben Planbarkeit und Vertragssicherheit erhalten, ohne dass Fehler bis zur Abnahme unentdeckt bleiben.

Eine einfache Faustregel: Je besser Sie heute schon wissen, wie die fertige Software aussehen muss, desto eher trägt ein Phasenmodell. Je mehr sich erst im Gebrauch zeigt, desto wichtiger werden kurze Schleifen.

Typische Stolpersteine

• Lastenheft als Wunschliste. Wenn alle Abteilungen ihre Wünsche ungeprüft eintragen, wird das Projekt groß, teuer und langsam.
• Test ganz am Ende. Wird erst nach Monaten getestet, stapeln sich die Fehler. Auch im Wasserfall lohnen Zwischentests einzelner Module.
• Abnahme als Formsache. Wird die Abnahme einer Phase unter Zeitdruck durchgewunken, wandern ungeklärte Punkte in die nächste Phase – und werden dort teurer.
• Änderungsverfahren ohne Regeln. Änderungen kommen trotzdem. Fehlt ein geregeltes Verfahren mit Aufwandsschätzung, entstehen Streit und Nachträge.

In der Praxis: Planbarkeit ohne späte Überraschungen

Wenn wir Individualsoftware entwickeln, wählen wir das Vorgehen nach Ihrem Vorhaben. Steht der Umfang fest, etwa bei einer genormten Schnittstelle, arbeiten wir mit klaren Phasen und Abnahmen. Ist der Bedarf noch in Bewegung, kombinieren wir einen festen Rahmen mit kurzen Etappen. Welche Vertragsform zu welchem Vorgehen passt, erklärt der Beitrag Werkvertrag oder Dienstvertrag im IT-Projekt. Geht es um einen öffentlichen Auftrag mit festem Leistungsverzeichnis, unterstützt Sie TenderDach bei Suche und Unterlagen.

Häufige Fragen

Ist das Wasserfallmodell veraltet?

Nicht grundsätzlich. Für Vorhaben mit feststehenden Anforderungen ist es weiterhin sinnvoll. Für neue Software mit unklarem Bedarf gilt es als zu starr.

Was ist der Unterschied zwischen Wasserfall und V-Modell?

Das V-Modell ordnet jeder Entwurfsphase eine passende Testphase zu. Dadurch wird früh festgelegt, wie später geprüft wird. Der Ablauf bleibt aber ebenfalls phasenweise.

Welche Dokumente entstehen im Wasserfallmodell?

Typisch sind Lastenheft, Pflichtenheft, Entwurfsdokumente, Testprotokolle und ein Abnahmeprotokoll. Sie machen den Projektstand nachvollziehbar und dienen bei Streit als Beleg, was vereinbart war.

Kann man mitten im Projekt auf agil umstellen?

Ja, das kommt vor, etwa wenn sich im Test grundlegende Missverständnisse zeigen. Dafür müssen Vertrag, Abnahmeregeln und Rollen angepasst werden.