Tagasi Inkrementaalne arendusmudel

Inkrementaalne arendusmudel


Inkrementaalne arendusmudel on üks viis kuids lahendada kosemudeli jäika tsüklit. See aitab
Arendus meeskonnal toime tulla muudatustega paremini. Muudatused võivad tulla ka äritegevusest
kliendi soovidest, turu olukorra muutumisest, tehnoloogia muutumisest, seaduse muutumisest või
lõppkasutaja tagasisidet. Kuna kosemudelis keset arendustööd on muudatusega toimetulek
keeruline, on kosemudeli kasutamise puhul muudatuste sisseviimine üsna kulukas, siinkohal tulebki
appi inkrementaalne arendusmudel. Mudel ise on siis ajagraafikupõhine ja ei tugine erinevalt
kosemudelist täielikult valmiskirjeldatud kavandile. Selles mudelis saab arendada erinevaid
programmiosi samaaegselt või erinevatel aegadel.
Inkrementaalses arengumudelis 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õetes kirjeldatud keskset funktsiooni.
Näiteks kui 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 osaliselt



Kuidas on inkrementaalses arenduses tegevuseta käik?

Nõuete kirjeldus

Kirjeldatakse ära üldjoontes mida valminud tarkvaratoode tegema peab. Nõudedjaotatakse ka
ära tähtsamateks ja vähemtähtsateks. 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 mingisugune toimiva toote 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 vastavalt 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 (kosemudeli) bõi agiilse mudeliga. See milline arendus
mudel kõige praemini sobib, on arendusmeeskonna otsustada, vastavalt sellele milline
Programmiosa parasjagu arendusel on.

Arendusega samaaegne nõuete täiendus

Kui arendatava programmiosa nõuded on külmutatud (ehk neid ei saa hetkel muuta), siis muude
mittearendusesolevate osade nõudeid on võimalil muuta, ning nüüd kui mingisugune programmiosa
läbib parasjagu arendustsüklit 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äljaselgitama lõpetnud, saab seda
arendama asuda, enne kui nõuded täielikult valmis on.

Tarne ja integratsioon

Nõuetele vastava programmiosa valmistamisel tarnitakse programmiosa - ehk inkrement - kliendile
Klient saab siis selle koheselt kasutusse võtta - või omapoolset läbi testida - ja
täpsustada edasis 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
Valminud osa koheselt integreerida muu olemasoleva keskkonna või eelnevalt või eelnevalt arendatud toote
süsteemidega.



Inkrementaalne arenduses 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õhiliselt - 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
suunda. klient näeb ka kui palju tehtud on.
 Süsteemi stuktuur 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 refakroreerimisele, et sisemine struktuur
korras hoida. Kui korrashoidu ei teostata, on hilisem muudatuste ja uute
valmisoode 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 arendusmudeli


Arendusmudeli joonis



Mis vahe on inkrementaalsel SDLCl ja iteratiivsel SDLCl?

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

Allikas(eucip)