Software­kwaliteit vraagt meer sturing

Testen meten alleen óf iets werkt, niet hoe. En functiepunten laten softwarekwaliteit links liggen. Zij meten documentatie. Dit is onpraktisch, onrealistisch, onzinnig en een gemiste kans. Functiepunten zeggen niets over softwarearchitectuur, niet-functionele eisen of kwaliteit. We kunnen het ons niet permitteren software als randverschijnsel te blijven behandelen.

Werner Heijstek

Ik woon in Leiden, een stad die rijk werd door de productie van laken. Leidse lakenmakers specialiseerden zich in de vijftiende eeuw in halffabricaten van laken en onderwierpen zich aan een strenge kwaliteitscontrole. Het resultaat was hoogwaardig laken en de dominantie van de Nederlandse lakenindustrie gedurende die hele eeuw. Die kwaliteitscontrole is interessant. Vaststellen van de kwaliteit van laken is een ingewikkeld klusje dat nauwkeurigheid en deskundigheid vereist. Een keurder drukte bijvoorbeeld de harige omwinding van het weefsel tegen de draad in om de fijnheid van het visgraatmotief vast te stellen. Dit motief wordt de keper genoemd. Nauwkeurig en deskundig een product bekijken heet nog altijd iets op de keper beschouwen. In Leiden snapte men vijfhonderd jaar geleden al dat je aardig kunt verdienen aan sturen op productkwaliteit. Bij software gaat dat anders. Software is geen laken. En hoewel hij zich graag affilieert met engineering is software ook geen brug of huis. Dus hoe weet je nu of je een kwalitatief hoogwaardig stuk software koopt of levert?
Het is gangbaar te vinden dat je dat doet door te testen. Maar een beetje trekken aan zo’n laken is toch even iets anders dan het op de keper beschouwen. Testen beschrijven óf iets werkt, niet hóe iets werkt. Dat doet er nogal toe. Het aanbrengen van wijzigingen aan bestaande systemen en ze verder uitbouwen is de norm. Reken maar dat de bouwkwaliteit hierin een hoofdrol speelt. Je organisatorische aanpassingsvermogen ligt besloten in de onderhoudbaarheid van je systemen, los van of ze nu goed uit allerlei testen komen of niet. Een wijziging aan een slecht gebouwd systeem kost rustig meer dan het drievoudige vergeleken met een kwalitatief hoogwaardig systeem.
Dat is geen gezever over kwaliteit, dat zijn harde euro’s. Dat is onredelijk veel geld kwijt zijn voor ogenschijnlijk simpele wijzigingen in systemen. Dat is elk jaar onverklaarbaar meer geld moeten uitgeven voor onderhoud. Dat is met lede ogen moeten aanzien hoe een concurrent een voorsprong neemt met een nieuwe dienst.

Functiepunten

Een ander voorbeeld van de geringe rol van software als product is een gangbare aanpak voor het vaststellen van de veronderstelde omvang van software: functiepunten. Waar testen zich nog verlaten op het gedrag van software, laten functiepunten software helemaal links liggen.
Functiepunten meten documentatie. Dit is onpraktisch, onrealistisch, onzinnig en een grote gemiste kans.
Het vereisen van gedetailleerde documentatie waar die in steeds mindere mate bestaat is onpraktisch. De resultaten van softwareontwikkeling bestaan uit documentatie en software. De afgelopen twee decennia is in toenemende mate de nadruk op software komen te liggen, ten nadele van documentatie. Zo is dit bijvoorbeeld letterlijk één van de vier pijlers van het agile softwareontwikkelmanifest.
Functiepunten bieden een hulpmiddel bij het vaststellen van een mate van omvang op basis van documentatie. Dit was bijzonder handig bij zogeheten greenfield softwareontwikkeling, veelvoorkomend in de jaren zeventig, tachtig en negentig. Tegenwoordig is de norm bijbouw, uitbouw, herbouw en het aan elkaar knopen van standaardcomponenten. Recente ontwikkelingen als enhancement function points zijn ingewikkeld en vangen de werkelijkheid slecht. Ook zijn bestaande systeemlandschappen complexer dan ooit. Het tekenen van grenzen tussen systemen, cruciaal voor de functiepuntmethode, blijkt steeds lastiger. De manier waarop software is gebouwd wordt wederom geheel buiten beschouwing gelaten. Functiepunten zeggen niets over softwarearchitectuur, niet-functionele eisen of kwaliteit terwijl zaken als performance, security, reliability en onderhoudbaarheid juist zoveel belangrijker zijn geworden de afgelopen twee decennia.
De functiepuntengemeenschap doet aanzienlijke moeite om maar niet te hoeven kijken naar al die bestaande software: testpunten, enhancement points, en het experimentele SNAP, een manier om non-functionals te betrekken bij metingen. Stuk voor stuk ingewikkelde voorstellen die in de praktijk lastig toe te passen blijken en die volledig voorbij gaan aan het product zelf.

KADER: Functies tellen
Functiepunten raakten in de jaren tachtig van de vorige eeuw in zwang als begro­tingssystematiek.  Functiepunten werden berekend op basis van de functionele eisen aan de software in termen van de bedrijfsfuncties die de softwaremodules zouden gaan vervullen.

