Fouten in software kosten soms ongelooflijk veel geld en kunnen desastreuze gevolgen hebben, zoals de explosie van de Ariane-raket vorig jaar aantoonde. Volgens softwareconsultant Les Hatton moet de oorzaak gezocht worden in de lichtzinnigheid van de systeemontwikkelaar, die niet leert van het verleden.Hij ontkracht een aantal misvattingen over software-ontwikkeling en geeft tips om fouten te vermijden.
In het vertrek waar we softwareconsultant Les Hatton spreken, rent een klein kind voorbij. We hebben zojuist uitgebreid gesproken over de gevaren van softwarefouten, over de mogelijke oorzaken, over schijnoplossingen en over modegrillen in software-ontwikkeling. "Je moet je toch niet voorstellen dat zo’n kind", zegt Les Hatton plotseling, "het slachtoffer wordt van fouten in de software, bijvoorbeeld in een vliegtuig." In een wereld die steeds meer afhankelijk wordt van software is dat immers niet langer denkbeeldig.
Les Hatton is directeur van Programming Research Ltd en geeft adviezen op het gebied van softwarekwaliteit. Ook doet hij onderzoek en publiceert hij regelmatig. Recent verscheen van zijn hand ‘Safer C’, een boek waarin hij wijst op de gaten in de taal C. Het is ook een handleiding om betrouwbaarder software te schrijven in deze taal. Tot zijn klanten rekent Hatton ondermeer Philips, Asml, Ericcson, Shell en Interpay.
Onrustbarend
Les Hatton ventileert graag een aantal tegendraadse opvattingen. De belangrijkste is wel dat het aantal fouten per duizend regels code in de loop der jaren nauwelijks is afgenomen, ondanks alle nieuwe programmeermethoden en talen. Dat blijkt ondermeer overduidelijk uit onderzoek van het softwarelab van de universiteit van Maryland. Onderzoek dat is gebaseerd op data van de Nasa. In de afgelopen jaren is het aantal fouten marginaal gedaald van zes naar vijf per duizend regels code. Dat is een onrustbarende constatering. Het aantal regels code waaruit een programma bestaat, groeit elk jaar immers fors. Men zou het een bijwerking van de ‘wet van Moore’ kunnen noemen. Die wet, vernoemd naar zijn bedenker, één van de topmensen van Intel, zegt dat de capaciteit van een chip elke achttien maanden verdubbelt tegen gelijkblijvende prijs. Goedkopere en snellere chips zorgen ervoor dat we minder krampachtig met software hoeven om te gaan, en dat we grotere programma’s kunnen schrijven. Die zijn bijvoorbeeld nodig om de functionaliteit en het bedieningsgemak te vergroten. De schaduwzijde lijkt dat de betrouwbaarheid en de stabiliteit er onder te lijden hebben.
Problemen met Mir
Fouten in software beginnen zo langzamerhand bedreigend en duur te worden. Nog niet zo lang geleden mislukte de lancering van een Europese Ariane 5 raket in Frans Guyana als gevolg van een softwarefout. Deze blunder heeft elke Europese burger tien gulden gekost.
In januari 1990 zorgde een ‘bug-fix’, ter grootte van drie regels code, ervoor dat een telefooncomputer van AT&T enkele uren het telefoonverkeer lamlegde in het oosten van de Verenigde Staten. De kosten van deze softwarefout worden ruwweg geschat op één miljard dollar.
Onlangs had het installeren van nieuwe software op een router tot gevolg dat de e-mailserver van America Online, de grootste online service, voor vele uren uit de lucht ging. Post raakte zoek en klanten waren boos. Ook andere Internetproviders als Microsoft Netwerk worden door dergelijke problemen geplaagd. En heel recent voorbeeld zijn de huidige problemen bij het Russische ruimtestation Mir. Die worden voor een deel toegeschreven aan fouten in een nieuw besturingssyteem van het bevoorradingsschip Progress.
Om zijn stelling te bewijzen dat software steeds slechter wordt, heeft Les Hatton over een periode van meerdere jaren bijgehouden hoe vaak hij fouten tegenkwam op zijn diverse computersystemen. Telkens als een computer vastliep, legde hij dat vast. De oorzaak werd genoteerd en geanalyseerd. Uit zijn ervaringscijfers blijken zowel Windows 95 als Macintosh OS hoogst onbetrouwbaar. Windows 95 in combinatie met Professional Office vertoonde gemiddeld elke 42 minuten een vastloper. In 28 procent van de gevallen hielp alleen een volledige ‘reset’. Mac OS plus Microsoft Office hield het iets langer uit: 188 minuten, maar in 56 procent van de vastlopers bracht alleen resetten de oplossing. Daarentegen scoorden diverse op Unix-gebaseerde besturingssystemen beter met minder dan één fout per jaar, overigens zonder ‘reboot’. Linux, een ‘freeware’-variant van Unix voor ondermeer het Intelplatform scoort goed. Hatton heeft in drie maanden continu gebruik onder gemiddelde belasting nog nooit een vastloper meegemaakt.
Raakvlakken met mode-industrie
Hatton begint inmiddels te vrezen voor de veiligheid van zijn medemens. Software kun je tegenwoordig immers op de meest onverwachte plaatsen tegenkomen: in scheerapparaten, in TV’s en in auto’s. De hoeveelheid software in consumentenproducten verdubbelt elke achttien maanden. Volgens Hatton hebben de gebruikers van PC’s geleerd te leven met software van slechte kwaliteit. Maar dat zullen we van consumentenproducten niet accepteren. De lage betrouwbaarheid van bijvoorbeeld een Windows 95 of Mac OS zal voor een TV nooit geaccepteerd worden. "Stel je eens voor dat je tijdens de finale van de Europa Cup twee keer je TV moet resetten." In breedbeeld-TV’s worden overigens al meer dan 150.000 regels C gebruikt.
Waarom zitten er zoveel fouten in software? Les Hatton is er van overtuigd dat de oorzaak gevonden moet worden in de lichtzinnigheid van de systeemontwikkelaar. Het vak heeft momenteel meer raakvlakken met de mode-industrie dan met de ingeneurspraktijk. Een ingenieur leert immers van zijn fouten en ontwerpt de volgende keer een betere brug. Software-engineering wordt echter gekenmerkt door de bijna volledige afwezigheid van enige vorm van systematische meetmethoden. Software-ontwikkeling wordt soms meer beschouwd als een kunstvorm. Zonder te leren van het verleden loopt men achter een nieuwe mode aan. Hatton somt het allemaal op. In de jaren zeventig zou gestructureerd programmeren voor de oplossing zorgen. In de jaren tachtig was het de beurt aan case-tools. En nu is het object- oriëntatie (oo) die betere software belooft. "Van enige vooruitgang is echter geen sprake", zegt Hatton. "Claims worden niet onderbouwd. Marketing overheerst. Het is echt ongelooflijk dom om de besturing van een kernreactor te programmeren in een taal als C++, iets wat nu echt gebeurt."
Hatton somt een aantal breed verspreide misvattingen op over software-ontwikkeling:
- De keuze van een programmeertaal maakt veel uit voor de uiteindelijke betrouwbaarheid van een systeem;
- Object-oriëntatie verbetert de betrouwbaarheid van software aanzienlijk;
- Formele methoden zijn een grote stap voorwaarts;
- In elk systeem zijn kleine, goed geconstrueerde componenten het meest betrouwbaar;
- Hergebruik van code zal de kwaliteit verhogen;
- ISO 9001 zal helpen.
Taal irrelevant
Onder programmeurs kan nog wel eens een verhit debat ontstaan over de kwaliteiten van de gebruikte programmeertaal. Meestal verdedigt een programmeur de door hem gebruikte taal met verve, terwijl andere talen met enig dédain worden afgedaan. De werkelijkheid leert echter, zo ontdekte Hatton, dat het niet zoveel uitmaakt welke taal er gebruikt wordt. Er bestaat niet zoiets als een direct verband tussen een computertaal en het aantal gevonden fouten in de code. Ada bijvoorbeeld, een taal die geacht wordt betrouwbare programmatuur op te leveren, levert in de praktijk geen betere resultaten. Aan de andere kant is C, een taal die als onbetrouwbaar wordt gezien, succesvol toegepast in een aantal van de meest foutvrije systemen die ooit werden ontwikkeld. De conclusie mag luiden dat de correlatie tussen een programmeertaal en de betrouwbaarheid op zijn hoogst zwak is.
Momenteel wordt wereldwijd fors geïnvesteerd in objectgeoriënteerde talen als Java. Het geloof in deze aanpak is zo groot dat men het niet nodig acht om met feiten te komen die aantonen dat object-oriëntatie inderdaad betrouwbaarder software oplevert. In een recente studie werden twee systemen vergeleken van elk 50.000 regels code. Het ene programma was geschreven in C, het andere in C++. Uit het onderzoek bleek dat het aantal fouten per 1000 regels bijna gelijk lag, respectievelijk 2,4 en 2,9 fouten per 1000 regels. Uit de studie bleek bovendien dat de kosten voor onderhoud, zoals het verwijderen van fouten, nadat de software is opgeleverd (gewoonlijk goed voor 40 procent van de softwarekosten in de totale levenscyclus) voor het in C++ geschreven systeem bijna 300 procent hoger lagen dan voor het systeem geschreven in C. Andere studies bevestigen dit beeld. Over andere oo-talen als Smalltalk, Eiffel en natuurlijk Java zijn helaas nauwelijks onderzoeksgegevens beschikbaar. Les Hatton beschouwt de huidige populariteit van oo-talen dan ook als weer een gigantische stap zijwaarts in de ontwikkeling van de software-engineering.
Kleine componenten
Onder programmeurs heerst een hardnekkig bijgeloof dat het opdelen van een systeem in een groot aantal uiterst kleine componenten de beste softwaresystemen oplevert. Een reeks studies wijst uit dat dit volstrekt onjuist is. De onderzoeken werden uitgevoerd bij talen als Ada, C, C++, Pascal, Fortran 77 en zelfs diverse assemblers. Ook werden verschillende systemen in ogenschouw genomen, van communicatiesoftware, besturingssystemen tot databases. Uit de onderzoeken kwam naar voren dat de ideale grootte van een component zo tussen de 150 en 250 regels ligt. Maakt men de componenten kleiner dan neemt het aantal fouten sterk toe. Evenzo zullen grotere componenten meer bugs opleveren.
Bij het opdelen van een systeem in een groot aantal kleine componenten zal het hergebruik van code binnen een applicatie toenemen. Men gaat dan uit van de veronderstelling dat bij meer hergebruik het aantal fouten afneemt. Mis. Het tegenovergestelde effect kan worden bereikt, omdat in de kleine componenten juist meer fouten voorkomen. De totale betrouwbaarheid van een systeem zal dalen.
Wie bestaande componenten wil gebruiken in een nieuw te ontwikkelen systeem loopt grote risico’s. Uit ervaring blijkt dat licht aangepaste, oude softwarecomponenten meer problemen opleveren dan volledig nieuw ontwikkelde componenten. Het hergebruik van bestaande, goedwerkende componenten, is bijvoorbeeld verantwoordelijk voor de desastreuze softwarefout die de lancering van de Ariane 5 liet mislukken. Het probleem was verrassend simpel. De programmeurs namen een getal, beschreven in het 64-bits drijvende-kommaformaat, en lasten dat getal in op een plek waar alleen 16 bits integer-getallen (integer is een geheel getal) ingevuld mochten worden. Dit kon gebeuren omdat in de betreffende softwarecomponent alles goed werkte voor de voorloper van de Ariane 5: de Ariane 4. De software was overigens geschreven in Ada, de lieveling van ‘missioncritical’-programmeurs. In 1992 probeerden programmeurs van de Shuttle, de ruimtependel van de Nasa, een getal (64-bits drijvende komma) op een plek te proppen waar alleen 32-bits drijvende-kommagetallen waren toegestaan. De programmeertaal hield de programmeurs niet tegen. Het resultaat van deze actie was uiteraard dat de nauwkeurigheid van de positiebepaling met de helft afnam. Daardoor had de Shuttle Endeavour de grootste moeite om in de buurt van de beschadigde Hughes F/6 Intelsat-satelliet te komen. Dat was immers het doel van de missie.
Oplossing
Volgens Les Hatton kan maar liefst 40 procent van alle fouten tijdig ontdekt worden, zelfs nog voordat de software gecompileerd is. Daarvoor zal de ontwikkelaar gebruik moeten maken van bestaande analyse-hulpmiddelen die de regels software doorvlooien op zoek naar afwijkingen. Ongeveer zoals een spellingscontroleur een tekst op fouten bekijkt. Les Hatton heeft overigens een commercieel belang bij een dergelijke tool, te weten QA C dat hij mede hielp ontwikkelen.
Naast het gebruik van analysesoftware zou er meer ontwikkeld moeten worden op de wijze waarop een ingenieur een brug ontwerpt. Er moet vooral onderzoek worden gedaan naar mogelijke risico’s. Verder is het van het grootste belang te leren van je fouten. Vliegtuigbouwers proberen na een fataal ongeluk het gecrashte vliegtuig compleet te herbouwen uit de brokstukken. Daaruit kan men vaak afleiden wat de oorzaak is geweest van het ongeluk. Foutvrij zal software nooit worden, denkt Les Hatton. Zo zullen in de 137.000 regels software die nodig zijn om de ‘flaps’ van een Boeing 777 te besturen statistisch gezien vijftig fouten voorkomen. Een weinig opbeurende gedachte als je in het betreffende vliegtuig stapt. In totaal maakt de Boeing 777 overigens gebruik van vier miljoen regels software. Niet alleen in de vliegtuigindustrie zijn er problemen te verwachten. "De meeste banken hebben slechte software", aldus Les Hatton. "Vooral de snel gebouwde handelssystemen zijn werkelijk rotzooi. Dit soort applicaties wordt gebouwd om op de beurs een nieuwe systeem uit te proberen. Dergelijke software gaat vaak maar een maand of twee mee en wordt veelal gebouwd in Visual Basic." Les Hatton huivert alleen al bij de gedachte.
Ook het gebruik van C++ bij banken stuit op onbegrip van Hatton. "Ik heb twintig Britse banken ondervraagd over hun software-ontwikkeling. Het bleek dat ze stuk voor stuk in C++ gaan ontwikkelen. Gevraagd naar de reden voor de overstap gaf men als belangrijkste motivatie dat het de wens was van de ontwikkelaars. Ervaring in C++ stond goed op hun c.v.." Volgens Hatton is C++ een taal die niemand meer doorgrondt. "De commissie die zich bezighoudt met de standaard kwam enkele weken geleden bijeen in Londen en ik verzeker u, niemand van die mensen weet meer hoe de taal exact werk. De specificaties zijn inmiddels aangegroeid tot een stapel papier van tien centimeter hoog. Het is volgens mij veel belangrijker om vloeiend een bepaalde taal te beheersen, dan steeds weer nieuwe talen aan te leren. Vergeet niet: goede ingenieurs zijn conservatief."
Dat een besturingssysteem als Windows 95 zoveel fouten bevat, terwijl het toch het meest uitvoerig geteste stuk software is uit de historie (er zijn dertigduizend fouten uitgehaald voordat het op de markt verscheen), verbaast Hatton niet. "Er moet door de leverancier een afweging gemaakt worden tussen kwaliteit en ’time to market’. Als je te lang wacht met het uitbrengen van software verlies je marktaandeel. Het is soms beter om slechte software op de markt te brengen dan helemaal niets."
Hoe komt het dan dat een besturingssysteem als Linux van een zo uitzonderlijke kwaliteit is? Hatton: "Als je voor Linux schrijft ben je verplicht je broncode openbaar te maken. Iedereen kan dus inspecteren wat je doet. Daarom is het voor een Linux-ontwikkelaar (die daar overigens niets voor ontvangt, Linux is freeware, AM) zijn eer te na om fouten af te leveren. De broncode wordt vooraf nauwlettend geïnspecteerd door anderen.
Ad Mulder, freelance medewerker Computable
Programmatuur op tilt: de oogst van een jaar
Betaalautomaten waar niet meer gepind kan worden, Airbus-vliegtuigen die onverklaarbare bochten inzetten, commerciële raketten die zichzelf moeten vernietigen na een stuurfout. De lijst van hele en halve ongelukken ten gevolge van fouten in programmatuur is schier eindeloos. Ter illustratie een paar voorbeelden om de uitspraken van softwareconsultant Les Hatton nog eens te onderstrepen.
De lijst pretendeert niet volledig te zijn, maar lijkt toch lang genoeg om met vlinders in de buik uit te kijken naar 1 januari 2000.
23 augustus 1997
Door een fout in een schoonmaakprogramma van Internic is een aantal bedrijven in de Verenigde Staten een weekend lang onbereikbaar geweest. Het Internetwork Information Center Internic is verantwoordelijk voor de domeinnamen op het ‘world wide web’. De fout komt bij de getroffen bedrijven aan het licht als grote hoeveelheden e-mail onbestelbaar teruggestuurd worden.
22 augustus 1997
Door een ‘hapering’ in het computersysteem zijn in Nederland alle geld- en betaalautomaten van de Postbank gestoord. Geld opnemen of pinnen in de winkels is de hele ochtend niet mogelijk. De problemen komen rond negen uur aan het licht; tegen de middag is de zaak verholpen. De oorzaak van de moeilijkheden moet gezocht worden in het vernieuwen van een deel van de software in de centrale computer ’s morgens vroeg.
Half juli 1997
Internic, de beheerder van domeinnamen voor het ‘world wide web’ zorgt wederom voor voorpaginanieuws. Een systeembeheerder wist (ondanks waarschuwingen van de programmatuur) een bestand met tientallen domeinnamen, waardoor het Internet voor lange tijd ontregeld is.
16 april 1997
Vermoedelijk door een fout in de software kunnen gebruikers van het GSM-net van PTT Telecom het landelijk alarmnummer 112 niet draaien. De softwarefout veroorzaakte een storing in de betreffende PTT-centrale. Ook gebruikers van het Libertel-netwerk zijn door de storing getroffen, maar dat verkeer werd snel ‘omgeleid’.
1 januari 1997
Zeker elf miljoen Duitsers hebben voor hun nieuwjaarstelefoontjes twee tot drie keer te veel betaald. Oorzaak is een programmeerfout in de software. De gedupeerden mogen op 25 februari ter compensatie een dagje goedkoop telefoneren. De kosten van die actie, ruim honderd miljoen mark, verhaalt Deutsche Telekom op de softwareleverancier SEL Alcatel. Het Franse bedrijf wijst de beschuldigingen van de hand.
18 november 1996
De politie in Rotterdam moet de veelgeplaagde Erasmusbrug een tijdlang afsluiten voor het verkeer. Het bewegende deel van de brug wilde niet meer dicht na het doorlaten van een schip. Volgens Gemeentewerken was het defect een gevolg van een computerstoring. ‘Een van de computers stond te scherp afgesteld’.
22 oktober 1996
Een computerstoring bij Van Dijk Studieboeken in Kampen dupeert vele honderden leerlingen van het middelbaar onderwijs. Bestelde studieboeken arriveren te laat of in het geheel niet en ook de meegestuurde rekeningen kloppen niet.
Begin juni 1996
Door een fout in de besturingssoftware eindigt de Europese draagraket Ariane 5 haar eerste proefvlucht in een explosie. Door een onachtzaamheid werd een deel van het controlemechanisme van haar voorganger Ariane 4, dat in de nieuwe draagraket overbodig is, niet uitgeschakeld. De fout zit in het traagheidsnavigatiesysteem, dat stand, positie en snelheid van de Ariane regelt. Toen de softwarefout een breuk in de elektrische bedrading veroorzaakte, gaf de besturingscomputer opdracht tot zelfvernietiging van de veertig seconden eerder gelanceerde raket.
Bron: Computable en De Volkskrant
