Risk based development

Zoals we in de testwereld al gewend zijn aan productrisico's als input voor testen en prioriteitstelling, is het gebruiken van deze risico's in de testfase, een beetje het paard achter de wagen spannen. Als we deze productrisico's toch al kennen, waarom nemen we ze dan niet mee in een eerder stadium?

In de testwereld zijn we inmiddels gewend geraakt aan het gebruik van productrisico's als input voor de prioritering van testcases. We hebben gezien dat het focussen op de belangrijkste productrisico's de meest effectieve testen oplevert, doordat in de beschikbare tijd de onderdelen van het system under test (SUT) met het hoogste productrisico als eerste wordt getest. Door naar onze opdrachtgevers te rapporteren over de productrisico's die al dan niet afgedekt zijn met goed doorlopen testgevallen spreken we de taal van de opdrachtgever en andere stakeholders. Het communiceren over productrisico's heeft hiermee nog een extra voordeel.

Het beste moment om de productrisico's te analyseren is aan het begin van de software development life cycle (SDLC), tegelijkertijd met de requirements-analyse, omdat op dat moment de productrisico's ook gebruikt worden om de omissies te vinden in de requirements. Op deze manier levert het werken met productrisico's een kwaliteitsverbetering op ten behoeve van de requirements.

Door de requirements aan een statische test (bijvoorbeeld inspectie) te onderwerpen, zien we dat we ‘testen' ook kunnen gebruiken om in een vroeg stadium van de SDLC bevindingen te doen op de requirements en daarmee te voorkomen dat fouten pas later in het SDLC ontdekt worden. Testen helpt hiermee de kwaliteit van de requirements te verhogen en daarmee de kwaliteit van de opgeleverde software. De herstelkosten van fouten in deze fase worden hierdoor een stuk minder in vergelijking met fouten die in een latere SDLC-fase gevonden worden. Een groot voordeel in plaats van alleen achteraf de kwaliteit van de software te meten.

Als we deze praktijken combineren kunnen we de risico's op zichzelf ook gebruiken om de kwaliteit van de software verder te verbeteren door tijdens de ontwikkelfase aandacht te besteden aan de productrisico's die we geïdentificeerd hebben. Op deze manier kunnen we tijdens de ontwerpfase en de ontwikkelfase borgen dat de productrisico's daadwerkelijk niet optreden in plaats van pas achteraf vaststellen dat de productrisico's nog steeds aanwezig zijn tijdens de testfase.

Nu wordt bij veel bedrijven wel degelijk risicoanalyse meegenomen in het ontwikkelproces, maar deze risico's zijn niet de productrisico's, maar projectrisico's of risico's zoals deze door een beveiligingsafdeling geanalyseerd zijn. Focus op productrisico's, wat is de schade als het product niet doet wat het moet doen, zien we in deze stadia maar zelden.

Uiteraard kunnen de productrisico's tijdens de ontwikkelfase ook gebruikt worden om prioritering aan te brengen in de developmentactiviteiten, zodat de grootste productrisico's vroegtijdig aangepakt kunnen worden, waardoor stabielere en betere software afgeleverd kan worden.

Een manier om dat te doen is het afdwingen van product risk mitigation plans tijdens elke fase van het ontwikkeltraject. In deze product risk mitigation plans kan worden bijgehouden welke maatregelen genomen worden of zijn genomen om de kans op optreden van de productrisico's tegen te gaan. Hiermee kunnen we ook zien welke productrisico's expliciete aandacht hebben gehad en welke risico's nog aandacht verdienen. Als we tevens bij alle productrisico's bepalen in welke fase van de software development life cycle we deze productrisico's willen afdekken, kan het vastleggen van productrisico beperkende maatregelen, ook randvoorwaardelijk zijn voor de overgang een volgende fase in het project.

Een belangrijk voordeel hiervan is dat in een vroeg stadium duidelijk wordt welke acties ondernomen moeten worden om de productrisico's af te dekken. Zo kunnen performance gerelateerde eisen vaak in een vroeg stadium van het ontwerptraject aandacht vragen, bijvoorbeeld tijdens de keuze van een nieuwe architectuur of nieuw ontwikkelplatform. Door de productrisico's expliciet mee te nemen in de verschillende SDLC-fasen, is de kans dat de productrisico's worden beperkt groter, waardoor het optreden van productrisico tijdens de testfase kleiner is.

Op deze manier maken we optimaal gebruik van de productrisicoanalyse die we toch al aan het begin van het project (willen) uitvoeren en verhogen we de kwaliteit van de op te leveren software op het moment dat het er toe doet; niet in de bugfix-fase maar in de bouwfase.