Bij mijn werk als gerechtelijk deskundige ICT wordt in vaak geconfronteerd met verschil van mening over fouten in de geleverde of gerealiseerde software. De afnemer klaagt dat het “fout is” en dat er niet mee gewerkt kan worden, de leverancier geeft aan dat het standaard zo werkt, het conform de afspraak is die gemaakt is, de functionaliteit in orde is, of meer vergelijkbare interpretaties. En als ik hier schrijf “leverancier” en afnemer, dan kunt u ook lezen “gebruiker” en “ICT afdeling”, of “Functioneel ontwerper” en “Programmeur”, maar voor de leesbaarheid heb ik het hieronder over leverancier en afnemer.
Wat is een fout?
De eerste valkuil voor het omgaan met fouten is de ruimte voor verschillende interpretaties van het begrip.
Volgens het woordenboek is een fout: iets dat niet juist is, een vergissing, een ongerechtigheid, een dwaling, een mankement, een gebrek, een verschil tussen de theoretische waarde en de werkelijke waarde.
Als je deze betekenissen doorleest, dan begrijp je al snel dat er ruimte is voor verschillende interpretaties, zeker als er een waardeoordeel meespeelt, bijvoorbeeld het begrip mankement. Dit geeft het begrip fout een negatieve lading, Als ik in een gerechtelijk onderzoek het begrip fout tegenkom, dan gebruik ik liever een woord waarin het waardeoordeel grotendeels verdwenen is. De laatste definitie van het begrip fout hierboven (een verschil tussen theorie en praktijk) vind ik goed voorbeeld hiervan.
Los daarvan, op zich is een fout niet erg als beide partijen er allebei geen probleem mee hebben. Dus vermijd ik het woord fout en spreek in dit vervolg over een gebrek. En dit woord laat zich ook makkelijker vertalen: er ontbreekt iets, het is niet compleet, er wijkt iets af van wat verwacht wordt.
Geen fout, maar gebrek
Bij het onderzoeken van gebreken in de software, is het gewenst een objectief meetbare categorisering aan te houden voor de ernst van het gebrek en die categorisering vast te leggen:
Categorie: 1: Blokkerend – Gebreken die het testen van de programmatuur onmogelijk maken, dan wel een zodanig nadelige invloed op het functioneren daarvan hebben, dat het normale gebruik ervan in ernstige mate wordt verstoord.
Categorie 2: Belemmerend – Gebreken die weliswaar het gebruik van de Programmatuur als geheel of op essentiële functies daarvan niet onmogelijk maken, maar die dat gebruik wel aanmerkelijk nadelig beïnvloeden.
Categorie 3: Overig – Gebreken die het gebruik van de Programmatuur wel nadelig beïnvloeden, maar waarvoor aanstonds een (provisorische) oplossing gevonden wordt en overige gebreken, voor zover niet tot de 1- of 2- categorie behorend.
Categorie 4: Wijziging – Dit zijn gebreken die in het eindresultaat als gebrek gezien worden, maar aan het begin niet als functionaliteit was vastgelegd: voortschrijdend inzicht.
Expliciet kies ik ervoor om geen waardeoordeel in de categorisering vast te leggen, zoals ernstige of kleine fout, omdat zo’n waardebepaling de discussie aanwakkert en meningsverschil oproept.
Probleem weg?
Is men het dan vanzelfsprekend eens na het onderzoek over de gebreken die zijn geconstateerd? Was dat maar waar. Een deel van de angel is verdwenen, er is minder verschil van mening, maar uiteindelijk ben ik er dan voor om mijn oordeel als deskundige te geven en te rapporteren.
Heeft u suggesties voor andere indelingen? Ik hoor het graag…