Exkurs: Wasserfall Model

Wasserfall

Beispiel fĂŒr Wasserfall Probleme

  • In den Tests wird das erste Mal ersichtlich, dass eine Anforderung falsch verstanden wurde...

  • Konsequenz

    • Kosten und Entwicklungszeit verdoppeln sich...

  • Weiteres Problem

    • Keine Steuerung von Risikofaktoren

Gravierende RĂŒckschritte durch spĂ€te Probleme

Warum Wasserfall?

Einge Geschichte unglĂŒcklicher MissverstĂ€ndnisse:

  • Winston W. Royce (1929-1995), Informatiker und Direktor bei Lockheed Software Technology Center

  • Paper Managing the Development of Large Software Systems, 1970 Beschreibt den fehlerbehafteten und risikoreichen Prozess der Software-Entwicklung in den 1960ern

I believe in this concept, but the implementation described above is risky and invites failure.

Wasserfall Ursprung

The same top-down approach to a series of requirements statements is explained, without the specialized military jargon, in an excellent paper by Royce ;he introduced the concept of the “waterfall” of development activities. In this approach software is developed in the disciplined sequence of activities shown in Figure I.

  • Allerdings sieht DOD-STD-2167A vor, dass der Prozess iterativ ausgefĂŒhrt werden kann, wodurch grundsötzlich auch eine agile Arbeitsweise möglich gewesen wĂ€re.

[...] The Software development process shall include the follwing major activities, which may overlap and may be applied iteratively or recursively.

MissverstÀndnisse

Das von Royce beschriebene Modell ist nicht so starr, wie oft angenommen. In den AusfĂŒhrungen von Royce finden sich Konzepte, die sich heute in Agilen Methoden und DevOps-AnsĂ€tzen wiederfinden.

  • DevOps: Entwicklung und Betrieb in einem Team

There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it

  • Scrum: Iterative Entwicklung („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


  • Scrum: Involve the customer


points following requirements definition where the insight, judgment, and commitment of the customer carl bolster the development effort.

It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery.


also the kind of development effort for which most customers are happy to pay, since both steps [Anm. Analyse u. Codierung] involve genuinely creative work which directly contributes to the usefulness of the final product.

Weiterhin schlĂ€gt Royce zahlreiche Reviews vor, um frĂŒhzeitig Feedback einzuholen:

  • Royce beschreibt in seinem Paper drei Reviews, die sich im »Wasserfallmodell« jedoch nicht finden

  • Preliminary Software Review

    • Zeitpunkt: Nach vorlĂ€ufigem Software Design

  • Critical Software Review

    • Zeitpunkt: Nach dem Programm Design

  • Final Software Acceptance Review

    • Zeitpunkt: Nach dem Testen

Zusammenfassung

  • Wasserfall war ursprĂŒnglich kein empfohlenes Vorgehensmodell, sondern beschrieb den unzureichenden Stand der Technik in den 1960ern.

  • Durch eine Verkettung von unglĂŒcklichen Ereignissen etablierte sich dieses Modell als de-facto Standard in der Software-Entwicklung.

  • Im originalen Paper von Royce finden sich bereits viele Empfehlungen und Beobachtungen, die erst ab den 2000ern in agilen Vorgehensmodellen und der DevOps-Bewegung Anklang fanden.

Last updated