Foss - Fossmodell

Cascade modell enhet

Fossmodellen, også kjent som Waterfall, er en av de mest kjente tilnærmingene til programvareutvikling. Forfatteren av modellen er Winston Royce. I 1970 beskrev han essensen av innovasjonen sin i en artikkel som beskriver fordelene og ulempene. Samme sted forklarte han hvordan denne modellen kan foredles til en iterativ modell. Til å begynne med, i fossefallsmodellen, går utviklingsstadiene i følgende rekkefølge:

• Definisjon og koordinering av krav;
• Prosjektgodkjenning;
• Koding;
• Oppretting av en fungerende versjon av programvareproduktet;
• Testing og feilsøking;
• Installasjon av programvare;
• Brukerstøtte.

I henhold til fossefallsmodellen skjer utførelse av handlinger fra utvikleren sekvensielt - punkt for punkt. Til å begynne med jobbes det med å fastsette og bli enige om programvarekrav i form av en liste som skal fylles ut.

Etter det er det en overgang til opprettelse og godkjenning av prosjektet, som et resultat av at det skrives dokumentasjon som beskriver hvordan man implementerer de tidligere avtalte programvarekravene.

Hvis designet er fullført, tar utviklerne på seg implementeringen. Deretter kommer sammenslåingen av koden – integrering av individuelle deler av prosjektet, som ble jobbet med av ulike teammedlemmer.

Det neste trinnet er å teste og feilsøke produktet. Tidligere funnet feil rettes her.

Til slutt er programmet installert og støttet. Det innebærer om nødvendig å gjøre endringer i funksjonaliteten og eliminere feilene som er funnet.

Kaskademodellen forutsetter at du kan flytte til neste utviklingstrinn strengt sekvensielt - bare etter fullføring av forrige oppgave. Muligheten for tilbakerulling eller inkonsekvens i fasene er ikke gitt.

Fordeler og ulemper

Fra tid til annen blir fossefallsmodellen kritisert på grunn av dens manglende fleksibilitet. Mange liker det ikke fordi målet om prosjektledelse råder i det, mens det å overholde tidsfrister, kostnad og kvalitet på utviklingen er mye viktigere.

Men når det gjelder store prosjekter, så er ledelse ofte viktigere i dem, siden dette reduserer risikoen ved prosjektet og forbedrer åpenheten i arbeidet.

Til tross for manglene, spesifiserer PMBOK tredje versjon formelt bare metoden for "kaskademodell". Andre alternativer, inkludert iterativ prosjektledelse, tilbys ikke.

Fordeler med fossefallsmodellen:

• Teamutvikling er lettere å kontrollere. Kunden er kjent med hva programmererne jobber med for tiden, han kan endre tidsfrister og budsjett for prosjektet.
• Utbyggingskostnaden godkjennes i første trinn. Etter å ha blitt enige om alle trinn i implementeringen, skrives programvareproduktet fortløpende.
• Erfarne testere er ikke nødvendig. For testfasen kan du bruke programdokumentasjonen.

Ulemper med fossefallsmodellen:

• Siden testing starter på fullføringsstadiet av utviklingen, vil det koste mer å fikse den hvis en feil blir oppdaget enn på det første stadiet. Tross alt vil testere bare finne en feil når utvikleren allerede er ferdig med å skrive koden, og tekstforfattere - dokumentasjonen.
• Kunden gjør seg kjent med det ferdige produktet etter at utviklingen er fullført. Følgelig kan han vurdere produktet bare når det er nesten helt klart. Dersom han ikke liker resultatet, vil kostnaden for prosjektbudsjettet øke markant på grunn av behov for korrigering.
• Jo mer teknisk dokumentasjon, jo lengre tid tar det å fullføre arbeidet. Slik dokumentasjon krever flere endringer og godkjenninger.

"Waterfall" brukes ofte i prosjekter innen medisinsk og romfartsindustri, hvor det allerede er en bred base av dokumenter, på grunnlag av hvilke det er mulig å utarbeide krav til ny programvare.

Når du bruker fossefallsmodellen, er det viktigste å skrive detaljerte krav. Under testing skal det ikke vise seg at det er en feil et sted som har en skadelig effekt på hele prosjektet.