🐢
SEKS
  • Kursinformationen
    • Termine
  • Einheit 01: Komplexität
    • Aufgabe Kurzreferat
    • Beispielvideos
  • C4 Software Dokumentation
    • Lab: C4 Modell
  • Einheit 02: Projektmanagement
  • Exkurs: Vorgehensmodelle
  • Einheit 03: Scrum
  • Exkurs: Wasserfall Model
  • Einheit 06: Testen
  • Einheit 07: Anforderungsanalyse
  • Einheit 08: TDD und MOCKs
  • Lab 01: Projektplan
  • Lab 02: Backlog Planung
  • Lab 03: Personas
  • Downloads
  • Einheit 05: Metriken
Powered by GitBook
On this page
  • Wasserfall
  • Beispiel fĂźr Wasserfall Probleme
  • Gravierende RĂźckschritte durch späte Probleme
  • Warum Wasserfall?
  • Wasserfall Ursprung
  • Missverständnisse
  • Zusammenfassung

Exkurs: Wasserfall Model

PreviousEinheit 03: ScrumNextEinheit 06: Testen

Last updated 1 year ago

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

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

Wasserfall Ursprung

  • Der Prozess wurde als solcher nie von Royce propagiert

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.

Paper , 1970 Beschreibt den fehlerbehafteten und risikoreichen Prozess der Software-Entwicklung in den 1960ern

Erstmals genannt im Paper von von Bell & Thayer, , 1976

Aber 1986 im Department of Defense Standard 2167A () als quasi Entwicklungsstandard fĂźr externe Entwicklungspartner eingefĂźhrt

Managing the Development of Large Software Systems
Software requirements: Are they really a problem?
DOD-STD-2167A