Vattenfallsmodellen

Från Wikipedia
Hoppa till: navigering, sök

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.

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 50-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[redigera | redigera wikitext]

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 (verifiering)
  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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

  • 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.
  • 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 [6].

Nackdelar[redigera | redigera wikitext]

  • 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
  • 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

Kritik[redigera | redigera wikitext]

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 IT-system. 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).

Referenser[redigera | redigera wikitext]

  1. ^ United States. Navy Mathematical Computing Advisory Panel. (29 June 1956), Symposium on advanced programming methods for digital computers, [Washington, D.C.]: Office of Naval Research, Dept. of the Navy, OCLC 10794738 
  2. ^ Benington, Herbert D. (1 October 1983). ”Production of Large Computer Programs”. IEEE Annals of the History of Computing (IEEE Educational Activities Department) "5" (4): sid. 350–361. doi:10.1109/MAHC.1983.10102. http://sunset.usc.edu/csse/TECHRPTS/1983/usccse83-501/usccse83-501.pdf. Läst 2011-03-21. 
  3. ^ Royce, Winston. ”Managing the Development of Large Software Systems”. http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf. 
  4. ^ Royce, Winston (1970), ”Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON 26 (August): 1–9, http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf 
  5. ^ Conrad Weisert, Waterfall methodology: there's no such thing!
  6. ^ . http://student.ch.lu.se/kom/10/skda32/wp-content/uploads/2010/10/Vattenfallsmod.pdf.