Leitfragen zu Royce‘ Kritik am „Wasserfallmodell“

Royce’ Kritik am einfachen Phasenmodell (Wasserfallmodell)

https://bildung.social/@oerinformatik/110454170489315291

https://oer-informatik.de/royce-kritik-am-wasserfall

tl/dr; (Bearbeitungszeit ca. 90 min): Die meisten Auszubildenden nutzen in ihren Abschlussarbeiten das “Wasserfallmodell” basierend auf 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 wieder verloren gegangen. Wir versuchen uns diesen fünf Schritten über das Originaldokument und Leitfragen zu nähern. (Zuletzt geändert am 30.05.2023)

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” dem 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 hat diese Grafik nur erstellt, um auf deren Probleme hinzuweisen. Das dann “Wasserfallmodell nach Royce” zu nennen, ist etwas irreführend. (angelehnt an Figure 3 seines Artikels)
Royce hat diese Grafik nur erstellt, um auf deren Probleme hinzuweisen. Das dann “Wasserfallmodell nach Royce” zu nennen, ist etwas irreführend. (angelehnt an Figure 3 seines Artikels)

Royce benennt viele Probleme beim einfachen phasenorientierten dokumentengetriebenen Vorgehen, die auch viele iterativ-inkrementelle Vorgehensmodelle adressieren: in dem Artikel aus 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 eines Microcontrollers für Scheitern von Projekten verantwortlich waren: Speicherplatz (Storage), Laufzeit (Timing) und Datenfluss (Dataflux). 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:

Lest bitte abschnittweise den Artikel von Winston W. Royce Managing the development of large software systems und beantwortet für jeden Abschnitt die folgenden Leitfragen. Ich empfehle DeepL & Co beiseite zu lassen, und den Text direkt auf Englisch zu lesen. Damit das allen einfacher fällt habe ich ein paar Schlüsselbegriffe aus den Seiten notiert.

Einführung: Computer Programm Development Functions:

Englische Begriffe aus S. 328
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. vom Kunden) häufig als nicht nötig angesehen?
Englische Begriffe aus S. 329
eng dt
invariable ausnahmslos
octal patch (vermutlich meint er händische Anpassung im compilierten ( Assembler-)-Code)
disruptive (zer-)störend
  • Welche Probleme sieht Royce in seinem zweiten Modell nach der Testphase?

Step 1: “Program Design comes first”

Englische Begriffe aus S. 331
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”

Englische Begriffe aus S. 332
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”

Englische Begriffe aus S. 334
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”

Englilsche Begriffe aus S. 335
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 der Kunde eingebunden werden?

Fazit: Ist Royce der erste agile Softwarentwickler?

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?

Das abschließende Modell von Royce mit den fünf zusätzlichen Schritten" “Programm design comes first”, “Document the design”, “Do it twice”, “Plan, control and monitor tests”, “Involve the customer” (angelehnt an Figure 10 seines Artikels)
Das abschließende Modell von Royce mit den fünf zusätzlichen Schritten" “Programm design comes first”, “Document the design”, “Do it twice”, “Plan, control and monitor tests”, “Involve the customer” (angelehnt an Figure 10 seines Artikels)

  • 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, 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.

  • 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/wasserfall. Stand: 30.05.2023.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]

  1. z.B. Jens Himmelreich: “Agile Software Entwicklung nach Winston Royce”↩

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...