1

Informacioni sistemi u saobradaju i komunikacijama PREDAVANJE 6.

Modeli agilnog razvoja

Agilne metode predstavljaju reakciju na probleme klasinih modela za razvoj softvera da brzo prezentuju

konkretne rezultate i odgovore na promjene. Agilni modeli razvoja informacionih sistema predstavlja

skup razliitih pristupa, metoda ili tehnika, koje su namijenjene za razliite problemske situacije i koje

nisu nuno nastale pod zajednikim uticajem ili kroz bio kakvu vrstu kooperacije.

U modele agilnog razvoja spadaju:

Extreme Programming (XP),

Adaptive Software Development (ASD),

Dynamic Systems Development Method (DSDM),

Scrum,

Crystal,

Agile Modeling (AM).

etiri kljune vrijednosti koje predstavljaju sutinu ovog pristupa su:

ljudi i interakcije prije nego procesi i alati,

softver koji radi prije nego sveobuhvatna dokumentacija,

kolaboracija sa klijentom prije nego pregovori o ugovoru,

odgovoriti na promjene prije nego pratiti plan.

Agilne metode su izgraene na osnovu iterativnog modela, adaptivne su i fleksibilne. Takoer, moe se

redi da su vie orjentisane ljudima nego procesima i da su u direktnoj komunikaciji sa korisnicima. Agilne

metode tee da smanje rizik kroz manje projekte. Osnovni nedostatak agilnog modela je neizvijesna

funkcionalnost cjeline.

Principi agilnog razvoja

Postoji veliki broj principa kod agilnog razvoja informacionog sistema, a neki od njih su:

Najvii prioritet je zadovoljavanje klijenta kroz ranu i kontinualnu isporuku korisnog softvera.

Promjene zahtjeva se prihvataju, ak i u kasnim fazama razvoja. Promjene se kontroliraju kroz

agilne procese, a u korist klijentove kompetitivne prednosti.

Funkcionalan softver treba isporuivati esto, u intervalima od par sedmica do par mjeseci, sa

preferencijom.

Oni koji razvijaju softver i poslovni ljudi moraju raditi zajedno svakodnevno tokom cijelog

trajanja projekta .

2

Projekti se grade oko motiviranih osoba kojima treba dati podrku, potrebno okruenje i

povjerenje.

Najefikasniji i najefektivniji metod prenosa informacija u i oko razvojnog tima je face-to-face

razgovor.

Primarno mjerilo napretka je funkcionalan softver.

Agilni procesi promoviraju odrivi razvoj; investitori, izvoai i korisnici treba da imaju stalan

ritam rada.

Stalna panja usmjerena na tehniku izvrsnost i dobar dizajn ojaava agilnost

Jednostavnost umjetnost maksimiziranja koliine rada koji ne treba uraditi je od esencijalne

vanosti.

Najbolje arhitekture, zahtjevi i dizajn pojavljuju se u samoorganizujudim timovima.

Tim mora u regularnim intervalima da razmatra kako da postane efektivniji i da u skladu s tim

koriguje i fino utimava svoje ponaanje.

Extreme Programming (XP)

Agilni model Ekstremno programiranje-Extreme Programming (XP) je nastao kao kolekcija ideja i prakse

iz ved postojedih metoda.

Slika. Ekstremno programiranje

Za XP model preporuuje se da se usvaja postepeno i da nije potrebno usvojiti sve njene principe i

tehnike. Ideja XP-a je da ne postoji jedan proces koji odgovara svim situacijama, nego da se skup

3

dostupnih principa i tehnika mora adaptirati svakoj od specifinih situacija. XP nije primjenjiva na sve

situacije, ali se njeni limiti danas jo ne mogu procijeniti.

Karakteristike XP modela su:

rapidni razvoj softvera uprkos stalno mijenjajudim zahtjevima je primarni cilj,

iteracije, mali release-ovi i brzi odziv, intenzivna participacija korisnika,

komunikacija i koordinacija,

kontinualna integracija i testiranje,

kolektivna odgovornost za kod,

limitirana dokumenatcija,

programiranje u paru,

XP je namijenjen malim i srednje velikim timovima,

zahtjeva agilnost poslovnog i tehnolokog razvojnog okruenja,

neagilnost i slaba participacija korisnika (iz bilo kojeg razloga) potpuno unitava XP filozofiju i ini

metodu neupotrebljivom.

ivotni ciklus XP modela sastoji se od est faza:

istraivanje,

planiranje,

iterativna realizacija,

produkcija,

odravanje i

terminacija projekta.

Projekt se realizuje inkrementalnoo i svaki inkrement prolazi kroz prvih pet faza. Prvi inkremenz sadri

funkcije koje su od najvee vanosti za naruioca i one se zatim dopunjujuu kroz naredne inkremente, do

finalnog rjeenja.

Istraivanje. U okviru faze istraivanja piu se zamisli koje se trebaju ukljuiti u projekt. U ovoj fazi tim se

upoznaje sa alatima, tehnologijom i procedurama koje de se koristiti u toku projekta i realizuje male

prototipove koji mu pomau da isproba pretpostavke o razliitim aspektima bududeg rjeenja.

Planiranje. Tokom faze planiranja projektni tim uz pomod korisnika analizira i procjenjuje vrijeme

potrebno za realizaciju projekta. Faza planiranja u prosjeku traje nekoliko dana.

Iterativna realizacija. Tokom ove faze vri se implementacija i testiranje.

Faza produkcije. Nakon faze interacije prelazi se u produkcionu fazu. Na poetku se vri dodatno

testiranje i optimizacija performansi. Ukoliko se ukae potreba za nekom izmjenom ili dodavanjem, tim

zajedno sa korisnikom odluuje da li de odmah izvriti izmjene ili de ostavii za narednu fazu.

Odravanje. Tokom faze odravanja potrebno je vriti izmjene na inkrementima koji su proli

produkcionu fazu, uz istovremeni rad na preostalim inkrementima.

4

Terminacija. Faza termincije nastupa kada se realizuju odabrane prie ili kada se projekt ne moe

nastaviti iz nekog razloga.

Nedostaci XP modela:

Nestabilni zahtjevi korisnika,

Nedostatak specifikacija i dokumenata,

Kompromisi usljed konflikta sa korisnikom nisu dokumentovani.

Adaptive Software Development (ASD)

Adaptivni razvoj softvera (Adaptive Software Develocupment - ASD) je metodologija bazirana na teoriji

