SPECIAL
●
SOFTWARE
MANAGEMENT
GOED MAKEN VAN GOEDE SOFTWARE MAKKELIJK GEZEGD, MOEILIJK GEDAAN! Prof.dr.ir. F.J. Heemstra en Prof.dr. R.J. Kusters*
Softwarekwaliteit en softwareontwikkeling De kwaliteit van software wordt bepaald door (Heemstra, Kusters & Trienekens, 2001): – de wijze waarop het ontwikkelproces is ingericht en wordt uitgevoerd; – de wijze waarop ontwikkeling, implementatie, gebruik en beheer worden gemanaged; – de betrouwbaarheid, volledigheid, actualiteit enzovoort van de eisen waaraan de software moet voldoen; – de invloed van allerlei mogelijke beperkingen en enablers.
Wil de softwareindustrie in staat zijn software van goede kwaliteit te maken, dan zal dus aandacht besteed dienen te worden aan deze vier zaken. We zullen toelichten wat deze vier zaken inhouden en laten zien dat de softwareindustrie moeite heeft met het vinden van een juiste balans in de aandacht voor deze factoren die bepalend zijn voor de kwaliteit van software. De meeste aandacht in het verleden is altijd uitgegaan naar zo goed mogelijke specificaties van de software; de gedachte was immers dat de kwaliteit van de output primair werd bepaald door de kwaliteit van de input. Deze productgeoriënteerde benadering van softwarekwaliteit heeft uiteindelijk geleid tot de over het algemeen breed geaccepteerde standaard ISO 9126.
Bedrijfskunde,
jaargang
74,
2002
nr.
1
S A M E N V A T T I N G
De ontwikkelaar van software kan kiezen uit een enorme gereedschapskist vol met procesmodellen, methoden, technieken en tools enzovoort. Procesmodellen geven keurig aan welke activiteiten uitgevoerd moeten worden om software te realiseren. De methoden en technieken geven concrete ondersteuning bij de uitvoering van die activiteiten en met behulp van tools kunnen sommige activiteiten zelfs min of meer geautomatiseerd worden gerealiseerd. Voor elke klus kan de ontwikkelaar dus kiezen uit een breed scala van gereedschappen. En daar begint zijn probleem; welk gereedschap moet hij wanneer kiezen. Belangrijke overwegingen daarbij zijn dat de keuze leidt tot goede software, tot een hoge productiviteit, tot snelle en betrouwbare levering. De softwareontwikkelaar krijgt niet echt goede ondersteuning in het keuzeproces. Nog lastiger wordt het als de ontwikkelaar, nadat hij zijn keuze gemaakt heeft, zich afvraagt hoe hij het ontwikkelproces zo goed mogelijk moet inrichten, organiseren en uitvoeren. Hij tast in het duister bij beantwoording van de vraag of de kwaliteit van zijn ontwikkel-
proces goed is. De literatuur over softwareontwikkeling zegt hier weinig over. Wel is er een sterk groeiende stroom aan publicaties die in generieke termen beschrijven wat een softwareorganisatie moet doen om het ontwikkelproces steeds verder te verbeteren. Die beschrijvingen, vastgelegd in proceskwaliteitsmodellen als ISO 9000 en het Capability Maturity Model, zijn referentiemodellen, dat wil zeggen ideaaltypische beschrijvingen van een ‘goed’ proces waaraan een softwareorganisatie zijn eigen ontwikkelproces kan spiegelen. Het is nog maar de vraag of de eisen die dit soort modellen stellen aan een ontwikkelproces van toepassing zijn voor de eigen specifieke situatie. Dat zal meestal niet het geval zijn. En dit raakt de kern van dit artikel. We vragen ons in dit artikel af hoe een softwareontwikkelorganisatie de eisen die het aan zijn ontwikkelproces wenst te stellen, kan achterhalen. Een pasklaar antwoord zult u niet krijgen. Wel zullen we aangeven waar een softwareorganisatie rekening mee moet houden bij het in kaart brengen van proceseisen.
*Prof.dr.ir. F.J. Heemstra is verbonden aan de Open Universiteit Nederland te Heerlen. Prof.dr. R.J. Kusters is verbonden aan de Open Universiteit Nederland te Heerlen en aan de Technische Universiteit Eindhoven.
30
SOFTWARE
MANAGEMENT
Traditioneel heeft er altijd ook volop aandacht bestaan voor methoden en technieken voor kwaliteitsbeheersing. Voor zaken die te maken hebben met motivatie, commitment en gedrag van ontwikkelpersoneel, met teamsamenstelling, met mate van professionaliteit, beschikbare tijd en geld enzovoort (de hierboven genoemde beperkingen en enablers) bestaat binnen de softwareindustrie weinig of geen structurele aandacht. Dat wekt verbazing omdat binnen andere takken van de industrie meer dan eens is aangetoond dat juist deze factoren een grote invloed hebben op de kwaliteit van het eindresultaat (Heemstra, Kusters & Trienekens, 2001a). Pas de laatste jaren is er een sterk groeiende aandacht voor de invloed van de kwaliteit van het softwareontwikkelproces op de kwaliteit van de software. Dit is het onderwerp van dit artikel. We beginnen met een korte toelichting op het proces van softwareontwikkeling en de kwaliteitsaspecten die daarbij een rol spelen. Een softwareontwikkelproces verloopt grofweg in twee fasen. De eerste fase wordt de Requirements Engineering genoemd en is gericht op het in kaart brengen van de vereiste softwarekwaliteit, dat wil zeggen op het beantwoorden van de vraag ‘wat moet de software doen en hoe goed moet de software dat doen?’ (de eisen). Die eisen worden primair afgeleid uit de wensen en behoeften van de belanghebbenden/stakeholders. Zij geven aan wat de kwaliteit van een specifieke applicatie moet zijn. Ook de ontwikkelorganisatie kan, als een van deze stakeholders, zelf kwaliteitsdoelen hebben, bijvoorbeeld
●
SPECIAL
dat elke applicatie die de organisatie verlaat minder dan twee fouten per duizend regels code moet bevatten. De tweede fase is gericht op het realiseren van de gespecificeerde kwaliteitseisen. De mate waarin een softwareorganisatie erin slaagt de kwaliteitseisen te realiseren is afhankelijk van de invloed van allerlei beperkingen en enablers. Tijdsdruk en een krap budget maken het bijvoorbeeld lastig om aan alle kwaliteitseisen naar behoren te voldoen. Hoog gekwalificeerd personeel en een perfect projectteam hebben daarentegen weer een positieve uitwerking op de kwaliteit van de software. Wel of niet gebruik (en de kwaliteit van het gebruik) van ontwikkelmethoden en ontwikkelstandaarden zijn eveneens een succes- of faalfactor bij het realiseren van goede softwarekwaliteit. Ten slotte zijn er nog invloeden van de organisatie zelf of vanuit de omgeving van de organisatie. Bij invloeden vanuit de organisatie gaat het om de invloed van bijvoorbeeld organisatiebeleid, organisatiecultuur en -structuur. Bij omgeving moet men denken aan de invloed van bijvoorbeeld de wetgever en de branche. De kwaliteit van software ten slotte wordt ook bepaald door de wijze waarop de software - eenmaal ontwikkeld - wordt geïmplementeerd, gebruikt en beheerd. Tijdens de implementatie en het gebruik worden eventuele tekortkomingen zichtbaar of worden additionele eisen geformuleerd. In figuur 1 wordt de samenhang tussen de zaken die van invloed zijn op softwarekwaliteit weergegeven. In die samen-
Bedrijfskunde,
jaargang
74,
2002
nr.
1
Figuur 1. Wat bepaalt de kwaliteit van software?
31
SPECIAL
●
SOFTWARE
hang is het goed te beseffen dat er zoiets is als het vinden van de juiste balans tussen datgene wat men wil en datgene wat men kan. Extra eisen en strengere eisen leiden wellicht tot een beter product, maar leggen ook een groter beslag op tijd, geld, capaciteit en dergelijke. Steeds weer opnieuw moet worden afgewogen waar het optimale kwaliteitsniveau ligt. Bekend is het voorbeeld (Boehm, 2000) van software waarvoor een antwoordtijd van minder dan één seconde werd geëist. Deze eis legde een zware claim op de benodigde hardware en technische architectuur van de software. Gevolg: kosten minimaal 100 miljoen dollar. Toen men vervolgens de eis van één seconde terugbracht naar maximaal vier seconden, bleken de technische hoogstandjes niet noodzakelijk en kon men met 30 miljoen dollar volstaan. Bovendien bleek dat de gebruiker met de tragere antwoordtijd in 90 procent van de gevallen goed uit de voeten kon.
Kwaliteit van het proces van softwareontwikkeling
Bedrijfskunde,
jaargang
74,
2002
nr.
1
In dit artikel richten we ons op proceskwaliteit, dat wil zeggen op de kwaliteit van het ‘softwareontwikkelproces’. Bij het realiseren van proceskwaliteit ligt de nadruk op het meten aan het proces, het evalueren van de meetresultaten en op basis van die meetresultaten gericht verbeteren van de proceskwaliteit. Meten, evalueren en verbeteren is niet een eenmalige activiteit maar dient bij het realiseren van ‘goede’ proceskwaliteit een continu karakter te hebben. Binnen de softwareontwikkeling heeft men het dan ook over continuous improvement. Binnen andere productieprocessen dan de softwareontwikkeling wordt al tientallen jaren met succes gewerkt aan het continu verbeteren van proceskwaliteit. Alom bekend in dit kader is het zogenoemde Deming-model, ofwel de ‘plan-docheck-act’-cirkel (Deming, 1967). Door deze vier activiteiten steeds weer achtereenvolgend te blijven uitvoeren, wordt volgens Deming een steeds betere proceskwaliteit gerealiseerd. Binnen de softwareontwikkeling heeft proceskwaliteit pas vanaf 1980 serieus aandacht gekregen. De komst van het Capability Maturity Model (CMM) (Humphrey, 1989) met in haar kielzog een hele verzameling zogenoemde proceskwaliteitsmodellen, heeft ervoor gezorgd dat softwareproceskwaliteit momenteel volop in de belangstelling staat.
wikkelorganisaties enorme bedragen uitgegeven aan procesverbeteringen. Kosten noch moeite wordt gespaard om bijvoorbeeld een ISO-certificering ‘binnen te halen’ of op een hoger niveau van het CMM te komen. En waarom al deze moeite? Uiteraard om uiteindelijk betere (dat wil zeggen kwalitatief hoogwaardigere) software op een steeds efficiëntere wijze (dat wil zeggen sneller en goedkoper) te kunnen maken. Maar hoe ligt die relatie tussen proces en product nu precies? Aan welke ‘procesknop’ moet worden gedraaid om betrouwbaardere software te krijgen of om bijvoorbeeld het aantal foutmeldingen per maand te halveren? Er zijn veel vragen maar weinig antwoorden. Duidelijk is in ieder geval dat investeren in het ontwikkelproces leidt tot betere software, tot een gedisciplineerder proces, tot een beter inzicht in datgene waar je mee bezig bent, tot een beter beheersbaar proces enzovoort. Ondanks deze positieve constatering blijft echter onverlet dat de relatie tussen proces- en productkwaliteit er een is van schieten met hagel. Allerlei verbeteracties worden ondernomen en zowaar, de kwaliteit van de output neemt toe. Aan welke verbeteractie welke vooruitgang moet worden toegeschreven, is nog maar de vraag. Sceptici gaan nog een stapje verder en beweren dat procesverbetering nooit op zich staat, maar altijd gepaard gaat met allerlei andere kwaliteitsacties. Dit alles leidt binnen een organisatie tot een hoger kwaliteitsbewustzijn dat op zijn beurt weer zorgt voor betere producten i.c. software. Kortom, het ontbreekt aan een heldere oorzaak-gevolgrelatie. In dit artikel willen we een bijdrage leveren om deze kluwen te ontwarren. We willen dat doen door ons af te vragen wat een ‘goed’ ontwikkelproces is. In de volgende paragrafen gaan we nader in op deze vraag. We zullen constateren dat er niet zoiets is als het beste proces en dat afhankelijk van omstandigheden en tijd bepaald wordt welke proceseisen wel, minder en niet relevant zijn. Vervolgens zullen we aangeven welke wegen een softwareontwikkelorganisatie kan bewandelen om de eisen te achterhalen waaraan een ontwikkelproces dient te voldoen. Feitelijk zijn er twee basisstrategieën waarvoor een organisatie kan kiezen; óf de organisatie bepaalt zelf de eisen waaraan het proces dient te voldoen, óf anderen (bijvoorbeeld de opdrachtgever of de klant) bepalen dat.
Wat is een ‘goed’ ontwikkelproces? Vragen die in deze ‘verbeteringsdrang’ vaak onbeantwoord blijven, zijn: – Levert dat verbeteren een beter ontwikkelproces op? – Wat is een goed ontwikkelproces? – Levert zo’n goed proces überhaupt betere software op? Dit zijn geen triviale vragen. Jaarlijks worden door ont-
32
MANAGEMENT
Bij het ontwikkelen van software wordt onder meer gebruikgemaakt van procesmodellen. Deze modellen - zoals de lineaire of sequentiële modellen, de evolutionaire modellen, de prototypingmodellen, het spiraalmodel enzovoort - formuleren op een redelijk hoog abstractieniveau richtlijnen hoe de activiteiten binnen de ontwikkelcyclus uitgevoerd dienen te
MANAGEMENT
●
SPECIAL
worden. Er zijn globale criteria die aangeven welk procesmodel in welke situatie het best gebruikt kan worden (Davis, 1981). Zo is het verstandig om in onzekere situaties, dat wil zeggen in situaties waarin de kwaliteitseisen lastig te achterhalen zijn, te kiezen voor een evolutionair procesmodel. In zekere c.q. bekende en vertrouwde situaties bieden lineaire modellen een goede oplossing.
kelproces wordt het CMM ontwikkeld. Het ontwikkelde instrumentarium, inclusief vragenlijsten en beoordelingscriteria, blijkt niet alleen geschikt voor het beoordelen van (potentiële) leveranciers c.q. softwareontwikkelorganisaties. Ook de ontwikkelorganisaties zelf gebruiken het CMM als een aanpak om een verbetertraject van het eigen ontwikkelproces op te starten en te structureren.
Er zijn echter, gegeven een bepaald procesmodel, geen criteria voor een goede invulling van zo’n procesmodel. Een procesmodel richt zich immers op wat er moet gebeuren en geeft niet aan hoe dat moet gebeuren. Een goed gefundeerde beslissing voor een bepaald procesmodel is daarom nog geen garantie voor goede proceskwaliteit. Een procesmodel geeft bijvoorbeeld niet aan of inspecties uitgevoerd moeten worden, wie dat zou moeten doen en wanneer en hoe vaak dat zou moeten gebeuren. En dat terwijl meer dan eens is aangetoond dat toepassen van inspectietechnieken de kwaliteit van het ontwikkelproces sterk verbetert (Boehm, 1989; Stutze, 1999).
In Europa tekenen zich twee stromingen af: een ISOen een SPI-stroming (Software Process Improvement). Binnen de ISO-stroming (ISO, 1999) worden de kwaliteitsnormen van de ISO 9000-serie vertaald naar normen voor de IT-wereld. Zo ontstaan de ISO 9000-3 richtlijnen. Inmiddels zijn in Nederland in de IT-sector relatief veel ISO-certificaten toegekend. De SPI-stroming in Europa krijgt vorm binnen een ESPRIT-project (Rout, 1995) en leidt uiteindelijk tot het Bootstrapmodel (Kuvaja & Bicego, 1994). Bootstrap heeft als basis het CMM, maar met toevoeging van enkele belangrijke elementen uit de ISO-normen en andere kwaliteitsbenaderingen. Naast CMM, Bootstrap en ISO zijn nog tal van andere zogenoemde proceskwaliteitsmodellen ontwikkeld, veelal varianten van deze drie basisbenaderingen. We zullen in dit artikel slechts summier ingaan op de ins en outs van dit soort modellen. Voor een uitvoerige beschrijving verwijzen we naar de gestaag groeiende lijst van publicaties. Zie voor verdere verwijzingen Heemstra, Kusters en Trienekens (2001).
Tabel 1. Belangrijke verschillen tussen de CMM-achtige en ISO-achtige kwaliteitsmodellen
CMM-achtige modellen - specifiek - evaluaties gericht op continu verbeteren - groeimodellen
ISO-achtige modellen - generiek - evaluaties gericht op consolidatie - ‘as-is’ modellen
dynamisch
statisch
nr. 2002 74,
Proceskwaliteitsmodellen kunnen worden beschouwd als referentiemodellen, als een ideaaltypische situatie van een ‘goed’ proces waaraan de eigen actuele situatie gespiegeld kan worden. Zo’n model bestaat uit een verzameling eisen te stellen aan een ontwikkelproces. De basisgedachte bij elk referentiemodel is er een van ‘de juiste dingen op de juiste wijze doen’. Het ISO 9000-model en het CMM vormen de basis voor de huidige generatie proceskwaliteitsmodellen. Hoewel beide modellen hier onder één noemer worden behandeld, verschil-
1
Softwareproceskwaliteitsmodellen
jaargang
Het structureel nadenken over vragen als ‘wat is een goed proces?’ en ‘welke eisen te stellen aan een softwareontwikkelproces?’ begint in het midden van de jaren tachtig door te breken. Het Amerikaanse ministerie van Defensie (het DOD) zet daarin de toon door eisen te formuleren waaraan het ontwikkelproces van zijn softwareleveranciers dient te voldoen. Voor een opdrachtgever als defensie is het belangrijk te kunnen beoordelen of de kwaliteit van de softwareontwikkeling bij de opdrachtnemers/leveranciers voldoet aan zekere standaards van professionaliteit. Men wil er zeker van zijn dat de betreffende opdrachtnemer in staat is software te maken van hoge kwaliteit. Al in de jaren vijftig werden door de DOD de gedetailleerde AQAP-kwaliteitsnormen geïntroduceerd (Allied Quality Assurance Publications). Ergens in de jaren tachtig wordt aan het Software Engineering Instituut (SEI) van de Carnegie Mellon Universiteit de opdracht gegeven een beoordelingsinstrument te ontwikkelen om de bekwaamheid (capability) van softwareleveranciers te bepalen. Mede onder invloed van de ideeën van Watts Humphrey over het managen van het softwareontwik-
Bedrijfskunde,
SOFTWARE
33
SPECIAL
●
SOFTWARE
Bedrijfskunde,
jaargang
74,
2002
nr.
1
len zij aanzienlijk in filosofie en uitwerking. In tabel 1 worden enkele fundamentele verschillen genoemd, die vervolgens nader worden toegelicht.
34
De CMM-achtige modellen dienen primair beschouwd te worden als evaluatiemethoden. Op basis van dergelijke evaluaties worden verbeteringen voorgesteld die naar believen kunnen worden doorgevoerd. We spreken dan van procesverbetering (process improvement). De CMM-achtige modellen zijn gericht om via evaluaties het ontwikkelproces steeds verder te verbeteren. Uitgangspunt is dat een proces nooit ‘af’ is, maar dat voortdurend gezocht moet worden naar verbetermogelijkheden. Proceskwaliteitsmodellen gebaseerd op een CMM-achtige benadering groeien als het ware, via continue verbeteracties, naar een hoger niveau van ‘volwassenheid’. Het zijn dus groeimodellen. Bovendien hebben dit soort modellen een specifieke oriëntatie. Hiermee wordt bedoeld dat er geen absoluut ‘goed’ proces bestaat, maar dat wat goed is bepaald wordt door lokale omstandigheden en door de doelen die de organisatie zichzelf heeft gesteld. Het is aan de organisatie om te bepalen welk niveau van volwassenheid bereikt dient te worden of welke verbeteractiviteiten wel of niet van belang zijn. Om dit soort overwegingen duiden we de CMMachtige modellen aan als ‘dynamische proceskwaliteitsmodellen’. Anders ligt het bij ISO 9000. De essentie ligt hier voornamelijk in het certificatiemechanisme dat wordt geboden. In ISO 9000 wordt een beschrijving gegeven van de kwaliteitseisen waaraan een proces dient te voldoen. Een organisatie die aan deze eisen voldoet, ontvangt een ISO-registratie. Dit betekent dat een organisatie wel of niet gecertificeerd is c.q. wel of niet voldoet aan deze eisen van ‘een goed ontwikkelproces’. Een beetje gecertificeerd of bijna goed bestaat niet. ISO-achtige modellen zijn daarom zeker geen groeimodellen. Wordt eenmaal voldaan aan de certificatie-eisen dan wordt de dan bereikte situatie geconsolideerd. Bovendien geldt dat er een reeks absolute eisen is waaraan voldaan moet worden. Van customizing naar lokale omstandigheden is geen sprake. Verder verschillen de beide benaderingen als het aankomt op procesverbeteringen. Binnen het CMM is dit een integraal onderdeel van het model, terwijl dit binnen ISO in feite ontbreekt. De ISO-achtige modellen noemen we ‘statische proceskwaliteitsmodellen’. De verschillen tussen beide benaderingen nemen geleidelijk af. Steeds duidelijker beginnen ook de CMM-achtigen zich te profileren als certificatie-instrument. Verder onderkent de laatste versie van ISO 9000:2000 het belang van continu verbeteren of SPI. Ondanks alle goede bedoelingen geven dit soort modellen geen antwoord op de centrale vraag in dit artikel, namelijk ‘wat is een goed ontwikkelproces?’ Hoewel de meeste model-
MANAGEMENT
len immers vrij gedetailleerd aanwijzingen geven rondom het thema projectmanagement, ontbreekt het aan gedetailleerde aanwijzingen omtrent de inhoudelijke inrichting van de ontwikkelprocessen. Deze keuze wordt aan de ontwikkelorganisatie zelf overgelaten. Dit is op zich een juiste benadering. Wat goed is, wordt situationeel bepaald en is bovendien tijdsafhankelijk. Zo hoeft het geen betoog dat aan het proces van softwareontwikkeling voor de besturingssoftware van een kerncentrale of van de Space Shuttle andere eisen worden gesteld dan het ontwikkelproces voor de voorraadadministratie van een potlodenfabriek. Ook spreekt voor zich dat een organisatie die als core business heeft het ontwikkelen, onderhouden en beheren van software andere eisen aan het ontwikkelproces zal en kan stellen dan een kleine ontwikkelafdeling binnen een ‘nietsoftware’-organisatie die af en toe kleine applicaties bouwt en het grote werk uitbesteedt aan derden. Beide ontwikkelorganisaties zullen de juiste dingen op de juiste wijze willen doen, maar in het eerste geval kan men het zich permitteren om bijvoorbeeld een uitgebreid metriekenprogramma op te starten en te onderhouden, terwijl in het tweede geval 100 procent ingezet wordt op een gedegen projectmanagement en management van toeleveranciers en subcontractors. Ook de proceseisen die het CMM stelt, dienen organisatiespecifiek ingevuld te worden. Het CMM suggereert weliswaar dat het ‘op maat’ ingevuld kan worden voor een specifieke organisatie, maar die flexibiliteit heeft zijn beperkingen. Elk maturity-niveau van het CMM kent een set proceseisen. Wil een softwareorganisatie zo’n niveau bereiken, dan dient aan al deze eisen te worden voldaan. De aanpasbaarheid aan lokale omstandigheden betekent dat sommige eisen mogen vervallen als die niet van kracht zijn in die specifieke situatie. Waarom bijvoorbeeld zou een organisatie die nooit met subcontractors werkt kosten en moeite steken in de CMM-eis ‘subcontracting management´? Vasthouden aan die eis zou inhouden dat deze organisatie nooit CMM-niveau 2 zou kunnen bereiken. Dat die organisatie daarom slechte software maakt, hoeft zeker niet het geval te zijn. De CMM-flexibiliteit betekent echter niet dat extra specifieke eisen toegevoegd zouden kunnen worden of een ander gewicht zouden kunnen krijgen. Kortom, het CMM biedt voornamelijk een generieke set van eisen die maar heel beperkt aanpasbaar zijn naar lokale omstandigheden. De conclusie uit het bovenstaande is dat er niet zoiets bestaat als dé verzameling kwaliteitseisen waaraan een ontwikkelproces moet voldoen. Wat goed is, verschilt van situatie tot situatie en moet daarom ook per softwareorganisatie bepaald en ingevuld worden. Dezelfde redenering geldt voor procesverbetering; ook dat is iets dat elke softwareorganisatie zelf zal moeten invullen. Onderzocht dient te worden waar een pro-
MANAGEMENT
In een brief, gedateerd op 25 september 1991 (inmiddels al weer heel wat jaren geleden) wijst het Rome Laboratory, Griffiss Air Force base (een onderdeel van de Amerikaanse luchtmacht) haar softwareleveranciers op het volgende: “We wish to point out that at some point in the near future, all potential software developers will be required to demonstrate a software maturity level 3 before they can compete in ESD/R1 (Electronic Division/Rome Lab.) major software development initiatives…Now is the time to start preparing for this eventuality.” Deze toekomstvoorspelling is inmiddels al lang uitgekomen en heeft zich niet beperkt tot deze specifieke situatie.
In deze paragraaf willen we een aanpak beschrijven die een softwareorganisatie helpt bij het bepalen van een ‘goed’ proces en de realisatie van zo’n proces. Een voorwaarde in deze aanpak is een expliciet geformuleerd kwaliteitsbeleid dat als afgeleide van het organisatiebeleid wordt opgesteld. Zo’n beleid is noodzakelijk omdat een organisatie niet in staat is aan te geven of ‘iets wel of niet goed’ is als niet bekend is waar dat ‘iets’ toe moet leiden. Dit kwaliteitsbeleid kan zowel vanuit eigen doelen als vanuit eisen en wensen van de afnemer (of een combinatie van beiden) worden beïnvloed. Vervolgens dient de organisatie te beschikken over zoiets als ‘kwaliteitsdoelen’, over normen wat goed of niet goed is. Kwaliteitsdoelen geven (in generieke termen) aan waaraan de kwaliteit van de processen, maar ook van de producten en middelen dient te voldoen. Voorbeelden van kwaliteitsdoelen zijn ‘reductie van het aantal fouten per duizend regels code met 50 procent’ of ‘verkorten van de ontwikkeltijd met 25 procent binnen een jaar’. De kwaliteitsdoelen zijn enerzijds een weerslag van het kwaliteitsbeleid van de organisatie maar worden anderzijds ook bepaald door evaluaties van bijvoorbeeld het ontwikkelproces, de werkwijzen, procedures enzovoort en door klachten/problem reports van klanten.
1
De klant bepaalt Bij het ontwikkelen van software komt het steeds vaker voor dat de klant eist dat het ontwikkelproces van een leverancier voldoet aan bepaalde kwaliteitseisen. Deze eisen worden dan meestal in generieke termen gedefinieerd door aan te geven dat de leverancier bijvoorbeeld ISO gecertificeerd dient te zijn of zich minimaal op niveau 3 van het CMM moet bevinden. Wil een leverancier c.q. ontwikkelorganisatie zaken (blijven) doen met de betreffende klant dan zal het of door middel van een ISO-certificaat of een CMM-assessment dienen aan te tonen dat voldaan is aan de gestelde voorwaarde. Dat deze ontwikkeling snel is gegaan, wordt geïllustreerd aan de hand van het volgende voorbeeld (Saiedian, 1995).
Een aanpak voor het bepalen van een ‘goed’ ontwikkelproces
nr.
In de praktijk van softwareontwikkeling zal men meestal een combinatie van deze strategieën aantreffen. Soms ligt het accent meer op de ene en soms meer op de andere strategie. Vanuit ordeningsoogpunt worden ze hier gescheiden en afzonderlijk toegelicht.
De organisatie bepaalt zelf Bij deze strategie is het de ontwikkelorganisatie zelf die bepaalt wat wel en wat niet goed is voor het eigen ontwikkelproces, die zelf het kwaliteitsniveau van het eigen ontwikkelproces bepaalt, die zelf aangeeft op welke wijze en in welk tempo dat niveau bereikt moet worden en probeert via gerichte verbeteracties al experimenterend en lerend de proceskwaliteit te verbeteren. Deze strategie sluit dus aan bij de conclusies van de vorige paragraaf, namelijk dat situationeel wordt bepaald wat een goed proces is.
2002
Goed beschouwd zijn er twee basisstrategieën om de eisen te bepalen waaraan een ‘goed’ softwareontwikkelproces dient te voldoen. 1. De klant/opdrachtgever bepaalt de eisen. 2. De ontwikkelorganisatie bepaalt zelf de eisen.
Het komt, zover ons bekend, maar weinig voor dat een klant (onafhankelijk van welk proceskwaliteitsmodel dan ook) heel specifieke kwaliteitseisen stelt aan het ontwikkelproces van een leverancier. Soms zien we dat een klant eist dat bijvoorbeeld een kostenschatting opgesteld dient te zijn met behulp van een specifiek schattingsmodel of dat een offerte aan bepaalde eisen dient te voldoen. Maar dit soort eisen hebben meestal als doel om verschillende offertes onderling te vergelijken en hebben niet de pretentie eisen op te leggen aan het ontwikkelproces van de leverancier.
74,
Strategieën voor het formuleren van proceskwaliteitseisen
SPECIAL
jaargang
ces tekortschiet en welke specifieke ingrepen nodig zijn. Gegeven dit feit is het daarom weinig zinvol te zoeken naar de steen der wijzen c.q naar dé proceskwaliteitseisen. Die bestaan immers niet. Waar we in dit artikel wel een antwoord op willen geven is de vraag ‘hoe de kwaliteitseisen (voor een specifiek ontwikkelproces) achterhaald kunnen worden’. In de volgende paragraaf zullen we twee strategieën onderscheiden die gebruikt kunnen worden bij het formuleren van proceskwaliteitseisen.
●
Bedrijfskunde,
SOFTWARE
Om kwaliteitsdoelen te realiseren dient het ontwikkelproces (maar ook de in te zetten middelen, de invoer van
35
SPECIAL
●
SOFTWARE
Bedrijfskunde,
jaargang
74,
2002
nr.
1
het proces, allerlei tussenproducten en dergelijke) aan bepaalde proceskwaliteitseisen te voldoen. Wat betreft ontwikkelpersoneel zou bijvoorbeeld een bepaalde opleiding, specifieke vaardigheden en ervaring geëist kunnen worden. Als het gaat om tussenproducten zouden specifieke eisen aan documentatie, modulariteit en toegankelijkheid kunnen gelden. Evenzo dienen de eisen die gesteld worden aan het ontwikkelproces geëxpliciteerd te worden. Voor het hierboven genoemde voorbeeld zouden de volgende proceskwaliteitseisen geformuleerd kunnen worden. – Van elk ontwikkelproject dient een work-breakdown structure opgesteld te worden waarbij voor elk deelproduct op basis van functiepuntanalyse een schatting van kosten en tijd gemaakt dient te worden. – Elk (deel)product en document dient onderworpen te worden aan een inspectie. – Op activiteitsniveau dient vastgelegd te worden de geschatte en gerealiseerde ontwikkeltijd en de oorzaak van eventuele verschillen hiertussen.
36
Om het ontwikkelproces te kunnen laten voldoen aan de kwaliteitseisen dienen de inrichting, aansturing/beheersing en/of informatievoorziening van het proces aangepast te worden. Onderzocht zal moeten worden welke aanpassing/maatregel het best een bepaalde eis afdekt. Vaak is dat een lastig keuzeproces omdat bijvoorbeeld nog maar weinig bekend is van het effect van ingrepen in het proces, omdat verschillende eisen om conflicterende maatregelen vragen en omdat nog weinig inzicht bestaat in de kosten en baten van een maatregel. Zo kan de eerdergenoemde proceskwaliteitseis ‘dat op activiteitsniveau vastgelegd dient te worden wat de geschatte en gerealiseerde ontwikkeltijd en de oorzaak van eventuele verschillen hiertussen is’, de volgende maatregelen tot gevolg hebben. – De projectleider dient van elke ontwikkelactiviteit een schatting van ontwikkeltijd en doorlooptijd (in uren) op te stellen. – De ontwikkelaar dient, na afronding van een ontwikkelactiviteit aan te geven het aantal bestede uren en de werkelijke doorlooptijd. – Wekelijks dient de projectleider van alle afgesloten activiteiten na te gaan of er overschrijdingen in ontwikkel- en doorlooptijd zijn opgetreden en dient hij vast te leggen wat de oorzaken zijn van die overschrijdingen. – Periodiek dient de projectleider een oorzakenanalyse uit te voeren en op basis hiervan eventuele voorstellen te doen om het proces bij te sturen. De softwareorganisatie zal met behulp van ‘procesmetingen’ dienen na te gaan of de maatregelen het gewenste effect hebben. Omdat nog maar zo weinig bekend is van procesverbeteractiviteiten is een softwareorganisatie genoodzaakt al
MANAGEMENT
experimenterend ervaring op te doen en al lerend inzicht te krijgen in het effect van ingrepen in het proces (Van Solingen, 1999). Dat er nog maar weinig bekend is van de relatie maatregelen en effect van die maatregel blijkt uit het feit dat slechts van twee procesmaatregelen onomstotelijk vaststaat dat ze daadwerkelijk leiden tot procesverbetering en uiteindelijk tot betere software. Dit zijn inspecties en het zoeken, vinden en herstellen van fouten zo snel mogelijk na het maken van de fout (Boehm, 1981). Dit laatste impliceert maatregelen die gericht zijn om tijdens het ontwikkelen van software voortdurend de kwaliteit te controleren. Het gaat echter niet uitsluitend om ingrepen in het proces. Het kan ook zijn dat proceseisen bijgesteld moeten worden, dat kwaliteitsdoelen geherformuleerd moeten worden of dat niet de juiste maatregelen zijn geselecteerd of juist zijn ingevoerd. Zo kan het kwaliteitsdoel om de ontwikkeltijd binnen een jaar te verkorten met 25 procent te hoog zijn gegrepen of wegen de kosten om te voldoen aan de eis dat elk (tussen)product en document geïnspecteerd dient te worden, niet op tegen de baten. Ook kan de goedbedoelde maatregel om van elke activiteit geplande en werkelijke ontwikkeltijd te bepalen, nergens toe leiden omdat de betrokkenen er geen heil in zien en nauwelijks bruikbare gegevens aanleveren. Wat het bovenstaande ons leert is dat het formuleren van proceskwaliteitseisen en het gericht verbeteren van het softwareontwikkelproces lastig is. Elke stap om van kwaliteitsbeleid uiteindelijk uit te komen bij gerichte ingrepen in het ontwikkelproces kent veel hindernissen. We weten niet precies welke eisen we aan een proces moeten stellen, we weten ook niet goed welke maatregelen we moeten treffen om aan die eisen te kunnen voldoen, ook is niet goed bekend wat het effect is van bepaalde maatregelen en hoe we die effecten moeten meten. Het lijkt bijna een hopeloze zaak, maar dat is het zeker niet. Het is wel een lastige weg en een van de lange adem. Alleen door consequent de bovengenoemde stappen steeds weer opnieuw te nemen en te blijven meten, krijgt een softwareorganisatie inzicht in haar eigen ontwikkelproces en weet het welke eisen leiden tot welke ingrepen. In figuur 2 wordt het traject van beleid tot proces weergegeven. In het linker gedeelte van de figuur is de interne weg van kwaliteitsbeleid naar kwaliteitseisen en procesverbetering in beeld gebracht. In het rechter deel wordt de externe weg weergegeven, dat wil zeggen de invloed vanuit de omgeving op de kwaliteit van het ontwikkelproces. De voorgestelde aanpak bouwt voort op een eventuele keuze voor een bepaald CMM-niveau of een ISO-certificering. Al eerder is aangegeven dat zowel CMM als ISO onvoldoende hand-
MANAGEMENT
●
SPECIAL
vatten geven bij de feitelijke inrichting van ontwikkelprocessen. Toch kunnen deze kwaliteitsmodellen nuttige richtlijnen geven bij opstellen van het kwaliteitsbeleid. Bij de volgende stappen zal de organisatie naast algemene best practices ook moeten kiezen voor proceseisen en procesverbetering op basis van eigen kwaliteitsdoelen, eigen inzichten en assessments van het eigen proces.
Conclusie In dit artikel is een aanzet gegeven, en niet meer dan dat, om een discussie te openen over eisen die aan een goed
ontwikkelproces gesteld dienen te worden. Natuurlijk bestaan er al lijsten van dergelijke eisen, verpakt in modellen als het CMM, Bootstrap, ISO enzovoort. Deze modellen zijn echter te algemeen en houden vaak geen rekening met de eigen lokale omstandigheden van een betreffende ontwikkelorganisatie. En dat is nu juist waar het in dit artikel om gaat. Wat goed is voor het ontwikkelproces van organisatie A hoeft nog niet goed te zijn voor het ontwikkelproces van organisatie B of is te hoog gegrepen voor organisatie C. Het is dus de ontwikkelorganisatie zelf die door een goede procesanalyse en klantonderzoek bepaalt wat een geschikt ontwikkelproces is.
Bedrijfskunde,
Figuur 2. De weg naar proceskwaliteitseisen en procesverbetering
jaargang
74,
2002
nr.
1
SOFTWARE
37
SPECIAL
●
SOFTWARE
Literatuur Boehm, B.W., Software engineering economics, Prentice Hall, 1981. Boehm, B.W., Software risk management, IEEE Computer Society Press, Los Alamitos 1989. Boehm, B.W., ‘Verifying software and systems engineering’, IEEE Computer, March 2000. Deming, W.E., ‘What happened in Japan?’, Industrial Quality Control, 24(2), 1967. Heemstra, F.J., R.J. Kusters & J. Trienekens, ‘Wat bepaalt de kwaliteit van software?’, Informatie, oktober, 2001a. Heemstra, F.J., R.J. Kusters & J. Trienekens, Softwarekwaliteit: op weg naar betere software, tenHagenStam, 2001. Humphrey, W.S., Managing the software process, SEI Series in Software Engineering, Addison-Wesley, Reading 1989. ISO 1999. ISO/CD2 9001:2000 (1999), ISO/CD2 9004:2000 (1999), Committee Drafts. Kuvaja, P. & A. Bicego, ‘Bootstrap: a European assessment methodology’, Software Quality Journal, 3(3), p. 117-128, 1994. Rout, T.P., ‘Spice: a framework for software process assessment’, Software Process: Improvement and Practice, 1(1), p. 57-66, 1995. Saiedian, H. & R. Kuzara, ‘SEI Capability Maturity Model’s impact on contractors’, Computer, 28(1), 1995. Stutzke, R., ‘Measuring defects containment in software processess’. In: R. Kusters, A. Cowderoy, F. Heemstra & E. van Veenendaal (eds.), Project control for software quality, Proceedings of the 10th European conference on Software Control and Metrics. Van Solingen, On product quality and process improvement of embedded software:
Bedrijfskunde,
jaargang
74,
2002
nr.
1
the development and application of product focused SPI, PhD thesis, 1999.
38
MANAGEMENT
