Inkrementaalne mudel SDLC-s: kasutamine, eelised ja puudused

Mis on inkrementaalne mudel?

Inkrementaalne mudel on tarkvaraarenduse protsess, kus nõuded jaotatakse mitmeks eraldiseisvaks tarkvaraarenduse tsükli mooduliks. Järkjärguline arendus toimub etapiviisiliselt alates analüüsi kavandamisest, juurutusest, testimisest/kontrollimisest ja hooldusest.

Inkrementaalne mudel SDLC-s

Iga iteratsioon läbib nõuded, projekteerimise, kodeerimise ja testimise etapid. Ja süsteemi iga järgmine väljalase lisab funktsiooni eelmisele versioonile, kuni kõik kavandatud funktsioonid on rakendatud.

Inkrementaalne mudel SDLC-s

Süsteem pannakse tootmisse, kui tarnitakse esimene juurdekasv. Esimene juurdekasv on sageli põhitoode, mille põhinõuded on täidetud ja järgmiste sammudega lisatakse täiendavaid funktsioone. Kui klient on põhitoodet analüüsinud, on kavas järgmise juurdekasvu jaoks välja töötada.

Inkrementaalmooduli omadused hõlmavad

  • Süsteemiarendus on jaotatud paljudeks miniarendusprojektideks
  • Osasüsteeme ehitatakse järjest, et saada lõplik kogusüsteem
  • Esmalt lahendatakse kõrgeima prioriteedi nõue
  • Kui nõue on välja töötatud, külmutatakse selle juurdekasvu nõue
Inkrementaalsed faasid Järkjärguliste etappidena teostatavad tegevused
Nõuete analüüs
  • Kogutakse kokku tarkvara nõuded ja spetsifikatsioonid
Disain
  • Selles etapis on kavandatud mõned tipptasemel funktsioonid
kood
  • Selles etapis tehakse tarkvara kodeerimine
test
  • Kui süsteem on kasutusele võetud, läbib see testimisetapi

Millal kasutada inkrementaalseid mudeleid?

  • Süsteemi nõuded on selgelt arusaadavad
  • Kui tekib nõudlus toote ennetähtaegse vabastamise järele
  • Kui tarkvaraarendus meeskond ei ole väga hästi kvalifitseeritud ega koolitatud
  • Kui tegemist on kõrge riskiga funktsioonide ja eesmärkidega
  • Sellist metoodikat kasutatakse rohkem veebirakenduste ja tootepõhiste ettevõtete jaoks

Inkrementaalse mudeli eelised ja puudused

Eelised Puudused
Tarkvara genereeritakse kiiresti tarkvara elutsükli jooksul See nõuab head planeerimist
Nõuete ja ulatuse muutmine on paindlik ja odavam Probleeme võib põhjustada süsteemiarhitektuur kui selline, et kõiki nõudeid ei koguta kogu tarkvara elutsükli jooksul eelnevalt kokku
Muutusi saab teha kogu arendusetapi jooksul Iga iteratsioonifaas on jäik ega kattu üksteisega
See mudel on teistega võrreldes odavam Probleemi kõrvaldamine ühes üksuses nõuab parandamist kõigis üksustes ja kulutab palju aega
Klient saab vastata igale hoonele
Vigu on lihtne tuvastada