Software

Fejlfri software

Pålidelighed er på dagsordenen - også i it-industrien. Men der er stadig lang vej, til det bliver udbredt til almindelige forbrugere. Det er simpelthen for dyrt, mener professor Lars Birkedal.

Alle, som har været til tasterne for at skrive mere end et par linjers kode, ved, at det er svært at programmere fejlfrit. Professor i Trustworthing Computing ved It-Universitetet Lars Birkedal forsker i, hvordan fejl i kodning kan mindskes.
- Vi forsker i den store it-udfordring: pålidelige systemer. Det vil sige, at man på forhånd kan stole på, at systemerne er pålidelige. At softwaren er tilgængelig, pålidelig og virker efter hensigten, siger Lars Birkedal. Som forbruger vil du gerne have visse garantier. Når du downloader software fra Realkredit Danmark, så vil du være sikker på, at når du regner på din låneomlægning, så cracher systemet ikke.
- Vi forsker i, hvordan man kan lave sådanne garantier. Lige nu kan man godt lave simple garantier.
Men det er dyrt og tager lang tid, hvis man skal lave udvidede garantier. Typisk skal man så bevise, at programmet er korrekt, og det vil involvere en masse manuelt arbejde, siger Lars Birkedal.

Massive investeringer
Store virksomheder som Microsoft, Oracle og Google er interesseret i pålidelig software og poster en masse penge i forskerne og deres egne forskningsafdelinger. Det er dårlig forretning at lade være. Hvis du kan give garantier på forhånd, kan du også øge prisen. Den ekstraværdi, man putter i softwaren, vil man også gerne have hjem igen, mener professoren.
Den største udfordring for virksomheder, som lever af at sælge værktøjer, der kan analysere Java og C#, er at få det til at skalere, så man kan bruge det til store programmer. I dag mangler virksomhederne modulære teknikker til at gøre det. Og det er det, som professor Lars Birkedal og hans forskningsteam arbejder på at udvikle.

Hvorfor er det så svært at lave fejlfri software i dag?
I mange år har man drømt om fejlfri software. Men det har ikke kunnet lade sig gøre, fordi man har manglet værktøjer, som kunne lave verifikationen. Samtidig er der sket en udvikling i teorien, så man arbejder mere modulært. Det vil sige, man analyserer de enkelte dele, og så sætter man delanalyserne sammen på et stort program. Det arbejder vi blandt andet med. Vi har primært fokuseret på at lave det matematiske fundament, så det kan lade så gøre. Men nu er vi også begyndt at lave prototype-værktøjer, så vi kan få testet teknikker.

Nu har vi haft systemudvikling i 50 år eller mere. Hvor lang tid skal der gå, før vi får fejlfri software?
Vi har pålidelig software i dag. Rumraketter, militærsoftware, hospitaludstyr, atomkraftværker har pålidelig software. Her er det kritisk, at tingene de virker. Altså mere kritisk, end at dit Wordprogram går ned. Men efterhånden er det også sådan, at der er så store penge investeret i de programmer, som almindelige mennesker bruger, at det bliver vigtigt, at de virker. Et af de værktøjer, som Microsoft Reacarch har udviklet, handler om at sikre device-drivers, bliver mere pålidelige. Typisk er det hardware-producenterne, som står for det, og det er uden for Microsofts kontrol. Men hvis det ikke virker, så vil en almindelig forbruger sige: Arrg, det er også Microsofts skyld! Derfor har Microsoft en interesse i at sikre sig, at softwaren er pålidelig. Man brugte teknikker, som er baseret på forskning lig det, vi laver, til at sikre sig, at der er en hel klasse af fejl, man kan udrydde. Pålidelighed er på dagsordenen, også i industrien lige nu. Men det er et spørgsmål om at få det til at blive mere udbredt. Og få pålidelighed til at omfatte flere egenskaber end de simple. Når man programmerer i Java, så har man en garbage-collector, som sikrer, at simple klasser af fejl relateret til hukommelsen ikke opstår. Vi vil gerne udvide det til at omfatte flere egenskaber. Vores forskning vil ikke løse alle problemer, men det kan være et skridt i den rigtige retning.

