Oslo 20170628. Datakriminalitet kan regnes som kriminalitet som er rettet mot data og datasystemer, og kriminalitet hvor datautstyr benyttes som verktøy for å begå handlingen. Foto: Lise Åserud / NTB scanpix

Det er beklagelig nok en rekke eksempler på store offentlige IT-prosjekter som feiler, og man kan spørre seg om det er et mønster, og i så fall hvorfor. Det foreligger flere forskjellige typer av offentlige IT-prosjekter, her skal vekten legges på utvikling av IT-systemer, mens drift av IT-systemer belyses i en senere artikkeldetaljeringer

I stikkords form kan de forskjellige fasene IT-systemutvikling, ideèlt sett, beskrives slik:
• Et prosjekt starter med en bestilling, inneholdende en tilsynelatende komplett     kravspesifikasjon.
• Dette resulterer i et IT-system – en applikasjon – som dekker kravspesifikasjonen, enkelt og greit.

Slik er det ikke, så langt der ifra, virkeligheten er tvert imot:
• Kravspesifikasjon, viser seg utilstrekkelig, idet utviklerne raskt kommer tilbake med detaljspørsmål.
• Bestillerens nødvendige detaljeringer og utvidelser øker i rykk og napp slik at prosjektets ramme og overordnede egenskaper øker både i bredden og dybden.
• Stemningen mellom bestiller og utfører blir dårligere og dårligere. Bestilleren opplever utviklerne som til dels nedlatende og svært lite samarbeidsvillige, mens utviklerne opplever at bestillernes ønsker stadig detaljeres, i praksis øker, uten at bestilleren tar dette innover seg.
• Prisen øker – og leveransen forsinkes.

Hvorfor er det slik? Svaret er enkelt; i alt annen enn små applikasjoner er mulighetene for tolkning av spesifikasjonene som oppleves som uklare og ufullstendige, ikke fordi bestilleren er inkompetent, men fordi antall mulige alternativer er uhåndterlig, dvs. at det ikke er mulig å tenke gjennom alle detaljer ved bestillingen. Under prosjektarbeidets gang dukker det også opp ønsker fra bestiller som opplever av utviklerne som utvidelser som har potensiale for å innebære vesentlig økning av systemets størrelse.

Årsaken til dette kan beskrives slik: system-spesifikasjonen (også kalt –definisjonen) er en del av systemutviklingen, og omvendt. Dette har vært kjent lenge, den første som beskrev en empirisk utviklet teori som tar høyde for dette var en glup nederlender ved navn Rittel, allerede på slutten av 60-tallet. En avledet metode er «smidig systemutvikling».

Nå har fornektelse av dette ubehagelige faktum resultert i flere spektakulære, og meget dyre, feilslåtte IT-utviklingsprosjekter med offentlige bestillere. Dette skjer selvfølgelig også i privat virksomhet, men i mindre omfang. Årsaken til de offentlige institusjoners ofte lite heldige rolle som bestillere er selvfølgelig basert på flere forhold. Det viktigste er dog manglende IT-kompetanse, slik at den prosjekt-enheten som skal kontrollere arbeidet gang, styringsgruppen, ikke kan gå inn på ønsket faglig detaljnivå, men overlater dette til utvikleren. En klassisk «bukken og havresekken». Det finnes nødvendig «hard» faglig kompetanse der ute, som effektivt kan bistå en styringsgruppe, men dette oppleves nok som uønsket innblanding og også en fallitterklæring til egen kompetanse. Beklagelig, unødvendig og svært dyrt for samfundet!

Advertisements
Bjørn Brevik
En av de første med cand. real. graden, fra Universitetet i Oslo 1973, med hovedfag konsentrert rundt avansert IT, nærmere bestemt basis programvare (system software). Hovedinteresse er å følge med i utvikling av (applikasjoner med funksjonstype) kunstig intelligens, AI, og bidra til øket forståelse av denne utviklingen.

Velkommen til Resetts kommentarfelt

Kommentarer forhåndsmodereres, det kan derfor ta noe tid før de dukker opp i kommentarfeltet. Skriv gjerne kort. Resett tar ikke ansvar for lenker til andre sider og for filmlenker. Resett står ikke inne for meningene som uttrykkes av den enkelte kommentator. Personangrep, hets, trusler og oppfordring til vold, spamming, trolling og avsporing av debatten er ikke tillatt. Det oppfordres til normal høflighet. Resett forbeholder seg retten til å fjerne enhver kommentar uten begrunnelse. Ved å kommentere her godtar du disse betingelsene. Gjentatte brudd på betingelsene kan føre til utestengelse.
Har du spørsmål knyttet til kommentarfeltet kan du sende det til [email protected]