Hoe kostbaar zijn fouten in welk stadium van softwareontwikkeling? – Deel I

BLOG | LEESTIJD: 4 MINUTEN

De stelling:

Hoe later een defect wordt gevonden in de levenscyclus van softwareontwikkeling, hoe duurder het is.

Elke IT-er die al even meeloopt, zal bovenstaande stelling herkennen. Dit was dé mantra in het zogenaamde waterval-tijdperk. In elke presentatie werd je wel een keer gewezen op deze waarschuwing. Vaak geïllustreerd door de bekende curve van Barry Boehm. Maar nu de hamvraag: klopt deze stelling wel?

• Stijgen de kosten exponentieel naarmate defects/bugs later in de cyclus van softwareontwikkeling (ADLC/SDLC) worden gevonden?
• En wat zijn succesfactoren om de kosten van wijzigingen wel te bedwingen en mogelijkheden om het softwareontwikkelproces te verbeteren?

Om daar antwoord op te kunnen geven, kijken we eest even naar het verleden.

De watervalmethode, wat was dat ook alweer?

Tegenwoordig is agile het toverwoord, maar nog niet eens zo heel lang geleden was de watervalmethode een zeer populaire methode voor softwareontwikkeling. Kenmerkend voor deze methoden, in 1970 geïntroduceerd door W.W. Royce, is dat de ontwikkeling lineair een aantal fasen doorloopt. Namelijk: analyse, basisontwerp, technisch ontwerp, bouw, testen, integratie, beheer en onderhoud. Je start in fase 1 en gaat verder met fase 2 als de eerste fase is afgerond. Zo werk je steeds verder naar de volgende fases. Vloeiend naar beneden, als een waterval. Markant detail: Royce vond zijn conceptversie zelf verre van volmaakt. Hij noemde het zelfs ‘gewaagd en gedoemd te mislukken’. Royce zag meer in een herhaalde methode, het iteratief model, met de mogelijkheid om terug te koppelen naar de vorige fase, zoals we dat nu zien. De kritiek van Royce op zijn conceptversie werd grotendeels genegeerd en de methodiek werd breed en langdurig omarmd.

Twee voordelen van de watervalmethode:

• Wanneer fouten in het begin van het project worden ontdekt, kost het minder inspanning (en dus minder tijd en geld) om deze fout te herstellen.
• Bij het watervalmodel ligt de nadruk op documentatie. Dit is een sterk punt ten opzichte van de huidige methodieken waarin minder documentatie is. Documentatie maakt kennisoverdracht voor het team eenvoudiger en vertraagt het project minder.

Een nadeel van de watervalmethode:

• Testen gebeurt pas in één van de laatste fasen van het project en dus niet zodra er één bepaald deelproduct klaar is.

De stap na waterval: het V-model

De opvolger en afgeleide van de watervalmethode was het V-model, in 1986 ontworpen door Paul E. Rook. In het V-model is de aandacht tussen ontwikkeling en verificatie meer in balans. Net als in het watervalmodel worden in het softwareontwerp een aantal fasen gevolgd. De afronding van een fase, die gepaard gaat met de oplevering van een bijbehorend (en vooraf gespecificeerd) product, vormt de basis voor een volgende fase. De afgeronde fase moet goedgekeurd zijn en is voorwaardelijk voor de start van een volgende fase. Bij elke specificatiefase aan de linkerzijde van de V hoort een integratiefase aan de rechterzijde van de V. Het V-model is een lineaire methode en volgt altijd de lijn: links van boven naar beneden, rechts van beneden naar boven.

Belangrijkste voordeel van de V-methode:

• Elke fase van integratie wordt getest.

Belangrijkste nadeel van de V-methode:

• In elke fase bestaat de kans op fouten. In het V-model vindt de eerste verificatiefase plaats na het ontwerp van de modules.

Terug naar de stelling

“Hoe later een defect wordt gevonden in de levenscyclus van softwareontwikkeling, hoe duurder het is.” Klopt deze stelling nu wel of niet? Er is een stroming die van mening is dat het extreem duur is om wijzigingen laat in de software-ontwikkelcyclus te doen, omdat de kosten van verandering exponentieel stijgen. De andere stroming beweert dat wijzigingen zo laat mogelijk moeten worden gedaan, omdat de kosten van het wijzigen van software in wezen laag zijn (of in ieder geval kunnen zijn).

Wijzigingen moeten zo vroeg mogelijk gedaan worden!
De eerste stroming volgt duidelijk de lijn van Boehm die zijn conclusies trok uit op data-gebaseerde onderzoeken van watervalprojecten bij TRW en IBM. Deze conclusies zijn gepubliceerd in zijn boek Software Engineering Economics (1981), wetenschappelijk onderbouwd en bevestigd in latere studies.

Of toch niet?

Kleine kanttekening: er bestaat enige controverse over de nauwkeurigheid en volledigheid van deze gegevens en hoe representatief deze vandaag de dag nog zijn. Cruciaal is ook welke kosten je aan een change toerekent. Meestal kijkt men enkel naar de directe uren programmeertijd, maar als je zaken zoals root cause analyse, opnieuw testen en allerlei andere kosten berekent, even los van de business cost van een mogelijke vertraging, kom je al gauw op een wezenlijk ander kostenplaatje. Bovendien hebben we inmiddels veel betere ontwikkeltools en zijn we overgestapt van zware sequentiële watervalontwikkeling naar lichtgewicht iteratieve, incrementele ontwikkelingsmethoden.

De weg naar Agile

Boehm realiseerde zich in de jaren tachtig dat we vroegtijdig meer fouten zouden kunnen vinden (en dus de kosten van ontwikkeling kunnen verlagen) als we vooraf risico’s in overweging nemen en software incrementeel ontwerpen en bouwen met behulp van wat hij het Spiral Model noemde. Dit in plaats van software proberen te definiëren, ontwerpen en bouwen in een waterval-sequentie. Dezelfde ideeën zijn de basis voor meer moderne, lichtere Agile-ontwikkelingsbenaderingen.

Kent Beck (Extreme Programming) zegt dat de kosten van changes kunnen worden verlaagd als teams gebruik maken van de principes in XP, zoals:

• Eenvoudig ontwerp: het eenvoudigste doen dat werkt en direct nodig is. (YAGNI),
• Voortdurende en gedisciplineerde refactoring van code om deze begrijpelijk en makkelijk onderhoudbaar te houden.
• Test Driven Development: vooraf geautomatiseerde tests schrijven (TDD) om codeerfouten onmiddellijk op te sporen.
• Nauwe en constante samenwerking tussen ontwikkelaars en de klant. Samenwerken om oplossingen te ontwerpen en fouten en misverstanden vroegtijdig te signaleren en elimineren.
• Werkende software boven documentatie. Om de hoeveelheid papierwerk bij wijzigingen te minimaliseren (onder het motto: schrijf code, geen specificaties).

Wat is nou de conclusie?

Zijn de werkelijke kosten van verandering exponentieel of zijn ze vlak? De waarheid is niet voor elk ontwikkelproces gelijk en ligt ergens in het midden. De kosten voor het wijzigen van software hoeven niet zo hoog te zijn als 30 jaar geleden. We kunnen het vandaag zeker beter doen, met betere tools en betere, goedkopere manieren om software te ontwikkelen. De écht econclusie en het antwoord op de vraag, lees je in deel 2!