Das Wasserfallmodell

Hintergrund: Die (ewige) Software-Krise

Die Informatik ist eine noch recht junge Wissenschaft. Der produktive Einsatz von elektronischen Rechanmaschinen geht auf die Zeit des Zweiten Weltkriegs zurück, als Alan Turing mit seinem Team die Enigma-Verschlüsselung der Achsenmächte mithilfe von einem Computer knackte. In der Nachkriegszeit wurden Computer dann vermehrt für friedliche Zwecke eingesetzt, beispielsweise bei Banken und Versicherungen, aber auch in der Raumfahrt.

Die Projekte wurden immer ambitionierter, die Werkzeuge (Programmiersprachen wie COBOL und Fortran) und Methoden waren aber noch nicht sehr ausgereift. Man wähnte sich Ende der 1960er-Jahre in einer Software-Krise. Edsger W. Dijkstra, der diese Krise mithilfe der strukturierten Programmierung bewältigen wollte, berichtet ein anschauliches Beispiel von der NATO-Konferenz 1969: ein Software-Fehler im Apollo-Programm (Quelle: Edsger W. Dijkstra Archive), der nur zufälligerweise entdeckt worden ist, und sonst mehreren Astronauten das Leben gekostet hätte.

Trotz strukturierter (und später: objektorientierter) Programmierung und planmässigerem Vorgehen beim Programmieren scheiterten weiterhin viele Software-Projekte. Ca. 40 Jahre nach dieser NATO-Konferenz schreiben Ken Schwaber und Jeff Sutherland, die Autoren des Scrum Guide, im Einleitungskapitel ihres Buches Software in 30 Days folgendes:

You have been ill served by the software industry for 40 years—not purposefully, but inextricably. […] In this part of the book, we investigate why software development has been so bad.

Als Ursache für den schlechten Zustand der Software-Industrie machen die Autoren planmässiges, lineares, dokumentlastiges Vorgehen aus: das Wasserfallmodell.

Winston Royce und sein Wasserfall-Artikel

1970 veröffentliche Winston Royce einen Beitrag mit dem Titel Managing the Development of Large Software Systems (Quelle). Darin beschrieb er seine Meinung darüber, wie grosse Software-Projekte durchgeführt werden sollten. Diese Meinung basiert auf seinen persönlichen Erfahrungen, die er in Software-Projekten im Bereich Raumfahrt sammeln konnte.

Die folgenden Abschnitte fassen einige wichtigen Aussagen daraus zusammen.

Kleine Projekte, wenige Schritte

Kleine Software-Projekte zeichnen sich dadurch aus, dass ihre Ergebnisse oft nur intern oder vom Autor selber verwendet werden. Das Vorgehen ist informell und umfasst zwei Schritte: Analyse (Analysis) und Umsetzung (Coding):

Beide Schritte tragen direkt zum Ergebnis bei und werden darum auch gerne vom Kunden bezahlt.

Grosse Projekte, viele Schritte

Für grössere Projekte funktioniert dieses Vorgehen leider nicht. Es sind weitere Arbeitsschritte nötig, die der Kunde lieber nicht bezahlen möchte. Die Aufgabe des Managements ist es, dem Kunden diese Arbeitsschritte zu verkaufen und das Team dazu zu bringen, diese auch gewissenhaft auszuführen.

• Vor der Analyse müssen Anforderungen (System Requirements und Software Requirements) aufgenommen werden.
• Zwischen Analyse und Umsetzung muss ein Design (Program Design) erarbeitet werden.
• Nach der Umsetzung muss die Software getestet und betrieben werden (Testing und Operations).

Dieses Modell – das naive Wasserfallmodell – geht davon aus, dass Arbeiten in abgeschlossenen Phasen keine Probleme in Folgephasen verursachen. In der Praxis ist dies oft nicht der Fall.

Frage: Welche Fehler in einer Phase können welche Fehler in der Folgephase erzeugen?

Rückmeldungen aus Folgephasen

Ein rein lineares/sequenzielles Modell funktioniert nur, wenn in keiner Phase Fehler gemacht werden, was mit zunehmender Grösse eines Projekts immer unwahrscheinlicher wird.

Somit ist es nötig, dass in jeder Phase Arbeitsschritte der vorgelagerten Phase erneut ausgeführt werden können, wenn deren Ergebnisse sich als unzulänglich erweisen. Das lineare/sequenzielle Modell wird zu einem iterativen Modell:

Die Fehlerursache und -wirkung liegt aber oftmals weiter auseinander. So kann eine falsch verstandene Anforderung (Software Requirements) im schlimmsten Fall erst beim Abnahmetest durch den Kunden (Testing) erkannt werden. Oder das System erweist sich im Betrieb (Operations) als unterdimensioniert und kann nicht mit der Last umgehen, da die Systemanforderungen (System Requirements) falsch eingeschätzt worden sind. (Dies ist heutzutage weniger ein Problem, da man Hardware-Ressourcen einfacher skalieren kann. 1970 war eine Software noch wesentlich stärker an ihre konkrete Hardware gebunden.)

Angenommen, beim Testen (Testing) wird erkannt, dass die Software falsch entworfen worden ist (Fehler beim Program Design). Der Fehler kann entweder beim Design gemacht worden – oder einer fehlerhaften Anforderung (Software Requirements) geschuldet sein:

In diesem Fall müssen verschiedenste Phasen erneut durchlaufen werden, wodurch die Projektkosten je nach Ausmass des Fehlers sich bereits verdoppeln können.

Lösungsansatz in fünf Schritten

Im Rest seines Artikels beschreibt Royce seinen Lösungsansatz – das erweiterte Wasserfallmodell – in fünf Schritten:

1. Schritt: ein vorläufiges Design
   • Zwischen Anforderungsaufnahme und Analyse soll eine weitere Phase eingefügt werden: ein vorläufiges Design (Preliminary Design). Auf Basis der Anforderungen soll ein Design ohne vorherige Analyse erarbeitet werden. Dadurch kann der Ressourcenbedarf bereits vor der Analyse grob abgeschätzt werden.
   • Ziel dieser Phase ist es nicht, ein korrektes Design für die tatsächliche Implementierung zu erreichen, sondern die Machbarkeit und den Ressourcenbedarf des Projekts zu prüfen. Die Erkenntnisse aus dieser Phase sollen in einem Übersichtsdokument zusammengefasst werden, damit alle im Projekt ein gemeinsames Verständnis erhalten.
2. Schritt: das Design dokumentieren
   • Wie viel soll in einem Software-Projekt dokumentiert werden? Ziemlich viel, beantwortet Royce diese Frage und begründet dies folgendermassen:
     1. Die Kommunikation zwischen Designer, Kunden und Management muss dokumentiert werden, damit man ein gemeinsames Verständnis davon sichern kann. Verbale Kommunikation kann dies nicht leisten.
     2. In den frühen Phasen ist die Dokumentation das einzige Zwischenprodukt: in Form von Anforderungen, Analyse und Design.
     3. Der Nutzen einer guten Dokumentation zahlt sich erst in den späteren Phasen aus: sie erleichtert die Fehleranalyse beim Testen, ermöglicht einen reibungsfreien Betrieb und stellt eine solide Basis für die Weiterentwicklung der Software dar.
3. Schritt: alles zweimal machen
   • Für ein neuartiges Projekt lohnt es sich, den ersten Viertel bis Drittel der Projektzeit in einen Prototyp zu investieren. Hierbei wird das ganze Vorgehensmodell einmal im Kleinen durchgespielt.
   • Ein erfahrenes Team mit guter Intuition kann in dieser Pilotphase mögliche Fehlerquellen aufspüren, wertvolle Erfahrungen machen und diese mithilfe einer guten Dokumentation dem Rest des Teams zur Verfügung stellen.
4. Schritt: planen, kontrollieren und auswerten
   • Die Testphase ist oft die aufwändigste und risikoreichste – und durch Verzögerungen oft zeitlich kritischste. Durch eine gewissenhafte Durchführung der drei vorherigen Schritte wird das Risiko in der Testphase minimiert.
   • Viele Fehler können in den vorherigen Phasen bereits mithilfe eines Reviews durch eine andere Person entdeckt werden. So können die Fehler bereits vor dem Testen erkannt und korrigiert werden.
5. Schritt: den Kunden miteinbeziehen
   • Der Kunde soll bereits zu einem frühen Zeitpunkt erneut in das Projekt miteinbezogen werden. Dies soll nicht erst beim Ausliefern der Software erfolgen, sondern bereits nach Abschluss der Design-Phase, um mögliche Missverständnisse vor der Implementierung zu klären. Der Auftragnehmer soll zwischen Anforderungs- und Betriebsphase nicht einfach sich selber überlassen werden.

Diese Massnahmen sind zwar aufwändig und kosten Geld, erhöhen aber die Wahrscheinlichkeit für die erfolgreiche Umsetzung des Projekts.

Kritik am Wasserfallmodell

Die Befürworter agiler Methoden kritisieren das Wasserfallmodell oft aus folgenden Gründen:

Das Wasserfallmodell…

1. bietet keinen Feedback-Mechanismus; der Kunde ist nicht involviert.
   • agile Lösung: kurze, iterative Entwicklungsphasen
2. ist zu dokumentlastig; der Kunde will Software und keine Dokumente.
   • agile Lösung: dem Kunden laufende Software zeigen
3. basiert auf Anforderungen; der Kunde weiss gar nicht, was er will.
   • agile Lösung: ständiger Austausch mit dem Kunden
4. erfordert viel Design-Arbeit; dies führt zu Over-Engineering.
   • agile Lösung: Anforderungen möglichst einfach umsetzen und iterativ verbessern
5. hat einen katastrophalen Leistungsausweis; wir haben eine Software-Krise.
   • agile Lösung: wir werfen alles über Board und fangen agil an zu entwickeln.