Tagasi

inkrementaalne Arendusmudel


inkrementaalne arendusmudel on üks viis kuidas lahendada kosemudeli jäika tsükli, see aitab arendusmeeskonna
toime tulla muudatusedega paremini. Muudatused võivad tulla kas äritegevusest, kliendi soovidest, turu olukorra
muutmisest, tehnoloogia muutmisest, seaduse muudatustest või siis lõppkasutaja tagasisidest.
Kuna kosemudelis keset arendustööd on muudatusetega 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
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 hakkatakse. Tehakse näiteks, kas mingisugune
kasutajaliidese prototüüp või programmeeritakse vähese testimise läbitud 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-kolme formaati.



Kuidas on inkrementaalses arenduses tegevuste käik?


Nõuete kirjeldus

Kirjedatakse ära üldjoontes mida valminud tarkvaratoode tegema peab. Nõuded jagatakse 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
kuida arendustöö toimima hakkab, ehk millistes inkrementides klient oma toodet saama hakkab - ehk kui pika aja tagant.
Iga inkrement peab tarnima kliendile mingisuguse tiite funktsioneeriva osakese.

Süsteemi arendus


Kui nõuded on olemas, ning ära jaotatud prioriteedi järgi hakatakse toodet tarnima peale nüüd teostavat arendusprotsessi.
Siin arendataksegi välja vastatavalt 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 jälgimist nagu faili sisse lugemine
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 samaegne nõuete täiendus

Kui arendatava ürogrammiosa 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 arendavate
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 arenduskiiruspõ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 vastu 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õppviimist		 Koodi korrashoiu mitteteostamine tõstab hiljem paranduste ja muudatuste sisseviimise kulusid


Arendusmudeli joonis:

Inkremetaalne ja Iteratiivne?


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



EUCIP