First page Back Continue Last page Overview Graphics
Wasserfall mit Iteration
Notes:
Rasch zeigten sich Kritikpunkte am Wasserfall:
Softwareentwicklung ist kein wasserfallartiger Prozess. Jede einzelne Spezifikation, die im Verlauf der Phasen entsteht ist fehlerträchtig und macht ein Zurückkehren zu einer vorangegangenen Phase angezeigt.
Das Wasserfallmodell berücksichtigt nicht, dass eine Anforderungsspezifikation unpräzise oder an den Vorstellungen des Auftraggebers vorbei entwickelt worden sein könnte.
Der Auftraggeber hat selten präzise Vorstellungen vom Endergebnis. Es kristallisieren sich wesentlich Punkte erst relativ spät im Entwicklungsprozess heraus
Eine lauffähige Version steht im Wasserfallmodell erst gegen Ende der Implementierungsphase zur Verfügung. Viele – gerade Spezifikations~ - Fehler werden für die Benutzern erst jetzt sichtbar = bewusst.
Durch das berühmte Nichteinhalten der Projektdauer fällt im Wasserfall das Projektende mitten in die Testphase . Lässt sich diese nicht „verlängern“, sind mangelhaft getestete Produkte die Folge. Das ist zwar an sich ein Management~ und kein Modellfehler, aber das Modell verstärkt diese.
Testen nur am Ende der Entwicklung ist ein Kritikpunkt für sich. Im Sinne einer allgemeinen Qualitätssicherung wäre möglichst frühzeitiges Testen wünschenswert
Die genannten Schwächen haben bereits frühzeitig zur oben dargestellten Erweiterung des Wasserfallmodells geführt: dem Wasserfall mit Iterationen. Hier werden alle Aktivitäten mehrfach durchlaufen.
Dazu wird das Projekt in Teilprojekte zerlegt, von denen jedes in einer „Iteration“ implementiert wird, sodass das Gesamtprojekt sozusagen „zwiebelschalenartig“ aufgebaut wird. Zuerst implementiert man einen Funktionskern, den man in weiteren Iterationen um immer weitere Funktionalitäten erweitert. Die Teilprojekte können parallel ablaufen und befinden sich nicht unbedingt im selben Stadium!
Verwechseln Sie bitte nicht die Vorgangsweise eines iterierten Wasserfalls mit „durcheinander Programmieren wie es uns einfällt“! Jede Iteration (Teilprojekt) ist bereits im Vorfeld zumindest zu benennen und wenn es soweit ist, gemäß einem ordentlichen Ablauf umzusetzen. Seien Sie auf der Hut, wenn Sie Aussagen hören wie: „Der Code dieser Iteration ist nicht so gut gelungen, aber das bessern wir in nachfolgenden Iterationen aus“. Eine solche Aussage ist ein untrügliches Zeichen dafür, dass Projektleitung und/oder Team nicht verstanden haben, worauf es beim iterierten Wasserfall ankommt: Eine nachfolgende Iteration ist nicht dazu da, Schwächen vorangegangener Iterationen auszumerzen sondern soll neue Funktionalität implementieren.
Zusammengefasst: Der iterierte Wasserfall versucht die Schwächen des Wasserfalls auszumerzen, indem das Projekt in Teilprojekte zerlegt wird, die ausreichend klein sind, so dass die Schwächen des Wasserfalls noch nicht zum Tragen kommen. Aber jedes dieser Teilprojekte wird gemäß Wasserfallmodell abgearbeitet.