dr. ir. jacob brunekreef hva publicaties Een grijs gat Meten aan software ( kwaliteit )

* omslag Jacob Brunekreef

24-09-2007

16:53

Pagina 1

hva publicaties

dr. ir. jacob brunekreef

Een grijs gat Meten aan software ( kwaliteit ) 9 789056 295035

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Een grijs gat Meten aan software(kwaliteit)

Dr. Ir. Jacob Brunekreef Lector Softwarekwaliteit Instituut voor Informatica

Openbare Les Uitgesproken op 1 november 2007 Hogeschool van Amsterdam

In many ways, the software engineering process is an informational ‘black hole’ – it draws in money and resources like a magnet but little data emerges. (H.A. Rubin)

Measurement has been the basis of all science and engineering progress except for software. (Capers Jones)

Geloven, weten en meten Software engineering is het vakgebied dat zich bezighoudt met het ontwerpen, bouwen, testen en beheren van software. Het vakgebied is nog jong. Het idee om methoden en technieken uit bestaande engineering disciplines in te zetten voor het ontwikkelen van software stamt uit het eind van de jaren zestig van de vorige eeuw. Het was een antwoord op wat toen de ‘software crisis’ werd genoemd: een overvloed aan problemen met slecht functionerende software, ontwikkeld in softwareprojecten die te laat opleverden en te veel kostten. Aan de basis van gevestigde engineering disciplines als elektrotechniek, werktuigbouwkunde en chemische technologie staat de natuurwetenschappelijke benadering. Het ontstaan van die benadering wordt uitgebreid beschreven in De mechanisering van het wereldbeeld van de hand van de Utrechtse hoogleraar E.J. Dijksterhuis (Dijksterhuis, 1950). In dit monumentale boek beschrijft hij de geboorte van de klassieke natuurkunde, waarbij experimenten en wiskundige afleiding een prominente rol spelen. De voorganger daarvan, de antieke natuurkunde, was primair gebaseerd op principes die wij nu samenvatten onder de noemer ‘metafysica’: religieuze en filosofische invloeden op de theorievorming, het primaat van de theorie boven het experiment. Pas nadat de natuurkunde zich ontworsteld had aan haar metafysische ketenen ontstond een wetenschap die nu nog steeds model staat voor de (natuur)wetenschappelijke praktijk. Een wetenschap die aan de basis heeft gestaan van grote maatschappelijke veranderingen, zoals de industriële revolutie. De geboorte van de klassieke natuurkunde is niet vast te pinnen op één enkele gebeurtenis of één enkel tijdstip. Er is sprake van een periode waarin oude inzichten langzaam afsterven, nieuwe inzichten langzaam rijpen. Opvallend is de rol van de techniek: de sterk toegenomen kwaliteit van instrumenten in de zestiende en zeventiende eeuw gaf een enorme impuls aan het aantal en het niveau van experimenten. Daarmee werd het mogelijk een wetenschap te ontwikkelen die gebaseerd was op nauwkeurige waarnemingen. Enigszins generaliserend kunnen we zeggen dat de belangrijke rol die het meten (waarnemen, het uitvoeren van experimenten) toegewezen krijgt in het wetenschappelijk bedrijf de overgang markeert van het geloven naar het weten. We zouden dan ook mogen verwachten dat meten een prominente plaats inneemt in de ontwikkeling van de software engineering als toegepaste wetenschap, maar – zoals de citaten aan het begin van deze openbare les aangeven – dit is ogenschijnlijk niet echt het geval. Die citaten stammen uit het begin van

3

een grijs gat

de jaren negentig van de vorige eeuw (Rubin, 1993; Jones, 1991). Sindsdien is er in mijn ogen wel het één en ander ten goede veranderd, zonder dat er nu sprake is van een optimale situatie. Zodat we wellicht niet meer moeten spreken van een ‘black hole’, een ‘zwart gat’, maar eerder van een ‘grijs gat’: nog steeds wordt er binnen de software engineering te weinig aandacht besteed aan het meten en aan het analyseren van meetgegevens. Wat kunnen we eigenlijk meten aan software? Hoe moeten we meten? Wat kunnen we doen met meetresultaten? In deze openbare les wil ik op deze vragen ingaan vanuit de overtuiging dat het vakgebied van software engineering alleen werkelijk voortgang kan boeken als het meten een meer centrale plaats zal gaan innemen.

4

Dr. Ir. Jacob Brunekreef

ICT is overal ‘De producten van de digitale techniek, in het bijzonder de computer, hebben zich een essentiële plaats in de maatschappij veroverd: een ontwikkeling zonder weerga in de geschiedenis der techniek.’ Dit is geen zinsnede uit een recente populairwetenschappelijke beschouwing over ICT, maar een citaat uit de inaugurele rede van mijn leermeester Gerrit Blaauw, uitgesproken in 1966 op de toenmalige TH Twente in Enschede (Blaauw, 1966). De onderkenning van het grote maatschappelijke belang van ICT is dus al zeker 40 jaar oud. Tegenwoordig is ICT alom aanwezig in onze samenleving. Vrijwel ieder mens in de westerse wereld komt een aantal keren per dag in aanraking met toepassingen van ICT. Zo maken een treinkaartje uit een automaat, een sms-berichtje op een mobiele telefoon en route-instructies uit een routeplanner stuk voor stuk gebruik van ICT. ICT verandert de maatschappij. Reisbureaus zijn grotendeels uit het straatbeeld verdwenen; een reis boek je ’s avonds achter je pc, op het internet, niet meer aan een balie. Artikelen worden via een virtuele marktplaats of veiling verkocht en gekocht, niet meer in een winkel. Kennis haal je niet uit een boek maar van het internet. Je bent overal bereikbaar, per telefoon, sms of e-mail. De ICT-sector is ook van groot economisch belang. Met een aandeel in de nationale productiewaarde van ruim 5% en een aandeel van ruim 4% als het gaat om werkverschaffing is de ICT-sector van substantiële waarde voor de BV Nederland (CBS, 2006). De ontwikkelingen in de ICT zijn voor een belangrijk deel mogelijk gemaakt door de stormachtige vooruitgang op het terrein van de hardware. In ruim 60 jaar tijd is de ruimte die nodig is voor een elementaire digitale schakeling gekrompen van enkele kubieke centimeters (een elektronenbuis) tot enkele kubieke micrometers of zelfs nanometers (een halfgeleiderschakeling), en de tijd die nodig is om die elementaire schakelaar om te zetten, is teruggebracht van tienden van seconden tot nanoseconden. De snelheid van de ontwikkeling van hardware werd al in 1965 vastgelegd in de Wet van Moore: iedere twee jaar verdubbelt het aantal transistors op een chip. Figuur 1 toont de schets die ten grondslag lag aan deze wet. De lijn voor 1970 was een voorspelling.

5

een grijs gat

Figuur 1. Gordon Moores oorspronkelijke grafiek uit 1965. Al die krachtige hardware functioneert bij de gratie van software. Die levert de instructies op basis waarvan computers, mobiele telefoons en pinautomaten functioneren. Ook het produceren van software heeft in de afgelopen jaren een enorme ontwikkeling doorgemaakt. De eerste computers werden geprogrammeerd met behulp van stekkers en snoeren. Al snel werden computerprogramma’s opgeslagen in het geheugen van de computer. Aanvankelijk werden deze programma’s opgesteld in machinetaal: een lijst met instructies die direct uitvoerbaar is door de computer. Omdat deze taal voor de mens vrijwel onbegrijpelijk was (en is), werden al in de jaren vijftig van de vorige eeuw kunstmatige talen ontwikkeld die voor mensen begrijpelijker waren, maar verder van de machine afstonden. Deze talen dienden vaak specifieke doeleinden, zoals de taal Cobol voor het ontwikkelen van administratieve software en de taal Fortran voor wetenschappelijke rekenintensieve software. Deze talen waren de voorlopers van een generatie van imperatieve of procedurele talen, met groepen opdrachten (statements) die nog vrij direct om te zetten waren in instructies voor een machine. Sinds de jaren tachtig van de vorige eeuw wordt er in sterk toenemende mate geprogrammeerd in zogenaamde ‘object-georiënteerde’ talen. Daarbij dienen klassen van objecten, met welgedefinieerde operaties op die objecten, als basis voor een programma. Hedendaagse voorbeelden van talen uit deze categorie zijn Java, C# en C++.

6


Gezien de succesvolle aanwezigheid alom van ICT zouden we mogen veronderstellen dat het wel goed zit met de kwaliteit van de software die al die toepassingen aanstuurt. Helaas, niet alleen het succesverhaal maar ook het falen van software is legendarisch. Lijsten met softwarefouten zijn te vinden op het internet; zie bijvoorbeeld http://www5.in.tum.de/~huckle/bugse.html en http://www.cs.tau.ac.il/~nachumd/verify/horror.html. Soms is een fout hilarisch: in het najaar van 2006 ontvingen vrijwel alle werknemers van de Universiteit van Groningen een e-mail bericht waarin hun ontslag werd aangekondigd. Foutje van de computer(software). En, in februari 2007 lag het treinverkeer van en naar Amsterdam een aantal uren plat door een hardwarestoring. Wie tijdens die uren probeerde op de website van de NS meer informatie over deze storing te verkrijgen, kreeg een wel heel originele storingsmelding (zie figuur 2).

