Hva er fossefallsmetoden innen programvareutvikling?

Hva er fossefallsmetoden innen programvareutvikling?

Fossemetoden er en av de programvareutviklingsmetodene som brukes av mange utviklere til prosjektstyring. Den har en lineær tilnærming fra prosjektets start til slutt, noe som betyr at hver fase i utviklingsprosessen må fullføres før man kan gå videre til neste. Mange organisasjoner har oppnådd de ønskede resultatene ved å bruke denne strukturerte og grundige tilnærmingen, som har vært brukt i flere år.

Ved hjelp av fossefallsmetodikken samler man inn kunde- og interessentforespørsler i begynnelsen av programvareprosjektet, slik at man kan utvikle en sekvensiell prosjektplan. På denne måten blir alle aspekter av prosjektet dokumentert på forhånd, inkludert brukerhistorier, grensesnitt, funksjoner osv., slik at du kan generere nøyaktige tidsestimater og fastsette en forutsigbar lanseringsdato. I denne artikkelen kan du lese mer om fossefallsmetodikken, dens faser, fordeler og ulemper.

Fem standardfaser i fossefallsmetodikken

Som nevnt tidligere fungerer metoden kronologisk, med utgangspunkt i faste krav, datoer og resultater. Det krever derfor ikke at teamene samarbeider, med mindre det hele tiden er behov for spesifikke integrasjoner. De jobber vanligvis selvstendig, i motsetning til Agile-metoder, som krever at teammedlemmene gir hyppige statusrapporter og samarbeider.

Dette avsnittet tar for seg de fem hovedfasene eller trinnene i fossefallsmetoden, slik den opprinnelig ble foreslått av opphavsmannen Winston W. Royce. Dessuten starter hvert trinn i programvareutviklingen først etter at det forrige er avsluttet. Når du vurderer et programvareutviklingsprosjekt, er følgende trinn vanligvis inkludert i prosessen:

• Krav
• Design
• Gjennomføring
• Verifisering eller testing
• Implementering eller vedlikehold

1. Krav

Den første fasen handler om å samle inn og forstå kundens og interessentenes krav til prosjektet. Prosjektlederen utfører oppgaven, slik at teamet kan planlegge de påfølgende fasene deretter. Vanligvis nedtegnes alle kravene skriftlig i ett enkelt dokument for å sikre at de er nøyaktige.

Den beskriver kostnader, forutsetninger, risikoer, avhengigheter, suksesskriterier og sluttdatoer for hver fase av prosjektet. I teorien vil ikke kommunikasjonen med kundene ta seg opp igjen før produktet er ferdig etter at den første fasen er avsluttet.

2. Utforming

I designfasen løser programvareutviklerne tekniske problemer som følge av kravene til produktet. Løsningen kan være layouter, scenarier, datamodeller osv. Det første de gjør, er å lage et utkast til et design som skisserer prosjektets mål og parametere, samt den generelle veien for hver komponents trafikk og integrasjonspunkter. Dette kalles delfasen for logisk design.

Deretter transformeres designutkastet til et fysisk design ved hjelp av spesifikke maskinvare- og programvareteknologier i delfasen for fysisk design. I denne fasen konverteres alle ideene som ble diskutert i den logiske designfasen til faktiske spesifikasjoner ved hjelp av maskinvare- og programvareteknologier som teamet har valgt.

3. Gjennomføring

Nå kommer implementeringsfasen, fasen der alt settes ut i livet. Dette er vanligvis den korteste fossefallsfasen, fordi all research og design skal være ferdig på dette tidspunktet. I denne fasen bruker programmererne spesifikasjonene og kravene fra designfasen til å utvikle kode. Det kan imidlertid hende at teamet må gå tilbake til designfasen hvis det er behov for vesentlige justeringer i løpet av implementeringsfasen.

4. Verifisering eller testing

Verifisering eller testing av et produkt før det slippes til kundene er en viktig fossefallsfase som uansett ikke kan unngås. Det er nødvendig å garantere at produktet er feilfritt og at alle krav er oppfylt for å gi en positiv brukeropplevelse av programvaren. I denne fasen overlater utviklingsteamet prosjektet til QA-testteamet.

