i ett praktiskt mjukvaruutvecklingsprojekt är den klassiska vattenfallsmodellen svår att använda. Så, iterativ vattenfallsmodell kan betraktas som införlivande av nödvändiga förändringar i den klassiska vattenfallsmodellen för att göra den användbar i praktiska mjukvaruutvecklingsprojekt. Det är nästan samma som den klassiska vattenfallsmodellen förutom att vissa förändringar görs för att öka effektiviteten i mjukvaruutvecklingen.
den iterativa vattenfallsmodellen ger återkopplingsvägar från varje fas till dess föregående faser, vilket är den största skillnaden från den klassiska vattenfallsmodellen.
Återkopplingsvägar som introduceras av den iterativa vattenfallsmodellen visas i figuren nedan.
när fel upptäcks i någon senare fas tillåter dessa återkopplingsvägar att korrigera fel som begåtts av programmerare under någon fas. Feedbackvägarna gör att fasen kan omarbetas där fel begås och dessa förändringar återspeglas i de senare faserna. Men det finns ingen återkopplingsväg till scen-genomförbarhetsstudien, för när ett projekt har tagits, ger inte upp projektet lätt.
det är bra att upptäcka fel i samma fas som de begås. Det minskar den ansträngning och tid som krävs för att korrigera felen.
Fasinneslutning av fel: principen att upptäcka fel så nära deras engagemangspunkter som möjligt kallas Fasinneslutning av fel.
fördelar med iterativ vattenfallsmodell
- Återkopplingsväg: I den klassiska vattenfallsmodellen finns inga återkopplingsvägar, så det finns ingen mekanism för felkorrigering. Men i iterativ vattenfall modell återkoppling väg från en fas till dess föregående fas gör det möjligt att korrigera de fel som begås och dessa förändringar återspeglas i de senare faserna.
- enkel: iterativ vattenfallsmodell är mycket enkel att förstå och använda. Det är därför det är en av de mest använda mjukvaruutvecklingsmodellerna.
nackdelar med iterativ vattenfallsmodell
- svårt att införliva ändringsförfrågningar: Den stora nackdelen med den iterativa vattenfallsmodellen är att alla krav måste anges tydligt innan utvecklingsfasen påbörjas. Kunden kan ändra krav efter en tid men den iterativa vattenfallsmodellen lämnar inget utrymme för att införliva ändringsförfrågningar som görs efter att utvecklingsfasen börjar.
- inkrementell leverans stöds inte: i den iterativa vattenfallsmodellen är hela programvaran helt utvecklad och testad före leverans till kunden. Det finns inget utrymme för någon mellanliggande leverans. Så kunderna måste vänta länge på att få programvaran.
- överlappning av faser som inte stöds: iterativ vattenfallsmodell antar att en fas kan starta efter avslutad föregående fas, men i verkliga projekt kan faser överlappa varandra för att minska ansträngningen och tiden som behövs för att slutföra projektet.
- riskhantering stöds inte: projekt kan drabbas av olika typer av risker. Men iterativ vattenfallsmodell har ingen mekanism för riskhantering.
- begränsade kundinteraktioner: Kundinteraktion sker i början av projektet vid tidpunkten för kravinsamling och vid projektets slutförande vid tidpunkten för leverans av programvara. Dessa färre interaktioner med kunderna kan leda till många problem eftersom den slutligen utvecklade programvaran kan skilja sig från kundernas faktiska krav.
