Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

Waarom er nog altijd softwarefouten zijn

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4702800). © Jaarbeurs IT Media.
?

 

Reacties

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.

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.

Computable Expert
Wilbert van den Bliek

Wilbert van den Bliek
Algemeen Directeur SQS BeNeLux, SQS BeNeLux. Expert van Computable voor het topic Development.
Hele profiel

Gerelateerde artikelen:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×