Viele Softwareentwickler sagen ein Aussterben des klassischen Waterfall-Vorgehens voraus. Zu früh, sagt Anton Dechko von SaM Solutions. [...]
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.
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.
* Der Artikel stammt von der deutschen Computerwoche.
Be the first to comment