Wasserfall-Modell

Das Wasserfall-Modell ist eine Aufschlüsselung der Projektaktivitäten in linear sequentiell Phasen, in denen jede Phase von den Ergebnissen der vorherigen abhängt und einer Spezialisierung der Aufgaben entspricht.[1] Der Ansatz ist typisch für bestimmte Bereiche von Ingenieur-Design. Im Software-Entwicklung,[1] Es gehört dazu, zu den weniger iterativen und flexiblen Ansätzen zu gehören, da der Fortschritt weitgehend in eine Richtung fließt ("Abwärts" wie a Wasserfall) durch die Phasen der Konzeption, Initiierung, Analyse, Entwurf, Konstruktion, testen, Einsatz und Wartung.[2]

Das Wasserfallentwicklungsmodell stammt aus dem Herstellung und Konstruktion Industrien, in denen die hoch strukturierten physikalischen Umgebungen dazu führten, dass Designänderungen im Entwicklungsprozess viel früher teuer wurden. Bei der ersten Übernahme für die Softwareentwicklung gab es keine anerkannten Alternativen für wissensbasierte kreative Arbeit.[3]

Geschichte

Die erste bekannte Präsentation, die die Verwendung solcher Phasen in der Software -Engineering beschreibt, wurde am 29. Juni 1956 von Felix Torres und Herbert D. Benington auf dem Symposium für fortschrittliche Programmiermethoden für digitale Computer gehalten.[4] In dieser Präsentation ging es um die Entwicklung von Software für SALBEI. 1983 wurde das Papier von Benington mit einem Vorwort erneut veröffentlicht und erklärte, dass die Phasen absichtlich nach der Spezialisierung von Aufgaben organisiert waren und darauf hingewiesen wurden, dass der Prozess tatsächlich nicht streng von oben nach unten durchgeführt wurde, sondern von einem Prototyp abhängig war .[3]

Obwohl der Begriff "Wasserfall" in dem Papier nicht verwendet wird, wird das erste formale detaillierte Diagramm des später als "Wasserfallmodell" bezeichneten Prozess Winston W. Royce.[5][6][7] Er hatte jedoch auch das Gefühl, dass es große Fehler hatte, die sich aus der Tatsache ergeben, dass das Test nur am Ende des Prozesses stattfand, was er als "riskant" bezeichnete und ein Scheitern einlädt.[5] Der Rest seines Papiers führte fünf Schritte ein, die er für notwendig hielt, um "die meisten Entwicklungsrisiken zu beseitigen", die mit dem unveränderten Wasserfallansatz verbunden waren.[5]

Royces fünf zusätzliche Schritte (einschließlich des Schreibens vollständiger Dokumentation in verschiedenen Entwicklungsstadien) unternahm nie den Mainstream -Halt, aber sein Diagramm für einen fehlerhaften Prozess wurde zum Ausgangspunkt bei der Beschreibung eines "Wasserfall" -Ansatzes.[8]

Die früheste Verwendung des Begriffs "Wasserfall" war möglicherweise in einem Papier von Bell und Thayer in einer Zeitung von 1976.[9]

1985 die Verteidigungsministerium der Vereinigten Staaten erfasste diesen Ansatz in DOD-STD-2167A, ihre Standards für die Zusammenarbeit mit Softwareentwicklungsunternehmen, in denen festgestellt wurde, dass "der Auftragnehmer einen Softwareentwicklungszyklus implementiert, der die folgenden sechs Phasen umfasst: Analyse der Softwareanforderung, vorläufiges Design, detailliertes Design, Codierung und Testen, Integration und Testen der Einheit".[10]

Modell

In Royces ursprünglichem Wasserfallmodell werden die folgenden Phasen in der Reihenfolge befolgt:

  1. System und Software Anforderungen: in einem gefangen genommen Produktanforderungen Dokument
  2. Analyse: ergebend Modelle, Schema, und Geschäftsregeln
  3. Entwurf: führt zur Softwarearchitektur
  4. Codierung: das Entwicklung, Beweis, und Integration von Software
  5. Testen: Die systematische Entdeckung und Debuggen von Mängel
  6. Operationen: das Installation, Migration, Unterstützung, und Wartung von vollständigen Systemen

Daher behauptet das Wasserfallmodell, dass man sich nur dann in eine Phase bewegen sollte, wenn seine vorhergehende Phase überprüft und verifiziert wird.

Verschiedene Modifizierte Wasserfallmodelle (einschließlich des endgültigen Modells von Royce) kann jedoch geringfügige oder wesentliche Variationen dieses Prozesses enthalten.[5] Diese Variationen umfassten die Rückkehr zum vorherigen Zyklus, nachdem Fehler stromabwärts gefunden worden waren, oder die Rückkehr in die Entwurfsphase, wenn die nachgeschalteten Phasen als unzureichend eingestuft wurden.

Argumente unterstützen

Die Zeit, die zu Beginn des Softwareproduktionszyklus verbracht wird, kann die Kosten in späteren Phasen senken. Beispielsweise ist ein Problem, das in den frühen Stadien (z. B. Anforderungsspezifikation) gefunden wurde, billiger zu beheben als der gleiche Fehler, der später im Prozess gefunden wurde (um einen Faktor von 50 bis 200).[11]

In der allgemeinen Praxis führen Wasserfallmethoden zu einem Projektplan mit 20 bis 40% der Zeiten, die für die ersten beiden Phasen investiert wurden, 30–40% der Fälle bis zur Codierung und dem Rest, der sich der Prüfung und Implementierung widmet. Die tatsächliche Projektorganisation muss stark strukturiert sein. Die meisten mittleren und großen Projekte umfassen detaillierte Verfahren und Kontrollen, die jeden Prozess des Projekts regulieren.[12][Fehlgeschlagene Überprüfung]

Ein weiteres Argument für das Wasserfallmodell besteht darin, dass es den Schwerpunkt auf Dokumentation (wie Anforderungen und Entwurfsdokumente) betont Quellcode. Bei weniger gründlich gestalteten und dokumentierten Methoden geht das Wissen verloren, wenn die Teammitglieder vor Abschluss des Projekts gehen, und es kann schwierig sein, sich von dem Verlust zu erholen. Wenn ein vollständig funktionierendes Entwurfsdokument vorhanden ist (wie es die Absicht von der Absicht ist Big Design vorne und das Wasserfallmodell), neue Teammitglieder oder sogar völlig neue Teams sollten sich durch das Lesen der Dokumente vertraut machen können.[13]

Das Wasserfallmodell bietet einen strukturierten Ansatz; Das Modell selbst führt linear durch diskrete, leicht verständliche und erklärbare Phasen und ist daher leicht zu verstehen. Es bietet auch leicht identifizierbare Meilensteine ​​im Entwicklungsprozess. Aus diesem Grund wird das Wasserfallmodell möglicherweise als Anfangsbeispiel für ein Entwicklungsmodell in vielen Software -Engineering -Texten und -kursen verwendet.[14]

Kritik

Kunden wissen möglicherweise nicht genau, welche Anforderungen sie haben, bevor sie Arbeitssoftware sehen, und ändern daher ihre Anforderungen, was zu einer Neugestaltung, Sanierung und Wiederholung sowie erhöhten Kosten führt.[15]

Designer sind sich bei der Gestaltung eines neuen Softwareprodukts oder einer neuen Funktion oder Funktionen möglicherweise nicht der zukünftigen Schwierigkeiten bewusst. In diesem Fall ist es besser, das Design zu überarbeiten, als in einem Design bestehen, das keine neu entdeckten Einschränkungen, Anforderungen oder Probleme berücksichtigt.[16]

Organisationen können versuchen, mit einem Mangel an konkreten Anforderungen von Kunden zu befassen, indem Systemanalysten verwendet werden, um vorhandene manuelle Systeme zu untersuchen und zu analysieren, was sie tun und wie sie ersetzt werden können. In der Praxis ist es jedoch schwierig, eine strikte Trennung zwischen aufrechtzuerhalten Systemanalyse und Programmierung.[17] Dies liegt daran, dass die Implementierung eines nicht trivialen Systems fast unweigerlich Probleme und Kantenfälle aufdecken wird, die der Systemanalyst nicht berücksichtigt hat.

Als Reaktion auf die wahrgenommenen Probleme mit dem rein Wasserfallmodell, modifizierte Wasserfallmodelle wurden eingeführt, wie "Sashimi (Wasserfall mit überlappenden Phasen), Wasserfall mit Unterprojekten und Wasserfall mit Risikominderung".[11]

Einige Organisationen, wie das Verteidigungsministerium der Vereinigten Staaten Mil-std-498 veröffentlicht 1994, was ermutigt Evolutionserwerb und Iterative und inkrementelle Entwicklung.[18]

Während Befürworter von Agile Software Entwicklung Argumentieren Sie, dass das Wasserfallmodell ein ineffektiver Prozess für die Entwicklung von Software ist. Einige Skeptiker schlagen vor, dass das Wasserfallmodell ein falsches Argument ist, das nur zum Markt verwendet wird Alternative Entwicklungsmethoden.[19]

Rational einheitlicher Prozess (RUP) Phasen erkennen den programmatischen Bedarf an Meilensteinen an, um ein Projekt auf dem Laufenden zu halten, aber die Iterationen (insbesondere innerhalb der Disziplinen) innerhalb der Phasen zu fördern. RUP-Phasen werden oft als "wasserfallartig" bezeichnet.

Modifizierte Wasserfallmodelle

Als Reaktion auf die wahrgenommenen Probleme mit dem "reinen" Wasserfallmodell viele viele Modifizierte Wasserfallmodelle wurde vorgestellt. Diese Modelle können einige oder alle Kritikpunkte des "reinen" Wasserfallmodells ansprechen.

Dazu gehören die schnellen Entwicklungsmodelle, die Steve McConnell nennt "modifizierte Wasserfälle":[11] Das "Sashimi -Modell" von Peter DeGrace (Wasserfall mit überlappenden Phasen), Wasserfall mit Unterprojekten und Wasserfall mit Risikominderung. Sonstiges Softwareentwicklungsmodell Es gibt auch Kombinationen wie "inkrementelles Wasserfallmodell".[20]

Royces letztes Modell

Royce Final Model

Winston W. RoyceDas letzte Modell, seine beabsichtigte Verbesserung seines anfänglichen "Wasserfallmodells", zeigte, dass Feedback (sollte und würde dies oft) von Code -Tests bis zum Entwurf führen (als Tests von Code, die in der Gestaltung entdeckt wurden) und vom Design zurück zu den Anforderungen Die Spezifikation (als Entwurfsprobleme können die Entfernung widersprüchlicher oder anderweitiger unbefriedigender / unerheblicher Anforderungen erfordern). In demselben Papier befürwortete Royce auch große Mengen an Dokumentation und erledigte den Job "zweimal, wenn möglich" (ein Gefühl ähnlich dem von Fred Brooks, berühmt für das Schreiben des mythischen Mannmonats, ein einflussreiches Buch in Software Projektmanagement, wer befürwortete die Planung, "einen wegzuwerfen") und den Kunden so weit wie möglich einzubeziehen (ein Gefühl ähnlich der von ähnlich extremes Programmieren).

Royce Notizen zum endgültigen Modell sind:

  1. Vollständige Programmdesign vor Beginn der Analyse und Codierung
  2. Die Dokumentation muss aktuell und vollständig sein
  3. Machen Sie den Job zweimal, wenn möglich
  4. Tests müssen geplant, kontrolliert und überwacht werden
  5. Den Kunden einbeziehen

Siehe auch

