Nieuws
image

Slordig programmeren kost mensenlevens

woensdag 12 april 2006, 12:36 door Redactie, 8 reacties

Het apparaat was ontworpen om mensenlevens te redden, maar door een programmeerfout leverde de Therac 25 een overdosis straling waardoor drie mensen het leven verloren. De code van de verantwoordelijke programmeur was nooit goed gecontroleerd en getest.

Naast het leven van mensen zijn ook miljoenen geinvesteerde euro's afhankelijk van de programmeerkunsten van de ontwikkelaar. Toch mislukken er teveel projecten omdat er niet goed geprogrammeerd wordt. En de problemen worden alleen maar groter, omdat programmeurs ook met extra uitdagingen te maken krijgen, zoals het programmeren voor multicore apparaten.

Uit onderzoek blijkt dat er onder programmeurs grote behoefte is aan software debug tools, en kost het testen en debuggen de meeste tijd tijdens het ontwikkeltraject.

"Dit is de enige industrie waar je producten met bekende fouten kunt aanbieden zonder te worden aangeklaagd" zei consultant Jack Ganssle tijdens de Embedded Systems conferentie.

Uit ander onderzoek blijkt dat 80% van de software projecten faalt omdat ze het budget overschrijden, belangrijke features missen of een combinatie van factoren. Grote software systemen met meer dan een miljoen regels code hebben 20.000 fouten bij de oplevering, waarvan er een jaar later nog 1800 aanwezig zijn.

Reacties (8)
12-04-2006, 12:48 door awesselius
Voor tips over programmeer problemen binnen projecten:

http://www.joelonsoftware.com/

Staan aardig wat valkuilen met naam en toenaam aangegeven en
wat er aan te doen.

Het probleem met programmeren is de X-factor. Het onbekende
wat de computer gaat doen op jou stukje code. Gaat het goed?
Gaat het onder bekende omstandigheden goed? Gaat het onder
onbekende omstandigheden goed (stress-testing)?

De computer behelst zoveel onberekenbare factoren
(architectuur, andere software (dependencies of juist niet))
enz. Daarnaast hebben de gebruikers zelf ook onberekenbare
factoren. Daar valt niet tegen op te debuggen. Dat is de
kracht van open-source. Je stelt je project open voor de
gebruiker, die zelf gaat testen en feedback geeft.

- Unomi -
12-04-2006, 13:32 door gmlk
[url=http://www.artima.com/intv/testdriven.html]Test-Driven Development[/url]?
[url=http://c2.com/cgi/wiki?CodeUnitTestFirst]Code the Unit Test First[/url]?

En als het echt belangrijk is (mensenlevens of miljoenen euros): Een [url=http://
www.cs.rug.nl/~bakker/ProgCor/bundel.pdf]formeel bewijs van de correctheid
van het programma[/url]? ([url=http://www.google.com/search?q=%22program+correctness%22]Program Correctness[/url])
12-04-2006, 13:54 door Anoniem
Is dit nieuws??! De ongelukken met de Therac gebeurden
tussen 1985 and januari 1987. Dat is bijna 20 jaar geleden!
Wat ICT betreft is dit prehistorie.

Verder nieuws: steensplinters bij het maken van vuistbijlen
leiden tot oogletsel...
12-04-2006, 14:25 door gmlk
Door Anoniem
Verder nieuws: steensplinters bij het maken van vuistbijlen leiden tot oogletsel...
Nieuwste technologische ontwikkeling: Die steensplinters zijn veel scherper dan die vuistbijl en kunnen gebruikt worden om vrij nauwkeurig te snijden! Uitvinders van deze technologische vooruitgang zeggen dat dit de vleesindustrie net zo zal revolutioneren als de uitvinding van het beheersbare kampvuur. Vuistbijl leveranciers zijn sceptisch.

Terug in het heden: We hebben weinig geleerd sinds 1987.
12-04-2006, 15:45 door jeed
Ik moet het eerste project nog meemaken waarin Kwaliteit
serieus genomen wordt. Haast is er genoeg, het programmeren
komt achteraan en is dus altijd de bottleneck.
12-04-2006, 15:54 door Anoniem
De code van de verantwoordelijke programmeur was
nooit goed gecontroleerd en getest.
Het is onterecht dat de programmeur verantwoordelijk wordt
gehouden. In elk bedrijf waar ik als programmeur heb
gewerkt, was een enorme tijdsdruk en werden de producten
vaak afgeraffeld. De software bedrijven zijn aansprakelijk,
niet een individuele programmeur.

Gelukkig ben ik uit die business.
12-04-2006, 17:06 door Anoniem
Opvallend dat hier over programmeren wordt gesproken terwijl het fysiek
onmogelijk moet zijn een gevaarlijke dosis straling af te geven met een
apparaat. Dat mag nooit afhankelijk zijn van programmacode.
16-04-2006, 10:49 door Constant
Uit ander onderzoek blijkt dat 80% van de software projecten faalt
omdat ze het budget overschrijden, belangrijke features missen of een
combinatie van factoren.
Dat zijn de gevolgen, ik mis de bron van de oorzaken van project falen
zoals tussentijds veranderen van specificaties terwijl het programmeren
al begonnen is. Dit is doorgaans nr. 1 (al 30-40 jaar lang) in de lijstjes
met root causes mbt mislukte projecten.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.

Zoeken
search