In mijn vorige blog 'Waar softwarefouten toe kunnen leiden' had ik het over de schade die kan ontstaan door softwarefouten. Ik haalde voorbeelden aan waarbij een softwarefout leidt tot vele euro’s schade of fouten die zelfs levensbedreigend kunnen zijn. De vraag dringt zich dan al snel op waarom deze fouten niet worden voorkomen.
In deze blog wil ik deze vraag beantwoorden door op zoek te gaan naar de oorzaak van softwarefouten. Ik doe dit aan de hand van probleemstellingen die ik in de afgelopen jaren regelmatig ben tegengekomen bij verschillende organisaties.
We kennen allemaal wel het statement dat software nooit honderd procent foutvrij is. Bij testen draait het er dan ook vooral om vast te stellen dat de software op de belangrijkste aspecten volgens verwachting functioneert. Om te kunnen bepalen wat de belangrijkste aspecten zijn, moeten ze worden vertaald naar productrisico’s. Vervolgens ga je vaststellen in welke mate je deze productrisico’s kunt afdekken binnen de beschikbare middelen van budget, tijd en resources.
Vier probleemstellingen
In de praktijk blijkt deze focus op productrisico’s lastig te zijn. De beperkte doorvertaling naar productrisico’s is mijns inziens één van de belangrijkste oorzaken dat softwarefouten met een grote impact optreden. De problematiek van productrisico’s is op te delen naar vier probleemstellingen:
1. Organisaties hanteren een aanpak die niet is gebaseerd op productrisico’s.
Het gevolg is dat veel aandacht wordt besteed aan een beperkt aantal risico’s en dat andere belangrijke productrisico’s niet zijn afgedekt. Dit kom ik vooral tegen bij organisaties waar testen en kwaliteitszorg niet of in beperkte mate worden toegepast.
2. Er is wel een productrisicoanalyse uitgevoerd, maar het grootste deel van de risico’s zijn gelijk geprioriteerd.
In veel gevallen ligt hier de betrokkenheid van een gevarieerde groep met stakeholders aan ten grondslag. Iedere stakeholder benadert de risico’s vanuit zijn eigen belang, waardoor veel risico’s op hetzelfde totaalgemiddelde uitkomen. Daarbij geldt dat het vaak een hoog gemiddelde betreft, omdat het besluit om een risico laag te prioriteren in de praktijk vaak moeilijk ligt. Het gevolg is dat de risico’s een gelijke aandacht krijgen en dat er geen mogelijkheid meer bestaat voor een diepgaande controle op de belangrijkste risico’s.
3. Een risico-inventarisatie is uitgevoerd, waarbij vooral is gelet op de productieschade.
Met andere woorden, we redeneren vanuit een situatie dat een incident optreedt in productie, waarbij de impact die deze fout heeft wordt uitgedrukt in de hoeveelheid financiële schade, imagoschade, enzovoort. Het probleem bestaat eruit dat in de risico-inventarisatie geen aandacht is voor de kans op falen. Denk bijvoorbeeld aan de complexiteit van de programmatuur, doorwerking van wijzigingen in de softwareketen en het ervaringsniveau van de programmeurs. Hoge risico’s op de faalkans worden onvoldoende afgedekt.
4. Een risico-inventarisatie is vooral gericht op de functionele werking van de software.
Er is onvoldoende aandacht voor aspecten als onderhoudbaarheid, security, portabiliteit en performance. Om een voorbeeld te noemen, een aantal weken geleden bleek de app van het RTL4-programma ‘Weet ik veel’ overbelast vanwege het hoge aantal deelnemers dat via de app wilde meespelen.
In mijn volgende blog wil ik ingaan op de maatregelen die we kunnen nemen om deze oorzaken te bestrijden.
Dit is een tweede blog in een serie over de schade die kan ontstaan als het gevolg van fouten in de software.
Ik heb niet zo veel geleerd, moet ik zeggen. Wel mis ik een en ander. Veel risico’s zijn geduid en worden bewust genomen, omdat de kosten niet opwegen tegen de baten. Het is mij niet duidelijk of de overbelasting van/door de app van het RTL4-programma ‘Weet ik veel’ niet van te voren is ingecalculeerd. Externe factoren hoor ik hier ook niets over. Software draait altijd onder een besturingssysteem, op hardware, met diverse interfaces etc. stroomvoorzieningen etc. Al deze externe factoren vormen ook risico’s, een aanpassing bij 1 van de externe factoren na oplevering, al dan niet bij of door een externe partij vormen ook risico’s. Zijn dat initiële software fouten?
Goede testscenario’s en uitgebreide risico analyses leiden uiteindelijk tot risico’s die bewust genomen worden vanuit strategisch en/of bedrijfseconomisch oogpunt.
“Waarom zijn er nog altijd software fouten”, dat was de vraag waarop, naar ik aanneem, Wilbert een antwoord op zoekt. Welnu Wilbert, uit mijn vorige reactie blijkt dus al e.e.a.
Gevolgen door invloeden en wijzigingen van externe factoren bij het functioneren van bestaande software, zonder vooraf geïnformeerd te worden, zijn niet te duiden als software fouten. Updates en nieuwe versie van Microsoft Windows zorgen al jaren voor problemen met plots disfunctioneren van hardware, randapparatuur, software en last but not least, zelfs Microsoft Applicaties plots “fouten” lijken te bevatten. Bij ondernemingen met veel exotische techniek (randapparatuur) is een uitrol van elke Microsoft release/update niet bedrijfsbreed te testen. (KPN, ziekenhuizen, Philips, laboratoria etc. etc.). Deze risico’s zijn eventueel te reduceren met behulp van goede rollback scenario’s en/of schaduwdraaien voor x periode. Maar ook het tijdstip van wijzigingen bij externe factoren zijn niet altijd vooraf bekend, en er is dan ook geen sprake van een software fout maar falen van communicatie bij de externe factoren.
Laten we Schiphol overkappen met bomvrij dak, dan kunnen er ook geen bommen op vallen, “oeps” vergeten dat de vliegtuigen niet meer kunnen op stijgen en/of landen………..
Het is allemaal geen rocket science, wat nodig is is gezond verstand, projectmanagement/test tool(s) en protocollen om risico’s te reduceren. De vraag die boven het artikel gesteld wordt is wat mij betreft te vergelijken met “Waarom zijn er nog altijd auto’s die niet 100% veilig zijn en geen onderhoud behoeven?”
Software wordt gemaakt door mensen. Mensen maken fouten. Dus software bevat fouten. Fact of life.
Ik mis in dit deel de ‘bullit’ dat softwarefouten ook te wijten zijn aan onvoldoende professionele software ontwikkelaars zelf. Wie herkent niet de situatie dat fouten in software je ernstig doen denken aan eerdere fouten die je bent tegengekomen?
Daar waar in enkele reacties al wel ingegaan wordt op de hogere kosten van herstel (bv door uitgebreid testen), is evident dat het voorkomen van softwarefouten door professionele ontwikkelaars per definitie een positieve business case oplevert. Maar de vraag blijft natuurlijk wel hoe je een professionele software ontwikkelaar wordt. Wellicht biedt PSP je een oplossing: http://en.wikipedia.org/wiki/Personal_software_process. Maar daarmee loop ik vooruit op het volgende artikel van Wilbert lijkt me.
Ja herkenbare situaties, maar met het creëren van lijsten om de risico’s in kaart te brengen zullen waarschijnlijk wel iets gaan helpen. Maar het is niet de oplossing of een maatregel om fouten in software te voorkomen.
Het heeft veelal te maken met tijd en geld, waardoor kwaliteit meestal het kind van de rekening is.