Wasserfall-Modell? LOL!

Continuous Architecture Eberhard Wolff  –  467 Kommentare

Das Wasserfall-Modell ist recht alt, aber taucht dennoch bei der Diskussion über Softwareentwicklungsprozesse immer noch sehr häufig auf. Die Geschichte dieses Modells ist weitgehend unbekannt – dabei zeigt sie die Herausforderungen des Modells und warum man es nicht nutzen sollte.

Das einfache Wasserfall-Modell beschreibt ein Prozessmodell für die Softwareentwicklung. Es hat folgende Eigenschaften:

  1. Der Prozess wird in einzelne Phasen wie Anforderungen, Design, Implementierung, Verifikation und Wartung unterteilt.
  2. Eine Phase baut auf den vollständigen Ergebnissen der vorherigen Phase auf. Daher lässt sich eine spätere Phase erst starten, wenn die vorherige Phase vollständig abgeschlossen ist
  3. Die Umsetzung geht vorwärts durch die Phasen. Jede Phase wird einmal ausgeführt.

Die Visualisierung ist dementsprechend ein Wasserfall, bei dem die Phasen von oben links nach unten rechts angeordnet sind. Das "Wasser" entspricht jeweils den Ergebnisdokumenten, die dann in die Folgephase einfließen. Die einzelnen Phasen können sich dabei in jedem Projekt unterscheiden.

Vorbedingung für dieses Modell ist, dass die Anforderungen sich nicht wesentlich ändern. Sonst geht schon das Ergebnis der ersten Phase von falschen Voraussetzungen aus und damit auch alle weiteren Phasen und deren Ergebnisse. Anforderungen sind in der Praxis oft nicht fest oder vollständig bekannt. Dann sind agile Methoden, die auf diesen Umstand Rücksicht nehmen, die bessere Wahl. Aber nehmen wir für den Rest des Texts an, dass dieser Umstand alleine das Wasserfall-Modell noch nicht ausschließt.
Ansätze für Softwareentwicklung können sich nur an dem Erfolg in der Praxis messen lassen. Die Frage ist nun, welche Erfahrungen es zum Wasserfall-Modell gibt.

Der Ursprung

Das Wasserfall-Modell für die Softwareentwicklung hat den Ursprung in den Fünfzigerjahren. Damals haben die USA das SAGE-System entworfen (Semi-Automatic Ground Environment). Es diente zur Koordination der Luftverteidigung insbesondere gegen einen möglichen Angriff der UdSSR. Im Wesentlichen sollte es ein umfassendes, konsolidiertes Bild aus den verschiedenen Radarstationen erzeugen und dann das Bekämpfen der Ziele koordinieren. Das ist ein Bereich, in dem die Anforderungen relativ klar und unveränderlich sein sollten.

Zu diesem Zeitpunkt gab es keine höheren Programmiersprachen, keine Terminals und kein Time Sharing. Es gab nur Lochkarten und Röhrenrechner. Jedes SAGE Direction Center bekam einen AN/FSQ-7 Computer. Das waren damals die leistungsfähigsten Computer mit einer Fläche von 2.000 m2, 49.000 Röhren, 75.000 Instruktionen pro Sekunde und einem Magnetkernspeicher von 65.536 32-Bit-Wörtern.
Weil Hardware damals um viele Größenordnungen teurer und weniger leistungsfähig war als heute, mussten Projekte bei der Unterstützung der Entwicklung viel sparsamer mit Rechenzeit umgehen. Daher können moderne Softwareentwicklungsprozesse viel mehr Rechenzeit für die Unterstützung von Entwickler:innen aufwenden.

Das SAGE-Projekt war kostspieliger als das Manhattan-Projekt zum Bau der Atombombe, gegen dessen Resultat es ja schützen sollte. Wesentliches Ergebnis war die Software mit insgesamt 0,5 Millionen Instruktionen. Ein Viertel des Codes ist das eigentliche System, der Rest diente zur Unterstützung der Entwicklung.

Wasserfall?

