Broncodeanalyse laat methodenstrijd links liggen

De eisen aan ‘straks’ zijn vaak zacht en niet cijfermatig gespecificeerd: software moet goed aanpasbaar zijn, eenvoudig, goedkoop te beheren en lang meegaan. Projectmanagers sturen hun projecten op de eisen van ‘nu’. Daar worden ze immers op afgerekend. De eisen voor ‘straks’ worden vaak minder hard meegenomen, daar wordt toch niet hard op gecontroleerd.
En daar betaal je als opdrachtgever/CIO straks de prijs voor. Tachtig procent van de kosten van software wordt immers gemaakt gedurende de gebruiksfase (hier ‘straks’ genoemd). Je zou – zo geredeneerd – meer aandacht verwachten voor het managen, controleren, van de technische kwaliteit van software tijdens het bouwen ervan. (Overigens kan voor ‘software bouwen’ vaak ook gelezen worden: sofware implementeren, configureren, parametriseren, programmeren, het lijkt vaak verdacht veel op elkaar.)

Traditioneel
Hoe worden softwareprojecten traditioneel gemanaged? Er lijkt sprake van een heuse methodenstrijd. Zonder wetenschappelijke onderbouwing kan er een tweedeling worden gemaakt:
• Het proces: hoe richten we het proces in? Welke projectmanagementmethode kiezen we? RUP, DSDM, Prince-2, CMMI, Scrum?
• De architectuur: hoe richten we de technologie in? Volgens welke architectuur moet er gewerkt worden? Elke technologie heeft een eigen frameworkstrijd: thin client, 3-tier, service oriented architecture (SOA), objectoriëntatie et cetera.
Zou het kunnen zijn dat we hiermee iets missen? Is er in softwareland misschien bovenmatig veel aandacht voor het ontwerpen van softwaredevelopmentprocessen en -architecturen? En uitzonderlijk weinig aandacht voor het meten van geleverde softwarekwaliteit? Terwijl dat laatste misschien wel de meest bepalende factor is voor beheerkosten, aanpasbaarheid en meer belangrijke onderwerpen. Dit is overigens ook wat gezegd werd over de ooit zo populaire ISO-certificeringen: ‘ISO geeft aan of je je proces op orde hebt, maar je kunt ISO-gecertificeerd betonnen zwemvesten produceren.’
Hebben de procesmethodes als Scrum en RUP dan geen nut? Is Prince-2 onzinnig? Integendeel, je kunt niet zonder. Ze bevorderen – elk op hun eigen wijze – goede communicatie binnen projecten, zorgen dat taken afgestemd en verdeeld worden, helpen requirements goed in beeld te brengen, ze volledig en snel vast te leggen, en ze bieden handvatten voor projectmanagers om voortgang te bewaken. Dus onmisbaar.
En ook de architecturen/frameworks zijn onmisbaar. Ze geven structuur aan de realisatie van software. Zó moet er gebouwd worden, dít zijn de afspraken, dát doen we dus niet in dit project. Deze architecturen scheppen het kader waarbinnen iedereen zich moet en mag bewegen en creëren ook een gezamenlijk platform. Je moet alleen wel controleren of dat alles tot goede software leidt en daar helpen de genoemde methoden en frameworks niet of nauwelijks bij.

Broncode
Uiteindelijk, nadat alle consultants en programmeurs hun werk gedaan hebben, is de broncode het product dat een leverancier oplevert aan zijn klant. De broncode is datgene waar de gebruikers van de systemen hun functionaliteit van krijgen. Een softwaresysteem kan door de beste mensen, onder de beste projectleiding, met de beste hulpmiddelen, met het beste ontwerp en met de beste processen gemaakt zijn. De broncode met documentatie is uiteindelijk het enige dat men overgedragen krijgt. En het enige waar het bedrijf echt mee gaat werken.
De broncode is daarmee de enige valide bron om softwarekwaliteit te meten. Een vergelijking met de huizenbouw, vaak misbruikt overigens, is hier op zijn plaats. Wat keurt een keurder namelijk bij de oplevering van een huis? Hij keurt het fysieke bouwsel. Niet het ontwerp, niet het bestek, niet de planning van de aannemer, ook niet of de metselaars de juiste papieren hebben, niet of de fabriek die de kozijnen leverde, ISO-gecertificeerd is. Nee, de keurder keurt simpelweg dat wat opgeleverd wordt: het bouwsel. Hij keurt of het voldoet aan de ontwerpen, hij keurt of het voldoet aan de wensen van de klant, algemeen geaccepteerde standaarden en hij verricht metingen waar nodig.
Dat alles kan bij softwareontwikkeling ook, het kan zelfs beter. Het is namelijk niet mogelijk kwaliteitsproblemen in broncode te verstoppen (zoals het mogelijk is inferieure funderingsconstructies of slecht materiaal in de bouw toe te passen). Tevens kan softwarebouw geautomatiseerd van dag tot dag worden geanalyseerd. Dat lukt bij bouwkundige keuringen niet.
Kwaliteitsmetingen met behulp van geautomatiseerde broncodeanalyse leveren objectief inzicht. Het levert, ondersteund door metingen, inzicht in wat er geleverd is en het helpt om een leverancier te managen. Het managen van software­kwaliteit met behulp van broncodeanalyse is een goede aanvulling op, maar geen vervanging van CMMI, Prince2, SOA en andere kwaliteitsverhogende systemen.

