Skal vi bare acceptere programfejl?

Det er velkendt, at der er fejl i de programmer, som leverandørerne leverer til os kunder. På det seneste har man bl.a. kunne følge en sag i medierne om KMD's Opera system, der anvendes i kommunernes jobcentre til at administrere ydelser og arbejdsgange omkring ledige og som har givet kommunerne meget ekstraarbejde og mange frustrationer.

For nylig oplevede vi i min egen kommune, at et andet centralt system lavede graverende fejl, hvilket betød, at kommunens personale måtte gribe til en ekstraordinær nødprocedure og udbetale tilskud til mere end 500 borgere på gammeldags, dvs. helt manuel manér.

Jamen, kan man da ikke komme efter leverandørerne i sådanne tilfælde?

Jævnfør K01-kontrakten, som er udbredt som skabelon for anskaffelse af 'standard'-systemer som de nævnte, så kan leverandøren i tilfælde af fejl i hans systemer ikke afkræves erstatning for drifttab, følgeskader eller andre indirekte tab, herunder tab af data. Min kommune kan således ikke sende leverandøren en regning for de arbejdstimer der er medgået til at foretage manuel udbetaling til 500 borgere.

Hvorfor skærper vi som kunder så ikke bare de kontraktlige formuleringer vedr. leverandørernes erstatningsansvar, så det også omfatter indirekte tab og følgeskader?
Mit eget umiddelbare bud er, at samfundet som helhed generelt har accepteret, at IT er forbundet med jævnlige (program-)fejl. For hvorfor ser K01-kontrakten, der som bekendt er blevet til som et kompromis mellem kunde- og leverandørside, ellers ud som den gør' Står leverandørerne af, hvis de skal bære det fulde erstatningsansvar'

Kommentarer (23)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Mads N. Vestergaard

Jeg siger på ingen måde at man skal stille sig tilfreds med programfejl, tværtimod.

Men en paralel er hvis ens vaskemaskine går i stykker, og man skal vaske i hånden. Her har man heller ikke mulighed for at sende producenten en regning for den ekstra manuelle process man har gennemgået for at få vasket sit tøj.

Jeg mener dog stadig at der bør være en SLA for sådanne fejl, med en responstid fra leverandøren, så man er sikret at disse bliver udbedret indenfor en overskuelig tid.

  • 0
  • 0
#2 Torben Frandsen

Står leverandørerne af, hvis de skal bære det fulde erstatningsansvar?

Så længe I har penge at spendere løber de ingen steder. De vil i stedet tage den øgede risiko ad notam, prissætte den og indregne den i kontraktsummen. De vil sikkert også sætte en hob jurister til at styre kontrakterne endnu hårdere, med hvad det så medfører af yderligere administrativt overhead og deraf følgende omkostninger. Skatteyderne gi'r.

Der er altid risici forbundet med software. Spørgsmålet for dig som aftager må være hvordan du bedst holder dem dækket. Vil du bruge leverandøren som forsikringsselskab, vil du være selvforsikrende, eller bruge et rigtigt forsikringsselskab?

Jeg er hverken jurist, økonom eller assaurandør, så jeg skal ikke kloge mig på hvordan skatteydernes penge er bedst brugt. Men du må ikke forvente, at du gratis kan slippe for den risiko, som i sidste ende er din.

  • 0
  • 0
#3 Deleted User

Der er en syg accept i samfundet. Mange går ligefrem så langt som til at postulere at alle programmer indeholder fejl, man kan aldrig blive fri for sikkerhedshuller osv. Det bliver til en selvopfyldende profeti, så længe fejl er så bredt accepteret så bliver der heller ikke gjort det store fra udviklerne for at undgå dem.

Det har tilsyneladende også bredt sig til hardware, når nu hjemmerouteren er blevet svinet til med 3. parts operativsystem og rigelige mængder unødvendig kode, ja, så går den også ned fra tid til anden.

  • 0
  • 0
#4 Michael Deichmann

Ole - hvorfor er den fejl ikke fundet under acceptance testen? Så peger pilen jo ligesom tilbage på jer selv, ikke? Nååh - scenarioet er så komplekst at det ikke er muligt for jer at udtænke alle scenarier og teste dem. Leverandøren har samme problem. K01 er nok det bedste kompromis, og lad os så se at finde nogle ingeniørmæssige discipliner der kan benyttes for IT konstruktion, der sikrer imod disse fejl.

  • 0
  • 0
#5 Deleted User

Man undgår ikke kun fejl ved at teste. Man undgår fejl ved metodisk programmering. Det er ikke simpelt at gøre systemer simple, men det er i høj grad det der skal til, og gode udviklingsmetoder kan gøre en kæmpe forskel. Det er leverandørens ansvar at benytte de rigtige metoder, men det er ikke noget som ordentligt kan sættes på kontraktform.

  • 0
  • 0
#6 Poul-Henning Kamp Blogger

Mit eget umiddelbare bud er, at samfundet som helhed generelt har accepteret, at IT er forbundet med jævnlige (program-)fejl.

Ole,

For nu at sætte sagen på spidsen, så erindrer jeg noget om at 10% af alle sager i de gamle kommuner havde sagsbehandlingsfejl når de blev undersøgt nærmere.

Bevares, der er selektionsbias, sager der så underlige ud havde større chance for at blive undersøgt.

Men alligevel, skal vi gætte på at mindst en ud af hver 1000 sager fejlbehandles på en eller anden vis ?

Programmører er også mennesker og hvis I vil have programmer der har under 1 fejl per 100 linier kode, en typisk rate for almindelig "business code" må I betale for det.

Vil I ned på under 1 fejl per 1000 linier kode, der er typisk for "seasoned system-code" må I betale endnu mere.

Rigtig "Hi-Rel" eller fejlfri kode har I ikke råd til.

Så ja: Programmer har fejl, lev med det.

Jeres opgave er at designe jeres systemer og procedurer så I opdager når programfejl, indtastningsfejl eller folk der bare trykker på noget tilfældigt bliver stoppet og rettet i tide.

Og Folketinget har et ansvar for ikke at lave love og regler så indviklede, at de er umulige at checke med simple midler.

Som det er idag spiller de rent IT-mæssige konsekvenser absolut ingen rolle for lovforslags udformning, jeg kan ikke forestille mig en privat bestyrelse gøre det samme.

Når det er sagt, har jeg svært ved at se hvorfor leverandører i nogen branche, software, hardware eller cykelstyr, skal kan fraskrive sig ethvert ansvar for deres handlinger.

Når en SW-leverandør hugger en hæl, klipper en tå eller efterlader gabende huller af bekvemmeligheds- eller overskuds-hensyn, mener jeg at der burde være et erstatningsansvar på linie med med det alle andre brancher har.

Poul-Henning

  • 0
  • 0
#7 Brian Hvarregaard

Jeg synes begreberne er lidt svævende, jeg har altid lært:

"Tests kan ikke påvise at der ingen fejl er i systemet, tests kan kun påvise at der er fejl"

Du kan teste alt det du vil, også metodisk, men at du ikke finder fejl er ikke ensbetydende med at der ingen fejl er!

  • 0
  • 0
#10 Torben Mogensen Blogger

Hvis en programstump i teorien kan gøre noget forkert, men aldrig gør det i praksis, er det så en fejl ?

Det er naivt at tro, at man man teste eller verificere dele af et program i isolation, uden at have en nøjagtig beskrivelse af den invariant, der gælder, når denne del af koden bliver kaldt.

Så hvis kodestumpen kan gøre noget forkert, når invarianten ikke overholdes, er det ikke nødvendigvis en fejl, men hvis den kan, når invarianten er opfyldt, så er der en fejl i koden -- forudsat, at invarianten er præcis.

Man kan realistisk set ikke beskrive enhver invariant 100% præcist, så man må lade de specificerede invarianter omfatte ikke-realiserbare situationer. Når man så tester eller verficerer kodestumpen overfor invarianten og finder en ulovlig opførsel, må man undersøge, om denne opførsel er realiserbar (og i givet fald rette fejlen i kodestumpen) eller ej (og i givet fald enten ignorere opførslen eller præcisere invarianten, så den ikke-realiserbare opførsel udelukkes).

