Bij methoden voor versnelde systeemontwikkeling zoals model-based application development voldoet de klassieke functiepuntanalyse niet meer. Om systeemomvang en benodigde capaciteit toch te kunnen inschatten zijn twee telmethoden inzetbaar. De één is gebaseerd op het informatiemodel; de ander op het meer gedetailleerde gegevensmodel. Beide tonen zich in de praktijk betrouwbaar, aldus consultant Kees Kranenburg.
Methoden voor versnelde systeemontwikkeling doen meer en meer hun intrede bij maatwerk-systeemontwikkeling. Zij treden in de plaats van het traditionele, lineaire ‘waterval’-projectscenario. Kenmerkend voor deze aanpakken is het iteratieve karakter van specificeren en de intensieve gebruikersparticipatie. Voorbeelden van dergelijke methoden zijn rapid application development (rad) [1], model-based application development (mad) [2] en evolutionaire systeemontwikkeling (evo) [3].
Voor het begroten van dergelijke projecten voldoet de traditionele functiepunten-telling als schattingsmethode niet. Functiepuntanalyse (fpa) is immers gebaseerd op gedetailleerde specificaties; bij versnelde systeemontwikkeling (rad, mad, evo) ontbreken deze. Toch wil men ook bij deze projecten al in een vroeg stadium van het ontwikkeltraject inzicht krijgen in de omvang van het systeem en een betrouwbare schatting kunnen maken van de benodigde capaciteit. Er moet dan dus worden geteld op basis van het informatiemodel of – later – op basis van het meer gedetailleerde gegevensmodel.
In de afgelopen jaren is een aantal projecten met rad en mad uitgevoerd, onder andere bij Philips en BSO/Origin. Uit deze projectervaringen zijn twee alternatieven voor fpa (telmethoden 1 en 2) ontstaan, die elk op een verschillend moment tijdens het project kunnen worden toegepast. Aan de hand van het ontwikkeltraject uit de mad-aanpak (figuur 1) worden deze alternatieven beschreven.
Mad
Bij mad wordt tijdens de analyse een procesmodel opgesteld van de activiteiten van een organisatie (bijvoorbeeld met structured analysis and design technique, sadt) en de informatiebehoefte van die organisatie (bijvoorbeeld met Nijssens informatie analyse methode, Niam, of het ‘entity-relationship’ model). Het procesmodel toont de bedrijfsactiviteiten en hun informatie-uitwisseling. Het informatiemodel beschrijft de gerelateerde informatiebehoefte in termen van entiteittypen en hun associaties, attribuuttypen en de geldende wetmatigheden (business rules of informatieregels).
Tijdens de specificatiefase wordt van het informatiemodel een relationeel gegevensmodel (tabellen, domeinen en kolommen) afgeleid. Dat model wordt aan een applicatiegenerator aangeboden, die hieruit een eerste systeemversie genereert. Dit systeem beschikt dan over alle onderhoudsfuncties op de tabellen, bewaakt de integriteitsregels die bij de tabellen zijn gedefinieerd en biedt de mogelijkheid tot complete navigatie tussen tabellen. Bij mad volgt hierna een proces van prototyping en verdere detaillering van de specificaties. Door het tonen en bespreken van de gegenereerde systeemversies worden de reeds bekende informatieregels gevalideerd en de nog onbekende gespecificeerd. Deze specificaties worden weer toegevoegd aan de generator, die daaruit een volgende systeemversie genereert.
Bij mad komt de gebruikersparticipatie tot uiting tijdens bedrijfsmodelleren (analysefase) en systeemmodelleren (specificatiefase). Deze twee stappen zijn vergelijkbaar met de jrp-workshops (joint requirements planning) en de jad-workshops (joint application design) uit rad.
Het iteratieve systeemontwikkelproces wordt bij mad ondersteund door repository-based applicatiegeneratoren. Deze tools genereren op basis van een relationeel gegevensmodel generieke functionaliteit, zoals de onderhouds- en navigatiefuncties. Overige systeemfunctionaliteit wordt gespecificeerd in de vorm van regels die aan het gegevensmodel worden toegevoegd.
Informatiemodel
Telmethode 1 (figuur 1) is een alternatieve fpa-telling die wordt uitgevoerd op basis van een informatiemodel. Dit model beschrijft de entiteittypen, enkele kenmerkende attribuuttypen en de relaties tussen de entiteittypen. Bovendien bevat het model de op dat moment bekende informatieregels. De beschrijving van de informatieregel hoeft nog niet compleet of gedetailleerd te zijn. Een algemene omschrijving volstaat, zonder precies te weten hoe de regel wordt uitgevoerd of berekend.
De telling gaat uit van een invoer-, uitvoer-, opvraag- en bestandsfunctie per entiteittype. Aan de hand van het aantal informatieregels en de complexiteit hiervan wordt per entiteittype en per functie een inschatting gemaakt van de classificering (eenvoudig, gemiddeld of complex). Vervolgens wordt deze classificering gekoppeld aan de bekende normering volgens fpa (laag, gemiddeld en hoog). Dit resulteert in een hoeveelheid functiepunten per entiteittype, variërend van 17 tot 34. Aanvullend worden de koppelingsfuncties geclassificeerd en genormeerd.
Deze telling kan al na de bedrijfsanalyse of na afloop van de jrp-workshops worden uitgevoerd zodra het informatiemodel stabiel is. De telling levert een bruto aantal functiepunten op. Deze worden met behulp van de omgevingsfactoren omgezet naar netto functiepunten. Vervolgens wordt hieraan een produktiviteitsratio gekoppeld, hetgeen een schatting van de benodigde capaciteit (in uren) oplevert.
Figuur 2 geeft een indruk van de betrouwbaarheid van telmethode 1. 
Gegevensmodel
Een andere telling (telmethode 2, figuur 1) wordt uitgevoerd aan de hand van het gegevensmodel en wordt toegepast na de specificatiefase of na afloop van de jad-workshops. Op dit moment is bij mad reeds een systeemversie beschikbaar met gegenereerde functionaliteit. Deze laatste is tijdens de specificatiefase tot stand gekomen door het gegevensmodel bekend te maken aan de applicatiegenerator. Bovendien is dit model tijdens een aantal jad-workshops door de gebruikersvertegenwoordigers gevalideerd en is de overige systeemfunctionaliteit gespecificeerd. Wat nu nog moet worden begroot is deze niet-generieke systeemfunctionaliteit, zoals regels, rapporten, gebruikersinterface-modificaties, interfaces met andere systemen en ‘batch-jobs’.
Bij mad wordt alle niet-generieke systeemfunctionaliteit gedefinieerd in de vorm van regels. Deze worden gespecificeerd in een natuurlijke taal (bijvoorbeeld Nederlands of Engels). De regels worden ingedeeld in een aantal klassen. Voor elke regel in een bepaalde klasse is de realisatietijd bekend. Figuur 3 geeft hiervan een voorbeeld.
| Klasse | Soort informatieregel en overige functionaliteit | Norm uren |
| 1 | Eenvoudige beperkingsregels | 0,5 |
| 2 | Waardebeperkingen | 1 |
| 3 | Afhankelijkheidsregels, eenvoudige berekeningen | 2 |
| 4 | Berekeningen | 4 |
| 5 | Transitieregels | 8 |
| 6 | Gebruikersinterface modificaties, autorisatie | 16 |
| 7 | Complexe rapporten, complexe berekeningen, ‘batch jobs’ | 32 |
Figuur 3. Niet-generieke systeemfunctionaliteit wordt gedefinieerd in de vorm van regels, die worden ingedeeld in klassen. Van regels, behorende tot een speciale klasse, is de realisatietijd bekend.
Daarnaast bestaat nog steeds de mogelijkheid om een expertschatting te geven voor één bepaalde regel. Zo zal het uitvoeren van een complexe berekening, bijvoorbeeld het berekenen van een pensioenpremie, niet in één van de bovenstaande klassen vallen. Het is mogelijk om voor een dergelijke regel apart een schatting te registreren. De totaal benodigde capaciteit (in uren) voor het realiseren van het systeem wordt nu verkregen door per klasse het aantal regels te vermenigvuldigen met de norm. Eventueel apart geschatte regels worden hierbij opgeteld. De norm voor realisatie (in uren) wordt steeds geactualiseerd aan de hand van de werkelijke gerealiseerde uren.
Kees Kranenburg is werkzaam als senior management consultant bij Origin Advies
Literatuur
1. Martin, James, Rapid application development, NY: MacMillan, 1991.
2. Kranenburg, Kees en Ad van Riel, Model-based application development – Modelleren en genereren van informatiesystemen, Deventer: Kluwer Bedrijfswetenschappen, 1995
3. Akkerman, Ton en Harry de Weerd, Evolutionaire systeemontwikkeling, Deventer: Kluwer Bedrijfswetenschappen, 1995.
