Papildu modelis SDLC: izmantošana, priekšrocības un amp; Trūkums

Satura rādītājs:

Anonim

Kas ir elementārais modelis?

Inkrementālais modelis ir programmatūras izstrādes process, kurā prasības tiek sadalītas vairākos atsevišķos programmatūras izstrādes cikla moduļos. Pakāpeniska izstrāde tiek veikta, sākot no analīzes izstrādes, ieviešanas, testēšanas / verifikācijas, apkopes.

Katra iterācija iziet cauri prasībām, projektēšanas, kodēšanas un testēšanas fāzēm . Katrs nākamais sistēmas izlaidums pievieno funkciju iepriekšējam laidienam, līdz tiek ieviesta visa projektētā funkcionalitāte.

Sistēma tiek ražota, kad tiek piegādāts pirmais solis. Pirmais pieaugums bieži ir pamatprodukts, kurā tiek risinātas pamatprasības, un nākamajos pieaugumos tiek pievienotas papildu funkcijas. Kad klients ir analizējis galveno produktu, tiek izstrādāts plāns nākamajam pieaugumam.

Elementa moduļa raksturojums ietver

  • Sistēmas izstrāde ir sadalīta daudzos mini izstrādes projektos
  • Daļējas sistēmas tiek secīgi veidotas, lai izveidotu galīgo kopējo sistēmu
  • Vispirms tiek risināta augstākās prioritātes prasība
  • Kad prasība ir izstrādāta, prasība par šo pieaugumu tiek iesaldēta
Papildu fāzes Darbības, kas veiktas pakāpeniski
Prasību analīze
  • Tiek apkopotas prasības un programmatūras specifikācijas
Dizains
  • Šajā posmā ir izstrādātas dažas augstas klases funkcijas
Kods
  • Šajā posmā tiek veikta programmatūras kodēšana
Pārbaude
  • Kad sistēma ir izvietota, tā iziet pārbaudes fāzi

Kad izmantot elementāros modeļus?

  • Sistēmas prasības ir skaidri saprotamas
  • Kad rodas pieprasījums pēc produkta pirmstermiņa izlaišanas
  • Kad programmatūras inženieru komanda nav pārāk kvalificēta vai apmācīta
  • Kad ir iesaistītas augsta riska funkcijas un mērķi
  • Šāda metodika vairāk tiek izmantota tīmekļa lietojumprogrammām un uzņēmumiem, kuru pamatā ir produkti

Inkrementālā modeļa priekšrocības un trūkumi

Priekšrocības Trūkumi
  • Programmatūra tiks ātri izveidota programmatūras dzīves cikla laikā
  • Tas prasa labu plānošanu
  • Mainīt prasības un darbības jomu ir elastīgi un lētāk
  • Sistēmas arhitektūras dēļ problēmas var rasties pašas par sevi, un ne visas prasības ir savāktas visā programmatūras dzīves ciklā
  • Izstrādes posmos var veikt izmaiņas
  • Katra atkārtojuma fāze ir stingra un nepārklājas
  • Šis modelis ir lētāks, salīdzinot ar citiem
  • Problēmas novēršanai vienā vienībā nepieciešama visu vienību labošana un patērē daudz laika
  • Klients var atbildēt uz katru ēku
  • Kļūdas ir viegli identificējamas