Vattenfallsmodellen

Vattenfallsmodellen är ett sätt att driva ett projekt, till exempel ett större administrativt datasystem. Tanken är att varje steg ska vara helt klart och bedömas innan man går vidare i nästa steg. Vattenfallsmetoden är mer än 30 år gammal.

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ör ett datasystemprojekt kan stegen i vattenfallsmodellen variera men oftast finns dessa steg med.

• Förstudie / behovsprövning
• Kravspecifikation / funktionell specifikation
• Designspecifikation
• Implementation
• Test
• Integration / leverans
• Drift och underhåll

Fördelar

• Kostnadskontroll, beställaren (den som betalar) kan besluta i varje steg huruvida projektet ska startas, fortsätta, avslutas eller läggas på is. 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.
• Det som levereras är testat och är kvalitetssäkrat.

Nackdelar

• Vattenfallsmodellen hanterar egentligen inte förändringar. Ett förändringsförslag (tilläggsbeställning) måste gå igenom flera steg för att genomföras.
• Det blir många dokument. Flera av dem är nödvändiga, andra dokument kanske inte kommer att läsas.
• 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

Vattenfallsmodellen har fått mycket kritik och de flesta hävdar idag att det är bevisat via undersökningar att det inte fungerar för att utveckla datasystem. 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).