Hvad er resultaterne af forskningen?
Vi har publiceret forskningsresultater, men det er stadig mest i forskningsverdenen. Men vi vil gerne have det ud i virkeligheden. Vi er ved at starte et projekt, hvor vi vil verificere et bibliotek, som min kollega Peter Sestoft har lavet. Biblioteket hedder C5 og er lavet til C#, som rigtigt mange mennesker bruger. Så vi vil tage udfordringen op at prøve at verificere det, fordi det vil være direkte nyttigt, fordi det vil teste vor teori.

Hvorfor går det galt med softwaren?
I første omgang er det en udfordring at lave præcise specifikationer. Det er svært i sig selv. Når man kommer ned i de mange detaljer, som skal beskrive softwaren, så skal der laves specifikationer for hvert enkelt modul. Det er også ret vanskeligt. Selv når man har gjort det, er det svært at sikre sig, at man får det programmeret korrekt. Nogle af de teknikker, vi har udviklet, kan man bruge til at bevise med hånden, at det fungerer. Værktøjer, vi laver, kan også få computeren til at tjekke, at de er bevist korrekt. Men det tager lang tid, så det er kun noget, man er klar til at investere i, hvis det er software, hvor det er meget vigtigt, at det virker. Ellers er det simpelthen for dyrt.

Som forbruger kan man jo ikke købe et nyt produkt fra et af verdens største it-virksomheder, Microsoft, uden straks at få 148 fejlmeldinger, som man kan downloade, når man er kommet på nettet. Hvordan kan det være?
Nogle gange har virksomheden ikke været forudseende nok. Andre gange har der været fejl i softwaren. Microsoft opdager en fejl, retter den og stiller viden til rådighed til forbrugerne, som selv skal opdatere deres software til en ny version. Vi håber på, at man på forhånd kan sikre sig, at det ikke sker.

Er det et problem, at software er så kompleks?
Det er udfordringen. Man skal huske på, vores forskning er én af ingredienserne i, at få pålidelig software. Men der mange aspekter involveret. Man kan sammenligne det med en bilmotor. Tænk på, hvor mange timer der er gået med at udvikle, hvordan en bilmotor skal fungere basalt. Og så, hvor mange timer der er brugt på at skabe optimeringer. Der jo brugt enorme mængder af timer på det. Det er det samme med et softwareprodukt.

Hvad er det, vi mangler for at få bedre software?
Der skal ske en udvikling på mange områder. Der skal ske en udvikling i, hvordan vi får undersøgt softwaren. Hvilke specifikationer der skal være? Hvordan vi udvikler softwaren over tid? Hvis vi først har et produkt, hvordan bliver det så udviklet til næste skridt. Man skal også sørge for, at programmørernes værktøjer bliver bedre. Der håber vi, at vores arbejde kan bidrage, så de kan blive bedre til at sikre, at deres arbejde fungerer.

Er programmørerne godt nok uddannet?
Mange af dem er udmærket uddannet. Men en del af programmørerne kunne få glæde af nogle af de ting, vi laver.

Er der stor interesse fra programmørernes side?
Det er mest fair at sige, at programmørerne anser det for akademisk. Vi vil gerne udvikle nogle værktøjer, så udviklernes arbejde bliver nemmere. Programmører arbejder ofte ved en kraftig pc, som egentligt ikke laver noget, fordi programmørerne arbejder i en teksteditor. Men pc´en kan jo gøre alle mulige ting samtidig. Hele ideen er, at få lavet værktøjer, som skal analysere de programmer, man allerede har lavet, samtidig med at man udvikler nye, så man kan gøre det hurtigere. Ideen er, at sætte computeren til at lave noget fornuftigt, mens programmøren arbejder, slutter professor Lars Birkedal.
Når han bliver pensioneret, vil han gerne kunne konstatere, at hans arbejde har betydet, at der er færre softwarefejl. Og at han har været med til at udvikle teorier og værktøjer, som stadig bliver brugt.