Software Engineering - The Classic or Unmodified Waterfall Model

Aka the Linear Sequential Model

by Max Maurer, LMU, Munich, January 2007

Einleitung

Das Waterfall Model ist ein Methode zur sequentiellen Entwicklung von Software. Das Waterfall Model ist eines der ersten Software Entwicklungs Modelle (ein Software Entwicklungs Modell beschreibt einen Software Life Cycle und sein Durchführung) und wurde zum ersten Mal in den 1970er Jahren, allerdings noch ohne Namen, dokumentiert. Der Name "Waterfall Model" kommt hierbei von einem mehrstufigen Ablauf bei dem von Stufe zu Stufe vorwärts gegangen wird, ähnlich wie Wasser bei einem Wasserfall von einer Ebene zur anderen fließt. Nach diesem Prinzip werden die verschiednen Phasen der Reihe nach abgearbeitet.

Zum ersten Mal aufgezeigt wurde das Waterfall Model von Dr. Winston W. Roye, der in seinem Papier "Managing The Development Of Large Software Systems" versuchte seine Erfahrungen bei der Entwicklung großer und wichtiger Softwareprogramme zu verdeutlichen, die er bis zu diesem Zeitpunkt gesammelt hatte. Die hier verwendete Quelle ist vom März 1987 gibt aber an einen Nachdruck von 1970 zu veröffentlichen. (1 S. 328) Am Zeitpunkt der Veröffentlichung und an der Tatsache das Royce von seiner Arbeit an Softwareprojekten und -entwicklungen für die Luft- und Raumfahrt spricht lässt sich bereits erkennen, dass dieses Model nicht mehr auf dem aktuellen Stand der Wissenschaft ist. Trotzdem wird es auch in sehr aktuellen Quellen immer wieder zitiert.

In seiner Veröffentlichung spricht Royce zunächst von den beiden wichtigsten Schritten der Softwareentwicklung: "Analysis" und "Coding". Diese beiden Schritte müssen bei jeder Art von Software egal wie klein das fertige Produkt werden soll durchgeführt werden. Dabei sind dies auch die beiden Schritte, die sowohl dem Programmierer als auch dem Kunden als plausibel und notwendig erscheinen. Weitere eingeführte Schritte verursachen zusätzliche Kosten und Arbeit. Ein Projektmanager muss also darauf achten den Sinn von solchen zusätzlichen Schritten sowohl dem Kunden als auch den eingen Mitarbeitern zu vermitteln. (1 S. 328)

Größere Softwareprojekte müssen sich also um wesentlich mehr Entwicklungsschritte bemühen, da sie sonst zum scheitern verurteilt sind. Für solche Projekte nennt Royce sieben Schritte: 1. System Requirements, 2. Software Requirements, 3. Analysis, 4. Program Design, 5. Coding, 6. Testing und schließlich 7. Operations. Hierbei soll jeder Schritt in Hand in Hand mit seinem Nachfolger und Vorgänger arbeiten. Weiter entfernte Schritte haben jedoch nichts damit zu tun. Analyse und Progrmmierung bleiben dabei natürlich erhalten und bilden den Kern des Ablaufs und des Modells. Allerdings ist die Analyse bei größeren Projekten wesentlich komplexer und bedarf deswegen gewisser Vorarbeit durch ermitteln der System sowie der Software Requirements. (1 S. 328 f.)

Das Model als solches wird in der vorliegenden Quelle noch gar nicht als Waterfall Model bezeichnet, diese Bezeichung bekam es erst später durch den sequentiellen nach unten gerichteten Ablauf der einzelnen Schritte. Heute benutzt der Autor in aktuellen Veröffentlichungen allerdings auch selbst diesen Namen für sein Model. (8)

Rocye nennt hier nicht nur die Phasen seines Modells sondern er zeigt auch gleich eine Reihe von Problemen auf. Insbeseondere: "The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed." (1 S. 329) Die Testphase für Software ganz an den Schluß zu setzen kann dazu führen das evtl. ein komplettes redesign erforderlich wird, da in sämtlichen anderen Entwicklungsschritten nie geprüft wird in wie weit das bisher entwickelte auch dem gewünschten Ergebnis entspricht.

