Tarkvaraarenduse üks võtmeküsimusi on - kuidas tulla toime muudatustega, sest suurte tarkvaraprojektide puhul on muutused vältimatud. Äritegevus muutub ja see toob endaga kaasa muutunud nõuded, tekivad uued tehnoloogiad, mida oleks otstarbekas tarkvarasüsteemides nende täiustamiseks rakendada ning muutuvad platvormid, millele süsteem on rajatud. Nimetatud muutused nõuavad ümbertegemist ning maksab nii nõuete korduv analüüsimine koos teostusega kui ka uute funktsionaalsuste realiseerimine. Muudatuste maksumust tuleb hoida nii väiksena kui võimalik. Seega tuleb arendusprotsessi tuua sisse tegevused, mis aitavad muudatusi ette näha enne kui nende sisseviimine olulist tööd nõuab. Näiteks prototüüpimise abil saab kliendile näidata varakult süsteemi olulisi omadusi. Muudatusi on parem teha siis, kui nende sisseviimine on võimalikult odav. Sellest tulenevalt on mõistlik toote järk-järguline (inkrementaalne) arendus ja üleandmine. Nii saab muudatusi teha ka nendes osades, mida pole veel arendama asutud.

Mõistelist segadust tekitavad iteratiivne ja inkrementaalne arendus. Alistair Cockburni järgi on tegemist kahe erineva arendusmudeliga:

• Inkrementaalne arendus on etapiviisiline ja ajagraafikut järgiv strateegia, kus süsteemi erinevaid osi arendatakse erinevatel aegadel ja erineva kiirusega ning kui üks osa valmis saab, integreeritakse see juba valmis süsteemiga.
  Alternatiivne strateegia oleks kodeerida kõik süsteemi osad ja siis kogu kood integreerida ühekorraga.
• Iteratiivne arendus on nö muutmisstrateegia, kus nähakse ette olemasolevate süsteemi osade ümbertegemine ja parandamine.
  Alternatiivne strateegia oleks planeerida tegevused selliselt, et kõik tehtaks õigesti esimesel katsel

Ian Sommerville järgi on iteratiivne arendusmudel pigem üldine nimetus mitmele nn hübriidmudelile (sh inkrementaal- ja spiraalmudel). Sõna "iteratiivne" rõhutab seda, et tegevused selles mudelis korduvad.

Sõltumata tähendusest, mis pannakse iteratiivse arenduse taha, on inkrementaalne arendus erinevates allikates üsna üheselt kirjeldatud.

Inkrementaalne arendus võib olla nii plaanipärane kui ka paindlik. Mudel näeb ette ehitada valmis algul väike osa süsteemist ning seda järgnevalt mitmes etapis laiendada. Inkrementaalne lähenemine võimaldab arendajatel ja ka tulevastel süsteemi kasutajatel varajastest iteratsioonidest õppida, saada tagasisidet veel siis kui on võimalik teha muudatusi nt süsteemi arhitektuuri kirjutamata kogu koodi ümber.

Joonis 1-2. Inkrementaalne arendus

Tarkvara spetsifikatsioon, projekt ja teostus jaotatakse osadeks (increment), mida asutakse ükshaaval arendama. Sel viisil väheneb ümbertegemist vajavate süsteemi osade hulk ja kliendid saavad võimaluse oma soove pikema aja vältel ringi mõelda. Tüüpiliseks tuleks pidada veel seda, et valminud süsteemi osad on kasutatavad ning see aitab kliendil oma edasistes soovides paremat selgust saada.

Tegevuste käik on järgmine: kõigepealt määratakse nõuded üldisemal kujul ning nad jaotatakse tähtsamateks ja vähemtähtsateks. Järgnevalt määratakse tarneosad - mitme tarnena ja millest koosnevana klient oma tarkvara saama hakkab. Tarne all mõeldakse süsteemi osa ehk inkrementi. Iga tarne peab lisama süsteemile kindla funktsionaalsuse. Sealjuures tootmist alustatakse kõrgema prioriteediga osadest. Kui süsteemi osad on määratud, võetakse ette 1. osa ja hakatakse seda detailiseerima, kasutades selleks sobivaimat protsessi (ja miks ka mitte koskmudelit). Samaaegselt saab täpsustada teiste osade nõudeid, kuid töös oleva osa nõuded on külmutatud. Kui väga vaja, pöördutakse selle osa juurde tagasi hiljem. Kui osa saab valmis, tarnitakse see kliendile, kes saab selle töösse rakendada (või vähemalt seda tõsiselt katsetada). See aitab kliendil täpsustada nõudeid järgmiste osade jaoks (või sama osa hilisemate versioonide tarvis). Seejärel võetakse käsile järgmine osa. Uued osad liidestatakse olemasoleva süsteemiga. Kõiki osi ei pea arendama sama protsessi kasutades.

Inkrementaalse arenduse eelised:

1. Kulutused, mida tehakse kasutaja nõuete muutumise tõttu, vähenevad, uuesti tehtava analüüsi ja dokumentatsiooni hulk väheneb oluliselt võrreldes koskmudeliga.

2. Kergem on saada kliendi tagasisidet juba tehtud arendustööle - kliendid saavad anda kommentaare valminud osadele ja ka näevad, kui palju on tehtud. Sel viisil on esimesed süsteemi osad nagu prototüübid kogu süsteemile.

3. Kliendile on võimalik kiiremini tarnida ja evitada loodavat tarkvara - kliendid võivad saada süsteemist reaalset kasu varem, kui see oleks võimalik koskmudeliga.

Inkrementaalse arendused probleemid:

1. Progress ei ole hästi jälgitav - haldurid vajavad pidevalt materjale progressi mõõtmiseks. Kiire arenduse korral ei ole tasuv tekitada dokumente iga pisikese versioonimuudatuse jaoks.

2. Süsteemi struktuur kipub halvenema uute osade lisandumisel - pidev muutmine rikub süsteemi struktuuri. Selle vältimiseks ja tarkvara kvaliteedi parandamiseks on vaja kulutada lisaks aega ja raha refaktoreerimisele. Halb struktuur muudab tarkvara hilisema muutmise keerulisemaks ja kulukamaks.

Agiilsed arendusmeetodid

Agiilsete arendusmeetodite jaoks sobib kasutada inkrementaaset mudelit. Agiilse tarkvaraarenduse levimise algus läheb 2001 aastasse, kui senise üliplaanipärase arenduse vastased kirjutasid alla "The Agile Manifesto"-le, mille kõige olulisemates punktides rõhutakse inimesele ja inimeste vahelisele suhtlemisele:

• Inimesed ja suhtlemine on tähtsamad kui protsessid ja tööriistad.
• Töötav tarkvara on tähtsam kui dokumentatsioon.
• Koostöö kliendiga on tähtsam kui läbirääkimised lepingu üle.
• Muudatussoovidele vastutulek on tähtsam kui plaani järgmine.

Enam arvestatakse tagasiside (koormustestimine, kasutajate arvamus jm) käigus saadud infoga kui loodetakse hoolika etteplaneerimise tehnikale. Põhitähelepanu on inimestel, sh kasutajatel, ja pideval testimisel. Öeldakse, et agiilmeetoditega saavutatakse parem tulemus sama raha eest, aga agiilmeetoditega on raskem ette planeerida, millal tarkvara mingi funktsioon valmis saab - „Agile process will provide the most bang for the buck, but won't say exactly when that bang will be".

Tuntumad ja levinumad agiilsed arendusmeetodid on ekstreemprogrammeerimine (XP), Scrum, Feature Driven Development (FDD), Open Unified Process (OpenUP) jt

Ekstreemprogrammeerimine ehk XP on tuntumaid agiilmeetoodeid. XP-s viiakse sammud läbi äärmuslikult (ekstreemselt - siit meetodi nimetus) lühikestena, võrreldes klassikaliste arendusmudelitega - esimene sammude läbimistsükkel võib olla päevad või nädal pikk, samas kui klassikalistes mudelites kestab see kuid ja aastaid. Enne kodeerimist kirjutatakse automatiseeritud testid, mida tarkvara peab läbima, seejärel programmeeritakse paarides (so kaks programmeerijat ühe arvuti taga kodeerivad ühte programmilõiku - nn "paarisprogrammeerimine"). Kui valminud kood läbib testid, on programmeerimise samm antud iteratsioonis lõpetatud.