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.
Tja Wilbert, je geeft zelf al bij herhaling aan dat er te weinig aandacht wordt besteed aan hoe software tot stand komt.
De discussie die nu ongetwijfeld volgt is gewoon een herhaling van de reacties die bij zoveel andere artikellen te vinden zijn.
http://www.examenvragen.info/tmap-next/tmap-samenvatting/tmap-productrisicoanalyse.html
zo moeilijk is het allemaal niet.
Titel stuk: Waarom er nog altijd softwarefouten zijn.
Antwoord heb ik niet in het stuk gevonden.
Risico analyses en inventarisaties lossen geen softwarefouten op. Ik zie dus al een mismatch tussen doel en middel. Dat belooft weinig goeds.
Dan het voorbeeld: RTL4-programma ‘Weet ik veel’ overbelast vanwege het hoge aantal deelnemers dat via de app wilde meespelen.
Dat is geen softwarefout, dat is een probleem met beschikbaarheid en dus weer… een mismatch.
Ik wil geen mauwerd zijn (ghe ghe), maar laat je stukken proeflezen door mensen die oprecht de inhoud kunnen beoordelen. Deel 2 is hiermee beter dan deel 1, maar dat was ook niet heel erg moeilijk. Twee keer niks is nog steeds niks.
Daarmee wil ik niet zeggen dat de 4 punten niet valide zijn, maar de context er omheen is gewoon niet goed waardoor de boodschap die je wilt brengen in mijn ogen niet goed overkomt. Beetje snijden en schaven, dan wordt het vast beter, want leesbaar is het in ieder geval wel!
Tja, in navolging van Reza ga ook ik me deze keer proberen in te houden en niet te reageren; auteur heeft nog geen één keer gereageerd op de reacties op zijn artikelen, dus ik ga me de moeite besparen
Softwarefouten zijn simpelweg niet te voorkomen. Op een paar wetenschappelijke experimenten na is het nog niemand gelukt om foutloze software te ontwikkelen. Het enige wat je kan doen is zoveel mogelijk fouten op te lossen door de tijd te nemen en moeite te doen om degene die praktisch gebruik in de weg staan op te sporen en te verbeteren.
Maar omdat er tegenwoordig wel erg makkelijk naar softwareontwikkeling wordt gekeken krijgen de ontwikkelaars en testers te weinig tijd om systematisch zaken aan te pakken.
Wat dat betreft ben ik het roeren met mauwert eens. Het hoeft niet zo moeilijk te zijn.
ik neem aan dat het volgende deel gaat heten:
waarom er altijd software fouten zullen blijven…
De reden dat software nog steeds barst van de fouten is dezelfde als de reden waarom er nog steeds gebouwen instorten. Dat is niet omdat het onmogelijk is om robuust te bouwen, maar het heeft alles te maken met zo snel en goedkoop mogelijk bouwen en opleveren. De verantwoordelijken zeggen liever dat fouten nu eenmaal onvermijdelijk zijn, dan dat ze zeggen dat ze er om kosten te besparen met de pet naar hebben gegooid. IT-ers doen vrolijk mee: zij zeggen ook liever: “foutloze software bestaat nu eenmaal niet” en niet: “ik had geen zin om vooraf goed na te denken en achteraf uitgebreid te testen”.
Volgens mij is het dan ook vooral een mentaliteits- en geldkwestie en geen technische onmogelijkheid. In de bouwwereld hebben ze dat aangepakt door voorschriften en toezicht. Zoiets zou ook goed zijn voor de it-wereld, maar daarvoor zullen er eerst nog wat meer it-rampen moeten gebeuren.
Beste Wilbert,
Jouw blog heb ik met veel plezier gelezen. Een duidelijk en herkenbaar verhaal!
Ik ben wel benieuwd naar jouw derde blog waarin je ingaat op maatregelen. Ik hoop dat je daarvoor opnieuw terugvalt op je eigen praktijkervaring en verder gaat dan de theorie zoals TMap die geeft. Op dat gebied heb ik al vele publicaties gezien, maar blijven theoretisch van aard. Ik ben dus op zoek naar maatregelen die zich wel in de praktijk hebben bewezen. Ik kijk ernaar uit!
Ik mis de economische reden. Hoeveel kost het volledig doortesten t.o.v. de kosten van herstel in productie. Zeker wanneer het projectbudget op raakt, wordt er nog weleens gekozen om eventuele fouten dan maar later vanuit het lijnsupport te herstellen.
Daarnaast maak ik ook nog regelmatig mee dat men gewoon de gestelde deadline wil halen en dan dus maar met de welbekende ‘know issues’ in productie gaan. Doen de meest gerenomeerde software houses ook, niet voor niets zegt men weleens gekscherend, ik wacht wel totdat het eerste service pack beschikbaar is.
@Willem: Goed punt.
Snel, Goed en Goedkoop. In een IT-project kun je er maar maximaal twee krijgen.