Risico’s

Risico binnen software is een waarde oordeel op twee gebieden. Het eerste gebied is het belang van het bedrijfsproces dat je ondersteunt; welke (soorten) kwaliteit zijn voor je bedrijfsdoel belangrijk? En daarmee dus: wat is de impact als het misgaat. Het tweede gebied is een (meestal technische) inschatting van de kans dat er iets misgaat.

Daarbij heb je antwoord nodig op 3 vragen.

Beste klant, hoe belangrijk is het dat …

bedrijfsbelangBijvoorbeeld hoe belangrijk is het dat het melden van een schade op de autoverzekering goed gaat? En dat was dus functioneel, maar het kan ook op gebruiksvriendelijkheid: hoe belangrijk is het dat de klant op een snelle, logische manier zijn scooterverzekering kan afsluiten? Of bij beveiliging: hoe belangrijk is het dat echt alleen de bedoelde personen toegang krijgen tot premieberekeningen. Je kunt de vraag hoe belangrijk iets is ook steeds omdraaien in een vraag hoe erg iets zou zijn. In het laatste geval; hoe erg is het als een ongeautoriseerd persoon (zoals een hacker) toegang krijgt tot alle premieberekeningen die ooit op onze website zijn gedaan?

Beste architect (mocht je er zijn), hoe …

Dit is de vertaalslag van de belangen van de klant naar een software oplossing.

Beste IT-er, hoe groot is de kans dat …

itfaalkansBijvoorbeeld de kans dat het afsluiten van een ongevallenverzekering niet werkt? Want misschien gaat het om een heel complexe berekening, of een lange ketting aan koppelingen met andere systemen, of een compleet nieuw stuk maatwerk.

 

Dit vereist wat oefening, maar met een creatieve brainstorm kom je al een heel eind. Want onbewust hebben de klant en de IT-er de informatie al bij zich. Er moet alleen even iemand expliciet om vragen. En al die overwegingen moeten ook expliciet worden opgeschreven.

Tijd voor een voorbeeld: onze online winkel

Voorbeelden bij ‘belang’ (en daarmee impact als het fout gaat):

Alle modules waar onze klant mee werkt, moeten goed functioneren en erg gebruiksvriendelijk zijn, want de klant eist hoge standaarden en kijkt al snel verder. Alle modules waar klant- en betalingsgegevens op te vragen zijn, moeten goed beveiligd zijn. Verder onderscheiden we ons door ons unieke logistieke concept, dus dat moet altijd perfect werken. En als de klant ons belt of mailt over zijn winkelwagen of over de voortgang van zijn bestelling, dan moet dat meteen beantwoord kunnen worden.

Voorbeelden bij ‘faalkans’

Bijna alle functionaliteit is standaard, maar de logistieke module is erg aangepast naar onze eigen wensen en bovendien gaat er érg veel data doorheen. Er zijn veel complexe koppelingen nodig om tot een bestelling te komen. Eisen aan gebruiksvriendelijkheid zijn nauwelijks beschreven.

En die overwegingen leiden tot een risicomatrix. Zie hieronder voor een voorbeeldje. Vooral op basis van de overwegingen hierboven, plus wat eigen inschattingen.

RisicomatrixDe risicomatrix

Door het vermenigvuldigen van belang met faalkans (met scores tussen de 1×1 en de 3×3) krijg je al snel de grote lijnen van het risico profiel. En zo’n risicomatrix is na een paar keer oefenen in 30 minuten ingevuld. Achter ieder plusje zit een afweging en voor grotere projecten schrijf ik alle afwegingen helemaal op. Dat is wat extra werk, maar maakt het voor al die belanghebbenden makkelijker om mee te denken. Voor kleinere projecten schrijf ik de achterliggende gedachte niet hier op, maar pas in de teststrategie. En die komt er nu aan.

> > Door naar de teststrategie

  1. Ronald schreef op maandag 24 juni 2013 om 15:46 1

    Interessant Sander. We gaan het toepassen en dan verder met de teststrategie.

Naam*: E-mail*: