Development

Software-ontwikkeling
telmachine

Waarde agile in functiepunten?

© CC BY 2.0 - Flickr,  Aden Davies
9 mei 2016
Hoe meet je de waarde van agile softwareontwikkeling? Volgens Frank Vogelezang en Hennie Huijgens kunnen functiepunten worden gebruikt om de productiviteit van softwareontwikkeling te meten, ook in agile omgevingen. Zij laten zien hoe bestaande problemen kunnen worden opgelost.

Voor steeds meer bedrijven is het agile (door)ontwikkelen van software de standaardwerkwijze geworden. De gebruikers zijn blij, omdat ze sneller gewenste veranderingen zien in de software. De ontwikkelaars zijn blij, omdat ze direct met de gebruikers in contact komen en software maken die ook echt wordt gebruikt.

Functiepunten

Een functiepunt is een rekeneenheid die op een gestandaardiseerde manier de functionaliteit die een IT-systeem aan de gebruiker biedt, vertaalt naar een getalswaarde. Deze getalswaarde kan vervolgens gebruikt worden om de financiële waarden van gelijksoortige IT-systemen vergelijkbaar te maken. Functiepunten zijn al decennialang de enige betrouwbare eenheid voor het voorspelbaar en vergelijkbaar maken van ontwikkelinspanning en ontwikkelkosten, softwarekwaliteit en beheercapaciteit.

Er zijn verschillende methoden beschikbaar die door ISO gestandaardiseerd zijn om het aantal functiepunten vast te stellen en onafhankelijk te auditen.
De eerste generatie functiepunten is datageoriënteerd en kent waarde toe aan interne gegevens, externe gegevens, invoer-, uitvoer- en opvragingsfunctionaliteit (Nesma, IFPUG). Deze standaards zijn geënt op volledige (administratieve) systemen.

De tweede generatie functiepunten is transactiegeoriënteerd en kent waarde toe aan invoer, uitvoer, opslag en het inlezen van gegevens (COSMIC). Deze standaard is ook geschikt voor (SOA) componenten en embedded software.

Voor de budgethouders en controllers ligt dat anders. Hoe kunnen zij de beslissers overtuigen om budget vrij te maken voor agile projecten, en hoe zorgen ze ervoor dat de agile ontwikkelde software ook echt waarde toevoegt aan de organisatie? Van een groot project kun je een businesscase maken, maar hoe doe je dat met tweewekelijkse releases, laat staan met continuous deployment? En welke waarde willen we meten van de software?

Bij agile denken we vooral aan gebruikswaarde, waarbij stories met de meeste gebruikswaarde de hoogste prioriteit krijgen. Beslissers denken veelal in boekwaarde, waarbij vooral de kosten van het realiseren van de software een grote rol spelen. De storypoints die de Scrumteams gebruiken zijn prima geschikt om sprints te plannen en te bepalen welke gebruikswaarde vanuit de backlog in de software terechtkomt. Ze zijn niet geschikt om een commerciële prijs te contracteren of voor het vergelijken van de performance van verschillende projecten en releases in termen van geld, tijd en kwaliteit.

Met functiepunten kan dat wel (zie artikel ­Rini van Solingen & Jolijn Onvlee, AG 15 maart 2012). Met behulp van functiepunten kan de functionaliteit van software op een onafhankelijke manier worden bepaald. Aangezien softwareontwikkeling betekent dat de functionaliteit van de software wordt aangepast, kunnen functiepunten worden gebruikt om de productiviteit van softwareontwikkeling te meten. Budgethouders hebben hiermee een maat om de omvang van hun software en de wijzigingen daaraan te kunnen volgen (zie kader).

Gebruikswaarde

Waarom wordt dit dan toch niet overal toegepast? Daarvoor zien we de volgende redenen.

  1. Functiepunten meten de omvang van de functionaliteit. Dat is niet zomaar hetzelfde als de waarde van functionaliteit.
  2. Functiepunten lenen zich slecht om sprints in te plannen en passen daardoor niet in de flow van een iteratie. Scrumteams zien daardoor het meten van functiepunten als waste, omdat het niet bijdraagt aan het opleveren van software.
  3. Functiepunten worden bepaald op basis van documentatie. In veel Scrumteams is het maken van documentatie waarop je functiepunten kunt bepalen bij het invoeren van een agile manier van werken waste geworden.

Het eerste punt is het werkterrein van de product owner. Die zorgt ervoor dat alleen functionaliteit die waardevol is voor de organisatie wordt ontwikkeld. Als dat goed werkt, is een toename van de functionaliteit ook een toename van de waarde. Maar hoe bepaalt een product owner welke functionaliteit veel waarde heeft? Dat is niet zo eenvoudig als het lijkt. Neem het voorbeeld van Whatsapp. De functionaliteit van de app is in functiepunten uitgedrukt niet heel groot. Maar de waarde ervan in termen van het aantal gebruikers en de frequentie waarmee zij de app gebruiken, is enorm. Blijkbaar zijn er naast functionaliteit ook andere aspecten die waarde beïnvloeden.

Onderzoek

De International Conference on Software ­Engineering (ICSE) is de oudste en grootste conferentie over softwareontwikkeling, waar de nieuwste ontwikkelingen worden gepresenteerd en bediscussieerd. Dit jaar wordt de conferentie voorafgegaan door een keur aan gespecialiseerde workshops en conferenties. Een daarvan is de International Conference on Software and System Processes (ICSSP) waarin ontwikkelingen worden gedeeld op het bij ­elkaar brengen van de snel veranderende ­bedrijfsprocessen en de processen om de ­ondersteunende software te maken.

