Wasserfall - Wasserfallmodell

Kaskadenmodellgerät

Das Wasserfallmodell, auch Waterfall genannt, ist einer der bekanntesten Ansätze zur Softwareentwicklung. Der Autor des Modells ist Winston Royce. Im Jahr 1970 beschrieb er das Wesentliche seiner Innovation in einem Artikel und beschrieb detailliert deren Vor- und Nachteile. An gleicher Stelle erläuterte er, wie dieses Modell zu einem iterativen Modell verfeinert werden kann. Im Wasserfallmodell laufen die Entwicklungsstufen zunächst in der folgenden Reihenfolge ab:

• Definition und Koordination von Anforderungen;
• Projektgenehmigung;
• Codierung;
• Erstellung einer funktionierenden Version des Softwareprodukts;
• Testen und Debuggen;
• Software Installation;
• Unterstützung.

Nach dem Wasserfallmodell erfolgt die Ausführung von Aktionen durch den Entwickler sequentiell – Punkt für Punkt. Zunächst wird daran gearbeitet, Softwareanforderungen in Form einer auszufüllenden Liste zu ermitteln und zu vereinbaren.

Danach erfolgt der Übergang zur Erstellung und Genehmigung des Projekts, in dessen Folge eine Dokumentation verfasst wird, die beschreibt, wie die zuvor vereinbarten Softwareanforderungen umzusetzen sind.

Ist der Entwurf abgeschlossen, übernehmen die Entwickler die Umsetzung. Als nächstes folgt die Zusammenführung des Codes – die Integration einzelner Projektteile, an denen verschiedene Teammitglieder gearbeitet haben.

Der nächste Schritt ist das Testen und Debuggen des Produkts. Zuvor gefundene Fehler werden hier behoben.

Abschließend wird das Programm installiert und unterstützt. Dabei geht es darum, bei Bedarf Änderungen an der Funktionalität vorzunehmen und festgestellte Fehler zu beheben.

Das Kaskadenmodell geht davon aus, dass Sie streng sequentiell zur nächsten Entwicklungsstufe übergehen können – erst nach Abschluss der vorherigen Aufgabe. Die Möglichkeit eines Rollbacks oder einer Inkonsistenz in den Phasen ist nicht vorgesehen.

Vorteile und Nachteile

Das Wasserfallmodell wird von Zeit zu Zeit wegen seiner mangelnden Flexibilität kritisiert. Vielen gefällt es nicht, weil darin das Ziel des Projektmanagements vorherrscht, während Termintreue, Kosten und Qualität der Entwicklung viel wichtiger sind.

Bei Großprojekten kommt dem Management jedoch oft eine größere Bedeutung zu, da es die Risiken des Projekts reduziert und die Transparenz der Arbeit erhöht.

Trotz der Mängel spezifiziert die 3. Version des PMBOK formal nur die Methodik des „Kaskadenmodells“. Andere Optionen, einschließlich iterativem Projektmanagement, werden nicht angeboten.

Vorteile des Wasserfallmodells:

• Teamentwicklung lässt sich leichter steuern. Der Kunde weiß, woran die Programmierer gerade arbeiten, er kann die Fristen und das Budget des Projekts ändern.
• Die Entwicklungskosten werden in der ersten Phase genehmigt. Nachdem alle Phasen der Implementierung vereinbart wurden, wird das Softwareprodukt kontinuierlich geschrieben.
• Erfahrene Tester sind nicht erforderlich. Für die Testphase können Sie die Programmdokumentation nutzen.

Nachteile des Wasserfallmodells:

• Da das Testen in der Phase des Abschlusses der Entwicklung beginnt, ist die Behebung eines Fehlers teurer als in der Anfangsphase, wenn ein Fehler entdeckt wird. Denn Tester finden einen Fehler erst, wenn der Entwickler den Code bereits fertig geschrieben hat, Texter hingegen die Dokumentation.
• Nach Abschluss der Entwicklung lernt der Kunde das fertige Produkt kennen. Dementsprechend kann er das Produkt erst bewerten, wenn es fast vollständig fertig ist. Gefällt ihm das Ergebnis nicht, verteuert sich das Projektbudget aufgrund des Korrekturbedarfs deutlich.
• Je mehr technische Dokumentation vorhanden ist, desto länger dauert die Fertigstellung der Arbeiten. Eine solche Dokumentation erfordert weitere Änderungen und Genehmigungen.

„Waterfall“ wird häufig in Projekten in der Medizin- und Luft- und Raumfahrtindustrie eingesetzt, wo bereits eine breite Dokumentenbasis vorhanden ist, auf deren Grundlage Anforderungen an neue Software erstellt werden können.

Bei der Verwendung des Wasserfallmodells geht es vor allem darum, detaillierte Anforderungen zu formulieren. Beim Testen sollte sich nicht herausstellen, dass irgendwo ein Fehler vorliegt, der sich nachteilig auf das gesamte Projekt auswirkt.