Figuur 2. Storingsmelding NS, februari 2007. Er zijn ook dramatischer voorbeelden te geven van het falen van software, ongelukken met ruimtevaartuigen, vliegtuigen of medische software, waarbij mensenlevens verloren zijn gegaan. Niet alleen het product software, ook projecten waarin software wordt geproduceerd hebben een bedenkelijke reputatie. Ze worden beëindigd zonder dat ze enig resultaat hebben opgeleverd en kosten veel meer tijd en/of geld dan 7

een grijs gat

oorspronkelijk was begroot. Beroemd is het Chaos Report van de Standish Group uit 1994. Dit rapport bevat onthutsende cijfers over het percentage softwareprojecten dat voortijdig gestrand is tegenover het percentage projecten dat op tijd voltooid is (zie tabel 1). Grote bedrijven Middelgrote bedrijven Kleine bedrijven Op tijd gereed Over tijd/over budget Voortijdig beëindigd

9%

16%

28%

62% 29%

47% 37%

50% 21%

Tabel 1. Slagingspercentage softwareprojecten in de Verenigde Staten, 1994. De cijfers hebben betrekking op de situatie in de Verenigde Staten, maar er is weinig reden om aan te nemen dat de situatie in Europa in 1994 anders lag. Onderzoek van recenter datum van dezelfde partij laat overigens betere cijfers zien. In 2006 was 35% van de projecten succesvol afgerond, was 46% van de projecten over tijd/over budget en stopte 19% van de projecten voortijdig. Maar, dit zijn nog steeds niet cijfers om trots op te zijn! De Standish Group heeft in haar onderzoek naar het slagen en falen van softwareprojecten een top-10 lijst van oorzaken opgesteld (zie tabel 2). Top-10 factoren slagen projecten

Top-10 factoren falen projecten

1.

Betrokkenheid gebruikers

1.

Gebrekkige specificaties

2.

Support uitvoerend management

2.

Onvoldoende betrokkenheid gebruikers

3. 4.

Duidelijke specificaties Heldere planning

3. 4.

Gebrek aan personeel, tools Onrealistische verwachtingen

5.

Realistische verwachtingen

5.

Gebrek aan management support

6.

Kleine project milestones

6.

Tussentijds wijzigen specificaties

7.

Competent personeel

7.

Gebrek aan planning

8.

Eigenaarschap

8.

Niet meer nodig…

9.

Heldere visie en doelen

9.

Gebrek aan IT-management

10. Hardwerkend en betrokken personeel

10. Gebrek aan technische kennis, vaardigheden

Tabel 2. Top-10 factoren voor het slagen en falen van softwareprojecten.

8


Opvallend is in de eerste plaats de betrokkenheid van de gebruikers. De aanwezigheid van die betrokkenheid is een belangrijke slaagfactor voor projecten, de afwezigheid een belangrijke faalfactor. Moderne ontwikkelmethoden als DSDM en XP propageren dan ook terecht een sterke betrokkenheid van de gebruiker van begin tot eind. Helaas moet ik vanuit mijn eigen softwarepraktijk constateren dat er vaak onvoldoende invulling aan dit punt wordt gegeven. Soms uit onvermogen, soms uit onwil, worden gebruikers pas in een zeer laat stadium, bij het acceptatietesten, betrokken bij een ontwikkelproject, met alle gevolgen van dien. In de tweede plaats valt het belang van goede specificaties op. Specificaties worden opgesteld door vertegenwoordigers van toekomstige gebruikers. Ze dienen als opdrachtomschrijving voor softwareontwerpers. Volgens sommigen is hier sprake van een fundamenteel communicatieprobleem. In zijn boek The Inmates Are Running The Asylum introduceert Alan Cooper het begrip ‘cognitive friction’. Hieronder verstaat hij de mentale kloof tussen de opdrachtgever/gebruiker aan de ene kant en de ontwerper aan de andere kant: de één leeft in een wereld van gewenste functionaliteiten, de ander in een wereld van mogelijke features (Cooper, 2004). Het tussentijds wijzigen van specificaties geldt als een belangrijke reden voor het falen van projecten. Dit is voorstelbaar. Maar, zeker bij langer lopende projecten is het een gegeven dat de specificaties tijdens het project wijzigen. De buitenwereld staat immers niet stil. De huidige generatie ontwikkelmethoden is daar dan ook tot op zekere hoogte op ingesteld. Als lector aan een onderwijsinstelling doet het me goed te zien dat ook de kennis en vaardigheden van personeel ertoe doen, zowel in positieve zin (competent, hardwerkend en betrokken personeel is belangrijk voor het slagen van een project), als in negatieve zin (gebrek aan technische kennis en vaardigheden is een faalfactor). En dan is er natuurlijk de planning en aansturing van een project. Een heldere planning, realistische verwachtingen en kleine project milestones zijn succesfactoren voor een softwareproject. Daartegenover staan een gebrekkige planning, onrealistische verwachtingen en gebrek aan IT-management als faalfactoren. Vooral het plannen, begroten en aansturen van grote projecten is een moeizame zaak. Dit geldt overigens niet alleen voor softwareprojecten. Ook grote infrastructuurprojecten in Nederland, zoals de Betuwelijn en de HSL, kampen met forse vertragingen en budgetoverschrijdingen. En ook hier zien we wat doorgaans als een van de grootste bedreigingen van de voortgang in software-

9

een grijs gat

projecten wordt gezien: het tijdens de rit wijzigen van het programma van eisen en wensen. De beveiligingssystemen die nu worden voorgeschreven voor de HSL zijn gebaseerd op eisen die nog niet bestonden bij de start van het project!

10


De virtuele wereld van software Zowel het succes als het falen van ICT, van softwareproducten en -projecten, is zeer zichtbaar in onze maatschappij. Voor het vakgebied van de software engineering ligt er de uitdaging om het succespercentage te verhogen door permanente aandacht voor kwaliteitsverbetering. Het aanpakken van een probleem begint met het in kaart brengen van wat er nu feitelijk aan de hand is. Daarbij speelt meten een belangrijke, zo niet centrale rol. In de fysieke wereld zijn we zeer vertrouwd met meten. Tal van eigenschappen van objecten worden uitgedrukt in een meeteenheid: de lengte van een persoon in meters, de massa van een auto in kilogrammen, de elektrische spanning van een batterij in volt en ga zo maar door. Software functioneert in een virtuele wereld. Dat is een andere wereld dan de fysieke wereld, wat betekent: andere eigenschappen, andere meeteenheden en andere meetprocessen. Voordat ik daar nader op inga, wil ik eerst enkele kenmerken van die virtuele wereld aanstippen die een rol spelen bij de mogelijkheden en onmogelijkheden van het meten aan software. 1. De relatie tussen statische en dynamische eigenschappen is indirect Gloeilampen worden gemaakt om licht te geven. Auto’s worden gemaakt om in te rijden. In de fysieke wereld kunnen direct waarneembare statische eigenschappen al duidelijk maken dat een product niet naar wens zal functioneren. Een gloeilamp zonder fitting, een auto met vierkante wielen… Al tijdens het ontwerpen en bouwen wordt duidelijk dat de gevraagde functie (licht geven, verplaatsen van personen) niet geleverd kan worden. Software wordt gemaakt om gewenst gedrag te vertonen als het programma gedraaid wordt. Software bestaat uit een aantal regels met programmacode. Aan die programmacode zelf is niet in één oogopslag te zien of er problemen zullen zijn bij dit dynamische gedrag. Daarin onderscheidt software zich van engineering-producten in de fysieke wereld. Bij software die functioneert in een virtuele wereld is de directe relatie tussen statische en dynamische eigenschappen niet aanwezig. 2. De grenzen van de virtuele wereld zijn niet helder In de fysieke wereld zorgen materiaaleigenschappen en natuurwetten voor een soort natuurlijke bovengrens voor wat betreft de mogelijkheden. Een brug met een overspanning van 10 kilometer, een auto met een topsnelheid hoger dan

11

een grijs gat

het geluid, een kerncentrale die heel Nederland van stroom voorziet: het zijn toekomstdromen van futuristen. De huidige generatie ingenieurs en constructeurs houdt zich er niet serieus mee bezig. Zowel informatici als niet-informatici zijn bijzonder goed in het bedenken van complexe uitdagingen op softwaregebied, zonder dat ze een helder zicht hebben op de mogelijkheden om ze te realiseren. Door het ontbreken van natuurlijke beperkingen is het niet altijd direct inzichtelijk dat de doelstellingen soms ver voorbij het haalbare liggen. Zo zijn in het verleden tal van grote automatiseringstrajecten gestart die voortijdig gestopt zijn, zonder dat ze enig resultaat hebben opgeleverd. Een berucht voorbeeld uit een wat verder verleden is het Strategic Defense Initiative (SDI) uit de jaren tachtig van de vorige eeuw, ook wel Star Wars genaamd: een computergestuurd raketschild in de ruimte dat de Verenigde Staten moest beschermen tegen raketaanvallen van buiten de VS. In 1985 trok de bekende informaticus David Parnas zich terug uit dit project omdat hij de realisatie van de benodigde software op vakinhoudelijke gronden voor onmogelijk hield. Zijn belangrijkste argumenten waren: inherent onvolledige specificaties (de kenmerken van een vijandige raket zijn pas met zekerheid bekend ten tijde van de aanval), het feit dat men het systeem niet kan testen in een realistische omgeving en het gegeven dat door de korte tijd waarin een aanval zich afspeelt een handmatige correctie van een foutieve beslissing niet mogelijk zal zijn (Parnas, 1985). Ook nu nog is voor grotere softwareprojecten de volledigheid van specificaties niet te garanderen en is een realistische testomgeving moeilijk of niet te realiseren. Mede hierom hebben kleinere projecten nog steeds een grotere kans van slagen dan grote projecten. 3. De virtuele wereld is discreet van karakter De fysieke wereld is voor het overgrote deel continue van karakter. In een continue wereld leidt een kleine verandering of afwijking tot kleine gevolgen. Eén wat zwakkere spaak in een wiel leidt niet direct tot het sneuvelen van een fiets. Software in de virtuele wereld gedraagt zich anders. Eén enkele foutieve actie in een programma kan leiden tot een 100% fout resultaat. Dit discrete gedrag van programmatuur (overigens ook al gememoreerd door David Parnas in zijn eerdergenoemde artikel) maakt het bijzonder moeilijk om ongewenste resultaten te allen tijde te voorkomen. In de fysieke (continue) wereld is overdimensionering een veelgebruikte techniek om potentiële problemen te voorkomen. Maak de spaken in een wiel extra dik, zodat ze bij normale belasting nooit