Praktijk
De werkwijze kan heel eenvoudig zijn. Het team van software-engineers (intern of extern) werkt met zijn normale reguliere ontwikkelomgeving aan de realisatie van de software. De gerealiseerde broncode wordt op vaste intervallen ter beschikking gesteld aan een onafhankelijke auditpartij. Deze partij meet de ontvangen broncode door en bepaalt relevante kwaliteitsmetrieken (denk aan: complexiteitsindices, architectuurissues, codeerstandaarden et cetera). De auditpartij analyseert de trends en rapporteert de bevindingen aan de opdrachtgever en aan het team van engineers. Dit gebeurt door grafieken en overzichten op een beveiligde website en door mondelinge toelichtingen van de auditerende consultants.
Hiermee is de prestatie van het team (de leverancier) volkomen transparant geworden en kan iedereen een vinger aan de pols houden. Met name het feit dat metingen geautomatiseerd (objectief en herhaalbaar) en op regelmatige basis (dagelijks) uitgevoerd worden, creëert waardevol inzicht. Er blijkt daarnaast, als gevolg van de metingen, een heel ­prettige open, objectieve en positief ­competitieve sfeer in het project te ontstaan. Dit komt omdat elke stakeholder weet waar op gemanaged wordt: tijd, geld én (broncode)kwaliteit. Iedereen acteert daar dan ook naar. En als er dan eens een onderdeel minder goed gaat, dan zorgt het kortcyclische karakter van de metingen ervoor dat er direct correctieve acties worden ondernomen.

Randvoorwaarden
Naast een regelmatige, geautomatiseerde analyse van broncode zijn er natuurlijk meer randvoorwaarden om een gecontroleerde wijze van softwareontwikkeling mogelijk te maken, zoals:
• een heldere projectscope;
• een heldere definitie van welke aspecten van technische kwaliteit we nu eigenlijk willen nastreven, hiervoor is een goede softwarearchitectuur (en overeenstemming daarover) cruciaal;
• een deskundige klantorganisatie en een deskundige leveranciersorganisatie;
• capabele softwareontwikkelaars die het concept van kwaliteitsmetrieken kennen (geen ‘programmerende consultants’ die enkel op functionaliteit letten);
• een goede project- en contractstructuur;
• een onafhankelijke organisatie die in staat is objectieve kwaliteitsmetingen te doen.
Op dit moment is het objectief kunnen beoordelen van leveranciersprestaties van meer en meer belang, mede als gevolg van de voortdurende outsourcingsinspanningen en de SOX-eis aan de CIO. CIO’s kunnen zich niet verschuilen achter het argument: ‘Kwaliteit?, dat is de verantwoordelijkheid van de leverancier.’ Het wordt tijd dat organisaties niet alleen denken in proceskwaliteit, maar vooral ook in productkwaliteit. Gebruikers van ICT, aanbieders van ICT en het IT-budget zullen daar wel bij varen.

Frank Krom is CIO bij ING Lease (frank.krom@mail.ing.nl). Jan Willem Klerkx (jw.klerkx@sig.nl) is als directeur Strategie werkzaam bij de Software Improvement Group, die in 2000 als spin-off van het Centrum voor Wiskunde en Informatica is opgericht en vorig jaar de R&D Innovatieaward won op het Nationaal ICT Event 2005. Vanaf begin oktober dit jaar is SIG gestart met een vestiging in Zwitserland.

ISO 9126
Kwaliteitsmanagers hebben een vrij eenvoudige definitie van ‘­kwaliteit’, namelijk: ‘De mate waarin iets voldoet aan de eisen die eraan gesteld worden.’
De vraag is dus welke eisen aan de software gesteld worden en dat is weer afhankelijk van de rol die men heeft. Gebruiker, beheerder, budgeteigenaar, software-engineer: allen hebben andere eisen.
Traditioneel let men met name op ‘functionele kwaliteit’. Dat is wat smal. Daarom is het goed eens te kijken naar ISO-norm 9126 (bijvoorbeeld op www.iso.org). Deze norm definieert zes karakteristieken die gebruikt kunnen worden voor het implementeren en beoordelen van softwaresystemen. Dit zijn:
• effectiviteit;
• betrouwbaarheid;
• bruikbaarheid;
• onderhoudbaarheid;
• flexibiliteit;
• efficiëntie.
ISO 9126 maakt gebruik van interne- en externe metrieken. Interne metrieken betreffen de software zelf. Externe metrieken hebben betrekking op de software in zijn omgeving. ISO 9126 is bruikbaar en zinnig, maar feitelijk helaas wat teleurstellend als norm omdat hij (anders dan bij veel andere ISO-normen) geen echte normen stelt, enkel begrippen definieert. Desondanks is vooral de definitie aangaande het aspect onderhoudbaarheid waardevol.