Exkurs: Wasserfall Model
Last updated
Last updated
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
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.
Der Prozess wurde als solcher nie von Royce propagiert
Erstmals genannt im Paper von von Bell & Thayer, Software requirements: Are they really a problem?, 1976
Aber 1986 im Department of Defense Standard 2167A (DOD-STD-2167A) als quasi Entwicklungsstandard für externe Entwicklungspartner eingeführt
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.
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
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.