12


zullen buigen. Een dergelijke aanpak is in een discrete wereld onzinnig, want het toevoegen van een paar extra statements verhoogt op geen enkele manier de betrouwbaarheid van een programma! 4. De virtuele wereld kent zeer veel verschillende toestanden We kunnen een computerprogramma beschouwen als een automaat met een aantal toestanden. Door een externe prikkel (muisklik, menucommando, invoer van een getal) gaat de automaat over van de ene toestand naar een andere toestand. Enig rekenwerk laat zien dat zelfs bij eenvoudige programma’s het aantal mogelijke toestanden al snel in de miljoenen loopt. Dat wil zeggen dat niet iedere toestand waarin het programma kan verkeren, getest kan worden voordat het programma in gebruik wordt genomen, en dat houdt op zijn beurt weer een fundamenteel risico in: een programma kan in een niet geteste toestand ongewenst gedrag vertonen. 5. (Re)productie kost geen materiaal Aan het produceren van software zijn nagenoeg geen materiaalkosten verbonden. Zeker als de productieomgeving (de hardware) al aanwezig is, zijn de kosten van het produceren van software volledig toe te schrijven aan de inzet van de benodigde menskracht. Dit betekent dat een bestaand softwareproduct zonder verlies van materiaalkosten gewijzigd of zelfs weggegooid kan worden. Moderne ontwikkelmethoden voor software maken gebruik van deze eigenschap: tussenproducten worden aan toekomstige gebruikers getoond, en als deze niet bevallen, worden er wijzigingen in doorgevoerd. Dit is een belangrijk verschil met de fysieke wereld. Als een productiestraat voor een auto er eenmaal staat, dan is het zeer kostbaar om daar veranderingen in aan te brengen. In de klassieke engineering disciplines is alles er dan ook op gericht om éérst goed te ontwerpen en daarna pas te gaan bouwen, met als doel het aantal corrective actions tot een absoluut minimum te beperken. Binnen de virtuele wereld is een bestand (programma, maar ook documenten, muziek, foto’s, films) zeer eenvoudig en kosteloos te kopiëren. Ook dit is een belangrijk verschil met de fysieke wereld. Het ontwerpen en implementeren van een reproductieproces is een belangrijk aandachtsgebied binnen de klassieke engineering disciplines: hoe maak ik zo goed en goedkoop mogelijk grote aantallen gloeilampen, auto’s, etc. Binnen de virtuele wereld is het reproductieproces zeer eenvoudig en daarmee geen punt van aandacht/zorg (afgezien van auteursrechten of patenten, maar dat is een ander verhaal).

13

een grijs gat

Figuur 3. Onbeperkt kopiëren in de virtuele wereld. Op basis van de genoemde punten is te verwachten dat werken in een virtuele wereld gebaseerd zal moeten zijn op andere inzichten dan werken in de fysieke wereld. De klassieke engineering-aanpak, met ontwerpen op basis van materiaalkennis en natuurwetenschappelijke inzichten en bouwen en reproduceren op basis van beproefde constructiemethoden, is niet zonder meer overdraagbaar naar het terrein van de softwareontwikkeling. Het vakgebied van software engineering is nu zo’n zestig jaar onderweg met het verkennen van de mogelijkheden en onmogelijkheden van de virtuele wereld. Gezien de tijd die de natuurwetenschappen nodig hebben gehad om zich te ontwikkelen tot hun huidige niveau mogen we nauwelijks verwachten dat de software engineering al tot volledige wasdom is gekomen. In mijn ogen bevindt de ontwikkeling van software engineering als wetenschap zich in een fase die vergelijkbaar is met die van de natuurkunde in de zestiende, zeventiende eeuw. Alleen is nu niet een mechanisering maar een virtualisering van het wereldbeeld aan de orde. Oude inzichten die hun oorsprong hebben in de fysieke wereld gaan overboord. Nieuwe inzichten zijn al volop aanwezig, maar moeten nog tot volle wasdom komen. De geschiedenis heeft geleerd dat dit tijd kost. Ook al gaan wetenschappelijke ontwikkelingen vandaag de dag razend snel, dan nog is niet te verwachten dat een totaal nieuwe wetenschap als software engineering zich in ruim een halve eeuw volledig kan ontwikkelen.

14


Bij het ontwikkelen van een eigen wetenschappelijke aanpak op het terrein van de software engineering speelt een bezinning op het meten aan software een belangrijke rol. Hoe is de in andere wetenschappelijke disciplines zo succesvol gebleken empirische benadering te vertalen naar het specifieke domein van software engineering?

15

een grijs gat

Meten aan software Meten speelt in de natuurwetenschappen een cruciale rol. Op basis van meetresultaten worden theorieën geverifieerd of gefalsifieerd en worden onvolkomenheden in theorieën aan het licht gebracht. De natuurwetenschappen kennen een uitgebreide theorie en praktijk als het gaat om meten. Begrippen als ‘meetschaal’, ‘meeteenheid’ en ‘meetfout’ zijn uitgebreid beschreven, nauwkeurig gedefinieerd. Meten kan gezien worden als het (zo mogelijk kwantitatief) bepalen van een eigenschap (attribuut) van een object. Met het vaststellen van een aantal verschillen tussen de virtuele wereld en fysieke wereld dient zich direct de vraag aan wat we kunnen meten in de virtuele wereld en hoe we dit moeten meten. In deze paragraaf wordt een aantal direct meetbare eigenschappen (basismetrieken) benoemd voor zowel het product software als het proces van softwareontwikkeling (en -gebruik). Bij iedere eigenschap wordt een meeteenheid gegeven. Ook wordt aandacht besteed aan de meetmethode. Daarbij speelt het onderscheid tussen handmatig en geautomatiseerd een rol. Sommige eigenschappen zijn alleen via persoonlijke waarneming/inspectie te meten, andere kunnen via de inzet van tools (meetinstrumenten) zonder menselijke tussenkomst gemeten worden. Meten aan het product Een product kent dynamische en statische eigenschappen. Dynamische eigenschappen, zoals de snelheid van een auto, de remweg, de CO2-uitstoot, hangen samen met het gebruik. Statische eigenschappen zeggen iets over het product op zich: het gewicht, de lengte, de kleur van een auto. De oudste vorm van meten van de dynamische eigenschappen van software is testen. Door het programma te draaien op een computer kan een gebruiker, programmeur of beheerder waarnemen of het gedrag van het programma overeenkomt met de verwachtingen. Daarbij wordt vooral gekeken naar de functionaliteit: is de gewenste functionaliteit beschikbaar, leidt het activeren van een functie met specifieke parameters tot het beoogde resultaat? Functionaliteit wordt doorgaans niet gemeten tijdens het reguliere gebruik, maar in een aparte testsituatie in een aparte testomgeving. Een programmeur test vanuit een technische invalshoek of een module of functie correct werkt. Een gebruiker test meestal het hele programma. Hij controleert of het programma op de gewenste manier het bedrijfsproces van de gebruiker ondersteunt. Functionaliteit wordt gemeten door een groot aantal nauwkeurig beschreven

16


testgevallen af te lopen. Per testgeval wordt een geïsoleerd stukje gedrag van het programma gecontroleerd. Het is mogelijk om de uitkomsten van het testen uit te drukken in een getal, bijvoorbeeld het percentage testgevallen dat geslaagd is. Dit soort percentages is doorgaans weinig zeggend: het falen van één enkele essentiële functie is veel belangrijker dan het correct functioneren van een aantal onbelangrijke functies. Testen is voornamelijk een handmatige activiteit, die deels ondersteund wordt met tools. Testen is een vak op zich. Methodes als TMap zijn ontwikkeld om het testproces zorgvuldig vorm te geven, de juiste testgevallen vast te leggen (zie Pol et al., 2000). Het is belangrijk om te beseffen dat met testen wel de aanwezigheid van fouten/problemen kan worden aangetoond, maar nooit de afwezigheid. Omdat we vrijwel nooit alle toestanden van het programma kunnen testen, verkrijgen we niet de garantie dat een programma absoluut zonder fouten is. Naast functionaliteit zijn er ook andere dynamische eigenschappen die kunnen worden gemeten: – Performance: hoe snel komt het programma met een reactie? – Belasting: in hoeverre belast het draaien van het programma de hardware (processorcapaciteit, geheugencapaciteit, bandbreedte van het netwerk)? – Beschikbaarheid: op welke momenten is het programma (niet) beschikbaar voor gebruikers? – Incidenten: hoeveel klachten, vragen, suggesties worden door gebruikers en beheerders gemeld? Performance en belasting kunnen zowel gemeten worden in een testomgeving als in de productieomgeving (gebruikssituatie). Alleen in het laatste geval zijn de uitkomsten echt realistisch. Hierbij kunnen ‘harde’ data worden gemeten, zoals responsetijden en geheugenbeslag (bytes). Het meten van deze grootheden gebeurt vaak met behulp van specifieke systeemsoftware. De beschikbaarheid kan alleen gemeten worden in de gebruiksfase. In feite komt dit neer op het meten van tijdsintervallen waarin het programma wel of niet beschikbaar is voor de gebruikers. Dit kan vrij eenvoudig geautomatiseerd gemeten worden, maar in de praktijk wordt het vaak handmatig vastgelegd. Binnen meer professioneel ingerichte organisaties worden tijdens de gebruiksfase incidenten geregistreerd, bijvoorbeeld door een service desk. Het aantal en de zwaarte van de incidenten zegt iets over de kwaliteit van het pro-

