Hvad er vandfaldsmetoden inden for softwareudvikling?

Hvad er vandfaldsmetoden inden for softwareudvikling?

Vandfaldsmetoden er en af de softwareudviklingsmetoder, der bruges af mange udviklere til projektstyring. Det er en lineær tilgang fra projektets start til slut, hvilket betyder, at hver fase i udviklingsprocessen skal være afsluttet, før man kan gå videre til den næste. Mange organisationer har opnået de ønskede resultater ved at bruge denne tilgang, som er struktureret og grundig, og som har været brugt i flere år.

Vandfaldsmetoden begynder med at indsamle kunde- og interessentanmodninger i begyndelsen af softwareprojektet, så der kan udvikles en sekventiel projektplan. Så alle aspekter af projektet vil være dokumenteret på forhånd, herunder brugerhistorier, grænseflader, funktioner osv., hvilket giver dig mulighed for at generere nøjagtige tidsestimater og etablere en forudsigelig udgivelsesdato. I denne artikel kan du læse mere om vandfaldsmetoden, dens faser, fordele og ulemper.

Fem standardfaser i vandfaldsmetoden

Som tidligere nævnt arbejder metoden kronologisk med udgangspunkt i faste krav, datoer og resultater. Derfor kræver det ikke, at teams samarbejder, medmindre der konstant er behov for specifikke integrationer. De arbejder som regel selvstændigt i modsætning til agile metoder, som kræver, at teammedlemmerne giver hyppige statusrapporter og samarbejder.

Dette afsnit dækker de fem hovedfaser eller trin i vandfaldsmetoden, som oprindeligt blev foreslået af dens skaber, Winston W. Royce. Desuden starter hvert trin i softwareudviklingen først, når det forrige er afsluttet. Når man overvejer et softwareudviklingsprojekt, indgår følgende trin typisk i processen:

• Krav
• Design
• Implementering
• Verifikation eller test
• Implementering eller vedligeholdelse

1. Krav til

Den første fase handler om at indsamle og fuldt ud forstå kundens og interessenternes projektkrav. Projektlederen udfører opgaven, hvilket gør det muligt for teamet at planlægge de efterfølgende faser i overensstemmelse hermed. Typisk nedfældes alle krav skriftligt i et enkelt dokument for at sikre nøjagtigheden.

Den vil skitsere udgifter, antagelser, risici, afhængigheder, succeskriterier og afslutningsdatoer for hver fase af projektet. Teoretisk set vil kommunikationen med kunderne ikke blive genoptaget, før produktet er færdigt, efter at den første fase er afsluttet.

2. Design

I designfasen løser softwareudviklerne de tekniske problemer, som kravene til produktet giver anledning til. Løsningen kan være layouts, scenarier, datamodeller osv. Det første, de gør, er at udarbejde et design, der skitserer projektets mål og parametre samt den generelle vej for hver komponents trafik og integrationspunkter. Det kaldes den logiske designfase.

Derefter omdannes designudkastet til et fysisk design ved hjælp af specifikke hardware- og softwareteknologier i den fysiske designunderfase. I denne fase bliver alle de ideer, der blev diskuteret i den logiske designfase, konverteret til faktiske specifikationer via teamets valgte hardware- og softwareteknologier.

3. Gennemførelse

Nu kommer implementeringsfasen, den fase, hvor alt sættes i værk. Det er normalt den korteste vandfaldsfase, fordi al research og design skal være afsluttet på dette tidspunkt. I denne fase vil programmørerne bruge specifikationerne og kravene fra designfasen til at udvikle kode. Teamet kan dog blive nødt til at gå tilbage til designfasen, hvis der er behov for væsentlige justeringer i løbet af implementeringsfasen.

4. Verifikation eller test

At verificere eller teste et produkt, før det frigives til kunderne, er en vigtig vandfaldsfase, som ikke kan undgås, uanset hvad. Det er nødvendigt at garantere, at produktet er fejlfrit, og at alle krav er opfyldt for at give en positiv brugeroplevelse af softwaren. Så i denne fase vil udviklingsteamet overdrage projektet til QA-testteamet.

