Een kwalitatief goed produkt wordt niet verkregen door het opleveren van foutloze software. Testen achteraf is onvoldoende. De kwaliteit van software wordt gegarandeerd door beheersing van het hele ontwikkelproces. Ook dan blijft er echter behoefte aan een keurmerk, meent consultant Rien Scholing.
Net als de automatisering zelf is ook het kwaliteitsdenken flink in beweging. Op diverse niveaus is men bezig met de kwaliteit van automatisering, hetgeen zijn beslag krijgt in nieuwe methodieken en normen en in Europese projecten. Toch kost het veel organisaties moeite om de juiste weg te vinden. Voorbeelden daarvan zijn er te over. Een falende computerbesturing zorgde ervoor dat een medisch scanapparaat plotseling een fatale stralingsdosis uitzond. De Duitse PTT wekte de woede van haar klanten toen bleek dat op nieuwjaarsdag door een programmeerfout aan 11 miljoen Duitsers te hoge gesprekskosten in rekening waren gebracht. Deze dag werd door het programma als een doordeweekse dag gezien in plaats van als feestdag. Een klein programmeerfoutje legde in 1990 negen uur lang een groot deel van het Amerikaanse telefoonnet plat. Een computer van een Engelse bank schreef plotseling miljarden over naar het buitenland. Het verongelukken van de Ariane 5 was het gevolg van een fout in de navigatiesoftware, die niet werd opgemerkt als geolg van onvolledige testprocedures. Favoriet in een dergelijk rijtje is nog altijd de straaljager die bij het passeren van de evenaar uit zichzelf ondersteboven ging vliegen: foutje in de coördinatenverwerking.
Enkele van de meest in het oog springende fouten. De minder spectaculaire gevallen komen vaker voor, en ook daar kan het leed, de ergernis of de schade groot zijn. Al met al vormen ze een groot risico voor organisaties.
De vraag is hoe dergelijke ongelukken ten gevolge van foute software voorkomen kunnen worden. Het voor de hand liggende antwoord hierop luidt: lever goede spullen af. Het moge duidelijk zijn dat elk bedrijf in ieder geval zal proberen om een goed produkt te leveren. Geen enkele ondernemer produceert moedwillig rommel.
Maar met het streven naar een goed produkt is een bedrijf er nog lang niet. Dit is nog maar de ‘nulfase’ van de kwaliteitszorg. Uiteindelijk moeten alle processen die invloed hebben op de kwaliteit van het produkt zodanig worden beheerst, dat het produkt de gewenste kwaliteit heeft tegen minimale kosten. Ook moet een cultuur zijn ontstaan waarin voortdurend wordt gestreefd naar verbetering. Kwaliteitszorg is niet lui en tevreden achteroverleunen met het behaalde certificaat, maar vereist voortdurend beweging.
Een organisatie die deze kant op wil, wordt geconfronteerd met de vraag hoe zij zich een weg moet banen door de vele methoden en technieken die worden aangeboden. Lang twijfelen over deze vraag is niet mogelijk, omdat de steeds verdergaande stem van de klant het bedrijf dwingt om deze weg op te gaan. Klanttevredenheid en continuïteit zijn derhalve de belangrijke drijfveren. De beloning is een betere beheersing van de geleverde kwaliteit die de concurrentiepositie verbetert en tot hogere omzetten leidt.
Tijdens deze zoektocht rijzen veel vragen bij mensen die niet zijn ingewijd in kwaliteitssystemen. Is testen achteraf voldoende of moet het proces van software-ontwikkeling ook onder de loep worden genomen? Welke bedrijven zijn in staat om als aannemer op te treden van projecten als het gaat om hoge betrouwbaarheid? Hoe kan ik zo’n bedrijf worden? Bestaan daarvoor maatstaven of richtlijnen? Hoe staat het met de faalkans van een softwareprodukt? Is het mogelijk om een soort keurmerk af te geven? De nieuwe methodieken geven nieuwe mogelijkheden, maar hoe ver gaan ze eigenlijk?
Kwaliteit en foutloze software
Kwaliteit van software betekent meer dan het aantal fouten dat na ingebruikname wordt gevonden. Voorheen was er sprake van een aanbiedersmarkt en werd naar softwareprodukten gekeken vanuit de optiek van de ontwikkelaar, dat wil zeggen met een technische oriëntatie. Deze maatstaf voor kwaliteit was vooral van belang voor de ontwikkelaars zelf. Als zij hadden voldaan aan de afgesproken functionaliteit, geen of weinig fouten in de opgeleverde software, dan hadden zij hun werk goed gedaan.
Maar wat is kwaliteit van software dan wel? Duidelijk is dat het aantal fouten in de software alleen, niets zegt over de beleving van het softwareprodukt door de gebruiker. Vaak wordt pas na oplevering van het produkt duidelijk dat het toch niet voldoet aan de verwachtingen van de klant. Technisch is het produkt weliswaar in orde, maar de gebruikersvriendelijkheid en de tijd die nodig is om het produkt onder de knie te krijgen (fitness for use) zijn teleurstellend.
De adders onder het gras zijn de impliciete eisen en verwachtingen ten aanzien van het eindprodukt. Wat de klant als common sense en normaal beschouwt, interpreteert de leverancier op geheel andere wijze. Om die reden wordt op internationaal niveau, zoals binnen ISO-9126, gewerkt aan een standaard die kwaliteit ook vanuit de gebruiker definieert. De kwaliteitskenmerken van softwareprodukten omvatten in deze gevallen meer dan alleen het voldoen aan de afgesproken functionaliteit. Ook aan kenmerken als bruikbaarheid, efficiency, betrouwbaarheid, onderhoudbaarheid en openheid (portability) zijn steeds beter expliciete eisen te stellen in het voortraject, zodat teleurstellingen achteraf voorkomen kunnen worden.
Belangrijk is dat de klant krijgt waar hij om gevraagd heeft. Als hij de kwaliteit van een lelijke eend wil, geef je hem geen Rolls Royce. Natuurlijk is het afhankelijk van het soort softwareprodukt in hoeverre belang aan een bepaald kenmerk moet worden gehecht. Dit houdt verband met de kritische succesfactoren van de klant. Zo zal voor een nieuw onderhoudsinformatiesysteem in een fabriek het kwaliteitskenmerk bruikbaarheid van groot belang zijn. Weerstanden die toch al vaak bestaan bij nieuwe werkwijzen kunnen op die manier zo veel mogelijk worden voorkomen bij de onderhoudsmedewerkers.
Voor een systeem dat in de nabije toekomst waarschijnlijk wordt uitgebreid, zal het kwaliteitskenmerk openheid van groot belang zijn: besturingssystemen, databases en bestandsformaten moeten eenvoudig te koppelen zijn met andere systemen.
Voor beslissingsondersteunende systemen is gebruikersvriendelijkheid van minder groot belang. Betrouwbaarheid en foutloze uitvoering van de vereiste functionaliteit op de momenten dat het erop aankomt, hebben de hoogste prioriteit. Daarom moet veel aandacht worden geschonken aan de methode om de faalkans van het produkt te bepalen. Het produkt moet aantoonbaar voldoen aan strenge eisen met betrekking tot faalkans.
Produktieproces
Naast de vraag wàt kwaliteit is, is ook van belang hóe men tot een kwaliteitsprodukt komt. Het produktieproces staat met andere woorden ook in de belanstelling. Eigenlijk geeft één principe daarbij de doorslag, namelijk first time right. Dit impliceert dat je niet alleen achteraf je produkten controleert op fouten, maar dat je het produktieproces beter beheerst. Hierdoor is op tijd bij te regelen in het geval van te voorziene fouten. Dit principe is al langer bekend in produktiebedrijven, waar de consequenties heel direct te zien zijn. Samen met afgekeurde produkten worden immers ook de grondstoffen en de menselijke arbeid die daarvoor gebruikt zijn, weggegooid. ‘Waarom afval produceren als je het toch weggooit,’ luidt de bekende spreuk van ‘Loesje’.
Ook in de IT-sector wordt een dergelijk kwaliteitsbesef steeds meer geconcretiseerd. Tot voor kort was het de gewoonte om softwareprodukten achteraf te testen. Zeker met grote en complexe projecten levert dat problemen op. Een project van enige omvang zou jaren tot tientallen jaren getest moeten worden om de meeste fouten te elimineren. Dit is een onwerkbare situatie, niet alleen vanwege de vele kosten in verband met het testen, maar vooral ook door de veel te late oplevering. De time to market van produkten wordt steeds belangrijker onder druk van de concurrentie.
De kwaliteit wordt derhalve gegarandeerd door beheersing van het ontwikkelproces. Dat het beheersen van het ontwikkelproces van softwareprodukten niet eenvoudig is, blijkt wel als men naar de resultaten van onderzoek op dit gebied kijkt. Een kwart van de grote softwareprojecten wordt voortijdig afgeblazen; een project duurt gemiddeld de helft langer dan verwacht, en driekwart van alle grote systemen blijkt in de praktijk veel ellende te bezorgen.
Los van de hoofdpijn die men soms krijgt bij het installeren van een printer, een pakket of een nieuw besturingssysteem, zijn er voorbeelden te over waar de software gewoon niet doet wat hij moet doen.
Hoe het ontwikkelproces beheersbaar en voorspelbaar gemaakt moet worden is uiterst moeilijk te bepalen. Eigenlijk moeten de wetenschappelijke grondslagen daarvoor nog ontwikkeld worden, zodat met mathematische modellen, bewezen ontwerpmethoden en gedegen kwaliteitscontroles een werkelijk professionele aanpak mogelijk wordt.
Andere, oudere takken van engineering kunnen vaak tot voorbeeld dienen. Bouwkundige constructies zijn nooit voor honderd procent perfect en veilig, maar uit de soms eeuwenlange praktijk is een soort ‘engineering-tolerantie’ ontstaan.
De huidige aanpak binnen de automatisering is nog te sterk afhankelijk van enkele begaafde software-ontwikkelaars en kan nog niet leunen op standaard ontwerpprocessen en standaard opleidingen, zoals in de civiele techniek. De laatste jaren hebben wetenschap en industrie wel stappen gezet in de goede richting. De inzet van formele methoden geeft al een juiste aanzet. Deze worden met name toegepast voor ingebouwde programmatuur in consumentenelektronica en projecten waar hoge betrouwbaarheid wordt geëist. Duidelijke handvatten voor praktisch inzetbare methoden en technieken geeft de norm IEC 1508. Deze gaat bijvoorbeeld in op technieken die fouten kunnen voorkomen, zoals toe te passen standaarden, notatiewijzen, nagaan van bekwaamheid van het personeel, opleidingseisen, specificatietools, risico-analyse en projectmanagement. Met behulp van de norm is een faalkans toe te kennen aan het produkt, afhankelijk van de gebruikte ontwikkelmethoden en -technieken.
Keurmerk
Toch blijft er behoefte bestaan aan een soort keurmerk van het produkt zelf. Ook al heb je het ontwikkelproces compleet onder de knie, het eindprodukt zal toch gekeurd moeten worden. Dit resulteert bij voorkeur in een hard getal voor wat betreft bijvoorbeeld faalkans en andere kwaliteitskenmerken als bruikbaarheid en openheid.
In het verleden zijn wel pogingen ondernomen tot het ontwikkelen van een keurmerk, maar die hebben nog steeds niet tot een werkbare methode geleid. Nog steeds is men bezig op dit gebied, zoals in het kader van het Esprit-project Space-Ufo; de verwachtingen zijn hooggespannen.
Deze noodzaak wordt steeds sterker gevoeld, zeker nu allerlei huis-, tuin- en keukenapparatuur voorzien wordt van ingebouwde programmatuur. Denk bijvoorbeeld aan de software die de batterij in een scheerapparaat of een tandenborstel in de gaten houdt. Of de software in een moderne televisie die twee kanalen op het scherm afbeeldt, een menu biedt om helderheid, kleur en geluid in te stellen of die bij defect raken de diagnose in een processor opslaat. Het rijtje kan eenvoudig aangevuld worden met wasmachines, videorecorders, stofzuigers, verlichtingssystemen, auto’s, enzovoort. Ingebouwde software moet bovenal logisch voor de gebruiker, betrouwbaar en foutloos zijn. Het klassieke excuus van programmeurs dat een softwareprodukt nu eenmaal altijd bugs bevat, die er met een volgende release wel weer uitgehaald worden, kan hier geen opgeld doen. Zo kan een fabrikant een paar maanden na het op de markt brengen van superstofzuiger 5.0 alweer genoodzaakt zijn om superstofzuiger 5.1 uit te brengen. De producent krijgt dan weliswaar gratis publiciteit voor het nieuwe produkt, maar wel aandacht die uitermate slecht is voor de reputatie.
Drs Rien Scholing is werkzaam als consultant Adviesgroep Informatiesystemen bij Tebodin, Consultants & Engineers, Den Haag
In het tweede en laatste deel van deze serie zal worden ingegaan op de vraag hoe een bedrijf zijn eigen kwaliteit kan bepalen en verbeteren.