Blinde vlek
Een stap verder gaat het als functiepunten gebruikt worden voor het vaststellen van productiviteit. Letterlijk genomen meet men hier de hoeveelheid documentatie die wordt opgeleverd. Bij levering zou je moeten kijken naar het laken, niet naar de order of de gespreksverslagen. Er is geen relatie tussen functiepunten en daadwerkelijke inspanning, vonden Frank Niesink en Hans van Vliet al in 1997 (Predicting Maintenance Effort with Function Points). Een klant in Duitsland vatte het onlangs kernachtig samen: Een tafel in deze kamer plaatsen is één functiepunt. Maar als hij niet past en er een draagmuur uit gesloopt moet worden voor hij kan worden geplaatst, is dat net zo goed één functiepunt. Over productiviteit zegt dit natuurlijk helemaal niets. Na het op de keper beschouwen van de architectuur van een systeem, is die draagmuur zo gevonden.
Sturen op een maximale hoeveelheid functionaliteit per euro leidt in de praktijk tot zeer lastig onderhoudbare systemen. Werkzaamheden aan de kwaliteit van die systemen leveren immers geen functiepunten op. Uitsluitend sturen op wat software doet, leidt tot achterstallig onderhoud.
Een ander probleem is de resultaatgerichtheid van functiepunten. Dit is een gevaarlijke blinde vlek voor vendor- en contractmanagement. Hoe zit het eigenlijk met de werkelijk geleverde inspanning? Als een softwareleverancier een manier heeft gevonden om met een klein deel van de tot dan toe benodigde inspanning telkens een gelijkwaardige hoeveelheid functionaliteit te leveren, zou je dat dan willen weten? Elke keer als ik die vraag stel, is het antwoord een volmondig ja.
Metingen aan software laten maar weinig ruimte voor discussie. Het is allemaal heel tijdrovend als de leverancier en afnemer aan tafel moeten om de onvermijdelijke verschillen in tellingen te overbruggen. Waarom niet gewoon dezelfde bron van informatie gebruiken? Het laken zelf. De hoeveelheid werk op codeniveau is een accurate reflectie van de daadwerkelijke hoeveelheid geleverde ontwikkelinspanning, of je die nu uitrekent per commit in een versiebeheersysteem of op basis van versies van een systeem, die enkele maanden uit elkaar liggen. Subjectieve conversiefactoren voor ontwikkelomgevingen zijn niet nodig. Het schrijven van een regel Clojure kost immers net zoveel tijd als het schrijven van een regel COBOL. Het meten van feiten maakt discussies minder ingewikkeld. Bovendien stelt deze aanpak je in staat zeer concreet te sturen op daadwerkelijke ontwikkel­inspanning en de kwaliteit van het geleverde werk, in plaats van veel ongrijpbaarder begrippen als functionaliteit of veronderstelde toegevoegde businesswaarde. Geen interpretaties maar feiten.

 

KADER: Regels code tellen
Om geleverde inspanning te beoordelen is het zaak niet zomaar alle, maar heel precies de juiste ontwikkelde, aangepaste en verwijderde regels code te tellen.
Voorbeelden van zaken die niet moeten worden meegeteld:
• Gegenereerde code.
• Third-party libraries.

Voorbeelden van zaken die juist wel moeten worden meegeteld:
•  Ontwikkelde testcode.
•  Configuratie.

Voorbeelden van zaken waarvoor een robuuste telaanpak moet kunnen corrigeren:
•  Verplaatste code.
•  Gedupliceerde code.
Hoe vaker je meet aan een systeem, hoe meer inspanning je meet. Niet alle inspanning eindigt immers in een release – een goede maat van efficiency. Het gebruik van een versiebeheersysteem geeft de meest accurate reflectie van wat er allemaal gebeurt op codeniveau. Bij het meten aan systeem-snapshots waartussen grotere intervallen liggen bestaat een vrij constante afwijking, blijkt uit onderzoek van bijvoorbeeld Jos Kraaijeveld. Hier kun je dus uitstekend voor corrigeren.

Goudmijn
Voor aanvang van ontwikkeling kun je prima vaststellen wat de verwachte hoeveelheid werk is op codeniveau: Welke componenten moeten worden aangepast? Welke verwijderd? En welke nieuwe moeten er worden geschreven? Je kunt vragen stellen over de technische relevantie van werk en of de inschatting van de werkzaamheden in lijn is met de verwachte arbeid op codeniveau. In de praktijk kom ik in dit vroege stadium grove over- en onderschattingen tegen. Door quotes en verwachte technische arbeid in balans te brengen behoed je leveranciers én klanten voor veel frustratie. Bovendien kun je door te bench­marken en continu te meten heel exact de vinger aan de pols houden: Gaat een project of release langzamer dan verwacht? Hoe is de kwaliteit van het ontwikkelde werk en hoe ontwikkelt zich de kwaliteit van het systeem als geheel?
Softwareversiebeheersystemen zijn een goudmijn voor objectieve informatie. Door het analyseren van zo’n systeem kun je vaststellen welke onderdelen van een systeem uitsluitend zijn aangeraakt door mensen die niet meer in dienst zijn. Dit is zeer waardevol als die componenten een centrale rol spelen in een voor de business cruciaal op stapel staand project. Hoeveel van de daadwerkelijk ontwikkelde code eindigt in productie? Welke ontwikkelaars hebben baat bij training voor het ontwikkelen van kwalitatief hoogwaardige systemen? Organisaties zijn vaak zelf de eigenaar van de systemen waar hun leverancier aan werkt. De versiebeheersystemen waar de broncode van die systemen in leeft, zouden in dat geval gewoon toegankelijk moeten zijn.
Software is gecodificeerde kennis, bedrijfskapitaal – en zal alleen maar aan belang toenemen. We kunnen het ons niet permitteren software als randverschijnsel te blijven behandelen en alleen te meten aan zaken in de periferie. Er ligt een schat aan ongebruikte objectieve stuurinformatie voor het oprapen.

Werner Heijstek is senior consultant bij de Software Improvement Group en als docent en onderzoeker verbonden aan het Leiden Institute of Advanced Computer Science (LIACS) van de Universiteit Leiden.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag