FAKULTET POLITEHNIKIH NAUKA

Agilni razvoj programskih proizvoda

Seminarski rad

Student: Alen Durakovi, PT-24/13-I

Kolegij: Razvoj programskih proizvoda
Profesor: Prof.dr Halid igi
Akademska godina: 2014/2015

Travnik, Januar 2015

Sadraj

1.

Uvod................................................................................................................. 3

2.

Nastanak agilnih metoda................................................................................. 4

3.

ta je agilno programiranje ?...........................................................................5

4.

Usporedba sa drugim tipovima metoda razvoja programske podrke..............6

5.

4.1.

Usporedba s iterativnim razvojem.............................................................6

4.2.

Usporedba s vodopadnim modelom...........................................................7

Agilne metode razvoja programskih proizvoda................................................8

5.1.

Razvoj temeljen na osobinama (FDD)........................................................8

5.2.

Ekstrenmo programiranje (XP)...................................................................9

5.3.

Scrum...................................................................................................... 11

6.

Zakljuak........................................................................................................ 12

7.

Literatura....................................................................................................... 13

1. Uvod

Tijekom 1990-ih godina u razvoju programskih proizvoda dominirale su

dvije paradigme. U ranim 90-im bila je to paradigma koja se temeljila na CASE
alatima i jezicima etvrte generacije, dok je u drugoj polovici desetljeca bila
aktualna paradigma koja se temeljila na objektnoj orijentaciji. I dok softverska
industrija nije bila zrela za CASE pristup, objektno orijentirana paradigma se
odrala, iako u potpunosti nije ispunila sva najavljivana ocekivanja. No, postala je
osnova

za

komponentni

razvoj,

objektno

orijentirane

jezike,

notaciju

za

modeliranje UML kao i filozofiju reverzibilnog inenjerstva. Dananja situacija u

softverskoj industriji ukazuje da se scenarij ponavlja.
Kada

bi

vam

netko

ponudio

metodu

programiranja

kojom

na

jednostavniji, efikasniji, bri i pouzdaniji nain dolazite do konanog proizvoda

gotove programske podrke za koritenje, naravno uz prezadovoljne klijente,
biste li ga bili spremni posluati? Vjerujem da je odgovor na ovo pitanje potvrdan,
a razlog zato ga se postavlja je jer tema ove radnje, agilni postupci razvoja
programske podrke, upravo govori o tome.

2. Nastanak agilnih metoda

Potaknuta nezadovoljstvom uzrokovanim velikim procentom neuspjenih IT

projekata, skupina sastavljena od sedamnaest strunjaka iz podruja softverskog
inenjerstva zagovornika agilnih metoda razvoja, sastala se 2001. godine u maloj
kolibici u skijakom odmaralitu negdje u planinama Jute kako bi pokuali nai
rjeenje za gorue probleme postojeih metodologija programskog inenjerstva.
Rezultat njihovog druenja je uveni manifest - Agile Manifesto. Agilni manifest je
dokument koji opisuje temeljne postavke buduih agilnih metoda.
Manifest moemo ukratko saeti na etiri temeljne poruke:

Individualci i interakcija ispred procesa i alata

Softver koji radi ispred iscrpne dokumentacije
Saradnja s klijentom ispred pregovora o ugovoru
Reagiranje na promenu ispred praenja plana.
Ove poruke zapravo su prilagodba temeljnih koncepata lean menadmenta

softverskom inenjerstvu. Lean menadment se pojavio u Japanu 80-ih godina

prolog vijeka i njegov je cilj eliminacija nepotrebnih aktivnosti i vea ukljuenost
samih radnika u unaprjeenje procesa proizvodnje.
Nastanak ranih agilnih metoda vezuje se za period prije 2000.godine:

1986. SCRUM u oblasti opteg menadmenta

1995. Adaptivni razvoj softvera, Razvoj voen karakteristikama i Metod

dinaminog razvoja sistema

1996. Crystal clear i ekstremno programiranje.

3. ta je agilno programiranje ?

