Im voran gegangenen Beitrag hatte ich diese Aussage schon getroffen. Nachdem einige Nachfragen eingetroffen sind, möchte ich die Aussage etwas weiter ausführen. Nebenstehend ist ein typisches Wasserfall-Diagramm zu sehen. Die konkrete Benennung der Phasen kann variieren – entscheidend ist der Grundgedanke, dass eine Phase abgeschlossen wird und ihre Ergebnisse quasi in die nächste Phase ergießt. Die Ähnlichkeit zu Gantt Diagrammen und klassischen Projektplänen ist keineswegs zufällig. Diese Darstellung geht auf eine Veröffentlichung von Winston Royce aus dem Jahr 1970 zurück. Der Titel lautet MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS. Diese Darstellung des Wasserfalls hat sich in das Bewusstsein der Softwarebranche und des Projektmanagements eingebrannt. Bei aller Kritik am Wasserfallmodell blieb der Eindruck hängen, dass es bei hinreichender Sorgfalt der Anforderungserhebung, funktionieren würde.
Anforderungs-, Change- und Scopemanagement sind genau genommen Versuche das Wasserfallmodell zu verbessern. Im Laufe der Zeit verbreiteten sich iterative Ansätze und mündeten in den 90er Jahren des letzten Jahrhunderts in agile Vorgehensweise. Das tragische Element an dieser Geschichte ist, dass die Grundaussage der Veröffentlichung eine andere ist als jene die in das Bewusstsein der Branche drang.
Winston Royce schreibt in der Zusammenfassung:
In my experience, however the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.
Die erwähnte „simpler method“ ist der klassische oben skizzierte Wasserfall. Die Mehrkosten durch den aufwändigeren Prozess (Iterationen) sind geringer als jene, die durch Nachbesserungen (Terminüberschreitungen) am einfachen Modell entstehen. Er schreibt also sinngemäß: „Das hat noch nie funktioniert„. Dementsprechend sind in der Veröffentlichung einige andere Grafiken enthalten, mit denen er bereits 1970 eine iterative Vorgehensweise bis hin zu wiederholtem Coding vorschlägt – das würde man heute Refactoring nennen.
Ein wenig erinnert mich das an die Legende vom Eisengehalt des Spinats 😉
… den bis heute noch gelegentlich behaupteten, außergewöhnlich hohen Eisenanteil besitzt Spinat jedoch nicht – der Schweizer Physiologe Gustav von Bunge hatte 1890 den Wert zwar richtig berechnet, doch bezogen sich seine Angaben auf getrockneten Spinat, wurden aber später irrtümlich frischem Spinat zugeschrieben, der zu ca. 90 % aus Wasser besteht. (Wikipedia)
Pingback: Das Ende des Wasserfalls? | KMUT's Blog
Pingback: Scrum mit ein bisschen Wasserfall? Klar, und Popeye wird stark dank Spinat… « Unlocking Potential
Hallo Thomas, vielen Dank für die ausführliche Ergänzung, lg Eberhard
Hallo Eberhard,
schön, dass Du das Thema aufgegriffen hast. Ich bin (als ich für meine wiss. Arbeit recherchiert habe) ebenfalls auf das Paper gestoßen und dabei zu einer etwas ähnlichen Erkenntnis gekommen: Das Wasserfallmodell in seiner einfachen Form funktioniert zwar nicht für große SW-Projekte, jedoch kann es für diese Fälle sinnvoll erweitert werden.
Insbesondere fand ich den Teil spannend, in der Royce über das Erstellen von Prototypen redet (in der Automobilbranche ist dieses Vorgehen auch gerne gesehen).
„Step 3: Do it twice
[…] If the computer program in question is being developed for the first time, arrange
matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design operations areas are concerned.
[…]
In this case a very special kind of broad competence is required on the part of the personnel involved. They must have an intuitive feet for analysis, coding, and
program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally
arrive at an error-free program.“
Damit hat Royce das Rapid Prototyping vorweggenommen und dabei auch schon Einiges gesagt, was heutzutage meiner Meinung nach auch noch mal wiederholt werden sollte:
1. Einen Prototypen verwendet man, um Erkenntnisse zu sammeln. Anschließend fängt man mit der eigentlichen Entwicklung an – die dann jedoch nur die Erkenntnisse des Prototypen übernimmt.
Hingegen habe ich schon erlebt, dass Prototypen kontinuierlich zur Serienreife gebracht werden, mit der Folge, dass ein chaotisch gestartetes Prototypen-Projekt plötzlich zum „gut dokumentierten“ Serienprojekt werden soll…
2. Dokumentation: Weil man den Fehler in (1) gemacht hat, verlangt man nun von den Prototypen, dass sie genauso gut dokumentiert werden sollen, wie die eigeintliche Serienentwicklung.
Dadurch nimmt man sich aber die Chance einer schnellen und flexiblen Prototypenphase und lässt diese dadurch sinnlos werden.
Grüße,
Thomas
Das Wasserfallmodell funktioniert!
(solange es seine Aufgabe ist Wasser von einem höheren Niveau nach unten zu bringen) 🙂