Security

Betere software door product- of proceskwaliteit

Joris is 15 jaar geleden gestart met een ICT-bedrijf dat maatwerkapplicaties ontwikkelt. Joris wil zijn klanten kwaliteit bieden en natuurlijk ook wat verdienen. Tot op heden gaan de zaken goed. Maar toch,… er zijn nogal wat incidenten. Daarvan wordt Joris niet vrolijk.

Zo zijn er heel wat klanten die klagen over te late opleveringen. En als de software is opgeleverd en de klant de applicatie gaat gebruiken, dan zijn er geregeld discussies over hoe het systeem werkt. De klanten hebben het over fouten in het systeem. 

Joris stelt vast dat de oorzaken heel divers zijn. Soms heeft de klant verkeerde informatie gegeven, soms ligt het aan de manier waarop het systeem wordt gebruikt, soms is het gebrekkige kennis bij de gebruikers van het systeem, en regelmatig is het een fout in het ontwerp of in de programmacode. Joris heeft al veel geïnvesteerd in het testproces en in opleidingen van zijn medewerkers. Eigenlijk vindt hij dat het testen wel heel veel tijd kost en vooral ook het oplossen van de gevonden fouten is erg tijdrovend. Dit kost hem een groot deel van de begrote winst. en daarnaast extra doorlooptijd. Dat leidt dan weer tot telefoontjes van ontevreden opdrachtgevers. 

Joris besluit deze problemen aan te pakken en zich te onderscheiden van zijn concurrenten door wel altijd op tijd op te leveren en te streven naar een 8 van zijn klanten voor de producten die hij oplevert. De vragen die hij zich stelt zijn: Welke kwaliteit willen mijn klanten? Hoe spreek ik dat af? En vooral: Hoe zorg ik ervoor dat mijn organisatie die kwaliteit dan ook levert? Joris gaat op onderzoek uit en vindt informatie op internet, in de literatuur en bij collega’s. 

Wat is kwaliteit? 

Kwaliteitsbeleving is heel subjectief. Wat de één belangrijk vindt, is voor de ander irrelevant. Hetzelfde product wordt door de ene consument als heel goed ervaren, terwijl een ander het volstrekt waardeloos vindt. Kwaliteit is geen eenduidig begrip. Er zijn volgens Garvin vijf soorten definities van kwaliteit te onderscheiden: 

  • transcendente definities: 
    Dit is een benadering vanuit een ideaalbeeld, een uitmuntendheid die niet gedefinieerd kan worden. 
  • productgebaseerde definities: 
    Kwaliteit is meetbaar door het vaststellen van de kwantiteit waarmee bepaalde eigenschappen of kenmerken in het product voorkomen. 
  • klantgerichte definities: 
    De behoeften van de consument staan centraal. Het gaat hier om de mate waarin die behoeften bevredigd worden. 
  • productiegerichte definities: 
    Deze benadering gaat uit van het gezichtspunt van de producent. Het gaat om de mate waarin een product voldoet aan de specificaties. 
  • waardegerichte definities: 
    In deze benadering wordt gekeken naar de prijs/prestatie verhouding: komt de waarde van het product overeen met de prijs? 

Praten over kwaliteit gaat dan ook nergens over zolang je het begrip kwaliteit geen handen en voeten hebt gegeven. 

Nou, dat helpt, maar niet heus. Als Joris erover gaat nadenken komt hij erachter, dat zijn klanten heel divers zijn in hun eisen- en wensenpakket. De één vindt het essentieel dat de nieuwe applicatie op tijd wordt opgeleverd, omdat die nodig is voor een groot verandertraject. Een ander wil dat het systeem heel gemakkelijk te gebruiken is, omdat er veel met flexwerkers wordt gewerkt. Daarnaast is het zo dat alle klanten verwachten dat het systeem het “gewoon doet”, dat alles een beetje snel werkt en dat het dezelfde “look & feel” heeft als gangbare marktproducten. Joris komt tot de conclusie dat hij “de” kwaliteit vooral ook zelf moet definiëren; als leverancier wil hij kunnen instaan voor zijn producten. Verder zijn er klantspecifieke kwaliteitseisen. Wellicht is het zinvol daarvan een checklist te maken om ze te inventariseren. Dan is de kans dat er wat wordt vergeten een stuk kleiner. 

