Tagasi

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 sisse viimine üsna kulukas, siinkohal tulebki appi Inkrementaalne arendusmudel. Mudel ise on
ajagraafikupõhine ja ei tugine, erinevalt kosemudelist, täielikult valmiskirjutatud kavandile. Selles mudelis
saab arendada erinevaid programmi osi samaaegselt või erinevatel aegadel. Inkrementalses 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-kolme formaati.

Kuidas on inkrementaalses arenduses tegevuste käik?

Nõuete kirjeldus

Kirjeldatakse ära üldjoontes mida valminud tarkvara tegema peab. Nõudeid 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 millistest inkrementides klient oma toodet saama hakkab - kui pika aja tagant.
Iga inkrement peab tarnima kliendile mingisuguse funktsioneeriva 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 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 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 samaaegne nõuete täiendus

Kui arendatava programmi nõuded on külmutatud (ehk hetkel, arendustöö ajal, on nende muutmine võimatu), siis muude
tulevikus arendusse 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 inkrement 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 programiosa 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.

Arendusmudeli head ja vead

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õpuleviimist	Koodi korrashoiu mitteteostamine tõstab hiljem paranduste ja muudatuste sisseviimise kulusid

Arendusmudeli joonis

Inkrementaalne ja Interatiivne?

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

Inkrementaalne arendus
- on tarkvaratoote arendus kus iga inkremeni raames valmib toimiv tarkvara osa.
Valmis saadud tarkvara toote osake integreeritakse muu süsteemiga mis eelnevalt arendatud on.
Iteratiivne Arendus
- on muutmisstrateegia kus parandatakse või tehakse ringi juba olemasolev süsteem,
et seda siis täiustada, ehk olemasolev süsteem saab uue ja parema variandi - ehk iteratsiooni.

ALLIKAD:

EUCIP