Im weiteren Verlauf versucht Royce durch Hinzufügen fünf weiterer Schritte die Nachteile des Waterfall Models zu verbessern und daraus ein interatives Model zu erstellen. Hierzu später noch mehr. Zitiert wird in der Litaratur selten Royce endgültige Ausarbeitung dieses Models sondern der von ihm selbst kritisierte erste Ansatz. (s. 2,3)

Die fünf Phasen

Ashley Williams (2) fasst die Idee nochmal zusammen und spricht hierbei allerdings nur von fünf statt den ursprünglich sieben generellen Schritten im Entwicklungsprozeß unter Verwendung des Waterfall Models:
"1. Analyzing requirements, 2. Designing the system, 3. Developing the system, 4. Testing the systen, 5. Deploying it" (2 S. 5)

• Analyzing requirements
  Gerade in diesen Schritt wird beim Waterfall Model am meisten Zeit und Geld investiert. Eine gute Requirement Analysis ist die Voraussetzung für erfolgreiche weitere Schritte. In der Requirement Analysis werden die Anfoderungen an das Projekt, wie sie der Kunde sehen möchte gesammelt. Royce teilt diesen Schritt in System Requirements und Software Requirements. System Requirements sind eher technischer Natur, also auf welchem System soll eine Software laufen, was leistet dieses System und was kann man sich dort an vorhandenen technischen Vorgaben zu nutze machen. Die Sofware Requirements legen fest, was die Software selbst können soll, also welchen Problemstellungen sie lösen soll und welche Funktionen sie bietet. In dieser Phase sollten laut dem Waterfall Model bereits möglichst viele Informationen gesammelt und ein fertiges Bild der Kundenwünsche angefertigt werden. Den Abschluss dieser Phase bildet die Ausarbeitung eines Requirements Document in dem alle Informationen dokumentiert sind.
  
  
• Designing the system
  In dieser zweiten Phase, wird das in der ersten Phase erzeugte Document sozusagen als Eingabe oder Grundvoraussetzung benutzt. An Hand der dort festgehaltenen Requirements, wird nun das Programm passend zur Hardware und den Software Requirements designed. Dabei wird entschieden in welcher Programmiersprache und -umgebung das Projekt umgesetzt werden soll, wie das Backend der Applikation mit seinen Funktionen aussehen soll und auch schon teilweise wie die GUI also das Graphical User Interface später für den Benutzer der Software aussehen wird. Wie in der ersten Phase auch entseht auch hier wieder ein Design Document, welches alle getroffenen Entscheidungen und Vorgaben beeinhaltet.
  
  
• Developing the system (Coding)
  Hier in der dritten Phase, wird nun das Projekt in der Programmiersprache implementiert die in der vorhergehenden Spezifikation festgelegt wurde. Das Abschluss Document dient also wieder als Basis für diesen weiteren Schritt. Das festgelegte Design wird unter Programmierern und GUI Designern und anderen aufgeteilt. Alle gemeinsam erarbeiten eine funktionfähige Version der Software die die vorgegebenen Dokomumente bis ins kleineste Details umsetzen muss.
  
  
• Testing the system
  Eine unumstößliche Wahrheit der Programmierung ist, das kein Programm bei seinem ersten Testlauf perfekt läuft. Deswegen wird hier in der vierten Phase die fertige Software auf Herz und Nieren geprüft. Es wird getestet und debugging durchgeführt. Hierbei gibt es verschiedene Methoden wie Black Box und White Box Testing. Ziel der Phase ist möglichst alle noch in der Software steckenden Fehler und Schwächen zu erkennen und diese auszumerzen. In dieser Phase, erhält der Kunde auch zum ersten Mal einen Blick auf die Software und kann seine eigenen Korrekturen einbringen. Dies passiert hier natürlich erst zu einem sehr späten Zeitpunkt was bei zu großen Änderungswünsche eventuell daszu führt, das über ein komplettes Redesign der Applikation aber der ersten oder zweiten Phase nachgedacht werden muss.
  
  
