Därför kraschar datorn

Traditionella ingenjörsmetoder gör inte programmen tillräckligt bra.

Alla som använder persondatorer har någon gång varit med om program som kraschar eller gör något helt annat än man tänkt sig. I bästa fall leder det till att man måste starta om programmet eller datorn, och ibland får man lära sig att vissa kommandon helt enkelt inte fungerar. I värre fall förstörs värdefull information och veckors arbete går förlorat.

Hur kommer det sig att datorprogram har så många brister? Varför verkar det omöjligt att konstruera felfria program, när exempelvis en rulltrappa eller en tv kan fungera felfritt i många år?

Vid Lunds tekniska högskola bedrivs forskning om just programutveckling. En av författarna till denna artikel, Per Runeson, har utvärderat en ny metod för att utveckla program. Även om metoden inte lovar perfekta datorprogram, visar studien att det finns mycket att vinna på att ersätta de traditionella metoderna för att utveckla program.

Dyr programutveckling

Programutveckling är en allt viktigare del av vårt samhälle. Datorprogram styr fler och fler produkter och tjänster som vi är beroende av i vårt dagliga liv. Det gäller inte bara våra persondatorer; datorprogrammen styr också hur bilen ska bromsa, vilka pengatransaktioner som ska göras på banken och hur telefonsamtal ska kopplas.

Pålitliga och effektiva program har därför blivit en viktig – och dyr – del av nya produkter. Utvecklingskostnaderna för en ny mobiltelefon består till 80-90 procent av programutveckling. För industrirobotar ligger nivån på omkring 75 procent. Även för bilar, som ju uppfattas som huvudsakligen mekaniska, har programutvecklingen på tio år gått från en obetydlig del till en tredjedel av produktionskostnaden.

Anledningen till de höga kostnaderna är att dagens program är oerhört komplexa. Programutveckling är inte längre något som enskilda personer klarar av på en vecka eller två. Det är enorma projekt som kan engagera hundra programmerare i ett år eller mer.

Ett exempel är telefonsystemen. För femton år sedan hade programmen som styr en telefonväxel ungefär en miljon rader med kod, alltså kommandon som säger åt en dator vad den ska göra. Det motsvarar femtio böcker med programkod sida upp och sida ner. I dag finns lika mycket kod i en enkel mobiltelefon! Och en modern telefonväxel kräver 10-100 miljoner rader kod.

När en ny telefonmodell ska utvecklas kräver det alltså inte bara att 50 böcker med text skrivs samman. Olika delar av koden måste också fungera ihop, och slutprodukten ska förstås möta de krav som finns på funktioner och kvalitet. Dessutom ska allt göras inom loppet av vanligtvis 8-15 månader. Ett programpaket med ordbehandlare och presentationsprogram kan innehålla fem gånger så mycket kod – tillräckligt för att fylla en hel bokhylla.

Till detta kan vi lägga att förutsättningarna för datorprogram förändras snabbt. Datorerna i dag är dubbelt så snabba som för ett och ett halvt år sedan. Om man jämför med järnvägens utveckling motsvarar det att ta steget från smalspårig järnväg till magneträls på några få år. Men medan de som bygger tåg har haft 150 år på sig att utveckla ny teknik, måste programmerare anpassa sig snabbt för att deras kunskap inte ska bli föråldrad. Den förbättrade kapaciteten i datorerna används dessutom sällan för att få bättre prestanda eller kvalitet, utan till att stoppa in nya funktioner eller ge programmen häftigare utseende på bildskärmen – vilket förstås gör dem mer komplexa. Så våra datorer kör fortfarande i ångloksfart på höghastighetsräls, tåget får med jämna mellanrum motorstopp mitt på linjen, men vi reser bekvämt och har trevliga kupéer att sitta i.

Ett program blir till

Det är alltså inte konstigt att datorprogram innehåller brister, och deras komplexitet ställer därför stora krav på att utvecklingen av nya program leds och samordnas på ett effektivt sätt.

Vanligtvis utgår programutveckling från ett antal krav från en kund eller en marknad, som beskriver vad programmet ska göra och vilka funktioner det ska ha. Utifrån kraven designar utvecklare programmets övergripande struktur – vad olika programkomponenter ska uträtta och hur de ska fungera tillsammans. Därefter sker den egentliga programmeringen, där programkoden skrivs. När programmeringen är klar testas produkten, vilket kan leda till nya krav från kunden, och så kan utvecklingen fortsätta i flera varv.

I vissa fall, när kraven på säkerhet är extremt höga, kan utvecklingen gå via en matematisk-logisk beskrivning av kundens krav, som sedan omvandlas till programkod. På så vis går det att bevisa att den färdiga produkten uppfyller kraven, vilket kan vara avgörande för exempelvis styrsystem för kärnkraftverk eller medicinsk teknik. Men en sådan modell för programutveckling är mycket tidskrävande och förutsätter dessutom att kunden är van att uttrycka sig matematiskt-logiskt.

I stället använder programutvecklare sig oftast av en arbetscykel som omfattar krav, design, programmering och test. Ett huvudproblem för traditionell programmering är att det tar för lång tid mellan den faktiska utvecklingen och utvärderingen. Det kan leda till att kunden har hunnit ändra sig eller att marknaden förändrats av att konkurrenter har lanserat nya produkter.

Ett annat problem med traditionell utveckling är att den bygger på att man bryter ner problemet i komponenter och att dessa delar utvecklas separat. När delarna väl sätts samman kan det visa sig att de inte passar ihop.

Nya metoder för utveckling

I Per Runesons studie utvärderades en annan modell för programutveckling, kallad extremprogrammering. Det är en modell som betonar flexibilitet och där tiden för återkoppling kortas drastiskt.