Verifikationsværktøjer vil normalt sammen med en besked om, at her går noget galt, også angive et [i]trace[/i], der leder til problemet. Det giver mulighed for at se, om dette [i]trace[/i] er realiserbart.

Men selvfølgelig medfører Rices sætning, at ethvert spørgsmål om korrekthed (i forhold til en formel specifikation) er uafgørligt. Test kan bevise, at et program ikke er korrekt, og verifikation kan bevise, at et program er korrekt, men der vil altid være programmer, som hverken kan verificeres korrekte eller påvises ukorrekte gennem test. I disse tilfælde må man enten slække på kravene og lade tvivlen komme programmet til gode eller forkaste et potentielt korrekt program. I praksis er den første udvej den mest brugte, da den er billigst, og derfor må vi leve med fejl i programmer.

  • 0
  • 0
#12 Kim Henriksen

Fordi det er nogle slipse fyre som ikke rigtig læser kontrakterne, og på ingen måde varetager borgernes interesser?

Men derimod bare glæder sig til at sætte tænderne i frokosten som leverandøren har betalt.

Efter de har sat deres autograf?

  • 0
  • 0
#13 Thomas Kjeldsen

Det er forståeligt at i søger en form for kompensation, men hvad er det i søger kompensation for?

Jeg krummer tæer når du nævner manuel udbetaling til 500 borgere.

Det lyder ikke som om i har taget leverandøren med på råd til brandslukningen, og hvis det er tilfældet mener jeg ikke det er rimeligt at afkræve leverandøren kompensation for den tid i nu måtte have brugt på "manuel udbetaling".

Leverandøren kunne fx have hjulpet jer med problemet i denne omgang. Som bonus ville jeres leverandør have fået en forståelse for fejlen og kunn i samme omgang lave en fejlrettelse af jeres system, sådan at i ikke oplever fejlen igen.

Med jeres manuelle stunt har i blot smidt en masse mandetimer ud af vinduet.

  • 0
  • 0
#14 Karsten Nyblad

Situationen er faktisk endnu værre end Torben Mogensen skriver. Ved verifikation forstå man at føre matematisk bevis for et programs korrekthed. Der er bare flere progblemer med metoden. Den første er, at bevisbyrden (alt mængden af beviser) er så stor, at i praksis er der ikke nogen, der vil betale for og vente på at programmer bliver bevist korrekte.

Det næste problem er, at beviserne kun viser en ting, nemlig at programmet er korrekt i forhold til den samling af matematisk logiske formler, der udgør den formelle kravspecifikation. Der er intet, der sikre, at den formelle kravspecifikation er korrekt eller fuldstændig. Efter som sådan en samling formler hurtigt kan blive lige så lang som programmet selv, burde det være klart for enhver programmør, at sådan en formel specifikation selv vil indeholde fejl. Naturligvis vil man opdage de fleste fejl i både programmet og den formelle specifikation, når man forsøger at føre beviset af den simple årsag, at fejlne gør det umuligt at føre beviset. Desværre er der ingen, der siger, at de, der har skrevet programmet, og de, der har skrevet den formelle kravspecifikation, ikke har lavet den samme brøler. F.eks. er både program og den formelle kravspecifikation afledt af en kravspecifikation i almindeligt sprog, og er der fejl i denne, (og det er der jo nok,) så kan disse fejl ende i både program og formel specifikation. Ham det skriver programmet, og ham der skriver specifikationen, vil typisk også have den samme skoling. Hvis krav specifikationen i almindeligt sprog ikke er 100% entydig, kan det ske, at begge misforstår specifikationen på den samme måde.

Kigger man på de ulykker, der har vøret med Airbus fly, så viser det sig, at de flere af dem helt eller delvis skyldes, at piloterne ikke kendte og forstod brugerinterfacen godt nok. Verifikation er uegnet til at afsløre den slags problemer.

  • 0
  • 0
#15 Poul-Henning Kamp Blogger

Det næste problem er, at beviserne kun viser en ting, nemlig at programmet er korrekt i forhold til den samling af matematisk logiske formler, der udgør den formelle kravspecifikation.

Dette er den helt centrale kerne i problemet: en meget stor andel af alle "programfejl" og "computerfejl" er i virkeligheden specifikationsfejl, tastefejl, misforståelser og almindelig sjusk.

