altinn – som forventet

Det fine med kriser er at det gir en anledning til å lære. Enkelte områder ansees så kritiske at det øyeblikkelig nedsettes en havarikommisjon eller lignende når en ulykke inntreffer. Hensikten er selvfølgelig å dra lærdom av hendelsen. Det positive med de siste dagers altinn-problemer er at DNV sin Tekniske Rapport Vurdering av Altinn II Plattformen ble frigitt. Rapporten har faktisk en litt misvisende tittel, for her vurderes i stor grad utviklingsprosjektet og ikke den ferdige løsningen. Veldig interessant lesning!

Prosjektets utilstrekkelighet


Altinn II utviklingen ble kjørt som et tradisjonelt prosjekt mot en sluttermin, med Accenture som leverandør. Dette prosjektet må kunnes sees på som ganske vellykket, for Altinn er blitt et system som gjør hverdagen til både bedrifter og enkeltpersoner betydelig enklere. Men så var det dette med kvaliteten da. Hvor gode betingelser har vi for å levere god kvalitet når arbeidet organiseres som prosjekter? SMÅ! I hvert fall om det som skal utvikles er komplekse systemer. Vi har snakket og skrevet om dette gjentatte ganger.

Problemet er altså at det synes uungåelig at vi styrer mot tid og kost, i stedet for å fokusere på høy kvalitet. For hva er egentlig høy kvalitet i programvare? Ikke helt lett for en stakkars kunde å vite hvordan man måler dette. Og det som ikke er målbart, blir konsekvent ofret – når vi er under press. Leverandøren har som regel kunnskap om hva som er kvalitetsmessig godt håndtverk, men velger under press å ofre dette. For godt håndtverk tar tid.

Testing og feilretting

“Alle” i programvarebransjen vet nå ta du må teste grundig, automatisk og så tidlig som mulig. Feil skal ikke finnes i produksjon – da er de ekstremt dyre å finne og rette. Vi automatiserer gjerne tester på flere nivåer. Problemet med dette er at det tar tid. Fra rapporten:

5.2 Feil og feilretting

Som beskrevet i avsnitt 5.3 Test, er det vår oppfatning at kvaliteten på testingen har vært for dårlig i alle faser – fra modul-/ enhetstest til akseptansetest. En konsekvens har bl.a. vært at det er produksjonssatt en løsning med mange kjente og ukjente feil. For dårlig testing i alle faser har resultert i at mange feil har blitt oppdaget sent. Feil som burde vært funnet

i modul-/ enhetstest avdekkes ikke før i integrasjonstest, feil som burde vært funnet i integrasjonstest avdekkes ikke før i systemtest, osv. Erfaringene fra akseptansetest er at det ble funnet feil som klart burde vært avdekket tidligere. Videre har vi også fått opplyst at fatale feil ikke ble avdekket før produksjonssetting.

Grafen er sakset fra rapporten og viser DNV sitt syn på kostnadskonsekvensene ved å oppdage feil sent i prosessen.

Dette viser en utvikling som ikke akkurat er under kontroll. Når man finner så mye feil så sent i prosessen forteller det oss at dette systemet ikke er stabilt.

Teknisk Gjeld

Rapporten peker gjentatte ganger på at man her har bygget opp en teknisk gjeld. Teknisk gjeld er en god metafor for det som skjer når man forsøker å vinne tid eller penger ved å unnlate å gjøre håndtverket skikkelig. Testing er en opplagt kandidat til å gjøre mindre av. Dokumentasjon og refaktorisering av kode og struktur er andre områder. DNV har skutt inn et utdrag fra en annen rapport:

CapGemini gjorde på oppdrag av BRREG to kodegjennomganger en i 2009 /112/ og en i 2010 /113/.
Fra CapGemini code review report /112 / har vi sakset følgende oppsummering:
“De svakeste områdene i Altinn II er følgende:
Enhetstestene inneholder mange feil og er ikke komplette
Deler av koden virker uferdig med mange TODO‟s og utkommentert kode
En del metoder er svært lange og komplekse
Noen steder har vi funnet try-catch-blokker som ”svelger” feil uten å gjøre noe med disse
Presentasjonsprosjektet framstår som rotete. Det er ingen skiller mellom presentasjon,
datahåndtering og forretningslogikk. “

Endringskostnader

CoC - Cost of Change

CoC - Cost of Change

Alt dette peker mot det vi ofte kaller “slutterminens forbannelse”. Når man kjører komplekse prosjekter på denne måten virker det som en naturlov at denne gjelden blir stor. Stor teknisk gjeld fører til ustabile systemer med mye feil. Men det har også en annen effekt, nemlig at endringskostnadene over tid skyter i været.

IT-systemer har ofte (overraskende) lang levetid, og de er under stadig utvikling. Det er sjelden slik at en stor leveranse er slutten på nyutvikling. Når vi så kjører mot slutterminen med en leverandør som er på fastpriskontrakt får vi også unødvendig dyrt vedlikehold over tid. De store IT-kundene bør tenke nøye igjennom hvordan de bruker pengene på IT-utvikling. Kanskje det er på tide å utfordre prosjekttankegangen?

Bruk rammeavtale i stedet!

Altinn er ikke enestående, dette er normalen innen IT-prosjekter i norge. Vi kan anta at det er bygget opp en formidabel teknisk gjeld i IT-systemene her i landet. Men det er fullt mulig for en IT-kunde å ta styringen selv. I stedet for å legge ut fastprisavtaler med en leverandør som ikke har egen interesse av å levere høy kvalitet kan man bruke en “Time and material” type avtale der leverandørene stiller opp med kompetanse og ressurser, mens kunden selv styrer. Vi tror dette vil kunne spare samfunnet for mye tid, penger og ergrelser. I en rammeavtale kan fokuset ligge på det som er viktig over tid. Man kan spare mye ressurser i startfasen, siden man slipper den store, tunge anbudskonkurransen. Samtidig kan styringen gjøres betydelig enklere gjennom smidige metoder. Og man får validert løsningene underveis og kan med enkle grep unngå at testing og annen god praksis ofres til fordel for framdrift.

Begynn å ta virkeligheten på alvor! 

 

Posted on March 22, 2012 at 9:56 pm by gamsjo · Permalink
In: prosjektledelse, Samfunn · Tagged with: , ,

21 Responses

Subscribe to comments via RSS

  1. Written by Arve Systad
    on 23/03/2012 at 12:10 am
    Reply · WordPress › Error