• Før projektet implementeres, vil de lede efter eventuelle fejl, der skal rettes, og de vil grundigt registrere ethvert problem, de opdager under kvalitetssikringen.
• Hvis en anden udvikler støder på en lignende fejl, kan de bruge den tidligere dokumentation til at hjælpe med at løse problemet.
• Efter fejltest stilles det færdige produkt til rådighed for kunden i verifikationsfasen.
• Kunden inspicerer det færdige produkt for at sikre, at det lever op til de krav, der blev specificeret ved projektets start.

5. Implementering og vedligeholdelse

Efter verifikation og test bliver produktet leveret til kunden inden for den korrekte tidsfrist. Men der er tilfælde, hvor der opdages en ny fejl, eller hvor der kræves en softwareopdatering, når produktet er implementeret. Så i vedligeholdelsesfasen kan teamet foretage de nødvendige rettelser og frigive opdaterede softwareversioner for at sikre fuld kundetilfredshed. Det er almindeligt i softwareudvikling at arbejde kontinuerligt med denne fase.

Hvordan gavner det dig?

Ud fra det, du har læst i de foregående afsnit, er vandfaldsmetoden en klar og ligetil tilgang til projektledelse, som er blevet anvendt af mange organisationer i årenes løb. Da du vil være klar over projektets krav fra starten, vil teamet vide, hvad og hvornår det skal gøres, og vil være i stand til at planlægge projektet godt for at afslutte det inden for den givne frist. Følgende er nogle af fordelene ved metoden:

• Ved at identificere designfejl tidligt i krav- og designprocessen kan udviklere hjælpe med at forhindre, at de skriver dårlig kode senere i implementeringsfasen.
• Når kravene er fastlagt, er det muligt at estimere projektets samlede omkostninger og tidslinje med nøjagtighed.
• At måle fremskridt i overensstemmelse med veldefinerede milepæle gøres enklere med en organiseret tilgang.
• Når nye udviklere slutter sig til et igangværende projekt, har de ingen problemer med at komme op i fart, fordi kravdokumentet bør indeholde alle de oplysninger, de har brug for.
• Kunder, der kommer med nye krav til projektet, vil ikke forsinke produktionen.

Hvad er ulemperne?

Fordelene på ét område kan føre til ulemper på et andet, ligesom i enhver anden udviklingsproces. På grund af dens vægt på forudgående projektplanlægning og dedikation til specifikke, definerede fremskridt, er vandfaldsmetoden mindre tilpasningsdygtig senere i processen. At foretage ændringer senere i processen kan være smertefuldt, tidskrævende og dyrt. Der er flere grunde til, at metoden måske ikke er effektiv.

• Sammenlignet med en iterativ tilgang som den agile metode, kan det tage længere tid at gennemføre et projekt, når man bruger denne kronologiske metode.
• På grund af deres manglende evne til at udtrykke deres behov klart på forhånd, kan kunderne bede om ændringer og nye funktioner senere i processen, hvor det vil være mere udfordrende at opfylde dem.
• Design- og implementeringsfaserne er ikke åbne for kundens deltagelse.
• En proces kendt som “deadline creep” opstår, når et trin udskydes, og det samme gør alle de andre.
• Tilgangens største ulempe er, at når en fase er afsluttet, kan det være svært at gå tilbage til den.

Så du har lært en masse om vandfaldsmetodikken i denne artikel. Denne tilgang appellerer måske ikke til alle softwareudviklingsprojekter. Metoden foretrækkes typisk af projektledere, der styrer projekter med præcise krav, som giver et klart billede af, hvordan tingene vil udfolde sig fra begyndelsen, og som sandsynligvis ikke vil ændre omfang, efter at projektet er begyndt. For nogle projekter kan tilgangen virke urimeligt restriktiv, men den kan være et fremragende værktøj til at forhindre et klart defineret, forudsigeligt projekt i at overskride budget- og tidsplanbegrænsninger. Så tag en informeret beslutning baseret på oplysningerne i artiklen.

Interessante links:

Se mere information om vandfaldsmodellen inden for softwareudvikling

Hvad er fordelene og ulemperne ved vandfaldsmetodikken?

Billeder: Canva

Forfatteren: Sascha Thattil arbejder på Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programmører til IT-virksomheder, agenturer og IT-afdelinger.