Meten is weten, zo wordt er verteld.  Doet software wel wat je belooft wat ze doet?

In enterprise applicaties is functionaliteit een belangrijk, maar vaak ook het gemakkelijkere deel van software ontwerp.  Zolang iedereen maar weet wat ie wilt: dat heeft meer  te maken met visie, duidelijke communicatie, verantwoordelijkheden en overleg, ethiek, eerlijkheid, psychologisch en sociologisch inzicht, dan met informatica.

Niet-functionele requirements (NFRs) zijn de uitdaging

De niet-functionele requirements maken software ontwerp echter moeilijk op een andere manier omdat ze niet dicteren wàt de software moet doen, maar hoé ze haar werk moet doen.  Behalve dat het verband tussen niet-functionele requirements en een ontwerp minder expliciet zijn (hoe druk je robuustheid van software formeel uit in functie van de geschreven code?), verhogen ze ook aanzienlijk de dimensionaliteit van het op te lossen vraagstuk. Het is niet moeilijk om snelle code te schrijven, het wordt moeilijk als ze ook functioneel correct moet zijn, hoogbeschikbaar, schaalbaar, elegant, uitbreidbaar, goedkoop in onderhoud en ga zo maar voort.

De vraag is: hoe kun je software leveren die een bepaalde beschikbaarheid belooft (bv. max. 8u downtime per jaar voor 99.9%) als je de beschikbaarheid nog nooit gemeten hebt? Of maar gedurende 3 maand in Acceptatie? Misschien had je geluk (goede statistische corner)? Is deze meting wel onder een realistische load gebeurd? Dezelfde redenering gaat op voor schaalbaarheid, fail-over, aanpasbaarheid, robuustheid, continuous operations, …

Meet de test de applicatie of omgekeerd?

Uit ethisch standpunt zou dus elke applicatie die in productie gezet wordt, rigoureus getest moeten worden op alle NFRs.  Hiervoor moet uiteraard test-software geschreven worden.  Essentieel hierbij is dat de test-software zeer goed geschreven en beheersd wordt, zodat we bij het verkijgen van een resultaat zeker weten dat deze beïnvloed werd door de applicatie en niet door de test.  Dit is de reden waarom test-apparatuur in elektronica zo duur is, bijvoorbeeld.

De arrogantie van de onwetendheid

Als een mens naar de wolken kijkt en zegt welke figuur zij/hij ziet, zegt dit meer over die persoon dan over de wolken. Niemand heeft de arrogantie om anders te beweren – waarom kunnen we dan niet hetzelfde bij software ontwerp?