Derfor er den rigtige holdning ikke at spilde penge på matematiske beviser, eller kæmpe for dagbøder i kontrakten, men at indrette sin organisation så den er robust overfor computere eller mennesker der ikke opfylder deres job.

Jeg mindes da direktøren for Københavns Lufthavne blev interviewet om Y2K, han sagde noget i stil med: Vi har folk nok, de ved hvad opgaven er, så jeg er ikke nervøs. Om vi så skal have dem til at gå rundt med papskilte skrevet bag på brugte pizzaæsker, skal vi nok få kunderne med de rigtige flyvere.

Det er den rigtige holdning til programfejl.

Poul-Henning

  • 0
  • 0
#16 Karsten Nyblad

Der er en syg accept i samfundet. Mange går ligefrem så langt som til at postulere at alle programmer indeholder fejl, man kan aldrig blive fri for sikkerhedshuller osv. Det bliver til en selvopfyldende profeti, så længe fejl er så bredt accepteret så bliver der heller ikke gjort det store fra udviklerne for at undgå dem.

Problemet er, at alt alle ikke trivielle programmer har så mange forskellige input, at man ikke kan teste dem alle. Lad os f.eks. sige, at vi skal test en rutine, der indlæser passwords. Så skal vi teste at den virker, lige meget hvilke tegn, der bliver brugt. Ikke bare det, men man skal også teste alle kombinationer af tegn. Det kunne jo vøre, at af en eller anden syg årsag virker rutinen ikke, når passwordet er abekat eller @{{åå. I dag er det helt almindeligt med internationele websites, så derfor skal rutinen også kunne håndtere kyriliske, græske, kinesiske, og f.eks. japanske tegn. Hvis et password må være f.eks. 10 tegn langt, så giver det 18*10**30 muligheder at teste, og så har vi ikke en gang testet, at rutinen virker, hvis en bruger taster for mange tegn ind.

Det var et simpelt eksempel, hvor mængden af input er endelig, men allerede her er antallet af ting, der skal testes, så stort, at det ikke kan gøres i praksis. I de fleste rigtige programmer er der ikke rigtig nogen øvre grænse for, hvor mange forskellige input der kan komme. Lad os bare tage en så simpel applikation som denne website. Selv hvis vi ser bort fra, at folk kan taste et astronomisk antal forskellige artikler ind, så er der masser af andre faciliter, der hurtigt bringer antallet af ting, der skal testes så højt op, at det ikke kan gøres i praksis. F.eks. skal det testes, at alle mulige e-mail addresser kan bruges som brugernavne, og igen skal passwordrutinen testes. Så skal faciliterne til administration testes, journalisterne skal kunne lægge artikler, videoer osv. på siten. Alt det skal virke, selv om ingen ved, i hvilken orden journalister, systemadministratorer og læsere gør hvad i. I teorien skulle man teste, at journalisterne og brugerne kan lægge alle mulige artikler ind i en hvilken som helst orden. Inden du har set dig om, er antallet af muligheder igen ufatteligt højt.

Vi har ganske enkelt ikke softwareteknikkerne til at skabe korrekte programmer. Selv ikke i situationer, hvor man er villig til at betale mange penge kan det lade sig gøre. Der er også fejl i den software, der bruges i passagerfly og i våbensystemer.

  • 0
  • 0
#17 Torben Mogensen Blogger

Dette er den helt centrale kerne i problemet: en meget stor andel af alle "programfejl" og "computerfejl" er i virkeligheden specifikationsfejl, tastefejl, misforståelser og almindelig sjusk.

Det er rigtigt, at specifikationer (både formelle og uformelle) ofte indeholder fejl, men det er nu en gang det man har. Det eneste test og verifikation ellers kan afsløre (eller udelukke) er køretidsfejl.

Men man verificerer i reglen ikke imod en komplet specifikation, men for at udelukke særlige fejlsituationer: Man viser ikke, at programmet gør "det rigtige", men f.eks. at det ikke kan lave deadlock eller andre uheldige opførsler. Til dette er verifikation ofte bedre end test: Du kan f.eks. ikke med test alene sikre imod deadlock.

Man kan også bruge verifikation og test på specifikationer: En verifikation kan f.eks. sikre, at en protokol sikrer mod datatab (så længe, der ikke er 100% tab af pakker). Man kan også teste en specifikation: Man kan checke, at positive (korrekte) testdatasæt opfylder specifikationen og negative (ukorrekte) testdatasæt er udelukket af denne.

  • 0
  • 0
#18 Poul-Henning Kamp Blogger

Torben,

Forskellen på dit syn og Oles syn på sagen er, at du kun ser på hvad der skal få computerne til at køre, mens Ole er nødt til at få hele butikken til at køre.

IT folk, af alle arter, er uhyggeligt dårlige til at få en butik til at køre, fordi de glemmer at computeren kun er et element af hele problemet.

Således også du.

Poul-Henning

  • 0
  • 0
#19 Deleted User

Forstå mig ret, jeg tror heller ikke at vi kan blive fri for softwarefejl. Der hvor kæden hopper af er når folk accepterer enhver fejl. Cowi fx burde ikke have haft en krone for deres test klamphuggeri, men de fik alligevel de alt for mange millioner fordi nogen blødsødne folk på den anden side af bordet tror på at den slags er sort uheld og ikke inkompetence.

  • 0
  • 0
#20 Poul-Henning Kamp Blogger

Det er vi sådan set enige om.

Men fakta er at de fleste institutioner har en stor robusthed overfor fejl de kan se foran sig, blå skærm, programmer der hænger osv. Men hvis programmet ser ud til at køre, har de en tyrkertro på at output er 100% rigtigt. Computere siger det jo...

Poul-Henning

  • 0
  • 0
#21 Morten Bøgh

Selv med en systematisk udviklingsproces og en systematisk test og med brug af den bedste vilje slipper der fejl igennen. Det betyder at det er væsentligt at kunne rette fejl sikkert og hurtigt når de efterfølgende dukker op.

Et paradoks er, at hvis systemudviklingsprocessen drives i retning af at kunne føre matematisk bevis for programmets korrekthed, vil det gøre det sværere at rette de fejl der (alligevel) dukker op. Thi vi er så inde i et scenarie med meget omfattende test som skal bevise en overensstemmelse mellem en meget omfattende dokumentation og et tilsvarende programmel. Så du retter ikke bare programmet og kører en specifik test mod rettelsen samt en generel acceptest, næh næh næh det må man ikke, du skal iterere store dele af projektforløbet. Du har dobbeltarbejdet med at beskrive systemet både i en dokumentation og i et programmel plus arbejdet med at føre bevis for at de to beskrivelser stadig er ens.

Når systemet så er rettet, skal rettelsen ind i brugernes miljøer. Her er også et rigt område for bureaukrati og tunge værktøjer.

Det er det med den amerikanske talemåde: it's not rocket-science. Nul-tolerance overfor fejl er ligeså naturstridig som at forsøge at lodret-starte en næsetung, hækmotordrevet raket. Det kræver enormt mange hvidkitlede eksperter og lykkes alligevel ikke. Det kan bedre betale sig at investere i en ordentlig fejl-rettelses-proces og bruge den feedback man får fra virkeligheden:

Du sørger for at holde udviklingsprojektet bemandet efter at det er afsluttet, du sørger for at bruge en metodik som er rimeligt agil (hvilket i høj grad kan koges ned til at dobbeltarbejde som ovenfor beskrevet skal undgås), du sørger for en kort pipeline mellem kode og kørende system således at en programrettelse kan være i brugernes system på under x timer. Du sørger for at eventuelle underleverandører i systemudviklingen kører processerne på samme vis.

Læg hertil at systemets grunddesign skal være robust overfor rettelser (dvs at grunddesignet ikke indeholder fejl), og især at databasesiden af systemet ikke må have grundlæggende fejl. Da dette er uladesiggørligt, må man acceptere en vis grad af rettelser som ikke er optimale: fejl i grunddesignet som løses fx ved misbrug af databasesiden. Sådanne rettelser kan også være kompensation for fejl hos underleverandøren som de ikke selv vil rette. Konsekvensen bliver en langsom invalidering af systemets oprindelige overskuelige struktur, dvs i løbet af nogle år opstår et behov for omprogrammering af dele af systemet for at genskabe en overskuelighed der kan rettes videre i....

Det er ikke nemt, overhovedet ikke. Men det bliver ofte sværere når et fejl-forebyggende bureaukrati lægges ovenpå. Kontraktmæssig adskillelse af udvikling og drift i hvert sit udbud kan også bidrage til problemer. Overhovedet ideen om at købe software på samme måde som man køber VVS-installationer. Software er en relation, et leverandørforhold, ikke bare en leverance.

Fejl skal ikke undgås, de skal minimeres, og dem der slipper igennem skal rettes.

  • 0
  • 0
#22 Deleted User

"A bug is something that bugs somebody who matters."

Det er stjålet fra James Bach og Michael Bolton (ikke sangeren), og jeg bruger det selv som "huskeregel", det strider måske mod hårde kravspecs. (der forudsættes at være 100% korrekte), og som tager højde for alle permutationer i kode samt kørselsmiljø, men det er nok mere reelt ift. alle interessenters oplevelse af et system.

  • 0
  • 0
#23 Deleted User

Hvis en programstump i teorien kan gøre noget forkert, men aldrig gør det i praksis, er det så en fejl ?

Den type fejl, er ikke kun dem som er sværest at finde, men desværre også oftest de alvorligste. Fejl, som opstår ved tests, er ofte overvejet, og årsagen til de ikke rettes, er en overvejelse over omkostninger ved fejlretning, og risiko. Derimod fejl, som kun sker, når det virkeligt går galt, er helt ukontroleret, og måske langt værre, end kan accepteres.

Vi må acceptere at mennesker fejler. Alligevel, er det vores pligt, at sikre at softwaren ikke fejler. Det kan ske, ved at anvende metoder, både når vi programmerer, og når vi tester. I nogle tilfælde, kan vi reducere risikoen for fejl, ved at lade flere implementere samme program/funktion, og sammenligne dem med hinanden runtime. Derved testes også, at specifikationerne er enentydige, og ikke forstås forskelligt, af flere hold uafhængige programmører. Naturligvis øger det omkostningerne - både fordi, at opgaven kodes flere gange, og fordi at flere fejl end normalt opdages, og må rettes. Og samtidigt, øges prisen, fordi at fejlene skal rettes, for at kunne fortsætte.

Det er vigtigt, at vi ikke bare accepterer fejl - for så bliver der flere af dem. I princippet, så skal vi lave fejlfri kode, og programmerne må ikke indeholde fejl. Alligevel, er vigtigt, at vi har forståelse for, at programmører ikke er uden fejl. Den største fejl, som man kan begå, er at kræve fejlfrie programmører, fordi man skal løse en opgave fejlfrit. Det rigtige er, at tage højde for, at programmører fejler. En programmør, der begår fejl, kan være mindre farlig, fordi man ved han begår fejl, end en som næsten er fejlfri, og som man derfor stoler på.

Jeg tror, at det er gået så galt indenfor software, fordi der ikke har eksisteret de sædvanlige garanti og reklamasionsforpligtelser, som gælder hardware. Det er også meget svært, at lave pålideligt hardware. Alligevel, så er det lykkedes, og normalt er det ikke hardwaren som laver fejl. Det skyldes, at det er dyrt at rette fejl på hardware, og at forbrugerlovene kræver garanti. Derfor, er nødvendigt, at udvikle hardwaren, så der ikke er fejl, når den når køberen. Ellers koster det kassen. Indenfor software, er fejl noget, som kan rettes gratis. Der lægges bare en gratis update på nettet, og så forventer man, at køberen selv løser det. Ugentlige rettelser, er helt utænkeligt indenfor hardware - både på grund af prisen, og fordi at loven forbyder det. Et produkt, skal rettes, indenfor et rimeligt antal forsøg, og ellers kan kunden kræve at få pengene retur. For avancerede produkter, accepteres dog et større antal forsøg, end for et simpelt produkt. Men ugentlige rettelser er helt utænkelige.

  • 0
  • 0
Log ind eller Opret konto for at kommentere