Na poetetku ovog rada treba razjasniti osnovne ideje i koncepte koji stoje
iza postupaka agilnog programiranja. Agilno programiranje predstavlja vrstu
konceptualnog okvira kojeg se treba drati prilikom raenja projekata razvoja
programske podrke. Postoje razliite metodologije razvoja programske podrke,
a neke od njih predstavlja neprofitna organizacija Agile Alliance.
Veina agilnih metoda pokuava smanjiti rizik (od programskih pogreaka,
prekoraenja vremenskih rokova, itd.) razvijajui softver u kratkim vremenskim
okvirima, koji se nazivaju iteracije, a koji traju tipino od jednog do etiri tjedna.
Svaka iteracija je nalik na mali samostalni projekt razvoja programske podrke, i
sadri sve zadatke koji su potrebni da bi nastao napredak u funkcionalnosti
programa:

planiranje,

analiza

zahtjeva,

dizajn,

kodiranje,

testiranje

dokumentiranje. Iako pojedina iteracija ne moe garantirati da e dodati dovoljno

funkcionalnosti u program da bi se moglo rei da je to gotov proizvod, projekt koji
se razvija nekom od agilnih metoda nastoji proizvesti novu verziju programa
nakon svake iteracije. Na kraju svake iteracije, projektni tim vri ponovnu
evaluaciju prioriteta unutar projekta.
Agilne metode naglaavaju vanost komunikacije u realnom vremenu, po
mogunosti licem u lice, a s druge strane stavljaju puno manje panje na pisanu
dokumentaciju. Veina agilnih timova svrstano je u tzv. Bullpen i u njemu se
nalaze svi ljudi potrebni za dovrenje programa. Najmanje to agilni tim moe
sadravati su programeri i njihovi klijenti. Klijenti su ljudi koji definiraju konaan
proizvod. To naravno mogu biti menaderi, poslovni analitiari, ljudi iz drugih
dijelova firme, i stvarni klijenti koji kupuju programsko rjeenje. U bullpen-u mogu
biti i testeri gotovog sistema, dizajneri, pisci tehnike dokumentacije, te razni
slojevi upravljakog kadra.
Ono to agilne metode takoer naglaavaju je program koji radi kao glavni
pokazatelj napretka projekta. Kad se to kombinira s naklou prema komunikaciji
licem u lice, moe se zakljuiti da agilne metode proizvode vrlo malo pisane
dokumentacije u usporedbi sa drugim metodama. To je do sada rezultiralo time
da su agilne metode proglaavane nediscipliniranim hakiranjem ili kaubojskim
6

kodiranjem (eng. cowboy coding). Sve to je ovdje navedeno predstavlja glavne

karatkeristike agilnog razvoja programske podrke. Malo vie detalja slijedi u
slijedeoj cjelini Agile Manifesto.

4. Usporedba sa drugim tipovima metoda razvoja programske podrke

Agilne metode razvoja programske podrke esto se opisuje kao metode

koje se nalaze na suprotnoj strani spektra od metoda koje su planske ili
disciplinirane. To svrstavanje je pogreno, budui da iz njega proizlazi da su
agilne metode neplanske ili nedisciplinirane. Neto tanije svrstavanje bi bilo
kad bi se reklo da se metode razvoja programske podrke nalaze na liniji od
prilagodljivih do predvidljivih. Agilne metode se nalaze na prilagodljivom
kraju linije.
Prilagodljive metode fokusiraju se na brzu prilagodbu stvarnosti koja se
mijenja. Kada se potrebe projekta mijenjaju, mijenja se i prilagodljivi tim.
Prilagodljivi tim e imati potekoa u opisivanju stvari koje e se dogoditi u
budunosti. to je datum dalje u budunosti, to e prilagodljiva metoda imati
mutniju sliku o tome to e se dogoditi tog datuma. Prilagodljivi tim moe tono
rei koji zadaci su zacrtani za sljedeu sedmicu, ali zna samo one osobine
programa koje e se implementirati u sljedeih mjesec dana. Kada ga se pita o
verziji programa koja e izai za est mjeseci, prilagodljivi tim moe samo izrei
glavnu misiju za tu verziju, ili izjavu oko oekivanog odnosa dobiti i troka.
Predvidljive metode, kao suprotnost tome, fokusiraju se na detaljno
planiranje budunosti. Predvidljivi tim moe tono rei koje osobine programa i
koji zadaci su planirani za cijelo vrijeme trajanja razvoja programske podrke.
Predvidljivi timovi imaju potekoa oko mijenjanja smjera. Plan je tipino
optimiziran za poetno odredite (cilj) i mijenjanje smjera moe uzrokovati to da
se do tada zavreni posao odbaci i da se napravi iznova potpuno drugaije.
Predvidljivi timovi e esto osnovati odbor za kontrolu promjena kako bi
osigurali da se razmatraju samo najvanije promjene.

