Inkrementaalne ehk järk-järguline (ingl. k. successive) arendusmudel, mille käigus ehitatakse esmalt lihtne töötav süsteem valmis ning antakse kliendile üle. Seejärel implementeeritakse ning antakse üle mitmeid järk-järgulisi iteratsioone, kuni on saavutatud soovitud lõplik versioon.
Mudeli eesmärk on paremini toime tulla varasema kosemudeli jäikade omadustega, kuna reaalsuses võib arendajatel olla vajalik teha töö käigus erakorralisi muudatusi tulenevalt muudatustest kliendi soovides, turul, tehnoloogiates ning seadustes. Kosemudeli puhul viiks sellistele muutustele reageerimine projekti kulud kõvasti üles, mistõttu agiilsed meetodid nagu inkrementaalne mudel aitavad arendajatel paremini reageerida.
Üks olulisimaid erinevusi inkrementaalsel mudelil kosemudeliga võrreldes on see, et see on ajagraafikupõhine ega ei tugine mingil täielikult valmiskirjutatud kaval. Tänu sellele on võimalik arendada erinevaid programmiosi näiteks samaaegselt. Näiteks saab teha prototüübi kasutajaliidesele, millega saab kliendile vahendada visuaalset infot valmiva programmi kohta või minimaalse töötava toote (MVP - minimum viable product), mis katab pogrammi nõuetes kirjeldatud keskset funktsiooni.
Defineeritakse arendatava tarkvaratoote olulisemad funktsioonid ja omadused, mis kirjeldatakse nõuetes. Nõuded jaotatakse tähtsamateks ja vähem tähtsamateks. Tähtsmate nõuete alla lähevad enamasti kliendile enim väärtust toovad nõuded.
Vastavalt nõuetele kujuneb esialgne plaan inkrementide kohta, mille tagant klient oma toodet saama hakkab. Iga inkrement peaks tarnima kliendile mingisuguse toimiva osa tootest.
Iga inkrementi ehk osa saab arendada, kasutades erinevaid eksisteerivaid arendumudeleid, mis võivad olla teised väledad meetodid, aga ka kosemeetod. Sobiva töömudeli määrab suuresti arendatav programmiosa, selle vajadused ning arendusmeeskonna eelistused.
Kui arendatava programmiosa nõuded on külmutatud (ehk neid hetkel ei muudeta), siis teiste mitte arenduses olevate osade nõudeid on võimalik muuta.
Kui programmiosa valmis saab, tarnitakse see kliendile, kes saab selle töösse rakendada ning seda põhjalikult testida. See aitab omakorda kliendil täpsustada nõudeid järgmiste osade jaoks. Seejärel võetakse käsile järgmine inkrement/osa ning iga järgmine valmiv osa liidestatakse olemasoleva süsteemiga.
| Eelised | Probleemid |
|---|---|
| Kulutused on väiksemad, kuna kliendi soovide muutuste ajendil tehtav analüüsi ja dokumentatsiooni hulk väheneb oluliselt võrreldes kosemudeliga. | Kiire arenduse puhul on rojekti progressi raske jälgida, kuid samal ajal on ebapraktiline tekitada dokumentatsiooni iga versioonimuudatuse jaoks. |
| Kliendiga toimub kiirem infovahetus, klient saab anda tagasisidet olemasolevale arendustööle selle valmimise käigus, samuti näeb ta projekti valmimisprogressi ning saab vajadusel täpsustada uusi nõudeid ja soove. | Süsteemi struktuur aja jooksul degreerub - pidevalt uusi (ja mitteplaneeritud) osi juurde arendades kipub projekti sisemise struktuuri kvaliteet ja loetavus kannatama. See tekitab vajaduse teostada regulaarset koodi korrashoidu. |
| Klient saab kohe pärast arendustöö lõppu võtta funktsioneerivad osad kasutusele, mis annab talle varem kasu võrreldes tootega, mida arendatakse jäiga arendusmudeliga. | Mitteplaanipäraste iteratsioonide lisandumine arenduse käigus võib oluliselt tõsta projekti kulusid. |
Kuna inkrementaalne ja iteratiivne arendus on oma nimede poolest sarnased, kipuvad need inimestel tihti sassi minema. Ometi on nad oma olemuselt üsna erinevad.