Het gehele begrotingsproces omvat aanzienlijk méér dan het uitvoeren van een omvangstelling. Bij een methodische begroting is het bepalen van de (functionele) omvang wel een belangrijke eerste stap. Het vaststellen van de functionele omvang kan o.a. door het toepassen van een (liefst ISO gecertificeerde) Functional Size Measurement methode zoals FPA en COSMIC.
Deze pagina laat de rol van COSMIC zien binnen het begrotingsproces.
Om COSMIC te kunnen gebruiken bij het maken van een begroting dient een organisatie (productiviteits)normen te kennen. Onder norm wordt verstaan: hoeveel ontwikkeluren zijn gemiddeld nodig om één functiepunt te realiseren. Bepalend voor deze normcijfers zijn ervaringen met de behaalde productiviteit in het verleden.
Om op basis van het aantal functiepunten een project te begroten, wordt niet zonder meer de algemene productiviteitsnorm van de betreffende ontwikkelomgeving gehanteerd. Eerst wordt bekeken of er voor het project specifieke productiviteitsbeïnvloedende omstandigheden zijn. Deze analyse kan leiden tot bijstellen van de norm: de projectnorm.
Omvang (aantal CFP) x projectnorm (benodigde uren per CFP) levert een basis voor de projectbegroting. Hieraan dienen de uren voor niet in de norm begrepen activiteiten te worden toegevoegd.
Het gehele begrotingsproces omvat dus aanzienlijk méér dan het uitvoeren van een omvangsmeting. COSMIC is één van de door ISO gecertificeerde methoden voor het meten van de functionele omvang. In dit proces kan men vier stappen onderkennen. Deze stappen worden op deze pagina uitgelegd.
De benodigde uren voor het maken van een systeem zijn gerelateerd aan
zijn omvang. Hoe groter het systeem, des te duurder het zal zijn.
COSMIC functiepunten zijn een goede maat voor de functionele omvang van een
systeem. De systeemomvang wordt uitgedrukt in een aantal COSMIC functiepunten
(CFP).
Hoe COSMIC de omvang van een systeem vaststelt staat beschreven op de pagina
"Hoe werkt COSMIC" van dit cluster.
Bij het bepalen van de (functionele) omvang van het systeem is de ontwikkelomgeving van het systeem buiten beschouwing gebleven. Het is duidelijk, dat de ontwikkelomgeving (software en hardware) een grote rol speelt in het aantal ontwikkeluren, vooral in de fase Realisatie.
Het kan veel uitmaken, of een systeem wordt gebouwd in een 3-GL taal
zoals COBOL, of in een 4-GL tool.
Ditzelfde geldt voor de diverse hardwarelijnen en architecturen, zoals
mainframe, PC, client server.
Het is noodzakelijk om voor elke ontwikkelomgeving een
(productiviteits)norm te hebben: aantal benodigde ontwikkeluren per
CFP.
Voor elke projectfase kunnen deze productiviteitsnormen worden aangelegd. Voor de fase realisatie zijn ze het meest bruikbaar.
Productiviteitsnormen legt een bedrijf aan op basis van ervaringen uit eerdere, vergelijkbare projecten. Deze normen zijn een indicator voor de te behalen productiviteit. Ervaringen uit nieuwe projecten kunnen aanleiding zijn productiviteitsnormen bij te stellen.
Om een norm zinvol in toekomstige situaties te kunnen gebruiken moet worden vastgelegd, welke activiteiten in de norm zijn meegenomen (bijv. wel programmatesten, maar niet projectleiding). Activiteiten die niet onder de norm vallen, dienen in stap 4 apart te worden begroot.
Als een organisatie (nog) niet beschikt over ervaringscijfers in een bepaalde ontwikkelomgeving, kan eventueel gebruik worden gemaakt van de Benchmarkcijfers van de ISBSG database. Deze ‘open’ database bevat productiviteitscijfers van duizenden projecten. De ISBSG database is via de NESMA te bestellen. Zie de sectie Boeken.
Aan de hand van een checklist met zogenoemde "productiviteitsattributen" dient men na te gaan of er voor dit project specifieke omstandigheden gelden die productiviteit in positieve of negatieve zin beïnvloeden (bijv. onervaren/zeer ervaren personeel, nieuw hulpmiddel, etc.).
Hiervan dient de invloed te worden geschat en te worden vertaald naar de te hanteren projectnorm (uren/CFP) voor het betreffende project. Deze kan dus afwijken van de algemene norm voor de betreffende ontwikkelomgeving.
De stap van functiepunten naar initiële projecturen is simpel: het aantal functiepunten vermenigvuldigen met de projectnorm (uren/CFP).
Bij elk productiviteitsnorm (uren/CFP) dient een organisatie te hebben vastgelegd welke activiteiten in de norm zijn meegenomen, en welke niet. Deze laatste zullen doorgaans activiteiten zijn die niet gecorreleerd zijn aan de omvang van een project of activiteiten die soms wel en soms niet spelen.
Zo kan het voorkomen, dat bij systeemontwikkeling soms wel en soms niet uitgebreid overleg met externe partijen nodig is. Een bedrijf kan dan besluiten dat dit aspect niet wordt meegenomen in de norm.
Voor dit soort activiteiten die buiten de norm gehouden worden, dient vervolgens het aantal benodigde uren te worden geschat en te worden toegevoegd aan de hierboven bepaalde initiële projecturen.
Het is altijd aan te bevelen ook op een andere manier (bijv. op basis van historische gegevens en ervaringen van specialisten) een schatting te maken van de orde van grootte van het aantal projecturen.
Confrontatie van beide schattingen kan leiden tot een nadere analyse en dus tot een betere schatting.
Uit de projecturen, tarieven en andere uitgaven wordt tenslotte de begroting samengesteld.