Royce’ Kritik am einfachen Phasenmodell (Wasserfallmodell)
https://bildung.social/@oerinformatik/110454170489315291
https://oer-informatik.de/royce-kritik-am-wasserfall
Wasserfallmodell, Winston W. Royce, Phasenmodell, Vorgehensmodelle, Softwareentwicklung, Dokumentation, Pilotversuch, Testen, Kundeneinbindung, Agilität
tl/dr; (ca. 11 min Lesezeit): Viele Auszubildende nutzen in ihren Projektdokumentationen das „Wasserfallmodell“ auf Basis einer Grafik, die Winston W. Royce als Beschreibung einer unbefriedigenden Ausgangslage herangezogen hat. Dass er daraufhin fünf wesentliche Schritte formuliert hat, die diesem Modell hinzugefügt werden müssen, um Risiken zu minimieren, ist über die Zeit scheinbar verloren gegangen. Wir nähern uns diesen fünf Schritten über das Originaldokument und Leitfragen [AI-Assisted]. (Zuletzt geändert am 28.10.2026)
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Dieser Artikel baut auf der Kann-Liste des Artikels Vorgehensmodelle: klassisch und agil auf.
Als Vorgehensmodell-Grundlagen kann ich nach Durcharbeiten des Artikels…
… erklären, warum Winston W. Royce nicht als Erfinder oder Befürworter des Wasserfallmodells gelten kann.
… beschreiben, welche Probleme Royce beim einfachen Phasenmodell sieht (Ressourcenengpässe zeigen sich erst im Test, Neuentwurf, Termin- und Kostenüberschreitung).
… die fünf Schritte nennen, die Royce dem Phasenmodell hinzufügt.
… erläutern, warum Royce eine umfangreiche Dokumentation fordert und welchen Nutzen sie in Test, Betrieb und Weiterentwicklung hat.
… den Zweck eines Pilotversuchs („Do it twice“) und der formalen Einbindung der Kundschaft beschreiben.
Darüber hinaus kann ich als Vorgehensmodell-Expertenwissen…
… Royce’ Vorschläge mit agilen Prinzipien vergleichen und Gemeinsamkeiten und Unterschiede beurteilen.
… einen englischen Fachtext abschnittsweise erschließen und seine Aussagen in den damaligen Kontext einordnen.
Kontext und Einordnung
Dass ausgerechnet Winston W. Royce oft als “Erfinder des Wasserfallmodells” bezeichnet wird, ist auf viele Arten ungewöhnlich: Weder hat er den Begriff „Wasserfall“ im Ursprungsartikel verwendet, noch ist er in diesem Artikel ein Verfechter dieses Modells. Vielmehr dient die oft zitierte Grafik, die dann Betitelungen wie „Wasserfallmodell mit Rücksprung“ bekommt, in seinem Artikel lediglich dazu, zu zeigen, an welchen Stellen dieses verbreitete Vorgehen verbessert werden muss.
Royce benennt viele Probleme beim einfachen phasenorientierten, dokumentengetriebenen Vorgehen, die auch viele iterativ-inkrementelle Vorgehensmodelle adressieren: In dem Artikel von 1970 kann man daher auch einen frühen Vorboten der Agilität mit den Mitteln seiner Zeit sehen.1
Royce hat den Artikel Managing the development of large software systems zu einer Zeit geschrieben, als häufig die begrenzten Ressourcen der damaligen Rechner für das Scheitern von Projekten verantwortlich waren – er selbst entwickelte Software für die Planung und Auswertung von Raumfahrtmissionen: Speicherplatz (storage), Laufzeit (timing) und Datenfluss (data flux). Da diese Limitierung heute bei vielen Projekten nicht mehr zutrifft, müssen seine Aussagen im damaligen Kontext eingeordnet und auf die heutigen limitierenden Faktoren übertragen werden!
Wir wollen uns diesem Artikel über Leitfragen nähern:
Lies den Artikel von Winston W. Royce Managing the development of large software systems abschnittsweise und beantworte für jeden Abschnitt die folgenden Leitfragen. Lass DeepL & Co. am besten beiseite und lies den Text direkt auf Englisch. Damit das einfacher fällt, sind zu jedem Abschnitt ein paar Schlüsselbegriffe notiert. Für das Lesen des Originals und die Fragen brauchst Du etwa 90 Minuten.
Einführung: Computer Program Development Functions
| eng | dt |
|---|---|
| salvageable | verwertbar |
| preserved | gut erhalten |
- Welche zwei Schritte sieht Royce als essenziell in allen Softwareentwicklungsprozessen an?
- Unter welchen Voraussetzungen reicht die Gliederung in diese beiden Schritte seiner Meinung nach aus?
- Warum werden die zusätzlichen Schritte (v. a. von der Kundschaft) häufig als nicht nötig angesehen?
| eng | dt |
|---|---|
| invariable | ausnahmslos |
| octal patch | (vermutlich meint er händische Anpassung im compilierten ( Assembler-)-Code) |
| disruptive | (zer-)störend |
- Welche Probleme sieht Royce bei diesem Vorgehen in der Testphase?
Step 1: “Program Design comes first”
| eng | dt |
|---|---|
| preliminary | vorbereitend |
| to culminate in sth. | in etwas gipfeln |
| allocation | Zuweisung |
| insufficient | ungenügend |
- Welche Kritikpunkte sieht Royce am Konzept “Program Design comes first”?
- Welche Verbesserungen verspricht er sich von “Program Design comes first”?
- Die genannten Engpässe (Timing, Storage, Dataflux) spielen heutzutage oft keine große Rolle mehr. Welche Schlüsse können wir trotzdem heute aus dem Absatz “Program Design comes first” ziehen?
Step 2: “Document the Design”
| eng | dt |
|---|---|
| ruthless | schonungslos |
| intangible | nicht greifbar |
| unequivocal | unmissverständlich |
| downstream | Nachgelagert (eigentlich: Ausfluss / talseitig) |
- Aus welchem Grund spricht sich Royce für stringente Dokumentation aus? In welchen Phasen sieht er welche Vorteile?
Step 3: “Do it twice”
| eng | dt |
|---|---|
| leverage | Einfluss |
| to arrange matters | die Belange anordnen/sortieren |
| to utilize | benutzen |
| pilot effort | erste Versuch |
| straightforward | direkt / einfach |
- Welche Kompetenzen benötigen die Entwickler*innen, die am Pilotversuch beteiligt sind?
- Welche Vorteile bietet ein vorgeschalteter Pilotversuch?
Step 4: “Plan, control and monitor Testing”
| eng | dt |
|---|---|
| feasible | machbar |
| proofreading | Korrekturlesen |
| to plow | pflügen |
| to obscure sth | etwas verschleiern |
| to give free rein to sth. | etwas / jemandem freien Lauf lassen |
| to bolster | unterstützen |
- Welche Kernpunkte spricht Royce für die Testphase an?
Step 5: “Involve the customer”
- Wann sollte die Kundschaft eingebunden werden?
Fazit: Ist Royce der erste agile Softwareentwickler?
Am Ende hat Royce aus dem ursprünglichen Zwei-Phasen-Modell einen relativ komplexen Ablauf entwickelt. Die spannendste Frage ist: wie hätte sein Dokument ausgesehen, wenn er es dreißig Jahre später geschrieben hätte?
In welchen Bereichen verfolgt Royce die gleichen Ziele wie agile Vorgehensmodelle?
In welchen Bereichen weicht er von agilen Prinzipien ab?
Royce ist angetreten, um Risiken zu minimieren und das Scheitern von Projekten zu erschweren. Er ist nicht „Vater des Wasserfallmodells“, sondern einer der ersten, der dieses Vorgehen hinterfragt hat. Wir sollten ihn nicht mit der Ausgangsgrafik seiner Problemanalyse zitieren, als wäre es seine Idee, so vorzugehen.
Leitfragen
- Warum ist es irreführend, Winston W. Royce als „Vater des Wasserfallmodells“ zu bezeichnen?
Royce verwendet den Begriff „Wasserfall“ nicht und nutzt die bekannte Grafik nur, um die Schwächen dieses verbreiteten Vorgehens zu zeigen; danach schlägt er fünf Schritte vor, die das Risiko senken. Siehe Abschnitt „Kontext und Einordnung“.
- Welches Kernproblem sieht Royce beim einfachen Phasenmodell?
Ob Laufzeit, Speicher und Datenfluss ausreichen, zeigt sich erst in der Testphase. Reichen sie nicht, ist ein grundlegender Neuentwurf nötig, und Termin und Kosten laufen aus dem Ruder. Siehe Abschnitt „Einführung“.
- Welche fünf Schritte fügt Royce dem Phasenmodell hinzu?
Program design comes first, Document the design, Do it twice, Plan, control and monitor testing und Involve the customer. Siehe Abschnitt „Fazit“.
- Warum fordert Royce so viel Dokumentation?
Sie macht die Kommunikation verbindlich, ist in den frühen Phasen die eigentliche Spezifikation und das Design und ermöglicht später, dass andere testen, betreiben und weiterentwickeln können. Siehe Abschnitt „Step 2“.
- Was bringt ein Pilotversuch nach „Do it twice“?
In einer verkleinerten ersten Version werden kritische Abläufe früh erprobt; die ausgelieferte Fassung ist dann in den kritischen Bereichen schon die zweite, und Risiken lassen sich besser einschätzen. Siehe Abschnitt „Step 3“.
- Worin ähnelt Royce agilen Vorgehensmodellen, und worin unterscheidet er sich?
Gemeinsam sind das frühe Erkennen von Risiken, das Ausprobieren in einer ersten Version, gründliches Testen mit Reviews und die Einbindung der Kundschaft vor der Auslieferung. Anders als agile Modelle setzt Royce auf umfangreiche Dokumentation, feste Phasen mit formalen Reviews und höchstens zwei Durchläufe statt vieler kurzer Iterationen. Siehe Abschnitt „Fazit“.
Links und weitere Informationen
Überblick über klassische und agile Vorgehensmodelle: Vorgehensmodelle: klassisch und agil
Zentrales Dokument ist natürlich der Artikel von Winston W. Royce von 1970: Managing the development of large software systems
Einen sehr lesenswerten Versuch, Royce’ Artikel in eine Reihe mit agilen Vorgehensmodellen einzuordnen hat Jens Himmelreich in seinem Artikel “Agile Software Entwicklung nach Winston Royce” gemacht, Leseempfehlung! (PDF aus: Bernd Oestereich (Hrsg.): Agiles Projektmanagement, Beiträge zur interdisziplinären Konferenz interPM, 2006, dpunkt-Verlag, ISBN-13: 978-3898644129)
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Royce’ Kritik am einfachen Phasenmodell (Wasserfallmodell)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/royce-kritik-am-wasserfall veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
