Het bepalen van de kwaliteit van een organisatie en het verder professionaliseren van bedrijfsprocessen staat centraal in dit tweeluik over kwaliteit en softwarebouw (deel 1 in Computable week 7). In gegaan wordt op de vraag hoe stappen om hoog op de kwaliteitsladder te zetten. Ondanks het streven naar optimalere taakinvulling blijft testen nodig, zo blijkt.
Verdere professionalisering van organisaties en bedrijfsvoering is in het streven naar kwaliteit dringend nodig, zo luidt de conclusie van het vorige artikel uit dit tweeluik over software-ontwikkeling en kwalitei. Het is echter de vraag of er al methoden bestaan om vast te stellen in welke mate een bedrijf voldoet aan eisen op kwaliteitsgebied. Natuurlijk biedt een ISO-9000 certificaat een soort minimumbasis, maar daarmee is niet de mate van professionaliteit vast te stellen. Software-ontwikkeling is teamwork. Dat moet men bedenken wanneer men wil bepalen in hoeverre een bedrijf in staat is om op tijd en binnen het gestelde budget software met de vereiste kwaliteit te leveren. De vaardigheden van het bedrijf als geheel zijn bepalend voor het eindresultaat en niet de individuele capaciteiten. Het bedrijf moet leren hoe de werkzaamheden op elkaar afgestemd dienen te worden. Op dit gebied zijn de laatste jaren vorderingen gemaakt. Het bekendste model dat gedetailleerd aangeeft hoe organisaties deze vaardigheden kunnen verbeteren is ontwikkeld aan de Carnegie Mellon University. Dit model, het Capability Maturity Model, (CMM) beschrijft de verschillende stadia in een organisatie, die systematisch werkt aan het verbeteren van de software-ontwikkelingsprocessen.
Bij het opzetten van het model realiseerde men zich dat het vakgebied automatisering nog jong en onvolwassen is, en dat er behoefte is aan verdere professionalisering. Centraal stonden de vragen: wat maakt software-ontwikkeling als proces zo bijzonder, en kan men niet gebruikmaken van bestaande modellen voor het verbeteren van processen?
Men begon dan ook met het bestuderen van bestaande modellen voor verbetering van processen. Het betrof voornamelijk industriële processen. Deze worden gekenmerkt door hun repetitieve karakter. Denk daarbij aan een lopende band: het proces is stabiel en de handelingen worden steeds herhaald. Het verbeteren van processen wordt in dergelijke gevallen bereikt door standaardisatie.
Niet alle werkprocessen zijn echter zo te karakteriseren. Zo valt het werk in een onderzoekslaboratorium niet zondermeer te verbeteren door standaardisatie van handelingen. Dat werk wordt sterk bepaald door persoonlijke kenmerken, zoals inzet en inventiviteit.
Hiermee zijn meteen de twee uitersten gekenmerkt van mogelijke procestypen in een bedrijf. Aan de ene kant de processen met een sterk repetitief karakter, zoals de lopende band. Aan de andere kant de creatieve processen, zoals het uitvinden van verbeterde waspoeders. Op de schaal tussen deze twee uitersten zal ieder proces een eigen positie innemen, die in de loop van de tijd kan variëren. In een jong vakgebied waar steeds nieuwe technieken ontstaan, zal na een chaotische start ‘van trial and error’ pas veel later ruimte ontstaan voor standaardisatie. Denk daarbij aan eeuwenoude vakgebieden als bouwkunde of civiele techniek, die steeds verder komen met standaardisatie. De telefoon was vorige eeuw nog uiterst vernieuwend, maar is intussen verregaand gestandaardiseerd.
Standaardisatie
Binnen de automatisering volgen de moderniseringen elkaar in hoog tempo op. Een systeem is nog nauwelijks in produktie of men werkt alweer aan een nieuwe versie. De gebruikers raken nooit vertrouwd met het systeem en de organisatie heeft nauwelijks tijd om het geïnvesteerde geld terug te verdienen. Wie probeert mee te gaan is voortdurend bezig om nieuwe problemen aan het licht te brengen in plaats van efficiënt te werken. In tegenstelling tot wat in bijvoorbeeld de bouwkunde gangbaar is, blijkt het bij software-ontwikkeling heel gewoon te zijn om de te volgen ontwikkelmethodiek en omgeving bij vrijwel ieder project weer ter discussie te stellen. Dit komt mede door de instroom van nieuwe technieken. De ontwikkelaar is daarbij met zichzelf bezig in plaats dat hij oog heeft voor de klant.
Waar staat de automatisering tussen de twee geschetste uitersten? Innovaties in tools en technieken voor automatisering zullen vrijwel altijd gebaseerd zijn op creativiteit. Standaardisatie zal daarom niet direct tot verbeteringen leiden. Het produceren van software is een proces van ontwikkeling; het proces moet tegen veranderingen kunnen. Klanteisen wijzigen, experts veranderen van baan, en er komen betere ontwikkeltechnieken op de markt. Het ontwikkelproces behelst echter niet alleen creativiteit. Veel stappen in het proces zijn redelijk bekend. Het steeds veelvuldiger gebruik van softwarepakketten is een bewijs dat grote delen te standaardiseren zijn. Zelfs de producent die roept dat zijn bedrijf zo bijzonder is dat deze niet in een material resource planning-pakket te vangen is, zal zich vaak verbazen.
Groeipad
Het Capability Maturity Model onderscheidt vijf niveaus in het groeipad naar volwassenheid: initieel, herhaald, gedefinieerd, beheerst en geoptimaliseerd. Uit een onderzoek onder 261 organisaties bleek dat het overgrote deel van de organisaties zich nog op de eerste twee niveaus bevindt. Slechts twee kwalificeerden zich op het hoogste niveau. Ter illustratie volgt een korte beschrijving van de niveaus.
Een organisatie op initieel niveau kenmerkt zich als chaotisch en ad-hoc. De software wordt veelal te laat opgeleverd en is van slechte kwaliteit. Als er al op tijd wordt geleverd, dan is dat te danken aan de bovenmatige inzet van de medewerkers, die daarmee het slechte ontwikkelproces compenseren. De kans dat goede producten worden geleverd is klein.
Functioneren in het tweede ontwikkelingsstadium herhaald is al een aanzienlijke verbetering. Een eerste basis is gelegd, hetgeen blijkt uit het bestaan van een goede planning en bewaking, eisenbeheer en configuratiebeheer. Een organisatie op dit niveau is in staat zich aan een planning te houden, mits niet te veel veranderingen optreden in een project.
Op gedefinieerd niveau is de software-ontwikkeling zowel op managementvlak als op het vlak van technieken gedocumenteerd. Standaardisatie is ingesteld. Alle projecten in zo’n organisatie worden op overeenkomstige wijze uitgevoerd. De organisatie is in staat aan te geven of veranderingen effect hebben.
Op beheerst niveau worden zowel aan het ontwikkelproces als aan het softwareproduct gedegen metingen uitgevoerd. Beide worden op die manier in kwantitatieve zin beheerst, dat wil zeggen wat betreft de inzet van mensen en middelen en wat betreft de benodigde tijd. Het effect van veranderingen kan goed worden ingeschat.
Een organisatie die zich bevindt op het niveau optimaliserend beheerst het proces niet alleen, maar verbetert het ook continu. De metingen aan het proces worden niet alleen gebruikt om benodigde mensen, middelen en tijd in te schatten, maar ook voor verdere optimalisatie. Inefficiënties in de uitvoering kunnen zo boven water komen, en de organisatie is in staat om daar nieuwe ideeën of technieken toe te passen ter verbetering.
De hogere niveaus bieden een steeds betere vorm van beheersing. Binnen het CMM ligt de nadruk in de lagere niveaus op het beheersen van managementvraagstukken, in de hogere niveaus op technische vraagstukken.
Methodieken voor gevorderden
Vaak grijpen bedrijven in hun aanvankelijk enthousiasme direct naar methodieken voor ‘gevorderden’. Dat kan problemen geven. Het model gaat uit van een oplopende volgorde in het groeipad. Een organisatie kan bijvoorbeeld pas zinvol aan niveau 4 beginnen als niveau 3 al gehaald is.
Het model wordt al een aantal jaren toegepast met opvallende resultaten. Wapenfabrikant Raytheon beweert dat zijn cost of rework is gedaald van 41 procent naar 11 procent. Dit gebeurde in drie jaar en met een investering van een miljoen dollar. Het bedrijf schoof twee cmm-niveaus op.
Uiteraard is het cmm-model niet heilig; er wordt nog voortdurend aan gesleuteld. Op dit moment biedt het echter wel de beste mogelijkheden om een bedrijf te verbeteren.
De vijf niveaus in het cmm-model dient men niet te verwarren met de vijf ontwikkelingsstadia die doorgaans binnen total quality management worden onderscheiden. Total quality management richt zich op alle activiteiten van een organisatie en is niet specifiek bedoeld voor softwarekwaliteit.
Testen blijft belangrijk
Velerlei methoden en technieken kunnen het software-ontwikkelingsproces verbeteren, nog voordat testen op de ontwikkelde software worden uitgevoerd. Voorbeelden daarvan zijn coderingsstandaarden, formele methoden, gescheiden ontwikkel- en testteams, standaard case-tools, walkthroughs, evaluaties, Fagan-inspecties, enzovoort. Een voorbeeld van de invloed van het toepassen van formele C-specificaties op het maken van fouten is de casestudie die is uitgevoerd bij het ontwikkelen van een luchtverkeerssysteem. Bij de moduletesten viel het aantal fouten per duizend regels terug van elf naar een.
Naast al deze technieken blijven de testwerkzaamheden echter belangrijk. Het maakt niet uit of het daarbij gaat om moduletesten, integratie- en systeem-of acceptatietesten, zie figuur 1. Dat dit nog steeds nodig is, blijkt uit recent onderzoek. Automatiseringsspecialist Healey meldt dat gemiddeld nog zes tot tien fouten per duizend regels code optreden, ondanks het feit dat men ongeveer 50 procent van de ontwikkeltijd besteedt aan testen. Daarnaast gaat 60 procent van de totale middelen zitten in het onderhoud, waarbij een niet onbelangrijk deel wordt besteed aan het begrijpen van de code. Deze statistieken zijn gebaseerd op programmering in gestructureerd Cobol, zij het in complexe situaties.
Groter leed
Groter wordt het leed met de huidige gui-programma’s op client/server-architecturen. Het aantal mogelijke logische combinaties in gui-programma’s is vele malen groter dan bij eenvoudige menugestuurde programma’s. Met een client/server-architectuur voeg je nog meer complexiteit toe: de applicaties zijn over twee of meerdere platformen verspreid, en vaak is er sprake van een netwerk en van meerdere besturingssystemen en programmeertalen.
Het blijkt dat testen steeds in dergelijke systeemomgevingen lastiger is geworden. Intussen zijn er meerdere testhulpmiddelen op de markt gekomen. Zo zijn er tools om te controleren of met het testen alle code is gedekt. Andere tools zijn bedoeld om te kunnen schatten wat er gebeurt met de belasting en de prestatie van een multi-usersysteem als dat wordt opgeschaald. Ook bestaan er tools om de code-standaarden te inspecteren, bijvoorbeeld voor Fortran, C en C++. Daarnaast zijn er vele mogelijkheden om het handmatige deel van het testen verder te automatiseren, waarbij testgegevens worden opgeslagen. Herhaling van testen is daardoor goed gedefinieerd. Voor de automatische interpretatie van uitvoer bestaan eveneens tools. Extrapolatiemechanismen geven de mogelijkheid om uit het aantal gevonden fouten een schatting te maken van het aantal fouten dat nog in het systeem aanwezig is. Hierdoor is een goede afweging te maken ten aanzien van het risico dat de bedrijfsvoering loopt met de implementatie van het systeem.
Ongebruikelijk goed
Onderzoek van Programming Research Limited wijst uit dat het beste resultaat met de inzet van de bestaande testtools 0,5 fout per duizend regels is. Ongebruikelijk goed gedefinieerde en zeer frequent gebruikte software zoals bijvoorbeeld compilers vallen daarbuiten. Om dit optimale resultaat te halen, moeten goed testbare modulen van circa vierhonderd regels worden opgezet. Ook moet de dekkingsgraad van testen hoog zijn; voor werkelijk belangrijke modulen zelfs 100 procent. Dat betekent dat alle mogelijke paden in de software doorlopen moeten worden met behulp van de testcases. Een ervaren, slimme tester, die aan de hand van de specificaties testcases opstelt, zal met zijn cases in het algemeen een dekkingsgraad bereiken van hooguit 50 procent. De testtools geven de mogelijkheid om de ‘vergeten’ testcases te onderkennen. Hier geldt de Engelse wijsheid: "if it looks right, it could be wrong, but if it looks wrong, it can’t be right."
Rien Scholing is consultant bij de Adviesgroep Informatiesystemen van Tebodin in Den Haag.