kompleksnih adaptivnih sistema i namjenjena je za razvoj kompleksnih rjeenja, uz oslonac na

inkrementalni i iterativni razvoj kao i na evolutivne prototipove. Nasljednik je metodologije RADical

Software Development. ASD je koncipirana tako da obezbjedi okvir za balansiranje na ivici haosa,

odnosno da prui dovoljno smjernica koje treba da sprijee projekat da potone u haos, ali bez previe

detalja koji bi uguili kreativnost tokom razvoja. Cilj je da projektni tim dobije mogudnost kontinuirane

adaptacije na nove uslove koji neminovno nastaju kao posljedica interakcije velikog broja nezavisnih

agenata: korisnici, programeri, sponzori, akcionari, konkurentska preduzeda i sl. Poto je cilj realizovati

sistem koji je 24 sata potreban u datim okolnostima, a ne koji je dogovoren davno prije nego to su

promjene nastupile, striktno planiranje i pridravanje plana nije najbolje rjeenje. Umjesto klasinog

ciklusa razvoja baziranog na planiranju, projektovanju i realizaciji planiranog, ASD koristi iterativni ivotni

ciklus baziran na predvianju potreba korisnika (speculate), saradnji (collaborate) i uenju na bazi

realizovanog (learn).

Slika. Adaptivni ivotni ciklus

ASD ivotni ciklus posjeduje est osnovnih karakteristika:

usmjeren na misiju projekta,

orijentisan na realizaciju potrebnih funkcija softvera,

iterativan,

podjeljen u striktno vremenski ograniene cjeline,

voen rizikom,

tolerantan ka promjenama.

5

Slika. Faze adaptivnog ivotnog ciklusa

Predvianje (Speculate)

ASD umjesto rjei planiranje koristi rje predvianje, da bi se naglasila promjenjiva priroda

kompleksnog sistema koji se razvija i nemogudnost tanog spoznavanja svih njegovih aspekata u

poetnim fazama. Takoe, rije plan se izbjegava iz razloga to asocira na neto

nepromjenjivo, dok ASD promjene i adaptaciju na njih tretira kao nunost. Predvianje se sprovodi u

vie koraka.

Prvi korak je inicijalna faza projekta gdje se definiu misija i ciljevi projekta, otkrivaju ogranienja,

formira organizacija projekta, prikupljaju zahtjevi na visokom nivou, kreiraju procjene veliine projekta i

definiu glavni rizici.

Drugi korak je odreivanje vremenskog intervala potrebnog za realizaciju projekta na bazi definisanih

funkcija, raspoloivih resursa i procjena iz prethodnog koraka.

Tredi korak je definisanje broja iteracija i dodjela vremenskog intervala svakoj od njih. Vrijeme

dodjeljeno iteraciji je obino od etiri do osam nedjelja.

etvrti korak je definisanje teme svake iteracije, odnosno ciljeva koje mora zadovoljiti.

Peti korak je raspored funkcija po iteracijama.

Rezultat predvianja predstavlja tek okvirni plan razvoja. On se, sa stanovita funkcija koje je potrebno

realizovati, rafinira na poetku svake iteracije, na bazi steenih saznanja u prethodnom radu. Pri tome,

nije dozvoljena promena dogovorenog intervala za realizaciju projekta i pojedinanih iteracija, da bi se

svi uesnici prisilili da se fokusiraju na najvanije funkcije.

Saradnja (Collaborate)

U ambijentu razvoja visoko-promenljivih, kompleksnih sistema, gdje jedna osoba ne moe posjedovati

sve potrebne informacije, saradnja sa drugim ljudima predstavlja neminovnost. Potrebno je da postoji

6

saradnja izmeu svih inilaca razvojnog procesa: razvojnog tima, korisnika, spoljnih konsultanata,

naruioca i sl.

to je poslovni domen kompleksniji i broj uesnika vedi, potrebno je da se saradnja ostvaruje na

formalniji nain, uz pomod voe projekta i uz oslonac na razliite alate i tehnike. U sluaju manjeg

projekta gdje se razvoj odvija na jednoj lokaciji, saradnja se moe ostvarivati i neformalno, usputnim

daskanjem uesnika, diskusijama uz tablu za skiciranje i sl.

Uenje (Learn)

Tokom cjelokupnog trajanja projekta potrebno je da tim testira svoja tekuda saznanja i prikuplja nova, u

cilju dobijanja to je mogude kvalitetnijeg rjeenja za korisnika i minimiziranja greaka. Postojanje

greaka je neizbjeno, ali su greke manje ako se projekat dovoljno esto pretresa sa korisnicima i

unutar projektnog tima vre potrebne korekcije.

Na kraju svake iteracije (a moe i ede) se organizuju sesije namjenjene za sticanje slijededih saznanja:

kakav je kvalitet aplikacije sa stanovita korisnika

kakav je kvalitet aplikacije sa stanovita projektnog tima

da li je funkcionisanje projektnog tima zadovoljavajude sa stanovita koridenih

kakav je status projekta u odnosu na predvieno reenje

Na kraju projekta se vri zavrna analiza kvaliteta, organizuje se post-mortem sesija namjenjena za

sumiranje utisaka o projektu i aplikacija predaje u ruke korisnika.

Dynamic Systems Development Method (DSDM)

Metod za razvoj dinaminih sistema (Dynamic Systems Development Method -DSDM) je razvijen

sredinom 90-ih godina prolog vijeka od strane konzorcijuma formiranog od strane 16 kompanija.

Cilj konzorcijuma je bio realizacija i odravanje RAD (Rapid Application Development) metoda koji bi

postao industrijski standard. Postojedi RAD metodi su uglavnom bili nedovoljno strukturirani i podloni

razliitim interpretacijama.

DSDM je baziran na sljededim principima:

aktivno uede korisnika je imperativ razvoja,

DSDM tim mora posjedovati ovladenja da donosi odluke,

fokus razvoja je na estim isporukama (djelova) softvera,

osnovni kriterijum za prihvatanje realizovanog softvera je njegova primjenljivost u okviru

poslovnog domena,

iterativni i inkrementalni razvoj je neophodan radi konvergiranja ka odgovarajudem rjeenju,

sve promjene tokom razvoja moraju biti reverzibilne,

korisniki zahtjevi na najviem nivou, jednom dogovoreni, ne smiju se mjenjati,

7

testiranje je sastavni dio ivotnog ciklusa projekta,

neophodna je tijesna saradnja i kooperativnost svih uesnika.

ivotni ciklus DSDM projekta

DSDM metod podrava slijedede faze razvoja projekta:

studiju o izvodljivosti (Feasibility Study),

studiju poslovnog domena (Business Study),

iterativni razvoj funkcionalnog modela (Functional Model Iteration),

iterativno projektovanje i konstrukciju (Design and Build Iteration) i

implementaciju u realnom okruenju (instaliranje kod korisnika)

Slika. Faze DSDM projekta

Prve dvije faze se izvravaju samo jednom i koriste za pribavljanje informacija potrebnih za poetak razvoja softverskog proizvoda, dok se kroz preostale tri faze prolazi iterativno, na nain kako konkretni projektni tim procjeni da je najbolje. Razvoj se odvija u okviru vremenski ogranienih intervala (timebox) koji mogu trajati od nekoliko dana do najvie est nedjelja. U okviru jednog intervala moe se prodi kroz jednu ili vie razvojnih faza, u zavisnosti od definisanog cilja. Jednom planirani rok zavretka intervala se ne moe pomjerati, niti se mogu povedavati predvieni resursi. Ukoliko nema dovoljno vremena i resursa za realizaciju svih planiranih funkcija, rjeenje se trai u smanjenju broja realizovanih funkcija, pri emu se odbacuju funkcije sa manjim prioritetima. Odbaene funkcije se mogu realizovati u okviru novog DSDM projekta.

8

Studija o izvodljivosti

Studija o izvodljivosti se realizuje na poetku i koristi za procenu potencijalnih koristi i rizika koje dati

projekat moe donijeti preduzedu. Takoe, procjenjuje se da li se DSDM moe uspjeno primjeniti

na razmatrani problem. Realizacija studije o izvodljivosti traje najvie nekoliko nedjelja. Ukoliko se

pokae da su rizici vedi od potencijalne koristi ili da DSDM nije pogodan metod za razvoj, projekat se u

ovoj fazi prekida.

Studija poslovnog domena

Studija poslovnog domena predstavlja pripremnu fazu za realizaciju softverskog proizvoda u okviru koje

se vri:

definisanje okvira problemskog domena koji je u nadlenostiprojekta,

kreiranje liste zahtjeva sa definisanim prioritetima,

formiranje poetne arhitekture projekta,

kreiranje plana razvoja i definisanje strategije za upravljanje verzijama.

Lista zahtjeva na najviem nivou koja se definie u ovoj fazi je nepromjenjiva tokom trajanja

projekta, dok se arhitektura moe mjenjati u kasnijim fazama.

Iterativni razvoj funkcionalnog modela

Namjena realizacije funkcionalnog modela je prikupljanje detaljnih zahtjeva u okviru funkcionalnih

prototipova, umjesto u okviru klasinih specifikacionih dokumenata, kao i dalji razvoj potrebnih

modela. Funkcionalni prototipovi imaju dvije namjene:

postizanje boljeg razumjevanja izmeu projektnog tima i korisnika, to rezultuje

kvalitetnijom analizom zahtjeva

koriste se kao ulaz za narednu fazu, gdje se dodavanjem potrebne funkcionalnosti prevode u

finalno rjeenje (dio rjeenja).

Podloga za prikupljanje detaljnih zahtjeva je lista zahtjeva na najviem nivou definisana tokom studije

poslovnog domena. Detaljni zahtjevi se mogu mjenjati u toku projekta.

Iterativno projektovanje i konstrukcija

U okviru ove faze se nastavlja razvoj uz oslonac na evolutivne prototipove, dok ne prerastu u

finalni proizvod (dio finalnog proizvoda). DSDM ne propisuje koridenje nikakvih posebnih tehnika i

alata, mada se implicitno podrazumjeva da je potrebno koristiti neki alat koji omogudava brz razvoj

prototipova, da korisnici koji uestvuju ne bi izgubili interesovanje. Podrazumjeva se da se testiranje

sprovodi sve vrijeme, pri emu se takoe ne propisuju nikakve odreene tehnike projektni tim

sam definie svoju strategiju testiranja.

9

Implementacija u realnom okruenju

U okviru ove faze se vri instaliranje rjeenja u okviru preduzeda, izrada korisnikih uputstava i

obuka korisnika. U zavisnosti od prirode problema, ova faza se moe sprovoditi iterativno, tokom

cjelog trajanja projekta ili jednom, na njegovom kraju.

SCRUM

Scrum metodologija predstavlja najpopularniju agilnu metodologiju u razvoju softvera.

Scrum je metodologija koja poseban akcenat stavlja na upravljanje razvojnim procesom, bazirana na

idejama empirijskog modela kontrole proizvodnih procesa. Empirijski model kontrole se primjenjuje na

procese sa velikim stepenom neodreenosti, a upravljanje se sprovodi uz kontinuirano pradenje i brzo

prilagoavanje procesa u skladu sa dobijenim rezultatima i eljenim izlazima. Scrum predstavlja nain

rada za timove da rade zajedno kako bi razvili proizvod. Tanije Scrum predstavlja jednostavan okvir za

timsku saradnju na sloenim projektima. Scrum nudi mali skup pravila koja nude timovima dovoljno

mogudnosti da se usmjere na svoje inovacije i na rjeavanje onoga to bi mogao biti nepremostiv izazov.

Dakle, Scrum je okvir (eng. framework) metodologije razvojnog procesa koji se koristi za upravljanje

kompleksnim razvojem. Scrum ne definira detalje procesa, ved daje okvir unutar kojega tim stvara

proces prilagoen sebi, odnosno proces ija je karakteristika konstantno usavravanje i prilagodba timu

koji ga provodi.

Meutim, Scrum je i mnogo vie od jednostavnog okvira. On podrava nau potrebu da se bude ovjek

na poslu da pripada, ui, radi, stvara i bude kreativan i da bude u interakciji sa drugim ljudima. Drugim

rijeima, Scrum iskoritava uroene osobine i karakteristike u ljudima kako bi uiniti velike stvari

zajedno, tj. Scrum je utemeljen na tvrdnjama da znanje dolazi iz iskustva. Izgraditi sloene proizvode za

kupce je teak zadatak, meutim Scrum daje strukturu kako bi se timovi nosili sa tim tekodama Scrum

je jednostavan, lahko razumljiv i vrst razvojni proces te je fokusiran na bitne funkcionalnosti koje je

