Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 19. november 2004.
Den danske softwareleverandør Terma udvikler software til blandt andet militær og rumfartsindustrien. Enorme summer og menneskeliv kan gå tabt, hvis softwaren ikke er fejlfri.
Den 4. juni 1996 eksploderede den europæiske rumraket Ariane 5 kort efter opsendelsen. Årsagen var en simpel softwarefejl.
Da systemet, der holdt øje med kursen, forsøgte at konvertere et 64-bitformat til 16-bit, resulterede det i et overflow. Rakettens computer modtog derfor en fejlkode, men computeren opfattede fejlkoden som oplysninger om rakettens kurs og besluttede derfor at ændre kurs - blot 37 sekunder efter start.
Kursændringen medførte at rakettens selvdestruktionsmekanisme blev aktiveret. Syv milliarder dollars var tabt på grund af et overflow.
- Jeg vil lige understrege, at Terma ikke stod for den software, siger Carsten Jørgensen, direktør for Termas rumfartsdivision. Carsten Jørgensen bruger Ariane 5-ulykken til at illustrere vigtigheden af fejlfri software. Fejlfri software er, hvad en af Termas kunder, den europæiske rumfartsorganisation ESA, forventer, at Terma leverer.
For at sikre at softwaren udvikles på forsvarlig vis, kræver ESA, at leverandørerne følger en veldefineret udviklingsmodel ECSS (European Cooperation of Space Standard), der er baseret på ISO 12207.
- Der er tale om veldefinerede faser, der meget koncist beskriver hvad vi skal gøre i hver enkelt fase, siger Carsten Jørgensen.
Selv om man følger en proces slavisk, er det dog ingen garanti for fejlfri software.
- Faserne beskriver hvad vi skal gøre, ikke hvordan. Der er dog nogle de-facto teknikker som det forventes, at man bruger. Men procesbeskrivelserne sikrer ikke fejlfri software, siger Carsten Jørgensen.
ESA forsøger at opnå den fejlfri software ved at involvere sig i udviklingsprocessen i en grad som ikke kendes fra it-udviklingsprojekter af administrativ software.
ESA foretager løbende audits, hvor de gennemgår, hvordan Terma håndterer processen og faserne.
- Udviklingsprocessen hos Terma er fuldstændig synlig for ESA. De foretager løbende evalueringer af vores udviklingsarbejde, siger Carsten Jørgensen.
Men det er ikke kun udviklingsprocessen, som ESA følger på tæt hold. ESA gennemgår tekniske kravspecifikationer, designdokumenter og foretager kode-review.
- Hver gang vi skal gå fra en fase til en anden, foretager ESA review af vores arbejde. Eksempelvis gennemgår ingeniørerne hos ESA vores designdokumenter, inden vi får lov til at starte kodningen. Først når ESA har vurderet, at designet er sundt, kan kodningen starte, siger Carsten Jørgensen.
Det tætte samarbejde indebærer sevfølgelig, at ESA har folk med de rette kvalifikationer:
- ESA har en række ingeniører og kvalitetsfolk, der har samme kompetenceniveau som Terma. Det er med til at sikre en god teknisk dialog - og besværliggøre samarbejdet, siger Carsten Jørgensen med et smil.
- Men det tætte samarbejde med kunden skal sikre, at vi undgår situationer hvor menneskeliv eller enorme summer går tabt.
Selv om der er anvendt detaljerede proces-beskrivelser, grundige reviews og tæt samarbejde, kan der stadig være fejl i den færdige software. Derfor skal der udføres en omfattende test af softwaren.
- Jeg vil tro, at vi anvender 60-70 procent af tiden på et udviklingsprojekt til test, fortæller Carsten Jørgensen.
Den første test, der skal udføres ifølge ECSS, er en Unit-test.
- Hver eneste instruktion skal testes i en 100 procents coverage-test, forklarer Carsten Jørgensen.
- Vi skal kunne vise, at alle dele af et program har været testet. Det betyder eksempelvis, at alle en "if-sætnings" forgreninger skal testes. Det kan blive til en del test, hvis man har 100.000 liniers kode, siger Carsten Jørgensen.
Udover de egentlige test anvender Terma også "Software Fault Tree Analysis" og "Software Failure Mode and Criticality Analysis".
Ved en Software Fault Tree Analysis starter man med en tænkt uønsket tilstand for et system, eksempelvis en satellit, der har sine solpaneler vendt væk fra solen. Herfra analyserer man sig frem til, hvad der kan have forårsaget den tilstand
- Ved en "Software Failtrace" analyse siger man: Hvis vi har den her konsekvens, hvad kan årsagen være? Der kan være en lang årsagsrække, som man må analysere sig igennem, før man kan oprette en "Safety Barrier", en mekanisme der sikrer at den egentlige årsag til den uønskede tilstand ikke opstår, oplyser Carsten Jørgensen og fortsætter:
- Ved en Software Failure Mode and Criticality Analysis analyserer man den anden vej: Hvis den her komponent fejler, hvad sker der så? Igen kan man blive nødt til at gennemgå en lang årsagsrække for at finde frem til den endegyldige konsekvens.
Teknikkerne anvendes både til at gennemgå design og kodning.
Administrative it-projekter er ofte ofre for ændrede krav som følge af forretningsmæssige, politiske og organisatoriske ændringer. Det er rumfarts-software heller ikke forskånet for.
- Nye krav til systemerne dukker jævnligt op. Eksempelvis var kun 20 procent af kravene på plads til kontrolprogrammet til en robotarm, da Terma startede på programudviklingen. Den 11 meter lange robotarm skal anvendes på den internationale rumstation ISS i 2007. På grund af ændrede projektplaner, blev udviklingen igangsat, inden alle krav var kendt. Kravene kom i fire bundter, fortæller Carsten Jørgensen.
Den store forskel på administrative it-projekter og Termas rumfartsprojekter er, at håndteringen af krav måske er mere formaliseret i de "tunge" rumfartsprojekter.
- Vi måtte lave antagelser om, at de første 20 procent af kravene ikke blev påvirket af efterfølgende krav. Hvis de gør det, træder en meget formaliseret proces om kravændringer i kraft. Her analyseres konsekvenserne af kravændringerne. Hvilken indflydelse har det på projektplanen og på budgettet? Processsen i forbindelse med ændrede krav, konsekvensanalyse, og hvordan man håndterer kravændringer er mere formel end ved administrativ it, mener Carsten Jørgensen.
På trods af grundigt design, kodning ifølge kodestandarder og grundige test, kan der stadig opstå uforudsete problemer.
Hvis systemet kan komme i en tilstand som man ikke har tænkt på, vil der ikke være defineret nogen software-krav til at håndtere dem. Det var, hvad der skete ved Ariane 5's eksplosion.
Man havde valgt at genbruge software fra en tidligere raket, der var langsommere og mindre end Ariane 5. Da softwaren allerede havde været igennem hele ESA's software-proces, mente man ikke, det var nødvendigt at teste den så grundigt igen. Ariane 5's størrelse og hastighed betød imidlertid, at systemet kom ud i nogle tilstande, som den genbrugte software ikke tog højde for. Med enorme omkostninger til følge.
Boks:
udviklingsværktøjer og metoder Cobol blev ved introduktionen i 1959 hilst velkommen som en mulighed for, at slutbrugere selv kunne skrive applikationer i den engelsklignende syntaks. Det skete ikke. Siden dengang har nye tendenser inden for udviklingsværktøjer og metoder lovet, at systemudviklingen vil blive nemmere og hurtigere.
Boks:
termas programmeringssprog
Terma anvender Assembler, C og Ada til udvikling af rumfarts-software.
Ada anses som et af de mest sikre programmeringssprog og er udbredt i militær software.
Ved programmering anvendes udelukkende statisk memory-allokering, da dynamisk memory-allokering anses for risikabel.
Boks:
Vi har talt med:
• Poul Staal Vinje, VR Partners
• Kasper Rasmussen, Corporate Communication, Terma
• Carsten Jørgensen, Direktør for rumfartsaktiviteter, Terma
• Jens Østergaard, systemarkitekt, PFA
• Lars Lennart Jensen, systemchef, CSC
• Thomas Kurian, Vice President Development & Application servers, Oracle
• Laurent Seraphin, Director Software Product EMEA, Borland
• John Norman Hansen, uddannelsesleder, Niels Brock
Boks:
En dag vågner vi op, og så er softwarefabrikken der. Vi er på vej.
Poul Staal Vinje VR Partners
Billedtekst:
Bom. I 1996 eksploderede rumraketten Ariane 5 kort efter opsendelsen på grund af en simpel softwarefejl. Det kostede syv milliarder dollars.
Foto: Arianespace
Billedtekst:
- Vi skal kunne vise, at alle dele af et program har været testet. Det betyder eksempelvis, at alle en "if-sætnings" forgreninger skal testes. Det kan blive til en del test, hvis man har 100.000 liniers kode, siger Carsten Jørgensen, direktør for Termas rumfartsdivision.