4.1. Usporedba s iterativnim razvojem

Veina agilnih metoda sadri osobinu izrade funkcionalne programske podrke u

kratkim vremenskim periodima, to je glavna osobina iterativnog razvoja.
Iterativne metode temelje se na inkrementalnom razvoju novih verzija (npr. RUP
Rational Unified Process) programske podrke. Nove verzije nastaju iz iskustva s
razvojem i koritenjem starijih verzija. Agilne metode razlikuju se od iterativnih
metoda po tome to se kod njih vremenski periodi mjere u tjednima a ne u
mjesecima, to je sluaj kod iterativnih metoda. Veina agilnih metoda takoer se
razlikuje od iterativnih metoda po tome to tretiraju svoje vremenske periode
striktno kao vrijeme, a ne kao zacrtani cilj kojega treba ostvariti. Iterativne
metode razlikuju se od predvidljivih u svojoj biti, a to je da predvidljive metode
(na primjer vodopadni model) nemaju pojam iteracija, ve se sve odvija
pravocrtno. Zapravo, finalna verzija vodopadnog modela. Sastoji se od vie
iteracija originalnog vodopadnog modela. Ali treba imati u vidu da se u literaturi
pojam vodopadnog modela upotrebljava za originalni Royce-ov dizajn, pa e se
i u ovom tekstu podrazumjevati da je vodopadni model predvidljiva metoda bez
iteracija.

4.2. Usporedba s vodopadnim modelom

Aglini razvoj ima malo slinosti sa vodopadnim modelom. Kod nekih ljudi
danas vlada miljenje da vodopadni model vie nije adekvatan za razvoj
programske podrke, ali mnogi ga i dalje smatraju klasinim modelom razvoja
programske podrke. Vodopadni model je najpredvidljiviji od svih metoda. Model
se sastoji od analize zahtjeva, dizajna, kodiranja i testiranja u striktno
isplaniranom redosljedu, djelomino zavravajui svaku osobinu programa u
svakom stupnju. Vodopadni model proizvodi funkcionalnu programsku podrku na
kraju svakog ciklusa, sa vremenskim periodom od tipino nekoliko mjeseci do
nekoliko godina. Agline metode, nasuprot tome, proizvode potpuno gotove
osobine programa (ali samo mali podskup ukupnog skupa osobina) svakih
nekoliko

sedmica.

Neki

agilni

timovi

ponekad

koriste

vodopadni

model,

ponavljajui cijeli ciklus vodopadnog modela u svakoj iteraciji. Drugi timovi, a to

je najuoljivije kod timova za ekstremno programiranje, rade na aktivnostima
istovremeno, tako da ne postoje odijeljene faze.
9

10

5. Agilne metode razvoja programskih proizvoda

5.1. Razvoj temeljen na osobinama (FDD)

Za FDD smatra se da je agilna i prilagodljiva metoda razvoja programske

podrke. FDD ne obuhvaa cijeli proces razvoja programske podrke, ve se
fokusira na dizajn i izgradnju sistema. Ipak, metoda je dizajnirana za rad i sa
ostalim djelovima razvojnog procesa te ne zahtijeva koritenje niti jednog
specifinog procesa. FDD metoda objedinjuje iterativni razvoj sa praksama za
koje se smatra da su trenutno najbolje i najefikasnije u industriji razvoja
programske podrke. Metoda naglaava kvalitetu kroz cijeli razvojni proces te
ukljuuje este
i opipljive isporuke programske podrke, kao i precizno nadgledanje napretka
projekta. FDD se sastoji od pet slijednih procesa i kao metoda, osigurava tehniku i
smjernice koje su potrebne sudionicima projekta da ga isporue. Nadalje, FDD
sadri uloge, ciljeve i vremenske rokove koji su potrebni u projektu. Za razliku od
nekih drugih agilnih metoda, za FDD se smatra da je metoda pogodna za razvoj
kritinih sistema.
Kao to je ranije spomenuto, FDD se sastoji od pet slijednih procesa tokom
kojih se razvija dizajn i izgradnja sistema (Slika 5.1.1). Iterativni dio FDD procesa
podrava agilni razvoj s brzom prilagodbom izmjenama zahtjeva i promjeni
poslovnih potreba. Tipino, iteracija jedne osobine programskog rjeenja zahtjeva
timski rad od jednog do tri tjedna.

11

Slika 5.1.1 Pet procesa FDD metode

Kad pone razvoj ukupnog modela, domenski strunjaci (vidi objanjenje u

sljedeem odjeljku) ve znaju opseg, kontekst i zahtjeve koje ima eljeni sistem.
Postoji mogunost da ve postoje dokumentirani zahtjevi u toj fazi. U
dokumentirane

zahtjeve

ulaze

sluajevi

koritenja

prava

funkcionalna

specifikacija sistema. Ipak, za FDD metodu nije nuno da ima razvijen proces
prikupljanja i upravljanja zahtjevima. Domenski strunjaci prezentiraju takozvani
opis problema putem kojeg informiraju lanove tima i glavnog arhitekta o
globalnom izgledu sistema.
Ukupna domena programskog rjeenja se dalje dijeli na razliite domene
gdje se svakom lanu odreene domene prezentira detaljniji opis problema koji se
tie ba te domene. Nakon svakog opisa problema pojedine domene, razvojni tim
poinje raditi u malim grupama kako bi proizveo objektni model za svoju domenu.
Za svaku od domena, razvojni timovi raspravljaju i odluuju o adekvatnom
objektnom modelu. Paralelno s time, proizvodi se ukupni model za cijeli sistem.

5.2. Ekstrenmo programiranje (XP)

12

Ekstremno programiranje je disciplina razvoja programske podrke koja

vrednuje jednostavnost, komunikaciju, povratne informacije i hrabrost. Fokusira
se na uloge klijenta, upravitelja i razvojnog inenjera te pridjeljuje kljuna prava i
odgovornosti onima koji nose te uloge.
Ova definicija pokazuje kljune osobine ekstremnog programiranja (XP).
Inae, XP je evolviralo iz problema koji su pratili duge razvojne cikluse
tradicionalnih razvojnih metoda. Poinje se tako to se ukazala prilika da se
odreeni posao napravi efikasno, a koriste se postupci koji su se pokazali
efikasnim u prolim desetljeima. Nakon brojnih uspjenih pria iz prakse, XP
metoda je teoretizirana kroz kljune principe i postupke koji su koriteni u njenoj
realizaciji. Iako pojedini postupci unutar XP-a nisu novi, u XP-u oni su skupljeni i
posloeni na potpuno novi nain i tako je stvorena nova metoda razvoja
programske podrke. Naziv ekstremno dolazi iz injenice da su ti jednostavni
postupci i principi unutar ove metode dovedeni do svojih ekstrema.
ivotni ciklus XP-a prema sastoji se od est faza: istraivanje, planiranje,
iteracije do izdavanja, produkcija, odravanje i smrt.

Slika 5.2.1 ivotni ciklus XP procesa

13

U fazi istraivanja, klijenti piu svoje prie na kartice o onom to bi eljeli