• Før prosjektet settes i drift, ser de etter eventuelle feil som må rettes, og de registrerer grundig alle problemer de oppdager under kvalitetssikringen.
• Hvis en annen utvikler støter på en lignende feil, kan de bruke den tidligere dokumentasjonen til å løse problemet.
• Etter feiltesting blir det ferdige produktet gjort tilgjengelig for kunden i verifiseringsfasen.
• Kunden vil inspisere det ferdige produktet for å sikre at det oppfyller kravene som ble spesifisert i starten av prosjektet.

5. Implementering og vedlikehold

Etter verifisering og testing distribueres produktet til kunden innen riktig frist. Men det hender at det oppdages en ny feil eller at en programvareoppdatering er nødvendig etter at produktet er tatt i bruk. I vedlikeholdsfasen kan teamet utføre nødvendige reparasjoner og lansere oppdaterte programvareversjoner for å sikre full kundetilfredshet. I programvareutvikling er det vanlig å jobbe kontinuerlig med denne fasen.

Hvilken nytte har du av det?

Med tanke på det du har lest i de foregående avsnittene, er fossefallsmetodikken en klar og enkel tilnærming til prosjektledelse som har blitt tatt i bruk av mange organisasjoner opp gjennom årene. Siden du vil være klar over prosjektkravene fra starten av, vil teamet vite hva som må gjøres og når det må gjøres, og vil kunne planlegge prosjektet godt for å fullføre det innen den gitte fristen. Nedenfor følger noen av metodens fordeler:

• Ved å identifisere designfeil tidlig i krav- og designprosessen kan utviklere unngå å skrive dårlig kode senere i implementeringsfasen.
• Når kravene er fastsatt, er det mulig å estimere prosjektets totalkostnad og tidsramme med stor nøyaktighet.
• En organisert tilnærming gjør det enklere å måle fremdriften i henhold til veldefinerte milepæler.
• Når nye utviklere slutter seg til et pågående prosjekt, vil de ikke ha problemer med å sette seg inn i det, fordi kravdokumentet bør inneholde all den informasjonen de trenger.
• Kunder som kommer med nye krav til prosjektet, vil ikke føre til forsinkelser i produksjonen.

Hva er ulempene?

Fordelene på ett område kan føre til ulemper på et annet, akkurat som i enhver annen utviklingsprosess. På grunn av vektleggingen av prosjektplanlegging på forhånd og fokus på spesifikk, definert fremdrift, er fossefallsmetodikken mindre tilpasningsdyktig senere i prosessen. Å gjøre endringer senere i prosessen kan være smertefullt, tidkrevende og kostbart. Det er flere grunner til at metoden kanskje ikke er effektiv.

• Sammenlignet med en iterativ tilnærming som Agile-metoden, kan det ta lengre tid å fullføre et prosjekt ved bruk av denne kronologiske metoden.
• Fordi kundene ikke er i stand til å uttrykke behovene sine tydelig på forhånd, kan det hende at de ber om endringer og nye funksjoner senere i prosessen, når det er vanskeligere å oppfylle dem.
• Design- og implementeringsfasene er ikke åpne for kundens deltakelse.
• En prosess som kalles «deadline creep» oppstår når ett trinn utsettes, og alle de andre også.
• Tilnærmingens største ulempe er at når en fase er avsluttet, kan det være vanskelig å gå tilbake til den.

Du har lært mye om fossefallsmetodikken i denne artikkelen. Det er ikke sikkert at denne tilnærmingen passer for alle programvareutviklingsprosjekter. Metoden foretrekkes vanligvis av prosjektledere som styrer prosjekter med presise krav som gir et klart bilde av hvordan ting vil utvikle seg fra begynnelsen av, og som sannsynligvis ikke vil endre omfang etter at prosjektet har startet. For noen prosjekter kan tilnærmingen virke unødvendig restriktiv, men den kan være et utmerket verktøy for å forhindre at et klart definert og forutsigbart prosjekt overskrider budsjett- og tidsrammene. Så ta en informert beslutning basert på informasjonen i artikkelen.

Interessante lenker:

Her finner du mer informasjon om fossefallsmodellen i programvareutvikling.

Hva er fordelene og ulempene med fossefallsmetodikken?

Bilder: Canva

Forfatteren: Sascha Thattil jobber på Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til IT-selskaper, byråer og IT-avdelinger.