U kent het wel. Er loopt een project en dat project heeft een deadline. Wordt die deadline gehaald?
Een goede vraag. Uitloop is bij ICT-projecten standaard. Dat hoeft echter niet zo te zijn. Met een goede analyse van de gevonden en opgeloste issues kunnen je statistisch een uitstekende voorspelling doen.
Ieder ICT project kent fasen. Kort: er wordt software gespecificeerd, ontworpen, ontwikkeld, tijdens ontwikkeling getest, opgeleverd en nogmaals getest voor ze in productie komt. In elke fase worden defects gevonden. En opgelost. Uit onderzoek blijkt dat het aantal issues dat in elke fase ontstaat redelijk voorspelbaar is, gegeven de kwaliteit van het proces en de omvang van de code.
Zo wordt in ontwikkeling gerekend met aantal defects per KLOC. Een KLOC staat voor 1000 regels code. Bij een uitstekend ontwikkelproces is het aantal defects per KLOC in de ontwikkelfase 10 tot 50 of meer. Bij grotere aantallen fouten wordt meestal het project voortijdig gestopt. Door een proces van testen en fixen neemt het aantal fouten af. In commerciële leveringen, geschikt voor productie, resteren 0,2 tot 1 fout per KLOC. Voor uitzonderlijke projecten, waarbij foutvrijheid essentieel is, kan door intensief testen en kwaliteitszorg het defectpercentage nog lager worden, tot aan 0,01 defect per KLOC.
Defects tijdens ontwikkeling ontstaan, statistisch gezien, volkomen willekeurig. Ze zijn onderdeel van het ontwikkelproces. Hoe meer inspanning, hoe hoger het aantal gegenereerde defects per week wordt. Nadat de bulk van het systeem is geprogrammeerd worden nagenoeg geen defects meer geïntroduceerd.
Het vinden is een ander verhaal.
Defects vinden is een tijdrovend proces dat ook een eigen productiviteit kent. Bij uitstekend geschreven software is het vinden van defects moeilijk, bij slechte software is het een makkie om defects te vinden. Statistisch gezien varieert de defect detection rate (DDR) van 0,5 tot 20 per mens-week. Bij een lagere DDR stopt men met testen, tenzij de eisen heel hoog zijn: bij veiligheidssoftware, medische toepassingen en ruimtevaart.
En tenslotte, defects oplossen is, statistisch gezien, ook een proces met een bepaalde kans. Het ene defect los je op in een paar uur, een ander kan weken kosten. De productiviteit ligt in de praktijk rond gemiddeld 2 weken per fix. En ook daarin is variatie. Agile ontwikkeling tendeert naar een sneller oplosproces dan traditioneel ontwikkelen.
De opeenvolgende fasen maken dat het aantal open defects in het begin snel toeneemt, een maximum bereikt en vervolgens langzaam afneemt. Onderzoek heeft uitgewezen dat het aantal open defects een zgn. Rayleigh-curve volgt. We hebben daar een praktijkvoorbeeld van:
Hoewel het, in dit geval, rond week 40 het erop leek dat alle defects bijna opgelost waren, werden er in week 41 en 42 weer nieuwe gevonden. Zoiets is normaal. Fixen genereert nieuwe issues. Gelukkig werden ook deze defects snel opgelost.
Het interessante is dat een Rayleigh curve helpt om het moment te bepalen dat de software bijna klaar is. Dat is het moment dat 90 tot 95% van alle gevonden defects zijn opgelost, de zwarte lijn in de grafiek. Uit ervaring weten we dat dan de resterende defects te managen zijn.
Met resterende defects managen bedoelen we: de defects zijn bekend, en er komen weinig nieuwe bij. Je kunt nu besluiten welke resterende defects acceptabel zijn en welke opgelost moeten worden voordat je in productie kan gaan. Dat laatste kost nog extra tijd.
Dit softwaresysteem ging uiteindelijk, na een intensieve testperiode, in week 50 in productie.
Omgekeerd, er geldt ook dat als het aantal open defects nog stijgende is, of misschien net op het maximum, er nog lang geen sprake is van productie-rijpe software.
Een voorbeeld daarvan is te zien in deze grafiek:
Een analyse zoals bovenstaand helpt om verwachtingen van stakeholders te managen. Zo’n tijdanalyse is gebaseerd op onderzoek van honderden software ontwikkelprojecten en het heeft daardoor een grote kracht van voorspelling.
Als je Rayleigh-curves bij een project wilt toepassen is het wel uiterst belangrijk dat er een betrouwbare registratie is. Worden bijvoorbeeld gevonden defects niet alle geregistreerd, dan lijkt het alsof de gebouwde software beter is. Met gevolg: er komen later meer defects aan het licht dan verwacht. Met volgend gevolg: uitstel van inproductiename.
Een softwareproject waarvan de kwaliteit onvoldoende is, dat is in wezen kapitaalvernietiging. Er gaat veel tijd en geld in het project zitten, tijd en geld die niet aan andere dingen kan worden besteed. Een extra check met een Rayleigh curve kan helpen een goed beeld van de toekomst te krijgen. ITs Jaap kan u daarbij helpen.