Proces of product? 

Hoe kun je er als organisatie voor zorgen dat je producten en diensten de gewenste kwaliteit hebben? Er zijn twee benaderingen denkbaar: 

  1. productgerichte controle: 
    Van elk product wordt expliciet vastgesteld of het voldoet aan de eisen. Dat betekent dus dat: 
    1. de eisen  bekend moeten zijn, 
    2. de eisen toetsbaar gemaakt moeten zijn, 
    3. er een controlemechanisme moet zijn ingericht. 
  2. beheersing van het proces: 
    Er wordt geproduceerd volgens beheerste en gecontroleerde omstandigheden; het productieproces is dermate onder controle dat de producten “automatisch” voldoen aan de gestelde eisen. 

Het huidige kwaliteitsdenken stimuleert een procesbenadering. De gedachte is dat als een organisatie het proces beheerst, de resultaten van dat proces betrouwbaar zijn. Dit denken komt voort uit de systeemtheorie (zie figuur). 

In de figuur wordt de organisatie afgebeeld als een proces dat input (van leveranciers) transformeert naar output (voor klanten). Het proces wordt bestuurd met behulp van informatie over de input, het proces en de output. Het besturend orgaan regelt dat het proces wordt bijgestuurd als dat nodig is. 
ISO 9001:2008 is een voorbeeld van een kwaliteitsnorm die het procesdenken sterk stimuleert. De norm stelt dat de vele onderling verbonden activiteiten bestuurd moeten worden. Een kwaliteitsmanagementsysteem dat gebaseerd is op de procesbenadering verhoogt de klanttevredenheid door op een efficiënte wijze te voldoen aan de eisen. 
Meestal is er sprake van een combinatie van productcontrole en procesbeheersing. De optimale mix is sterk afhankelijk van: 

  • het soort product / dienst; 
    In de sector van bij voorbeeld olie, gas, chemicaliën, energie en glas (zogenaamde procesindustrie) ligt het accent sterk op procesbeheersing. Maatwerkproducten zoals installatietechniek en ICT liggen aan de andere kant van het spectrum. Omdat elk maatwerkproduct uniek is, dient er aandacht te zijn voor controle van de individuele producten. 
  • de volwassenheid van de organisatie; 
    Een onvolwassen organisatie heeft geen strakke processen en besturing, er wordt veelvuldig ad hoc gehandeld. Er kan dan door alleen procesbeheersing (voor zover dat überhaupt lukt) geen garantie worden gegeven op de kwaliteit (betrouwbaarheid) van producten. Hoe volwassener een organisatie is, hoe minder productcontroles nodig zijn (natuurlijk nog steeds afhankelijk van de aard van de producten).  
  • de beschikbare methoden en technieken; 
    Niet alle methoden en technieken voor controle / beheersing zijn voor elk product, c.q. elke branche toepasbaar. 
  • de gewenste zekerheid dat elk product volledig aan de eisen voldoet; 
    Productcontrole geeft, normaliter, meer zekerheid over het individuele product. 
  • het budget. 
    Productcontrole is in het algemeen duurder dan procescontroles. 

Joris denkt diep na. Hij heeft zich gespecialiseerd in maatwerkapplicaties. Elk product dat hij maakt is uniek. Door middel van gestructureerde testen stelt hij bij elk product opnieuw vast of de applicatie doet wat ze doen moet. Een aantal jaren geleden heeft hij met behulp van TMap zijn testprocessen verbeterd. Probleem is nog wel dat niet van te voren altijd goed is afgesproken aan welke kwaliteitseisen elke applicatie moet voldoen. Daar valt nog wel wat te verbeteren. 
En Joris vraagt zich af of hij ook niet meer moet doen aan procesbeheersing. Immers de kosten van het testen, en zeker de herstelkosten daarna, zijn een bron van zorg. Joris gaat verder op zoek. Met succes. 

Productkwaliteit 

