Jeg kjenner ikke prosjektet inngående, og kan derfor ikke si noe om de konkrete problemene, men har lest rapporten, og gjør meg noen tanker. Her har jeg klippet ut noen avsnitt som man kan reflekterer over. Dette er ikke enestående, snarere tvert imot. Her har både kunde og leverandører et ansvar.
"Det er få ikke-funksjonelle krav, til bl.a. ytelse, i mandat og utviklingskontrakt. De kravene som eksisterer der er ofte spesifisert på et for høyt nivå (effektmål, ikke spesifisert som produktmål). Kravene blir vanskeligere å måle og mindre testbare enn funksjonelle krav, og dermed er det vanskeligere å avgjøre om ikke-funksjonelle krav er levert. "
"DNV mener at de kravene som er stilt ikke er “utfordret” godt nok. Vi mener at mengden krav som er utformet, manglende kravhierarki, måten krav er formidlet og håndtert på i Altinn II-programmet er en vesentlig bidragsyter til den kompleksiteten mange opplever med Altinn II-plattformen. Krav som er stilt er i hovedsak funksjonelle krav og med svært variabel detaljeringsgrad. Ikke funksjonelle krav er det svært få av."
Er ikke dette noe vi ofte ser ? Krav er vanskelig, og spesielt de som er ikke-funksjonelle. Her tror jeg både kunde og leverandør har et ansvar. Krav må være målbare (les:kunne verifiseres i test). For en kunde er dette helt avgjørende. En leverandør vil kunne tenke at det som ikke er krav-satt ikke kan slå meg i hodet senere, men det er vel ikke helt riktig.
Her er nok noe av problemet også det offentliges anbuds-regime. Som leverandør vegrer du deg fra å skrive noe annet enn "ja - innfris" i kravmatrisa som fremlegges. Slik dagens regime er du redd for at å endre eller skrive forutsetninger gjør at du taper konkurransen.
"Prosjektstyringen i forhold til test og akseptanse har vært preget av tidspresset i prosjektet og kontraktstruktur, der man har akseptert produksjonssetting av løsning med et stort antall kjente feil. (Se avsnitt 5.3 Testing)"
"Dersom det ikke settes av tilstrekkelig tid til akseptansetest og feilretting i utviklingsprosjekter, vil flere feil videreføres til produksjon. Feilrettingskostnadene for feil i produksjonsmiljø er uforholdsmessig mye høyere enn feilretting under design, utvikling og test. I tillegg påvirker feil i produksjon omdømmet til Altinn II og dermed tjenesteeieres ønske om å utvikle tjenester på plattformen og realisering av gevinster."
Dette er alvorlig. I en slik løsning er test og feilretting essensielt. At man blir presset på tid på store prosjekter er vel det vanlige, og at det da er test som lider - ha det har hendt før. Egentlig vitner dette om at både kunde og leverandør har vært umodne. Ofte beskriver vi et triangel i utviklingprosjekter. Pris - Tid - Kvalitet. Dette er parametre i trianglet som ofte står opp mot hverandre. Kunsten for prosjektet er å balanser de tre parametrene. Det som står ovenfor vitner om at pris og tid har vunnet over kvalitet. Det som da gjøre det dobbelt vondt er at både leverandøren, begge burde være profesjonelle aktører har sviktet.
Kundeutsagn:
- “Forventet bedre kvalitet og ikke alle feil”
-
“Vi må betale for å få estimert endringsforslag”
-
“Vi må betale for å rette feil. Jo flere feil vi finner jo mer koster det oss” "
Forventninger og forventningstyring. Dette er regulert igjennom kontrakten, eller bør være det. Og forankring i mottakers organisasjon. Say no more!
"Skalering ift. antall brukere og antall tjenester: DNV stiller spørsmål ved om systemet vil skalere opp til forventet antall tjenester noen år frem i tid. Arkitekturen er databasesentrisk der det ved skalering vil være flere prosesser som konkurrerer om bruk av samme database. Skalering kan skje opp til et visst nivå gjennom utøking av HW, men utover dette må det gjennomføres flaskehalsanalyser av design og tas tiltak ift. dette. (Ref mer detaljert diskusjon i avsnitt 5.5, Teknisk løsning. "
Ytelse og skalering er en av de viktigste driverne for god arkitektur. Sammen sikkerhet og oppetid. Her kan det virke som om det er valgt en arkitektur som i stor nok grad ikke hensyntar dette. Det som gjør det ekstra kinkig er at AltInn skal voks, og omfatte flere og´flere tjenester fremover. Dette vil kreve en redesign før eller siden. Man kan skalere på HW kun til et vist nivå. Vi kjenner ikke alle designvalgene men det er overraskende at det smeller her. AltInn er tross alt en liten løsning målt opp mot en del andre nett-tjenester du bruker hver dag.
"Den tekniske kompleksiteten er som forventet i et så stort system."
"Den organisatoriske kompleksiteten derimot, er stor, med et meget stort antall interessenter og parter i Altinn II-samarbeidet, hvor flere har sterke forventinger ift. egne behov. Svært få har et komplett bilde av helheten. "
Disse to utsagnene er veldig interessant. Det som sies er at teknisk er ikke løsningen mer kompleks enn nødvendig. Derimot er organisering et issue. Mange parter, lite oversikt - ingen overordnet styring.
"Driftskompetanse har blitt sent involvert i vurderinger ift. arkitekturvalg. Det eksisterer heller ikke et tilstrekkelig produksjonsnært testmiljø for ytelse, "
Jeg "liker" denne. Dette er noe jeg har sett mange ganger. Ofte er det tilnærmet branntette skott mellom drift og utvikling. En utvikler kan ikke drift. De som drifter må derfor inn i prosjektet fra dag en!!
Oppsummert kan en si det er masse som kunne vært gjort anderledes. Det som er interesant er at det er like mye på organisering og krav som ren teknisk løsning - selv om det kanskje er de tekniske manglene som dreper løsningen til slutt.
Er du interessert i å lese heler rapporten fra DNV se her: http://www.regjeringen.no/upload/NHD/Vedlegg/Rapporter_2012/altinn_sluttrapport_20120321.pdf
