SlideShare a Scribd company logo
1 of 2
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
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!

More Related Content

Similar to Begroten van een ICT project

Datawarehouse testen van theorie naar praktijk
Datawarehouse testen van theorie naar praktijkDatawarehouse testen van theorie naar praktijk
Datawarehouse testen van theorie naar praktijkmkompagne
 
Workshop BI/DWH AGILE TESTING SNS Bank Dutch
Workshop BI/DWH AGILE TESTING SNS Bank DutchWorkshop BI/DWH AGILE TESTING SNS Bank Dutch
Workshop BI/DWH AGILE TESTING SNS Bank DutchMarcus Drost
 
Oogst gauc universal analytics learnings - juni 2015 - martijn staal kevin laan
Oogst  gauc universal analytics learnings - juni 2015 - martijn staal kevin laanOogst  gauc universal analytics learnings - juni 2015 - martijn staal kevin laan
Oogst gauc universal analytics learnings - juni 2015 - martijn staal kevin laanOogst
 
DevOps is geen scrum def
DevOps is geen scrum defDevOps is geen scrum def
DevOps is geen scrum defMyra Kievit
 
redactionele automatisering GEA consultancy
redactionele automatisering GEA consultancyredactionele automatisering GEA consultancy
redactionele automatisering GEA consultancyPatrick Swart
 
Agnl sessie aris test designerm - 8 nov v 1.0
Agnl sessie   aris test designerm - 8 nov v 1.0Agnl sessie   aris test designerm - 8 nov v 1.0
Agnl sessie aris test designerm - 8 nov v 1.0Niels Doeleman
 
Workshop BI/DWH AGILE TESTING Zwitserleven Dutch
Workshop BI/DWH AGILE TESTING Zwitserleven DutchWorkshop BI/DWH AGILE TESTING Zwitserleven Dutch
Workshop BI/DWH AGILE TESTING Zwitserleven DutchMarcus Drost
 
Productflyer - Plant Simulation
Productflyer - Plant SimulationProductflyer - Plant Simulation
Productflyer - Plant Simulationguestac59ac6
 
Fact Sheet Plant Simulation
Fact Sheet   Plant SimulationFact Sheet   Plant Simulation
Fact Sheet Plant Simulationmarkappelhof
 
Sdb Presentatie
Sdb PresentatieSdb Presentatie
Sdb Presentatiemenfey
 
Nederlandse Spoorwegen - Real time analytics
Nederlandse Spoorwegen - Real time analyticsNederlandse Spoorwegen - Real time analytics
Nederlandse Spoorwegen - Real time analyticsBigDataExpo
 
Automatiseren van IT activiteiten
Automatiseren van IT activiteitenAutomatiseren van IT activiteiten
Automatiseren van IT activiteitenRob Akershoek
 
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020Stork
 
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, Antwerpen
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, AntwerpenAVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, Antwerpen
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, AntwerpenTOPdesk
 
Product risico analyse in de praktijk (2010) - Kees Blokland
Product risico analyse in de praktijk (2010) - Kees BloklandProduct risico analyse in de praktijk (2010) - Kees Blokland
Product risico analyse in de praktijk (2010) - Kees BloklandKees Blokland
 

Similar to Begroten van een ICT project (20)

Datawarehouse testen van theorie naar praktijk
Datawarehouse testen van theorie naar praktijkDatawarehouse testen van theorie naar praktijk
Datawarehouse testen van theorie naar praktijk
 
Perfect Patch
Perfect PatchPerfect Patch
Perfect Patch
 
Content hot topics scia engineer
Content hot topics scia engineerContent hot topics scia engineer
Content hot topics scia engineer
 
Workshop BI/DWH AGILE TESTING SNS Bank Dutch
Workshop BI/DWH AGILE TESTING SNS Bank DutchWorkshop BI/DWH AGILE TESTING SNS Bank Dutch
Workshop BI/DWH AGILE TESTING SNS Bank Dutch
 
Rabobank 23 06 2010
Rabobank 23 06 2010Rabobank 23 06 2010
Rabobank 23 06 2010
 
Oogst gauc universal analytics learnings - juni 2015 - martijn staal kevin laan
Oogst  gauc universal analytics learnings - juni 2015 - martijn staal kevin laanOogst  gauc universal analytics learnings - juni 2015 - martijn staal kevin laan
Oogst gauc universal analytics learnings - juni 2015 - martijn staal kevin laan
 
DevOps is geen scrum def
DevOps is geen scrum defDevOps is geen scrum def
DevOps is geen scrum def
 
redactionele automatisering GEA consultancy
redactionele automatisering GEA consultancyredactionele automatisering GEA consultancy
redactionele automatisering GEA consultancy
 
Agnl sessie aris test designerm - 8 nov v 1.0
Agnl sessie   aris test designerm - 8 nov v 1.0Agnl sessie   aris test designerm - 8 nov v 1.0
Agnl sessie aris test designerm - 8 nov v 1.0
 
Workshop BI/DWH AGILE TESTING Zwitserleven Dutch
Workshop BI/DWH AGILE TESTING Zwitserleven DutchWorkshop BI/DWH AGILE TESTING Zwitserleven Dutch
Workshop BI/DWH AGILE TESTING Zwitserleven Dutch
 
Productflyer - Plant Simulation
Productflyer - Plant SimulationProductflyer - Plant Simulation
Productflyer - Plant Simulation
 
konings st cv1
konings st cv1konings st cv1
konings st cv1
 
Fact Sheet Plant Simulation
Fact Sheet   Plant SimulationFact Sheet   Plant Simulation
Fact Sheet Plant Simulation
 
Sdb Presentatie
Sdb PresentatieSdb Presentatie
Sdb Presentatie
 
Asfalt &toepassing
Asfalt &toepassingAsfalt &toepassing
Asfalt &toepassing
 
Nederlandse Spoorwegen - Real time analytics
Nederlandse Spoorwegen - Real time analyticsNederlandse Spoorwegen - Real time analytics
Nederlandse Spoorwegen - Real time analytics
 
Automatiseren van IT activiteiten
Automatiseren van IT activiteitenAutomatiseren van IT activiteiten
Automatiseren van IT activiteiten
 
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020
Webinar - EAM /Reliability & Integrity Software selectie - 15 juli 2020
 
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, Antwerpen
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, AntwerpenAVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, Antwerpen
AVEVE Service delivery van de toekomst, TOPdesk on Tour 2016, Antwerpen
 
Product risico analyse in de praktijk (2010) - Kees Blokland
Product risico analyse in de praktijk (2010) - Kees BloklandProduct risico analyse in de praktijk (2010) - Kees Blokland
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!