Wasserfall beziehungsweise Waterfall als Methode der Softwareentwicklung ist tot, ein Hoch auf agile Methoden wie Scrum - diese Meinung dürften viele Softwareentwickler teilen. Aber stimmt diese gängige Überzeugung auch? Die Antwort lautet Nein! Wenn man den Wasserfall richtig verwendet, kann man mit ihm ebenso effizient wie mit agilen Methoden arbeiten. Bei Applikationen mit zwingend notwendigen, kritischen Systemeigenschaften hat er sogar deutliche Vorzüge.

Um diese Position zu verdeutlichen, sollen hier zunächst die wichtigsten Vorurteile und Überzeugungen zu Waterfall kurz dargestellt und diskutiert werden. Grundsätzlich: Waterfall ist eine alte, man kann auch sagen bewährte Methode zur sequenziellen, schrittweisen Entwicklung von Software, die bereits in den 70er Jahren des vorigen Jahrhunderts formuliert wurde. Sie heißt Waterfall, da in einem mehrteiligen Prozess von Stufe zu Stufe vorgegangen wird, ähnlich wie manche Wasserfälle fallen. Die verschiedenen Phasen im Entwicklungsprozess werden entsprechend der Reihe nach abgearbeitet. So weit, so gut. Was sind nun aber die häufigsten Einwände gegenüber dieser doch plausibel klingenden Vorgehensweise?

Kritikpunkt Dokumentation

"Waterfall ist ineffektiv und veraltet - agile Methoden wie Scrum sind modern und produktiv", so eine typische Einschätzung oder Fehleinschätzung. Sie geht davon aus, dass jedes Projekt unter Waterfall überdokumentiert ist und jeder einzelne Schritt zur Behebung auftretender, unerwarteter Probleme Monate dauert.

Tatsächlich aber benötigen agile Methoden wie Scrum ebenso viele, den Entwicklungsprozess begleitende Dokumente wie Waterfall. Auf eine Spezifizierung der Anforderungen, die Dokumentation der Architektur oder die Festlegung von Testszenarien wird auch hier nicht verzichtet.

Der wesentliche Unterschied besteht darin, dass in agilen Projekten diese Dokumente parallel zum Entwicklungsprozess und typischerweise als eher informeller Text erstellt werden. Der so genannte End-User versteht diese informellen Texte besser und sieht Ergebnisse der Entwicklung unmittelbar, da der agile Ansatz auf eine schnelle Umsetzung aus ist.

Manchmal ist dies von Wert, manchmal auch nicht. Es führt aber kein Weg daran vorbei, egal in welchem Prozessmodell, eine solide Dokumentation zu erstellen. Niemand kann ungezählte Zeilen von undokumentiertem Code pflegen, warten, erweitern oder verbessern. Die Frage ist nur, an welcher Stelle im Prozess diese Dokumentation erstellt wird: Vorab wie bei Waterfall oder begleitend zur Entwicklung wie etwa bei Scrum.

1. Fokus auf Kernfunktionen
Konzentrieren Sie sich bei der Definition der Anforderungen auf die Kernfunktionen der umzusetzenden Anwendung. Das Pareto-Prinzip gilt in der Regel auch in der Softwareentwicklung. Demnach sollten 80 Prozent der Funktionalität einer Anwendung durch 20 Prozent des Funktionsumfangs erbracht werden.

2. Defensiver Technikeinsatz
Vermeiden Sie technische Spielereien. Es muss nicht immer jedes neueste Feature genutzt werden. Wägen Sie den Einsatz neuer Techniken sorgfältig ab, auch wenn diese eine höhere Entwicklereffizienz und schnelle Ergebnisse versprechen. Grundsätzlich gilt: Je mehr Funktionen, desto komplexer und damit aufwändiger und teurer wird die Anwendungsentwicklung.

3. Einsatz vorgefertigter Komponenten
Prüfen Sie, ob Sie verfügbare Komponenten, Plattformen und Produkte nutzen können. Wenn es sich um nicht allzu komplexe Teillösungen handelt, kann das viel Aufwand ersparen. Allerdings ist eine "Buy"-Entscheidung nicht in jedem Fall der richtige Weg. Wenn die Komponenten erst "hingebogen" werden müssen, bis sie allen Anforderungen gerecht werden, ist das aufwändig und birgt Folgerisiken - etwa den Verlust der Release-Fähigkeit.

6. Nutzung von Erfahrungen
Frühe Fehler können sich zu einem späteren Zeitpunkt zu Kostentreibern entwickeln. Unerfahrene Mitarbeiter sind daher ein Projektrisiko. Zumindest an den neuralgischen Punkten eines Projektes - etwa dem Architekturdesign oder der Projektplanung - sollten Sie den Projektbeteiligten daher erfahrene Mitarbeiter oder externe Berater zur Seite stellen.

7. Stabile Anforderungen und verbindliche Absprachen
Sorgen Sie für stabile Anforderungen und klare Erwartungen an das Softwaresystem sowie für verbindliche Absprachen zwischen den Projektbeteiligten und strukturierte Change-Request-Verfahren. Dieses Vorgehen wirkt auf den ersten Blick etwas bürokratisch, letztlich hilft es aber, häufige Kurswechsel im Projektverlauf und daraus resultierende arbeitsintensive Nacharbeiten zu vermeiden.

8. Kalkulation interner Ressourcen
Bewerten Sie die Verfügbarkeiten und Kapazitäten der internen Projektbeteiligten realistisch. Mitarbeiter, die beispielsweise zusätzlich zu ihrem Tagesgeschäft "nebenbei" im Projekt mitarbeiten, verursachen oft versteckte Mehrkosten, Terminverschiebungen und vor allem Qualitätsprobleme.

10. Realistische Aufwandsplanung
Planen Sie die Aufwände eher vorsichtig. Zu optimistische Einschätzungen - "das ist schnell gemacht", "das ist ja fast fertig" - verfälschen die Kalkulation. Hektisches Nacharbeiten und Terminverzüge verursachen letztlich meist mehr Kosten als sauber geplante Projekte.

Worunter Wasserfall leidet

Das grundsätzliche Vorgehen unter Waterfall besteht darin, erst die Dokumentation und dann die Software zu erstellen. Die Idee dahinter: Probleme lassen sich durch Prüfprozesse identifizieren, bevor die Software erstellt worden ist, was durchaus von Vorteil sein kann. In der Praxis sieht ein typischer Waterfall trotzdem oft etwas ungeplant aus: Anforderungen an die Entwicklung werden in freier Textform eingereicht, gerne in ungeordneter Form auf unzähligen Seiten, immer aber unvollständig und inkonsistent. Prioritäten existieren ebenfalls nicht, denn jede Funktion ist gerade so wichtig wie eine andere auch. Zeit für einen soliden Prototypen gibt es ohnehin nicht, denn üblicherweise kommen die Anforderungen später als geplant, und die Termine für die Fertigstellung der Software lassen sich leider nicht verschieben.

Der Entwicklungs-Manager beginnt daher mit der Entwicklung, egal welche Anforderungen vorliegen. Die Dokumentation erfolgt dann nach der Fertigstellung der Architektur. So spart man sich unnötiges Umschreiben, denn Änderungen oder Erweiterungen sind auf der bestehenden Basis ohnehin nicht zu vermeiden. Eine weitergehende Begutachtung der Architektur entfällt. Für die Qualitätssicherung und Fehlerbehebung wird einfach der letzte Monat (oder die letzte Woche) reserviert, da ja keine formale Basis für Qualitätsmerkmale besteht. Abschluss und Akzeptanz eines so ablaufenden Projekts sind oft schmerzhaft, denn jeder hat das Mögliche getan, aber die Erwartungen von niemandem wurden erfüllt.

Wo Wasserfall trotzdem gut funktioniert

Am Anfang jeder Softwareentwicklung stehen die Anforderungen. Waterfall funktioniert genau dann sehr gut, wenn Endanwender oder Produkt-Management formalisierte Anforderungen auf einer halbwegs konstanten Basis anbieten können. Dabei muss es sich nicht einmal zwingend um Modelle aus der Unified Modeling Language (UML) oder aus einer anderen standardisierten Modellierungssprache handeln. Es sollte lediglich um Anforderungen gehen, die bis zu einem bestimmten Grad strukturiert sind. Ein derart einheitlicher Informationsfluss wird zur verlässlichen Größe und führt auch zu ziemlich genau planbaren Zeiträumen im Entwicklungsprozess.

Seine eigentliche Stärke spielt Waterfall aber an anderer Stelle aus. Nämlich dort, wo die zwingend erforderlichen Eigenschaften einer Software große Bedeutung für ihre systemweiten Fähigkeiten haben, so etwa bei der Performance, Sicherheit oder Zuverlässigkeit. Also dort, wo eine sorgfältige Balance oder Abstimmung notwendig ist, um den nichtfunktionalen Anforderungen zu begegnen. An solchen Stellen ist es immer eine gute Idee, die Anforderungen aufzuschreiben und auf einer formalisierten Grundlage mit den Projektbetroffenen vorab zu diskutieren. Geschieht dies nicht, ist die Gefahr einer unerwarteten Anpassung der Architektur während des laufenden Prozesses oder von übersehenen Systemanforderungen einfach zu groß.

Wenn Systemeigenschaften wie Performance, Sicherheit oder Zuverlässigkeit hohen oder sehr restriktiven Standards begegnen, etwa bei Systemsoftware oder Kommunikationslösungen, gibt es ebenfalls keine Alternative. An vielen Stellen im Geschäftsleben sind formalisierte Dokumentationen erforderlich, um den üblichen Standards verlässlich zu genügen. Daher sollte niemand grundsätzliche Bedenken gegenüber unnötigem "Papierformalismus" und Methoden wie Waterfall hegen. In manchen Projekten funktioniert ein agiler Ansatz ganz einfach nicht. (ph)

Bilder/Grafiken: Fotolia, Marvellous World, SaM Solutions