razvojni tim procijenio da se mogu implementirati. Vaan dio metodologije je komunikacija na

svakodnevnim sastancima na kojima se rjeavaju tekudi problemi i daju obedanja ta de se napraviti do

sljededeg sastanka ime se stvara povjerenje izmeu lanova tima (poslovni analitiari, programeri,

testeri...). Rezultat ovakvog pristupa jesu zadovoljni lanovi tima to za posljedicu daje kvalitetniji i bri

razvoj, a samim tim su zadovoljni naruitelji i korisnici programskog proizvoda.

Prednosti Scrum metodologije:

uteda vremena i novca,

poboljavanje produktivnosti kako individualnog tako i timskog rada,

organizacijom dnevnih Scrum sastanaka dovodi se do lahkog identifikovanja problema i brzog

rjeavanja istih,

jasna vidljivost projekta,

update(auriranje) na dnevnom nivou,

flexibilnost Sprint procesa omogudava uvijek spremnu demo verziju proizvoda.

10

Nedostaci Scrum metodologije:

Scrum metodologija zahtjeva lanove koji moraju biti individualno sposobni a poeljno experti u

svom podruju.

Pogodniji je za manje projekte jer za manje projekte su zadueni manji timovi koji imaju bolju

koordinaciju.

Zahtjeva definiran problem(zadatak).

Odluke donosi tim to jeste prednost ali ako tim nije organizovan moe dovesti do zastoja.

Temeljni program je veoma jednostavan i sadri tri temeljne uloge:

Proizvod Vlasnici odreuje ta treba biti ugraeno u narednih 30 dana ili manje.

Proizvodni timovi grade ono to je potrebno u 30 dana ili manje, a zatim prikazuju ono to su

izgradili. Na temelju ove demonstracije, vlasnik proizvoda odreuje ta graditi idude.

Scrum Masters omoguava da se taj proces odvija to jednostavnije, konstantno pomae

unapreenju procesa kako bi stvorio eljeni proizvod.

Slika. Scrum proces

Scrum proces

Od svih agilnih metoda i praksi najzastupljeniji je Scrum. Mali razvojni tim koji ima sva potrebna znanja

za analizu, kodiranje i test proizvoda u kratkim de ga iteracijama (sprint do 4 tjedna) razvijati dio po dio,

tako da se svaki sljededi inkrementalno nadograuje na onaj iz prethodne iteracije. Koliinu posla koju

tim moe obaviti u jednom sprintu odreuju sami lanovi, dakle posao se ne gura u tim, nego ga tim

vue (pull nasuprot push). Dnevno na kratkom sastanku (Daily Standup) tim prati ostvarenje zacrtanog

plana za taj sprint.

Nakon svake iteracije tim usavrava proces uedi retrospektivno iz iskustva protekle iteracije za to je

odvojeno posebno vrijeme. Progres prema konanom rjeenju uvijek je mjerljiv kodom koji je spreman

za potencijalnu isporuku, dakle proao je test i dovoljno je dokumentiran. Sustav je fleksibilan na

promjene zahtjeva kupaca jer u svakoj iteraciji tim radi na zahtjevima najvieg prioriteta u tom trenutku,

a sam kupac stalno i transparentno prati razvoj te daje timu povratnu informaciju na temelju

11

demonstriranog dijela, dakle dogovaraju rjeenje u kolaboraciji. To je posebno bitno jer kupac najede

dugo nije siguran kako de najbolje dodi do rjeenja svog problema.Kako bi ovako postavljen sistem

funkcionirao treba zadovoljiti neke temeljne pretpostavke. Scrum tim, dakle ljudi koji su najblii

proizvodnji vrijednosti za kupca i odgovorni su za razvoj proizvoda, moraju imati povjerenje, slobodu i

neometane uvjete da naprave posao. Tim radi u zajednikom prostoru i stalno uklanja ili poboljava

elemente koji ga usporavaju u radu. Takoer ima slobodu odabira naina i alata kojima de dodi do

rjeenja na najbolji nain.

ivotni ciklus Scrum projekta

ivotni ciklus Scrum projekta se sastoji od tri faze: pripreme (pre-game), razvoja i zakljuenja (post-

game). Faza pripreme se sastoji od dvije podfaze: planiranja i skiciranja arhitekture. U okviru potfaze

planiranja se vri: formiranje projektnog tima, definisanje potrebnih resursa neophodnih za poetak

razvoja, definisanje inicijalne liste zahtijeva i pribavljanje odobrenja uprave za poetak projekta.

Lista zahtijeva se formira prikupljanjem zahtijeva raspoloivih u datom trenutku od strane svih

zainteresovanih za bududnost proizvoda: direktnih korisnika, uprave, odjeljenja prodaje i marketing,

odjeljenja za pruanje podrke korisniciama, lanova razvojnog tima. Lista se aurira iskljuivo od strane

vlasnika liste. Projektni tim je duan vlasniku liste obezbijediti procjene vremena potrebnog za realizaciju

pojedinanih zahtjeva.

U okviru potfaze skiciranja arhitekture, vri se projektovanje u grubim crtama arhitekture bududeg

rijeenja na osnovu trenutnog sadraja liste zahtijeva i formiraju se preliminarni planovi za realizaciju

inkrementa u okviru razvojne faze.

Razvoj se realizuje u inkrementima od 30 dana, koji u okviru Scruma nose naziv sprint. Sprint poinje

sastankom u kome se definie njegov cilj i iz liste zahtjeva se vri izbor aktivnosti predvienih za

realizaciju u narednih trideset dana. Tokom sprinta, svakog dana se odrava po jedan sastanak u trajanju

od petnaest minuta, iji je cilj da se utvrdi stanje projekta, pomogne komunikacija u okviru tima i otklone

eventualne prepreke. Svaki lan tima bi trebalo da odgovori na tri pitanja: ta je uradio od prethodnog

sastanka, ta namerava da uradi do slededeg sastanka i da li postoje neke prepreke (bilo kakve vrste)

koje ga spreavaju da uradi planirano.

Posljednjeg dana sprinta organizuje se sastanak svih zainteresovanih strana na kome se prezentira

razvijeni inkrement softvera i odluuje o narednim potezima. Ovaj sastanak se koristi kao kontrolna

taka gdje sve zainteresovane strane imaju priliku da unaprijede svoje znanje, zahvaljujudi emu se u

