Het gehele begrotingsproces omvat aanzienlijk méér dan het uitvoeren van een functiepuntentelling. FPA is slechts ondersteunend in dit proces.
Deze pagina laat de rol van FPA zien binnen het begrotingsproces. Op de pagina Voorbeeld begroten met FPA wordt dit aan de hand van een voorbeeld geïllustreerd. Het NESMA handboek Begroten met behulp van FPA geeft uitgebreide richtlijnen voor het begroten op basis van FPA..
Om FPA 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 functiepunten) x projectnorm (benodigde uren per functiepunt) 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 functiepuntentelling. FPA is slechts ondersteunend in dit proces. 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.
Functiepunten zijn een goede maat voor de functionele omvang van een
systeem. De systeemomvang wordt uitgedrukt in een aantal functiepunten.
Hoe FPA de omvang van een systeem vaststelt staat beschreven op de pagina
"Hoe werkt FPA" van dit cluster.
Bij het bepalen van de (functionele) omvang van het systeem is de ontwikkel-omgeving van het systeem buiten beschouwing gebleven. Het is duidelijk, dat de ontwikkel-omgeving (software en hardware) een grote rol speelt in het aantal ontwikkel-uren, 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 hardware-lijnen en architecturen, zoals
mainframe, PC, client server.
Het is noodzakelijk om voor elke ontwikkel-omgeving een
(productiviteits)norm te hebben: aantal benodigde ontwikkel-uren per
functiepunt.
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.
Aan de hand van een checklist met zogenoemde "productiviteits-attributen" 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/functiepunt voor het betreffende project). Deze kan dus afwijken van de algemene norm voor de betreffende ontwikkelomgeving.
De stap van functiepunten naar initiële project-uren is simpel: het aantal functiepunten vermenigvuldigen met de projectnorm (uren/fp).
Bij elk productiviteitsnorm (uren/fp) 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 wordt 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 project-uren.
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 project-uren.
Confrontatie van beide schattingen kan leiden tot een nadere analyse en dus tot een betere schatting.
Uit de project-uren, tarieven en andere uitgaven wordt tenslotte de begroting samengesteld.