Softwareontwikkeling terug naar “af”?

Het zal altijd wel een droom blijven: software die echt “af” is.

Maar dat kan en mag ons er niet van weerhouden te streven naar het opleveren van software die tenminste voldoet aan de eisen die we er gedurende de ontwikkeling aan hebben gesteld! Dat het beter kan (en ja, het kan altijd beter) wordt duidelijk als we weer eens worden geconfronteerd met berichten als “Door een computerstoring rijden er geen treinen tussen Utrecht CS en Amersfoort!”, computers die spontaan en niet reproduceerbaar “hangen”, en geld dat de Belastingdienst onbedoeld op uw bankrekening stort maar wel snel terug willen hebben!

Hoe kan het beter: allereerst door vanaf de eerste declaratie, coderegel of instructie in het achterhoofd te houden dat de software als deze klaar is alleen moet werken zoals vereist. De vereiste werking moet dan correct, eenvoudig, verifieerbaar en methodisch zijn beschreven, en regelmatig moet worden vastgesteld of de ontwikkelde software nog steeds de correcte werking heeft. Het helpt daarbij bijvoorbeeld als ontwikkelaars zich regelmatig afvragen of voor alle toegestane invoer de juiste resultaten worden opgeleverd. Het mooiste is natuurlijk dat voor iedere aanpassing een correctheidsbewijs wordt geleverd, maar natuurlijk zou de software dan nooit “af” komen! Iets meer correctheidsbewijs zou wel degelijk helpen!

Daarnaast is software tegenwoordig dermate complex dat het overzicht over afhankelijkheden met andere softwareobjecten snel verloren kan gaan. Het is dan zeker niet ondenkbaar dat nieuwe of aangepaste code onbedoelde effecten heeft op code die al lang “af” is. Dit pleit voor het liefst geautomatiseerd testen in samenhang zodat zo veel mogelijk wordt voorkomen dat onbedoeld onvolledig wordt getest.  Als leverancier van software loont het dan wellicht iets langer te wachten met Release To Market en iets meer tijd te besteden aan beter testen. Of je nu agile of anders ontwikkelt; testen is zoals bekend vaak het sluitstuk van ontwikkelcycli (het is immers niet zo leuk als ontwikkelen) maar  als je niet uitkijkt een voortdurend lekkende kraan van meerkosten voor de klant en de leverancier.

Waar trek je nu de grens tussen de spreekwoordelijke 80% die goed is en 20% waarvan je dat niet meer zeker wilt weten? Ga te rade bij de uiteindelijke gebruiker en zorg dat er geen fouten optreden die de gebruiker als ” vermijdbaar” ziet. Ook de gebruiker weet dat foutloze software niet bestaat maar wil wel dat de ontwikkelaar al het mogelijke heeft gedaan om vermijdbare fouten te voorkomen!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *