Spricht man über Agilität kommt immer mal wieder das Wasserfallmodell zur Sprache. Mit seiner strengen sequentiellen Abarbeitung einzelner Projektphasen gilt es als klassischer Gegenentwurf zu Agilität.
Denn eine neue Phase im Wasserfallmodell kann erst gestartet werden, wenn eine andere abgeschlossen ist.
Dieses Vorgehensmodell wird fast immer mit Winston W. Royce in Verbindung gebracht. Und sein erweitertes Wasserfallmodell findet sich in vielen Abhandlungen zu diesem Thema.
Damit erscheint Herr Royce in einem aus heutiger Sicht ziemlich schlechten, weil unagilem Licht. Und das hat er nicht verdient.
Er hat das Wasserfallmodell nämlich gar nicht erfunden, sondern lediglich um eine agile Komponente erweitert, da auch ihm schon aufgefallen war, dass eine starre Vorgehensweise in der Praxis zu schlechten Ergebnissen führte.
Um dies zu verstehen, muss man sich vor Augen halten, vor welchen Problemen die Softwareentwicklung damals stand.
Wie die Softwarekrise zum Software Engineering führte
In der Mitte der 60er-Jahre bestimmte die Hardware die Entwicklung von Software. Deren Anwendungsgebiete waren aufgrund der begrenzten Möglichkeiten der damals eingesetzten Hardware weder komplex, transparent noch gut strukturiert. Verbesserungen im Bereich der Hardware führten dann allerdings dazu, dass sich immer mehr Aufgabengebiete für eine elektronische Bearbeitung anboten. Die neuen Aufgabengebiete wurden komplexer und ließen sich nicht mehr einfach strukturieren.
Den Entwicklern jener Zeit standen nur Methoden zu Verfügung, mit denen man kleine Programme entwickeln konnte. Diese Modelle waren der neuen Komplexität der Aufgaben jedoch nicht mehr gewachsen.
Es fehlte eine adäquate Technologie auf der Softwareseite für die Entwicklung komplexer Systeme.
Als Konsequenz dieses Sachverhaltes wurde Software schlagartig sehr teuer und konnte nicht mehr termingerecht fertiggestellt werden. Kosten- und Zeitaufwände konnten nicht mehr geschätzt werden. Außerdem mangelte es an Fachkräften, weshalb Projekte oft von Laien erstellt werden mussten.
Undurchschaubare, kaum erweiterbare und weitgehend unzuverlässige Software waren die Folgen.
Die mangelnde Zuverlässigkeit der Software führte dazu, dass ein Großteil der Programmierer mit Fehlersuche und Korrekturen beschäftigt war. Da insbesondere das Militär von diesem Umstand betroffen war, wurden gerade in diesem Bereich große Anstrengungen unternommen, die Krise zu überwinden.
Und so wurde im Jahr 1968 auf einer NATO-Konferenz erstmalig von Software Engineering gesprochen. Definiert wurde dieser Begriff von Peter Naur und Brian Randell als "establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines".
Hiermit sollte zum Ausdruck gebracht werden, dass die Softwareentwicklung, wie andere Ingenieurwissenschaften auch, einer grundlegenden theoretischen Fundierung sowie einer für die Praxis tauglichen Verfahrenstechnik bedürfe, um den folgenden Zielgrößen gerecht zu werden:
- Produktion von Software in hoher Qualität
- Erstellung von Software innerhalb eines festen Budgetrahmens
- Fertigstellung von Software zu einem geplanten Zeitpunkt
Mit der Übertragung von ingenieurwissenschaftlichen Methoden und Prinzipien auf die Softwareentwicklung ging man definitiv in die richtige Richtung. Allerdings passten die von Ingenieuren verwendeten Vorgehensmodelle nicht. Sie waren – wie bereits erwähnt – in einzelne Phasen aufgeteilt, die nacheinander abgearbeitet wurden.
Von Wasserfallmodellen war damals übrigens nicht die Rede. Dieser Begriff etablierte sich erst einige Jahre später.
Ein Wasserfall, der keiner ist
Winston W. Royce erkannte die Schwäche dieser Modelle und empfahl Rückkopplungen zwischen den einzelnen Phasen zuzulassen. Diese waren für ihn zwar immer noch Ausnahmen, da sie mit hohen Kosten verbunden waren, aber trotz allem notwendig, um den Erfolg eines Projekts sicherzustellen.
Royce setzte damit erstmalig agile Prinzipien um, wurde aber leider nicht richtig verstanden.
Dabei war er mit seiner Kritik an den bekannten Modellen sehr deutlich:
- So war es immer noch unmöglich, im Rahmen einer einzigen Analysephase eine vollständige, zeitlich überdauernde Beschreibung einer Organisation als Grundlage für eine Anforderungsdefinition zu erhalten.
- Es war immer noch mit hohen Kosten verbunden, alle einzelnen Projektphasen ohne Rückschritte vollständig zu durchlaufen.
- Eine Fehlerbehebung ausschließlich im Rahmen einer Pflege und Wartungsphase durchzuführen war nach wie vor nicht wirtschaftlich.
Außerdem führte er wichtige neue Prinzipien ein, die heute für uns selbstverständlich sind. So schlägt er beispielsweise eine frühe Benutzerbeteiligung vor:
It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery.
Usability lässt grüßen!
Es lohnt sich auf jeden Fall mal einen Blick in das Originaldokument MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS zu werfen.
Das endgültige Modell von Royce sieht übrigens wie folgt aus.
Mit einem Wasserfall, der als Begriff übrigens im gesamten Dokument von Royce nicht genannt wird, hat das wohl nichts mehr zu tun!
Kommentare