17

een grijs gat

gramma. Het registreren en afhandelen van incidenten vindt zowel handmatig als geautomatiseerd plaats. Sinds jaar en dag wordt er ook gemeten aan statische eigenschappen van software, door het inspecteren van programmacode en documentatie. Bij de programmacode kunnen eigenschappen worden gemeten als omvang, structuur, complexiteit en kwaliteit. Bij documentatie is het minder duidelijk wat er te meten is. Volledigheid en actualiteit zijn binnen zekere grenzen objectief vast te stellen; bij inhoudelijke kwaliteit wordt dat lastiger. Omvang programmacode Het is verrassend om te zien hoeveel meeteenheden er zijn om de omvang van programmacode in uit te drukken. Waar in de fysieke wereld een lengtemaat als de meter een onbetwist uitgangspunt is om de omvang van een object te bepalen, zien we in de virtuele wereld van de software verschillende meeteenheden die gebaseerd zijn op verschillende uitgangspunten. Zo kennen we de volgende meeteenheden: – Bytes: het aantal bytes dat een programma in een geheugen in beslag neemt. In de begintijd van de computer was geheugen een schaars goed. De omvang van een programma uitgedrukt in bytes was in die tijd dan ook een belangrijk item. Tegenwoordig is geheugen in (bijna) onbeperkte mate beschikbaar en speelt deze eenheid in de meeste gevallen een ondergeschikte rol. De omvang in bytes wordt gemeten met behulp van systeemsoftware. – Regels code: een programma is opgebouwd uit regels. Het lijkt dan ook voor de hand te liggen om de omvang van een programma uit te drukken in het aantal regels. Echter, er is een aantal complicerende factoren. Ieder programma bevat (als het goed is) regels met commentaar en lege regels. Tellen deze (voor de verwerking door de computer inhoudsloze) regels ook mee voor het bepalen van de omvang? Daarnaast kan in een programma onderscheid worden gemaakt tussen wel en niet executeerbare regels code, tussen regels die wel en niet statements bevatten. We zien dan ook dat de omvang van programmacode wordt uitgedrukt in verschillende eenheden: LOC (Lines Of Code), ELOC (Executable LOC), SLOC (Statement LOC). Het tellen van regels code gebeurt vrijwel altijd geautomatiseerd, vaak met behulp van specifieke software.

18


– Functiepunten: eind jaren zeventig van de vorige eeuw is door Albrecht bij IBM een methode ontwikkeld om de omvang van een programma uit te drukken in een eenheid die zijn basis heeft in de functionaliteit die een programma biedt aan de gebruiker: de functiepunt. Op basis van een specificatie van de gewenste functionaliteit kan al in een vroeg stadium een (globale) indicatie van de omvang van het nog te bouwen programma worden vastgesteld, uitgedrukt in functiepunten. Dit geeft houvast bij het verdere verloop van het project. De functiepunt kan ook worden ingezet bij het vaststellen van de omvang van bestaande software. Het tellen van functiepunten is een complexe activiteit die gebonden is aan een omvangrijke verzameling van telrichtlijnen (NESMA, 2004). De striktheid van de telrichtlijnen probeert te garanderen dat verschillende tellers bij het bepalen van de omvang van een programma op eenzelfde aantal functiepunten uitkomen. De telmethode is niet te automatiseren. Soms wordt de omvang in functiepunten van bestaande software bepaald door een relatie te leggen met het aantal regels code. Er bestaan tabellen die voor vrijwel alle gangbare programmeertalen het aantal regels code per functiepunt aangeven. Deze tabellen zijn gebaseerd op ervaringscijfers uit het verleden. Die methode, ‘backfiring’ genaamd, geldt als zeer onbetrouwbaar. Het grote voordeel ervan is het feit dat er geautomatiseerd mee geteld kan worden: het aantal regels code is geautomatiseerd te bepalen, via combinatie met een tabel met ervaringscijfers is direct het aantal functiepunten te bepalen. Structuur programmacode De structuur van programmatuur kan gemeten worden aan de hand van de begrippen ‘modulariteit’, ‘koppeling’ en ‘cohesie’. Programmatuur is doorgaans opgebouwd uit een aantal aparte modules die elkaar aanroepen, elkaars data gebruiken. Deze relaties kunnen in kaart worden gebracht. Daarmee ontstaat een gerichte graaf, met modules als knopen en relaties (‘roept aan’, ‘wordt aangeroepen door’, ‘maakt gebruik van’) als gerichte verbindingen tussen de knopen. Metrieken uit de grafentheorie, zoals de omvang van de graaf, de diepte, de breedte, het aantal ingaande en uitgaande verbindingen, de verhouding knopen/verbindingen, kunnen gebruikt worden om de structuur van de programmatuur kwantitatief in kaart te brengen.

19

een grijs gat

De wereld van het object-georiënteerd programmeren kent een specifieke set van zes structuurmetrieken die bekendstaat onder de naam ‘Chidamber Kemerer Metrics Suite’ (Chidamber, Kemerer, 1994). Ieder van de metrieken levert een getal. Aan de hand van die getallen kan de kwaliteit van een programma beoordeeld worden. Structuurmetrieken zijn doorgaans goed op geautomatiseerde wijze te bepalen (met tools). Complexiteit programmacode Het aantal bytes, regels code of functiepunten zegt niet direct iets over hoe complex de software in elkaar steekt. Om meer inzicht te krijgen op dit punt is in het verleden een aantal complexiteitsmetrieken ontwikkeld. De bekendste is de cyclometrische complexiteit van McCabe (McCabe, 1976). Deze metriek telt in essentie niets meer dan het aantal verschillende executiepaden binnen de code. Daarmee is de cyclometrische complexiteit goed te bepalen met een tool. Programma’s met een hoge McCabe-complexiteit zijn doorgaans moeilijk te begrijpen en daarmee moeilijk te onderhouden. Deze metriek speelt dan ook een belangrijke rol bij het vaststellen van de onderhoudbaarheid van code. Kwaliteit programmacode Onder deze noemer valt een groot aantal aspecten: gebruik commentaar, programma lay-out, gebruik naamgeving, correct gebruik taalconstructies, etc. Er zijn boeken over volgeschreven (zie bijv. McConnel, 2004; Spinellis, 2006). Het meten van deze aspecten is doorgaans lastig: er zijn geen eenduidige meetvoorschriften en normen, de meetresultaten zijn subjectief. Met het gebruik van checklists met concrete aandachtspunten kan zo goed als mogelijk geprobeerd worden deze bezwaren te ondervangen. Volledigheid documentatie Bij een kwalitatief goed softwareproduct hoort documentatie. Deze stelregel wordt breed onderschreven binnen het vakgebied der informatici. Een gebruikershandleiding ter ondersteuning van de gebruikers, specificaties en ontwerpdocumenten ten behoeve van het bouwen en onderhouden van de software, installatiehandleidingen ten behoeve van beheer: het moet er allemaal zijn. In de praktijk ontbreekt vaak een deel van deze documenten. Met een checklist kan eenvoudig ‘gemeten’ worden welke documenten aanwezig zijn en welke ontbreken.

20


Actualiteit documentatie In de gebruiksfase worden doorgaans tal van grote en kleine veranderingen in de software doorgevoerd. Deze veranderingen moeten ook verwerkt worden in de bijbehorende documentatie. Om tal van redenen wordt dit vaak achterwege gelaten. Daarmee wordt de documentatie steeds minder actueel: de beschrijving van het softwareproduct is steeds minder correct. Zeker bij grotere ontwikkelprojecten treedt het verouderen van documentatie vaak al op tijdens het project: de in een beginstadium van het project geschreven documenten worden niet aangepast als er later wijzigingen worden doorgevoerd. Daarmee is de documentatie al verouderd op het moment van opleveren. Het meten van de discrepantie tussen documentatie en programmacode is lastig, omdat er geen formele relatie tussen beide bestaat. Door de laatste datum van de wijziging van het document te vergelijken met die van de programmacode kan indirect het niet meer actueel zijn van documentatie worden vastgesteld. Inhoudelijke kwaliteit documentatie De kwaliteit van een document hangt nauw samen met een aantal aspecten, te weten een vaste en duidelijke opzet met inhoudsopgave en inhoudsbeschrijving, consistentie (bevat het document geen tegenspraken) en leesbaarheid (taalgebruik, goede afwisseling van tekst en grafische informatie). Deze zaken kunnen aan de hand van checklists worden beoordeeld (zie hierover verder Van der Pols, 2003). Opvallend is dat er in de literatuur weinig aandacht is voor metrieken op het terrein van documentatie. In de meeste gevallen bestaat documentatie uit een verzameling losse documenten. Meten aan die verzameling is handwerk, al kan een enkel aspect (actualiteit) in principe op geautomatiseerde wijze bepaald worden. Soms wordt documentatie opgeslagen in een apart tool, bijvoorbeeld Enterprise Architect, Oracle Designer. Binnen zo’n tool worden tal van items en hun onderlinge relaties vastgelegd: entiteiten (gegevens), functionaliteiten, user interfaces (schermen), etc. Daarmee wordt het mogelijk om snel inzicht te krijgen in aantallen voor wat betreft items en relaties daartussen. Meten aan het proces Binnen de levenscyclus van een softwareproduct zijn twee fasen te onderscheiden: de ontwikkelfase, waarin het product ontworpen, gebouwd en getest

