Wasserfallmodell: Phasen und Einsatz einfach erklärt

Ein Vorgehensmodell ist ein Plan für ein Softwareprojekt. Es teilt die Entwicklung in überschaubare Phasen auf, die zeitlich und inhaltlich begrenzt sind. Das Wasserfallmodell ist eines der ältesten Modelle und nimmt eine starre Abfolge der Phasen an. Es ist linear und nicht iterativ. Iterativ heißt: Ein Arbeitsschritt wird wiederholt und dabei verbessert. Im einfachen Wasserfallmodell wird jede Phase dagegen einmal durchlaufen.

Der Name kommt von der Darstellung: Die Phasen werden häufig als Kaskade gezeichnet, also als Stufen nach unten. Die Ergebnisse einer Stufe „fallen“ in die nächste und sind dort verbindliche Vorgaben. Jede Phase hat einen festgelegten Start und ein festgelegtes Ende mit eindeutig definierten Ergebnissen. Am Phasenende werden die vorgesehenen Dokumente im Projektmanagement verabschiedet. Das heißt, sie werden offiziell abgeschlossen.

Es gibt auch Varianten. Beim Wasserfallmodell mit Rücksprung darf man schrittweise in frühere Phasen zurückgehen. Das ist zum Beispiel nötig, wenn man beim Testen merkt, dass der Systementwurf angepasst werden muss.

Eine häufige Variante hat fünf Phasen. Phase 1 ist die Anforderungsanalyse und -spezifikation, sie führt zum Lastenheft. Phase 2 ist das Systemdesign und die -spezifikation, sie führt zur Softwarearchitektur. Das ist der Plan, wie der Programmaufbau aussehen soll. Phase 3 ist die Programmierung mit Modultests, sie führt zur eigentlichen Software. Phase 4 ist der Integrations- und Systemtest. Phase 5 ist Auslieferung, Einsatz und Softwarewartung.

Eine andere Variante hat sechs Schritte: Planung, Definition, Entwurf, Implementierung, Testen sowie Einsatz und Wartung. Dort entsteht beim Testen ein Testprotokoll. In der Definition entsteht das Pflichtenheft. Das Wasserfallmodell ist dokumentgetrieben: Am Ende jeder Aktivität steht ein fertiggestelltes Dokument.

Das Lastenheft schreibt der Auftraggeber, also der Besteller. Es sagt, was und wofür etwas gemacht werden soll. Das Pflichtenheft schreibt der Auftragnehmer, also der Hersteller. Es sagt, wie und womit er die Anforderungen lösen will. Erst wenn der Auftraggeber das Pflichtenheft akzeptiert, sollte die eigentliche Umsetzungsarbeit beginnen.

Der Auftraggeber ist in der Anfangsphase beteiligt. Danach erfolgen Entwurf und Implementierung ohne ihn. Weitere Änderungen stellen danach Neuaufträge dar.

Das Wasserfallmodell stammt ursprünglich aus dem Bau- und Produktionsprozess. Dort sind späte Änderungen prohibitiv teuer oder sogar unmöglich, also kaum bezahlbar. Es wird allgemein dort vorteilhaft angewendet, wo sich Anforderungen, Leistungen und Abläufe in der Planungsphase relativ präzise beschreiben lassen.

Vorteile sind die klare Abgrenzung der Phasen und einfache Möglichkeiten der Planung und Kontrolle. Außerdem gibt es eine klare Abschätzung von Kosten und Umfang bei stabilen Anforderungen.

Nachteile gibt es auch. Das Modell ist unflexibel gegenüber Änderungen. Frühes Festschreiben der Anforderungen ist oft problematisch, da es eventuell zu teuren Änderungen führt. Das System wird sehr spät nach Projektbeginn eingeführt, deshalb zeigt sich der Ertrag für das investierte Geld spät. Das ganze System kommt auf einmal (Big Bang), deshalb werden Fehler unter Umständen erst spät erkannt. Das fertige Ergebnis zeigt den Anforderungsstand zu Projektbeginn. Bei größeren Projekten mit meist sehr langer Laufzeit kann die Software schon bei der Einführung inhaltlich veraltet sein.

Ein Vorgehensmodell garantiert keinen Projekterfolg. Es sollte an die Anforderungen angepasst und nicht zum Selbstzweck eingesetzt werden. Prüfe also immer: Sind die Anforderungen früh genau beschreibbar und stabil?

Agile Softwareentwicklung (von lateinisch „agilis“, flink, beweglich) will Risiken und Fehlentwicklungen verringern. Sie versucht, die Entwurfsphase auf ein Mindestmaß zu reduzieren und so früh wie möglich zu ausführbarer Software zu kommen. Diese wird in regelmäßigen, kurzen Abständen mit dem Kunden abgestimmt. Agile Entwicklung ist iterativ, also wiederholend, und inkrementell, das heißt, das Produkt wird schrittweise erweitert. Dazu kommen selbstorganisierende Teams.

Das Wasserfallmodell arbeitet dagegen nach einem festen Plan in Phasen. Man nennt solche Modelle plangetrieben. Im Agilen Manifest heißt es zum Beispiel: Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Agile Methoden eignen sich besonders gut, um auf geänderte Anforderungen zu reagieren. Nachträgliche Änderungen sind dort durch die in der Regel kurzen Zeiträume relativ leicht möglich. Auch plangetriebene Modelle regeln Änderungen, aber der Aufwand und die geforderte Dokumentation sind vergleichsweise höher.

Agil ist aber nicht automatisch besser. Klare inhaltliche Vorgaben wie ein Pflichtenheft sind bei agilem Vorgehen schwierig, weil die Anforderungen erst während des Projekts entwickelt werden. Agile Methoden werden manchmal fälschlicherweise als Allheilmittel bei Projektproblemen angesehen. Hinderungsgründe wie Interessen- oder Zielkonflikte können für agile genauso wie für traditionelle Verfahren gelten.