Softwareontwikkeling is nog een jong vakgebied en wordt vaak als onvolwassen beschouwd omdat de gerealiseerde resultaten vaak niet overeenkomen met de verwachte. Een softwareproject dat binnen de gestelde tijd en budget wordt gerealiseerd is eerder uitzondering dan regel. Voorschriften voor ontwerpbeslissingen ontbreken alsmede controle ervan door een onafhankelijke instantie. Een van de oorzaken schuilt in de problematiek rond metingen aan software. In dit laatste artikel van zijn serie, geeft softwarearchitect Frits Greuter hiervan een schets.
Bij de meeste technische disciplines zijn ontwerpeigenschappen te meten in natuurkundige eenheden. Modellen ter ondersteuning van een ontwerpbeslissing worden verbeterd door het verzamelen van meetgegevens. Een bouwkundig ingenieur bijvoorbeeld kan beschikken over enorme hoeveelheden meetgegevens. Om de overspanning of het draaggewicht te bepalen van een beton- of houtconstructie, is gebruik te maken van diverse tabellen per type beton of per houtsoort. Het ontwerp van een brug kan worden doorgerekend in een model en de uitkomsten van de berekeningen zijn in het algemeen betrouwbaar: ze voorspellen de systeemeigenschappen correct. Binnen de softwareontwikkeling worden ontwerpbeslissingen zelden tot nooit genomen op basis van berekeningen die zijn gebaseerd op een model. Als er al wordt gemeten aan softwareontwikkelactiviteiten, softwaresystemen of -producten, worden de resultaten niet teruggekoppeld naar verbeteringen voor de ontwerpbeslissingen.
Hoe komt dat? Brooks [1] legt helder uit dat het verschil met andere disciplines wordt veroorzaakt doordat software in essentie ideeën weergeeft. Hoewel softwareontwerpen zijn gelimiteerd door de hardware (hoeveelheid rekenkracht, geheugen of bandbreedte) heeft een softwareontwerper een grote keuzevrijheid betreffende het ontwerp waarbinnen de gewenste systeemfunctie gerealiseerd kan worden. De natuurwetten leggen geen beperking op aan softwareontwerpen; binnen de softwareontwikkeling ontbreken natuurlijke eenheden of metrieken voor de begrenzing van de ontwerpen. Toch zijn de resultaten van een softwareontwerp getalsmatig uit te drukken. De vraag is: zijn deze getallen te gebruiken om de ontwerpruimte te beperken of ontwerpbeslissingen te sturen?
Metrificatie van ontwikkelactiviteiten
Voor de metrieken aan (software) ontwerpactiviteiten kunnen we verschillende categorieën onderscheiden:
- Business-metrieken; bijvoorbeeld geschatte of gemeten ontwikkelinspanning, doorlooptijd, ontwikkelingsrisico, enzovoort.
- Procesgerelateerde metrieken; Deze geven informatie of een activiteit volgens de methodiek is uitgevoerd, bijvoorbeeld: Is een ontwerp goedgekeurd tijdens de ‘review’? Is de activiteit binnen de mijlpaal afgesloten? Vaak wordt het proces gemeten via producteigenschappen, zoals het aantal fouten na een release, de gemiddelde tijd voordat een nieuwe fout wordt gevonden, de ‘uptime’ van het systeem, enzovoort.
- Omvanggerelateerde metrieken; ‘Source lines of code’ (loc of kloc) is bekend. Men kan ook denken aan functiepunten, aantal systeemeisen, enzovoort.
- Ontwerpgerelateerde metrieken; Er bestaan structuur-, algoritme- en prestatiemetrieken.
Een zeer uitgebreid overzicht van meer dan tweehonderd metrieken wordt gegeven door Zuse[4]. We noemen hier slechts enkele softwaremetrieken voor omvang en ontwerp per softwareontwerpactiviteit zoals deze gedefinieerd zijn in het eerste artikel van deze serie.
Softwarearchitectuurmetrieken
De omvang van softwarearchitectuur is uit te drukken in het aantal datastructuren (‘classes’), functies (‘public methods’) en parameters per functie. Om eigenschappen van een softwarearchitectuurontwerp uit te drukken, worden de softwarecomponenten vaak afgebeeld als een graaf. Graafeigenschappen als diepte, breedte, aantal knopen en aantal verbindingen worden gebruikt om informatie over de structuur van de software te achterhalen. Om bijvoorbeeld de koppeling te berekenen gebruikt Fenton [4]:
het maximum aantal verbindingen per knooppunt (software module); het gemiddelde aantal verbindingen per knooppunt, en het totaal aantal verbindingen.
Henry en Kafura [6] definiëren structuurcomplexiteit als Cp = (fan-in * fan-out)2.
Hierin is ‘fan-in’ het aantal modules dat een bepaalde module aanroept, en ‘fan-out’ het aantal modules dat aangeroepen wordt door een bepaalde module.
Lakos [7] neemt de testinspanning als uitgangspunt en definieert de ‘cumulative component dependency’ en laat verschillende ontwerpalternatieven zien om deze waarden naar beneden te krijgen waardoor de testinspanning dus lager wordt.
Alle genoemde auteurs geven geen absolute minimum- of maximumwaarden die niet geschonden mogen worden. Specifiek voor objectgeoriënteerde systemen bestaan nog de Mood-set van metrieken [8,9], die een indicatie geeft voor overerving, inkapseling, koppeling, en polymorfisme-eigenschappen van het ontwerp. Niet alle Mood-metrieken zijn architectuurmetrieken.
Implementatie- en realisatiemetrieken
De omvang van de software-implementatie kan worden uitgedrukt in kloc. Voor de kwaliteit van het software-implementatieontwerp zijn de metrieken van McCabe[10] en Halstead bekend. McCabe geeft ook maximale waarden voor de cyclomatische complexiteit, die een maat is voor de complexiteit van de logische structuren. Op basis van het tellen van sleutelwoorden als ‘if’, ’then’, ‘switch’, ‘while’ wordt het aantal mogelijke executiepaden door een stuk programma berekend. De Halstead-metrieken zijn gebaseerd op metingen van het aantal operanden en operatoren.
De belangrijkste softwarerealisatiemetrieken zijn de omvang van code of data en de executiesnelheid (hoeveelheid cpu-tijd). Ook software van derden zou meer moeten worden gecontroleerd op geheugen en cpu-gebruik. ‘Benchmarking’ van besturingssystemen binnen organisaties gebeurt nog nauwelijks. Hetzelfde geldt voor ‘benchmarking’ van compilers: hoe efficiënt is de vertaling van implementatie naar realisatie? Kan of moet ik vanwege een inefficiënte vertaling maar liever sommige programmeertaalconstructies achterwege laten? Andere metrieken zijn de ‘hit rate’ van de cpu-instructies op het data- of ‘code cache’-geheugen.
Meetproblemen bij softwaremetrieken
Aan ideeën om softwareontwerpeigenschappen getalsmatig uit te drukken ontbreekt het dus niet. Toch worden softwareontwerpmetrieken niet vaak gebruikt tijdens softwareontwikkelactiviteiten of softwareonderhoudactiviteiten. Zuse [4, p.7] zegt hierover: "Het grote probleem van softwaremetingen is de sceptische houding met betrekking tot het gebruik van numerieke waarden, omdat er geen bevredigende interpretatie van de getalswaarden bestaat en de betekenis van de getalswaarden ontbreekt."
Deze sceptische houding vinden we zowel bij de softwareontwikkelaars als het management. De meeste softwareontwikkelaars hebben geen training of opleiding gekregen in ontwerpmetingen. Vaak hebben ze het idee dat hun ontwerp te uniek is om metingen op toe te passen. De wetenschap dat een ontwerp een hoge koppelingswaarde heeft, vertelt een ontwerper nog niet hoe deze waarde te verlagen is. Echter, juist omdat software kneedbaar is, kan een ontwikkelaar elke structuur verzinnen die de systeemfuncties implementeert, dus ook een structuur met lagere koppelingswaarden. Door metrieken te gebruiken, wordt een ontwerper in ieder geval gedwongen nog eens kritisch naar zijn ontwerp te kijken en wellicht enige alternatieven te onderzoeken. Het management is sceptisch omdat, net als bij softwareprocesactiviteiten, een duidelijke ‘return of investment’ voor de meetinspanning ontbreekt. Een verband tussen bijvoorbeeld een lagere koppelingswaarde en een afname van de onderhoudskosten of het aantal fouten is nog niet vastgesteld. Ook is het nog onduidelijk welke metrieken zinvol zijn. Hiervoor is meer onderzoek nodig.
Het onderzoek naar softwaremetrieken kent enkele fundamentele problemen. In softwareontwikkeling zijn, net zoals in de sociale wetenschappen, geen herhaalbare experimenten in dezelfde omgeving mogelijk waar slechts één variabele kan worden gewijzigd.
Het vergelijken van meetresultaten is moeilijk omdat er niet aan identieke systemen wordt gemeten. Er is altijd een verschil in functionaliteit.
De metingen doen geen uitspraak over de functionele correctheid van het systeem, alleen over de niet-functionele eigenschappen van software. Ook doen de metingen geen uitspraak over het dynamisch gedrag van een ontwerp. Ze doen alleen een uitspraak over de eigenschappen van de statische structuren.
Kortom, de metingen worden door verschillende oorzaken verstoord. Binnen deze storingsgevoelige meetomgeving is het beter differentiemetingen toe te passen: vergelijk systemen met dezelfde functionaliteit of met dezelfde functionele zwaarte of omvang. Systemen met dezelfde functionaliteit vindt men alleen bij de directe concurrent en om verschillende systemen te vergelijken met gelijke ‘functionele zwaarte’ is een betere functiepuntmethode nodig. Deze methode om systeemfunctionaliteit uit te drukken is onvoldoende gestandaardiseerd en niet toereikend voor een groot aantal (ingebedde) systemen. Het is te overwegen om simpelweg gegevens te verzamelen van functioneel verschillende maar in omvang gelijke modules en te onderzoeken of de omvangeigenschappen inderdaad een correlatie hebben met fouten of (onderhouds)kosten. Blijkt er inderdaad een relatie te bestaan, dan kan de situatie worden omgedraaid: gegeven een gewenst niveau van onderhoudskosten of aantal fouten, dan gelden er voor modules, functies, enzovoort, maximum omvangwaarden.
Verschilmetingen met gelijke functionaliteit binnen een project zijn ook mogelijk indien over langere tijd wordt gemeten. Elk softwarearchitectuurontwerp is weer te geven in het realisatiedomein; we spreken dan van een executeerbare specificatie. Dit maakt het mogelijk om metrieken te bepalen tijdens zowel de architectuur- als de implementatiefase. Bij een goede softwarearchitectuur zullen gemeten waarden voor bijvoorbeeld koppeling niet mogen stijgen. Indien tijdens de onderhoudsfase wordt gekozen voor een totaal ander ontwerp, is te beoordelen of het nieuwe ontwerp inderdaad betere waarden heeft voor de gekozen metrieken.
Behalve verschilmetingen zijn ook de omvangdistributie-eigenschappen van de softwarecomponenten interessant. De softwarearchitectuur vertaalt tenslotte de systeemfunctionaliteit in datastructuren en functies daarop. Is het beter als de systeemfunctionaliteit gelijkmatig verdeeld wordt over de softwarecomponenten? Of in oo-terminologie: is een ontwerp met 2000 klassen en elke 4 tot 6 ‘public methods’ te prefereren boven een ontwerp van 500 klassen waarbij het aantal ‘methods’ varieert van 4 tot 60? Nu is dat nog onbekend.
Meting softwarekwaliteit
De metrieken zijn nodig om kwaliteitsattributen van een softwaresysteem te kunnen bepalen. Net als in andere disciplines zou het ook binnen de softwareontwikkeling mogelijk moeten zijn om ontwerpmetingen als feedback voor de ontwerpactiviteit te kunnen gebruiken.
Kazman[12] stelt de volgende kwaliteitsattributen voor om softwaresystemen te beoordelen:
- Systeemkwaliteitsattributen zichtbaar tijdens ‘runtime’ zoals prestaties, beschikbaarheid, functionaliteit en bruikbaarheid;
- Systeemkwaliteitsattributen onzichtbaar tijdens ‘runtime’ zoals modificeerbaarheid, portabiliteit, herbruikbaarheid, integreerbaarheid en testbaarheid;
- Business gerelateerde attributen zoals ’time to market’, kosten en gewenste levensduur van het systeem.
De vraag is hoe nu de metrieken ingezet kunnen worden om de kwaliteitsattributen van een systeem te meten.
Zijn er metriekwaarden voor kwalitatief goede en slechte ontwerpen? Hiervoor ontbreken zowel voldoende meetgegevens als voldoende kennis over achterliggende modellen die metriekwaarden koppelen aan kwaliteitsattributen. Een lichtpuntje is dat er weinig twijfel is over het nut van de kwaliteitsattributen. Elke student krijgt te horen dat een ontwerp ‘modulair’ moet zijn, en er is geen discussie dat eigenschappen als modulariteit, herbruikbaarheid, lagere koppeling, hoge cohesie, enzovoort, op een positieve manier bijdragen tot betere producten. Toch zijn er nauwelijks meetgegevens voorhanden om dit empirisch te ondersteunen. Zonder een betere empirische validatie blijft het gebruik van metrieken twijfelachtig. Ook hergebruik van software, geprezen als een van de beloften van objectoriëntatie, wordt niet getalsmatig uitgedrukt terwijl dit, zeker in het realisatiedomein, wel mogelijk is.
Uiteraard ligt de verantwoordelijkheid voor deze zorglijke toestand in eerste instantie bij de gebruikers van softwareprogramma’s zelf. Bij aanschaf van een software letten zij voornamelijk op de functionele eigenschappen van het programma. Eindgebruikers zijn natuurlijk ook niet in staat om een product op zijn onzichtbare eigenschappen te controleren. Net als bij de aanschaf van een huis of auto gaan zij er terecht van uit dat het programma volgens kwalitatieve voldoende richtlijnen is ontworpen en gebouwd. Dit is echter niet het geval; sterker nog, er bestaat zelfs geen overstemming over de kwaliteitskeurmerken. Elke fabrikant mag straffeloos beweren dat zijn softwarepakket modulair, uitbreidbaar, beschikbaar en onderhoudbaar is, maar niemand kan dat controleren. Hier is een rol voor een keurmerkinstantie weggelegd.
Los hiervan speelt natuurlijk ook nog het aspect van de aansprakelijkheid. Een autofabrikant kan aansprakelijk worden gesteld indien zijn product op het cruciale moment niet correct functioneert. Hij is strafbaar indien zijn product kwalitatief niet goed is geproduceerd en hij niet kan achterhalen onder welke omstandigheden onderdelen zijn geproduceerd, en wat de kwaliteitskenmerken van de onderdelen zijn. Voor softwarefabrikanten gelden blijkbaar andere normen. Alleen bij wanprestaties wordt nu een enkele keer een softwarefabrikant aansprakelijk gesteld.
Een weg uit het moeras
Metingen aan software zijn problematisch. Procesverbeteringsprogramma’s als cmm richten zich niet op de ontwerpeigenschappen zelf. Indien we aan ontwerpactiviteiten willen gaan meten, moeten we eerst precies definiëren wat de ontwerpactiviteiten inhouden en hoe ze georganiseerd moeten worden (zie hiervoor de twee voorafgaande artikelen uit deze serie). Pas als dit op een uniforme manier gebeurt, wordt het mogelijk om gegevens tussen verschillende organisaties te vergelijken, zeker indien de organisatie van de softwareactiviteiten ook meer gestroomlijnd wordt. Het betekent dat er een volwassen softwareontwikkelproces moet zijn alvorens met softwareontwerpmetingen te kunnen beginnen. Vervolgens moet er over een langere periode gemeten worden voordat er conclusies zijn te trekken. Dit vereist een behoorlijk ‘commitment’ aan een meetprogramma terwijl in veel softwareontwikkelorganisatie de korte-termijnbelangen (de volgende versie) nog steeds voorrang krijgen. Omdat de softwareonderhoudskosten stijgen, en wijzigingen in eisen er altijd zullen zijn, wordt het belangrijker te weten hoe de software te structuren is zodat de kosten zullen dalen. De focus van het ontwerpen van software ontwerpen zal meer en meer komen te liggen op het aan elkaar knopen van de functionaliteit, en minder op het vinden van optimale algoritmiek voor de functie implementatie. Los van het functioneel correcte gedrag van een bepaald programma kunnen we ons afvragen: Bestaan er structuren voor softwarefunctionaliteit, kunnen we eigenschappen daarvoor benoemen en deze inzetten om de structuur voor de functionaliteit onderhoudsvriendelijker te maken? Naar mijn stellige overtuiging luidt het antwoord op al deze vragen bevestigend.
Frits Greuter Softwarearchitect Rohill Technolog
Literatuur
[1]. Brooks, F.P., The Mythical Man Month, Essays on Software Engineering Anniversary Edition, 1995, Addison-Wesley.
[2]. Blaauw, G.A., en F.P. Brooks. Computer Architecture, herfst 1982, Lecture notes of course 126113 of Twente University of Technology.
[3]. Putnam, L.H., Measures for excellence, reliable software on time, in budget. Yourdon Press Computing Series
[4]. Zuse, H., A framework of Software Measurement, 1997, Walter de Gruyter
[5]. Fenton, N.E., en S.L. Pfleger, Software Metrics, 1996, International Thomson Publishing Inc.
[6]. Henry, S.M., en D.G. Kafura: Software structure metrics based on information Flow, Ieee Transactions of Software Engineering, Volume 7, No.5, 1981
[7]. Lakos, J., Large scale c++ software design, 1996, Addison-Wesley.
[8]. Basili, V.R., en W.L. Melo. A validation of object-oriented design metrics as quality indicators, IEEE Software, Oct. 1996
[9]. Harrison, R., S. J. Council, en R.V. Nithi, An evaluation of the mood set of object-oriented software metrics, IEEE Software, June 1998.
[10]. Watson, A. H., en Th. J. McCabe, Structured testing: a testing methodology using the cyclomatic complexity metric, 1996, NIST Special Publication 500-235
[11]. Kan, S.H., Metrics and models in software quality engineering, 1995, Addison-Wesley, Inc
[12]. Bass L., P. Clements, en R. Kazman. Software architecture in practice, Addison-Wesley 1998
Deze serie bestaat uit drie delen:
