www.imCMS.net - Iterativ utveckling - om utvecklings-<br>metoder

Hem

Prova imCMS här och nu!

Ladda ner

Argument för imCMS

imCMS & Offentlig sektor

Varför ger vi bort imCMS?

Case study Gotland

Exempel på kunder och projekt

In English »


Iterativ utveckling - om utvecklingsmetoder

Det finns 2 huvudmetoder (med ett otal varianter) att använda när man vill bygga upp webbaserade system, t ex ett intranät. I systemutvecklingsteori brukar huvudmetoderna kallas för "Vattenfallsmetoden" respektive "Iterativ utveckling". Ofta är upphandlingsrutinerna hos företag och myndigheter anpassade till den äldre "Vattenfallsmetoden". Detta ger en sämre slutprodukt, högre totalkostnader och mindre inflytande för uppdragsgivarna. Detta dokument vill kortfatta beskriva fördelarna med att i stället använda en iterativ utvecklingsmetodik.

Vad innebär vattenfallsmetoden?
Vattenfallsmetoden har fått sitt namn utifrån liknelsen med ett vattenfall. Om man använder vattenfallsmetoden har processen en enda riktining, det finns en given ordning i vilket saker och ting måste genomföras.Slutresultatet blir en produkt av en kedja händelser i en väl definierad ordning.

Ofta ser processen ut så här:

Förstudie
Under förstudien går man igenom hela projektet och definierar samtliga såväl tekniska som organisatotiska krav som ska ställa på projektet. Här definieras problem som ska lösas och här definieras lösningarna. Ju nogrannare förstudie desto bättre projekt.
Avstämningspunkt med kravställarna (personalen)
Eftert att förstudien genomförts och innan den blivit såväl "Kravspecifikation" som "Upphandlingsunderlag" finns en avstämningspunkt där kravställarna, dvs personalen som ska använda systemet, får en möjlighet att kommentera och komma med förslag till ändringar.
Kravspecifikation och upphandlingunderlag
Förstudien med avstämning leder till såväl kravspecifikation som ett upphandlingunderlag så att man kan välja leverantör för att genomföra projektet (intern eller extern leverantör)
Val av leverantör
Kompletterande förstudie
Leverantören genomför ofta en egen kompletterande förstudie i samverkan med orgnisationen och som denna lämnar synpunkter på
Slutgiltigt produktionsunderlag
Produktion av systemet
Nu startar den egentliga produktionen av systemet. Nu skapas grafisk design, teknisk kod etc. Under processen redovisas förloppet steg för steg mot uppdragsgivaren.
Test av systemet
Efter att produktionen kommit in i sin slutfas, görs genomgripande testningar av systemet, alla funktioner kontrolleras och till slut anser man att systemet är klart att leverera.
Leverans av färdigt system
Implementation in i organisationen
De som ska använda systemet får lära sig hur det fungerar och börjar använda det.

Alla som har genomfört en systemutveckling inom ett företag eller organisation har mer eller mindre följt ovanstående schema. Imånga fall har de också kunnat konstatera att det inte är en väl fungerande metod. Det som levereras är ofta inte adekvat för organisationens behov. Att utveckla det till något som verkligen fungerar är dyrt och omständligt eftersom det innebär att man måste riva upp mycket av det som gjorts och skapa något annat.

Varför fungerar Vattenfallsmetoden dåligt?
Att metoden inte fungerar är inte leverantörernas fel. Problemet med metoden är att alla viktiga beslut tas på förstudiestadiet. Förstudien definierar helt hur slutresultatet kommer att bli.

Men det finns ingen systemutvecklare i världen som i förstudien kan förutse hur den totala samverkan mellan människa och system kommer att fungera. Även om man gör mycket nogranna förstudier, med stora mändgder tid nedlagt på att diskutera med slutanvändarna – är det bortkastad tid. Varken slutanvändare eller den som gör forstudien kan egentligen förstå vad som kommer att komma ut ur projektet. Den mycket nogranna förstudien är bortkastad.

Man kan likna det vid att anlägga en gångväg i en park. Man räknar noggrant ut hur gångvägen ska ligga och hur dess rundade gångbana ska passa in i naturen. När man väl byggt den ser man att folk går någon helt annanstans.

Det som saknas i Vattenfallsmetoden är konkret kunskap om hur systemet verkligen kommer att fungera – och de modifikationer som fortlöpande krävs för att komma till ett väl fungerande slutmål.

Varför används Vattenfallsmetoden?
Till stor del används nog fortfarande Vattenfallsmetoden därför att "så har man alltid gjort". På ytan ser den ut att skapa trygghet. En omfattande förstudie gör att köparen tror att denne vet vad han/hon köper, en kontinuerlig redovisning verkar betryggande under projektet, "vi förstår precis var vi är", och inte minst – upphandlingsprocessen är helt anpassad till Vattenfallsmetoden, såväl inom större företag som offentlig förvaltning (se vidare nedan). Att sedan slutresultatet egentligen inte blir särskilt bra kanske inte syns när "man gjort allt rätt".

Alternativet heter Iterativ utveckling
I modern systemutvecklingsteori finns det en annan metod – den iterativa metoden – som ger ett mycket bättre och säkrare resultat. Den bygger på principen att man tar en liten del av utvecklingsprocessen och gör den så klar att den kan prövas i verkligheten. Man bygger allt, från grafisk design till fungerande funktionalitet. Sedan sätts den i verklig drift, man samlar in erfarenheter från företagets personal och gör sedan om hela utvecklingsarbetet i omgångar tills man är nöjd med slutresultatet. Också här gör man naturligtvis en förstudie innan man börjar, men den behöver inte bli lika omfattande eftersom kraven förändras under projektets gång

Ofta ser processen ut så här:

Förstudie
Under förstudien går man igenom grundförutsättningarna för projektet och definierar det principiella slutmålet, utan teknisk detaljspecifikation.
Avstämningspunkt med kravställarna (personalen)
Eftert att förstudien genomförts och innan den blivit såväl Kravspecifikation som Upphandlingsunderlag finns en avstämningspunkt där kravställarna, dvs personalen som ska använda systemet, får en möjlighet att kommentera och komma med förslag till ändringar.
Kravspecifikation och upphandlingunderlag
Förstudien med avstämning leder till såväl kravspecifikation som ett upphandlingunderlag så att man kan välja leverantör för att genomföra projektet (intern eller extern leverantör)
Val av leverantör

Faser som repeteras tills man uppnåt tillräckligt slutresultat:

Förstudie av genomförandefas
Leverantören initierar i nära samverkan den första teknisk/funktionella förstudien och definierar vad som ska göras. Samtidigt är man väl medveten om att erfarenheter som görs i projektet kommer att förända förstudiens giltighet.
Produktionsunderlag och kravspecifikation
Produktion av systemet
Nu startar den egentliga produktionen av i denna fas. Här skapas grafisk design, teknisk kod etc.
Driftsättning av systemet i verklig provdrift i organisationen
Systemet sätts i drift hos slutanvändarna. De som ska använda systemet får lära sig hur det fungerar och börjar använda det. Användarna får reagera på hur systemet fungerar. Det system som driftsätts är en ganska liten del av det totala systemet. I början av projektet är det grundfunktionalitet, mot slutet modifieringar och tilläggsfunktionalitet.
Utvärdering
Erfarenheter från produktionen och driften tas till vara och läggs som ett underlag för nästa förstudie.
Ny förstudie, dvs tillbaka till punkt 1.

Slut repetition

Varför fungerar Iterativ utveckling väl?
Den iterativa metoden förutsätter att man tar små steg och genomför dem tills man är säker på att såväl användare som utvecklare har samma bild av vad som ska utvecklas. Varje enskild förstudie blir kortare och det blir enklare att visualisera och få verklig erfarenhet av hur projektets slutresultat kommer att bli. Allt hänger inte på den första förstudien, utan projektet korrigerar sig löpande. Skulle man ha råkat ta en något felaktig riktning från början, kommer detta snabbt att korrigera sig i nästa genomförandefas.

Om man liknar också detta vid att anlägga en gångväg i en park skulle det betyda att man först bygger parken utan att anlägga gångvägar, släpper in människorna, ser hur de går, och sedan anlägger gångvägarna där människorna vandrat. Det är betydligt träffsäkrare.

Varför används inte Iterativ metodik oftare?
Den viktigaste orsaken till att iterativ metodik inte används oftare är kanske att man inte i förväg kan säga exakt hur mycket varje fas kommer att kosta. Faserna är ju inte definierad när man startar projektet. Argumentet är inte hållbart om man ser till slutresultatet, eftersom metoden ger ett billigare och mycket träffsäkrare resultat, men det kan kännas tryggt för upphandlarna att veta på kronan när vad projektet kommer att kosta, oavsett om det sedan fungerar eller ej.

En annan förklaring är att traditionell upphandling, inte minst från offentlig sektor, inte i första hand går ut på att skapa det effektivaste systemet för organisationen, utan att göra upphandlingen korrekt och opartiskt. D v s ju mer av "hårda fakta" man kan definiera i upphandlingen, desto träffsäkrare anser man att leveransen från den upphandlade leverantören blir. Upphandlarna har svårt att hantera mjukare fakta som förmåga till samspel med organisationen och förmåga att ta till vara erfarenheter som gjorts under projektets gång. Upphandlingssystemen är i grunden inte anpassade till att köpa något man inte i detalj kan definiera från start.

En tredje förklaring är nog helt enkelt okunskap, både från leverantörer och upphandlare. Det blir andra faktorer än de traditionella som avgör om man har en kunnig leverantör. Mer avgörande blir förmågan till samverkan med den interna organisationen och mindre avgörande teknisk kapacitet. Fortfarande tror många företag att skapandet av t ex intranät eller kvalificerade webbportaler är tekniska projekt, medan de i verkligheten är kvalificerade organisationsprojekt, där den största delen av kostnaden ligger i interna timmar för den egna personalen. Tar man hänsyn till den interna arbetsbelastningen är iterativ utveckling skyhögt överlägsen traditionell Vattenfallsmetodik.

Klicka här om du vill läsa om ett typfall som använder iterativ utvecklingsmetodik

Visby 2003-02-16

^©Hillar Loor

Aktuellt

Gotlandska.se har bytt till imCMS