Het geheel van processen voor het maken en onderhouden van programmatuur krijgt de laatste tijd steeds meer aandacht. Reden om stil te staan bij een nieuwe norm voor procesbeoordeling en verbetering. De inmiddels in de praktijk getoetste norm is onlangs als ’technical report’ door ISO/IEC vrijgegeven.
Door de toenemende integratie van computers in de maatschappij neemt de afhankelijkheid hiervan toe, zoals blijkt uit de in de media breed uitgemeten ‘jaar 2000′-problematiek. Ook de veiligheid is in het geding; vliegen is alleen mogelijk bij de gratie van goed werkende computers. Straks worden de taken voor het besturen van auto’s ook uit handen genomen; dan is er pas echt sprake van een ‘elektronische snelweg’. Niet alleen de veiligheid, maar een groot deel van onze welvaart is gebaseerd op informatietechnologie. Een zwakke schakel is de programmatuur, waarbij de voortbrengingsprocessen een vitale rol spelen. Sinds het begin van de jaren negentig wordt meer aandacht besteed aan het beoordelen en verbeteren van processen. Denk bijvoorbeeld aan het capability maturity model (cmm) voor software [1].
In internationaal verband wordt nu getracht de verschillende beoordelingsmethoden te standaardiseren.
Procesbekwaamheid
Organisaties ontlenen hun bekwaamheden aan het geheel van processen. De processen transformeren invoer naar uitvoer met behulp van de benodigde middelen, onder besturing en binnen de randvoorwaarden. Primaire en ondersteunende processen, en processen voor bestuur en beheer worden zó ingericht en afgestemd, dat het resultaat voldoet aan de gestelde eisen. Vakmanschap wordt steeds meer gekoppeld aan het vermogen om procesmatig te werken. De mate van ‘procesbekwaamheid’ vormt een graadmeter voor de leverancier om aan de markteisen te voldoen. En potentiële afnemers krijgen nieuwe mogelijkheden om hun leveranciers aan de hand van procesbekwaamheden te selecteren. De leveranciers zijn daarnaast in staat om hun ‘eigen kunnen’ in beeld te brengen. Alle terechte aandacht voor processen neemt overigens niet weg dat mensen aan de basis staan van alle vormen van kwaliteit. Daarmee staat dus ook de persoonlijke kwaliteit aan de basis van de proceskwaliteit.
Ontwikkeling nieuw model
Het is een goede zaak wanneer het bepalen en vergelijken van procesbekwaamheid aan de hand van internationaal overeengekomen afspraken geschiedt. Diverse jaren geleden is een initiatief genomen om de behoefte aan en de eisen voor een norm voor procesbeoordeling gericht op software te onderzoeken. Dit leidde twee jaar later tot het zogenaamde Spice-project (Software Process Improvement Capability dEtermination), dat zich tot doel stelt te komen tot een ISO/IEC standaard. Er hebben reeds uitgebreide proeven plaatsgevonden, en onlangs is een ’technical report’ gepubliceerd [2]. Het nieuwe model biedt processen een referentie, een meetlat voor de bepaling van de procesbekwaamheid en richtlijnen voor de uitvoering van procesbeoordeling en verbetering. Net als cmm onderkent het een structuur met vijf niveaus. Procesbeoordeling vindt hier echter plaats aan de hand van een indeling in procescategorieën: klant-leverancier, systeemontwikkeling, ondersteuning, bestuur en beheer, en organisatie. Vanaf het laagste niveau kunnen alle processen in beschouwing worden genomen.
Figuur 1. Hoofdelementen Spice-model |
Van het geselecteerde proces wordt na de beoordeling het nieveau van bekwaamheid vastgesteld.
Het Spice-model biedt een raamwerk waarin los van elkaar de softwareprocessen staan en de (software onafhankelijke) procesattributen (middelste kolom). Het model zou derhalve ook toe te passen zijn op andere type processen.
De norm is beschreven in negen delen; het raamwerk staat in deel 2 dat samen met deel 3, waarin het uitvoeren van een beoordeling wordt beschreven, het normatieve gedeelte vormt. Deel 5 bevat een praktijkgerichte invulling die met de overige delen het informatieve gedeelte vormt. In het beoordelingsmodel wordt waar mogelijk de relatie aangegeven met een standaard waarin de levenscyclus van programmatuur staat beschreven [3]. Ook is er nog een aparte richtlijn beschikbaar met een aanpak voor kwaliteitsverbetering [4].
Procesbeoordeling
Procesbeoordeling dient plaats te vinden op basis van vooraf bepaalde doelen en criteria. De twee meest voorkomende doelen voor procesbeoordeling zijn leveranciersselectie/contractbeoordeling en procesverbetering. Beide dienen om de procesbekwaamheden en de risico’s in kaart te brengen. Het model biedt een uitgebreid referentiekader om processen te toetsen. De te volgen stappen zijn globaal als volgt: bepalen van de opdracht, uitvoeren van het onderzoek, uitvoeren van de risico-analyse en verifiëren van het resultaat. De organisatiebehoefte staat hierin centraal. Vastgesteld dient te worden welke processen of procesdelen beoordeeld moeten worden. Het opgestelde compatible (assessment) model [5] vormt het uitgangspunt en is dan aangepast aan de eigen situatie. Daarnaast kan een (target) process capability level profile voor het niveau van procesbekwaamheid worden opgesteld, waarin het gewenste niveau wordt vastgelegd. Dit is vooral van toepassing bij gebruik van het model voor leveranciersselectie, maar ook als een organisatie de eigen processen wil toetsen. Het niveau kan variëren per procesdeel, afhankelijk van de behoefte. Beide vormen de grondslag voor de procesbeoordeling. Aan de hand hiervan vindt onderzoek plaats en wordt het beoordelingsresultaat vastgelegd in een (assessed) process profile. De scores variëren van: niet, gedeeltelijk, grotendeels tot volledig beschikbare procesbekwaamheid. De beoordeling leidt tot het vaststellen van ‘gaten’ in de procesvoering. Hieruit is het risiconiveau af te leiden; na analyse wordt duidelijk wat de gevolgen kunnen zijn. Hiermee wordt inzicht gegeven in de mate van ‘kunnen’ en wordt een gedocumenteerde grondslag voor verdere acties verkregen.
Aan de bepaling van de onderzoeksbehoefte wordt veelal richting gegeven door de naast-hogere bedrijfsplannnen en de hiervan afgeleide doelen voor de programmatuur. Een antwoord op de vraag: ‘wat is nodig aan programmatuur voor de bedrijfsvoering en wat betekent dat voor de processen’, geeft de gewenste richting aan.
Leveranciersselectie
Oorspronkelijk waren de modellen voor softwareprocesbeoordeling gericht op het selecteren van leveranciers. De gedachte hierachter is dat de opdrachtgever het gewenste procesprofiel met proceseisen opstelt en aan de hand hiervan een leverancier selecteert die beschikt over de gewenste bekwaamheden. Hierbij worden de leveranciersprocessen geëvalueerd door onafhankelijke gekwalificeerde beoordelaars. Inkoop-gerelateerde beslissingen vinden dan mede aan de hand hiervan plaats. Omgekeerd kan een leverancier zich afvragen of de geschikte processen beschikbaar zijn om een contract met succes te kunnen uitvoeren. De procesbeoordelingmethode wordt hierbij toegepast om risico’s in de eigen bedrijfsvoering op te sporen en aan te pakken, maar ook om deze op een hoger niveau te brengen.
Procesverbetering
Procesverbetering begint met het onderzoek naar de behoefte (wat wil ik bereiken?), het vaststellen van de status met behulp van procesbeoordeling (waar sta ik?), de implementatie van de benodigde verbeteringen (hoe kom ik er?) en het handhaven, bewaken en borgen van de prestaties die dat oplevert (hoe bewaak ik het?). De procesbeoordeling vormt hierbij het uitgangspunt, waarbij de vastgestelde ‘gaten’ de tekortkomingen aangeven die opgelost moeten worden. Het verbeteren van die procesdelen ligt dan voor de hand. Naast het beheersen van risico’s, zijn aanleidingen voor procesverbetering veelal gelegen in het (nog) niet kunnen realiseren van de gewenste bedrijfsresultaten. Dit betekent dat de verbeteringsdoelen moeten worden vastgesteld. Voorbeelden zijn: (klant)tevredenheid, concurrerend vermogen, marktaandeel, omzet, winstgevendheid, aanzien in de markt, en dergelijke. De na te streven (afgeleide) doelen kunnen zijn: hogere kwaliteit van programmatuur, lagere ontwikkelings- of onderhoudskosten, kortere tijd om een product op de markt te brengen en een betere voorspelbaarheid en beheersbaarheid van de uitvoering van processen en het terugdringen van de projectrisico’s.
De moeilijkheid is om het oorzakelijk verband te bepalen tussen (delen van) processen, risico’s, mogelijke gevolgen en (bedrijfs)resultaten.
Softwareleveranciers kunnen zich directer richten op procesverbetering door te voldoen aan de kwaliteitseisen die de markt vraagt.
Goed is relatief
Het lijkt of procesverbetering een doel op zich is. Teksten als ’80 procent software bedrijven op cmm-niveau 1′ [6], geven impliciet aan dat het pas ‘goed’ zou zijn als je hoger scoort. Maar wat is goed? Dat hangt af van wat je wilt bereiken. Het streven naar een hoger niveau leidt niet per definitie tot betere resultaten. De kans dat de organisatie in staat is een beter product te maken wordt hierdoor wel groter. ‘Beter’ betekent hier dat het moet bijdragen aan de gewenste bedrijfsresultaten.
Een waarschuwing is op zijn plaats: niveau 1 is niet slechter dan niveau 3, maar anders! Een organisatie die voldoet aan de bekwaamheden van één van de lagere niveaus heeft alleen een ander (eenvoudiger) proces, waarbij de procesbekwaamheden die bij hogere niveaus horen, ontbreken. Wellicht past het niet bij de bedrijfscultuur of remt het zelfs de ontwikkeling. De norm geeft ruimte voor deze benadering door uit te gaan van de bedrijfsdoelen en de hiervan afgeleide procesdoelen.
De plaats die procesverbetering inneemt binnen de totale kwaliteitszorg moet daarbij in ogenschouw worden genomen. De stap na procesverbetering is aanpak van ‘het systeem’: de processen binnen een organisatie moeten één werkend geheel vormen. Daarna komt de aansluiting op de voortbrengingsketen: kan de uitvoer van de eigen bedrijfsprocessen zonder problemen worden verwerkt als invoer in de naast-hogere processen binnen de bedrijfskolom. Op het hoogste niveau komt de totale integratie van kwaliteit. Er hoeft niet in de aangegeven volgorde gewerkt te worden. Aandacht besteden aan de naast-hogere stappen kan een keuze zijn, in plaats van eerst te streven naar een geoptimaliseerde proces.
Geen doel op zich
Behalve aan het werken aan processen, kan aandacht worden besteed aan de naast-hogere niveaus van kwaliteitszorg. Sub-optimalisatie en werken in isolement moet zeker niet uit het oog worden verloren. Procesbeoordeling en -verbetering zijn immers geen doel op zich! De vraag of betere procesbekwaamheid tot betere productkwaliteit leidt, is niet eenduidig met ‘ja’ te beantwoorden. De kans hierop neemt toe naarmate er op een systematische wijze wordt gewerkt aan procesverbetering, zeker als die tot stand komt in overleg met alle betrokkenen. De norm geeft een referentiekader en richtlijnen waarbinnen procesbeoordeling en – verbetering kan plaatsvinden. De norm kan van grote waarde zijn voor het terugbrengen van de risico’s en het verhogen van de eigen procesbekwaamheden. Hiermee komt het verbeteren van de softwarekwaliteit binnen bereik.
Het model verdient toepassing vanwege het internationale aspect en de publieke toegankelijkheid ervan (public domain).
Peter Siebbeles RI schreef dit artikel op persoonlijke titel
Historie Spice
Spice is in 1993 gestart om een standaard voor de beoordeling van software-ontwikkelende organisaties vast te stellen [7]. Hierbij is gebruik gemaakt van de bestaande beoordelingsmethoden (waaronder cmm) en vooral van de praktische ervaringen daarmee. Spice richt zich op de beoordeling van het softwareontwikkelproces met het doel om deze te verbeteren en om de kwaliteiten van softwareleveranciers te bepalen. Organisaties uit meer dan twintig landen hebben aan de ontwikkeling bijgedragen. In relatief korte tijd (naar ISO-begrippen) is een negental documenten opgeleverd in 1997. Op één document na zijn deze, naar het zich laat aanzien, in het najaar als technisch rapport verkrijgbaar (onder andere bij het NNI [8]). Later dit jaar zal ook het laatste rapport verschijnen.
Zowel cmm [9] als Spice hebben tot doelstelling om de kwaliteit van het softwareontwikkelproces te beoordelen of te verbeteren. Toch is de primaire focus van beide methoden verschillend. Cmm richt zich op de organisatie, terwijl Spice zich op de processen richt. In cmm wordt de volwassenheid van de ontwikkelende organisatie als uitgangspunt genomen. Bij Spice zijn dat de diverse processen. Allereerst wordt vastgesteld welk deel van de organisatie wordt bekeken; dat kan een gehele organisatie zijn, maar ook een enkele afdeling of zelfs project. Er wordt een procesprofiel bepaald, aan de hand waarvan de status wordt vastgesteld als basis voor verdere actie.
In cmm wordt voor elk niveau (behalve niveau 1) aangegeven wat de aandachtsgebieden voor verbetering zijn. Als deze geïnstitutionaliseerd zijn, bevindt de organisatie zich op dat niveau van volwassenheid. Daarmee geeft cmm een route aan om tot meer volwassenheid te komen.
Spice daarentegen geeft aan de hand van de beoordeelde processen aan hoe de organisatie ervoor staat. Zo is te bepalen waar verbeteringen zijn aan te brengen. De processen van Spice bestrijken een vijftal gebieden; dit is meer dan bij cmm. Spice kent een breder scala, hetgeen tot voordeel heeft dat meer delen van het ontwikkelproces in een beoordeling of verbetertraject betrokken worden. Het nadeel is dat door de veelheid het overzicht zoek kan raken.
Alhoewel cmm en Spice zich op hetzelfde gebied richten, zijn de uitgangspunten verschillend. De vraag welke het best is, kan niet zonder meer beantwoord worden. De praktijk zal dat moeten uitwijzen. De keuze is afhankelijk van het doel en de specifieke wensen van de organisatie. Beide zijn in de praktijk getoetst. Cmm heeft echter al een langere historie en een grotere acceptatiegraad. Spice zal zich nog moeten bewijzen.
Paul Hendriks, SERC
Spice in de praktijk
KPN Research heeft deelgenomen aan de tweede internationale Spice-trial [10] met een evaluatie van een softwareontwikkelingsproject. Deze Spice-trials zijn georganiseerd om de in ontwikkeling zijnde ISO-norm bij organisaties wereldwijd te testen.
We wilden een pilot voor softwareprocesverbetering in eigen organisatie uitvoeren en tegelijkertijd de ISO-norm op de proef stellen. Hiervoor is een project geselecteerd dat bijna was afgerond en waarvan bekend was dat de resultaten succesvol waren. De vraag was: ‘Zijn met behulp van de nieuwe ISO-norm zelfs bij een succesvol project verbeteringen vast te stellen?’. Deze uitdaging is aangegaan.
In het geëvalueerde project werd een softwaresysteem ontwikkeld dat voor onderhoud aan een externe organisatie zou worden overgedragen. Met het oog op de overdracht wilde de sponsor er zeker van zijn dat een goed onderhoudbaar product opgeleverd werd. Hij heeft de ons de volgende vraag gesteld: ‘Wat moet een softwareontwikkelingsproject opleveren, zodat een externe organisatie het product verder kan ontwikkelen en onderhouden?’ Een zeer interessante vraagstelling, want het verbindt een producteigenschap, met name de onderhoudbaarheid, aan de proceskwaliteit!
Het doel van de evaluatie- en verbeteringsactie is hieruit afgeleid: Richt de softwareprocessen optimaal in om een goed onderhoudbaar product op te leveren.
Hiertoe werden processen uit het model geselecteerd die van belang zijn voor de onderhoudbaarheid. Geselecteerde processen waren onder andere: softwareontwerp, configuratiemanagement en documentatie. Vervolgens is het project geëvalueerd aan de hand van deze processen.
In het model wordt elk proces goed beschreven, waarbij het doel en de resultaten genoemd worden. Op basis van deze procesbeschrijving is het zeer eenvoudig om vragen te stellen tijdens de evaluatie. Verbeteringsvoorstellen volgen hieruit eigenlijk vanzelf. Deze vormen de basis voor het maken van een verbeteringsplan.
Een belangrijke verbeteringsvoorstel is bijvoorbeeld het idee om alle ontwerpbeslissingen vast te leggen in het detailontwerp. Hierdoor geeft het detailontwerp een precies beeld van het systeem en wordt het beter onderhoudbaar. Meer dan 65 procent van de verbeteringsvoorstellen werden door het geëvalueerde projectteam als belangrijk aangemerkt. Door deze in toekomstige projecten door te voeren, zijn problemen te voorkomen. Hierdoor worden deze projecten nog succesvoller.
Het procesmodel is zeer krachtig. Dankzij de ‘breedte’ ervan is het eenvoudig om processen te selecteren die voor het evaluatiedoel van belang zijn. De procesdefinities zijn compleet en bieden een goede ondersteuning bij het stellen van vragen tijdens de evaluatie en bij het definiëren van verbeteringsvoorstellen.
Zowel het onderzoeksteam als het geëvalueerde team zijn zeer tevreden over de evaluatiemethode en de resultaten. Iedereen heeft er zeer veel van geleerd! De evaluatie heeft aangetoond dat zelfs in een succesvol project verbeteringen mogelijk zijn.
Adriana Koetluk Florescu, KPN Research
Referenties
1. Watts S, Humphrey: Managing the software process, Carnegie Mellon University, Software Engineering Institute
2. ISO/IEC 15504: Technical Report: Information Technology. Software process assessment.
3. ISO/IEC 12207: 1995 (E). Information technology. Software life cycle processes.
4. ISO 9004: 1993 (E). Quality management and quality system elements, part 4: Guidelines for quality improvement.
5. Een aangepast beoordelingsmodel (voor intern gebruik, voor leveranciersselectie in specifieke situaties of bij het vaststellen van eisen voor specifieke toepassingsgebieden of gebruikssituaties)
6. Sassenburg, H. Betrouwbare software op tijd binnen budget. Informer, april 1998. NGI platform voor ICT-professionals.
7. http://www.sqi.cit.gu.edu.au/spice
8. http://www.nni.nl
9. http://www.sei.cmu.edu