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.