Als eerste stap in de ontwikkeling van een open toegankelijke oplossing die functiepunten meet direct op basis van de code in plaats van op ­documentatie, hebben de auteurs samen met onderzoekers van de TU Delft, CWI en SIG, een wereldwijd onderzoek gedaan onder measurementspecialisten. Er hebben 334 specialisten uit 40 landen aan meegedaan. Deze specialisten kregen een uitgebreide vragenlijst over het nut, de toepassing, de toegevoegde waarde en de haalbaarheid van het automatiseren van de bepaling van het aantal functiepunten. De resultaten hiervan zijn geanalyseerd en beschreven in een publicatie die na een reviewproces is geaccepteerd op de ICSSP. De resultaten worden 15 mei aanstaande gepresenteerd voor en ­besproken met een internationaal ­gezelschap experts op het gebied van procesautomatisering.

Belangrijkste conclusies uit het ­onderzoek waren:

  1. Een grote meerderheid (87 procent) van de respondenten noemt functiepunten een belangrijk gereedschap voor beslissers om investeringsbeslissingen te onderbouwen of te verantwoorden.
  2. Het geautomatiseerd meten van functiepunten wordt door 44 procent van de respondenten gezien als een belangrijke stap voorwaarts, zowel vanuit het perspectief van experts als van beslissers.
  3. Inhoudelijk zijn er nog wel wat hobbels te nemen om het idee werkend te krijgen, volgens 50 procent van de respondenten. Als belangrijkste obstakels worden gezien:
    • Het verschil tussen functionaliteit en technische invulling (26 procent).
    • Complexiteit en variatie in sourcecode (14 procent).
    • Het grote aantal programmeertalen (10 procent).
  4. Als beste methode om te automatiseren wijst 25 procent van de respondenten de COSMIC-methode aan.

De volledige publicaties van de onderzoeken zijn terug te vinden op de website van Goverdson.

Gebruikswaarde is een belangrijk begrip bij agile softwareontwikkeling, maar wat nu precies de gebruikswaarde bepaalt, is nog niet onomstotelijk vastgesteld. Uit onderzoek is gebleken dat de traditionele waarden als op tijd en binnen budget nauwelijks van invloed zijn op de ervaren gebruikswaarde. De kwaliteit van de opgeleverde software is de sterkste voorspeller van gebruikswaarde.De hoeveelheid opgeleverde functiepunten is wel een goede voorspeller voor kosten, kwaliteit en doorlooptijd, maar heeft maar beperkte invloed op de ervaren gebruikswaarde.

Wij denken dat een oplossing voor punt twee en drie ligt in het automatiseren van het meten van de omvang van opgeleverde software. Hiermee wordt het een opleveractiviteit in de flow van een iteratie en is het wel of niet aanwezig zijn van andere documentatie dan de ­code geen issue meer. Wanneer je het meten automatiseert en baseert op de opgeleverde code, in plaats van op documentatie die al dan niet aanwezig is, dan wordt het meten van de opgeleverde software een integraal onderdeel van een iteratie of een project.

Een van de weinige oplossingen voor het automatisch tellen van functiepunten die op dit moment in de praktijk gebruikt wordt is een commercieel product van CAST. Dit is een gesloten oplossing, waardoor de werking en de kwaliteit hiervan niet onafhankelijk getoetst kan worden. Juist het feit dat functiepunten onafhankelijk te auditen zijn, is de kracht van deze methodiek. Een gesloten oplossing past daar naar ons idee niet bij.

Daarom onderzoeken we de mogelijkheid om hiervoor een open-sourceoplossing te realiseren. Er zijn in de markt voor de meeste gangbare ontwikkeltalen parsers beschikbaar. ­Parsers converteren de inhoud van een stuk softwarecode, naar een datastructuur die gebruikt kan worden om de code te analyseren. Ook werken er al verschillende partijen aan algoritmen om datastructuren te vertalen naar functiepunten. OMG heeft al een werkstandaard gepubliceerd voor de IFPUG-standaard en Renault heeft zijn algoritmes op basis van de Matlab-documentatie vrijgegeven voor de COSMIC-standaard.

Door met behulp van open-sourcesoftware deze standaards toe te passen op de datastructuren die de parsers ­opleveren, kan de softwarecode toetsbaar ­worden vertaald naar functiepunten.

Obstakels

Uit onderzoek blijkt dat veel experts in functiepunten een belangrijk gereedschap zien voor het onderbouwen en verantwoorden van investeringsbeslissingen en dat automatisering daarvan een belangrijke stap voorwaarts is. De belangrijkste obstakels die hierbij worden gezien zijn:

  • Het verschil tussen functionaliteit en ­technische invulling.
  • Complexiteit en variatie in sourcecode.
  • Het grote aantal programmeertalen.

Wij zien dat functiepunten een belangrijk instrument zijn voor het besturen van softwareontwikkeling, in traditionele maar zeker ook in agile omgevingen. Het zou goed zijn wanneer er een open toegankelijke oplossing komt om die functiepunten te meten direct op basis van de opgeleverde code in plaats van op documentatie. Daarmee sluiten functiepunten beter aan op het steeds sneller en kortcyclischer opleveren van soft­wareproducten.

Zie ook Development op AG Connect Intelligence
Reactie toevoegen