Softwarefouten zijn nooit helemaal te voorkomen. In een vliegtuig zitten bijvoorbeeld gemiddeld nog honderden kleine foutjes in de software die niet direct voor gevaar zorgen. Het is dan ook zaak de grote fouten die tot de meeste schade kunnen leiden tijdens de ontwikkelfase op te sporen. Waar het in bij een vliegtuig om de veiligheid van mensen gaat, is vaker economische schade het gevolg. Hieronder drie gevallen rondom de handel in aandelen.
440 miljoen dollar verlies in 45 minuten
De nieuw geïnstalleerde software van een beurshandelaar heeft voor een schadepost van 440 miljoen dollar gezorgd in 2012. Met het systeem kan in drie kwartier grote hoeveelheden aandelen aan- en weer worden verkocht. Een fout in een software-algoritme zorgde ervoor dat de aandelen tegen een marktprijs werden verworven om vervolgens tegen een lagere prijs te worden verkocht. Op deze manier werd op elke transactie een paar dollarcent verloren. Door de levendige handel werd de prijs van de aandelen omhoog gestuwd. Het leidde uiteindelijk tot een gigantisch verlies voor de beurshandelaren, omdat ze noodgedwongen de tijdelijk overgewaardeerde aandelen tegen een lagere prijs moesten verkopen.
Beursgang gaat niet door
Een onderneming zag zich in 2012 gedwongen de geplande beursintroductie via het eigen handelssysteem af te breken. Oorzaak was een grote fout in de software, die leidde tot een technische storing op het eigen handelsplatform. Het probleem deed zich direct voor op het moment dat de beurs wilde overgaan tot de emissie van de aandelen en niet de normale handelsroutine kon volgen. Hierdoor kwam de handel in de aandelen al stil te liggen voor die goed en wel begonnen was.
Beursgang met hindernissen
Technologische problemen hebben ervoor gezorgd dat de handel in aandelen van een grote social netwerksite in 2012 ernstige hinder ondervindt. Naderhand wordt duidelijk dat een softwarefout er de oorzaak van is dat biedingen en annuleringen niet correct of zelfs helemaal niet worden verwerkt. Deze uitglijder zorgde ervoor dat uiteindelijk niet minder dan dertig miljoen aandelen niet op de juiste manier zijn afgehandeld.
Dit is een eerste blog in een serie over de schade die kan ontstaan als het gevolg van fouten in de software.
@all.
Auteur houdt het simpel.
Dat zouden meer mensen moeten doen
Inhoudelijk mag dit artikel niet sterk zijn, het maakt wel de discussie los. Wellicht is de reden dat het een inleidend stukje is en dat opzettelijk wat lichter is gehouden.
Voor de schrijver nog een aantal interessant punten mocht deze inspiratie nodig hebben.
Qua fouten kan je je afvragen of de gemiddelde gebruiker inmiddels niet is gewend dat computers fouten hebben en dat je daar maar mee moet leren leven. De gemiddelde 1.0 versie tegenwoordig heeft vaak nog meer fouten dan je van een beta versie zou mogen verwachten.
Maar bij de gevallen van medische technologie, vliegtuigen waar het toch fout ging waren er altijd redelijk zware eisen gesteld aan de kwaliteit van de software en waren deze wel degelijk uitgebreid getest maar toch ging het fout.
In diverse laboratoria opstellingen en een enkel praktijk geval zijn er wel degelijk projecten die een 100% werking garanderen alleen blijven deze voorbeelden vaak op de plank liggen.
@hk: Als het per se simpel moet is NuJij wellicht de site voor jou 😉
Gekheid, maar van de reactie van Ewout wordt ik heel blij en zet me aan het denken.
Als “platform” vind ik dit soort artikelen als incident geen bezwaar, maar als trend verwaterd het wel de waarde van de site, een reden waarom ik nauwelijks meer op bijvoorbeeld een webwereld.nl kom. Niet dat alle artikelen daar slecht zijn, er zit soms hele goede tussen, maar ook veel rommel met dito reacties waardoor ik mijn interesse verloren ben en de goede artikelen missen dan maar voor lief neem.
Reza had een paar keer al wat auteurs aangesproken op het niet reageren op eigen artikelen waardoor de auteurs alsnog overstag gingen en er *wel* een goede discussie volgde.
Nouja laten we hopen op een spetterend vervolg van dit artikel waarbij alle kritiek verstomd. Kritiek geven mag toch? Houdt ons wellicht scherp, zolang het maar onderbouwd is en geen reageren om het reageren.
Kijk, weer een voorbeeld van een artikel waarin de afwezigheid van de auteur, een stuurloze discussie veroorzaakt heeft. Laten we het een keer hebben over de kwaliteit van de artikelen en ook de site!
@Henri, leuk dat je mijn actie gewaardeerd hebt! En leuk te zien dat een collega opiniehouder dit waardeert terwijl de redactie met 2x sterren minder waardering getoond heeft!
Zolas eerder gezegd, ik ben ook benieuwd naar het volgende artikel in deze serie!
@Ewout
Eigenlijk is het een taak van de redactie om dit soort (te oppervlakkige) verhalen direct terug te sturen naar de auteur.
@ Reza
als je uitrekent wat er aan ** uitgedeeld is tussen oktober 2012 en een paar weken geleden dan is dat in ~97% van de gevallen 3* de rest is of 2 en soms soms 4, kortom:
@Redactie schaf het ***dom af, u doet er niets mee gezien de scorecijferontwikkeling over de afgelopen maanden. Neem dan die tijd die daardoor “vrijkomt” voor een initiële kwaliteitsbeoordeling van wat dus wellicht geplaatst wordt.
Dat voorkomt “advertorials”, te oppervlakkige stukjes en geeft wellicht ook nog zinvolle reacties, waardoor het geheel beter gewaardeerd zal worden door de lezer en wellicht daarna door de adverteerder.
@Maarten,
Het mee eens! Al lang roep ik dat de kwaliteit van deze site op verschillende punten verbeterd moet/kan worden. Deze hoeft niet perse geld te kosten als er maar een doordacht beleid ingevoerd is.
Computable.nl heeft alles om deze site interessanter te maken. (https://www.computable.nl/artikel/nieuws/ictbranche/4673648/2379258/computable-werft-magazineabonnees.html#4677083)
En wat betreft de sterren, tja als ik er gek op was dan had ik al lang geleden die op de grille van mijn auto NIET ingeruild voor een italiaanse schoonheid! 🙂
waar software fouten toe kunnen leiden …
een discussie over *** en de kwaliteit van de artikelen in computable
Ik weet zeker dat de auteur dit nooit bedacht heeft kunnen hebben 😀
@PaVaKe
Software fouten is alleen maar een inperking van het begrip “fouten” door er software voor te zetten. Software op zich is niet echt fout, het is meestal de volgorde die niet goed is of de gedachte er achter, dus de stap naar sterren is eigenlijk maar een hele kleine, want dat is namelijk ook fout zoals het ingezet wordt.
Auteur beschouwt softwarefouten als nooit helemaal te voorkomen.
Ik denk dat dit niet waar is.
Belangrijk daarbij is te bedenken wat je als uitgangspunt kiest voor de te ontwikkelen software. Als dit goedgekeurde requirements zijn en, op basis daarvan, een goedgekeurd FO, dan kan het zo zijn dat de software feitelijk foutloos wordt gerealiseerd, maar uiteindelijk toch niet doet wat de gebruiker er van verwachtte. Iets dat afwijkt van de verwachting is dus niet per definitie fout. Hooguit fout beschreven.
Software die een verkeerd algoritme bevat kan verkeerde input hebben gekregen. Zeker bij bedrijfskritische applicaties is het van belang dat dit stap voor stap wordt gecontroleerd en, na realisatie, stap voor stap, wordt getest.
De eerste reeks controles moeten uitsluiten dat verkeerde input wordt geleverd. De tests moeten uitsluiten dat verkeerd geprogrammeerde software in productie wordt genomen. Zoals Numoquest al zei: het is I/O
Het 100% uitsluiten van fouten is een kostbare zaak, want arbeidsintensief, maar zeker niet onhaalbaar en bovendien afhankelijk van de complexiteit van het te ontwikkelen programma. De vraag zal uiteindelijk altijd zijn welk risico je bereid bent te lopen.
Heel veel problemen zijn terug te voeren op het vakgebied Human Error. Ik liep hier voor het eerst tegen aan toen ik een afstudeeronderzoek deed naar de risico’s van spreadsheetgebruik binnen een organisatie.
Ray Panko is de goeroe op dit gebied. Zijn website ziet er niet uit, maar bevat wel interessante artikelen: http://panko.shidler.hawaii.edu/HumanErr/