Met GQM nieuw leven voor kwaliteitsverbetering van het softwareproces

Kwaliteitsprogramma’s voor het ontwikkelen van software zijn er in overvloed: Iso 9000, CMM, Iso 15504 (Spice) enzovoorts. Geen bedrijf kan zonder. De grote vraag is echter hoe goed ze in de praktijk werken en hoeveel ze opleveren. De onlangs in een boek beschreven ‘Goal/Question/Metric’-methode lijkt in dit opzicht betere mogelijkheden te bieden. Een gesprek met Rini van Solingen, een van de schrijvers.

Softwarekwaliteit is een weerbarstige materie. Er zijn onnoemelijk veel programma’s en methodes voorgesteld, die ongetwijfeld het beste voor hebben, maar in de praktijk niet echt goed blijken te werken. Iso 9000 is een heel bekende norm, maar dat maakt slechts het proces herhaalbaar, zonder dat proces zelf te optimaliseren. ‘Software engineering’ heeft tot doel ingenieursmethodieken te gebruiken bij de ontwikkeling van software, maar dat blijft een zeer algemeen begrip zonder veel specifieke inhoud. CMM (Capability Maturity Model) tracht de ervaring van vroegere projecten te benutten om volgende projecten meer voorspelbaar te maken, maar door personele en technische wisselingen lukt dat maar moeizaam.
Velen denken dat je het software-ontwikkelproces niet kunt standaardiseren, omdat het in de meeste gevallen geen proces is dat je volgens een vaste methodiek kunt voeren: de probleemstelling, de projectinhoud, de gereedschappen en andere omstandigheden zijn vaak zo verschillend dat het in de praktijk onmogelijk is om vroegere ervaringen te benutten.
De methode volgens het principe Goal/Question/Metric lijkt in dit opzicht betere mogelijkheden te bieden.
 
Wat maakt GQM anders dan al die andere methodes en technieken?
Rini van Solingen, ‘senior quality engineer’ bij Tokheim en verbonden aan de TU Eindhoven: "Afdelingen voor softwarekwaliteit staan inderdaad vaak onder vuur. Er zijn meestal veel meetgegevens beschikbaar, mogelijk verzameld in het kader van een Iso-certificaat of CMM, maar die zijn dan niet relevant voor een nieuw project. Dat was het beginpunt. Ik kwam toen, aanvang 1994, als afstudeerder bij Schlumberger (nu Tokheim). Er was in het verleden van alles gemeten, maar net niet die dingen die we voor het nieuwe project nodig hadden. We zijn toen op de ideeën van GQM gestoten, en samen met anderen hebben we deze ideeën verder ontwikkeld en uiteindelijk samen met onze ervaringen en resultaten uit vier projecten vastgelegd in een boek. Zoals de naam al zegt, het idee is om per project vast te stellen welke doelen (goals) je wilt meten en welke metrieken (metric) je daarvoor wilt gebruiken, om de ontwikkeling te optimaliseren. Je gebruikt dus wel je algemene ervaring als specialist, maar past de vragen (questions) en metrieken aan voor elk afzonderlijk project."

Ontstaansgeschiedenis

Van Solingen, in antwoord op de vraag hoe en wanneer de methode is ontstaan: "Oorspronkelijk in het begin van de jaren zeventig bij de Nasa, die toen door Victor Basili en David Weiss een totaal nieuw soort programma’s liet ontwikkelen van een ongekende complexiteit. Zij zijn er echter pas in 1984 toe gekomen om ervaringen te publiceren en in de laatste jaren begint er meer belangstelling voor te komen."
"Waarom dat zo lang gesluimerd heeft? Het heeft lang in de sfeer van defensie en de academische wereld geleefd, met mensen die deze methode nogal wetenschappelijk hebben bekeken, zonder de noodzaak te voelen hem te documenteren of in het bedrijfsleven toe te passen. Bij het afstudeerwerk bleek bij toeval dat een andere divisie van Schlumberger sinds kort samenwerkte met Dieter Rombach, een discipel van Basili. We hebben toen het werk gecoördineerd, en zo is het balletje steeds sneller gaan rollen en heeft het meer massa gekregen. Er is een innige samenwerking met Egon Berghout van de TU Delft ontstaan; we hebben samen het boek geschreven en in Delft proberen we een web-site met algemene informatie over GQM te ontwikkelen."
Rombach is inmiddels directeur van het Fraunhofer Center for Software Engineering in Kaiserslautern (Duitsland) geworden, en heeft Van Solingen overgehaald om met ingang van 1 januari 2000 de GQM-afdeling van twintig man te gaan leiden. Dat schept veel nieuwe mogelijkheden om de toepassing van GQM uit te breiden.
Van Solingen vertelt dat het boek is ontstaan doordat veel afstudeerprojecten bij Schlumberger en later Tokheim hebben plaatsgevonden die diverse aspecten van GQM hebben onderzocht. Hij zelf heeft onlangs zijn zevende GQM-project afgerond. Het boek en de uitwerking van GQM daarin is dus vooral een Nederlandse ontwikkeling.
 
