Als Wasserfallmodell bezeichnet man ein sequenzielles Vorgehensmodell, mit dem sich Entwicklungen anhand aufeinanderfolgender Phasen abbilden lassen.
Das Wasserfallmodell (englisch: waterfall model) ist ein lineares Vorgehensmodell, das Entwicklungsprozesse in aufeinanderfolgende Projektphasen unterteilt. Im Gegensatz zu iterativen Modellen wird jede Phase nur einmal durchlaufen. Die Ergebnisse einer jeden Vorgängerphase gehen als Vorannahmen in die Folgephase ein. Zur Anwendung kommt das Wasserfallmodell insbesondere in der Software-Entwicklung.
Die Entwicklung des klassischen Wasserfallmodells wird dem Computerwissenschaftler Winston W. Royce zugeschrieben. Royce jedoch ist nicht der Erfinder. Stattdessen beinhaltet sein 1970 veröffentlichter Aufsatz „Managing the Development of Large Software Systems“ eine kritische Auseinandersetzung mit linearen Vorgehensmodellen. Als Alternative stellt Royce ein iterativ-inkrementelles Modell vor, bei dem jede Phase auf die vorhergehende zurückgreift und deren Ergebnisse verifiziert.
Royce schlägt ein Modell mit sieben Phasen vor, das in mehreren Durchgängen (Iterationen) durchlaufen wird:
Das als Wasserfallmodell bekannt gewordene Vorgehensmodell orientiert sich an den von Royce definierten Phasen, sieht aber nur eine Iteration vor.
In dem von Royce verfassten Aufsatz kommt der Begriff Wasserfall nicht einmal vor.
Große Bekanntheit erlangte das Wasserfallmodell durch den US-Standard DoD-STD-2167. Dieser stützt sich auf eine stark simplifizierte Form des von Royce entwickelten Vorgehensmodells, das von den Autoren nicht ausreichend erfasst wurde. Grund dafür war das mangelnde Verständnis iterativ-inkrementeller Modelle, wie David Maibor – einer der Autoren des Standards – später zugab.
In der Praxis kommen verschiedene Versionen des Wasserfallmodells zum Einsatz. Gängig sind Modelle, die Entwicklungsprozesse in fünf Phasen unterteilen. Die von Royce definierten Phasen 1, 2 und 3 werden mitunter als Anforderungsanalyse in einer Projektphase zusammengefasst.
Die folgende Abbildung veranschaulicht, warum das lineare Vorgehensmodell als „Wasserfallmodell“ bezeichnet wird.
Erweiterungen des einfachen Wasserfallmodells ergänzen das Grundmodell um iterative Funktionen – beispielsweise um Rücksprünge, die es ermöglichen, die Ergebnisse einer jeden Phase mit den aus der Vorgängerphase gewonnenen Annahmen abzugleichen und somit zu verifizieren.
Im Wasserfallmodell reihen sich die einzelnen Phasen eines Entwicklungsprozesses in einer Kaskade aneinander. Jede Phase schließt mit einem Zwischenergebnis (Meilenstein) ab – beispielsweise mit einem Anforderungskatalog in Form eines Lastenhefts, mit der Spezifikation einer Software-Architektur oder mit einer Anwendung im Alpha oder Beta-Stadium.
Jedes Softwareprojekt beginnt mit einer Analysephase, die eine Machbarkeitsstudie und eine Anforderungsdefinition umfasst. In der Machbarkeitsstudie wird das Software-Projekt bezüglich Kosten, Ertrag und Realisierbarkeit eingeschätzt. Aus der Machbarkeitsstudie gehen ein Lastenheft (eine grobe Beschreibung der Anforderungen), ein Projektplan und die Projektkalkulation hervor sowie ggf. ein Angebot für den Auftraggeber.
Anschließend folgt eine detaillierte Anforderungsdefinition, die eine Ist-Analyse und ein Soll-Konzept beinhaltet. Während Ist-Analysen den Problembereich skizzieren, wird im Soll-Konzept definiert, welche Funktionen und Eigenschaften das Software-Produkt bieten muss, um den Anforderungen gerecht zu werden. Zu den Ergebnissen der Anforderungsdefinition gehören beispielsweise ein Pflichtenheft, eine detaillierte Beschreibung, wie die Anforderungen an das Projekt zu erfüllen sind, sowie ein Plan für Akzeptanztest.
Abschließend sieht die erste Phase des Wasserfallmodells eine Analyse der Anforderungsdefinition vor, in der komplexe Probleme in kleine Teilaufgaben zerlegt und entsprechende Lösungsstrategien erarbeitet werden.
Die Design-Phase dient der Ausarbeitung eines konkreten Lösungskonzepts auf Basis der zuvor ermittelten Anforderungen, Aufgaben und Strategien. Software-Entwickler erarbeiten in dieser Phase die Software-Architektur sowie einen detaillierten Bauplan der Software und konzentrieren sich dabei auf konkrete Komponenten wie Schnittstellen, Frameworks oder Bibliotheken. Das Ergebnis der Design-Phase umfasst ein Entwurfsdokument mit Software-Bauplan sowie Testplänen für einzelne Komponenten.
Realisiert wird die in der Design-Phase konzipierte Software-Architektur in der Implementierungsphase, die Software-Programmierung, Fehlersuche und Modultests umfasst. In der Implementierungsphase wird der Software-Entwurf in der gewünschten Programmiersprache umgesetzt. Einzelne Komponenten werden separat entwickelt, im Rahmen von Modultest überprüft und Schritt für Schritt in das Gesamtprodukt integriert. Das Ergebnis der Implementierungsphase ist ein Software-Produkt, das in der nachfolgenden Phase zum ersten Mal als Gesamtprodukt getestet wird (Alpha-Test).
Die Testphase beinhaltet die Integration der Software in die gewünschte Zielumgebung. In der Regel werden Software-Produkte zunächst als Beta-Version an ausgewählte Endbenutzer ausgeliefert (Beta-Tests). Ob die Software die zuvor definierten Anforderungen erfüllt, lässt sich mithilfe der in der Analysephase entwickelten Akzeptanztests ermitteln. Ein Software-Produkt, das Beta-Tests erfolgreich absolviert hat, ist bereit für den Release.
Nach erfolgreichem Abschluss der Testphase wird die Software für den Betrieb im Produktiveinsatz freigegeben. Die letzte Phase des Wasserfallmodells schließt Auslieferung, Wartung und Verbesserung der Software ein.
Das Wasserfallmodell bietet eine übersichtliche Organisationsstruktur für Entwicklungsprojekte, bei der die einzelnen Projektphasen klar voneinander abgegrenzt sind. Da jede Phase mit einem Meilenstein abschließt, ist der Entwicklungsprozess leicht nachvollziehbar. Der Schwerpunkt des Modells liegt auf der Dokumentation der Prozessschritte. Erarbeitetes Wissen wird in Anforderungs- oder Entwurfsdokumenten festgehalten.
In der Theorie soll das Wasserfallmodell durch im Vorfeld erstellte sorgfältige Planung die Voraussetzungen für eine schnelle und kostengünstige Durchführung von Projekten schaffen. Der Nutzen des Wasserfallmodells für den Praxiseinsatz ist jedoch umstritten. Zum einen sind Projektphasen in der Software-Entwicklung nur selten klar voneinander abgegrenzt. Gerade bei komplexen Software-Projekten, sind Entwickler häufig damit konfrontiert, dass sich die verschiedenen Komponenten einer Anwendung zur selben Zeit in verschiedenen Entwicklungsphasen befinden. Zum anderen entspricht der lineare Ablauf des Wasserfallmodells oft nicht den realen Gegebenheiten.
Streng genommen sind Anpassungen im Laufe des Projekts beim Wasserfallmodell nicht vorgesehen. Ein Software-Projekt, bei dem sämtliche Details der Entwicklung bereits zu Projektbeginn festgelegt werden, ließe sich jedoch nur dann erfolgreich beenden, wenn schon zu Beginn viel Zeit und Kosten in Analyse und Konzeption investiert werden würden. Hinzu kommt, dass sich große Software-Projekte mitunter über mehrere Jahre erstrecken und ohne eine regelmäßige Anpassung an aktuelle Entwicklungen Ergebnisse hervorbringen würden, die bereits bei der Einführung veraltet wären.
Vorteile | Nachteile |
✔ Einfache Struktur durch klar abgegrenzte Projektphasen. | ✘ Komplexe oder mehrschichtige Projekte lassen sich nur selten in klar abgegrenzte Projektphasen unterteilen. |
✔ Gute Dokumentation des Entwicklungsprozesses durch klar definierte Meilensteine. | ✘ Geringer Spielraum für Anpassungen des Projektablaufs aufgrund veränderter Anforderungen. |
✔ Kosten und Arbeitsaufwand lassen sich bereits bei Projektbeginn abschätzen. | ✘Der Endanwender wird erst nach der Programmierung in den Produktionsprozess eingebunden. |
✔ Projekte die nach dem Wasserfallmodell strukturiert werden, lassen sich auf der Zeitachse gut abbilden. | ✘Fehler werden mitunter erst am Ende des Entwicklungsprozesses erkannt. |
Wasserfallmodelle nutzt man vor allem bei Projekten, bei denen sich Anforderung und Abläufe bereits in der Planungsphase präzise beschreiben lassen und bei denen davon auszugehen ist, dass sich die Vorannahmen während des Projektablaufs höchstens geringfügig ändern. Streng lineare Vorgehensmodelle eigenen sich somit in erster Line für kleine, einfache und klar strukturierte Software-Projekte. Zu diesem Ergebnis kam Royce bereits in den 1970er-Jahren. Die von ihm vorgeschlagene Alternative zum linearen Vorgehensmodell, das später als Wasserfallmodell bekannt werden sollte, beinhalte daher drei wesentliche Erweiterungen:
Laut Royce sollten die Ergebnisse einer jeden Projektphase umgehend mit den zuvor erarbeiteten Dokumenten abgeglichen und verifiziert werden – beispielsweise müsste bereits nach der Entwicklung eines Moduls sichergestellt werden, dass dieses den zuvor definierten Anforderungen entspricht, und nicht erst am Ende des Entwicklungsprozesses.
Das Wasserfallmodell sollte laut Royce mindestens zweimal durchlaufen werden: zunächst für die Entwicklung eines Prototyps und anschließend für die Entwicklung des eigentlichen Software-Produkts.
Als dritte Erweiterung des Wasserfallmodells forderte Royce in seinem Aufsatz eine Maßnahme, die heute zum Standardvorgehen in der Produktentwicklung gehört: Den Einbezug des Endabnehmers in den Produktionsprozess. Royce schlägt vor, den Benutzer an drei Stellen in den Software-Entwicklungsprozess mit einzubeziehen: Während der Planung der Software im Rahmen der Analysephase, zwischen dem Software-Design und der Implementierung und in der Testphase vor dem Release der Software.
Aufgrund des streng linearen Ablaufs der sequenziell aufeinanderfolgenden Projektphasen eignet sich das Wasserfallmodell – wenn überhaupt – lediglich für kleine Software-Projekte. Komplexe, mehrschichtige Prozesse hingegen lassen sich nicht abbilden. Im Laufe der Zeit wurden daher diverse Alternativansätze entwickelt.
Während Modelle wie das Spiralmodell oder das V-Modell als Weiterentwicklungen des klassischen Wasserfallmodells gelten, folgen Konzepte wie Extreme Programming, Agile Software-Entwicklung oder Iteratives Prototyping einem gänzlich anderen Ansatz und erlauben meist eine flexiblere Anpassung an aktuelle Veränderungen und neue Anforderungen.
Was ist eigentlich Scrum? Wer sich mit agilem Projektmanagement auseinandersetzt, kommt nicht an Scrum vorbei. Ursprünglich in der Software-Entwicklung eingesetzt, ist Scrum inzwischen auch in vielen anderen Bereichen zu Hause. Fans des Modells schwärmen von einer höheren Effizienz und mehr Transparenz und loben den offenen Ansatz des Frameworks. Auch Sie überlegen, in Ihrem Unternehmen...
Welches Team möchte nicht seinen Workflow verbessern? Mit Kanban haben Sie eine einfache agile Methode an der Hand. Hauptelemente des Systems: Visualisierung aller Aufträge am Kanban-Board, Ablehnung von Multitasking und stetige Verbesserung der Abläufe. Aber was ist Kanban genau und wie kann man die Methode konkret umsetzen? Wir stellen Kanban vor und erklären Ihnen das System.
Wie viel Zeit nehmen Sie sich für die Projektvorbereitung? Viele Unternehmen vernachlässigen die Basis für ihren Projekterfolg: das Anforderungsmanagement. Das rächt sich später, wenn Kunden diverse Änderungswünsche haben und der Projektfortschritt sich immer weiter verzögert. Erfahren Sie, welche Aufgaben ein solides (IT-)Anforderungsmanagement umfasst und warum sich dieser Aufwand unbedingt...
