Vattenfallsmodellen

Vattenfallsmodellen är en sekventiell systemutvecklingsprocess där man ser framstegen som ett flöde (som ett vattenfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstruktion, test, produktionssättning och underhåll.

Historik

Modellen har sina rötter i tillverknings- och byggindustrin där det är mycket kostsamt att införa ändringar sent i processen - om inte omöjligt. Modellen är känd sedan 1950-talet och vid den tidpunkten fanns det inga systematiska modeller för utveckling av programvara, Man hänföll därför till de processer som användes för hårdvara och anpassade dem till programvarutveckling. Tanken är att varje steg ska vara helt klart och bedömas innan man går vidare i nästa steg.

Den första kända presentationen som beskriver användningen av faser i programvaruteknik hölls av Herbert D. Benington på symposiet om avancerade programmeringsmetoder för digitala datorer den 29 juni 1956^[1]. År 1983 publicerades artikeln igen^[2] med förord av Benington där han påpekar att processen i själva verket inte utförs strikt uppifrån och ned, utan förlitar sig på en prototyp.

Den första formella beskrivningen av vattenfallsmodellen anses vara i en artikel från 1970 av Winston W. Royce^[3]. Men Royce använde inte ordet "vattenfall" i artikeln. Royce presenterade modellen som ett exempel på en bristfällig, icke-fungerande modell^[4]. Detta är också i själva verket så termen vanligen används inom programvaruutveckling: att beskriva en kritisk syn på ett vanligt arbetssätt inom programvaruutveckling^[5].

Modell

I originalartikeln beskriver Royce följande steg som gås igenom i nämnd ordning:

1. Kravspecifikation
2. Design
3. Konstruktion (implementation, programmering eller kodning)
4. Integration
5. Test och avslutning
6. Installation
7. Underhåll

Modellen föreskriver att man ska vara färdig med ett steg innan man fortsätter med nästa. Varianter finns och även Royces slutgiltiga modell skiljer sig något.

Analogi

Ett exempel som ofta används på vattenfallsmodellen brukar vara att bygga ett hus. Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för att ta fram specifikationer i form av olika dokument för att få söka bygglov. Därefter byggs huset enligt specifikationen. Då byggnationen påbörjats är arkitekten frikopplad och inga ändringar görs. Efter byggnationen sker inflyttning och drift och underhåll av fastigheten påbörjas.

Fördelar

• Upptäcker problem tidigt under planeringen som kan spara både tid och pengar^[6]
• Hierarkisk projekt som börjar med A, sen B sen C och sist D^[6].
• Kostnadskontroll, beställaren (den som betalar) kan besluta i varje steg huruvida projektet ska startas, fortsätta, avslutas eller läggas på is^{[källa behövs]}. Ett projekt ska kunna återupptas med hjälp av de dokument som redan gjorts.
• Resursplanering eller upphandling kan göras mellan stegen. Om kravspecifikationen och designen är tillräckligt bra så ska vem som helst kunna implementera systemet^{[källa behövs]}.
• Det som levereras är testat och är kvalitetssäkrat.
• Vattenfallsmodellen är även relativt överskådlig och lätt att förstå, detta sparar tid för en projektgrupp då modellen inte behövs förklaras lika ingående i processens start som mindre välkända modeller ^[7].
• Om ett projekt pausas och ska återupptas i framtiden så innebär modellen att dokumentation finns som kanhjälpa till att se var man avslutade sitt arbete och hur långt man kom och vad som ska göras för att få klart projektet^[6].

Nackdelar

• Vattenfallsmodellen skjuter kvalitetsproblemen framför sig och skapar en ökad risk för senare leverans med fler kvalitetsproblem och ökad kostnad jämfört med iterativa modeller^[8]
• Testningen av projektet sker i de sista faserna, vilket innebär att om en bugg skulle uppstå, skulle det i sin tur medföra en hel del backtracking (och tillbaka till redan avklarade faser, och det tar både tid och pengar)^[6].
• Vattenfallsmodellen förutsätter att kraven/uppgifterna/features inte kommer att ändras under projektets gång vilket betyder att modellen inte hanterar förändringar^[6].
• Tidsestimat för arbetet kan bli felberäknat i och med att metoden inte nyttjar ständiga avstämningar^[6].
• Ett förändringsförslag (tilläggsbeställning) måste gå igenom flera steg för att genomföras^{[källa behövs]}.
• Det blir många dokument. Flera av dem är nödvändiga, andra dokument kanske inte kommer att läsas^{[källa behövs]}.
• Oftast är datasystem mycket mer komplexa än vad ett hus är att bygga så denna modell kan bara användas till viss del i projekt för datasystem^{[källa behövs]}.

Kritik

Vattenfallsmodellen har fått mycket kritik och de flesta hävdar idag att det är bevisat via undersökningar att den inte fungerar för att utveckla IT-system^{[källa behövs]}. Modernare metoder menar att man istället borde likna systemutveckling vid ett gemensamt lärande, där beställaren och leverantören tillsammans lär sig om varandras världar och gemensamt bygger en passande lösning i flera steg (iterationer)^{[källa behövs]}.

Referenser