hodu mogu redefinisati planovi i spreiti troenje energije na nepotrebne aktivnosti.

Zakljuna faza poinje kada se iscrpi lista zahtijeva i postigne saglasnost da je softver spreman za

instalaciju. U toku nje se vre zavrne integracije, testiranje i dokumentovanje i softver predaje

korisnicima. Scrum se zbog oslonca na neposrednu komunikaciju i adaptaciju u hodu moe efikasno

primenjivati u okviru malih timova od 5 do 9 lanova.

Proces razvoja programskog proizvoda provodi se kroz tri faze:

12

prije igre (planiranje, dizajn/arhitektura visoka razina apstrakcije),

igra (razvoj, sprintovi iterativni ciklusi, poboljanja, nove verzije),

poslije igre (nema novih zahtjeva, sustav spreman za produkciju).

Slika. Scrum proces

Karakteristike

Scrum framework se sastoji od Scrum timova, njihovih pridruenih uloga, dogaaja, artefakata i pravila.

Slika 3. Karakteristike Scrum modela

Scrum tim: Scrum tim se sastoji od vlasnika proizvoda, razvojnog tima i Scrum mastera.

Slika 4. Scrum tim

13

Dogaaji u Scrumu: Scrum koristi dogaaje tako da svaki vremenski dogaaj ima odreeno maksimalno

trajanje. Na ovaj nain se osigura dovoljno vremena za planiranje bez bespotrebnog troenja vremena.

Sprint: Sprint ili iteracija je bazna jedinica razvojnog procesa Scruma. Sprint je ograniena jedinica

vremenom u trajanju izmeu jedne sedmice i jednog mjeseca. Tokom sprinta se proizvede zavren,

upotrebljiv inkrement proizvoda. Za vrijeme trajanja sprinta se svakodnevno prati napredak. Novi sprint

poinje neposredno nakon to se zavri prethodni. Sprint se sastoji od: Sastanaka za planiranje Sprinta,

dnevnog Scruma(Daily Scrum) i revizije Sprinta.

Dnevni Scrum (Daily Scrum ili Stand up meeting)

Dnevni Scrum je 15-minutni sastanak iji je cilj usklaivanja aktivnosti i donoenja plana za sljededa 24

sata. Mjesto odravanja dnevnog scruma je uvijek isto. Ovi sastanci moraju poinjati u isto vrijeme i na

istom mjestu. lanovi tima za vrijeme sastanka stoje, odatle naziv Stand up meeting. Tokom dnevnog

Scruma svaki lan tima treba da odgovori na tri pitanja:

ta je napravljeno od juer?

ta de se uraditi danas?

Postoje li problem koji spreavaju izvrenje zadatka?

Ako postoje problemi koji spreavaju izvrenje zadatka oni su dokumentovani od strane Scrum mastera.

Njihovo rjeavanje se deava izvan ovog sastanka.

Zavrni sastanci: Na kraju sprint ciklusa odravaju se dva sastanka: Sprint review meeting (pregled

Sprinta) i Sprint retrospective(Sprint retrospektiva). Na sastanku pregleda Sprinta se pregledava zavreni

posao i planirani posao koji jo nije zavren. Prezentuje se zavreni rad Stakeholderima. Nezavreni rad

nede biti prezentovan. Trajanje ovog sastanka je maximalno 4 sata. Na sastaku Sprint retrospektive svi

lanovi tima oscrdu se na prethodni sprint. Dva glavna pitanja se postavljaju na ovom sastanku: ta je

dobro uraeno u Sprintu? ta se moe poboljati u sljededem Sprintu. Trajanje ovog sastanka je

maximalno 3 sata.

Artefakti (lista zahtjeva i dokumenata) u Scrumu:

Product Backlog (zaliha proizvoda) je lista zahtjeva koji de biti potrebni za proizvod. Vlasnik proizvoda je

odgovoran za Product Backlog. Koja stavka de ui u sprint odreuje se tokom Sprint sastanka planiranja.

Tokom ovog sastanka vlasnik proizvoda informira tim o pojedinostima, ukljuujudi njegov sadraj,

raspoloivost i sortiranje u Product backlog za koje eli da budu kompletirani. Tim odreuje koliko ovoga

se moe uraditi tokomsljededeg sprinta. Product backlog nikad nije konaan.

Sprint Backlog je lista poslovnih i tehnologijskih svojstava, poboljanja i nedostataka koji su rasporeeni

u trenutni Sprint. Sprint Backlog je vlasnitvo razvojnog tima. Task board je ploa sa zadacima koja slui

za laki pregled i mijenjanje trenutnih zadataka u Sprintu. Sprint backlog je plan sa dovoljno detalja da bi

se na Dnevnom Scrumu mogle razumjeti aktualne promjene.

14

Crystal

to je projekat kritiniji i broj uesnika vedi, potrebno je koristiti teu metodologiju koja podrazumijeva

formalniju komunikaciju i oslanja se na vie artefakata razvoja. Manje kritini projekti i mali timovi mogu

koristiti laku metodologiju koja se oslanja na mali broj artefakata i direktnu komunikaciju, ime se

postie izuzetno brz razvoj.

Metodologije, od lakih ka teim respektivno, nose naziv: Crystal Clear, Yellow, Orange, Orange

Web, Red, Magenta i Blue. Konkretne tehnike zavise od metodologije koja se koristi, pri emu su do sada

u potpunosti definisane i isprobane samo Crystal Clear i Crystal Orange. Crystal Orange Web je trenutno

u fazi verifikacije.

Crystal Clear

Crystal Clear je najlaka iz familije Crystal metodologija, namenjena za timove do est ljudi koji rade na

manje kritinim projektima.

Principi na kojima je baziran Crystal Clear su:

softver se razvija u inkrementima koji traju dva do tri meseca,

razvoj se meri na osnovu razvijenih inkremenata softvera koji rade, a ne na osnovu pisanih

dokumenata,

korisnici su direktno ukljueni u razvoj,

postoje bar dva vienja sa korisnicima u toku razvoja inkrementa,

na poetku i u sredini svakog inkrementa se odravaju radionice ija je namena bolje

prilagoavanje metodologije potrebama tima i bolje prilagoavanje softvera koji se razvija

potrebama korisnika.

U toku projekta, potrebno je realizovati:

redoslijed razvoja inkremenata,

raspored vienja sa korisnicima i raspored realizacije inkremenata,

