Skat-direktør: Vandfaldsmodellen er ikke måden at lave it-systemer på

5 kommentarer.  Hop til debatten
Skats direktør erkender, at vandfaldsmodellen er problematisk, men påpeger samtidig, at Skat har været fanget i en forældet tankegang.
14. juli 2016 kl. 11:35
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Vandfaldsmodellen får en del af skylden for de store offentlige it-skandaler, fordi den ikke giver mulighed for at gå tilbage og prøve en ny tilgang, hvis en del af projektet viser sig at volde problemer. Modellen har været brugt i store projekter som eksempelvis Skats EFI-system, der endte med aldrig at komme til at virke.

Derfor erkender Skats direktør Jesper Rønnow Simonsen da også, at modellen er problematisk:

»Vi har for længst taget til os, at vandfaldsmodellen ikke er måden at lave it-systemer på. Men Skat har i visse tilfælde desværre været tynget af sin arv og fanget af en forældet tankegang,« udtaler Jesper Rønnow Simonsen i et skriftligt svar til Version2.

Udtalelsen er et svar på en del af den kritik, som tidligere it-arkitekt på EFI-systemet, Kristian Mandrup, har fremsat på Version2.

Artiklen fortsætter efter annoncen

EFI-systemet var en del af en omfattende systemmodernisering, der blev planlagt i årevis og iværksat i 2006. EFI skulle således spille sammen med flere andre planlagte systemer, herunder det såkaldte Debitormotorsystem, DMI. Systemerne blev udviklet af forskellige leverandører, og det viste sig sent i forløbet, at det var sværere end ventet at få de to systemer til at arbejde sammen.

Systemmoderniseringen var imidlertid planlagt efter vandfaldsmodellen med forskellige fastlagte etaper, budgetter og mål. Projekterne blev forsinkede, og eksterne konsulenter advarede om, at der var høj risiko forbundet med projekterne.

Alligevel vurderede Skat, at det ville være muligt at nå i mål, selvom tidsplanen og budgetterne var overskredet. Det var først, da systemet blev taget i brug, at det for alvor viste sig, at der var alvorlige fejl i de beregninger, systemet foretog, som blandt andet indebar, at det ikke håndterede forældelsesfrister korrekt.

Derfor blev systemet taget ud af drift igen, og efterfølgende konkluderede nye konsulentrapporter, at det ikke ville være hensigtsmæssigt at prøve at få det leverede system til at virke efter hensigten på grund af den grundlæggende arkitektur, der var blevet fastlagt helt tilbage i udarbejdelsen af udbud og kravspecifikation.

Nu skal der udvikles et helt nyt system, der skal varetage de opgaver, EFI skulle have klaret, som i dag er overtaget af manuelle processer hos Skat.

Kritikere som Kristian Mandrup mener, at hvis man havde benyttet sig af agil udvikling, ville det have været muligt tidligere i forløbet at opdage problemerne med arkitekturen og lave den om.

I dette tilfælde var leverandørerne og Skat bundet af kravspecifikationen og kontrakten. Problemerne fortsatte også, selvom der undervejs blev udskiftet leverandører på projektet.

Det offentlige er siden kontrakterne om EFI blev indgået blevet mere åbne over for kontrakter, der giver mulighed for agile udviklingsprocesser. Samtidig har blandt andet Skat benyttet sig af muligheden for at lukke projekter, før de var afsluttet, hvis de så ud til ikke at kunne nå i mål.

5 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
5
16. juli 2016 kl. 15:30

Øhh...gad du bare ikke bare læse mellem linierne på min kommentar, eller passede det ikke så godt med den pointe du vil nå frem til?

Du behøver sådan set hverken at tilskrive mig hensigter eller meninger, som ikke står i min kommentar.

4
15. juli 2016 kl. 12:12

Øhh...gad du bare ikke læse resten af dokumentet eller passede det ikke så godt med den pointe du vil nå frem til?

Dr. Royce starter med at gøre opmærksom med visse problemer med fremgangsmåden og DEREFTER kommer han med forslag/løsninger til hvordan man kan minimere de problemer.

Jeg vil faktisk mene at den sidste model (figur 10) vil passe meget godt til (gen)udvikling af et stort offentligt IT-system.

Og jeg er 100% sikker på at der også er offentlige IT-projekter der er kørt agilt og med scrum der kommer til at fejle big-time. Når hverken chefer eller arkitekter har lyst til at indrømme at det er dem, der har ansvaret for fejl og mangler - og ikke nødvendigvis den udviklingsmodel der anvendes - så kommer vi ikke videre.

3
14. juli 2016 kl. 19:22

Året var 1970. I August måned publiceres det oprindelige dokument, hvor Dr. Royce beskriver "vandfaldsmodellen" for første gang i verdenshistorien. Allerede på 2. side beskriver Dr. Royce modellen sådan her:

"I believe in this concept, but the implementation described above is risky and invites failure."

-- Winston W. Royce

Check selv efter:https://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

1
14. juli 2016 kl. 12:54

Vandfaldsmodellen er da glimrende til visse IT projekter....

Har man skidt som input så vil man også altid få skidt som output - uanset model.

Man kan måske få wakeup kaldet lidt tidligere med AGIL - men om det gør at man reagerer/ændre inputtet i SKAT det tvivler jeg på....