Wasserfallmodell

Grundidee und Einsatzbereich

Das Wasserfallmodell ist ein lineares, nicht iteratives Vorgehensmodell, das besonders in der Softwareentwicklung eingesetzt wird. Ein Projekt wird in aufeinanderfolgende Phasen gegliedert. Die Ergebnisse einer Phase werden wie bei mehreren Kaskaden eines Wasserfalls an die nächste Phase weitergegeben und sind dort verbindliche Vorgaben.

Jede Phase besitzt vordefinierte Start- und Endpunkte sowie eindeutig festgelegte Ergebnisse. Meist wird außerdem beschrieben, welche Aktivitäten zur Erzeugung dieser Ergebnisse erforderlich sind. Zu bestimmten Meilensteinen und am Ende einer Phase werden die vorgesehenen Entwicklungsdokumente im Rahmen des Projektmanagements verabschiedet.

Das Modell eignet sich vor allem dann, wenn Anforderungen, Leistungen und Abläufe bereits in der Planungsphase relativ präzise beschrieben werden können. Erweiterte Varianten, etwa das Wasserfallmodell mit Rücksprung, erlauben ein schrittweises Zurückgehen in frühere Phasen. Das kann notwendig werden, wenn beim Testen Anpassungen am Systementwurf oder am Benutzerhandbuch erforderlich sind.

Phasen und Ergebnisse

Eine häufig verwendete Variante umfasst fünf Phasen:

• Anforderungsanalyse und -spezifikation: Ergebnis ist das Lastenheft.
• Systemdesign und -spezifikation: Ergebnis ist die Softwarearchitektur.
• Programmierung und Modultests: Ergebnis ist die eigentliche Software.
• Integrations- und Systemtest.
• Auslieferung, Einsatz und Softwarewartung.

Eine andere Variante unterteilt den Ablauf in sechs Schritte:

• Planung mit Lastenheft, Projektkalkulation und Projektplan (Systems Engineering).
• Definition mit Pflichtenheft, Produktmodell, GUI-Modell und eventuell bereits dem Benutzerhandbuch.
• Entwurf, beispielsweise mit UML und Struktogrammen (Design).
• Implementierung, also Programmierung.
• Testen mit Testprotokoll.
• Einsatz und Wartung (Maintenance).

In der sechsstufigen Variante entsprechen Definition und Entwurf ungefähr dem in der ersten Variante zusammengefassten Bereich Systemdesign und -spezifikation. Die beiden möglichen Ebenen des Softwaretestens – auf Modul- und auf Gesamtsystemebene – werden dort zusammengefasst.

Zentrale Eigenschaften

Die Aktivitäten werden in der vorgegebenen Reihenfolge und vollständig durchgeführt. Der Entwicklungsablauf ist sequenziell: Eine Aktivität muss beendet sein, bevor die nächste beginnt. Das Modell orientiert sich am Top-down-Verfahren, bei dem von übergeordneten Vorgaben schrittweise zu detaillierteren Bestandteilen vorgegangen wird.

Am Ende jeder Aktivität steht ein fertiggestelltes Dokument. Deshalb ist das Wasserfallmodell dokumentgetrieben. Seine klare Struktur macht es einfach und verständlich.

Eine Beteiligung des Benutzers oder Auftraggebers ist vor allem in der Anfangsphase vorgesehen. Danach erfolgen Entwurf und Implementierung grundsätzlich ohne weitere Beteiligung. Spätere Änderungswünsche gelten in dieser Sichtweise als Neuaufträge.

Entstehung und Weiterentwicklung

Das Wasserfallmodell stammt ursprünglich aus Bau- und Produktionsprozessen. Dort wurden hochstrukturierte Abläufe für Aufgaben verwendet, bei denen späte Änderungen prohibitiv teuer oder sogar unmöglich sein können. Da es zur Zeit der ersten Beschreibung noch keinen formalen Softwareentwicklungsprozess gab, wurden diese Abläufe auf die Softwareentwicklung übertragen.

Die erste bekannte Beschreibung des Modells in der Softwareentwicklung stammt von Herbert D. Benington. Er stellte es am 29. Juni 1956 beim Symposium on advanced programming methods for digital computers in einem Vortrag über die Entwicklung einer Software für SAGE vor. Der Vortrag wurde 1983 neu aufgelegt. In einem Vorwort erklärte Benington, dass der Prozess nicht streng von oben nach unten durchlaufen wurde, sondern auf einem Prototyp basierte.

Die erste formale Beschreibung wird Winston W. Royce zugeschrieben. In seinem Artikel von 1970 verwendete er den Namen „Wasserfall“ nicht. Er hielt das Modell für verbesserungswürdig und schlug vor, eine Designphase vor der Analysephase einzufügen, in der eine frühe Simulation beziehungsweise ein Prototyp des späteren Produkts nach demselben Modell umgesetzt und dokumentiert wird. Außerdem sollten Tests geplant, gemessen und überwacht sowie Kunden durch formale und fortlaufende Reviews einbezogen werden.

Vorteile, Probleme und Alternativen

Zu den Vorteilen gehören die klare Abgrenzung der Phasen, einfache Möglichkeiten zur Planung und Kontrolle sowie eine klare Abschätzung von Kosten und Umfang, sofern die Anforderungen stabil sind.

In der Praxis entstehen jedoch mehrere Schwierigkeiten. Die Grenzen zwischen Phasen sind häufig unrealistisch und die Übergänge fließend: Teile eines Systems können noch geplant werden, während andere bereits ausgeführt werden oder im Gebrauch sind. Außerdem sind Rückschritte entgegen der theoretisch strikt nacheinander verlaufenden Abfolge oft unvermeidlich.

Das Modell ist gegenüber Änderungen und auch im Vorgehen unflexibel. Anforderungen werden früh festgeschrieben; spätere Änderungen können teuer sein und ein wiederholtes Durchlaufen des Prozesses erfordern. Das System wird erst spät im Entwicklungszyklus eingeführt, wodurch sich der Return on Investment verspätet. Durch die vollständige Einführung zu einem bestimmten Zeitpunkt („Big Bang“) werden Fehler möglicherweise erst spät erkannt und müssen dann mit erheblichem Aufwand entfernt werden.

Da zu Projektbeginn oft nicht alles endgültig und detailliert festgelegt werden kann, besteht das Risiko, dass das fertige Ergebnis nicht den tatsächlichen Anforderungen entspricht. Häufig wird deshalb ein unverhältnismäßig hoher Aufwand in Analyse und Konzeption investiert. Das Ergebnis bildet unter Umständen den Anforderungsstand zu Projektbeginn statt den aktuellen Bedarf ab und kann bei langen Projekten bereits bei der Einführung inhaltlich veraltet sein.

Wegen dieser teilweise gravierenden Nachteile und der möglichen wirtschaftlichen Folgen wurden alternative oder ergänzende Ansätze entwickelt. Genannt werden unter anderem das Spiralmodell als Weiterentwicklung, der Rational Unified Process, Extreme Programming, agile Softwareentwicklung, iteratives und evolutionäres Prototyping sowie das V-Modell. Weitere Ansätze sind konfigurierbare Standardsoftware, Veränderungsmanagement über die Entwicklungsphase hinaus, die Auslagerung weniger priorisierter Aufgaben an Power-User und eine starke Modularisierung, bei der große Vorhaben in kleinere Projekte mit kürzerer Laufzeit aufgeteilt werden.