opis potrebnih funkcija ili dijagram sluajeva koritenja sa komentarima,

skice dizajna sa komentarima, ukoliko su potrebni,

zajedniki objektni model,

programski kod kojim se implementiraju traene funkcije,

programski kod za migraciju softvera,

ako je potrebno testove,

uputstvo za koritenje.

Crystal Orange

Crystal Orange je metodologija namenjena za timove do etrdeset ljudi koji rade na manje kritinim

projektima.

15

Radi lakeg upravljanja, tim je potrebno podijeliti u manje pod-timove od kojih svaki posjeduje sistem-

analitiara, dizajnera korisnikog interfejsa, projektanta baze podataka, nekoliko projektanata-

programera i strunjaka za svaku tehnologiju koja se koristi na projektu.

U toku projekta je potrebno realizovati:

analizu zahtjeva,

redoslijed razvoja inkremenata,

plan rada,

izvjetaje o statusu projekta,

dizajn korisnikog interfejsa,

zajedniki objektni model,

specifikacije potrebne za rad ostalih pod-timova,

programski kod kojim se implementiraju traene funkcije,

programski kod za migraciju softvera,

ako je potrebno testove,

uputstvo za koritenje.

Crystal familija metodologija posjeduje dva bitna ogranienja:

zbog insistiranja na direktnoj komunikaciji, moe se primjenjivati samo u okviru timova koji se

nalaze na istoj lokaciji,

do sada su u potpunosti definisani Crystal Clear i Crystal Orange koji imaju podrku samo za

manje kritine projekte.

Razvoj baziran na korisnikim funkcijama

Razvoj baziran na korisnikim funkcijama (Feature Driven Development - FDD) je metodologija

definisana na bazi iskustava u okviru sloenog projekta realizovanog za Singapursku banku koji su

predvodili Def Luka (Jeff Luca) i Piter Kod (Peter Coad).

FDD se ne bavi cijelokupnim ivotnim ciklusom softverskog proizvoda, ved se koncentrie na faze

projektovanja i konstrukcije koje se tako organizuju da se u to je mogude kradem vremenu krene sa

realizacijom malih, zaokruenih funkcija izolovanih u okviru problemskog domena. Ove funkcije se tako

biraju da svaka od njih ima prepoznatljiv doprinos za korisnika i da njihova realizacija ne traje due od

dvije nedjelje.

ivotni ciklus FDD projekta

Realizacija projekta primjenom FDD metodologije se sastoji od pet faza:

razvoj celokupnog modela,

realizacija liste potrebnih funkcija,

planiranje realizacije funkcija,

16

detaljno projektovanje i

konstrukcija uoenih funkcija.

Razvoj celokupnog modela - cilj ove faze je realizacija dijagrama klasa koji u grubim crtama modeluje

razmatrani poslovni domen u cijelini. U razvoju uestvuju lanovi tima i eksperti za poslovni domen,

najede iz redova krajnjih korisnika i naruioca softvera.

Pre poetka razvoja modela, podrazumijeva se da postoji inicijalni skup zahtijeva koji se postavljaju pred

bududi sistem i da su eksperti za poslovni domen upoznati sa njima. FDD ne posjeduje podrku za

prikupljanje zahtijeva, niti propisuje njihovu formu.

Razvoj modela se vri tako to eksperti za poslovni domen organizuju prolaske u formi tutorijala kroz

razmatrani domen za lanove tima, prvo u grubim crtama a zatim sa sve vie i vie detalja, kako model

napreduje. Rad na modelu se tako organizuje da ne traje previe dugo. Cilj je da model omogudi

sagledavanje razmatranog poslovnog domena u cijelini, pri emu se podrazumijeva se da de biti izmjena

tokom narednih faza. Teite se stavlja na modelovanje klasa i njihovih veza, mada se mogu ukljuiti i

uoene metode i atributi.

Realizacija liste potrebnih funkcija - u okviru ove faze se na bazi inicijalnog skupa zahtijeva, izolovanih

metoda cijelokupnog modela, neformalne liste funkcija i informacija preuzetih od eksperta za poslovni

domen formira zvanina lista potrebnih funkcija novog sistema.

Funkcije se na osnovu pripadnost i oblastima u okviru poslovnog domena grupiu u glavne skupove

funkcija, a u okviru njih na manje skupove funkcija prema pripadnosti odreenim aktivnostima u okviru

oblasti. Funkcije za koje se procijeni da se ne mogu realizovati za dvije nedelje se dekomponuju na

manje segmente.

Planiranje realizacije funkcija - na osnovu detaljne liste kreirane u prethodnoj fazi, formira se plan koji

treba da sadri sljedede informacije:

predvieni datum realizacije za svaki glavni skup funkcija,

predvieni datum realizacije za svaki pomodni skup funkcija, sa imenom glavnog programera

kome je poveren razvoj datog skupa,

definisane vlasnike klasa za sve klase iz cijelovitog modela koje se koriste za realizaciju

planiranih funkcija.

Za razliku od vedine agilnih metodologija kod kojih je programski kd zajedniko vlasnitvo koje svi

lanovi tima mogu da mijenjaju, u okviru FDD metodologije se za svaku klasu definie njen vlasnik, koji je

realizuje i odrava tokom trajanja projekta. Jedan programer u odreenom trenutku moe boraviti u vie

privremenih pod-timova. Glavni programeri su u potpunosti odgovorni za realizaciju dodijeljenih

funkcija, tako da imaju pravo da nametnu svoja rjeenja u sluaju potrebe. Oni se nalaze pod upravom

glavnog arhitekte.

17

Detaljno projektovanje i konstrukcija uoenih funkcija - po okonanju faze planiranja, glavni programeri

poinju sa realizacijom, koja za svaku funkciju iz dodjeljenog skupa podrazumijeva: formiranje

privremenog pod-tima, detaljno projektovanje i konstrukciju.

Projektovanje funkcije ukljuuje sledede korake:

prolazak kroz detalje date funkcije sa ekspertom za poslovni domen,

ukoliko je to potrebno analizu raspoloivih dokumenata (ako postoje),

realizaciju detaljnog dijagrama sekvenci,

auriranje cjelovitog dijagrama klasa (najede se vri dodavanje novih metoda, parametara

metoda i atributa, kao posljedica boljeg sagledavanja dijela poslovnog domena koji odgovara

datoj funkciji),

inspekciju od strane privremenog pod-tima, a po potrebi i od strane spoljnih uesnika,