21

een grijs gat

wordt, en de gebruiksfase, waarin het product gebruikt en beheerd wordt. Van oudsher wordt er zowel binnen de ontwikkelfase als binnen de gebruiksfase veel aandacht besteed aan het meten van de gerealiseerde productiviteit. Dat betekent dat gemeten wordt wat er geproduceerd wordt, en in welke tijd. Wat er geproduceerd wordt, wordt vaak gemeten via de omvang van het softwareproduct. Daarbij moet een beslissing worden genomen over hoe de omvang zal worden gemeten: in bytes, in regels code of in functiepunten. Vaak wordt een eenheid als LOC verkozen, omdat het aantal regels code eenvoudig geautomatiseerd te meten is. Daarnaast moet de bestede tijd gemeten worden. Dit is minder eenvoudig dan het lijkt. Punten als het wel of niet laten meetellen van werkoverleg, koffiepauzes en lunches spelen daarbij een rol. Ook moet een keuze gemaakt worden betreffende het wel of niet laten meetellen van de tijdsbesteding van niet direct productieve medewerkers, zoals managers en testers. Tijdregistratie wordt vrijwel altijd overgelaten aan de medewerkers zelf. Soms wordt gevraagd een spreadsheet bij te houden, soms wordt een meer geavanceerd tool beschikbaar gesteld, waarin per medewerker vastgelegd is op welke activiteiten uren geschreven kunnen worden. In de gebruiksfase wordt de productiviteit van de beheerders gemeten. Daarbij wordt de tijdsduur gemeten van activiteiten zoals het oplossen van incidenten en het doorvoeren van gevraagde wijzigingen. In tabel 3 staat een samenvatting van de in deze paragraaf beschreven meetbare eigenschappen van het product software en het proces van ontwikkelen en gebruiken van software, met meeteenheden en een indicatie of de eigenschap handmatig (H) dan wel geautomatiseerd (A) te meten is.

22


Eigenschap

Meeteenheid

H/A

aantal testgevallen OK/NOK sec

H (A) A

Dynamische eigenschappen product functionaliteit responsetijd capaciteitsbeslag

(m)sec CPU gebruik

A

Mb/Gb/Tb geheugengebruik

A

beschikbaarheid

sec, min, uren

A (H)

incidenten

aantal, zwaarte, per tijdseenheid

H, A

Statische eigenschappen product - code omvang

bytes

A

LOC – ELOC – SLOC functiepunten

A H (A)

structuur

< niet standaard >

A

complexiteit

aantal executiepaden

A

kwaliteit code

‘checklistscore’

H

Statische eigenschappen product - documentatie volledigheid


H

actualiteit

timestamps, ‘checklistscore’

H

inhoudelijke kwaliteit


H

(delen van) uren

H

Eigenschappen proces tijdsbesteding activiteiten

Tabel 3. Meetbare eigenschappen van software, product en proces. Het onderwerp van mijn lectoraat is ‘softwarekwaliteit’. Een interessante vraag is nu welke rol de genoemde meetbare eigenschappen spelen in de theorie rond de kwaliteit van software en de daarmee verbonden processen.

23

een grijs gat

Softwarekwaliteit Er is en wordt veel geschreven over het begrip ‘softwarekwaliteit’. Oudere definities van het begrip (geciteerd in Kan, 2003) gaan uit van ‘conformance to requirements’ en ‘fitness for use’. Let op het subtiele verschil tussen deze twee definities: bij slechte of onvolledige specificaties (requirements) kan een product van goede kwaliteit zijn volgens de eerste definitie, maar compleet waardeloos zijn volgens de tweede definitie. Volgens de huidige theorie spelen bij de kwaliteit van software drie factoren een rol: product, proces en resources (Heemstra et al., 2001; Kan, 2003). Daarbij wordt onderscheid gemaakt tussen de twee hoofdfasen in de levenscyclus van een programma: de ontwikkelfase en de gebruiksfase. Bovendien zijn er verschillende stakeholders betrokken bij de software: gebruikers, opdrachtgevers, ontwikkelaars, beheerders, verkopers, etc. Allemaal hebben ze hun eigen wensen of eisen. Daarmee wordt ‘softwarekwaliteit’ een begrip dat vanuit verschillende invalshoeken benaderd kan worden. Het product Een aantal kwaliteitsaspecten voor een softwareproduct is gebundeld in een ISO-standaard, bekend onder de naam ISO/IEC 9126 (ISO, 2001). In deze standaard worden ruim twintig verschillende kwaliteitsattributen benoemd, gegroepeerd in een zestal rubrieken (zie tabel 4). ISO/IEC 9126 Product Quality 1. Functionality

2. Reliability

3. Usability

1.1 Suitability

2.1 Maturity

3.1 Understandability

1.2 Accuracy

2.2 Fault tolerance

3.2 Learnability

1.3 Interoperability

2.3 Recoverability

1.4 Security

3.3 Operability 3.4 Attractiveness

1.5 Compliance 4. Efficiency 4.1 Time behaviour 4.2 Resource utilisation

5. Maintainability 5.1 Analysability 5.2 Changeability

6. Portability 6.1 Adaptability 6.2 Installability

5.3 Stability

6.3 Co-existence

5.4 Testability

6.4 Replaceability

Tabel 4. ISO/IEC 9126 Softwareproduct kwaliteitsaspecten. 24


De attributen hebben zowel betrekking op de dynamische kwaliteit van het product als op de statische kwaliteit ervan. Voor ieder attribuut wordt binnen de standaard een nadere omschrijving gegeven, maar die is niet ‘geoperationaliseerd’, dat wil zeggen: er wordt niet aangegeven op welke manier via meting kan worden vastgesteld of het product aan een van te voren gestelde norm voldoet. Er bestaat dus niet een heldere relatie tussen de genoemde attributen en de eerder in deze openbare les behandelde meetbare eigenschappen van een product. Daarmee kan de standaard helaas niet direct worden ingezet voor een beoordeling van de kwaliteit van een product. Een enigszins andere benadering van de kwaliteit van een softwareproduct is te vinden in Van der Pols, 2003. In dit boek wordt onderscheid gemaakt tussen functionele kwaliteit, technische kwaliteit en exploitatiekwaliteit. Daarmee wordt een opdeling van kwaliteitsaspecten gemaakt naar drie verschillende stakeholders: de gebruiker/opdrachtgever (functionele kwaliteit), de bouwer/applicatiebeheerder (technische kwaliteit) en de technisch beheerder (exploitatiekwaliteit). Voor elk van de aandachtsgebieden is een aantal kwaliteitsaspecten benoemd (zie tabel 5). Opvallend is de expliciete aandacht voor documentatie. De kwaliteitsaspecten worden ‘gemeten’ met behulp van checklisten en, daar waar mogelijk, ondersteund met meetresultaten uit tools. In deze benadering is evenmin sprake van een directe mapping van de kwaliteitsaspecten op de eerdergenoemde meetbare eigenschappen van programmatuur en documentatie. Functionele kwaliteit

Technische kwaliteit

Exploitatiekwaliteit

Informatiekwaliteit

Vorm documentatie

Doelmatigheid

Fit

Inhoud documentatie

Bedrijfszekerheid

Ergonomie

Vorm programmatuur

Beheersbaarheid

Inhoud programmatuur

Continuïteit

Tabel 5. Softwareproduct kwaliteitsaspecten volgens Van der Pols. Los van deze overkoepelende kwaliteitsmodellen zijn er in het verleden talrijke meer specifieke metrieken gedefinieerd, waarmee de kwaliteit van een product kan worden bepaald. Daarbij wordt onderscheid gemaakt tussen interne en externe productattributen. In de eerste categorie vallen de direct meetbare eigenschappen, als omvang en structuur. In de tweede categorie vallen veelge25

een grijs gat

bruikte metrieken die te maken hebben met het optreden van incidenten: het aantal incidenten dat optreedt in een bepaalde tijdsperiode, de gemiddelde tijd tussen twee incidenten (MTBF = Mean Time Between Failures) en de gemiddelde tijd om een fout te herstellen (MTTR = Mean Time To Repair). Voor deze metrieken is het noodzakelijk dat de beschikbaarheid van het softwareproduct wordt gemeten en incidenten worden geregistreerd. Op basis van gemeten waarden is het ook mogelijk om op statistisch verantwoorde wijze voorspellingen te doen over de betrouwbaarheid van een softwareproduct in de toekomst. Het is duidelijk dat er een statistische relatie zal bestaan tussen het aantal geregistreerde incidenten in het nabije verleden en het aantal te verwachten incidenten in de toekomst. Maar ook andere gemeten grootheden als omvang, complexiteit en structuurmetrieken kunnen worden gebruikt als input voor modellen die uitspraken doen over de betrouwbaarheid en onderhoudbaarheid van een product in de toekomst. Op basis van dit soort berekeningen kan bijvoorbeeld de omvang van de toekomstige beheerinspanning worden begroot. Het proces De kwaliteit van het proces van ontwerpen, bouwen en testen van software is al lange tijd een punt van aandacht binnen de software engineering. Er zijn tal van procesmodellen en methodieken ontwikkeld die de activiteiten in deze fase nauwkeurig benoemen, inclusief de onderlinge samenhang. Een van de oudste is de watervalmethode (Boehm, 1976). Bij deze methode wordt een scherp onderscheid gemaakt tussen de verschillende stappen in de softwarelife cycle, van het opstellen van requirements tot en met het gebruiken van het product. Iedere stap wordt volledig doorlopen voordat een volgende stap wordt gezet. Een belangrijk argument daarbij is de kostprijs van foutherstel: hoe verder in de ontwikkeling, hoe duurder het herstellen van een fout. Methoden van een latere datum, zoals DSDM, XP en RUP, hebben een meer iteratief karakter: in een aantal opeenvolgende slagen (iteraties) wordt telkens opnieuw een aantal ontwikkelstappen doorlopen, met een toenemende productkwaliteit als resultaat. In het wetenschappelijke bedrijf zou je mogen verwachten dat de keuze voor een specifieke ontwikkelmethode empirisch onderbouwd wordt met bijvoorbeeld het expliciet meten van de kwaliteit van de opgeleverde producten, de productiviteit van de medewerkers, de effectiviteit van de ondersteunende tools. Voor zover mijn waarneming strekt, is dit maar in beperkte mate ge-

26


beurd. Daarmee krijgen de discussies over de voors en tegens van een methode meer het karakter van een geloofsstrijd dan van een wetenschappelijk debat. Specifieke aandacht voor de processen rond het beheren en onderhouden van software is van recenter datum. Er wordt onderscheid gemaakt tussen technisch beheer, applicatief beheer en functioneel beheer (Delen en Looijen, 1992). Voor elk van deze terreinen bestaat een procesframework: ITIL voor technisch beheer (Janssen, 2002), ASL voor applicatiebeheer (Van der Pols, 2001), BiSL voor functioneel beheer (Van der Pols et al., 2005). Met een procesframework wordt een aantal processen benoemd en hun onderlinge samenhang, maar wordt de feitelijke invulling overgelaten aan de werkvloer. Die invulling kan worden ontleend aan zogenaamde ‘best practices’: voorbeelden uit de praktijk. De genoemde procesframeworks bevatten geen (beschrijvingen van) expliciete meetprocessen. Het meten van de kwaliteit en effectiviteit van de ingerichte processen blijft daarmee helaas onderbelicht. Aparte aandacht verdient CMMi als proceskwaliteitsmodel (CMMI Product Team, 2006). CMMi vindt zijn oorsprong in het Capability Maturity Model (CMM). Dit model is eind jaren tachtig van de vorige eeuw ontwikkeld op het Software Engineering Institute van de Carnegie Mellon University. Binnen CMM worden, net als de eerdergenoemde procesframeworks, een aantal processen (Key Process Area’s, KPA’s) met doelen en eigenschappen benoemd, en worden deze processen gerangschikt in een aantal volwassenheidsniveaus (maturity levels). Er zijn vijf levels gedefinieerd, van ‘primitive’ (level 1) tot ‘optimizing’ (level 5). Nauwkeurig is omschreven welke KPA’s ingericht moeten zijn om als organisatie op niveau n (n = 2..5) te functioneren. CMMi (CMM integration) is een uitbouw van CMM, waarin de KPA’s worden onderverdeeld naar een viertal werkterreinen: Project Management, Process Management, Engineering en Support. CMMi kent dezelfde vijf maturity levels als CMM, alleen biedt CMMi twee mogelijkheden om in niveau te stijgen: ‘staged’ (voor alle werkterreinen tegelijk) of ‘continuous’ (per werkterrein). Op CMMi level 2 bevindt zich het Measurement and Analysis-proces. Dat geeft aan dat al op level 2 een organisatie geacht wordt een meetproces ingericht te hebben en zich bezig te houden met de analyse van meetdata. De procesbeschrijving geeft niet concreet aan wat er gemeten moet worden, maar

27

een grijs gat

hiervoor worden wel suggesties gedaan. Verder wordt er als eis gesteld dat er zorgvuldig gemeten en geanalyseerd wordt. CMM(i) kan beschouwd worden als een ruwe meetschaal voor de kwaliteit van de processen van een ICT-organisatie. Het vaststellen van een level gebeurt door een externe, daartoe bevoegde partij. De meetprocessen die daarbij een rol spelen, zijn vrij nauwkeurig vastgelegd. In de VS wordt door een opdrachtgever vaak een bepaald CMM(i)-niveau van een ICT-leverancier vereist. In Nederland is dat nog nauwelijks het geval. Wel zien we CMM(i) dichterbij komen via offshoring: veel Indiase bedrijven zijn CMM(i)-gecertificeerd, vaak op een hoog niveau (4 of 5). Dit legt bij de Nederlandse partij die het Indiase bedrijf aanstuurt op zijn minst de morele druk om aantoonbaar op een vergelijkbaar niveau te acteren. Het gebruik van procesframeworks, in combinatie met een hoge CMM(i)-certificering, is geen garantie voor kwalitatief goede software. Het moet gezien worden als een waarborg dat er professioneel gewerkt wordt. Maar, ook onder professionele omstandigheden kan er slechte software gemaakt worden! De voor de hand liggende claim is dat de kans op ellende kleiner is dan bij werken onder niet-professionele omstandigheden. Resources Onder deze noemer vallen zowel mensen als ondersteunende tools. Ontwerpers en bouwers van hoge kwaliteit vormen, zoals in alle engineering disciplines, een noodzakelijke voorwaarde om een kwalitatief goed product te kunnen ontwikkelen. Daarnaast bepaalt de kwaliteit van de medewerkers uiteraard voor een belangrijk deel de productiviteit, en daarmee de kosten van ontwikkelen beheerprocessen. Het meten van kwaliteit van medewerkers kan gebeuren op basis van hun opleiding en ervaring. Tegenwoordig spelen ‘verworven competenties’ een belangrijke rol bij het bepalen van het opleidingsniveau. Voor het meten van opleiding, ervaring en competenties kunnen ordinale schalen worden gebruikt, waarbij alleen de volgorde van de schaalitems iets zegt. Een opleidingsschaal loopt dan bijvoorbeeld van ‘geen opleiding’ tot ‘universitair opgeleid’ en een ervaringsschaal van ‘geen ervaring’ tot ‘zeer ervaren’. De ICT’er van nu staan allerlei hulpmiddelen ter beschikking. Functionele specificaties en ontwerpen worden vaak niet meer opgesteld in een teksteditor, maar in een omgeving die direct een structuur in de specificatie aanbrengt. Daarmee ontstaat een model van waaruit soms al een deel van de programmacode automatisch gegenereerd kan worden. Op een meer basaal niveau

28


worden gegevensafhandeling (lezen uit en schrijven in een database), functionaliteit (zoeken, sorteren) en interactie met de gebruiker (velden en knoppen op een scherm) niet meer door de programmeur zelf geprogrammeerd, maar aangeleverd binnen een programmaframework. Het is dan de taak van de programmeur om uit deze componenten een werkend systeem samen te stellen. Daarnaast bestaan er hulpmiddelen voor het testen en debuggen van code, het uitvoeren van versiebeheer en configuratiebeheer, etc. Voor het categoriseren van ondersteunende tooling bestaan ordinale meetschalen die lopen van ‘basaal ondersteunend’ tot ‘volledige ondersteuning proces’.

29

een grijs gat

Empirische software engineering Om systematisch de kwaliteit van product, proces en resources te kunnen meten, moet een meetproces opgezet worden. Binnen dit proces moeten data verzameld worden en moeten deze data geanalyseerd worden. In het verleden zijn er tal van grootschalige en kleinschalige meetprogramma’s opgezet en uitgevoerd. Toch lijkt de indruk gerechtvaardigd dat het inrichten van een meetproces niet tot de standaardactiviteiten van de doorsnee ICT-organisatie behoort. Voor de kwaliteit van het op te leveren softwareproduct en de kwaliteit van de daarmee verbonden ontwikkelen beheerprocessen is het van groot belang dat er structureel gemeten en geanalyseerd wordt. In mijn ogen verdient het de voorkeur dit niet in handen te leggen van een afzonderlijke kwaliteitsafdeling, maar van de direct belanghebbenden (stakeholders): gebruikers, ontwerpers, projectmanagers en beheerders. Dat wil zeggen dat een opdrachtgever/ projectmanager de productiviteit van een team meet, dat een gebruiker de dynamische kwaliteit van het op te leveren product meet, dat een beheerder de statische kwaliteit van de te beheren code en documentatie meet, etc. De momenten van meten moeten goed gekozen worden. Productiviteit kan doorlopend (per week, per maand) gemeten worden. De dynamische kwaliteit van een product kan het beste gemeten worden op welgekozen momenten, als bijvoorbeeld een iteratie is voltooid. Dat geldt ook voor de statische kwaliteit: tijdens het bouwen bevat de code vaak allerlei ‘bouwmateriaal’ (stubs, testen debugcode) die de meetresultaten op onvoorspelbare wijze kunnen beïnvloeden. Een uitwerking van dit standpunt is te vinden in Brunekreef, 2007. Het meten moet vervlochten worden met de overige activiteiten die binnen een ICT-organisatie uitgevoerd worden. Gericht meten is een noodzakelijke voorwaarde om de kwaliteit van product en proces te verhogen. Dit besef moet groeien, zowel bij het management als op de werkvloer. In mijn ogen is het een cruciaal onderdeel van de professionalisering van het ICT werkveld.

30


Het lectoraat Softwarekwaliteit Het meten aan software is dus niet een onderwerp dat naast het proces van ontwikkelen en beheren van software staat. Dit levert voor het lectoraat zowel een onderzoeksrichting op als een visie op het onderwijzen van softwaremetrieken. Onderzoek Binnen de kenniskring – een groep van enkele docenten en de lector – zijn we nu ruim een jaar bezig met het onderwerp softwaremetrieken. Na een periode van inlezen in het onderwerp zijn we begonnen met een onderzoek naar de kwaliteit van de beschikbare tools voor het meten van metrieken. Daarnaast verdiepen we ons in ‘educational’ software metrics. Waar het primaire doel van gewone softwaremetrieken ligt in het vaststellen van de kwaliteit van softwareproducten en het proces van ontwikkelen en beheren, zijn educational software metrics vooral gericht op het ondersteunen van software engineering-onderwijs. Of dit leidt tot andere metrieken, dan wel een ander gebruik van metrieken, is een interessante onderzoeksvraag! In samenwerking met de Universiteit van Amsterdam en Getronics PinkRoccade heeft het lectoraat een subsidieaanvraag ingediend bij NWO voor het doen van onderzoek in het kader van het Jacquard programma 2008. Het onderwerp van deze subsidieronde is SaaS: Software as a Service. Binnen SaaS worden softwarediensten aangeboden en afgenomen op een sterk gestandaardiseerde manier. Daarbij valt van alles te meten, zowel op het vlak van performance als op dat van het feitelijk gebruik (waarop wordt een afnemer afgerekend?). Vanuit het lectoraat zal een onderzoeker met deze meetvragen aan de slag gaan, tenminste, als de aanvraag wordt goedgekeurd. De aanvraag is door de eerste selectieronde gekomen; een tweede en laatste ronde vindt plaats begin volgend jaar. Als je iemand opvolgt, dan krijg je te maken met zijn erfenis. Daar heb ik tot op de dag van vandaag plezier van. In deze openbare les wil ik twee parels uit de erfenis van Mark van den Brand noemen. In augustus 2005 is op zijn initiatief een junior onderzoeker, Jeroen Arnoldus, gestart met onderzoek op het terrein van softwaregeneratoren. Met gebruik van templates worden elementen uit een model (een functionele specificatie) omgezet naar stukken executeerbare code. Bij het genereren van deze code speelt het behoud van syntax-cor-

31

een grijs gat

rectheid een belangrijke rol. Met gebruik van de in de afgelopen decennia op het CWI ontwikkelde generieke taaltechnologie (Klint, 1993) is het mogelijk gebleken om het proces van syntax-safe codegeneratie concreet vorm te geven met behulp van templates (Arnoldus et al., 2007). Dit onderzoek vindt plaats in het kader van het Balance-project. Dit is een samenwerkingsverband tussen de Hogeschool van Amsterdam en het bedrijf Mattic bv uit Almere. Binnen dit project is ook een studiegroep rond softwaregeneratie gestart, met een aantal docenten van de hogeschool en Jeanot Bijpost van Mattic. In de erfenis van Mark zat ook het TISO-project. Door het aanbieden van echte dossiers uit de Nederlandse ICT-praktijk en een set van leertaken rondom deze dossiers wordt de kloof tussen theorie en praktijk overbrugd. Het project is inmiddels afgerond. De resultaten worden momenteel met succes geëxploiteerd door de Open Universiteit en de Hogeschool van Amsterdam (zie www. tisoweb.nl). We zijn bezig de mogelijkheden voor een vervolgproject te onderzoeken. Onderwijs Ik heb het eerder in deze openbare les betoogd: het meten van diverse aspecten van software (product en proces) moet een vanzelfsprekendheid worden in de softwarepraktijk. Dat betekent dat studenten die opgeleid worden voor deze praktijk al in hun opleiding die vanzelfsprekendheid moeten ervaren, moeten aanleren. Om dit te bereiken is vanuit het lectoraat een start gemaakt met de introductie van softwaremetrieken in het onderwijs. In het studiejaar 20062007 is binnen een project voor eerstejaarsstudenten een eerste set van eenvoudige productmetrieken geïntroduceerd: onder andere percentage commentaarregels, diepte klassenhiërarchie en aantal regels per methode. Studenten hebben de opdracht gekregen om deze metrieken toe te passen op de code die ze in het kader van het project produceren. Daarvoor kregen ze de beschikking over een tool. Het merendeel van de teams heeft de opdracht uitgevoerd en een rapportje geproduceerd met meetresultaten. In het studiejaar 2007-2008 wordt daarnaast in een tweedejaars-project (dus in principe voor dezelfde groep studenten) de oorspronkelijke set metrieken uitgebreid met complexere productmetrieken (functiepunten, cyclometrische complexiteit). In een later stadium van de studie zullen procesmetrieken worden geïntroduceerd. Op deze manier ontstaat een ‘software metrieken huis’ met verschillende niveaus (studiejaren). De metrieken worden niet apart onderwezen, maar geïntegreerd met het lopende onderwijs aangeboden. Op

32


deze wijze wordt een generatie studenten opgeleid waarvoor het inzetten van softwaremetrieken ten behoeve van kwaliteitsmeting en -verbetering een vanzelfsprekende zaak is. Daarmee worden de studenten beter voorbereid op een beroepspraktijk, waar deze manier van werken in het kader van professionalisering in toenemende mate als standaard zal gelden. Op dit moment worden de eerste stappen gezet in de richting van een ‘studentenkenniskring’. Op initiatief van Daan van den Berg, docent van dit instituut, is een groep studenten bezig met praktisch onderzoek aan small-world networks. Dit zijn netwerken die we onder andere terugvinden in neurologische netwerken (hersencellen). Het praktijkonderzoek van de studenten strekt zich uit tot het vaststellen van de complexiteit van de algoritmen die het gedrag van het netwerk beschrijven en het feitelijk meten van dit gedrag. De benodigde competenties van de Nederlandse informaticus staan volop ter discussie. Mijn collega Guus Delen signaleerde in zijn openbare les, uitgesproken in december 2006, dat er een verschuiving plaatsvindt in de benodigde kwalificaties (Delen, 2006). De programmeur zal gaan verdwijnen, de regisseur komt ervoor terug. Het rechttoe rechtaan programmeerwerk zal worden uitbesteed aan India. De taak van de Nederlandse informaticus verschuift naar het aansturen van dit werk: het vooraf helder en volledig formuleren van eisen (requirements) en het achteraf zorgvuldig controleren van de kwaliteit van het opgeleverde. Dit is een realistisch toekomstscenario voor grote Nederlandse bedrijven als ABN-AMRO, Shell en Philips, en voor grote Nederlandse ICT-dienstverleners als Getronics, CapGemini en Logica CMG. Maar laten we wel beseffen dat niet alle Nederlandse programmeurs bij deze bedrijven werken. Er zijn tal van software producerende bedrijven, vooral in de sector van het midden- en kleinbedrijf, waarvoor de offshore-route naar India of China niet of nauwelijks begaanbaar is. Dat betekent dat we het probleem van het maken van kwalitatief goede software (helaas?) niet kunnen exporteren naar India en dus dat we ook hier in Nederland goede programmeurs zullen moeten blijven opleiden. Ik ben dan ook niet bang dat de opleiding voor software-engineer die we binnen dit instituut kennen, opleidt tot werkeloosheid. Integendeel, ik ben ervan overtuigd dat software-engineers die zijn afgestudeerd bij ons instituut een belangrijke bijdrage zullen leveren aan de verdere ontwikkeling van de positie van Nederland als kennisland, ook op het gebied van ICT.

33

een grijs gat

Tot slot: het vakgebied ICT is niet echt populair bij de jeugd. Het aantal eerstejaars informatica hbo en wo is al een aantal jaren aan het dalen. Dit is een zorgelijke ontwikkeling, zeker nu de werkgelegenheid in de ICT stijgt. Voor we het weten zijn we voor onze ICT-expertise grotendeels afhankelijk van buitenlandse bronnen als Oost-Europa, India en China. Dit is een zeer ongewenste situatie. Het is de vraag hoe het imago van het vakgebied Informatica onder de Nederlandse jeugd verbeterd kan worden. In april van dit jaar heeft de Amsterdamse hoogleraar Paul Klint op het NIOC het motto ‘ICT inside’ gelanceerd. Op zeer veel objecten uit het dagelijks leven valt een sticker met de genoemde tekst te plakken. Daarmee kan worden aangegeven hoezeer ICT doorgedrongen is tot in de haarvaten van de maatschappij. Maar, in mijn ogen is dat niet genoeg. Het vakgebied ICT zal voor de jeugd van nu weer even uitdagend moeten worden als 10 tot 20 jaar geleden, toen de studentenaantallen vele malen hoger lagen. Om dat te bereiken zal een inhoudelijke aansluiting tot stand gebracht moeten worden tussen de ICT inside en al die spannende interactieve multimediaproducten waarop de stikker te plakken valt. Dat vereist aanpassingen van de informatica-opleidingen, die wellicht te lang een koers gevaren hebben die werd aangegeven door een oud kompas. Hier ligt een belangrijke uitdaging voor het Instituut voor Informatica. Het instituut is bezig op te gaan in een cluster met onder andere de instituten voor Interactieve Media en Media en Informatie Management. Samen met deze instituten, waar die uitdagende buitenwereld met al de leuke toepassingen van ‘ICT inside’ vooropstaat, kan een nieuwe koers naar de toekomst uitgezet worden. Ik beschouw het als een voorrecht om daaraan een steentje te mogen bijdragen.