da bude ukljueno u prvo izdanje. Svaka kartica sadri jednu osobinu programa.
U isto vrijeme projektni tim se poblie upoznaje sa alatima, tehnologijom i
postupcima koje e koristiti u projektu. Radi se prototip sistema koji e se koristiti
za testiranje eljene tehnologije i za ispitivanje razliitih varijanti arhitekture
sistema. Faza istraivanja traje od nekoliko sedmica do nekoliko mjeseci, to
najvie ovisi o tome koliko su dobro razvojni inenjeri upoznati sa tehnologijom.
Faza planiranja postavlja prioritete na korisnike prie (tj. osobine
programskog rjeenja), te se odreuje koje e se kartice sa korisnikim priama
koristiti za izradu prvog malog izdanja sistema. Prvo se razvojni inenjeri
dogovoraju oko toga koliko im je potrebno vremena za pojedinu karticu i nakon
toga se dogovara cjelokupni vremenski raspored. Vremenski rok za izdavanje
prvog malog izdanja obino ne traje dulje od dva mjeseca. Sama faza planiranja
traje nekoliko dana.
Faza iteracija do izdanja ukljuuje nekoliko iteracija sistema prije prvog
izdanja. Vremenski raspored iz faze planiranja se razbija u nekoliko iteracija od
kojih e svaka trajati jedan do etiri tjedna. Prva iteracija stvara takav sistem koji
obuhvaa cijelu arhitekturu ciljanog sistema. To se ostvaruje tako to se izabiru
one kartice sa korisnikim priama koje e podrati izgradnju strukture cijelog
sistema. Klijent odluuje o tome koje e se kartice koristiti pri svakoj narednoj
iteraciji. Testovi zadovoljavanja funkcionalnosti, koje stvara sam klijent, izvode na
kraju svake iteracije. Na kraju posljednje iteracije, sistem je spreman za
produkciju.
Faza produkcije zahtjeva dodatno testiranje i provjeru performansi
sistema prije nego se sistem moe isporuiti klijentu. U ovoj fazi mogu se nai
eventualne zamjerke na sistem te se mora odluiti da li e se rjeiti u ovom
izdanju. U ovoj fazi se iteracije moraju pouriti sa tri na najvie sedmica dana.
Zakanjele nove ideje i prijedlozi se dokumentiraju i njihova implementacija
odgaa se za kasnije, npr. u fazi odravanja.
Nakon to je prvo izdanje puteno u produkciju, te se njime klijent ve
moe sluiti, XP projekt mora istovremeno odravati projekt u produkciji i
proizvoditi nove iteracije sistema. Da bi se to ostvarilo, faza odravanja
14

zahtjeva dodatni napor na strani korisnike podrke. Zbog toga se brzina

implementacije smanjuje dok se projekt nalazi u produkciji. Faza odravanja moe
zahtjevati nove ljude unutar projektnog tima kao i promjenu strukture tima.
Faza smrti je blizu kada klijent nema vie novih kartica s priama koje
treba implementirati. Podrazumijeva se da sistem i u svakom drugom pogledu
zadovoljava klijentove zahtjeve (npr. pouzdanost i stabilnost sutava). Ovo je
pravo vrijeme u XP projektu da se konano napie sva korisnika dokumentacija
budui da vie nema promjena na arhitekturi, dizajnu i kodu sistema. Smrt moe
nastupiti i kada sistem ne ispunjava sva korisnika oekivanja, ili ako postane
preskup za daljnji razvoj.

5.3. Scrum

Prve reference u literaturi na termin Scrum pokazuju na lanak u kojem

je predstavljen brzi, prilagodljivi i samoorganizirani proces razvoja programske
podrke koji potjee iz Japana. Termin Scrum originalno dolazi iz ragbija gdje
oznaava strategiju vraanja lopte koja je izala iz igre nazad u igru uz pomo
timskog rada.
Scrum pristup razvijen je za upravljanje procesom razvoja sistema.
Predstavlja empirijski pristup koji primjenjuje ideje iz teorije industrijske kontrole
procesa

na

razvoj

sistema.

To

rezultira

sa

pristupom

koji

uvodi

ideje

prilagodljivosti i produktivnosti. Ne definira niti jednu specifinu tehniku razvoja

programske podrke u fazi implementacije. Scrum se fokusira na to kako bi
lanovi tima trebali funkcionirati da bi ostvarili fleksibilan sistem u okolini koja se
neprekidno mijenja.
Osnovna ideja Scrum-a je da razvoj sistema sadri nekoliko varijabli okoline
(npr. zahtjevi, vremenski okvir, sredstva, tehnologija) za koje postoji velika
vjerojatnost da e se promijeniti tokom procesa. To ini proces razvoja
nepredvidljivim i sloenim, to zahtjeva njegovu fleksibilnost kako bi mogao
kvalitetno odgovoriti na promjene. Kao rezultat procesa razvoja sistema nastaje
sistem koji je koristan kada je isporuen.
15

Scrum pomae u poboljanju postojeih inenjerskih postupaka unutar

