Development

Software-ontwikkeling
Rolmaat

Meten aan software: de beste methode bestaat niet

Kwaliteit is geen absoluut gegevens. De vraag is of de kwaliteit die je krijgt, goed genoeg is voor je doeleinden.

© www.freeimages.co.uk,  www.freeimages.co.uk
24 november 2016

Kwaliteit is geen absoluut gegevens. De vraag is of de kwaliteit die je krijgt, goed genoeg is voor je doeleinden.

Meten aan software geeft altijd stof tot discussie. Software kent vele aspecten. Het meten van die aspecten leidt tot verschillende inzichten. Daar is niets mis mee, zolang je maar met het juiste inzicht de juiste beslissing neemt. De beste meetmethode bestaat niet. De beste methode hangt af van de vraag.

Software neemt een steeds belangrijkere plaats in in onze maatschappij. Bedrijven worden meer en meer afhankelijk van hun software en willen daarom steeds meer weten over die software. Welke meting daarvoor gebruikt moet worden geeft nog steeds stof tot discussie. Daarbij lijkt het te gaan om te bepalen welke meetmethode de beste methode is. Dat is echter de verkeerde discussie.

In het septembernummer van AG Connect heeft Werner Heijstek een lans gebroken voor het meten van de kwaliteit en onderhoudbaarheid van software. In mei (AutomatiseringGids nummer 9, 13 mei) hebben Hennie Huijgens en ik geschetst hoe productiviteit kan worden gemeten bij agile softwareontwikkeling. Iets waarop Jolijn Onvlee en Richard Sweer in het oktobernummer van AG Connect uitgebreid zijn ingegaan. Beide thema’s raken elkaar, ze zeggen immers allebei iets over het realiseren van software. Wat is nu het beste?

De juiste vraag

Software kent vele aspecten. De ISO heeft alleen al voor de productkwaliteit van software een volledige reeks van 25000 tot 25099 gereserveerd. Daarnaast is er een metastandaard (ISO/IEC 14143) voor de functionele omvang van software met vijf uitgewerkte meetmethoden, waarvan de Nesma standaard voor functiepuntanalyse (ISO/IEC 24570) en COSMIC (ISO/IEC 19761) de bekendste zijn in Nederland. Er valt dus nogal wat te meten aan software. Maar wat je zou moeten meten, hangt af van wat voor jouw organisatie belangrijk is. Een organisatie die snel software nodig heeft om een product met een korte levensduur te ondersteunen, is vooral gebaat bij informatie over hoe snel die software klaar kan zijn. Een organisatie die langdurig het uitbetalen van bedragen moet uitvoeren en verantwoorden, is vooral geïnteresseerd in robuustheid en fout(on)gevoeligheid. Hoewel beide organisaties software nodig hebben, zouden ze wel eens hele andere aspecten willen meten. En zelfs daar heeft de ISO aan gedacht met een norm voor het selecteren van de juiste metingen (ISO/IEC 15939). Wat de beste methode is, hangt af van de vraag.

Kwaliteit

Kwaliteit heb je altijd. De vraag is alleen of de kwaliteit die je krijgt, goed genoeg is voor wat je als organisatie wilt bereiken. Een applicatie die kortdurend een campagne moet ondersteunen, hoeft in de regel veel minder robuust en onderhoudbaar te zijn dan een applicatie die langdurig ingezet gaat worden in een omgeving die aan regelmatige wijzigingen blootstaat. In het laatste geval is het van groot belang om hoge eisen te stellen aan de onderhoudbaarheid van software. Het onderhouden van slechte kwaliteit software is factoren duurder dan van goede kwaliteit software, zoals Werner Heijstek terecht vaststelt. Met de relatie die hij probeert te leggen met productiviteit, ondergraaft hij echter zijn argumenten voor een goede kwaliteit van software.

Voor applicaties die langdurig beheerd moeten worden, is goede kwaliteit een must

Gezien de opkomst van bedrijven als CAST, Omnext, SIG en TIOBE maken steeds meer bedrijven zich zorgen over de kwaliteit van hun software. Er is nog maar beperkt gepubliceerd over de relatie tussen softwarekwaliteit en beheerkosten, maar uit mijn eigen praktijk weet ik dat dat verband heel duidelijk is (zie kader). Dus voor applicaties die langdurig beheerd moeten worden is goede kwaliteit een must. Het bepalen van de kwaliteit van software kun je doen door te kijken naar het aantal fouten die in de software worden gevonden. Een andere optie is om te kijken naar een aantal karakteristieken van de software die de kans op fouten vergroot, zoals de eerder genoemde bedrijven doen. Een hele effectieve tussenvorm is om al bij de ontwikkeling van de code te kijken naar de karakteristieken om zo te voorkomen dat fouten de software binnensluipen.

Productiviteit

Bij softwareontwikkeling wordt tijd geïnvesteerd om functionaliteit te realiseren of aan te passen. Het resultaat hiervan is productiviteit. Zoals Jolijn Onvlee en Richard Sweer vorige maand al lieten zien, is dit een zeer relevant gegeven, ook als er agile wordt ontwikkeld. Vanuit de business wordt nog steeds de vraag gesteld hoeveel de software gaat kosten en wanneer het klaar is om een nieuwe wet te ondersteunen of een nieuw product te lanceren. Zeker met deadlines die hard worden gestuurd vanuit de wetgever of vanuit een marketingcampagne is het van groot belang om op tijd zeker te stellen dat de software op tijd klaar is. Kijken naar de hoeveelheid regels code levert daarover geen zekerheid. Op het niveau van de code kun je niet bepalen of dit ook functionaliteit oplevert die de klant nodig heeft en waar hij zijn plannen op maakt.

Waarde is niet voor elke organisatie hetzelfde

Bovendien kan binnen één programmeertaal de ene regel code veel meer functionaliteit bieden dan de andere en verschillende programmeertalen hebben een verschillende expressiviteit als het gaat om functionaliteit per regel code. Het is dan ook niet voor niets dat Jolijn Onvlee en Richard Sweer de programmeertaal opnemen in de top vier van belangrijkste factoren die tijd, geld en doorlooptijd bepalen. Daarnaast is het van belang om te weten hoe efficiënt het team de programmeertaal kan gebruiken om functionaliteit te realiseren.

Functionaliteit én kwaliteit

Als software een nieuwe wet of een nieuw product moet ondersteunen, moet de gebruiker daarvoor nieuwe of andere functionaliteit krijgen. Daarvoor moet de software bepaalde dingen kunnen om dat mogelijk te maken. Deze kunnen worden uitgedrukt in functiepunten. Daarvoor is geen code of uitgebreide documentatie nodig. De meeste Use Cases voldoen prima. Afhankelijk van het type software kun je kiezen voor de Nesma- of COSMIC-methode om de functionaliteit in uit te drukken. De functionaliteit wordt gerealiseerd in code. In die code wordt bepaald wat de kwaliteit van de software is, dus bijvoorbeeld hoe veilig en hoe onderhoudbaar de software is. In de regel is een gebruiker niet geïnteresseerd in hoeveel code er nodig is, maar vooral in wat hij met de software kan doen. En hoe hij dat kan. Dat meet je in functiepunten en schrijf je in code.

Softwarekwaliteit en beheerkosten

Figuur kwaliteit

De belangrijkste parameter voor de beheerkosten van software is de kwaliteit. Software van een lage kwaliteit is moeilijk onderhoudbaar en daardoor zijn wijzigingen aan die software duur. Vanaf een zeker kwaliteitsniveau nemen de beheerkosten beduidend af. Om van goed onderhoudbare naar perfect onderhoudbare software te komen vraagt dit weer relatief veel inspanning. Afhankelijk van de functie van de software kun je een kwaliteitsniveau bepalen waarbij de kwaliteit van de software goed genoeg is.

Waarde

Productiviteit alleen is niet zaligmakend. Het is van groot belang voor de planning, maar uiteindelijk gaat het er altijd om of het aspect dat je meet, waarde oplevert voor de organisatie. Bij agile projecten kun je dat heel mooi zien. In de eerste sprints wordt er nog weinig waarde toegevoegd. Het team moet dan voorbereidend werk doen, zoals het inregelen van architectuur, infrastructuur en tools. Deze zijn voor het team belangrijk, maar leveren de gebruiker nog weinig waarde op. Daarna wordt er snel waarde gerealiseerd met de topprioriteiten van de backlog. Op een gegeven moment zijn de belangrijkste zaken klaar en wordt er functionaliteit gerealiseerd die leuk is om te hebben, maar minder waarde heeft. Dat is hét moment om een agile project te stoppen. Daarom is het bij het contracteren van een agile project belangrijk om te zorgen dat het contract dit toelaat, anders ben je een deel van de waarde van agile ontwikkelen kwijt.

Productiviteit en waarde

Productiviteit

Productiviteit en burndown rate zijn tijdens het hele traject (vrijwel) constant en geven daarmee geen informatie wanneer de meeste waarde gecreëerd is en wanneer softwareontwikkeling steeds minder waarde toevoegt aan de organisatie. Toch sturen veel organisaties alleen op productiviteit en/of burndown rate, waardoor er ook in agile trajecten minder waardevolle software gecreëerd wordt.

Waarde is niet voor elke organisatie het zelfde. Bij een organisatie die gedreven wordt door snelheid, wordt de waarde vooral door productiviteit bepaald. Voor een organisatie die gedreven wordt door betrouwbaarheid wordt de waarde vooral door kwaliteit bepaald. De mix verschilt per organisatie en soms ook nog per project. Zo heeft een pakketleverancier een financieel pakket dat in een heel productieve programmeertaal was gebouwd, herbouwd in een taal waarmee minder snel kon worden ontwikkeld. Waarom? Omdat de software daardoor robuuster, sneller en energiezuiniger werd. De ontwikkeling van het pakket werd daardoor duurder, maar het gebruik van het pakket werd voor de eindgebruikers stabieler, sneller en goedkoper. Dat was voor de pakketleverancier vele malen meer waardevol dan de productiviteit waarmee het pakket kon worden aangepast.

Wat de waarde bepaalt voor een organisatie is lastig in een algemeen advies te vangen. Idealiter maak je voor ieder stukje functionaliteit een businesscase: wat het de organisatie gaat opleveren als het er is. Dit moet je iedere iteratie herijken. In de praktijk zie ik dat vrijwel nooit gebeuren. Een pragmatische oplossing voor projecten is om alle functionaliteit een MoSCoW-prioritering te geven en bij het bereiken van de ‘Should have’s’ te overwegen wanneer het project moet stoppen. In een DevOps-omgeving kun je gaan afschalen op het moment dat er geen ‘Must have’s’ meer naar productie worden gebracht.

Zie ook Development op AG Connect Intelligence
1
Reacties
Marc 09 december 2016 04:33

Het is hoog tijd dat een idee uit 1975 eindelijk serieus wordt genomen:
https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_pilot_system

De tweede poging is altijd beter. En zolang je niet weet wat er gebouwd moet worden moet iedere planning en iedere productiviteitsmeting met een korreltje zout worden genomen.

Reactie toevoegen