dokumentovanje projektantskih odluka.

Konstrukcija funkcije koja se sprovodi neposredno po zavretku njenog detaljnog projektovanja,

podrazumijeva:

implementaciju potrebnih klasa i realizaciju jedininih testova od strane njihovih vlasnika,

inspekciju kda pod vostvom glavnog programera u kojoj uestvuje cijeli privremeni tim,

integraciju realizovanih klasa i testiranje funkcije u cjelini od strane glavnog programera,

unos realizovanih klasa i testova u sistem za upravljanje verzijama,

dokumentovanje reenja.

Autori FDD-a smatraju da nema ogranienja za primjenu ove metodologije.

Slika. FDD proces

Agilno modelovanje (AM)

Agilno modelovanje (Agile Modeling - AM) nije metod koji podrava cjelokupni ivotni ciklus softvera,

ved se bavi iskljuivo tehnikama za realizaciju modela i dokumentacije u agilnom maniru. U skladu sa

tim, moe se primjenjivati u okviru bilo koje druge metodologije, agilne ili ne.

18

Vrijednosti na kojima je baziran AM se poklapaju sa vrijednostima XP-a : komunikacija, jednostavnost,

povratna sprega od strane korisnika i hrabrost, pri emu AM posjeduje i jednu dodatnu: skromnost.

Skromnost je potrebna da bi osoba koja modeluje bila u stanju da uvai tue miljenje, odnosno da

shvati da svako moe na neki nain doprinjeti projektu.

Osnovni principi na kojima je AM baziran su:

Softver koji zadovoljava potrebe korisnika je primarni cilj projekta (a ne lijepi modeli,

dokumentacija, izvetaji o statusu i sl,).

Priprema za period koji slijedi je drugi po vanosti cilj projekta (tj. ako projekat nije dovoljno

robustan za odravanje, moe predstavljati neuspjeh iako je uspjeno doveden do kraja).

Minimalno opteredivati projekat dodatnim artefaktima (tj. kreirati onoliko modela i

dokumentacije koliko je minimalno potrebno za rad).

Pretpostaviti da je najjednostavnije rjeenje najbolje rjeenje.

Prihvatiti da su promjene neminovne.

Razvijati sistem inkrementalno, po jedan manji deo u jedinici vremena, umjesto pokuati da se

sve odradi odjednom.

Modelovati sa svrhom, tj. ne kreirati modele radi njih samih.

Koristiti razliite vrste modela (softver je suvie kompleksan da bi samo jedna vrsta modela u

potpunosti mogla da ga opie).

Raditi kvalitetno (proizvodi od trajnog znaaja moraju biti kvalitetno realizovani)

Naruiocu pruiti najbolje za njegov novac.

Dodatni principi AM-a su:

sadraj (modela) je mnogo bitniji od njegove reprezentacije (tj. nisu neophodni CASE alati za

modelovanje, esto su dovoljni papir i olovka ili tabla i flomaster),

svako od svakoga moe neto nauiti,

dobro poznavati dobre i loe strane razliitih vrsta modela (nisu sve vrste modela podjednako

dobre za sve primjene),

AM se moe prilagoavati eljenom okruenju,

postidi iskrenu i otvorenu komunikaciju na projektu,

omoguditi brzu povratnu spregu gde god je to mogude,

+slijediti svoj instinkt.

Osnovne tehnike koje se koriste u okviru AM-a su:

Aktivno uede korisnika (stakeholder), od kojih u znaajnoj meri zavisi uspjeh projekta.

Primjena odgovarajudih vrsta modela za odreenu primjenu.

Zajedniko vlasnitvo nad modelima (svako ima pravo da promjeni bilo koji model ili dokument

za koji smatra da je to potrebno).

Paralelna realizacija vie vrsta modela u jedinici vremena.

19

Kreiranje jednostavnih rjeenja, odnosno uzdravanje od modelovanja dodatnih aspekata

sistema do trenutka kada zaista budu potrebni.

Kreiranje svedenih modela, odnosno koridenje podskupa raspoloivih notacija radi realizacije

jednostavnih dijagrama koji ilustruju samo kljune aspekte sistema koje je potrebno razumjeti

Dostupnost modela svim lanovima tima (na zidu, oglasnoj tabli, web-u i sl).

Prelazak na drugu vrstu modela kada se primjeti da sa tekudom vrstom postoje problemi da se

neki aspekt sistema opie.

Modelovanje u malim inkrementima (malo modelovati, pa zatim to programirati, testirati i

prikazati korisniku radi dobijanja povratnih informacija).

Modelovanje sa drugima, radi postizanja boljeg rjeenja (opasno je modelovati sam!)

Dokazivanje ispravnosti modela programskim kodom.

Pohranjivanje informacija na jednom i samo jednom mjestu (tj. izbor najadekvatnijeg artefekata

za smjetanje neke informacije: model, dokument ili programski kod i izbjegavanje njenog

prepisivanja u vie dokumenata. Ovim se izbjegava potreba da se vie dokumenata moraju

aurirati ako do promjene doe).

Koristiti najjednostavnije mogude alate za modelovanje koji odgovaraju datoj primjeni (papir i

olovku, tablu i flomaster, pa ak i CASE alate ako mogu biti od koristi).

Dodatne tehnike su:

Usvajanje i primjena standarda u modelovanju na nivou cijelog tima.

Primjena gotovih ablona u modelovanju (design patterns) samo kada je to neophodno (poto

pretjerana primjena komplikuje model i programski kod).

Odbacivanje privremenih (radnih) modela u trenutku kada vie nemaju znaaja za projekat (radi

smanjivanja prtljaga koji projekat nosi sa sobom).

Formalizacija modela koji se koriste za opis resursa koje kontrolie neki drugi tim (npr. postojeda

baza podataka na koju se naslanja tekudi projekat).

Auriranje modela samo kada gori (nije neophodno mjenjati model svaki put kada programski

kod odstupi od njega, sve dok on dovoljno dobro komunicira odreenu ideju. Izmjena modela

troi resurse tima).

U okviru AM-a preporuka je da sesije za razvoj modela traju to je mogude krade. Tokom poetne faze

projekta dozvoljeno je potroiti od nekoliko sati do nekoliko dana za prikupljanje osnovnih korisnikih

zahtjeva i kreiranje kostura arhitekture . Smatra se da sve preko ovoga dovodi projekat u opasnost zbog