Dezelfde Garvin die de perspectieven van het begrip Kwaliteit heeft beschreven, heeft ook een model opgesteld om productkwaliteit te beschrijven. Hij kiest hiervoor acht dimensies. 

  1. prestaties: 
    de primaire productattributen. Verschillende producten kunnen naar kwaliteit worden gerangschikt op basis van bepaalde prestaties. 
    Bij voorbeeld een auto: vermogen, verbruik, comfort. 
    Niet alle prestatieverschillen zullen echter als kwaliteitsverschil ervaren worden; 
  2. (overige) kenmerken: 
    de secundaire productkarakteristieken, opties of bepaalde bijkomstige attributen 
    Bij een auto: metaalglanslak, open dak, radio; 
  3. betrouwbaarheid: 
    de waarschijnlijkheid dat een product gedurende een bepaalde periode foutloos functioneert; 
  4. conformiteit: 
    de mate waarin de werkelijke eigenschappen van een product overeenstemmen met de beschrijving ervan in een offerte, standaard, catalogus, etc. oftewel de mate waarin een product ‘binnen specificaties” is. Dit is meestal objectief meetbaar; 
  5. duurzaamheid: 
    de mate en duur van gebruik voordat het product slecht(er) begint te functioneren; 
  6. onderhoudbaarheid: 
    de snelheid en het gemak waarmee onderhoud of een herstelling kan worden uitgevoerd. 
  7. esthetische waarde: 
    hoe voelt, smaakt, klinkt ruikt een product. Dit is zeer subjectief; 
  8. ervaren kwaliteit: 
    subjectieve perceptie van de kwaliteit van een product, gevormd door imago, reclame, verpakking, merkbekendheid, reputatie. Hierdoor wordt de kwaliteit van merkproducten hoger ingeschat dan die van merkloze producten. 

Per bedrijfstak kun je productkwaliteit specifieker rubriceren. Als voorbeeld het product “software”. Velen hebben moeite het begrip software überhaupt te definiëren (gaat het om de executable, is het inclusief broncode, hoort documentatie erbij, moet het ook werken, etc.). Nog lastiger is het om de kwaliteit te definiëren: de ISO 9126 norm bevat een model voor het definiëren van softwareproductkwaliteit. Deze norm onderscheidt 6 hoofdeigenschappen, verder uitgewerkt tot 32 eigenschappen in het extended ISO 9126 model. 

Mooi, denkt Joris, hiermee heb ik een checklist om onze eigen kwaliteitsstandaard te definiëren en om de klantspecifieke kwaliteitseisen te bespreken. En hij zoekt weer door en vindt. 

Meer weten of informatiebeveiliging of onze software oplossingen?

Tussentijdse controles of eindcontroles 

Alleen eindcontroles uitvoeren is erg duur. Veel producten worden afgekeurd en worden weggegooid of hersteld. Vaak is het veel effectiever om tussentijdse productcontroles uit te voeren. Herstelkosten nemen exponentieel toe naarmate een fout later wordt ontdekt.

