Inkrementaalimalli SDLC: ssä: käyttö, etu & Haitta

Sisällysluettelo:

Anonim

Mikä on inkrementaalimalli?

Inkrementaalimalli on ohjelmistokehitysprosessi, jossa vaatimukset jaetaan useisiin erillisiin ohjelmistokehitysjaksojen moduuleihin. Inkrementaalinen kehitys tapahtuu vaiheittain analyysin suunnittelusta, toteutuksesta, testauksesta / todentamisesta, ylläpidosta.

Jokainen iterointi läpäisee vaatimukset, suunnittelu-, koodaus- ja testausvaiheet . Ja jokainen seuraava järjestelmän julkaisu lisää toiminnon edelliseen julkaisuun, kunnes kaikki suunnitellut toiminnot on toteutettu.

Järjestelmä otetaan käyttöön, kun ensimmäinen lisäys toimitetaan. Ensimmäinen lisäys on usein ydintuote, jossa huomioidaan perusvaatimukset, ja lisäominaisuudet lisätään seuraaviin lisäyksiin. Kun asiakas on analysoinut ydintuotteen, suunnitelmia kehitetään seuraavaa lisäystä varten.

Inkrementaalimoduulin ominaisuudet sisältävät

  • Järjestelmän kehitys on jaettu moniin minikehitysprojekteihin
  • Osittaiset järjestelmät rakennetaan peräkkäin lopullisen kokonaisjärjestelmän tuottamiseksi
  • Korkein prioriteettivaatimus ratkaistaan ​​ensin
  • Kun vaatimus on kehitetty, lisäystä koskevat vaatimukset jäädytetään
Lisävaiheet Toiminta suoritetaan vaiheittain
Vaatimusanalyysi
  • Vaatimukset ja ohjelmiston määrittely kerätään
Design
  • Jotkut huippuluokan toiminnot on suunniteltu tässä vaiheessa
Koodi
  • Ohjelmisto koodataan tässä vaiheessa
Testata
  • Kun järjestelmä on otettu käyttöön, se käy läpi testausvaiheen

Milloin inkrementaalimalleja käytetään?

  • Järjestelmän vaatimukset ymmärretään selvästi
  • Kun kysyntä tuotteen ennenaikaiselle vapauttamiselle syntyy
  • Kun ohjelmistosuunnittelutiimi ei ole kovin ammattitaitoinen tai koulutettu
  • Kun kyseessä ovat korkean riskin ominaisuudet ja tavoitteet
  • Tällaista menetelmää käytetään enemmän verkkosovelluksissa ja tuotepohjaisissa yrityksissä

Inkrementaalimallin edut ja haitat

Edut Haitat
  • Ohjelmisto luodaan nopeasti ohjelmiston elinkaaren aikana
  • Se vaatii hyvää suunnittelua
  • Vaatimusten ja laajuuden muuttaminen on joustavaa ja halvempaa
  • Ongelmia saattaa aiheutua järjestelmäarkkitehtuurista, eikä kaikkia vaatimuksia ole kerätty etukäteen koko ohjelmiston elinkaaren ajan
  • Koko kehitysvaiheessa voidaan tehdä muutoksia
  • Jokainen iterointivaihe on jäykkä eikä päällekkäin toistensa kanssa
  • Tämä malli on halvempi verrattuna muihin
  • Ongelman korjaaminen yhdessä yksikössä edellyttää korjausta kaikissa yksiköissä ja vie paljon aikaa
  • Asiakas voi vastata jokaiseen rakennukseen
  • Virheet on helppo tunnistaa