De vaste prijs per functiepunt is in opmars. Logisch, want in crisistijd zoeken mensen graag hun toevlucht in eenvoud. Nuanceren is dan niet populair. Toch is het wel verstandig om de beperkingen van eendimensionale grootheden te blijven kennen.
In tijden van crisis en onzekerheid hebben we als mens de neiging ons vertrouwen te stellen in eenvoud. Eendimensionale grootheden waar je alles aan kan afmeten komen dan in zwang. In de maatschappij zie je bijvoorbeeld dat 'de Nederlandse identiteit' voor veel mensen zo'n lekker simpele, eenduidige maatstaf aan het worden is. Wie dan plotseling roept dat 'de Nederlandse identiteit' niet bestaat, roept daarmee behoorlijk wat weerstand op, zoals prinses Máxima kan navertellen. Toch is het belangrijk om af en toe stil te staan bij de beperkingen van dit soort eendimensionale versimpelingen. Vaak is de werkelijkheid namelijk 'veel te veelzijdig om in één cliché te vatten', in de woorden van Máxima.
In de ict heb je 'de functiepunt' die wordt gezien als redding in tijden van onzekerheid. Een heerlijke eendimensionale maatstaf. Het wordt steeds populairder om softwarehuizen af te rekenen op een vaste prijs per functiepunt. Functiepunten zijn immers objectief meetbaar. Als je de hoeveelheid tijd die het heeft gekost om het systeem te bouwen deelt door de omvang in functiepunten, weet je de tijd per functiepunt. Daaruit kun je een prijs per functiepunt berekenen, die je voor toekomstige systemen kunt afspreken met je klant of leverancier. Een kind kan de was doen.
Op het gevaar af hetzelfde lot als Máxima te ondergaan, poneer ik echter de stelling 'de functiepunt bestaat niet'. Net als Limburgers en Amsterdammers gedragen functiepunten van verschillende soorten systemen zich namelijk heel verschillend. De verhouding tussen functiepunt en realisatiekosten is in een traditioneel transactiesysteem nog redelijk stabiel, maar in complexere architecturen is het verband vaak ver te zoeken. Dat is omdat functiepunten bepaalde aspecten van het systeem niet meten. Moderne ict-systemen zitten vol interne functionaliteit die bij functiepunten buiten de boot valt. De verhouding tussen gemeten en niet-gemeten aspecten verschilt nogal per architectuur. Andere bekende factoren die veel invloed hebben op de kosten per functiepunt zijn doorlooptijd en kwaliteit. Een vaste prijs per functiepunt moet dan ook altijd gezien worden binnen de context van een vaste architectuur, omgeving en tijdsdruk.
'De functiepunt' kan vergeleken worden met 'de kilo fruit'. Die kun je ook niet kopen. Je kunt wel een kilo appels of mango's kopen, maar als je naar de groenteboer gaat en een vaste prijs per kilo fruit wilt afspreken, zal hij toch graag willen weten welk soort fruit je nodig hebt. Stel je de reactie voor van de groenteboer die gevraagd wordt een prijs per kilo fruit af te geven, waarbij de klant zich het recht voorbehoudt om op ieder moment in plaats van peren toch kiwi's af te nemen, tegen diezelfde prijs. Toch komen vergelijkbare vragen steeds vaker voor in de softwarewereld.
De beperkingen van functiepunten zijn goed bekend bij technisch onderlegde professionals. Functiepunten zijn echter juist populair bij beleidsmakers. En daar komt dan soms ook de vraag tevoorschijn om een vaste prijs per functiepunt, met het recht om de architectuur te wijzigen, of een context waar de functiepunt nauwelijks verband houdt met de productiekosten. Professionals reageren dan op dezelfde manier als de groenteboer hierboven, tot ergernis van de beleidsmakers. De ergernis die wij meemaken in dit soort situaties is soms onverwacht groot en emotioneel geladen. Het nuanceren of bekritiseren van een eendimensionale maatstaf in onzekere tijden wekt blijkbaar veel emoties op. Zie Máxima en 'de Nederlandse identiteit'.
Stabiele ontwikkelstraten kunnen systemen met een vaste architectuur uitstekend aan de lopende band produceren tegen een vaste prijs per functiepunt. 'Keep it simple, stupid' (KISS) is een veelgehoorde kreet in de ict. Het kan echter ook te simpel worden. Laten we dat vooral bij beleid rond functiepunten in gedachten houden. Want 'de functiepunt' bestaat niet.
Gelukkig kan ik tikfouten maken en spreken van fictiepunten … functiepunten zijn enkel fictie en dus enkel goed om verhalen te schrijven voor management maar niet in het dagelijks IT leven
Helemaal mee eens!
Het verschil zit hem nog al eens in de details en de ondersteuning die de klantopdrachtgever zelf geeft. Deze omgevingsvariabelen zijn op eens niet zo strak meer uit te drukken en zijn elke keer anders. Wat is het startpunt en niet alle startpunten zijn bij elk project gelijk. Dus we zijn soms bezig om appels en peren te vergelijken.
Op zijn best geeft Functiepunten een indicatie, waarna naar de verschillen gekeken kan worden
He he, dankjewel Eltjo! Eindelijk eens iemand die dit hardop durft te zeggen. Zelf maak ik op dit moment weer een nieuwe hype mee: de Use Case Point analyse. Dit is een verdere versimpeling van de Functiepuntanalyse waarbij alleen nog maar naar use cases wordt gekeken. Is inderdaad erg gemakkelijk toe te passen en zeer geliefd bij (project)managers, maar alleen geschikt voor projecten waar je schatting er minimaal een factor 2 tot 3 naast mag zitten.
In tijden van crisis en onzekerheid verliezen ook architecten blijkbaar af en toe hun scherpte. Dit stuk is daar een goed voorbeeld van. De schrijver stelt dat functiepunten bepaalde aspecten van het systeem niet meten. Welke aspecten dat zijn wordt vervolgens nergens meer vermeld, maar wel dat dit per architectuur nogal verschilt. Vroeger werkten functiepunten blijkbaar wel want hij stelt ook: ?Moderne ict-systemen zitten vol interne functionaliteit die bij functiepunten buiten de boot valt? .
Dit is natuurlijk een onhoudbare stelling en na verdere lezing van het stuk blijkt het probleem van de schrijver ook niet zozeer te zitten bij de functiepunt maar meer bij de ?overigens terechte – vraag vanuit de markt om een vaste prijs per functiepunt.
Natuurlijk heeft de schrijver gelijk dat een prijs per functiepunt alleen kan worden afgegeven binnen een bepaalde omgeving, want deze omgeving bepaalt weer de productiviteit van een ontwikkelaar en dus de prijs. Maar daardoor is de functiepunt natuurlijk niet minder bruikbaar.
Er komen nogal wat vragen naar boven als ik het stukje lees en met name de hierbovenstaande reacties. Worden jullie soms gedwongen om FPA te gebruiken? Hebben jullie soms jullie ervaringscijfers niet voor elkaar? Of nog erger, waarvoor dient al die architectuur, als het niet bijdraagt aan de gevraagde gebruikers functionaliteit.
Ik denk dat er een fundamentele fout wordt gemaakt bij het toepassen van de resultaten van functie punt analyse. FPA is verre van 1 dimensionaal: je houdt rekening met de benodigde gegevensstructuren, met de door de business benodigde functionaliteit en daaroverheen nog een aantal beinvloedingsfactoren. Ik vind dit een prima methode om objectief de omvang van een project en/of een systeem vast te stellen. Dat is wat functiepunt analyse is. Als je je dan vervolgens met elkaar houdt aan dezelfde afspraken hoe je FPA toepast om functiepunten te tellen (NESMA) dan bestaat DE functiepunt wel!
Kijk als je dan vervolgens de verkregen functiepunten gaat vermenigvuldigen met een 1 dimensionale prijs, tja dan zul je gemiddeld misschien goed uitkomen (maar per definitie dus de helft van je projecten te duur en de andere helft te goedkoop). Dat moet je dus niet doen.
Je zult daar een ervaringsprijs aan moeten koppelen. Hoeveel dimensies die ervaringsprijs moet hebben? Dat is aan u en hangt af van hoeveel verschillende soorten projecten u uitvoert.
Wij gebruiken al jaren de NESMA Functiepunt analyse. Samen met ervaringscijfers van vele diuzende projecten (QSM SLIM Estimate) begroten wij al onze projecten die stuk voor stuk op tijd opgeleverd worden.
M.i. kan de groenteboer in het voorbeeld een stuk beter uit de voeten met de afspraak over een prijs die iets heeft met een meerdimensionale prijs als: seizoensfruit ja/nee, lokaal/ingevlogen fruit, luxe/gewoon fruit. Dat vraagt om een aantal definities, maar is uitstekend mee te werken!
DE functiepunt bestaat dus wel, maar DE functiepuntprijs bestaat niet.
Heb weinig toe te voegen aan de uitstekende reactie van Alexander Vermeulen. Zelf gebruik ik NESMA FPA en Use Case Points (UCP) al jaren om de doorlooptijd en/of kosten van grotere wijzigingen en projecten in te schatten. Het aantal functiepunten is een vast gegeven en verschillende partijen of personen behoren op hetzelfde aantal punten uit te komen als de telling goed uitgevoerd wordt en ik ben het met Alexander eens dat de functiepunt bestaat, net als UCP! Als de teller goed op de hoogte is van de beoogde architectuur, de kwaliteiten en ervaring van de personen die het project gaan uitvoeren (wat vaak niet het geval is of een zorg voor ?later?), het ontwikkelplatform etc, dan is het eenvoudig om de kosten in te schatten mits de klant weet wat die wil. Dit laatste is zeker bij de overheid nog al eens een probleem en aan een project moet minimaal een gedegen Business Case ten grondslag liggen. De functiepuntprijs is re�el binnen de context waarbinnen de FP/UCP gerealiseerd worden. Mijn advies aan de opdrachtgevers is dan ook: zorg voor een Business Case, sluit partijen uit die geen FPA/UCP telling kunnen uitvoeren of met belachelijke resultaten aankomen en laat elke partij toelichten waarom men een bepaalde prijs per FP/UCP hanteert. Net als bij een aannemer in de bouw zal dan blijken dat de prijs bepaald wordt door de bouwmaterialen, de ervaring van het personeel, of het een spoedklus is etc. De klant wil zeker in deze tijd voor een dubbeltje op de eerste rij zitten, maar schiet zichzelf in de voet als hij of zij niet open is over de kwaliteitsnormen en (niet) functionele eisen waaraan een systeem moet voldoen. Zeker een architectuur moet zorgvuldig gekozen en later bewaakt worden want aanpassingen op dat niveau in een later stadium zijn vaak kostbaar en dus niet goed voor de Business Case.
FPA is een uitstekende manier om op een gestandardiseerde manier iets te zeggen over de omvang van een applicatie waarbij er gelet wordt op gegevensverzamelingen en de functies die een gebruiker hier op uitvoerd. Er is echter toch nog wel wat interpretatie ruimte waardoor er door gecertificeerde analisten op een verschillende resultaat uitgekomen kan worden. Dus een kleine marge voor afwijkingen ten op zichte van elkaar.
Waar inderdaad een halt toe moet worden geroepen is het ééndimensionaal maken van de productiviteit. Dit suggereert dat een project van 10 Functiepunten de zelfde dynamiek heeft als een project van 1000 Functiepunten. Metafoor met bouw wereld: een tuinhuis van 10 m2 neerzetten gaat 20 keer zo snel als een huis van 200 m2. Een tuinhuis duurt 2 keer 8 uur per dag. dus een huis 40 keer 8 uur per dag. Dit is letterlijk hoe sommige mensen de boel plat proberen te slaan.
Er zijn gerenomeerde instellingen die klanten ondersteunen bij aanbestedingen en deze ééndimensionale paradigma proberen te tackelen. Dit is een stap in de goede richting. Met name bij openbare aanbestedingen zou het verstandiger zijn om het verhaal over productiviteit te nuanceren en vanuit de leverancier toe te lichten en transparant te maken.
Eltjo zegt volgens mij niet dat functiepunt analyse niet zinvol is. Wat hij wel zegt is dat dè functiepunt niet bestaat. De functiepunt is geen onveranderlijke grootheid die altijd dezelfde waarde heeft en waar je dus in elke omgeving zomaar mee kunt gaan rekenen.
Linerair rekenen en vergelijken is zinvol als je het steeds over dezelfde grootheden hebt.
Binnen één ontwikkelstraat, waar een bepaald type applicaties op een bekende wijze herhaald wordt ontwikkeld kan planning en begroting op basis van FPA heel goed werken. Daar zal na verloop van tijd de schatting ook steeds nauwkeuriger worden.
Zoals een aantal commentatoren al aangeeft is eendimensionaal rekenen met functiepunten een weinig zinvolle bezigheid. Aanbestedingen op basis van een vaste prijs per functiepunt zijn in mijn beleving dan ook weinig zinvol. Vorige week heb ik een artikel geplaatst over hoe het wel zou kunnen.
https://www.computable.nl/artikel/ict_topics/beleid/3336794/2379250/goed-aanbesteden-op-basis-van-functiepunten.html