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

Transcriptie

1 * omslag Jacob Brunekreef :53 Pagina 1 hva publicaties dr ir jacob brunekreef Een grijs gat Meten aan software ( kwaliteit )

2 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

3 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 (HA Rubin) Measurement has been the basis of all science and engineering progress except for software (Capers Jones)

4 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 EJ 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

5 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

6 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 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

7 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 Dr Ir Jacob Brunekreef

8 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 en Soms is een fout hilarisch: in het najaar van 2006 ontvingen vrijwel alle werknemers van de Universiteit van Groningen een 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

9 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 9% 16% 28% Over tijd/over budget 62% 47% 50% Voortijdig beëindigd 29% 37% 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 Duidelijke specificaties 3 Gebrek aan personeel, tools 4 Heldere planning 4 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 Dr Ir Jacob Brunekreef

10 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

11 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 Dr Ir Jacob Brunekreef

12 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

13 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 Dr Ir Jacob Brunekreef

14 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

15 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 Dr Ir Jacob Brunekreef

16 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

17 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 Dr Ir Jacob Brunekreef

18 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 deskhet aantal en de zwaarte van de incidenten zegt iets over de kwaliteit van het pro- 17 een grijs gat

19 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 Dr Ir Jacob Brunekreef

20 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

21 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 Dr Ir Jacob Brunekreef

22 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

23 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 Dr Ir Jacob Brunekreef

24 Eigenschap Meeteenheid H/A Dynamische eigenschappen product functionaliteit aantal testgevallen OK/NOK H (A) responsetijd sec A 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 A functiepunten H (A) structuur < niet standaard > A complexiteit aantal executiepaden A kwaliteit code checklistscore H Statische eigenschappen product - documentatie volledigheid checklistscore H actualiteit timestamps, checklistscore H inhoudelijke kwaliteit checklistscore H Eigenschappen proces tijdsbesteding activiteiten (delen van) uren H 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

25 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 11 Suitability 21 Maturity 31 Understandability 12 Accuracy 22 Fault tolerance 32 Learnability 13 Interoperability 23 Recoverability 33 Operability 14 Security 34 Attractiveness 15 Compliance 4 Efficiency 5 Maintainability 6 Portability 41 Time behaviour 51 Analysability 61 Adaptability 42 Resource utilisation 52 Changeability 62 Installability 53 Stability 63 Co-existence 54 Testability 64 Replaceability Tabel 4 ISO/IEC 9126 Softwareproduct kwaliteitsaspecten 24 Dr Ir Jacob Brunekreef

26 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 veelge- 25 een grijs gat

27 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 Dr Ir Jacob Brunekreef

28 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 = 25) 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

29 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 ontwikkel- en 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 Dr Ir Jacob Brunekreef