Inkrementaalne arendusmudel


Inkrementaalne arendusmudel on üks viis kuidas lahendada kosemudeli jäika tsüklit. See aitab
Arendusmeeskonnal toime tulla muudatustega paremini. Muudatused võivad tulla kas äritegevusest,
kliendi soovidest, turu olukorra muutmisest või tehnoloogiate muutumisest, seaduse muutumisest või
lõppkasutaja tagasisidest. Kuna kosemudelis keset arendustööd on muudatustega toimetulek keeruline
on kosemudeli kasutamise puhul muudatuster sisseviimine üsna kulukas, siinkohal tulebki appi
inkrementaalne arendusmudel. Mudel ise on siis ajagraafiku põhine ja ei tugine erinevalt
kosemudelist täielikult valmis kirjeldatud kavandile. Selles mudelis saab arendada erinevaid
programmi osi samaaegselt või erinevatel aegadel.
Inkrementaalses arendusmudelis aitab samaaegset arendustööd teha kindlad tefevused mida
kosemudelis ei ole. Nende tegevuste abil on võimalik kliendile kuvada programmile keskse
tähtsusega osi, enne kui neid täielikult arendama hakatakse. Tehakse näiteks, kas mingisugune
kasutajaliidese prototüüp või programmeeritakse vähese testimise läbinud MVP (Minimum viable product)
mis omab ainult programmi nõudes kirjeldatud keskset funktsiooni. Näiteks kui tegemist on faili
konverteriga, siis ei oma ta suurt kasutajaliidese kujundust ega isegi kõiki formaate, mis
lõpp-programm teisendama peab vaid ainult demonstreerib seda funktsionaalsust osaliselt.



Kuidas on inkrementaalses arenduses tegevuste käik?

Nõuete kirjeldus

Kirjeldatakse ära üldjoontes, mida valminud tarkvaratoode tegema peab. Nõuded jaotatakse ka ära
tähtsamateks ja vähemtähtsamateks. Tähtsamad nõuded on tavaliselt need, mis kliendile rohkem
väärtust toovad. Siin määratakse ära ka kuidas arendustöö toimima hakkab ehk millistes
inkrementides klient oma toodet saama hakkab - ehk kui pika aja tagant.
Iga inkrement peab tarnima kliendile mingisuguse toimiva toote osakese.

Süsteemi arendus

Kui nõuded on olemas, ning ära jaotatud prioriteedi järgi hakatakse toodet tarnima peale nüüd
teostatavat arendusprotsessi. Siin arendatakse välja vastavalt nõuetele programmi osa.
Iga inkrementi saab arendada kasutades erinevaid eksisteerivad arendusmudeleid.
Näiteks kui on programmi osa, mis väga palju muutmist ei vaja - näiteks faili arvutist
lugemist või sinna kirjutamist - siis on seda programmiosa (või funktsiooni) võimalik
arendada ka näiteks jäiga mudeli (kosemudeliga) või agiilse mudeliga. See milline arendus-
mudel kõige paremini sobib, on arendusmeeskonna otsustada, vastavalt sellele milline
programmi osa parasjagu arendusel on.

Arendusega samaaegne nõuete täiendus

Kui arendatava programmi osa nõuded on külmutatud (ehk neid ei saa hetkel muuta), siis muude
mitte arenduses olevate osade nõudeid on võimalik muuta, ning nüüd kui mingisugune programmi
osa läbib parasjagu arendustsükli on võimalik muuta muid nõudeid, mille vastav inkrement, kas
hetkel arenduses enam ei ole või veel ei ole. Kõik muud nõuded on lahtised.
See tähendab ka
ühtlasi seda, et üks programmi osa on nõuete väljaselgitamise lõpetanud, saab seda arendama asuda
enne kui nõuded täielikult valmis on.

Tarne ja integratsioon

Nõuetele vastava programmiosa valmimisel tarnitakse programmiosa - ehk inkrement - kliendile.
Klient saab siis selle koheselt kasutusse võtta või omapoolselt läbi testida - ja täpsustada
edasisi projekti nõudeid ja anda tagasisidet valminud programmi osa kohta.
Selle põhjal võidakse tuletada juba valminud osale uusi nõudeid.
Klient saab siis ka
valminud osa koheselt integreerida muu olemasoleva keskkonna või eelnevalt arendatud
toote süsteemidega.



Inkrementaalse arenduse head ning halvad küljed

Head küljed Halvad küljed
Kulutused on väiksemad - kuna kasutaja nõuded on muutuvad,aga muudatusi
saab sisse viia arendustsükli käigus, on nende muudatuste kulud väiksemad
kuna arendustsükkel ise ei ole vaja lõpuni viia, enne muudatuste sisse-
viimist.		 Progressi jälgimine on keerukas - arendustöö progressi ei jälgita enam
arendatud nõuete järgi, kuna need ei ole arendustöö alguses valmis, vaid
progressi jälgitakse arenduskiirusepõhiselt - kui palju igas ajavahemikus
nõuetest arendada on võimalik. See tekitab siis halduritele nõude, et nad
vajavad pidevalt dokumentatsiooni arendustöö hetke kulgemise kohta. Kui
arendustöö on ka kiire, siis vahest on ka selle dokumentatsiooni hankimine
keeruline, kuna iga väikese versiooni kohta ei ole mõtet seda lihtsalt
tekitadagi.
Kliendi tagasiside on kohene - olemasolevale arendustööle saab meeskond
Keset arendust tagasiside, et vajadusel muuta oma nõudeid, ja seega
arenduse sunda. Klient näeb ka kui palju on tehtud.
 Süsteemi struktuur aja jooksul degredeerub - kuna arendatakse juurde
pidevalt uusi osi, ning ka selliseid osi mida alguses planeeritud ei olnud
siis kipub arendatava toote sisemine süsteem spagetistuma. Selle vältimiseks
kulutatakse lisaressursse koodi refaktoreerimisele, et sisemine struktuur
korras hoida. Kui korrashoidu ei teostata, on hilisem mudatuste ja uute
valmisosade integratsioon tunduvalt keerulisem.
Tarne on kiirem - klient saab juba funktsioneerivad osad kohe pärast
arendustöö lõppu kasutusele võtta, ning klient saab sellest varem kasu
kui näiteks tarkvaratootega, mida arendatakse jäiga arendusmudeliga.


Arendusmudeli joonis

Mis vahe on inkrementaalsel SDLCl ja interatiivsel SDLCl?

Kuna Inkrementaalne arendus ja iteratiivne arendus on lihtsalt sarnased sõnad
kipuvad nad inimestel sassi minema, aga nad siiski tähendavad erinevaid asju.

Allikas (eucip)