Därför kraschar datorn

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.