Step by Step

Iterative Softwareentwicklung

Es hat sich als sinnvoll erwiesen, größere Softwareprojekte iterativ, also in mehreren Stufen anzugehen. So wird nicht nach dem klassischen Wasserfallprinzip das ganze Projekt in einem Rutsch definiert und umgesetzt, sondern in kleinere überschaubare Häppchen (Iterationen) geteilt.

Nach jeder Iteration sollte eine Abnahme mit dem Kunden erfolgen und so die Anforderungen und die Qualität der Software überprüft werden.

Diese Vorgehensweise ermöglicht auch, die technisch oder inhaltlich riskantesten Bereiche eine Softwareprojektes zuerst anzugehen, um so das Projektrisiko zu mindern und die kritischen Bereiche in den folgenden Iterationen zu verfeinern und zu stabilisieren.

Das scheinbare Budgetrisiko

Ein Problem, welches sich bei dieser Vorgehensweise stellt, ist die Budgetierung eines Projektes: Aufgrund der Tatsache, dass auch die Anforderungen iterativ entwickelt werden, ist eine Festpreiskalkulation in der Regel nur schwer möglich. Jedoch muss erwähnt werden, dass auch die nach dem klassischen Pflichtenheft-Prinzip kalkulierten Projekte keineswegs Budgetsicher sind. Zwar kann festgestellt werden, wieviel Aufwand hinter der Umsetzung des zusammen entworfenen Anforderungskataloges steckt, ob die Anforderungen jedoch dem tatsächlichen Anforderungen im Produktivbetrieb entsprechen, ist häufig fraglich. Sind grundlegende Anforderungen übersehen oder falsch interpretiert worden, kann dies im schlechten Fall höchst aufwändige Anpassungen oder sogar ein Scheitern des Projektes nach sich ziehen.

Das Risiko in einem solchen Fall trägt ebenfalls (wie bei der iterativen Vorgehensweise) der Kunde: Der Dienstleister hat sich ja über das Pflichtenheft abgesichert. Das Gefühl vieler Kunden, bei einer festpreisigen Pflichtenheft-Vorgehensweise ein geringeres Risiko einzugehen ist also ein Trugschluss.

Vorteile iterativer Entwicklung

Da man sich in den ersten Iterationen auf die technisch und inhaltliche riskanten Aspekte eines Softwareprojektes konzentriert, sinkt das Projektrisiko. Sollte die gewählte Technologie nicht tragfähig sein oder sollte es Inkonsistenzen in den definierten Anforderungen geben, so kann möglichst früh die Notbremse gezogen und entsprechend reagiert werden.

Durch das ständige Abgleichen der Anforderungen nach jeder Iteration steigt die Qualität der Software. Das Produkt ist am Ende in der Regel besser auf den realen Prozess und die Anforderungen des Kunden abgestimmt.

Lesen Sie weiter: