TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
In einem typischen Wasserfall- bzw. V-Modell gibt es aufeinanderfolgende Phasen wie Anforderungsdefinition, Fachkonzept, Design, Codierung, Modultest, Integrationstest, Systemtest und Abnahmetest. Die Fehler, die die Entwickler in den Phasen Anforderungsdefinition bis Codierung machen, werden meist erst in den Testphasen entdeckt, also zu einem relativ späten Zeitpunkt. Der Aufwand, die Fehler dann zu korrigieren („Rework-Aufwand“), ist zum Teil erheblich und nimmt in einem typischen Softwareprojekt in der Summe ungefähr die Hälfte des Entwicklungsaufwands ein.
Seit ungefähr 1975 werden daher in vielen Projekten Software-Inspektionen eingesetzt. Diese Inspektionen (oft auch „Software-Reviews“ genannt) dienen dazu, sofort nach Fertigstellung eines Dokuments („Artefakts“) möglichst viele Fehler zu entdecken. Die gravierenden Fehler, also die Fehler, die später Zeit kosten und damit Rework-Aufwand verursachen, bezeichnet man als „Major Defects”. Mit richtig durchgeführten Inspektionen kann man ungefähr die Hälfte bis zu 2/3 der in den Dokumenten vorhandenen Major Defects finden und damit den Rework-Aufwand entsprechend verringern. Der Gesamt-Entwicklungsaufwand des Projekts reduziert sich damit um ungefähr 25 % bis 35 %.
2. Agile Software-Entwicklung
| | | |
Pair Programming und anderes „Reviewartiges“ in der agilen Software-Entwicklung |
Agile . since Jun 23 . Index . DOCs TOP TOC
Eine Gemeinsamkeit der verschiedenen agilen Entwicklungsmethoden ist, dass das zu entwickelnde System in vielen Iterationen (oder „Sprints“) entsteht. Iterationen dauern üblicherweise ein bis vier Wochen. Am Ende jeder Iteration steht ein getestetes und lauffähiges System („potentially shippable code“) mit neu dazu gekommener Funktionalität. Agile Entwicklungsmethoden bedienen sich in unterschiedlichem Ausmaß weiterer agiler Praktiken wie Test-Driven Development (TDD), Refactoring etc. Im Gegensatz zu Wasserfall-Projekten kann in agilen Projekten auf sich ändernde Anforderungen oder Prioritäten schnell reagiert werden. Es gibt einen sehr frühen Return on Investment, weil der Kunde schon nach der ersten Iteration ein lauffähiges System hat, das er produktiv einsetzen kann. Ein komplettes Scheitern des Projekts (kein lauffähiger Code), wie es bei Wasserfall-Projekten immer wieder vorkommt, ist wenig wahrscheinlich.