34


Dankwoord Veel plezier beleef ik aan de samenwerking binnen de kenniskring. Mijn dank gaat uit naar de (ex-)leden van de kenniskring Softwarekwaliteit, Ahmed Nait Aicha, Richard de Koning, Jan Derriks en Slobodanka Dzebric, voor hun inspirerende bijdragen. Jeroen Arnoldus laat zien dat wetenschappelijk onderzoek op een hbo-instelling kan gedijen. Ik dank hem voor zijn inzet, het niet-aflatende enthousiasme waarmee hij complexe problemen te lijf gaat. Bij de begeleiding van Jeroen speelt mijn voorganger, Mark van den Brand, een belangrijke rol. Mark dank ik voor zijn inspanningen in dezen, en voor de in deze openbare les genoemde erfenis die hij voor mij heeft achtergelaten. De medewerkers van het instituut dank ik voor hun belangstelling en collegialiteit. Marjan Freriks, tot 1 januari 2007 directeur van het Instituut voor Informatica, was voor mij een belangrijke steunpilaar in de eerste periode van het lectoraat, vanaf juni 2006. Mijn dank daarvoor. Emilie Randoe, de opvolgster van Marjan, en mijn collega-lector Guus Delen hebben een concept van deze tekst gelezen en van commentaar voorzien. Mijn dank daarvoor. Ik dank het College van Bestuur voor het continueren van het lectoraat Softwarekwaliteit. Dank aan Wouter Bouw en Bert Zonneveld voor het organisatorische werk dat zij verzet hebben rond deze openbare les. Een bijzonder woord van dank geldt mijn directe collega’s van Getronics PinkRoccade. Zij geven mij de ruimte om 50% afwezig te zijn, en tegelijkertijd geven ze mij het gevoel er toch 100% bij te horen. Mijn partner Ellie Streppel dank ik voor haar kritische commentaar op deze tekst. Haar werkveld, het kwaliteitsdenken in de zorg, levert zonder meer een interessante invalshoek om te kijken naar softwarekwaliteit.

35

een grijs gat

Referenties Arnoldus, J., Bijpost, J.W., Brand, M.G.J. van den, ‘Repleo, A Syntax-Safe Template Engine’ [geaccepteerd voor presentatie op GPCE 2007] Blaauw, G.A., Door de vingers zien, Inaugurele rede, 1966. Opgenomen in Vervoort, 2006. Boehm, B. ‘Software Engineering’, in: IEEE Transactions on Computers, Vol. C-25. p. 1226-1241, 1976 Boehm, B., Software Engineering Economics. Prentice Hall, 1981 Brunekreef, J., ‘Alleen softwarekwaliteit door prominentere rol beheerder’, in: Automatisering Gids, 2 februari 2007 Centraal Bureau voor de Statistiek (CBS), De digitale economie 2006. Statistische Bijlage, Voorburg, 2006 Chidamber, S.R., Kemerer, C.F., A Metrics Suite for Object Oriented Design, in: IEEE Transactions on Software Engineering, 20(6), p. 476-498, 1994 CMMI Product Team, CMMI for Development, Version 1.2. Technical Report CMU/SEI-2006-TR008, Software Engineering Institute, Carnegie Mellon University, 2006 Cooper, A., The Inmates Are Running The Asylum. Sams Publishing, 2004 Delen, G.P.A.J., A Global Perspective on Sourcing. Openbare les, Amsterdam: HvA Publicaties, 2006 Delen, G.P.A.J., Looijen, M., Beheer van informatievoorziening. SDM-reeks, Rijswijk: Cap Gemini Publishing, 1992 Dijksterhuis, E.J., De mechanisering van het wereldbeeld. Amsterdam: Meulenhof, 1950 Fenton, N.E., Pfleeger, S.L., Software Metrics, A Rigorous & Practical Approach. Boston: PWS Publishing Company, 1997 [tweede druk] Heemstra, F.J., Kusters, R.J., Trienekens, J.J.M., Softwarekwaliteit – Op weg naar betere software. Den Haag: Ten Hagen & Stam, 2001 International Organization for Standardization, Software Engineering – Product Quality – Part 1: Quality Model. Genève, 2001 Janssen, P., IT-Service Management volgens ITIL. Amsterdam: Pearson Education, 2002 Jones, C., Applied Software Measurement, New York: McGrawHill, 1991 Kan, S.H., Metrics and Models in Software Quality Engineering. Boston: Addison Wesley, 2003 Klint, P., ‘A Meta-Environment for Generating Programming Environments’, in: ACM Transactions on Software Engineering and Methodology, vol. 2, nr. 2, p. 176-201 McCabe, T., ‘A Software Complexity Measure’, in: IEEE Transactions on Software Engineering SE-2 (4), p. 308-320, 1976 McConnel, S., Code Complete. Redmond: Microsoft Press, 2004 NESMA, Definities en telrichtlijnen voor de toepassing van functiepuntanalyse, versie 2.2. Zeist: NESMA, 2004 Parnas, D.L., ‘Software Aspects of Strategic Defense Systems’, in: Communications of the ACM, vol. 28, nr. 12, p. 1326-1335 Pol, M., Teunissen, R., Van Veenendaal, E., Testen volgensTMap®. Den Bosch: Tutein Nolthenius, 2000 Pols, R. van der, ASL: een framework voor applicatiebeheer. Den Haag: Ten Hagen & Stam, 2001 Pols, R. van der, Nieuwe informatievoorziening – Informatieplanning en ICT in de 21ste eeuw. Den Haag: Academic Service, 2003 36


Pols, R. van der, Donatz, R., Outvorst, F. van, BiSL Een framework voor functioneel beheer en informatiemanagement. Zaltbommel: Van Haren Publishing, 2005 Rubin, H.A., ‘Software process maturity: measuring its impact on productivity and quality’, in: Proceedings of the First International Software Metrics Symposium. IEEE Computer Society Press, p. 28-39, 1993 Spinellis, D., Code Quality, The Open Source Perspective. Boston: Addison Wesley, 2006 Vervoort, W.A., Informatica aan de THT. Enschede: Universiteit Twente, 2006

37

een grijs gat

Curriculum vitae Jacob Brunekreef werd geboren in Utrecht, in 1951. Na een HBS-B opleiding studeerde hij elektrotechniek aan de toenmalige Technische Hogeschool Twente, met als specialisaties Programmatuur en Digitale Techniek. Daarmee ontving hij in feite een informatica-opleiding avant la lettre. Na zijn afstuderen in 1975 was hij tien jaar werkzaam in het middelbaar onderwijs, als leraar natuurkunde en wiskunde. Begin jaren tachtig nam hij deel aan het ‘Honderd scholen project’, het eerste ICT-onderwijsproject vanuit de Nederlandse overheid. In 1985 maakte hij de overstap naar de Universiteit van Amsterdam. Daar was hij nauw betrokken bij het vormgeven van met name het programmeeronderwijs voor eerstejaars. In 1995 promoveerde hij aan de UvA, bij prof. dr. J.A. Bergstra, op een proefschrift over modulaire algebraïsche specificatie van communicatieprotocollen. In 1999 maakte hij de overstap naar het bedrijfsleven. Na een kort avontuur bij een start-up bedrijf zette hij zijn loopbaan voort bij PinkRoccade, tegenwoordig Getronics PinkRoccade. Tot op heden is hij daar werkzaam. Hij houdt zich bezig met consultancy op het terrein van systeemvernieuwing en procesverbetering. Per 1 juni 2006 is Jacob Brunekreef benoemd tot lector Softwarekwaliteit aan het Instituut voor Informatica van de Hogeschool van Amsterdam.

38


HvA Publicaties is een imprint van Amsterdam University Press. Deze uitgave is tot stand gekomen onder auspiciën van de Hogeschool van Amsterdam.

Omslagillustratie Ruimte zonder geheugen, Marapi Obermayer, 1991 Kunstcollectie Hogeschool van Amsterdam Vormgeving omslag Kok Korpershoek, Amsterdam Vormgeving binnenwerk Marise Knegtmans, Amsterdam Opmaak binnenwerk JAPES, Amsterdam ISBN 978 90 5629 503 5 © HvA Publicaties, Amsterdam, 2007 Alle rechten voorbehouden. Niets uit deze uitgave mag worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voorzover het maken van kopieën uit deze uitgave is toegestaan op grond van artikel 16B Auteurswet 1912 jº het Besluit van 20 juni 1974, Stb. 351, zoals gewijzigd bij het Besluit van 23 augustus 1985, Stb. 471 en artikel 17 Auteurswet 1912, dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (Postbus 3051, 2130 KB Hoofddorp). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet 1912) dient men zich tot de uitgever te wenden.

dr. ir. jacob brunekreef hva publicaties Een grijs gat Meten aan software ( kwaliteit )

Recommend Documents