• Deploying the system
  Dies ist die finale Phase. Das Produkt sollte nun so fertig gestellt sein, wie sich der Kunde oder Auftraggeber die Anwendung vorgestellt hat. Die Software wird an ihn ausgeliefert, falls nötig installiert und damit sollte im Besten Fall das Projekt abgeschlossen sein. Normalerweise ist dies aber nicht so. Manche Fehler treten tatsächlich erst im Anwendungsfall auf oder er stellt sich heraus das der Nutzer nun erst während der Arbeit merkt welche wichtige Funktion ihm nun doch noch fehlt. An dieser Stelle ist darüber nachzudenken wie groß diese Veränderungen sein müssen. Geht man zurück in die vierte Phase und versucht sich dort an Korrekturen oder fängt man ein neues Projekt zur Verbesserung an.

Wichtig dabei: Keiner dieser Schritte wird hier paralell oder überlagernd durchgeführt. Liegen die Ergebnisse des ersten Schrittes vor, so wird zum nächsten Schritt über gegangen. Das bedeutet erst wird ein Bericht über die System Anforderungen erstellt, mit Hilfe dieses Berichtes wird im zweiten Schritt die Software geplant. Diese Planung setzten Programmierer dann im dritten Schritt um und danach wird die "fertige" Software getestet und Schluss endlich sollten keine Probelem aufgetreten sein frei gegeben. (2 S. 5)

In jedem dieser Schritte wird sehr viel Dokumentation in Form von Text und Bildern erzeugt um möglichst deutlich festzuhalten, was genau gemacht werden soll.

Hier hat das Waterfall Model Ähnlichkeit mit dem Sprial Model welches allerdings zusätzliche zum Waterfall Model mit Prototypen arbeitet und in jedem Schritt eine Risikobewertung durchführt. Insgesamt kann das Sprial Model sowohl zeitlich als auch inhaltlich als eine Art Nachfolger zum Waterfall Model angesehen werden. Ein ganz entscheidender Unterschied ist jedoch das im Sprial Model bereits Iteration verwendet wird. Auch hierzu später mehr. (3 S. 340 f.)

Vorteile des Waterfall Models

Das Waterfall Model verdeutlich obwohl es in die Jahre gekommen ist bereits stark, dass Softwareentwicklung weit mehr als die Programmierung von Software für einen besimmten Zweck ist und das sehr viel Dokumentation notwendig ist um ein Softwareprojekt eindeutig zu beschreiben. (6) Royce spricht hier bei einem Auftragsvolumen von 5 Millionen US Dollar von mindestens 1500 Seiten Dokumentation.

Eine weitere wichtige Erkenntnis des Waterfall Models ist das durch eindeutige Festlegung von Anfoderungen in einer frühen Projektphase spätere Phasen wesentlich leichter und schneller entwickelt werden können. (6)

Ein weitere Vorteil des Waterfall Models und wahrscheinlich auch ein Grund für seine die häufigen Zitate ist, dass es einfach Strukturiert und sehr einleuchtend ist. Man kann die Schritte leicht nachvollziehen und auch bei der Durchführung ist es leicht zu planen von einem Schritt zum anderen zu gehen. (6)

Kritikpunkte am Waterfall Model

Kritikpunkte am Waterfall Model gibt es viele:

So macht es zum Beispiel keinerlei Aussagen über Debugging und Wartung. (4 S. 95) Beim Schreiben von Software spielen diese beiden Gesichtpunkte jedoch eigentlich immer eine Rolle.

Des weiteren geht es davon aus, das sich in den Ergebnissen einmal durchgeführter Schritte keine Veränderungen mehr ergeben können, also dass beispielsweise die Anforderungen an eine Software sich im Softwareprozess nicht ändern. (5 S. 10) Bei großen Softwareprojekten bei denen die Entwicklung sich über Jahre hinzieht können sich in dieser Zeit Anfoderungen sehr wohl ändern.

Allerdings sind Software Systeme heute auch wesent Benutzerorientierter als in den 1970er Jahren und müssen deswegen schneller auf solche Anforderungen reagieren können. Veränderungen in den Anfoderungen sollten kein unerwünschter Einzelfall sein der vermieden werden muss, sondern sie finden immer statt und sollten von vorne herein eingeplant werden. (5 S. 10 f)

Es ist einfach nicht möglich einen Schritt des Softwareentwicklungsprozesses komplett korrekt abzuschließen. Dies ist das zentrale Problem des Waterfall Models, da es hat man ein Ebene einmal verlassen einem keine Möglichkeit zur Rückkehr in diesem Entwicklungsschritt bietet. (6)

Aspekete des Prototypings werden im Waterfall Model komplett vernachlässigt, somit ist es nicht möglich nach jedem Schritt zu schauen ob man sich noch auf dem richtigen Weg befindet, ist der Entwicklungsprozess einmal angestossen, so läuft er ohne größere Veränderungen bis zum Ende ab. (6)

Ähnliche Modelle und Weiterentwicklung des Waterfall Models

Durch die große Popularität des Waterfall Models wurde es sehr oft verändert und verbessert. Bereits Royce vebessert sein Waterfall Model in seiner eigenen Veröffentlichung so dass man es als "Erweitertes Waterfall Model" oder "Royce Final Model" (6) bezeichnen kann.

Erweitertes Waterfall Model

Roye erwähnt fünf Schritte zur Verbesserung seines ursprünglichen Waterfall Models: "Program Design Comes First", "Document The Design", "Do It Twice", "Plan, Control an Monitor Testing", "Involve The Customer". Mit diesen fünf Verbesserungen fügt er jedem Schritt im Waterfall Model nocheinmal eigene Bestandteile hinzu und sorgt dafür dass äussere Parameter auch bei der weiteren Softwareentwicklung eine Rolle spielen. Hiermit kann man nun auf äussere Veränderungen grob reagieren. Ausserdem liefert jeder Schritt als Ergebnis ein "Document" in welchem dann die Ergebnisse des einzelnen Schrittes festgehalten werden. Der eigentliche Schritt des Program Design wird nochmals aufgeteilt und soll durch einen weiteren Analyse Schritt helfen die Software vor der eigentlichen Programmierung zu perfektionieren. (1 S. 331 ff.)

The "Sashimi" Model

Im Sashimi Model sind die einzelnen Phasen nicht strikt voneinander getrennt sondern überlappen sich zu großen Teilen. Damit soll "Feedback" zwischen den einzelnen Phasen gewährleistet werden. Dadurch können auch während der Phase der Programmierung noch Änderungen am Programmdesign vorgenommen werden. Das Sashimi Model wird Peter DeGrace zugeschrieben. (6)

The Sprial Model

Als ein Waterfall Model mit Iteration kann das Spiral Model von Barry Boehm angesehen werden. Er begründete mit seinem Model warum Iteration im Software Entstehungsprozess vom großer Wichtigkeit ist. (7)

Quellen:

1) W. W. Royce: Managing the development of large software systems: concepts and techniques IN: Proceedings of the 9th international conference on Software Engineering ICSE '87, IEEE Computer Society Press, März 1987

2) Ashley Williams: The documentation of quality engineering: applying use cases to drive change in software engineering models, IN: Proceedings of the 22nd annual international conference on Design of communication: The engineering of quality documentation table of contents, ACM Special Interest Group on Systems Documentation Publisher, Memphis, Tennessee, USA 2004

3) Luciano Rodrigues Guimares: Software development and analysis: Comparing software development models using CDM IN: Proceedings of the 6th conference on Information technology education SIGITE '05, ACM Press 2005

4) L. B. S. Raccoon: Fifty years of progress in software engineering IN: ACM SIGSOFT Software Engineering Notes, Volume 22 Issue 1, ACM Press 1997

5) Phillip A. Laplante, Colin J. Neill: Departments: Opinion: The Demise of the Waterfall Model Is Imminent IN: Queue, Volume 1 Issue 10, ACM Press 2004

6) Waterfall Model IN: Wikipedia - The Free Encyclopedia, www.wikipedia.com, Version: 14:34, 15 January 2007

7) Spiral Model IN: Wikipedia - The Free Encyclopedia, www.wikipedia.com, Version: 17:48, 13 January 2007 SmackBot

8) http://www-128.ibm.com/developerworks/rational/library/content/RationalEdge/jun02/ResultsBasedSoftwareManagementJun02.pdf (16-01-2007)