Waarom software en software-projecten mislukken

15 februari 2008

Het implementeren van verouderde specificaties, slechte communicatie met de klant, overbodig werk omdat prioriteiten en doelstellingen gedurende het project wijzigen: over de oorzaken van het mislukken van software en software-projecten is veel te zeggen. Een rapport van Alpha Software doet een nieuwe duit in dat zakje. De ontwikkelaar van databasesoftware heeft een prachtig rapport online gezet over de redenen waarom softwareprojecten mislukken. Uiteraard komen Alpha's concurrenten er niet goed af, maar het rapport bevat wel degelijk een aantal interessante analyses. De schrijver van het rapport, David Moskowitz, al dertig jaar een veel gevraagd adviseur, onderscheidt drie voorkomende fouten: fouten in het proces, soft- en hardware die niet voldoet en slechte aansturing vanuit het management. Wat te denken van ontwikkelaars die aan te veel projecten tegelijk werken, onrealistische tijdsschema's, te krappe budgetten en rapportage-eisen die resulteren in veel papier. Of van schaal- en capaciteitsproblemen die pas na verloop van tijd aan het licht komen, bugs in software tools of problemen die onstaan omdat de computer niet meer krachtig genoeg is voor een nieuwe versie van de ontwikkelomgeving. Of management dat onvoldoende steun geeft of op grond van verkeerde motieven kiest voor een tool of leverancier. En ook met de software zelf kan van alles mis zijn….


Vorig jaar moest General Motors een groot administratief softwareproject afblazen, omdat het tweehonderd miljoen méér had gekost dan begroot. Het programma moest de afhandeling van bestellingen vergemakkelijken, maar in de praktijk bleek het het werk moeilijker te maken. Een paar jaar terug viel het luchtverkeersleidingssysteem van Californië en Nevada uit. Dat leidde tot vijf bijna-botsingen in de lucht, terwijl honderden vluchten werden vertraagd of afgelast. De fout: een computerprogramma dat nooit goed gewerkt had. Om het blijvend te laten werken moest het elke dertig dagen opnieuw opgestart worden, en deze keer was dat vergeten. Een oude mislukking: het plan uit de jaren tachtig om de hele VS een nieuw verkeersleidingssysteem te geven. Na jaren programmeren aan de software moest een groot deel van het project opgegeven worden. Verloren investering: een half miljard dollar. Duurder was een mislukt softwareproject van de Amerikaanse belastingdiensten, dat in 1997 gedumpt werd nadat het vier miljard had opgeslokt. Door een vergeten regel code ging de helft van de gegevens verloren die een sonde in januari 2005 verzamelde bij de afdaling naar Titan. Volgens een schatting van The Standish Group zijn twee derde van de softwareprojecten of totale mislukkingen of op zijn minst zwaar vertraagd of over budget. Slechts twee procent van de projecten verloopt probleemloos. Gartner schat dat de gemiddelde werknemer per jaar een week werktijd verliest aan problemen. Het rapport van de Rekenkamer onderstreept dat allemaal. 'Een belangrijke bron van moeilijkheden is de complexiteit en de omvang van moderne computersoftware', vindt Geert Deconinck van de KU Leuven, gespecialiseerd in de betrouwbaarheid van software. Het maken van software is het schrijven van 'code', instructies voor de computer die samen programma's vormen. Mensen hebben moeite om de gevolgen te zien van de instructies die ze schrijven. Een regel in de code kan elders in het programma heel onverwachte gevolgen hebben, en er zijn miljoenen lijnen in grote stukken software. Volgens schatting bevat software ongeveer tien tot honderd fouten per miljoen regels. Dat gaat dan over software van goede kwaliteit. Voor gewone commerciële software ligt het cijfer volgens Deconinck dichter bij een à twee fouten per duizend lijnen. Het opsporen van eerdere fouten slokt gemiddeld 80 procent op van de totale kosten van software-ontwikkeling. Wat niet helpt bij software-ontwikkeling zijn de steeds wijzigende wensen van de klant of de opdrachtgever. Softwaremakers hebben bij elk nieuw idee een reflex van 'dat maken we wel even'. Ze gaan enthousiast aan de gang, terwijl de prioriteiten misschien beter elders zouden liggen. En dan is er nog de tijdsdruk voor de ontwikkeling van commerciële softwarepakketten, de ' rush to market '. En tenslotte: er is geen open cultuur rond fouten in software. De bedrijven zijn geneigd ze voor zich te houden. Dat maakt het moeilijk om te onderzoeken hoe ze ontstaan en hoe ze voorkomen kunnen worden.

Share This:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.