Product risico analyse in de praktijk (2010) - Kees Blokland
Begroten van een ICT project
1. Begroten van een ICT project:
“Oude stijl”; geheel op maat te ontwikkelen nieuwe applicatie
“Nieuwe stijl”; aanpassen van/ voortbouwen op bestaande applicaties
Informatie analyse;
WAT moet er worden
gebouwd?:
- Procesbeschrijvingen
(uitgaande van de ideale
situatie)
- Meest voorkomende
uitzonderingen in de
praktijk
(stel :vaker dan 1%)
- Definitiestudies
(entiteiten met hun
attributen)
- Handleidingen
Systeemontwerp;
HOE moet het
worden
gebouwd?:
Instructies voor de
systeem
ontwikkelaars
Systeem
ontwikkeling
Testen:
- Systeemtests
- Functionele
Acceptatie
tests
- Gebruikers
Acceptatie
tests
- Productie
Acceptatie
tests
Oplevering;
invoer of
conversie
van
gegevens
Implementatie;
Nazorg;
Overdracht
aan beheer-
organisatie
Impact
analyse;
wat zijn de
aanvullende
wensen/
eisen?
Inschatten
hoeveel tijd en
geld de
aanpassingen
gaan kosten.
Functioneel
ontwerp; zie:
Informatie
analyse bij
“Oude stijl”.
Met name de
effecten van de
aanpassingen
op de
bestaande
applicaties
beschrijven.
Technisch
ontwerp:
Instructies
voor de
systeem
ontwikkelaars.
Systeem
ontwikkeling
Testen:
- Systeemtests
- Functionele
Acceptatie
tests
- Gebruikers
Acceptatie
tests
- Productie
Acceptatie
tests
Oplevering;
conversie
van
gegevens
Implementatie;
Nazorg;
Overdracht
aan beheer
organisatie
2. De vuistregel voor het begroten van een ICT project is: slechts ongeveer een derde van de tijd en het geld gaat zitten in het bouwen en testen van
een systeem. Het overige tweederde deel gaat zitten in de beschrijvingen van de processen, de definitiestudies, het schrijven van handleidingen
en dergelijke. Diezelfde verhoudingen mogen worden gehanteerd voor het implementatie- en nazorgtraject.
NOTA BENE:
Als er voor de ontwikkeling van een module 40 uur (1 werkweek) wordt geraamd, plan de ontwikkelaar dan in voor (minstens) 80 uur/ 2 weken!
Als gevolg van allerlei rationele en irrationele leegloop kan iemand namelijk gemiddeld slechts ongeveer 50% van zijn werktijd besteden aan één
project (bij één van mijn opdrachten kwam die netto beschikbaarheid in eerste instantie zelfs eerder in de buurt van 40% uit)!
Voor het testen van nieuw ontwikkelde programmatuur heeft een tester evenveel tijd nodig als één programmeur nodig had voor het
programmeren!
Een voorwaarde daarbij is bovendien, dat de testers vooraf het Systeemontwerp (“Oude stijl”) of Functioneel ontwerp (“Nieuwe stijl”) ontvangen.
De tester kan de testomgeving daar dan namelijk alvast op inrichten, zodat als allereerste wordt beoordeeld of de opgeleverde programmatuur
inderdaad conform de ontwerpen is!
Zodra bekend is wat ongeveer de doorlooptijd voor het ontwikkelen en testen van een systeem is, en wat de kosten daarvan zullen zijn, kunnen de
kosten voor het gehele traject worden geraamd, en kan de totale doorlooptijd worden geraamd.
Risico analyse:
Veel opdrachtgevers verkeren in de veronderstelling dat systemen “quick & dirty” kunnen worden ontwikkeld en geïmplementeerd, omdat laatste
plooien wel in het nazorgtraject zullen kunnen worden gladgestreken.
Stel echter:
- dat de analist een analyse oplevert die qua juistheid en volledigheid voor 90% betrouwbaar is; en
- de ontwerper op basis van die analyse een ontwerp oplevert dat eveneens voor 90% betrouwbaar is.
Dan moet de ontwikkelaar werken met een ontwerp dat ongeveer 90% x 90% = 80% betrouwbaar is! In de praktijk vullen ontwikkelaars de 20%
onjuistheid en onvolledigheid vaak in met eigen aannames.
Om die 20% onnauwkeurigheid er in het nazorgtraject weer uit te halen, kost ongeveer 80% van wat er vóór de oplevering is uitgegeven aan
informatie analyse, ontwerpen, ontwikkelen en testen! Het is daarom beter om 10 à 20% meer tijd te besteden aan zowel de informatie analyse als
het ontwerp, om de betrouwbaarheid daarvan op te tillen naar circa 98%!
Een rekenvoorbeeld:
Stel dat het ontwikkelen van een aanpassing wordt geraamd op 100 uur. Testen kost dan ook circa 100 uur => 100 + 100 = 200 uur = een derde.
Informatie analyse + ontwerp wordt aldus 2 x 200 = 400 uur. Als de betrouwbaarheid circa 90% is, kost het ongeveer 20% x 400 uur = 80 uur om
een niveau van 98% te bereiken. Wordt dat niet gedaan, dan is er in het nazorgtraject circa 80% x 600 uur = ca. 480 uur nodig voor herstel!
Een goede impact analyse kan ertoe leiden dat wordt besloten om het project niet uit te voeren vanwege de kosten <–> baten verhouding.
Er is dan ook veel voor te zeggen om impact analyses als “overhead” -en niet als nulde of eerste fase van een project- te beschouwen!