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 muutumisest, tehnoloogiate muutumisest, seaduse muutumisest või lõppkasutaja tagasisidest. kuna kosemudelis keset arendustööd on muudatusega toimetule keeruline, on
kosemudeli kasutamise puhul muudatuste sisseviimine üsna kulukas. siinkohal tulebki appi inkrementaalne arendusmudel. mudel ise on siis ajagraafiku põhineja ei tugine erinevalt kosemudelist täielikult
valmiskirjutatud kavandile.selles mudelis saab arendada erinevaid programmiosi samaaegselt või erinevatel aegadel.
inkrementaalses arendusmudelis aitab samaaegselt arendustööd teha kindlad tegevused, 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õuetes kirjeldatud keskset funktsiooni.
Näiteks kui tegemist on failikonverteriga, siis ei oma ta suurt kasutajaliidese kujundust ega isegi kõiki formaate, mis lõppprogrammi teisendama peab, vaid ainult demonstreerib seda funktsionaalsust osaliselt.

kuidas on inkrementaalses arenduses tegevuste käik?


nõuete kirjeldus

kirjeldatakse ära üldjoonstes, mida 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 tooteosakese.

süsteemi arendus

kui nõuded on olemas ning ära jaotatud prioriteedi järgi, hakatakse toodet tarnima peale nüüd teostatavat arendusprotsessi. siin arendataksegi välja vastavat nõuetele programmiosa.
iga inkrementi saab arendada kasutades erinevaid eksisteerivaid 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 ehk kosemudeliga või agiilse mudeliga. see, milline arendusmudel kõige paremini sobib, on arendusmeeskonna otsustada vastavalt sellele, milline programmipsa parasjagu arendusel on.

arendusega samaaegne nõuetetäiendus

kui arendatava programmiosa nõuded on külmutatud ehk neid ei saa hetkel muuta, siis muude mittearenduses olevate osade nõudeid on võimalik muuta ning nüüd kui mingisugune programmiosa läbib parasjagu arendustsüklit, on võimalik muuta muid nõudeid,
millele 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 kui üks programmiosa on nõuete väljaselgitamise lõpetanud, saab seda arendama asuda enne kui
nõuded täielikult valmis on.

tarne ja integratsioon

nõudele vastava programmiosa valmimisel tarnitakse programmi osa ehk inkrement kliendile. klient saab selle siis koheselt kasutusele võtta või omapoolselt läbi testida ja täpsustada edasisi projektinõudeid ja anda tagasisidet valminud programmiosa kohta.
selle põhjal võidakse tuletada juba valminud osale uusi nõudeid. klient saab siis ka valminud osa koheselt integreerida muu olemasoleva eelnevalt arendatud toote süsteemiga või olemasoleva keskkonnaga.



inkrementaalse arenduse head ning halvad küljed

head küljed halvad küljed
kulutused on väiksemad, kuna kasutaja nõuded on väiksemad, 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 sisseviimist progressi jälgimine on keerukas- arendustöö progressi ei jälgita enam arendatud nõuete järgi, kuna need ei ole arendustöö alguses valmis, vaid prograssi jälgitakse arenduskiiruse põ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 muuta arendussuunda. klient näeb ka, kui palju on tehtud.
 süsteemi struktuur aja jooksul degredeerub, kuna arendatakse juurde pidevalt uusi osi ning vahepeal ka selliseid, mida alguses planeeritud ei olnud. siis kipub arendatava toote sisemine süsteem spagetistuma.
selle vältimiseks kulutatakse lisaraha ja -aega koodi refaktoreerimisele, et sisemine struktuur korras hoida. kui korrashoidu ei teostata, onhilisem muudatuste ja uute valmisosade integratsioon
tunduvalt keerulisem.
tarne on kiirem- kliend 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 iteratiivsel SDLCl?

kuna inkrementaalne asendus ja iteratiivne arendus opn lihtsalt sarnased sõnad, kipuvad nad inimestel sassi minema, aga nad siiski tähendavad erinevaid asju.

Allikas