Böhm heeft ICT-projecten onderzocht en gemeten hoeveel goedkoper het is om in een vroegtijdig stadium fouten op te sporen en te herstellen dan tijdens het gebruik, Zo blijkt het een factor 40 tot 100 goedkoper te zijn om tijdens de requirementsanalyse een fout te herstellen dan tijdens productie.
Een veel gebruikte manier om de kwaliteit van tussenproducten te verbeteren bij software ontwikkeling is de reviewtechniek. Er zijn verschillende redenen om reviews toe te passen. De voornaamste is evalueren van opgeleverde tussen- of eindproducten. Daarnaast worden reviews ook gehouden om ideeën uit te wisselen en om consensus (draagvlak) te verkrijgen voor deze ideeën. Nog een andere reden is anderen informeren over een bepaald product, eventuele problemen bloot leggen en mogelijke oplossingen bespreken. 
Voor reviews op specificerende documenten (zoals bij voorbeeld requirements, architecturen en ontwerpen) bestaan diverse reviewtechnieken. De meest uiteenlopende zijn: 

  1. distributie voor commentaar 
    Als de auteur klaar is met zijn document, stuurt hij dit rond naar een aantal mensen met de vraag om hierop te reageren. Sommigen reageren met commentaren en anderen niet. Dat hangt af van de tijd die men heeft, van het onderwerp en van de persoon die verstuurt. Het kan leiden tot verbetering van het document maar zeker is dat niet. Belangrijkste functie lijkt vaak dat men geïnformeerd is en het recht verspeeld later commentaar te hebben op het stuk. 
  2. Fagan inspectie 
    Deze gestructureerde werkwijze is bedoeld om fouten in de documenten te vinden. Een document wordt aan diverse mensen verstrekt, met ieder een eigen taak b.v. toetsen op taalfouten, op consistentie met brondocumenten, op toepassing van de afgesproken methode en het format, op bruikbaarheid voor de vervolgstap etc. 
    De review is niet vrijblijvend. De deelnemers bespreken het document in een sessie onder leiding van een facilitator. De fouten worden systematisch vastgelegd. Het aantal fouten wordt gebruikt voor het goed- of afkeuren van het betreffende document. Goed toegepast geeft deze techniek een kwantitatieve kwaliteitsindicatie van het document. 

Dit spreekt Joris aan. Veel problemen bleken achteraf te liggen aan onduidelijke afspraken met de klant. Joris besluit direct om elke uitgevoerde requirements analyse te laten reviewen door 2 senior medewerkers. 

Proceskwaliteit 

De bedoeling van proceskwaliteit is om op consistente wijze goede producten en diensten te maken, door een goede beheersing van de werking van de processen. Hoe ”goed” is het proces: 

  • gedefinieerd; 
  • beschreven; 
  • geïmplementeerd; 
  • gemeten; 
  • bestuurd; 
  • geborgd; 
  • verbeterd? 

Het centrale paradigma is, dat productkwaliteit niet bepaald wordt door de eindcontrole (bij voorbeeld de acceptatietest), maar door het gehele voorgaande proces. Veel kwaliteitsliteratuur gaat dan ook over de inrichting van processen. 
De ISO 9001 norm beschrijft aan welke minimale normen de processen in een organisatie dienen te voldoen om een gegarandeerde kwaliteit te kunnen leveren. Dit blijft redelijk basaal. De processen dienen beschreven te zijn, de procedures moeten geaccordeerd zijn en de processen moeten aantoonbaar geïmplementeerd zijn. Je hoeft vaak geen grote organisatorische veranderingen door te voeren om hieraan te voldoen. Een belangrijke eis in ISO 9001:2008 is om continu met verbetering bezig te zijn. 
Voor de IT-sector is een CMMi een goede standaard voor proceskwaliteit. Het primaire doel hiervan is de processen te identificeren en te definiëren die essentieel zijn voor software engineering, en die daarom geëvalueerd moeten worden om de volwassenheid van de organisatie vast te stellen. 

Herken je deze Joris? 

Inmiddels is het 1 jaar later. Joris heeft de plan do check act cyclus een aantal keren doorlopen. Het requirements management proces loopt nu uitstekend. Joris heeft hiervoor gebruik gemaakt van het CMMi model en wel het onderdeel Requirements Management (REQM). Vooral het managen van de requirements tijdens het project is in het verleden niet goed gebeurd. Wijzigingen van de eisen van de klant werden wel afgesproken maar niet goed beoordeeld op de impact. Dit gebeurt nu wel goed. 
Het effect van het verbeteren van het requirements management proces is dat de laatste opleveringen perfect naar de zin van de klanten waren. Zij vertellen nu zelfs aan andere organisaties hierover. Dat schiet tenminste op. 

Ben je nog niet zover? Joris denkt intussen alweer na over een volgende stap. Want wat hij nu heeft bereikt wil hij natuurlijk ook zo houden. 

Actueel

Gerelateerd nieuws

09/04/2026

Werken terwijl de wereld slaapt: de risico's van nachtwerk

Lees verder
07/04/2026

Kader organiseert twee webinars over sociale veiligheid

Lees verder

De herziene EED-richtlijn: dit zijn de gevolgen voor je organisatie

Lees verder