Verweise

  1. ^ a b Petersen, Kai; Wohlin, Claes; Baca, Dejan (2009). Bomarius, Frank; Oivo, markku; Jaring, Päivi; Abrahamsson, Pekka (Hrsg.). "Das Wasserfallmodell in der groß angelegten Entwicklung". Produktorientierter Softwareprozessverbesserung. Vorlesungen in der Verarbeitung von Geschäftsinformationen. Berlin, Heidelberg: Springer: 386–400. doi:10.1007/978-3-642-02152-7_29. ISBN 978-3-642-02152-7.
  2. ^ "Der traditionelle Wasserfallansatz". www.umsl.edu. Abgerufen 2022-02-23.
  3. ^ a b Benington, Herbert D. (1. Oktober 1983). "Produktion großer Computerprogramme" (PDF). IEEE Annals of the History of Computing. Abteilung für Bildungsaktivitäten IEEE. 5 (4): 350–361. doi:10.1109/mahc.1983.10102. S2CID 8632276. Abgerufen 2011-03-21. Archiviert 18. Juli 2011 bei der Wayback -Maschine
  4. ^ Vereinigte Staaten, Navy Mathematical Computing Advisory Panel (29. Juni 1956), Symposium für fortschrittliche Programmiermethoden für digitale Computer, [Washington, D.C.]: Büro für Marineforschung, Abteilung der Marine, OCLC 10794738
  5. ^ a b c d Royce, Winston (1970), "Verwaltung der Entwicklung großer Softwaresysteme" (PDF), Verfahren von IEEE Wescon, 26 (August): 1–9
  6. ^ "Wasserfall". Bremen University - Mathematik und Informatik.
  7. ^ Abbas, Noura; Gravell, Andrew M.; Wills, Gary B. (2008). Abrahamsson, Pekka; Baskerville, Richard; Conboy, Kieran; Fitzgerald, Brian; Morgan, Lorraine; Wang, Xiaofeng (Hrsg.). "Historische Wurzeln von agilen Methoden: Woher", kommen agiles Denken "Von?". Agile Prozesse in Software -Engineering und extremer Programmierung. Vorlesungen in der Verarbeitung von Geschäftsinformationen. Berlin, Heidelberg: Springer: 94–103. doi:10.1007/978-3-540-68255-4_10. ISBN 978-3-540-68255-4.
  8. ^ Conrad Weisert, Wasserfallmethode: Es gibt so etwas!
  9. ^ Bell, Thomas E. und T. A. Thayer. Softwareanforderungen: Sind sie wirklich ein Problem? Proceedings der 2. Internationalen Konferenz über Software -Engineering. IEEE Computer Society Press, 1976.
  10. ^ "Militär Standard Defense System Software Development" (PDF).
  11. ^ a b c McConnell, Steve (1996). Schnelle Entwicklung: Zähmung wilder Softwarepläne. Microsoft Press. ISBN 1-55615-900-5.
  12. ^ "Wasserfall -Softwareentwicklungsmodell". 5. Februar 2014. Abgerufen 11. August 2014.
  13. ^ Arcisphere Technologies (2012). "Tutorial: Der Software Development Life Cycle (SDLC)" (PDF). Abgerufen 2012-11-13.
  14. ^ Hughey, Douglas (2009). "Vergleich der traditionellen Systemanalyse und des Designs mit agilen Methoden". Universität von Missouri - St. Louis. Abgerufen 11. August 2014.
  15. ^ Parnas, David L.; Clements, Paul C. (1986). "Ein rationaler Designprozess: Wie und warum, um es zu fälschen" (PDF). IEEE -Transaktionen auf Software -Engineering (2): 251–257. doi:10.1109/tse.1986.6312940. S2CID 5838439. Abgerufen 2011-03-21.
  16. ^ McConnell, Steve (2004). Code komplett, 2. Auflage. Microsoft Press. ISBN 1-55615-484-4.
  17. ^ Enserger, Nathan (2010). Die Computerjungen übernehmen die Kontrolle. p.42. ISBN 978-0-262-05093-7.
  18. ^ Larman, Craig; Basili, Victir (2003). "Iterative und inkrementelle Entwicklung: Eine kurze Geschichte". IEEE -Computer (June ed.). 36 (6): 47–56. doi:10.1109/mc.2003.1204375. S2CID 9240477.
  19. ^ Eine Wasserfallsystementwicklungsmethode… Ernsthaft? von David Dollschave. 2012. Archiviert 2. Juli 2014 bei der Wayback -Maschine
  20. ^ "Methodik: Entwurfsmethoden".

Externe Links