Vattenfall - Vattenfallsmodell

Cascade modell enhet

Vattenfallsmodellen, även känd som Waterfall, är en av de mest välkända metoderna för mjukvaruutveckling. Författaren till modellen är Winston Royce. 1970 beskrev han kärnan i sin innovation i en artikel som beskriver dess fördelar och nackdelar. På samma ställe förklarade han hur denna modell kan förfinas till en iterativ modell. Till en början, i vattenfallsmodellen, går utvecklingsstadierna i följande ordning:

• Definition och samordning av krav;
• Projektgodkännande;
• Kodning;
• Skapande av en fungerande version av mjukvaruprodukten;
• Testning och felsökning;
• Mjukvaruinstallation;
• Stöd.

Enligt vattenfallsmodellen sker utförandet av åtgärder från utvecklaren sekventiellt - punkt för punkt. Till att börja med pågår arbetet med att fastställa och komma överens om mjukvarukrav i form av en lista som ska fyllas i.

Därefter sker en övergång till skapandet och godkännandet av projektet, vilket resulterar i att dokumentation skrivs som beskriver hur man implementerar de tidigare överenskomna mjukvarukraven.

Om designen är klar tar utvecklarna på sig implementeringen. Därefter kommer sammanslagning av koden - integrationen av enskilda delar av projektet, som arbetats med av olika teammedlemmar.

Nästa steg är att testa och felsöka produkten. Tidigare hittade fel åtgärdas här.

Slutligen är programmet installerat och stöds. Det innebär att vid behov göra ändringar i funktionaliteten och eliminera de fel som hittats.

Kaskadmodellen förutsätter att du kan gå till nästa utvecklingsstadium strikt sekventiellt - först efter att föregående uppgift är klar. Möjligheten för återställning eller inkonsekvens i faserna tillhandahålls inte.

Fördelar och nackdelar

Då och då kritiseras vattenfallsmodellen på grund av dess bristande flexibilitet. Många gillar det inte eftersom målet med projektledning råder i det, samtidigt som att hålla deadlines, kostnad och kvalitet på utvecklingen är mycket viktigare.

Men när det gäller stora projekt är ledningen ofta viktigare i dem, eftersom detta minskar riskerna med projektet och förbättrar transparensen i arbetet.

Trots bristerna specificerar PMBOK 3:e versionen formellt endast metodiken för "kaskadmodellen". Andra alternativ, inklusive iterativ projektledning, erbjuds inte.

Fördelar med vattenfallsmodellen:

• Teamutveckling är lättare att kontrollera. Kunden är bekant med vad programmerarna arbetar med just nu, han kan ändra deadlines och budget för projektet.
• Kostnaden för utveckling godkänns i första skedet. Efter att ha kommit överens om alla steg i implementeringen skrivs mjukvaruprodukten kontinuerligt.
• Erfarna testare behövs inte. För testfasen kan du använda programdokumentationen.

Nackdelar med vattenfallsmodellen:

• Eftersom testningen startar när utvecklingen är färdig, om en bugg upptäcks, kommer det att kosta mer att fixa den än i det inledande skedet. När allt kommer omkring kommer testare att hitta ett fel först när utvecklaren redan har skrivit klart koden, och copywriters - dokumentationen.
• Kunden bekantar sig med den färdiga produkten efter att utvecklingen är klar. Följaktligen kan han utvärdera produkten först när den är nästan helt klar. Om han inte gillar resultatet kommer kostnaden för projektbudgeten att öka markant på grund av behovet av korrigering.
• Ju mer teknisk dokumentation, desto längre tid tar det att slutföra arbetet. Sådan dokumentation kräver fler ändringar och godkännanden.

"Waterfall" används ofta i projekt inom medicin- och flygindustrin, där det redan finns en bred bas av dokument, på grundval av vilka det är möjligt att utarbeta krav på ny programvara.

När du använder vattenfallsmodellen är det viktigaste att skriva detaljerade krav. Under testning ska det inte visa sig att det finns en bugg någonstans som har en skadlig effekt på hela projektet.