Hoe wordt die elders in de wereld ontvangen?
Van Solingen: "De erkenning van GQM begint langzamerhand te komen. De pioniers, en dan met name professor Basili en professor Rombach, hebben wel plannen gehad om een boek te publiceren, maar zijn er niet toe gekomen. Er zijn inmiddels wel teams in verschillende bedrijven in allerlei sectoren die het gedachtengoed gebruiken, en niet alleen in Europa. Het is echter nu nog vroeg om te zeggen of de methode op grote schaal zal aanslaan."

Ontwikkeling

De Amerikanen propageren vooral CMM, dat ontwikkeld is door Watts Humphrey en het SEI (Software Engineering Institute), waarin vijf niveaus van rijpheid van de organisatie bereikt kunnen worden. Humphrey heeft inmiddels ook PSP (Personal Software Process) ontwikkeld, waarmee een individu zichzelf kan verbeteren. Dat lijkt een goede stap.
Van Solingen: "En TSP (Team Software Process)! Die hebben allemaal hun goede kanten en bijten GQM niet. Maar ze verschillen van GQM in die zin dat je bij GQM voor elk project specifiek bepaalt welke kwaliteitsdoelen je nastreeft en hoe je die wilt meten, niet voor een hele organisatie, team of individu. Bovendien propageren we dat een kwaliteitsorganisatie op een andere manier gaat werken. Nu wordt de kwaliteitsgroep te vaak gezien als een politieagent die controleert en dicteert. Door deze rol ontstaat er vaak een grote afstand tot de ontwikkelaars. Wij willen zo dicht mogelijk, hulp biedend, met het project samenwerken. Het project blijft de baas; wij brengen alleen de discussie op gang over wat kwaliteit voor dit project betekent en helpen de groep om die te meten en ervan te leren. Als het projectteam denkt dat ons werk niet (meer) zinvol is, houden we er acuut mee op. De meetdoelen zijn dan meestal ook behaald."

Aspecten van kwaliteit

Op welke aspecten van software-kwaliteit richtten jullie je gewoonlijk?
Van Solingen: "Dat ligt heel verschillend en is volledig afhankelijk van het project in kwestie. In de theorie van GQM wordt gewerkt met drie voornaamste aspecten van kwaliteit: kosten, (doorloop)tijd en risico’s. In een bepaald project bij Tokheim, lagen de tijd en de kosten vast. Als het project langer zou duren of meer zou kosten, waren de effecten daarvan direct van invloed op de winstgevendheid van een productlijn. Productbetrouwbaarheid stond voorop, maar werd niet zo goed aangestuurd als de tijd en de kosten. Dus concentreerden we ons op de productrisico’s, die in dit geval vooral op het gebied van testen lagen. Zoals vaker bij het ontwikkelen van software komen de problemen pas aan het eind van de rit naar boven en is men vervolgens geneigd om het testen in te korten. De deadline is immers zelden te wijzigen. Op verzoek van de ontwikkelaars in het project hebben we ons dus speciaal gericht op de optimalisering van het testproces: de voorwaarden, de voorbereiding, de voortgang en het rapporteren van de resultaten daarvan. Maar in een ander project zal de nadruk op heel andere aspecten kunnen liggen, bijvoorbeeld het gebruik van een nieuwe programmeertaal, nieuw gereedschap, nieuwe mensen, een totaal nieuwe toepassing en noem maar op."
 
Hoe werkt dat optimaliseren in de praktijk? En hoe bereik je dat er tijdens de ontwikkeling wordt bijgestuurd om het ontwikkelproces te verbeteren?
Van Solingen: "Dat geschiedt door zogenaamde ‘feedback-sessies’, regelmatig gehouden bijeenkomsten waarin de conclusies uit de metingen van de afgelopen periode worden gepresenteerd en bediscussieerd. Vooraf wordt met het projectteam besproken welke aspecten worden gemeten en hoe dat het beste kan. Tijdens zo’n feedback-sessie worden de gemeten resultaten getoond en besproken – dit is een essentieel onderdeel van GQM. Daardoor komt er een nadruk te liggen op uitgekozen probleemgebieden, die hoe dan ook nuttig zijn om onder de aandacht van het projectteam te brengen, en motiveer je de teamleden. Zelfs al lukt het niet de GQM-doelen te halen door welke oorzaak ook, dan nog werkt deze aandacht voor kwaliteit positief op het eindresultaat – is onze ervaring."
Er bestaat een duidelijk verschil tussen de GQM-doelstellingen en de doelstellingen van het project. Dit kan bijvoorbeeld als doel verkorting van de doorlooptijd met 25 procent hebben. Het GQM-project richt zich dan op het meten van de factoren die de doorlooptijd beïnvloeden, zodat het project die kritieke doorlooptijd beter in de hand leert houden, en leert welke acties men kan nemen om het verbeterdoel te halen.

Organisatie

GQM-consultants zitten blijkbaar in een aparte organisatie. En het optimaliseren van het werk is in feite een taak voor de projectmanager.
Zou je dat niet beter direct bij die projectmanager kunnen onderbrengen? En hoe organiseer je de GQM-inspanning?
Van Solingen: "In theorie is de projectmanager de aangewezen persoon, maar in de praktijk werkt dat niet goed. De GQM-consultant kan beter in een aparte kwaliteitsgroep zijn opgenomen, die ergens (hoog) in organisatie hangt. Anders kan een projectmanager in de verleiding komen deze persoon in te schakelen bij de dagelijkse werkzaamheden. Een projectmanager heeft het te druk met allerlei dagelijkse problemen om zich met metingen bezig te houden. Hoewel veel managers verbeteringen op de lange termijn nastreven, wordt bij problemen direct weer naar korte-termijnoplossingen gezocht. De GQM-consultant neemt dat werk uit handen. Bovendien is het niet slecht om de GQM-expertise in een aparte groep te bundelen, zodat deze experts van elkaars ervaringen kunnen profiteren." Belangrijk is dat de GQM-consultants niet beschouwd worden als een politieagent (zoals vaak bij Iso 9000-projecten het geval is), maar als een meewerkend persoon die het project zo goed mogelijk helpt te leren en te verbeteren.
Het boek beschrijft de vier fasen van een GQM-proces: planning, definitie, dataverzameling en interpretatie, waarvan de laatste twee herhaald worden voor elke feedback-sessie. Het is natuurlijk ook mogelijk dat het plan en de definitie bijgesteld worden na een valse start. Van Solingen: "De moeilijkste periode in het GQM-proces is die tot de eerste feedback-sessie. Dan moeten de plannen worden gemaakt, de doelstellingen gedefinieerd en de metingen bepaald. In de eerste sessie blijkt tijdens de terugkoppeling van de eerste meetresultaten of de metingen direct bruikbaar zijn; als het projectteam daarvan overtuigd is, loopt de zaak verder op rolletjes."

Gereedschap

Een van de grote problemen met kwaliteitsprojecten is dat je gegevens nodig hebt voor het trekken van conclusies. Dat betekent dat de teamleden hun werk en tijd moeten registreren. De ervaring is dat dit vaak nonchalant wordt gedaan omdat het nogal wat tijd en discipline kost om het nauwkeurig te doen. Van Solingen: "Juist daarom is de motivatie die ontstaat tijdens de feedback-sessies zo cruciaal. De leden van het project ontdekken dan dat het in hun eigen voordeel is om mee te werken; dat doen ze alleen als ze de meetresultaten kunnen gebruiken en er van leren."
In de ervaring van Van Solingen kost het meewerken aan een GQM-project niet meer dan 2 procent van hun tijd, dat is gemiddeld 48 minuten per 40-urige werkweek, dus dat valt mee in vergelijking tot de grote voordelen die daardoor behaald worden. De GQM-consultant besteedt aanzienlijk meer tijd aan het project. Van Solingen heeft de ervaring dat een consultant niet meer dan drie projecten als volledige taak kan ondersteunen.
Het zou mooi zijn als de gegevensregistratie automatisch zou kunnen plaatsvinden, door die bijvoorbeeld in te bouwen in het gereedschap dat gebruikt wordt door de programmeurs, zoals compilers of statische test-tools. Van Solingen: "Dat klinkt goed, maar in de praktijk verschilt de definitie van wat je wilt meten zoveel van wat dergelijke automatische hulpmiddelen aanreiken, dat dit niet goed werkt. Vandaar dat we elektronische formulieren gebruiken die eenvoudig in een database of spreadsheet kunnen worden ingevoerd. Hetzelfde geldt ook voor de verwerking door de GQM-consultant: de queries die je moet doen zijn voor elk project anders. Ook daarvoor geldt dat de meeste problemen in de beginfase liggen; als die queries eenmaal goed gedefinieerd zijn, zijn die voor de volgende feedback-sessie gewoon een update."
Omdat organisaties met andere methodes en andere systemen werken, is het nogal ingewikkeld om een echt GQM-gereedschap te ontwikkelen. Het Finse bedrijf VTT Electronics, dat de promotie van het boek sponsort, heeft hiervoor wel een gereedschap ontwikkeld dat een diversiteit aan koppelingen met reeds bestaande databases ondersteunt. Het instellen van dit tool kost wel enige tijd en is daardoor in kleine GQM-projecten niet kosteneffectief te gebruiken. In dergelijke projecten is het gebruik van een spreadsheet meestal al afdoende.

Soort projecten

In welk soort projecten is GQM toepasbaar? En komen kleine twee- of eenmansprojecten ook in aanmerking?
Van Solingen: "Op zich maakt de grootte niet uit. Ik heb laatst een tweemansproject gedaan bij Tokheim. Mijn ervaring is dat het projectteam uiteindelijk altijd positief is over de kosten en baten. Als je immers weet wat het kost om laat ontdekte software-problemen te herstellen, dan hoef je niet veel problemen voortijdig te ontdekken om de extra kosten vanwege GQM goed te maken. Veel bedrijven hebben hoe dan ook een software-kwaliteitsgroep; de vraag is dan hoe je die het beste kunt inzetten. Dat hoeft overigens niet noodzakelijkerwijs met GQM te zijn. Het kan best zijn dat het voor het bedrijf essentieel is om een Iso 9000-certificaat of CMM niveau 3 te hebben, omdat hun afnemers dat eisen. Anders doen ze geen zaken, en dan is de keus niet zo moeilijk! Alleen, een bedrijf moet zich goed afvragen waar het om gaat: een certificaat aan de voordeur of een echt betere manier van werken; en misschien wel allebei!"
Van Solingen is zeker niet tegen andere kwaliteitsmethodes, maar heeft gemerkt dat ze vaak verzanden in een bureaucratie van procedures, waarbij het verkrijgen van een certificaat tot doel verheven is "omdat dit geëist wordt door de klanten". GQM heeft geen generieke doelstellingen waardoor dit gevaar veel minder bestaat.

Fouten uit onwetendheid

De methode en principes van GQM zijn algemeen, en zouden overal te gebruiken zijn waar iets ontworpen en ontwikkeld wordt.
Op de vraag of dat ook hun doel is, antwoordt Van Solingen: "Die stelling is in zijn algemeenheid juist, maar ik denk dat GQM toch vooral bij software-ontwikkeling bruikbaar is omdat daar het kwaliteitsprobleem zo groot en zo complex is. Als je een brug ontwerpt of een fiets, kun je de problemen zien. Die zijn overduidelijk, dus daar hoef je geen speciaal programma voor te hebben. Software is veel moeilijker te meten en je ziet de problemen niet, omdat software geen volume of massa bezit. En omdat het zo onzichtbaar is, bestaat er vreemd genoeg ook geen neiging haar te meten. Vandaar dat je GQM juist daarvoor moet gebruiken. Software-ontwikkelaars zijn in het algemeen uiterst intelligente mensen die zeker niet met opzet fouten maken. Integendeel! Ze maken fouten uit onwetendheid! De doelstelling van GQM is om die onwetendheid te verkleinen, zodat ontwikkelaars zich beter bewust worden dat het maken van fouten inherent is aan hun werk, en wat ze eraan kunnen doen om hiermee om te gaan. Maar het gaat natuurlijk niet alleen om het signaleren van problemen, maar om beter te leren werken. Dat moeten wij als GQM-experts goed weten over te brengen: wij zijn geen toezichthouder maar meer een ‘leidsman’, wij hebben de functie van ‘katalysator’."
 
Hein van Steenis, freelance medewerker
 
GQM voor kwaliteit
De Goal/Question/Metric-methode biedt een praktisch stappenplan voor het opzetten, uitvoeren en evalueren van een kwaliteitsprogramma om software te ontwikkelen. Kwaliteit wordt gezien in het spanningsveld van tijd, kosten en risico. In overleg met projectdeelnemers wordt beoordeeld waarop het verbeterprogramma zich zal richten en hoe dat zal plaatsvinden. De kosten/baten-analyse is een geïntegreerd onderdeel van GQM, waardoor van het begin af aan motivatie ontstaat bij het projectteam en achteraf duidelijk is vast te stellen of de extra inspanning de moeite waard is geweest.
De GQM-methode, die los staat van de gekozen ontwikkelcyclus, omvat vier stappen:

1. Planning – Kiezen van de verbeterdoelstellingen en vrijmaken van de middelen.
   
2. Definitie – Uitwerken van de meetdoelstellingen naar meetdoelen, vragen en metrieken.
   
3. Dataverzameling – Verzamelen van de meetgegevens.
   
4. Interpretatie – Analyseren van de verzamelde meetgegevens, trekken van conclusies, en die bespreken met het projectteam dat vervolgens maatregelen kan nemen.