FAKULTET POLITEHNIKIH NAUKA

Agilni razvoj programskih proizvodaSeminarski rad

Student: Alen Durakovi, PT-24/13-IKolegij: Razvoj programskih proizvodaProfesor: Prof.dr Halid igiAkademska godina: 2014/2015

Travnik, Januar 2015

Sadraj

1.Uvod32.Nastanak agilnih metoda43.ta je agilno programiranje ?54.Usporedba sa drugim tipovima metoda razvoja programske podrke64.1.Usporedba s iterativnim razvojem64.2.Usporedba s vodopadnim modelom75.Agilne metode razvoja programskih proizvoda85.1.Razvoj temeljen na osobinama (FDD)85.2.Ekstrenmo programiranje (XP)95.3.Scrum116.Zakljuak127.Literatura13

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 s 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 i 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 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.

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 estei 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.

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 i 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)

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

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 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. 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.

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.

7. Literatura

1. Ruben Picek, Integracijski okvir primjene uzoraka u razvoju programskog proizvoda temeljenom na modelima, Zagreb 2008. godine2. http://fit.spu.ba/test/wp-content/uploads/2014/09/DiplomskiRadZeljkoGavric.pdf3. http://www.efos.unios.hr/razvoj-poslovnih-aplikacija/wpcontent/uploads/sites/228/2013/04/RPA_P1_Agilne-metode1.pdf4. http://www.zpr.fer.unizg.hr/zpr/Portals/0/Predmeti/MIT/Agilni%20postupci%20razvoja%20programske%20podr%C5%A1ke.pdf5. http://infoteh.etf.unssa.rs.ba/zbornik/2011/radovi/E-I/E-I-16.pdf

13