1956 beschrieb Herbert Benington die grundlegenden Ideen zur Implementierung dieses Systems. Das Paper beschreibt, in welchen Phasen die Implementierung stattfinden soll, und einen linearen Ablauf durch diese Phasen wie in einem Wasserfall-Modell. Diese Beschreibung nimmt jedoch nur circa zwei Seiten ein und stellt lediglich einen Teil der vorgestellten Arbeitsweisen dar. Darüber hinaus diskutiert es unter anderem eine Art Architektur und verschiedene Werkzeuge zur Entwicklung von Systemen.

Prinzipiell sind die Anforderungen für die SAGE-Software wahrscheinlich im Wesentlichen fest, sodass ein solches Modell nicht unsinnig erscheint. Auch wenn der Prozess in dem Paper nicht "Wasserfall-Modell" genannt wird, zeigt sich scheinbar ein relativer Erfolg des Wasserfall-Modells. Schließlich hat das Projekt Software geliefert, die auch genutzt wird, auch wenn das Projekt die ursprüngliche Deadline um ein Jahr gerissen hat.

Oder nicht?

1983 wurde das Paper erneut in den "IEEE Annals of the History of Computing" veröffentlicht. Der Herausgeber macht dabei eine wichtige Bemerkung: SAGE war eines der ersten Systeme, das so groß war, dass es eine Person alleine nicht mehr entwickeln und verstehen konnte, während vorher einzelne Personen Programme sehr erfolgreich entworfen und geschrieben haben. Es war also der Beginn der Herausforderung, welche heute die Softwareentwicklung dominiert: ein komplexes Softwaresystem mit einem Team koordiniert umzusetzen.

Noch interessanter als diese Ausführung des Herausgebers ist das Vorwort des Autors zur Wiederveröffentlichung. Das SAGE-Projekt hat zunächst einen Prototypen mit 35.000 Instruktionen geschrieben. Das alleine ist schon eine wesentliche Abwandlung des einfachen Wasserfall-Modells, da für diesen Prototypen alle Phasen einmal durchlaufen werden müssen, während der einfache Wasserfall nur einen einmaligen Durchlauf vorsieht. Zwanzig Personen haben dieses Prototypen entwickelt, durch den alle Module, Schnittstellen und Performance-Anforderungen klar waren. Diese Personen haben die Implementierung des eigentlichen Systems wesentlich beeinflusst.

Außerdem steht im Vorwort weiter, dass der größte Fehler des Projekts der Sprung von 35.000 Instruktionen im Prototypen zu mehr als 100.000 Instruktionen im realen System war. Im Nachhinein wäre es sinnvoller gewesen, ein "Framework" für 250.000 Instruktionen zu schaffen, als den 35.000-Instruktionen-Prototypen in dieses "Framework" einzugliedern und weiterzuentwickeln. So hätten schätzungsweise 50 Prozent der Kosten eingespart werden können. Das ist dann aber kein einfacher Wasserfall mehr, weil Code für neue Funktionalitäten ergänzt wird, sodass mindestens Phasen wie Design, Implementierung und Verifikation mehrmals durchlaufen werden.

Die Erfahrungen mit einem der ersten komplexen Softwareentwicklungsprojekte legt also schon nahe, dass ein einfacher Wasserfall keine Lösung für Softwareentwicklung ist – und das trotz relativ klarer Anforderungen.

Abgesehen davon war das SAGE-System einschließlich der Röhrenrechner bis in die Achtzigerjahre in Gebrauch. Aufgrund des technologischen und sonstigen Wandels über die Jahrzehnte scheint die Bezeichnung "Wartung" für diese Phase unzureichend. In dieser Zeit sind sicherlich auch neue, wesentliche Features entstanden. Dazu müssen die Phasen aus dem einfachen Wasserfall wie Anforderung, Design und Implementierung erneut durchlaufen werden.

Winston Royce griff Ideen auf