nedostatka povratnih informacija na neto to radi. U okviru implementacione faze, preporuka je da

sesije za modelovanje traju od 10 do 20 minuta, koliko je potrebno da se skicira model nekog segmenta

problema, posle ega se odmah prelazi na njegovu implementaciju. Implementacija obino traje

nekoliko sati ili dana. U okviru sesija za modelovanje uestvuju lanovi tima i korisnici koji obezbeuju

informacije. Preporuka je da ne postoje ekskluzivni specijalisti iji je posao iskljuivo izrada modela, ved

da svi uestvuju i u realizaciji programskog koda (tj. da svi budu specijalisti opte prakse).

20

Slika. Realizacija projekta uz oslonac na agilni razvoj baziran na modelima

Razvoj se moe realizovati:

runo, bez alata za modelovanje i generisanje koda (procjena je da oko 70% do 80% timova radi

na ovaj nain),

kombinovanjem rune realizacije i sofisticiranih alata za modelovanje i generisanje dijela

programskog koda (10% do 20% timova) i

koridenjem MDA (Model Driven Architecture) alata koji u potpunosti generiu programski kod

na osnovu modela (5% do 10% u najboljem sluaju), pri emu se smatra da poslovni softver nije

pogodan za ovaj nain realizacije.

Prednosti i nedostaci agilnog modeliranja

Za razliku od klasinih metodologija koje svojim detaljno definisanim procesima i obimnom

dokumentacijom pokuavaju da izbjegnu zavisnost od uesnika projekta, agilne metodologije smatraju

da su ljudi, nezavisno od procesa, osnovni inioci uspjeha ili neuspjeha U skladu sa tim, agilne

metodologije pokuavaju da pomognu lanovima tima da daju svoj puni doprinos, insistiranjem na

neposrednoj komunikaciji, drueljubivosti, timskom radu, smanjivanju ceremonije i kreativnom pristupu

reavanju problema. Zahvaljujudi svojim principima i vrijednostima, agilne metodologije su za relativno

kratko vrijeme doivjele popularnost. Postoji niz publikovanih prikaza projekata iz industrijskog i

akademskog okruenja koji ilustruju povedanje brzine rada, smanjenje greaka i povedano zadovoljstvo

kako korisnika tako i lanova tima. Prema studija sprovedena u okviru 32 organizacije koje primjenjuju

agilne metodologije, dala je sledede rezultate:

21

povedanje produktivnosti od 15% do 23% u odnosu na publikovani prosjek za datu oblast,

smanjenje trokova za 5% do 7% u odnosu na publikovani prosjek za datu oblast,

smanjenje vremena potrebnog za realizaciju proizvoda od 25% do 50% u odnosu na prethodne

projekte realizovane bez primjene agilnih metodologija,

nepromjenjen kvalitet u 5 firmi (ostali nisu imali potrebne podatke).

Protivnici smatraju da su agilne metodologije (a prije svega XP) zapravo poziv na ad-hoc razvoj bez

discipline, reda i plana, bez modelovanja, bez rada na arhitekturi. Autori agilnih metodologija odgovaraju

da zbog akcenta na testiranju, vidljivosti rezultata i stalnom poboljanju programskog koda (refactoring)

definitivno nije tano da nema discipline, a modelovanje i realizacija arhitekture su kontinuirane

aktivnosti koje se odvijaju tokom cjelokupnog trajanja projekta, a ne iskljuivo na njegovom poetku.

Takoe, iroko je rasprostranjeno miljenje da agilne metodologije bez dodatnih proirenja nisu

skalabilne na velike projekte, uprkos nekolicini pojedinanih primjera koji pokazuju suprotno.Sa ovim se

slae i vedina autora agilnih metodologija. Na sastanku posvedenom primjeni agilnih metodologija na

vede projekte i timove predloene su sledede tehnike:

posvetiti neko vreme definisanju arhitekture na poetku projekta,

formirati vie manjih pod-timova i svakodnevno ih sinhronizovati uz pomod njihovih voa

(koncept preuzet iz Scrum-a),

formirati federaciju korisnika koji uestvuju u projektu, da bi mogli da pokriju vie pod-timova i

iri problemski domen,

angaovati analitiara sa dobrim poznavanjem poslovnog domena koji moe posluiti kao sprega

izmeu projektnog tima i korisnika,

koristiti kombinaciju agilnih i klasinih tehnika (u ovom delu se posebno istie rad Bari Bema

(Barry Boehm).

Bari Bem smatra da se za svaki projekat na osnovu njegovih karakteristika moe odrediti kombinacija

agilnih i klasinih tehnika (sa teitem na jednoj ili drugoj strani) i da se na taj nain mogu prevazidi

nedostaci oba pristupa. Karakteristike koje se razmatraju su: dinaminost projekta (sa stanovita

uestalosti izmene zahtjeva), kritinost projekta (sa stanovita gubitaka usljed greke u softveru),

veliina tima, kvalitet lanova tima i korporativna kultura (bazirana na haosu ili na disciplini) . Primeri

uspjenog kombinovanja agilnih i klasinih metoda mogu se nadi u okviru

Problem koji i zagovornici i protivnici agilnih metodologija imaju je to jo uvijek ne postoji dovoljan broj

zaista detaljnih i rigorozno sprovedenih studija koje bi potkrijepile njihove stavove. Posebno je teko u

redovima agilne zajednice uopte nadi podatke da neto od predloenih tehnika ne radi u praksi. Ukoliko

se i prijavi neki neuspjeh, uglavnom se za njega ne krive koridene agilne metodologije, ved projektni tim

koji se nije pridravao neke od preporuenih tehnika (posebno esto kod XP-a). Meutim, postoje i neke

slabe take. Naime, vedina agilnih metodologija vie daje smernice nego konkretno uputstvo za

realizaciju projekta; tim koji je nov u ovoj oblasti esto ima potekode ukoliko ne posjeduje bar jednog

lana sa iskustvom u izabranoj metodologiji. Takoer, potrebno je znatno vie kvalitetnih lanova tima

nego kod klasinih.

Modeli agilnog razvojaPrincipi agilnog razvojaExtreme Programming (XP)Adaptive Software Development (ASD)Predvianje (Speculate)

Dynamic Systems Development Method (DSDM)ivotni ciklus DSDM projekta

SCRUMCrystalRazvoj baziran na korisnikim funkcijamaAgilno modelovanje (AM)Prednosti i nedostaci agilnog modeliranja