Agiilne arendusmudel on peamiselt koostatud selleks, et saaks projektis muudatustega
kiiresti kohaneda. Selle arendusmudeliga saab projekti kiiremini valmis. Selleks,
eemaldatakse tegevusi mis ei ole tähtsad projekti jaoks. Kõik, mida loetakse aja ning
pingutuse raiskamine on välditud.
Agiilne arendusmudel koosneb kuuest etappidest:
Esimesel etappil toimub vajaduste kogumine. Seda saavutatakse suheldes klientiga. Nendega
kohtakse ning püütakse aru saada mida nad tahavad ning ootavad tarkvaralt. Siis tuvastakse
peamised vajadused ning ärieesmärgid. Määratakse, kui palju aega ning pingutust läheb tarkvara
arendusele. Mõeldakse läbi, kas projekt on tehniliselt võimalik ning kas see on investeerimise
väärt.
Teises etappil toimub vajaduste disainimine. Kui vajadused on kogutud, siis järgmine samm on
süsteemi arhitektuuri disainimine nende vajaduste põhjal. See aitab teha kindlaks, et tarkvara
struktueeritud kasutaja ootuste põhjal. Siis tehakse traatraamistikud kasutajaliidese jaoks. Need
on plaanid, mis näitavad kuidas tarkvara välja näeb ning kuidas kasutajad seda kasutavad, tagastades
seda et on kasutajasõbralik ja lihtne kasutada. Siis tehakse UML diagramme, et visuaalselt näidatakse
tarkvara struktuur ja kuidas eri osad töötavad koos. Siis on prototüübid tehtud, mis annavad sidusrühmadele
varaset vaadet tarkvarast. See aitab koguda tagasisidet varasemalt ning annab võimaluse muudatustele enne
kui täis arendus toimub.
Kolmandas etappis toimub konstruktsioon ja iteratsioon. Arendusmeeskond töötab funktsioonide peale, mida tuvastati vajaduse ning
disain faasides. Uued funktsionaalsused on kooditud ning integreeritud tarkvarale spetsiifilise iteratsiooni
eesmärkide põhjal. Pärast igat iteratsiooni, kasutatav versioon tarkvarast on valmis. Iga uue tsükliga, tarkvara on
täiustatud, lisades rohkem funktsioone ja täiustades olemasolevaid. Iga tsükkel kestab üks kuni neli nädalat.
Neljandas etappis toimub testimine ning kvaliteedi tagamine. Toimub plokkide testimine, kus vaadakse koodi väikesed osasid,
et tagada individuaalsed osad programmis saavad töötada iseseisvalt. Plokki testimist kasutatakse üksikud koodi plokkide testimiseks.
Integratsiooni testimisel tuvastakse ning lahendatakse probleeme, mis v]ivad tekkida kui erinevad plokkid tarkvaras on ühendatud. Siis
on ka süsteemi testimine, mill eesmärk on et tarkvara kothuks kasutajate vajadustega ning et see töötaks õigesti igas võimalikkus stsenaariumis.
Viiendas etappis toimub väljastamine. Kui iteratsioon on tehtud ning täielikult testitud, siis tarkvara on valmis väljalaskmiseks kasutajatele.
Agiilse arendusmudelis, väljastamine ei ole ükskord asi, vaid on käimasolev protsess. Uuendused ning täiendused tuuakse regulaarselt, tehes kindlaks
et tarkvara pidevalt areneb ning paremaks läheb iga väljastamisega.
Viimane etapp on tagasiside. Võetakse tagasiside klientidelt, kasutajatelt ning sidurühmadelt pärast igat iteratsiooni. Aru saadakse kui hästi toode kohtub
kasutaja vajadustega ning tuvastakse kohti, kust täiustust võiks teha. Kontrollitakse üle, kas on vigu või probleeme mida vajab parandust. Lõpuks, tehakse
täiustusi arendusplaanile tagasiside põhjal toode edasi täiustamiseks.
Agiilses arendusmudelis on olemas kümme alamvariante.
1. Testipõhine arendus (TDD) on tarkvara arendus protsess, mis tugineb ühiku testi juhtumite koostamisel enne päris koodi arendamist. See on iteratiivne lähenemine, mis
kombineerib kolm operatsiooni, programmimist, ühiku testi loomist ning refaktoreerimist. Kasu on sellest, et saadakse vigasid tuvastada enne tegelikku koodi arendamist.
2. Käitumisepõhine arendus (BDD) on tarkvara arendusprotsess, mille eesmärk on dokumenteerida ning arendada rakendust vastavalt kasutaja käitumisele, mida kasutaja rakenduse
kasutamisel ootab. See julgustab koostöödd arendaja, kvaliteedi eksperdi ning kliendi esindajate vahel. Kasu on sellest, et saadakse paremini aru kasutaja vajadustest,
jälgides nende käitumistele.
3. Vastuvõtutestipõhine arendus (ATDD) on koostöö protsess, kus kliendi esindajad, arendajad ning testijad tulevad koos, et arutada vajadused, võimalikud lõksud ning vähendada
võimalust probleemidele enne koodi alustamist. Kasu on sellest, et kliendi esindajate abil koos teiste meeskondadega pantakse paika vajadused ning mõeldakse
takistuste peale, mis võivad esineda ja ka lahendus nendele.
4. Pidev testipõhine arenduses (CTDD), arendaja kirjutab testi alguses, aga ei ole sunnitud täitma testi ise. Testid käivad automaatselt kasutades pidevat testimis tööriista, mis käib
taustal. See võib vähendada aja raiskamist, mille tulemusena ei vaja arendajat testi alustamiseks peale igat faasi normaalses testipõhises arenduse praktikas. Kasu on sellest, et
saadakse pidevat tagasisidet, mille tõttu kulutatakse vähem aega sest arendaja ei pea seda manuaalselt ise tegema.
5. Andmetepõhine arendus (DDD) on protsess, kus koostakse tarkvarat, mis tugineb andmetele, et suunata toode disaini, rakendamise ning testimisele. See tähendab, et andmeid kasutatakse otsuste
tegemiseks, eelduste kinnitamine, tulemuste mõõtmiseks ning protsesside optimeerimiseks. See tähendab ka seda, et kogutakse ning analüüsitakse andmeid kasutajatelt, klientidelt, konkurentidelt,
ning turult et aru saada nende vajadustest, eelistustest ja käitumistest. Kasu on sellest, et on olemas andmebaas, mille kaudu saab otsuseid langetada.
6. Andmetele orienteeritud disain (DOD) on tarkvara disain lähenemine, mis keskendub andmete ograniseerimisele viisil, mis teeb sellele ligipääsu ja selle käsitsemise lihtsaks. See põhinen ideel, et
andmed peavad olema peamine fookus programmis, pigem kui operatsioonid ja teisendused täidetud andmetes. Kasu on sellest, et vajalikud andmed millegi tegemiseks on lihtne kasutusele võtta.
7. Disainilt turvaline (SbD) on tarkvara ja riistvara arendamise lähenemisviis, mille eesmärk on muuta süsteemid võimalikult haavatavustevabaks ja rünnakukindlaks selliste meetmete abil nagu pidev
testimine, autentimiskaitsemeetmed ja parimate programmeerimistavade järgimine. Keskendudes toodete turvalisuse sisseehitamisele on vastuolus liigagi levinud kalduvusega jääda arenduses tagaplaanile.
Olemasolevate haavatavuste ja turvaaukude parandamine nende avastamisel võib olla ebaühtlane protsess ning ei ole kunagi nii tõhus kui süsteemide algusest peale võimalikult turvaliseks kujundamine.
Kasu on sellest, et algusest peale tarkvara on turvaline ning see turvalisus ainult kasvab ajaga.
8. Spetsifikatsioon näide kaudu (SbE) on protsess, kus täpselt määratletakse nõuded reaalsete näidete abil, minimeerides vigade ja arusaamatuste riski. Kasu on sellest, et see võimaldab
arendusmeeskondadel tõhusamalt töötada ja tootel paremini vastata kasutajate ootustele.
9. Domeenipõhine disain (DDD) on meetod, mis prioritiseerib spetsiifilise probleemi ala arusaamist ning modelleerimist kus süsteemi tarkvara toimib. Kasu on sellest, et see rõhutab vajadust tiheda koostöö järele valdkonna ekspertidega,
et saada põhjaliku arusaam valdkonna üksikasjadest ja keerukusest. See meetod pakub põhimõtted, mustrid ja tavad, mis aitavad arendajatel oma tarkvaradisainis valdkonna kontseptsioone täpselt tabada ja esitada.
10. Disainipõhine arendus kasutab disaini osana protsessist, mille eesmärk on õppida ja paremini määratleda nõudeid, et luua paremaid ja teadlikumaid tehnoloogilisi lahendusi. Seda võib vaadelda ka kui protsessi, kus
disain ja kasutajakogemus juhivad toote või tarkvararakenduse arendamist. Kasu on sellest, et see viib toodeteni, mida inimesed naudivad ja millest nad tahavad teistele rääkida.
Joonis :
Agiilse arendusmudeli tähtsaim omadus on kohanemisvõime muudatustega, sest klientidel võivad tekkida uued soovid ning seda vajab palju resursse ning aega, et neid uued soove kohtleda.
| Head agiilses arendusmudelis: | Vead agiilses arendusmudelis: |
|---|---|
| Kohanemine muudatustega; | Ennustavuse puudulikkus; |
| Hea ressursside kasutamine; | Vähem dokumentatsioon; |
| Hea meeskonna koostöö; | Projekti lõpu puudumine; |
| Parem klientide rahulolu; | Raske mõõta progressi; |
| Rõhk tehnilisel tipptasemel. | Sõltuvus klientide kaasamisest. |
Agiilne arendusmudel: geeksforgeeks
CTDD: wikipedia
Andmetepõhine arendus (DDD): capicua
DOD: medium
SOD: techtarget
SbE: procognita
Domeenipõhine disain (DDD): geeksforgeeks
Disainipõhine arendus (DDD): prototypr
Head ja Vead: groovetechnology