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 muudatustest või siis lõppkasutaja tagasisidest.
Kuna kosemudelis keset arendustööd on muudatustega toimetulek keeruline, on kosemudeli kasutamise puhul
muudatuste sisseviimine üsna kulukas, siinkohal tulebki appi inkrementaalne arendusmudel. Mudel ise on
ajagraafikupõhine ja ei tugine, erinevalt kosemudelist, täielikult valmiskirjeldatud kavandile.
Selles mudelis saab arendada erinevaid programmi osi samaaegselt või erinevatel aegadel. Inkrementaalses arendusmudelis
aitab samaaegset 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 funktsionaalsust. Näiteks:
Ütleme et tegemist on failikonverteriga, siis ei oma ta suurt kasutajaliidese kujundust, ega isegi kõiki formaate
mis lõpp-programm teisendama peab, vaid ainult demonstreerib seda funktsionaalsust käsurea abil, osaliselt. Teisendab
ainult kahte või kolme formaati.



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 ning
vähem tähtsamateks. Tähtsamad nõuded on tavaliselt need, mis kliendile rohkem väärtust toob. 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 toote funktsioneeriva osakese.

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 vastavalt nõuetele programmiosa. Iga inkrementi saab arendada kasutades erinevaid eksisteerivaid



arendusmudeleid. Näiteks:
On olemas nõuetes programmiosa mille arendus ei vaja dünaamilist nõuetele vastavuse jälgimist nagu faili sisselugemine
või faili kirjutamine - seda programmiosa saab arendada näiteks Kosemudeli abil. See milline
arendusmudel kõige paremini sobib on arendusmeeskonna enda otsustada vastavalt sellele milline nõutud programmiosa parasjagu
arenduses on.

Arendusega samaaegne nõuete täiendus

Kui arendatatava programmiosa nõuded on külmutatud (ehk hetkel, arendustöö ajal, on nende muutmine võimatu), siis muude
arendusse tulevikus minevate osade nõudeid on võimalik veel muuta. Kui on vaja ka juba arendatud ning kliendile üleantud
inkremendi nõudeid muuta, siis seda saab ka teha, kuid olemasoleva inkremendi mille nõudeid muudeti, läheb tagasi arendatavate
tööde nimekirja, pärast nende nõuete muutmist. Ehk kõik nõuded mis ei kuulu parasjagu arendatava programmiosa juurde on
lahtised. Mis tähendab ka ühtlasi seda, et projekti nõuded selle alustamiseks ei pea olema täielikult kirjeldatud.

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 projektis olevaid nõudeid ning anda tagasisidet
juba valminud programmiosade kohta. Selle tagasiside põhjal võidakse tuletada ka juba valminud osadele uusi nõudeid. Klient saab ka
valminud osa koheselt integreerida muu olemasoleva keskkonna või eelnevalt arendatud toote süsteemidega.



Head küljed Halvad küljed
Klient saab valminud tooteosa katsetada/kasutada ilma et kogu projekt valmis oleks Progressi jälgimine on keerukas - arendustöö progressi ei jälgita enam arendatud
nõuete järgi vaid arenduskiirus põhiselt - kui palju igas ajavahemikus arendada on võimalik
Iga inkrement on arendatav erineva arendusmudeli abil Projekti struktuur degredeerub iga uue muudatusega, kuna nõuded on muutuvad, ning
struktuur ei pruugi muudatuste arvule või muudatuste vajadustele vsatu pidada - tekib spagett.
Kulutused on väiksemad - kuna kasutaja nõuded on muutuvad, aga muudatusi saab sisse viia
arendustsükli käigus on muudatuste sisseviimise kulutused väiksemad, kui neid teha pärast
esmast arendustsükli lõpuleviimist.		 Koodi korrashoi mitteteostamine tõstab hiljem paranduste ja muudatuste sisseviimise kulusid


Arendusmudeli joonis

Inkrementaalne ja Iteratiivne


Kuna inkrementaalne arendus ja iteratiivne arendus on lihtsalt sarnased sõnad, kipuvad nad inimestel sassi minema,
aga nad siiski tähendavad eri asju:



EUCIP