Fossefallmodellen

Et eksempel på hvordan fossefallsmodellen kan se ut

Fossefallmodellen er en nedbrytning av aktiviteter i et prosjekt til lineære, sekvensielle faser hvor hver fase avhenger av leveransene fra den foregående fasen og korresponderer med en spesialisering av oppgaver. Tilnærmingen er typisk for visse fagområder i industrien. Innen programvareutvikling anses fossefallmodellen å være blant de mindre iterative og fleksible tilnærmingene ettersom prosessene stort sett flyter i én retning, derav navnet fossefall (nedover, som en foss), gjennom faser som unnfangelse, oppstart, analyse, design, konstruksjon, testing, depolyering og vedlikehold.

Historie

Fossefallmodellen oppstod i produksjons- og byggeindustrien hvor de svært strukturerte fysiske miljøene medfører at designendringer fort blir uoverkommelig dyre underveis i utviklingsprosessen. Da fossefallmodellen ble tatt i bruk i programvareutvikling var det ingen anerkjente alternativer for kunnskapsbasert kreativt arbeid. De siste årene har det vært en tendens til at programvareutvikling i økende grad har tatt i bruk smidige utviklingsmetoder som et alternativ (eksempelvis scrum og kanban).

Modell

I Royces sin opprinnelige fossefallmodell kommer fasene i denne rekkefølgen:

1. System- og programvarekrav: Fanges opp i et produktkravdokument
2. Analyse: Resulterer i modeller, skjemaer og forretningsregler
3. Design: Resulterer i programvarearkitektur
4. Koding: utvikling, testing og integrasjon av programvare
5. Testing: Systematisk oppdagelse og avlusing av programvarefeil
6. Drift: Installasjon, migrering, støtte og vedlikehold av komplette systemer

Dermed hevder fossefallmodellen at man bare bør gå over til en ny fase når den foregående fasen er gjennomgått og verifisert.

Det finnes en rekke modifiserte fossefallmodeller (inkludert Royce sin endelige modell), og disse kan ha små eller store avvik fra den ovennevnte prosessen. Eksempler på slike variasjoner kan være å returnere til forrige sykel dersom man finner feil nedstrøms, eller å returnere helt til designfasen dersom nedstrømsfasene blir ansett som utilstrekkelige.

Fordeler

Tid brukt tidlig i utviklingen kan redusere kostnadene til de senere stadiene. Eksempelvis kan et problem som identifiseres i de tidlige stadiene (for eksempel under kravspesifikasjon) være billigere å fikse enn dersom samme feil dukker opp senere i prosessen (med en faktor på 50 til 200).

Fossefallmodellen resulterer i en prosjektplan med 20-40% av tiden satt av til de to første fasene (kravspesifikasjon, analyse og modellering), 30-40% av tiden til koding og resterende 20-50% til testing og implementering. Det antas at prosjektorganisasjonen må være svært strukturert. De fleste mellomstore og store prosjekter vil ha en mengde med detaljerte prosedyrer og kontrolldokumenter som regulerer hver av prosessene i prosjektet. 

Fossefallmodellen legger vekt på dokumentasjon (for eksempel kravdokumenter og designdokumenter) samt kildekode. Dette kan hindre at kunnskap går tapt dersom gruppemedlemmer forlater prosjektet før det er fullført. Dersom man har et fullt fungerende designdokument kan nye lagmedlemmer eller til og med helt nye lag raskt bli kjent med prosjektet ved å lese dokumentene.

Fossefallmodellen gir en strukturert tilnærming. Selve modellen utvikler seg lineært gjennom diskrete, lettforståelige og forklarlige faser og er dermed lett å forstå. Den gir også lett identifiserbare milepæler i utviklingsprosessen. Dette kan være en mulig årsakt til at fossefallmodellen har blitt brukt som eksempel på en utviklingsmodell i mye litteratur og kursmateriell om programvareutvikling.

Kritikk

Kunder kjenner ikke nødvendigvis så godt til kravene sine før de får se en fungerende programvare, hvilket kan føre til endring av krav og nytt design, utvikling, testing og økte kostnader.

Designere er ikke alltid klar over fremtidige utfordringer når man designer ny programvare eller funksjonalitet, og noen ganger kan det være bedre å endre designet enn å holde seg til et design som ikke tar høyde for nylig oppdagede krav begrensninger eller problemer.

Det kan være en mulighet å håndtere mangel på konkrete krav fra kunder ved å ansette systemanalytikere som undersøker eksiterende systemer for å analysere hva disse gjør og hvordan de kan erstattes. I praksis er det imidlertid vanskelig å opprettholde en streng adskillelse mellom systemanalyse og programmering, ettersom at implementering av et ikke-trivielt system nesten uunngåelig vil avsløre problemer og kanttilfeller som systemanalytikeren ikke har vurdert.

Som et svar på de ovennevnte problemene med en ren fossefallmodell har det blitt laget modifiserte fossefallmodeller, som for eksempel Waterfall with Overlapping Phases, Waterfall with Subprojects og Waterfall with Risk Reduction.

I 1994 med utgivelsen av MIL-STD-498 uttalte det amerikanske forsvarsdepartementet at de foretrekker å ikke bruke fossefallsmetoder, og oppmuntret istedet til å bruke metoder for iterativ og inkrementell utvikling.

Noen forkjempere for smidige utviiklingsmetoder hevder at fossefallmodellen er en ineffektiv prosess for å utvikle programvare. Noen skeptikere har istedet foreslått at fossefallmodellen er et vikarierende argument som brukes utelukkende for å ha på hende alternative utviklingsmetoder.

Rasjonell enhetlig prosess (RUP) er et rammeverk for utvikling som anerkjenner behovet for milepæler for at et prosjekt skal beholde fremgang etter planen, men oppfordrer til å ha iterasjoner (spesielt innen disipliner) innenfor fasene. RUP-faser blir ofte kalt "fosselignende". 

Se også

• V-modellen