Inkrementell modell i SDLC: bruk, fordel & Ulempe

Innholdsfortegnelse:

Anonim

Hva er inkrementell modell?

Inkrementell modell er en prosess med programvareutvikling der kravene er delt inn i flere frittstående moduler i programvareutviklingssyklusen. Inkrementell utvikling gjøres i trinn fra analysedesign, implementering, testing / verifisering, vedlikehold.

Hver iterasjon går gjennom kravene, design, koding og testing . Og hver påfølgende utgivelse av systemet legger til funksjon til den forrige utgivelsen til all designet funksjonalitet er implementert.

Systemet settes i produksjon når første trinn leveres. Den første økningen er ofte et kjerneprodukt der de grunnleggende kravene blir adressert, og tilleggsfunksjoner blir lagt til i de neste trinnene. Når kjerneproduktet er analysert av klienten, er det planutvikling for neste trinn.

Kjennetegn ved en inkrementell modul inkluderer

  • Systemutvikling er delt inn i mange miniutviklingsprosjekter
  • Delvise systemer bygges suksessivt for å produsere et endelig totalsystem
  • Kravet til høyeste prioritet takles først
  • Når kravet er utviklet, blir kravet til den økningen frosset
Inkrementelle faser Aktiviteter utført i trinnvise faser
Kravsanalyse
  • Krav og spesifikasjon av programvaren samles inn
Design
  • Noen high-end funksjoner er designet i løpet av dette stadiet
Kode
  • Koding av programvare gjøres i løpet av dette stadiet
Test
  • Når systemet er distribuert, går det gjennom testfasen

Når skal du bruke trinnvise modeller?

  • Kravene til systemet er tydelig forstått
  • Når det oppstår etterspørsel etter en tidlig utgivelse av et produkt
  • Når programvareteknikk ikke er veldig dyktige eller opplært
  • Når høyrisikofunksjoner og mål er involvert
  • Slik metode er mer i bruk for webapplikasjoner og produktbaserte selskaper

Fordeler og ulemper ved inkrementell modell

Fordeler Ulemper
  • Programvaren genereres raskt i løpet av programvarens livssyklus
  • Det krever en god planleggingsdesign
  • Det er fleksibelt og billigere å endre krav og omfang
  • Problemer kan forårsake på grunn av systemarkitektur som sådan, ikke alle krav samlet inn for hele programvarens livssyklus
  • Gjennom utviklingsstadiene kan endringer gjøres
  • Hver iterasjonsfase er stiv og overlapper ikke hverandre
  • Denne modellen er billigere sammenlignet med andre
  • Å rette på et problem i en enhet krever korreksjon i alle enhetene og bruker mye tid
  • En kunde kan svare på hver bygning
  • Feil er lett å identifisere