Functiepuntanalyse leeft

• -Waarom meten, we hebben het toch al zo druk? • -Het beslechten van de onophoudelijke discussie over het meten zelf: welke metrieken worden er gebruikt en hoe gaat men de metingen uitvoeren? • -De organisatie zelf: commitments ten aanzien van het meten worden wel toegezegd, maar niet waargemaakt. Iedereen vindt meten belangrijk, maar in de ICT doet bijna niemand het. In de praktijk blijkt dat er vaak een externe ‘trigger’ nodig is om de zaak aan de gang te krijgen. Wat we vaak zien is dat de ICT-ontwikkelingsprocessen worden gebenchmarkt door een extern gespecialiseerd bureau (zie kader). Dit bureau voert achteraf metingen uit en vergelijkt de organisaties met vergelijkbare organisaties in de markt. Als dan de mededeling volgt dat het bedrijf minder presteert dan ‘de markt’ zal het bedrijf óf willen aantonen dat deze conclusie niet klopt óf gericht gaan werken aan verbeteringen. In beide gevallen is een meetprogramma noodzakelijk. Obstakel Het meten zelf is een obstakel. Wanneer men kwantitatieve informatie wil verzamelen en analyseren dan moeten er eerst categorieën geoperationaliseerd worden. Hans Sassenburg onderscheidt in zijn artikel ‘Kwaliteitsdenken ziet succesfactoren over het hoofd’ (Automatisering Gids, 9 januari 2004) drie categorieën kwantitatieve informatie. De eerste categorie ‘Schattingsvaardigheid’ gaat in op het verschil tussen de initiële planning en het uiteindelijke resultaat. Van belang hierbij zijn de dimensies functionaliteit, kwaliteit en budget. Deze zijn in combinatie met de dimensie doorlooptijd onlosmakelijk met elkaar verbonden. Men kan immers prima binnen het geplande budget en volgens de gestelde kwaliteit opleveren, maar wanneer er dan maar driekwart van de vooraf vastgestelde functionaliteit wordt opgeleverd, is de uitvoering nog steeds niet volgens plan. Zo zijn de dimensies onderling inwisselbaar. Om de schattingsvaardigheid vast te kunnen stellen en de oorzaak van verschillen te analyseren moeten minimaal gemeten worden: de kwaliteit, het budget, de doorlooptijd en de functionaliteit. In de praktijk blijkt dat dit makkelijker gezegd is dan gedaan. Toch hoeft het niet echt ingewikkeld te zijn: een paar metrieken zoals de omvang van het systeem of het project (zie kader), gevonden fouten, doorlooptijd en budget/bestede tijd. Zie hier de basisingrediënten voor een meetprogramma. Het invoeren van een meetprogramma wordt vaak onderschat. Enerzijds door de tijd die nodig is om eigen ervaringscijfers op te bouwen, anderzijds doordat de impact op de werkwijze groter is dan gedacht. In de praktijk komt men vaak het idee tegen dat met een cursus functiepunten het meetprogramma is ingevoerd. Het meten heeft dan echter nog geen plaats binnen de werkwijze gekregen en zal op een paar uitzonderingen na een zachte dood sterven. Het verzamelen van zelfs enkele basale kwantitatieve gegevens over een project is in de praktijk moeilijk van de grond te krijgen. Maar net zoals het normaal is dat er een projectplan bij ieder project wordt gemaakt, moet ook ieder project na afronding geëvalueerd worden. Een onderdeel hiervan moet het vastleggen van kwantitatieve gegevens zijn. Dit hoeft niet veel tijd te kosten; het zijn gegevens die iedere goede projectleider aan het einde van het project beschikbaar heeft. ‘Keep it simple’, vooral in het begin, beperk je tot basale gegevens zoals omvang project, uren, doorlooptijd en kosten. Bij dit soort invoeringstrajecten is het commitment van het management essentieel. Dit moet blijken uit concrete acties, zoals het vrijmaken van budget en aandacht voor het meetprogramma van het managementteam. Zo kan het management verplicht stellen dat bij de start van het project (bijvoorbeeld bij de budgetaanvraag) ook de omvang van het systeem of de grootte van de aanpassing op een systeem wordt aangegeven. Profijt Niet alleen de ICT-bedrijven zelf hebben profijt van het verzamelen van kwantitatieve gegevens, ook bij het aanbesteden van projecten wordt steeds meer door opdrachtgevers een vergelijking op meer dan alleen de prijs gemaakt. De omvang (bijvoorbeeld het aantal functiepunten) van het te realiseren systeem is een belangrijke indicator bij aanbestedingstrajecten. Het komt regelmatig voor dat aanbieders de ‘user requirements’ voor een systeem anders interpreteren dan de opdrachtgevers. Als het systeem in werkelijkheid zesduizend functiepunten groot is, maar de ‘goedkope’ aanbieder zijn offerte op drieduizend functiepunten baseert, dan komt de opdrachtgever vroeg of laat van een koude kermis thuis. Dit risico is te vermijden als de aanbesteder in de RFP (request for proposal) verzoekt om bij de uit te brengen offerte een functiepuntanalyse mee te leveren. Pas dan wordt duidelijk welk beeld de ontwikkelaar heeft van het systeem. Van belang hierbij is de telling te laten uitvoeren door een door Exin gecertificeerde FPA-specialist (CFPA). Een tweede wezenlijk kengetal bij het vergelijken van offertes is de productiviteit (bijvoorbeeld het aantal uren per functiepunt) die een aanbieder denkt te kunnen realiseren. En als derde het tarief per uur. Op deze wijze zijn in een offerte drie aparte indicatoren (omvang, productiviteit, tarief) te vinden, waardoor veel concreter over een offerte kan worden onderhandeld. Een transparante calculatie biedt zowel voor de opdrachtgever als opdrachtnemer de mogelijkheid om met open vizier tot een voor beiden acceptabele deal te komen. Verplicht Een veel gebruikte maat voor het uitdrukken van de omvang van een informatiesysteem of project zijn functiepunten. Functiepuntanalyse (zie kader) heeft zich de laatste jaren wereldwijd sterk uitgebreid, mede door de ISO-certificering in 2003. Zo zijn functiepunten sinds 2003 verplicht bij overheidscontracten in Zuid-Korea en Brazilië. Op deze wijze willen deze overheden meer greep krijgen op de ontwikkelingsprocessen en de ‘deliverables’. Men wil zich niet langer als een speelbal overgeleverd voelen aan softwarehuizen. Ook wat dit betreft is de tijd van vrijheid-blijheid voor softwareproducenten voorbij. Kenmerkend voor functiepuntanalyse is dat het een meeteenheid is die los staat van de technologische omgeving. Een meeteenheid die zowel door opdrachtgevers en gebruikers als door projectleiders en ontwikkelaars te begrijpen en te hanteren is. Functiepuntanalyse gaat namelijk uit van het abstractieniveau en de taal van de gebruiker. Het systeem wordt onderverdeeld in functies als: ‘Aanmaken rekening’, ‘Verwerken betaling’, ‘Opvoeren klant’ et cetera. Hier is geen woord jargon bij. Dit alles maakt het mogelijk de voortgang van projecten te monitoren en voor opdrachtgevers om te bepalen of ze inderdaad wel ‘value for money’ krijgen en of alle geoffreerde functionaliteit daadwerkelijk wordt opgeleverd. Partijen willen, vooral bij contractmanagement, zo vroeg mogelijk in het traject een indicatie hebben van de omvang van een te ontwikkelen systeem. Veel internationaal onderzoek richt zich op betrouwbaarheidsanalyses van methoden die op basis van globale user requirements de omvang van het systeem zo goed mogelijk benaderen. Baanbrekend werk op dit gebied heeft de Nesma (Nederlandse Software Metrieken Associatie) verricht met haar methoden ‘de globale functiepuntentelling’ en ‘de indicatieve functiepuntentelling’. In de internationale literatuur staat de indicatieve methode zelfs bekend als ‘the Dutch method’, waarin het woordje Dutch nu eens niet een pejoratieve betekenis heeft. In de hele wereld worden deze methoden voor ‘early function point counting’ met succes toegepast. Zo gaf een vooraanstaand Amerikaans bedrijf tijdens een internationaal congres onlangs aan dat het deze methode gebruikt als men bij een klant binnen redelijke marges de omvang van ‘de installed base’ moet bepalen, bijvoorbeeld wanneer er gedacht wordt over het outsourcen van ICT-activiteiten. Kader 1: Sterker dan ooit ‘Functiepuntanalyse. Bestaat dat nog?’ is een uitspraak die we vaak horen. Bijna iedereen in het vakgebied heeft van FPA gehoord. Velen associëren het met een hype van eind jaren tachtig, die nauw verbonden was met de toenmalige ontwikkelingsomgevingen. "Maar nu is de wereld anders: ‘object oriented’, ‘component based development’, ‘rapid application development’, web-applicaties", wordt er dan bijgezegd, "daarvoor is FPA niet bruikbaar." Dat de wereld anders is, valt niet te ontkennen. Maar FPA heeft de tand des tijds doorstaan. Sterker nog, de positie van softwaremetrieken en van FPA in het bijzonder, is anno 2004 krachtiger dan ooit tevoren. Sinds 1986 heeft FPA zich langzaam maar zeker over de wereld verspreid. De methode is in 1979 in de Verenigde Staten bij IBM ontwikkeld. In 1986 is in de USA de gebruikersvereniging Ifpug (International Function Point Users Group) opgericht. In 1989 volgden Nederland (Nesma), Groot-Brittannië (Uksma) en Australië (Asma). Deze landen hebben intensief samengewerkt om wereldwijd aandacht voor FPA en softwaremetrieken te verkrijgen. In 1998 is de eerste belangrijke internationale mijlpaal geslagen: de ISO publiceerde de generieke eisen waaraan een Functional Size Measurement method (FSM) moet voldoen. Na de nodige aanpassingen en moderniseringen is de FPA-methode in 2003 door de ISO erkend als internationale FSM-standaard voor de omvangbepaling van ‘user requirements’. In Nederland is het handboek ‘Definities en telrichtlijnen FPA versie 2.2’ door ISO gecertificeerd. Dit proces van het verkrijgen van de ISO-erkenning heeft een verrassend neveneffect. De managementaandacht voor FPA groeit wereldwijd plotseling sterk. Op steeds meer internationale congressen over SPI (Software Process Improvement), Quality Management en Project Control en CMM wordt FPA ten tonele gevoerd als methode om meer voorspelbaar uitspraken te doen over systeemontwikkelingsprocessen, en om meetbare doelstellingen te kunnen afspreken tussen opdrachtgevers en -nemers. Ook het outsourcen van het tellen van functiepunten is een nieuw fenomeen. Organisaties die zelf onvoldoende kennis of capaciteit hebben voor de omvangsbepaling in functiepunten laten dit door onafhankelijke specialisten uitvoeren tegen een vaste prijs per functiepunt en tegen een vastgestelde doorlooptijd. Een nieuwe methode voor ‘functional size measurement’ is CFFP (Cosmic Full Function Points). Deze methode drukt de omvang van systemen uit in CSU (cosmic size units). De methode is vooral ontworpen met het oog op de typische karakteristieken van real-timetoepassingen. De methode CFFP is bewerkelijker dan FPA, zeker voor administratieve toepassingen. Ook deze methode is in 2003 door de ISO gecertificeerd. FPA is niet lastig te gebruiken bij moderne ontwikkelingsmethoden zoals objectoriëntatie, CBD, RAD en DSDM. Zij bestaat onafhankelijk van de ontwikkelingsmethode en -omgeving. FPA meet de omvang van de functional user requirements. De modellen die in een methode worden gemaakt (zoals ERD’s, use cases, object diagrams) zijn slechts afbeeldingswijzen van de user requirements. Ze staan daarom los van de toepasbaarheid van meetmethoden als FPA en CFFP. Kader 2: Benchmarking Een ICT-bedrijf of -afdeling kan zich laten vergelijken met soortgelijke bedrijven. Commerciële adviesbureaus hebben hiervoor diensten ontwikkeld. Op basis van onder andere functiepunten worden vergelijkingen uitgevoerd. Ook zijn er tools op de markt beschikbaar waarin projectgegevens verzameld zijn en waaraan men de eigen projecten en organisatie kan spiegelen. Er bestaat een non-profit-initiatief (Isbsg: International Software Benchmarking Standards Group) van softwaremetriekenorganisaties over de hele wereld. Het doel van dit initiatief is het verschaffen van softwarebenchmarkgegevens die gestandaardiseerd, geverifieerd, actueel en representatief voor de huidige technologie zijn. In de Isbsg werken vooraanstaande landelijke koepelorganisaties op het gebied van software metrics en benchmarking uit diverse landen samen om productiviteitscijfers te verzamelen en te analyseren. Analyseren houdt in: het relateren van de omvang van een project (uitgedrukt in functiepunten) aan de benodigde inspanning, en het vinden van trends in bepaalde omgevingen of soorten projecten. De Isbsg heeft een ervaringsdatabase samengesteld met ruim tweeduizend projecten. Organisaties kunnen zelf projectgegevens insturen door de vragenlijst in te vullen. Deze vragenlijst is ook te gebruiken om te kijken wat verzameld moet worden om zelf een goede metriekendatabase op te bouwen. Wanneer een bedrijf projectgegevens aanlevert ontvangt het kosteloos een analyse terug met de plaats waar het project qua productiviteit staat ten opzichte van deze database. Deze gegevens worden anoniem voor researchdoeleinden aan universiteiten ter beschikking gesteld. Jaarlijks brengt de Isbsg een rapport uit waarin de kwantitatieve en kwalitatieve kenmerken van softwareprojecten worden vergeleken. De afgelopen tijd is er een sterke groei te zien in het aantal aangeleverde projecten. Drs. Jolijn Onvlee (Jolijn_Onvlee@fpa-ec.nl) is zelfstandig adviseur bij Onvlee Opleidingen & Advies en bij het FPA Expertisecentrum. Drs. Adri W.F. Timp is senior quality-consultant bij Interpay Nederland B.V. (a.timp@interpay.nl). Beiden zijn bestuurslid van de Nesma en lid van de werkgroep FPA-telrichtlijnen.Informatieve websites: www.exin.nl; www.nesma.nl; www.isbsg.org; www.functiepuntanalyse.nl; www.cosmicon.com