organizacije budui da ukljuuje upravljake aktivnosti koje imaju cilj da sistemno
uoavaju nedostatke u razvojnom procesu.
Scrum proces sadri tri faze: prije igre, razvoj i poslije igre.
Planiranje obuhvaa definiranje sistema koji e se razvijati. Stvara se lista
Product Backlog koja sadre sve trenutno poznate zahtjeve. Zahtjevi mogu biti
od klijenta, prodajnog ili marketinkog sektora, podrke klijentima ili razvojnih
inenjera. Vri se dodjela prioriteta za zahtjeve te se procjenjuje potreban napor
za njihovu realizaciju. Lista se stalno nadopunjuje sa novim i detaljnijim
zahtjevima, te sa sve tanije odreenim prioritetima i procjenama potrebnog
napora. Planiranje takoer ukljuuje odreivanje projektnog tima, potrebnih alata
i ostalih sredstava, procjenu rizika, procjenu potrebne edukacije i odobrenje od
upravitelja. U svakoj iteraciji Scrum Timovi pregledavaju nadopunjenu listu na
osnovu koje odreuju vlastita zaduenja.
Faza razvoja (takoer se zove i faza igre) predstavlja agilni dio Scrum
pristupa. Ova faza se tretira kao crna kutija u kojoj se moe oekivati
nepredvidljivo ponaanje. Tokom Sprintova unutar faze razvoja promatraju se i
kontroliraju razliite varijable okoline i ehnike varijable (vremenski okvir,
kvaliteta, zahtjevi, sredstva, tehnologije i alati za implementaciju, ak i razvojne
metode) koje se mogu mijenjati tokom procesa. Umjesto da ove varijable uzima u
obzir samo na poetku procesa razvoja sistema, Scrum metoda ih kontrolira
neprekidno kako bi se mogla fleksibilno prilagoditi promjenama.
Faza poslije igre sadri zavretak izdanja sistema. U ovu fazu ulazi se
kada se sloi oko toga da su varijable okoline, kao to su npr. zahtjevi, do kraja
ispunjene. U ovoj fazi nema vie starih zahtjeva za raditi niti se mogu izmiljati
novi zahtjevi. Sistem je spreman za izdavanje te se radi priprema za to. Priprema
ukljuuje testiranje, integraciju i dokumentiranje.

16

6. Zakljuak

Agilne metode razvoja softvera naglasak stavljaju na veu komunikaciju i

kreiranje korisnog programskog proizvoda, a u drugi plan su stavljeni strogi okviri
unaprijed definisanih projektnih faza i opirna dokumentacija. U praksi se
pokazalo kako prakticiranje agilnih metoda uvelike moe da povea procenat
uspenosti IT projekata obzirom da razvojni tim kroz intenzivnu komunikaciju s
klijentom i odgovaranje na promene u zahtevima koje nastaju u tijeku provoenja
projekta stjee bolji uvid u stvarne korisnikove potrebe i na taj nain kreira
softver koji je usklaeniji sa korisnikim oekivanjima. Iako agilne metode imaju
mnogo pozitivnih strana, postoje i problemi s kojima se suoavaju praktiari. Ti
problemi tiu se znanja steenih u radu, obzirom da ne postoji opirna
dokumentacija, velikih napora koje klijent mora uloiti, obzirom da se od njega
oekuje ukljuenost u razvoj, nedoreenosti u smislu pravne popraenosti
projekta, obzirom da ne postoje smernice za stvaranje agilnog ugovora te
problem finansiranja i osiguravanja projektnog budeta, jer se od agilnog tima
oekuje prilagoavanje promenama u zahtevima to neminovno znai i probijanje
vremenskog okvira projekta. Svi ovi, ali i neki drugi problemi prakticiranja agilnih
metoda mogu biti predmet buduih istraivanja iz ove domene.

17

7. Literatura

1. Ruben Picek, Integracijski okvir primjene uzoraka u razvoju programskog

proizvoda temeljenom na modelima, Zagreb 2008. godine
2. http://fit.spu.ba/test/wpcontent/uploads/2014/09/DiplomskiRadZeljkoGavric.pdf
3. http://www.efos.unios.hr/razvoj-poslovnihaplikacija/wpcontent/uploads/sites/228/2013/04/RPA_P1_Agilnemetode1.pdf
4. http://www.zpr.fer.unizg.hr/zpr/Portals/0/Predmeti/MIT/Agilni%20postupci
%20razvoja%20programske%20podr%C5%A1ke.pdf
5. http://infoteh.etf.unssa.rs.ba/zbornik/2011/radovi/E-I/E-I-16.pdf

18