Ett exempel på flexibilitet är att kunden deltar under stora delar av utvecklingen, för att löpande utvärdera och ge förslag på förändringar. Andra former av återkoppling är parprogrammering, där programmerare kommenterar varandras arbete, och kontinuerliga tester.

Per Runeson granskade två stora utvecklingsprojekt på Ericsson och ABB. Det visade sig att programmerarna genomgående ansåg att de med hjälp av extremprogrammering fick avsevärt bättre kontroll över sin arbetssituation och planering än vad traditionell programutveckling ger. Programmerarna kände större trygghet och tillfredsställelse i arbetet, vilket ledde till mer kod per tidsenhet och färre fel. Det nya arbetssättet med en kundrepresentant närvarande medförde också att man genomgående valde att programmera de funktioner som ansågs vara viktigast, och därmed fick bättre produkter.

Datorprogram som gått snett

1978 Upptäckt av ozonhål

Trots att satelliter mätte ett hål i ozonskiktet ovanför sydpolen redan 1978 dröjde det till 1985 innan resultaten nådde fram till forskare.

Orsak: Satelliterna var programmerade att ignorera värden som avvek för mycket från det förväntade och sorterade bort dessa som mätfel.

1983 Börsen i Vancouver

Några månader efter det att Vancouvers nya börssystem hade installerats visade det en nedgång på 50 procent trots att börsen egentligen gått upp 10 procent. Orsak: Programmet avrundade systematiskt nedåt, i stället för till närmsta värde. När de små felen lades ihop blev avvikelsen till slut mycket påtaglig.

1985 Cancerbehandling med Therac-25

Therac-25, en maskin för strålningsbehandling av cancer, utdelade kraftiga överdoser till minst sex patienter. Tre av dem dog till följd av detta.

Orsak: Inga planerade tester av programvaran genomfördes. Läkarna visste inte hur de skulle tolka felmeddelanden från maskinen.

1990 Telefonnätet i USA

I januari 1990 kraschade systemet för långdistanssamtal i USA och låg nere i nio timmar.

Orsak: Instruktionerna för omstart av telefonväxlarna innehöll felaktig kod, som fick intilliggande växlar att krascha. När även intilliggande växlar startade om, spreds felet vidare som en löpeld.

1991 Patriot Missile Defence System

Missiler tänkta att spränga fientliga raketer missade många mål under Kuwaitkriget. En missil träffade en byggnad där 28 soldater dödades och hundratals skadades.

Orsak: Styrsystemet för missilerna avrundade stora tidsvärden fel och behövde därför startas om var åttonde timme. Detta var inte känt bland alla användare.

1992 Samordning av Londons ambulanser

Ett nytt ledningssystem för Londons ambulanser kraschade redan efter några dagar. Systemet fördröjde nödsamtal och skickade även ibland dubbla, ibland inga, ambulanser till samma olycka. Uppskattningsvis 20 personer omkom på grund av försenade insatser.

Orsak: Tids- och resursplaneringen för utvecklingen var orealistisk. Det överambitiösa programmeringsföretaget använde många nya, oprövade lösningar. Systemet installerades trots många varningar.

1994 Bagagesystemet vid Denvers flygplats

Ett automatiskt system för att sortera och skicka bagage kraschade. I tester skadades väskor, tappades bagage bort och krockade bagagevagnar. Försenad utveckling kostade 20 miljarder kronor, och systemet övergavs till slut år 2005.

Orsak: Tidsplanen för programutvecklingen var orealistisk. Styrprogrammet klarade inte av annorlunda placerat bagage eller småfel vid läsning av streckkoder. Förändrade krav under utvecklingen ledde till ett dåligt sammanhållet program.

1995 Tågstation i Hamburg

Det nya kontrollsystemet i Altonastationen, Hamburg, bröt samman under första dagen. Stationen kunde inte ta emot några tåg under två dagar.

Orsak: Ett oprövat system för felhantering innehöll själv ett fel, och råkade in i en oändlig loop. Det fanns inget reservsystem att sätta in.

1996 Raketen Ariane 5

Rymdraketen Ariane 5 avvek för mycket från sin planerade bana och sprängdes av säkerhetsskäl 40 sekunder efter uppskjutning. Bakom projektet låg tre års utveckling och 4 miljarder kronor.

Orsak: Raketen använde styrprogram från äldre raketer, trots att uppskjutningsbanan var annorlunda. En variabel i styrsystemet gick över tillåtna gränser, och den drabbade processorn slogs av automatiskt. Även reservprocessorn stängdes på grund av samma fel.

2003 Strömavbrott i Nordamerika

Den 14 augusti 2003 blev över 50 miljoner människor i nordvästra USA och Kanada utan ström till följd av att ett varningssystem inte fungerade.

Orsak: Reservsystemet för varningar slogs ut av samma fel som originalsystemet. Operatörernas kontroller visade att allt fungerade, trots att två kraftledningar låg nere. Snedbelastningar slog ut fler och fler kraftledningar.

2004 Flygledningen i Los Angeles

I september 2004 bröts all röstkommunikation mellan Los Angeles flygledning och omkring 800 flygplan i deras luftrum. Problemen varade i två timmar. Kollisionsvarningar på flygplanen förhindrade olyckor.

Orsak: Datorsystemet för flygledningen behövde startas om var 30:e dag för att förhindra att en variabel i programmet gick över tillåtna gränser. Programmet signalerade inte att detta hade glömts bort. Reservsystemet hade inte blivit testat och fungerade inte.

Listan är sammanställd tillsammans med Kim Weyns, doktorand vid Lunds tekniska högskola.

Upptäck F&F:s arkiv!

Se alla utgåvor