Zijn fouten kostbaar bij software ontwikkeling? – Deel I

Kostbare foutjes

De stelling

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

De mantra die begon in het waterval-tijdperk en die velen zullen herkennen. Tot in den treure stak het wel weer ergens de kop op tijdens een presentatie. Vaak vergezeld gaand van de bekende curve van Barry Boehm.

Afbeelding Klopt dat wel?Maar, 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?

 

Weinig tijd?Spring naar Conclusie en de Sleutels tot Succes

Waterval

Tegenwoordig is het bijna allemaal agile maar terug in de tijd was het altijd waterval wat de klok sloeg. Kenmerkend voor deze methode van softwareontwikkeling is dat zij lineair een aantal fasen doorloopt; analyse, basisontwerp, technisch ontwerp, bouw, testen, integratie, beheer en onderhoud. Men start in fase 1 en start met fase 2 als de eerste fase is afgerond, en zo verder naar de volgende fases. Vloeiend naar beneden als een waterval.

De term “waterval” wordt toegeschreven aan W.W. Royce die deze in 1970 introduceerde. Markant details is dat hij zelf zijn conceptversie verre van volmaakt vond, hij noemde het zelfs gewaagd en gedoemd te mislukken. Royce zag meer in een herhaalde methode, het iteratief model, met de mogelijkheid tot terugkoppeling naar de vorige fase zoals we dat nu zien. De kritiek van Royce op zijn conceptversie werd grotendeels genegeerd. De methodiek werd breed en langdurig omarmd.

Voordeel:

Er worden veel voordelen aan de waterval methodiek toegeschreven waarvan we er twee uitlichten:

  • Wanneer in het begin van het project fouten worden ontdekt, kost het minder inspanning (en dus minder tijd en geld) om deze fout te herstellen.
  • Bij het watervalmodel legt men de nadruk op documentatie. In de nieuwere softwareontwikkelingsmethoden maakt men minder documentatie.

Het tweede is een sterk punt ten opzichte van de huidige methodieken omdat het de kennisoverdracht voor het team eenvoudiger maakt en het project minder vertraagt.

Nadeel:

Punt 1 valt samen met één van de belangrijkste nadelen van de waterval methodiek;

  • Het testen gebeurt pas in een van de laatste fasen van het project. Bij veel andere softwareontwikkelingsmethoden wordt getest zodra er één bepaald deelproduct klaar is en ook wordt op het laatst een integratietest gedaan.

V-model

Eveneens een bekend en ‘wereldberoemd’ fenomeen in de testwereld.

Het V-model

De opvolger en afgeleid van de ‘waterval’ methode; het V-model. In 1986 ontworpen door Paul E. Rook. In tegenstelling tot de waterval methode, is de aandacht tussen ontwikkeling en verificatie in het V-model meer in balans. Net als in ‘waterval’ worden in het softwareontwerp een aantal fasen gevolgd. De afronding van een fase, welke 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 aanvang van een volgende fase. Elke specificatiefase aan de linkerzijde van de ‘V’ kent een corresponderende 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.

Voordeel:

  • Elke fase van integratie wordt getest

Nadeel:

  • 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 wel? Stijgen de kosten exponentieel naarmate defects/bugs later in de cyclus van softwareontwikkeling worden gevonden?

Je hebt eigenlijk twee stromingen waarbij sommigen van mening zijn dat het extreem duur is om wijzigingen tot laat in het software ontwikkelcyclus te laten, dat de kosten van verandering exponentieel stijgen.

Terwijl de andere stroming beweert dat wijzigingen zo laat mogelijk moeten worden gelaten, omdat de kosten van het wijzigen van software in wezen laag zijn (of in ieder geval kunnen zijn)

De eerste stroming volgt duidelijk de lijn van Boehm die zijn conclusies trok uit op data-gebaseerde onderzoeken van waterval-projecten bij TRW en IBM. Gepubliceerd in zijn boek ‘Software Engineering Economics’ (1981). En deze conclusies zijn wetenschappelijk onderbouwd en bevestigd in latere studies.

Er bestaat enige controverse over hoe nauwkeurig en volledig deze gegevens zijn en hoe representatief deze vandaag de dag nog zijn. Belangrijk verschil zit ook in 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 eventuele mogelijke vertraging kom je al gauw op een wezenlijk ander kostenplaatje. Bovendien hebben we inmiddels veel betere ontwikkeltools en zijn overgestapt van zware sequentiële watervalontwikkeling naar lichtgewicht iteratieve, incrementele ontwikkelingsmethoden.

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, in plaats van software proberen te definiëren, ontwerpen en bouwen in een waterval-sequentie.

Dezelfde ideeën liggen achter meer moderne, lichtere Agile-ontwikkelingsbenaderingen.

Kent Beck (Extreme Programming) zegt dat de kosten van changes kunnen worden verlaagd als teams hieraan werken, gebruikmakend van de principes in XP, zoals:
– Eenvoudig ontwerp, het eenvoudigste doen dat werkt en direct nodig is. (YAGNI),
– Voortdurend 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 om hun behoefte steeds scherper te krijgen; samen bouwen en samenwerken om oplossingen te ontwerpen en problemen op te lossen, en om fouten en misverstanden vroegtijdig te signaleren en elimineren,
– Zich baseren op werkende software boven documentatie om de hoeveelheid papierwerk die bij elke wijziging moet worden gedaan te minimaliseren (onder het motto: “schrijf code, geen specificaties”)

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.

Er is geen reden waarom de kosten voor het wijzigen van software zo hoog moeten zijn als 30 jaar geleden. We kunnen het vandaag zeker beter doen, met betere tools en betere, goedkopere manieren om software te ontwikkelen.

LSleutels tot Succesees ook Deel II – De Sleutels tot Succes en de Conclusie

 

Wil je meer weten?

Wij zijn telefonisch bereikbaar maar mocht je verder willen lezen over dit onderwerp:

Onze blog over CI-tools

Voer over de Businesscase en waarde creatie

Achtergrond artikelen over de cost of defect:

Beter documenteren is als onderwerp niet ‘sexy’ voor een blog maar belt u hier gerust over.

Raakt deze materie jouw vakgebied als requirement engineer, developer, scopemanager, scrummaster, test specialist of anderszins horen wij graag van jou – wij zijn continu op zoek naar de beste mensen en vooral voor organisaties met een duidelijke maatschappelijke taakstelling – kijk ook even naar onze vacatures

Op de hoogte blijven? Volg dan ook onze corporate Linkedin pagina

Geef een reactie

Your email address will not be published.

top