Vad är vattenfallsmetoden inom mjukvaruutveckling?

Vad är vattenfallsmetoden inom mjukvaruutveckling?

Vattenfallsmetoden är en av de metoder för programvaruutveckling som används av många utvecklare för projektledning. Det är ett linjärt tillvägagångssätt från projektstart till slut, vilket innebär att varje fas i utvecklingsprocessen måste slutföras innan man kan gå vidare till nästa. Många organisationer har uppnått önskade resultat genom att använda denna metod, som är strukturerad och grundlig och har använts i flera år.

Vattenfallsmetoden börjar med att samla in önskemål från kunder och intressenter i början av programvaruprojektet, så att en sekventiell projektplan kan tas fram. Alla aspekter av projektet kommer att dokumenteras i förväg, inklusive användarberättelser, gränssnitt, funktioner etc., så att ni kan generera exakta tidsuppskattningar och fastställa ett förutsägbart lanseringsdatum. I den här artikeln kan du läsa mer om vattenfallsmetoden, dess faser, fördelar och nackdelar.

Fem standardfaser i vattenfallsmetoden

Som tidigare nämnts fungerar metoden kronologiskt och bygger på fasta krav, datum och resultat. Därför krävs det inte att teamen samarbetar om inte specifika integrationer ständigt behövs. De arbetar vanligtvis självständigt, till skillnad från Agile-metoder, som kräver att teammedlemmarna ofta lämnar statusrapporter och samarbetar.

I detta avsnitt behandlas vattenfallsmetodens fem huvudfaser eller steg, så som de ursprungligen föreslogs av dess skapare, Winston W. Royce. Dessutom startar varje steg i programutvecklingen först när det föregående steget är avslutat. När man överväger ett programvaruutvecklingsprojekt ingår vanligtvis följande steg i processen:

• Krav
• Design
• Genomförande
• Verifiering eller testning
• Driftsättning eller underhåll

1. Krav

Den första fasen handlar om att samla in och fullt ut förstå kundens och intressenternas projektkrav. Projektledaren kommer att utföra uppgiften, vilket gör det möjligt för teamet att planera de efterföljande faserna i enlighet med detta. Vanligtvis registreras alla krav skriftligen som ett enda dokument för att säkerställa noggrannhet.

Den ska beskriva kostnader, antaganden, risker, beroenden, framgångsmått och slutdatum för varje fas i projektet. Teoretiskt sett kommer kommunikationen med kunderna inte att återupptas förrän produkten är färdigställd efter att den första fasen har avslutats.

2. Utformning

Under designfasen löser programutvecklare tekniska problem som uppstår på grund av kraven på produkten. Lösningen kan vara layouter, scenarier, datamodeller etc. Det första de gör är att ta fram en design som beskriver projektets mål och parametrar, samt den allmänna vägen för varje komponents trafik och integrationspunkter. Det kallas delfasen för logisk design.

Därefter omvandlas designutkastet till en fysisk design med hjälp av specifik hårdvaru- och mjukvaruteknik i delfasen för fysisk design. I denna fas omvandlas alla idéer som diskuterats i delfasen för logisk design till faktiska specifikationer med hjälp av teamets val av hård- och mjukvaruteknik.

3. Genomförande

Nu kommer implementeringsfasen, det skede då allt sätts i verket. Det är vanligtvis den kortaste vattenfallsfasen eftersom all forskning och design bör vara klar vid denna tidpunkt. I denna fas använder programmerarna specifikationerna och kraven från designfasen för att utveckla kod. Teamet kan dock behöva gå tillbaka till designfasen om några betydande justeringar behövs under implementeringsfasen.

4. Verifiering eller testning

Att verifiera eller testa en produkt innan den släpps till kunderna är en viktig vattenfallsfas som inte kan undvikas, oavsett vad som händer. Det är nödvändigt att garantera att produkten är felfri och att alla krav har uppfyllts för att ge en positiv användarupplevelse av programvaran. I det här skedet kommer utvecklingsteamet att lämna över projektet till QA-testteamet.

