Inkrementell modell i SDLC: Användning, fördel och nackdel
⚡ Smart sammanfattning
Inkrementell modell i SDLC bygger programvara i successiva moduler, där varje steg lägger till funktion tills hela systemet är komplett. Denna resurs förklarar dess egenskaper, faser, användning samt fördelar och nackdelar.

Vad är inkrementell modell?
Stegvis utveckling är en process för mjukvaruutveckling där krav bryts ner i flera fristående moduler i mjukvaruutvecklingscykeln. Stegvis utveckling sker i steg, från analys, design, implementering och testning eller verifiering till underhåll.
Varje iteration passerar genom krav-, design-, kodnings- och testfaserVarje efterföljande version av systemet lägger till funktioner till den föregående versionen, tills all designad funktionalitet har implementerats.
Systemet sätts i produktion när det första inkrementet levereras. Det första inkrementet är ofta en kärnprodukt där de grundläggande kraven adresseras, och kompletterande funktioner läggs till i nästkommande inkrement. När kärnprodukten har analyserats av kunden finns det en plan för utvecklingen av nästa inkrement.
Egenskaper hos en inkrementell modell
- Systemutveckling är uppdelad i många miniutvecklingsprojekt.
- Delsystem byggs successivt för att producera ett slutligt, totalt system.
- Det högst prioriterade kravet hanteras först.
- När ett krav har utvecklats fryses kravet för den ökningen.
| Inkrementella faser | Aktiviteter som utförs i stegvisa faser |
|---|---|
| Kravsanalys |
|
| Design |
|
| Code |
|
| Testa |
|
När ska man använda inkrementella modeller?
- Systemets krav är tydligt förstådda.
- När det finns en efterfrågan på en tidig lansering av en produkt.
- När mjukvaruutveckling Teamet är inte särskilt välutbildat eller skickligt.
- När högriskfunktioner och mål är inblandade.
- En sådan metod används mer för webbapplikationer och produktbaserade företag.
Fördelar och nackdelar med inkrementell modell
| Fördelar | Nackdelar |
|---|---|
| Programvaran genereras snabbt under programvarans livscykel. | Det kräver god planering och design. |
| Det är flexibelt och billigare att ändra krav och omfattning. | Problem kan uppstå på grund av systemarkitekturen, eftersom inte alla krav samlas in i förväg för hela programvarans livscykel. |
| Ändringar kan göras under hela utvecklingsfasen. | Varje iterationsfas är stel och överlappar inte de andra. |
| Denna modell är billigare jämfört med andra. | Att åtgärda ett problem i en enhet kräver korrigering i alla enheter och tar mycket tid. |
| En kund kan svara på varje build. | |
| Fel är lätta att identifiera. |