Manchmal wird die Erfindung des Wasserfalls auch Winston Royce zugeschrieben, der 1970 ein Paper zu seinen Erfahrungen mit Softwareentwicklung großer Systeme verfasst hatte. Royce arbeitete im Bereich Luft- und Raumfahrt, in welchem Anforderungen eher stabil sind und eine weitestgehende Fehlerfreiheit von Anfang an wünschenswert erscheint. Also ein Bereich, für den das einfache Wasserfall-Modell sinnvoll sein könnte. Und tatsächlich findet sich eine Abbildung in dem Paper, die dem einfachen Wasserfall gleicht – der Name "Wasserfall-Modell" taucht allerdings nicht auf.

Aber auch hier zeigt der Rest des Papers mehrere wesentliche Abwandlungen vom reinen Wasserfall, zum Beispiel:

  • Es soll Feedback aus einer Phase in die davor oder sogar noch weiter zurückliegende Phasen geben. Das widerspricht einem einmaligen, linearen Durchlauf durch die Phasen.
  • Der gesamte Entwicklungsprozess sollte zweimal durchlaufen werden. Das erinnert an den Prototypen aus dem SAGE-Projekt.

Dementsprechend finden sich in dem Paper weitere Abbildungen, die andere, wesentlich vom einfachen Wasserfall abweichende Prozesse beschreiben.

The Leprechauns of Software Engineering

In seinem Buch "The Leprechauns of Software Engineering" setzt sich Laurent Bossavit mit verschiedenen Mythen im Bereich der Softwareentwicklung auseinander. Das Buch ist ein Plädoyer dafür, fundamentale Grundlagen der Softwareentwicklung kritisch zu hinterfragen.

Ein Kapitel beschäftigt sich mit dem Wasserfall-Modell. Dabei setzt sich Bossavit vor allem mit der Interpretation des Royce-Papers auseinander. Seiner Meinung nach sehen Verfechter der agilen Bewegung das Wasserfall-Modell als eine Fehlinterpretation des Royce-Papers. Der Sichtweise der Agilisten nach hat das Paper eigentlich einen agil-iterativen Ansatz proklamiert. Dabei fehlt dem Royce-Prozess aber in Wirklichkeit ein erneuter Durchlauf der Anforderungsphase.

Kritiker der agilen Bewegung sehen den einfachen Wasserfall als ein Modell, das niemand proklamiert, sondern welches nur zum Diskreditieren formaler Prozesse dient. Royces Modell ist schließlich nicht so unflexibel und empfiehlt auch keinen einmaligen, sequenziellen Durchlauf durch die Phasen. Tatsächlich sind laut Bossavit aber beide Interpretationen ungenügend.

Bossavit zeigt weiter, dass Royces Paper zumindest eine Quelle der bekannten grafischen Darstellung des Wasserfalls ist. Es wurde populär, weil Barry Boehm und seine Firma TRW in den Achtzigern dieses Paper als Rechtfertigung für existierende Top-down-Ansätze begriffen und entsprechend zitierten. Sie publizierten das Royce- und das SAGE-Paper erneut. Wenig später führte Boehm das iterativ-inkrementelle Spiral-Modell ein und interpretierte das Royce-Paper als dessen Vorläufer, da es ja schon eine Prototypphase etabliert hatte. So weist Bossavit darauf hin, dass Boehm auch eine wichtige Rolle in der Geschichte des Wasserfall-Projekts spielt. Wie Benington und Royce zuvor empfiehlt auch Boehme den einfachen Wasserfall nicht, sondern entwickelt ihn weiter.

Mythos Wasserfall beim Militär

Teilweise werden US-Militärstandards als weitere Quellen für Wasserfall-Vorgehen zitiert. Genau genommen diskutiert MIL-STD-490a von 1985 jedoch Spezifikationen und MIL-STD-483a von 1985 Konfigurationsmanagement. MIL-STD-2167 (1985) definiert Softwareentwicklungsstandards. Dort ist tatsächlich von einem Softwareentwicklungszyklus mit verschiedenen Phasen die Rede. Dieser Zyklus kann jedoch laut Abschnitt 4.1.1 in mehreren Iterationen durchgeführt werden und die Phasen sollen sich typischerweise überlappen. Auch das ist nicht unbedingt ein einfacher, sequenzieller Durchlauf, wie ihn der einfache Wasserfall vorsieht. Es ist natürlich vorstellbar, dass ältere Revisionen der Standards oder ältere Standards sich unterscheiden, aber über 35 Jahre alte Empfehlungen im Bereich Softwareentwicklung sind vermutlich nicht mehr der Stand der Technik.

Wenn man Wikipedia trauen kann, ist es auch beim deutschen V-Modell-Entwicklungsstandard der öffentlichen Hand möglich, “die Aktivitäten des V-Modells zum Beispiel auf ein Wasserfallmodell oder ein Spiralmodell abzubilden”. Das V-Modell XT von 2005 orientiert sich sogar an agilen und inkrementellen Ansätzen. Auch mit diesen Modell ist ein ein einfacher Wasserfall also nicht zwingend.

Fazit

Die Personen, denen das einfache Wasserfall-Modell zugeschrieben wird, haben es weder erfunden noch proklamierten sie es. Und das trotz Umgebungen, in denen Anforderungen vermutlich relativ fest sind und ein rigider Prozess noch sinnvoll war, um die bestehenden Limitationen beispielsweise bei der für die Entwickler:innen bei der Entwicklung nutzbaren Hardware einzuhalten.

Natürlich ist es denkbar, auch mit einem einfachen Wasserfall-Prozess erfolgreich zu sein – aber spätestens seit Royce und damit seit 50 Jahren sind andere Vorgehensmodelle zu empfehlen. Eigentlich sind diese Probleme aber schon seit dem SAGE-Projekt und damit seit Anbeginn der Softwareentwicklung im Team klar.

Wenn Anforderungen sich ändern, hat dieser Prozesse weitere offensichtliche und erhebliche Schwächen, da man dann bei einer wesentlichen Änderung im Prinzip von vorne anfangen müsste. Wer also einen einfachen Wasserfall empfiehlt, versteht den Stand der Technik vor 50 beziehungsweise 65 Jahren nicht. Und in diesen Jahrzehnten hat sich die Technologie weiterentwickelt, was viele Dinge wesentlich vereinfacht und es erlaubt, den Entwicklungsprozess selbst besser mit Software zu unterstützen. Das benachteiligt Wasserfall-artige Prozesse weiter.

Der einfache Wasserfall dient vermutlich in erster Linie als Gegenmodell zu Agilität und damit als ein Beispiel, wie man es nicht machen sollte. Das ignoriert aber die Abwandlungen, die von Anfang an genutzt wurden.

Vielleicht ist es auch verführerisch, endlich einen "sauberen" Prozess durchzuführen. Es mag intuitiv sinnvoll erscheinen, Dinge zu Ende zu führen, zu konsolidieren und dann darauf aufzubauen. Auch ich habe mich schon dabei ertappt, ein solches Vorgehen nach Phasen als "eigentlich richtigen" und "sauberen" Weg zu bewerten. Auch kann ein einfacher Wasserfall eine Illusion von Kontrolle geben: Es gibt eine klare Aufteilung in Phasen mit klaren Ergebnissen. Aber Probleme werden oft erst offensichtlich, wenn Software ausgeliefert wird und Benutzer die Software tatsächlich verwenden. Dieses Feedback verzögert der einfache Wasserfall, weil erst alle Phasen vollständig abgeschlossen sein müssen, statt möglichst schnell eine teilweise Lösung auszuliefern und Feedback dazu einzusammeln.
Zum Abschluss ein Vorschlag für ein Experiment: Wenn jemand das nächste Mal einen Wasserfall-Prozess vorschlägt, fragen Sie die Person, wer den Prozess erfunden und empfohlen hat.

tl;dr

Der einfache Wasserfall-Prozess war vor 65 Jahren schon nicht zu empfehlen – und damals fing Softwareentwicklung im Team erst an. Recherche in Original-Quellen ist hilfreich.

Vielen Dank an meine Kolleg:innen Lena Kraaz, Martin Kühl, Tammo van Lessen, Torsten Mandry, Jörg Müller, Joachim Praetorius, Gernot Starke und Stefan Tilkov für die Kommentare zu einer früheren Version des Artikels.