• Innan projektet driftsätts letar de efter eventuella buggar eller fel som behöver åtgärdas, och de registrerar noggrant alla problem som de upptäcker under kvalitetssäkringen.
• Om en annan utvecklare stöter på ett liknande fel kan de använda den tidigare dokumentationen för att hjälpa till att lösa problemet.
• Efter felsökning görs den färdiga produkten tillgänglig för kunden under verifieringsfasen.
• Kunden kommer att inspektera den färdiga produkten för att se till att den uppfyller de krav som specificerades i början av projektet.

5. Driftsättning och underhåll

Efter verifiering och testning distribueras produkten till kunden inom rätt tidsfrist. Men det finns tillfällen då en ny bugg upptäcks eller en programuppdatering krävs när produkten har distribuerats. I underhållsfasen kan teamet göra nödvändiga korrigeringar och släppa uppdaterade programversioner för att säkerställa fullständig kundtillfredsställelse. Det är vanligt inom mjukvaruutveckling att man kontinuerligt arbetar med denna fas.

Hur gynnar det dig?

Med tanke på vad du har läst i de tidigare avsnitten är vattenfallsmetoden ett tydligt och enkelt tillvägagångssätt för projektledning som har antagits av många organisationer under årens lopp. Eftersom du kommer att vara medveten om projektkraven från början kommer teamet att veta vad och när det måste göras och kommer att kunna planera projektet väl för att slutföra det inom den angivna tidsfristen. Nedan följer några av fördelarna med metoden:

• Genom att identifiera designbrister tidigt i krav- och designprocessen kan utvecklare undvika att skriva dålig kod senare i implementeringsfasen.
• När kraven har fastställts är det möjligt att göra en exakt uppskattning av projektets totala kostnad och tidplan.
• Att mäta framsteg i enlighet med väldefinierade milstolpar blir enklare med ett organiserat tillvägagångssätt.
• När nya utvecklare ansluter sig till ett pågående projekt kommer de inte att ha några problem med att komma igång eftersom kravdokumentet bör innehålla all information de behöver.
• Kunder som kommer med nya krav för projektet kommer inte att orsaka en försening i produktionen.

Vilka är nackdelarna?

Fördelarna på ett område kan leda till nackdelar på ett annat, precis som i alla utvecklingsprocesser. Eftersom vattenfallsmetoden lägger stor vikt vid projektplanering i förväg och är inriktad på specifika, definierade framsteg, är den mindre anpassningsbar senare i processen. Att göra ändringar senare i processen kan vara smärtsamt, tidskrävande och dyrt. Det finns ytterligare skäl till att metoden kanske inte är effektiv.

• Jämfört med en iterativ metod som Agile-metoden kan det ta längre tid att slutföra ett projekt om man använder den kronologiska metoden.
• Eftersom kunderna inte kan uttrycka sina behov tydligt i förväg kan de begära ändringar och nya funktioner senare i processen, när det blir svårare att uppfylla dem.
• Stadierna för utformning och genomförande är inte öppna för kundens deltagande.
• En process som kallas ”deadline creep” uppstår när ett steg skjuts upp och alla de andra likaså.
• Den största nackdelen med metoden är att när en fas är avslutad kan det vara svårt att gå tillbaka till den.

Du har alltså lärt dig en hel del om vattenfallsmetodiken i den här artikeln. Detta tillvägagångssätt kanske inte passar alla programvaruutvecklingsprojekt. Metoden föredras vanligtvis av projektledare som hanterar projekt med exakta krav som ger en tydlig bild av hur saker och ting kommer att utvecklas från början och som sannolikt inte kommer att ändra omfattning efter att projektet har inletts. För vissa projekt kan metoden verka onödigt restriktiv, men den kan vara ett utmärkt verktyg för att förhindra att ett tydligt definierat och förutsägbart projekt överskrider budget- och tidsramarna. Så fatta ett välgrundat beslut baserat på informationen i artikeln.

Intressanta länkar:

Ta reda på mer information om vattenfallsmodellen inom mjukvaruutveckling

Vilka är fördelarna och nackdelarna med vattenfallsmetoden?

Bilder: Canva

Författaren: Sascha Thattil arbetar på Software-Developer-India.com som är en del av YUHIRO Group. YUHIRO är ett tysk-indiskt företag som tillhandahåller programmerare till IT-företag, byråer och IT-avdelningar.