Fossefallmodellen
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[1] 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.[2]
Historie[rediger | rediger kilde]
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.[3] 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[rediger | rediger kilde]
I Royces sin opprinnelige fossefallmodell kommer fasene i denne rekkefølgen:
- System- og programvarekrav: Fanges opp i et produktkravdokument
- Analyse: Resulterer i modeller, skjemaer og forretningsregler
- Design: Resulterer i programvarearkitektur
- Koding: utvikling, testing og integrasjon av programvare
- Testing: Systematisk oppdagelse og avlusing av programvarefeil
- 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.[4] 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[rediger | rediger kilde]
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).[5]
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.[6]
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.[7]
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.[8]
Kritikk[rediger | rediger kilde]
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.[9]
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.[10]
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,[11] 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.[5]
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.[12]
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å[rediger | rediger kilde]
Referanser[rediger | rediger kilde]
- ^ www.ntnu.no https://www.ntnu.no/iie/fag/maler-standarder/fossefall/index.php. Besøkt 22. mai 2022.
- ^ «The Traditional Waterfall Approach». Besøkt 23. februar 2022.
- ^ Benington, Herbert D. (1. oktober 1983). «Production of Large Computer Programs» (PDF). IEEE Annals of the History of Computing. IEEE Educational Activities Department. 5 (4): 350–361. doi:10.1109/MAHC.1983.10102. Arkivert fra originalen (PDF) 18. juli 2011. Besøkt 22. mai 2022. Arkivert juli 18, 2011, hos Wayback Machine
- ^ Royce, Winston (1970), «Managing the Development of Large Software Systems», Proceedings of IEEE WESCON 26 (August): 1–9, arkivert fra originalen on 2020-10-02, https://web.archive.org/web/20201002080351/http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf, besøkt 2022-05-22
- ^ a b McConnell, Steve. Rapid Development: Taming Wild Software Schedules. Microsoft Press. ISBN 1-55615-900-5.
- ^ «Waterfall Software Development Model». Besøkt 11. august 2014.
- ^ Arcisphere technologies (2012). «Tutorial: The Software Development Life Cycle (SDLC)» (PDF). Arkivert fra originalen (PDF) 17. februar 2019. Besøkt 13. november 2012.
- ^ Hughey, Douglas. «Comparing Traditional Systems Analysis and Design with Agile Methodologies». University of Missouri – St. Louis. Besøkt 11. august 2014.
- ^ Parnas, David L.; Clements, Paul C. (1986). «A rational design process: How and why to fake it» (PDF). IEEE Transactions on Software Engineering (2): 251–257. doi:10.1109/TSE.1986.6312940.
- ^ McConnell, Steve. Code Complete, 2nd edition. Microsoft Press. ISBN 1-55615-484-4.
- ^ Ensmenger, Nathan. The Computer Boys Take Over. s. 42. ISBN 978-0-262-05093-7.
- ^ A Waterfall Systems Development Methodology … Seriously? Arkivert 2. juli 2014 hos Wayback Machine. by David Dischave. 2012. Arkivert juli 2, 2014, hos Wayback Machine