Vattenfallsmodell ( engelska vattenfallsmodellen , ibland översatt som "vattenfallsmodellen" ) är en processmodell för mjukvaruutveckling där utvecklingsprocessen ser ut som ett flöde som sekventiellt passerar genom faserna kravanalys, design, implementering, testning, integration och support . En artikel publicerad av W. W. Royce 1970 nämns ofta som källan till namnet ; trots att Royce själv använde en iterativ utvecklingsmodell .
I en artikel från 1970 beskrev Royce i konceptet vad som nu kallas "kaskadmodellen" och diskuterade bristerna med denna modell. På samma ställe visade han hur denna modell kan förfinas till en iterativ modell.
I den ursprungliga vattenfallsmodellen gick följande faser i denna ordning:
Efter vattenfallsmodellen flyttar utvecklaren från ett steg till ett annat strikt sekventiellt. Först är steget "kravdefinition" helt slutfört, vilket resulterar i en lista över programvarukrav. Efter att kraven är helt definierade sker en övergång till design, under vilken dokument skapas som i detalj beskriver metoden och planen för att implementera dessa krav för programmerare. Efter att designen är helt klar implementerar programmerarna det resulterande projektet. Nästa steg i processen är integrationen av individuella komponenter utvecklade av olika team av programmerare. Efter att implementeringen och integrationen är klar testas produkten och felsöks; i detta skede elimineras alla brister som dök upp i de tidigare utvecklingsstadierna. Därefter implementeras mjukvaruprodukten och dess support tillhandahålls - införandet av ny funktionalitet och eliminering av fel.
Vattenfallsmodellen innebär alltså att övergången från en utvecklingsfas till en annan sker först efter det fullständiga och framgångsrika slutförandet av föregående fas, och att det inte finns några övergångar bakåt eller framåt eller fasöverlappning.
Det finns dock modifierade kaskadmodeller (inklusive Royces egna) som har små eller till och med betydande variationer på den beskrivna processen.
Vattenfallsmodellens metodik kritiseras ofta för bristande flexibilitet och deklarerar formell projektledning som ett mål i sig på bekostnad av tid, kostnad och kvalitet. Men vid ledning av stora projekt var formalisering ofta av stort värde, eftersom det dramatiskt kunde minska många av riskerna med projektet och göra det mer transparent . Därför, även i PMBOK 3: e versionen, var endast metoden för "kaskadmodellen" formellt fixerad och alternativa alternativ kända som iterativ projektledning föreslogs inte .
Sedan PMBOK 4:e versionen har en kompromiss uppnåtts mellan metodologer som är engagerade i formell och progressiv projektledning, där metodologer förlitar sig på flexibla iterativa metoder . Från och med 2009, formellt, erbjuder Project Management Institute (PMI) som standard en hybridversion av projektledningsmetodiken, som kombinerar både fördelarna med vattenfallsmetoden och resultaten från iterativa metodologer.
| Mjukvaruutveckling | |
|---|---|
| Bearbeta | |
Koncept på hög nivå | |
| Vägbeskrivning |
|
| Utvecklingsmetoder _ | |
| Modeller |
|
| Anmärkningsvärda siffror |
|