US - Razvoj Aplikativnog Softvera

UNIVERZITET SINGIDUNUM

RAZVOJ APLIKATIVNOG SOFTVERA

Prvo izdanje

Beograd, 2012.

RAZVOJ APLIKATIVNOG SOFTVERA

Autor:

Recenzenti:

UNIVERZITET SINGIDUNUMBeograd, Danijelova 32www.singidunum.ac.rs

Priprema za tampu:

Dizajn korica:

Godina izdanja:2012.

300 primeraka

tampa:Mladost GrupLoznica

ISBN: 978-86-7912-437-1

Copyright: 2012. Univerzitet Singidunum!"#Reprodukcija pojedinih delova ili celine ove publikacije nije dozvoljeno.

iii

P r e d g o v o r

Ova knjiga je nastala kao rezultat potrebe za odgovarajuim pisanim materijalom iz predmeta Razvoj aplikativnog softvera koji autor dri na etvrtoj godini Fakulteta za informatiku i raunarstvo Univerziteta Singidunum u Beogradu. Pri pisanju je uinjen napor da knjiga bude prihvatljiva za itaoce bez nekog veeg predznanja iz oblasti razvoja softvera. Namenjena je i prilagoena prosenom studentu, jer je osnovni cilj autora bio da svi studenti koji sluaju predmet Razvoj aplikativnog softvera mogu na razumljiv i lak nain da savladaju predvieno gradivo.

Knjiga je podeljena u devet poglavlja kroz koja se prati ceo ivotni ciklus softvera.

U uvodnom poglavlju objanjeni su pojam softvera i njegovo mesto u raunarskom okruenju. Posebna panja je posveena pristupu reavanju sloenih problema, tj. analizi problema i sintezi reenja. Ukazano je na osnovne aspekte o kojima se mora voditi rauna pri izradi softvera. Na kraju poglavlja, opisane su uloge pojedinih uesnika u procesu razvoju softvera.

Drugo poglavlje je posveeno procesu razvoja softvera. U njemu su izloene faze u procesu razvoja, kao i naini planiranja razvoja. Detaljno je predstavljen vei broj tradicionalnih metoda modelovanja procesa razvoja, kao to su kaskadni model, V model, spiralni model, RUP i dr. Osim tradicionalnom pristupu, panja je posveena i agilnim metodama razvoja, posebno ekstremnom programiranju.

U treem poglavlju opisana je prva faza u procesu razvoja softvera, tj. analiza zahteva. Ukazano je na sve aktivnosti koje treba sprovesti u ovoj fazi, poevi od prikupljanja zahteva od korisnika i modelovanja ponaanja sistema razliitim metodama, pa do formulisanja i dokumentovanja zahteva. Na kraju su opisani postupci verifikacije i validacije zahteva kojima se potvruje da se sistem razvija na pravi nain i da su zahtevi ispravno definisani.

etvrto poglavlje se bavi postupcima projektovanja sistema na osnovu specifikacije zahteva koja je rezultat prve faze u razvoju softvera. Posebno je istaknut znaaj modularnosti u projektovanju. Centralni deo poglavlja opisuje najznaajnije strategije projektovanja, kao to su cevi i filti, klijent-server arhitektura, objektno-orijentisan pristup i dr. Izlaganja strategija su praena odgovarajuim primerima.

U petom poglavlju su iznete osnove UML jezika za modelovanje koji danas predstavlja najee korieni postupak modelovanja razliitih faza procesa razvoja

iv

softvera. Opisano je est osnovnih dijagrama, ukljuujui dijagram klasa, dijagram sluajeva korienja, dijagram aktivnosti, itd.

esto poglavlje je posveeno implementaciji softvera. U njemu je najvea panja posveena pisanju programa i izradi odgovarajue programske dokumentacije. Na kraju je navedeno o emu sve treba voditi rauna kako bi napisani program bio to kvalitetniji.

U sedmom poglavlju, detaljno je opisana faza testiranja softvera. Na poetku su uvedeni pojmovi greke i otkaza i izneta njihova klasifikacija. U centralnom delu, opisane su vrste testiranja, tj. jedinino, integraciono i sistemsko testiranje. U okviru jedininog testiranja predstaljeni su metodi crne i bele kutije. Nakon toga, objanjeni su razliiti metodi integracije (od vrha ka dnu, od dna ka vrhu i dr.), kao i postupci sistemskog testiranja (funkcionalno testiranje, testiranje performansi i dr.). U poslednjem delu poglavlja opisan je nain izvoenja testiranja.

Osmo poglavlje se bavi problemima isporuke i odravanja softvera. U fazi isporuke, posebna panja je posveena obuci korisnika i prateoj dokumentaciji. Faza odravanja je prikazana kroz vrste odravanja, probleme i trokove odravanja.

Poslednje, deveto poglavlje analizira kvalitet softvera. Najpre se analiziraju razliiti aspekti sa kojih se kvalitet moe posmatrati, a zatim se detaljno predstaljaju najznaajniji modeli kvaliteta iji je cilj to objektivnija procena softvera.

Na kraju udbenika, nalazi se Dodatak koji je namenjen studentima Univerziteta Singidunum koji polau predmet Razvoj aplikativnog softvera. U dodatku su date opte smernice za izradu projekta koji predstavlja sastavni deo ispita. One treba da pomognu studentima da bolje razumeju proces razvoja softvera. Smernicama su obuhvaeni samo oni delovi procesa razvoja koji su izvodljivi u datim uslovima, tj. mogu se sprovesti u fakultetskom okruenju.

Biu zahvalna svima onima koji mi ukau na greke ili daju korisne savete za budue ispravke i dopune ovog materijala.

Beograd, april 2012.god. Autorka

v

S A D R A J

Predgovor ................................................................................................. iii

1 Uvod ..................................................................................................... 9

2 Proces razvoja softvera ...................................................................... 15

2.1 Tradicionalne metode modelovanja ......................................................... 17 2.1.1 Kaskadni model .............................................................................. 17 2.1.2 V model ........................................................................................... 19 2.1.3 Fazni razvoj ..................................................................................... 21

2.1.3.1 Inkrementalni fazni razvoj ...................................................... 23 2.1.3.2 Iterativni fazni razvoj .............................................................. 24

2.1.4 Prototipski model ........................................................................... 25 2.1.5 Transformacioni model .................................................................. 27 2.1.6 Spiralni model ................................................................................ 28 2.1.7 RUP ................................................................................................ 30

2.2 Agilne metode .......................................................................................... 33 2.2.1 Ekstremno programiranje ............................................................... 35

3 Analiza zahteva .................................................................................. 43

3.1 Prikupljanje zahteva ................................................................................. 46 3.1.1 Vrste zahteva .................................................................................. 48 3.1.2 Razreavanje konflikata .................................................................. 50 3.1.3 Prototipovi zahteva ......................................................................... 51

3.2 Modelovanje ponaanja ............................................................................ 53 3.2.1 ER dijagrami ................................................................................... 53 3.2.2 Tragovi dogaaja ............................................................................ 55 3.2.3 Konani automati ............................................................................ 56

vi

3.3 Formulisanje zahteva ............................................................................... 57 3.3.1 Dokumentovanje zahteva ............................................................... 57 3.3.2 Kvalitet zahteva ............................................................................. 62

3.4 Validacija i verifikacija zahteva .............................................................. 63 3.4.1 Validacija zahteva .......................................................................... 63 3.4.2 Verifikacija specifikacije ................................................................ 65

4 Projektovanje sistema ........................................................................ 67

4.1 Modularnost u projektovanju ................................................................... 69 4.2 Strategije projektovanja ........................................................................... 70

4.2.1 Cevi i filtri ...................................................................................... 72 4.2.2 Slojevita arhitektura ........................................................................ 73 4.2.3 Klijent-server arhitektura ................................................................ 74 4.2.4 Ravnopravni pristup ....................................................................... 75 4.2.5 Arhitektura zasnovana na dogaajima ............................................ 76 4.2.6 Objektno-orijetisani pristup ............................................................ 76

5 UML modelovanje ............................................................................. 79

5.1 Dijagrami sluajeva korienja ................................................................ 79 5.2 Dijagrami klasa ........................................................................................ 83 5.3 Dijagrami sekvence .................................................................................. 89 5.4 Dijagrami aktivnosti ................................................................................. 93 5.5 Dijagrami komponenata .......................................................................... 102 5.6 Dijagrami rasporeivanja ........................................................................ 106

6 Implementacija softvera ................................................................... 111

6.1 Pisanje programa ..................................................................................... 113 6.1.1 Strukture podataka ......................................................................... 115 6.1.2 Algoritmi ....................................................................................... 117 6.1.3 Kontrolne strukture ........................................................................ 119

6.2 Programska dokumentacija ..................................................................... 120 6.2.1 Unutranja dokumentacija ............................................................. 121 6.2.2 Spoljanja dokumentacija .............................................................. 124

vii

6.3 Kvalitet programiranja ............................................................................ 125

7 Testiranje softvera ............................................................................ 127

7.1 Greke i otkazi ........................................................................................ 128 7.1.1 Klasifikacija greaka ..................................................................... 129

7.2 Vrste testiranja ........................................................................................ 132 7.2.1 Jedinino testiranje ....................................................................... 134

7.2.1.1 Metod crne kutije ............................................................... 137 Podela na klase ekvivalencije ................................................................. 139 Analiza graninih vrednosti .................................................................... 141 Uzrono-posledini grafovi .................................................................... 142

7.2.1.2 Metod bele kutije................................................................ 145 Pokrivanje iskaza .................................................................................... 146 Pokrivanje odluka ................................................................................... 147 Pokrivanje uslova .................................................................................... 148

7.2.2 Integraciono testiranje ................................................................... 149 7.2.2.1 Integracija po principu velikog praska ............................... 149 7.2.2.2 Integracija od dna ka vrhu ..................................................... 150 7.2.2.3 Integracija od vrha ka dnu ..................................................... 153 7.2.2.4 Sendvi integracija ............................................................. 154

7.2.3 Sistemsko testiranje ....................................................................... 155 7.2.3.1 Funkcionalno testiranje ......................................................... 156 7.2.3.2 Testiranje performansi ........................................................... 157 7.2.3.3 Testiranje prihvatljivosti ........................................................ 159 7.2.3.4 Instalaciono testiranje ............................................................ 161

7.3 Proces testiranja ...................................................................................... 161 7.3.1 Plan testiranja ................................................................................ 162

7.3.1.1 Zavretak testiranja ................................................................ 163 7.3.2 Specifikacija testova ...................................................................... 166 7.3.3 Realizacija testiranja ...................................................................... 168 7.3.4 Evaluacija rezultata testiranja ........................................................ 170

viii

8 Isporuka i odravanje softvera ........................................................ 173

8.1 Isporuka sistema ...................................................................................... 173 8.1.1 Obuka korisnika ............................................................................. 174 8.1.2 Dokumentacija ............................................................................... 177

8.2 Odravanje sistema ................................................................................. 180 8.2.1 Vrste odravanja ............................................................................ 181 8.2.2 Problemi odravanja ...................................................................... 183 8.2.3 Trokovi odravanja ...................................................................... 185

9 Kvalitet softvera ................................................................................ 187

9.1 Pogledi na kvalitet softvera ..................................................................... 187 9.1.1 Kvalitet proizvoda ......................................................................... 188 9.1.2 Kvalitet procesa razvoja ................................................................ 188 9.1.3 Kvalitet sa stanovita okruenja .................................................... 189

9.2 Modeli kvaliteta ...................................................................................... 190 9.2.1 McCall-ov model ........................................................................... 190 9.2.2 Boehm-ov model ........................................................................... 194 9.2.3 Dromey-ov model .......................................................................... 196 9.2.4 Model ISO 9126 ............................................................................ 198

Dodatak .................................................................................................... 203

Literatura

Intenzivan razvoj informatike i raunarstva u poslednjim decenijama uveo je softver u sve oblasti ivota. Razvijeni su brojni softverski proizvodi sa vrlo razliitim namenama. Softver je postao neohodan u svim oblastima drutva: privredi, obrazovanju, zdravstvu, medijima i komunikacijama, poslovanju, politici, itd.

Generalno posmatrano, mogu se izdvojiti dve vrste softvera: sistemski i aplikativni softver. Pod sistemskim softverom podrazumevaju se programi niskog nivoa (low-level) koji omoguavaju rad sa raunarskom opremom (hardverom). Moe se rei da sistemski softver na neki nain oivljava hardver i omoguava njegovo korienje. U sistemski softver se ubrajaju operativni sistemi, razvojni alati za generisanje pograma na razliitim programskim jezicima, mreni softveri, softveri za upravljanje bazama podataka, programske biblioteke, razne vrste prevodioca, alati za testiranje programa, itd. Sistemski softver obezbeuje osnovnu funkcionalnost koja ini platformu za rad aplikativnog softvera. Aplikativni softver ine programi napravljeni za specifinu svrhu, prema potrebama korisnika. Ova vrsta softvera nije u direktnoj vezi sa hradverom, ve se u svom izvravanju oslanja na sistemski softver, posebno na operativni sistem. Aplikativni softver obuhvata poslovne aplikacije opte namene (tekst procesore, aplikacije za tabelarna izraunavanja, grafike aplikacije i sl.), aplikacije za kunu upotrebu (igrice, edukativne aplikacije i dr.), industrijski softver, usluni softver, web aplikacije, itd. Odnos sistemskog i aplikativnog softera je prikazan na slici 1.1.

U nekim sluajevima, nema jasne granice izmeu sistemskog i aplikativnog

softvera. Na primer, ne postoji saglasnost svetskih strunjaka oko toga da li je pretraiva Internet Explorer deo operativnog sistema Windows ili nije.

1 Uvod

10 Uvod

RAUNARSKI HARDVER

SISTEMSKI SOFTVER

OS Prevodioci Mreni softver

Biblioteke Razvojna okruenja

APLIKATIVNI SOFTVER

Tekst procesori Grafike aplikacije

Igrice Web aplikacije

Slika 1.1 Mesto aplikativnog softvera u raunarskom okruenju

Potreba za razvojem aplikativnog softvera moe da nastane kada korisnik eli da rei neki problem ili da dobije neku uslugu. Meutim, pre izrade softvera, posebno ukoliko se radi o sloenom problemu, neophodno je sprovesti analizu sistema. Pod analizom sistema se podrazumeva sagledavanje problema i njegovo razlaganje na potprobleme koji su razumljivi i reivi. Posebna panja u analizi se mora posvetiti vezama izmeu potproblema, jer one mogu biti kljuni faktor u nalaenju kompletnog reenja. Nakon to se problem razloi na potprobleme koji mogu da se ree (sa jasno definisanim meusobnim vezama), pristupa se sintezi reenja. Svaki potproblem se najpre samostalno reava, a zatim se od dobijenih parcijalnih reenja formira kompletno reenje problema. Postupak analize i sinteze je ilustrovan na slici 1.2, na primeru problema koji se moe razloiti na tri potproblema: PP1, PP2 i PP3.

Reenje potproblema PP1 je R1, dok su R2 i R3 reenja potproblema PP2 i

PP3, respektivno. Spajanjem reenja R1, R2 i R3 dobija se reenje polaznog problema.

Rezultat sinteze reenja ukazuje na to da li posmatrani problem treba da se reava izradom odgovarajueg softvera, ili se moe reiti na neki drugi nain. Ako se utvrdi da je softver potreban, pristupa se njegovom razvoju.

Svaki problem koji se reava izradom softvera, moe se reiti na vie naina.

Naini se meusobno razlikuju po efikasnosti, preciznosti, razumljivosti, korisnosti, mogunosti modifikovanja i drugim osobinama. Stoga, izrada softvera zahteva posedovanje znanja, ali i domiljatosti i vetine. Osnovni cilj u izradi

Uvod 11

softvera jeste da softver bude sveobuhvatan, stabilan, razumljiv, da se lako odrava i radi efiksano ono zbog ega je napravljen. Nerazumljivost napisanog programa naruava njegov kvalitet, iako ponekad postoji pogreno miljenje da je takav program izuzetan, zato to niko osim autora ne moe da ga shvati.

PROBLEM

PP1 PP 3

R 3

REENJE

PP 2

R 1 R 2

Ana

liza

prob

lem

aSi

ntez

a re

enj

a

Slika 1.2 Analiza problema i sinteza reenja

Danas u svetu postoji veliki broj proizvoaa softvera. Svaki od njih se trudi da napravi softver bez mana. Meutim, praktino ne postoji softver bez nedostataka. Neki nedostaci se pojave odmah nakon putanja softvera u rad, dok je za druge potrebno znatno vie vremena. Ni za jedan softver se ne moe garantovati da za svo vreme primene nee ispoljiti nijedan nedostatak.

Da bi softver bio to bolji, pri njegovoj izradi mora se voditi o raznim aspektima, kao to su:

neovlaena upotreba sistema

trite softvera

obezbeivanje kvaliteta

12 Uvod

Za softver je vano da dobro radi u svim uslovima u kojima moe da se nae. Zato, pri njegovoj izradi treba voditi rauna i o moguoj neoekivanoj upotrebi sistema. Do neoekivane upotrebe moe da doe zbog pokuaja zloupotrebe softvera, ili zbog nestrunog rukovanja od strane korisnika. Na primer, est je sluaj zlonamernih napada na web stranice dravnih organa ili drugih organizacija. Zato, pri izradi ovih web stranica, treba sprovesti odreene mere zatite sadraja. U praksi je est i sluaj nestrunog rukovanja, posebno kada se korisnici susreu sa novom tehnologijom.

Zbog velike konkurencije na tritu softvera, da bi opstali, proizvoai moraju u relativno kratkim vremenskim periodima da isporuuju nove proizvode. To im ostavlja nedovoljno vremena za testiranje programa, pa su greke u programima ee. Kada se uoi neki nedostatak u softveru, proizvoa mora vrlo brzo da reaguje i da ga otkloni. On to moe da uini na dva naina: da ispravi greku menjanjem dela postojeeg softvera, ili da generie novi softver. Donoenje prave odluke u ovoj situaciji je od izuzetne vanosti. Naime, ako je nedostatak koncepcijske prirode, tj. ako je nastao zbog loe isprojektovanog sistema, njegovo otklanjanje izmenom dela kda moe da prouzrokuje nove, moda i vee probleme. Ima situacija u kojima je isplativije ponovo razviti ceo sistem, nego popravljati stari koji se ne moe popraviti. U svakom sluaju, donoenje odluke je najbolje prepustiti nekom iskusnom projektantu.

O kvalitetu softverskog proizvoda mora se voditi rauna tokom celog procesa razvoja softvera. Dokazano je da to nedostatak ostane due vremena neotkriven, to njegovo otklanjanje vie kota. Na primer, trokovi ispravljanja greke u fazi analize su deset puta manji od trokova ispravljanja iste greke nakon isporuke. Zato je jedan od primarnih ciljeva u svim fazama razvoja otkrivanje i otklanjanje greaka.

U proces definisanja i stvaranja softverskog proizvoda ukljueno je vie

uesnika koji mogu da imaju sledee uloge:

kupac

razvojni tim

korisnik

Kupac je kompanija, organizacija ili pojedinac koji naruuje softver i finansira njegov razvoj. Softver se pravi prema potrebama kupca i namenjen je reavanju nekog njegovog problema. Kupac kontaktira kompaniju, organizaciju ili pojedinca koji e napraviti eljeni softver i u tu svrhu, ova kompanija formira razvojni tim. Korisnik predstavlja jednog ili vie pojedinaca koji e stvarno koristiti sistem. Korisnik i kupac obino pripadaju istoj kompaniji ili organizaciji. Na primer, ako je

Uvod 13

potrebno razviti aplikaciju za podrku alterskom radu u banci, kupca predstavlja rukovodstvo banke, a korisnika alterski slubenici.

Za uspenost projekta, veoma je vana dobra komunikacija izmeu svih uesnika. Nakon postizanja dogovora o realizaciji softvera, kupac i organizacija koja razvija softver potpisuju ugovor. Zatim, poto je razumeo ta eli kupac, razvoji tim kontaktira krajnje korisnike da bi prikupio informacije o nainu funkcionisanja sistema u radnom okruenju. Na osnovu njih, razvojni tim realizuje softverski proizvod. Kada sistem bude gotov, isporuuje se, i kupac potpisuje papire o tehnikom prijemu softvera.

Opisane uloge ne moraju uvek da pripadaju razliitim uesnicima. U nekim, uglavnom manjim projektima, ista osoba ili grupa moe da ima dve, ili ak sve tri uloge. Na primer, ako neka kompanija ima svoj sektor za razvoj, moe se doneti odluka da taj sektor razvija softver koji e biti namenjen praenju trokova sopstvenih projekata. U ovom sluaju, sektor postaje i kupac i razvojni tim i krajnji korisnik.

U poslednje vreme, odnosi izmeu uloga postaju znatno sloeniji. To se deava zato to se kupci i korisnici sve vie ukljuuju u proces razvoja softvera.

Kupac i korisnik imaju veoma znaajne uloge u definisanju sistema. Meutim,

u realizaciji sistema, glavnu ulogu ima razvojni tim. Njega ine softverski inenjeri specijalizovani za razliite aspekte razvoja. Broj lanova u timu zavisi od veliine softverskog sistema koji se razvija. U veim projektima, mogu se izdvojiti sledee uloge lanova razvojnog tima:

analitiar lan razvojnog tima koji obavlja prve korake u razvoju. U komunikaciji sa korisnikom, analitiar utvruje ta korisnik eli i dokumentuje njegove zahteve. Nakon definisanja zahteva, analitiar radi zajedno sa projektantima na generisanju opisa funkcija sistema.

projektant projektuje, tj. dizajnira sistem prema zadatim funkcionalnim zahtevima, tako da kasnije programeri mogu lako da ga implementiraju.

programer pie programski kd na odgovarajuem programskom jeziku koristei predvieno razvojno okruenje. Kd mora da odgovara projektu sistema uraenom na osnovu korisnikih zahteva.

inenjer za testiranje testira programski kd koji je napisao programer. Prvo testiranje obino obavljaju sami programeri, a zatim se kd prosleuje na detaljnije testiranje inenjerima za testiranje. Pri integraciji sistema, tj. spajanju programskih modula u jednu celinu, timovi za testiranje rade na verifikaciji sistema. Zatim sledi validacija, tj. provera da li sistem ispunjava zahteve korisnika.

14 Uvod

inenjer za isporuku i odravanje isporuuje i instalira softver u radnom okruenju, obuava korisnike za operativno korienje sistema i bavi se poslovima odravanja sistema nakon njegove isporuke.

Navedene razvojne uloge kod velikih projekata obavljaju razliite osobe, dok kod manjih projekata, ista osoba moe da ima vie uloga.

Osim navedenih uloga, koje direktno imaju udela u realizaciji softverskog

proizvoda, neophodno je obezbediti i podrku skladnom radu razvojnog tima. Kod velikih projekata, dimenzije i sloenost sistema, kao i potreba za intenzivnom interakcijom izmeu lanova razvojnog tima, znaajno utiu na kvalitet rada tima, a samim tim i na kvalitet finalnog proizvoda. U tim situacijama je prilino teko kontrolisati razliite aspekte projekta. Zato se u razvojni tim ukljuuju i lanovi koji pruaju samo usluge podrke. To su, na primer, bibliotekari (bave se dokumentacijom), tim za upravljanje konfiguracijom (obezbeuje koordinaciju razliitih verzija sistema, usklaenost zahteva, projekta, implementacije i testova) i dr.

U optem sluaju, pod procesom se podrazumeva ureeni skup zadataka koje treba obaviti da bi se napravio neki proizvod ili pruila neka usluga. U svakom procesu se definiu aktivnosti koje treba izvriti, kao i resursi koji e tom prilikom biti korieni. I aktivnosti i resursi podleu brojnim ogranienjima. Na primer, ogranienja predstavljaju redosled aktivnosti u nekom poslu, raspoloivost alata, budet, prostor, vremenski rokovi, itd. Svaka aktivnost ima uslove pod kojima otpoinje i pod kojima se zavrava. Aktivnosti su esto meusobno povezane i uslovljene. Proces rezultira proizvodom ili uslugom.

Poto softver predstavlja jednu vrstu proizvoda, navedene osobine vae i za proces razvoja softvera. Ovaj proces se naziva i ivotnim ciklusom softvera, zato to opisuje ivot softverskog proizvoda od poetka njegove izrade do njegovog operativnog korienja i odravanja.

Proces razvoja softvera je vremenom evoluirao. U poetku, sa pojavom prvih

raunara, softver je bio vrlo jednostavan i programeri su mogli da ga generiu direktnim pisanjem kda. Nije bilo nikakvog planiranja, ve se na osnovu nekoliko odluka formirao sistem.

Kasnije, kada su zahtevi postali brojniji, softver je mogao da razvija samo vei broj programera koji su inili razvojni tim. Da bi proizveli eljeni proizvod, lanovi razvojnog tima su bili upueni na meusobnu saradnju. Za uspenost projekta najvanije je bilo da ceo razvojni tim ima isti pogled na sistem, tj. da na isti nain shvata problem, kao i njegovo reenje. Zbog poveanja sloenosti softvera, dodavanje novih funkcionalnosti je postajalo sve tee, kao i pronalaenje i otklanjanje greaka. Vremenom se dolo do ideje da bi ovaj problem najlake mogao da se prevazie uvoenjem metodologije razvoja. Pod metodologijom se podrazumeva disciplina u procesu razvoja koja ima za cilj bolju predvidljivost i veu efikasnost razvoja softvera.

2 Proces razvoja softvera


Razvoj softvera je podeljen u nekoliko faza:

analiza i definisanje zahteva. U ovoj fazi razvojni tim, u saradnji sa kupcem i korisnicima, utvruje zahteve koje sistem treba da zadovolji. Pri analizi zahteva moraju se uzeti u obzir svi entiteti, aktivnosti i ogranienja koji postoje u sistemu. Posebna panja se mora posvetiti interakciji sistema sa okruenjem. Razultat ove faze je lista korisnikih zahteva.

projektovanje sistema. U cilju ispunjenja zahteva definisanih u prvoj fazi, u ovoj fazi se generie projekat sistema koji daje plan reenja. Plan ukljuuje komponente i algoritme koji e biti korieni, kao i arhitekturu sistema.

projektovanje programa. U ovoj fazi se definiu podprojekti pogodni za programsku realizaciju. Svaki podprojekat predstavlja jedan modul sa datom funkcionalnou. Definiu se veze izmeu modula i naini razmene podataka izmeu njih.

izrada programa. Ovo je faza direktne izrade softvera u kojoj programeri piu programski kd prema uraenom projektu.

testiranje programa. Ova faza se bavi nalaenjem i ispravljanjem greaka u sistemu. Nakon pisanja programa, najpre se testiraju individualni delovi kda, tj. pojedinani moduli, to se naziva jedininim testiranjem. Zatim se vri integraciono testiranje tokom koga se moduli povezuju u jednu celinu. Na kraju sledi zavrno testiranje u kome se proverava da li sistem ispunjava postavljene zahteve korisnika.

isporuka sistema. U ovoj fazi, sistem se isporuuje naruiocu, softver se instalira u radnom okruenju i obavlja se obuka neposrednih korisnika.

odravanje. Ovo je dugotrajna faza u kojoj se ispravljaju greke u sistemu koje se javljaju nakon njegove isporuke. Takoe se radi i na daljem unapreenju pojedinih delova sistema u skladu sa zahtevima korisnika ili promenama u okruenju.

Teorijski posmatrano, pod procesom razvoja softvera podrazumeva se svaki opis razvoja softvera koji sadri neke od nabrojanih faza, organizovanih tako da proizvode odgovarajui ispravan i proveren kd.

Uvoenje planiranja u proces razvoja softvera prema zadatim fazama dovelo

je do nastanka tradicionalnih metoda modelovanja. Postoji veliki broj tradicionalnih metoda, a najznaajnije od njih su opisane u poglavlju 2.1.

Brojne tekoe u izvoenju tradicionalnih metoda modelovanja dovele su do pojave novog pristupa procesu razvoja softvera. To je agilni pristup koji negira

Tradicionalne metode modelovanja 17

potrebu za velikim planiranjem i obimnom dokumentacijom, ve se zalae za fleksibilniji razvoj u kome mnogo toga zavisi od znanja i vetina ljudskog faktora. Ovaj pristup je opisan u poglavlju 2.2.

2.1 Tradicionalne metode modelovanja

Modelovanje procesa razvoja softvera obezbeuje potpunu kontrolu i koordinaciju svih aktivnosti koje treba sprovesti da bi se proizveo eljeni softver i ispunili ciljevi projekta. Razloga za modelovanje ima vie:

kada projektni tim opie sistem, taj opis postaje zajedniko shvatanje svih uesnika u razvoju; to znatno olakava komunikaciju unutar tima i otklanja mnoge nesporazume i pogrena tumaenja

modelovanje odraava ciljeve razvoja; na osnovu modela, projektni tim, pre pisanja softvera, moe da oceni predviene aktivnosti sa aspekta njihove usklaenosti sa postavljenim zahtevima

modelovanje pomae u nalaenju nedoslednosti, suvinih ili izostavljenih elemenata, to poboljava efikasnost procesa razvoja

modeli se prave prema konkretnoj situaciji; meutim, mogu se koristiti i u drugim situacijama uz odreena prilagoenja; s druge strane, dobro je da neki trag ostane o projektu i nakon njegovog zavretka

Da bi se napravio model procesa razvoja softvera, potrebno je definisati skup aktivnosti koje treba da budu izvrene, njihov redosled, ulazne i izlazne podatke za svaku aktivnost pojedinano, preduslove koji moraju da budu ispunjeni da bi neka aktivnost mogla da se izvri, kao i posledice izvravanja pojedinanih aktivnosti.

2.1.1 Kaskadni model

Kaskadni model ili model vodopada je verovatno najstariji publikovani model razvoja softvera. Iako je i ranije korien u nekim organizacijama, o njemu je meu prvima pisao Royce 1970.godine.

Kaskadni model predstavlja veoma visok nivo apstrakcije razvojnog procesa. Naziv modela potie od naina na koji su u njemu razvojne faze meusobno povezane. Faze su povezane kaskadnom vezom koja se ostvaruje tako to se na narednu fazu prelazi tek nakon zavretka prethodne faze. Izlaz iz prethodne faze se prosleuje narednoj fazi kao ulaz.


Model vodopada sadri pet faza razvoja oznaenih i povezanih kao na slici 2.1. U prvoj fazi se radi analiza zahteva kupca. Tek nakon zavretka ove faze, moe se prei na projektovanje sistema. Slino, po zavretku projektovanja, otpoinje kodiranje, tj. pisanje programa. Zatim, po istom prinicpu, slede testiranje, isporuka i odravanje. Svaka faza je praena obimnom dokumentacijom, pa se za ovaj model esto kae da je voen dokumentima.

U svakoj fazi, mogu se definisati kritine take, koje predstavljaju repere na osnovu kojih se lako moe pratiti izvoenje projekta. Kritine take mogu da budu, na primer, sastanci u zakazanom terminu na kojima se prezentiraju rezultati, ili informacije da su neki moduli zavreni. Osim kritinih taaka, u svakoj fazi mogu se definisati i meuproizvodi, na osnovu kojih se dobija uvid u trenutnni stepen gotovosti projekta. Za razliku od kritinih taaka, koje su vie informativnog karaktera, meuproizvodi predstavljaju konkretne celine, na primer, istestiran programski kd.

Analiza zahteva

Projektovanje

Kodiranje

Testiranje

Isporuka i odravanje

Slika 2.1 Kaskadni model

Kaskadni model ima prednosti i nedostatke. Glavne prednosti modela su:

jednostavnost. Visok nivo apstrakcije modela olakava komunikaciju sa kupcima koji ne moraju da budu upoznati sa procesom razvoja softvera.

lako praenje projekta. Postojanje kritinih taaka i meuproizvoda omoguava rukovodiocu projekta da u svakom trenutku ima informaciju o tome kako projekat napreduje i da li je dolo do nekih bitnih odstupanja u realizaciji na koje treba da reaguje.

laka primena modela. Poto se ceo sistem razvija u samo jednoj iteraciji, kaskadni model je pogodan za korienje u sluajevima kada je potrebno stari sistem u kratkom roku zameniti novim.

Iako je kaskadni model jasan i jednostavan, zbog svojih nedostataka, mali je broj situacija u kojima se moe primeniti. Nedostaci kaskadnog modela su sledei:


ne podrava povratne sprege. U praksi, svaki sloeniji softver se razvija u vie iteracija. To je tako zato to je praktino nemogue u poetnoj fazi definisati kompletan skup projektnih zahteva (mnogi faktori razvoja nisu u tom trenutku ni poznati), ve se neki od njih, prema potrebi, dodaju kasnije. Osim toga, moe se javiti i potreba za izmenama u fazama koje su ve zavrene (na primer, pri kodiranju se ustanovi greka u projektovanju). Ove izmene predstavljaju povratne sprege od kasnijih ka ranijim fazama razvoja. Kaskadni model, po svojoj prirodi, ne ostavlja mogunost vraanja na prethodne faze, pa se ne moe primeniti u sistemima sa povratnim spregama (a takva je veina sistema).

ne ukazuje na nain povezivanja faza. U kaskadnom modelu, svaka faza ima svoj izlaz koji je istovremeno i ulaz naredne faze. Na primer, izlaz prve faze predstavljaju projektni zahtevi na osnovu kojih se zatim, u narednoj fazi, projektuje sistem. Meutim, u modelu nije naznaeno kako zahteve treba transformisati u dizajn. Slino vai i za ostale prelaze izmeu faza (transformacija dizajna u programski kd).

razvoj softvera se ne posmatra kao reavanje problema. Model vodopada odraava proizvoaki (industrijski, hardverski) pogled na proces razvoja, koji se zasniva na proizvodnji pojedinanih proizvoda i njihovom repliciranju. Meutim, softver se proizvodi na drugaiji nain. On evoluira sa boljim razumevanjem problema kroz ispitivanje razliitih varijanti moguih reenja. Razvoj softvera je stvaralaki, a ne proizvoaki proces.

ima ogranienu interakciju sa korisnikom. Kaskadni model doputa interakciju sa korisnikom samo u poetnoj fazi definisanja zahteva i poslednjoj fazi kada se vri isporuka. To se smatra nedovoljnim. Bilo bi bolje da korisnici ee i pravovremeno mogu da daju svoje sugestije, jer bi to proces razvoja uinilo efikasnijim.

Zbog znaajnih nedostataka, kaskadni model je vremenom doiveo mnoga unapreenja. Na osnovu njega, predloeno je nekoliko novih modela procesa razvoja softvera u kojima su otklonjeni neki od navedenih nedostataka.

2.1.2 V model

V model projektovanja softvera je nastao 1992.godine u Nemakoj, za potrebe nemakog Ministarstva odbrane. On predstavlja proiren i poboljan kaskadni model. Naziv modela potie od injenice da se proces razvoja softvera predstavlja u vidu dijagrama u obliku slova V, kao to je prikazano na slici 2.2. Leva strana dijagrama odgovara fazama u kaskadnom modelu, na dnu dijagrama se nalazi faza


kodiranja, a u desnom delu dijagrama faze testiranja i odravanja. Kao i u sluaju kaskadnog modela, i kod V modela faze su sekvencijalne, to znai da naredna faza moe da pone tek kada se prethodna faza zavri.

Analiza zahteva

Projektovanje sistema

Projektovanje programa

Kodiranje

Zavrno testiranje

Testiranje celog sistema

Testiranje modula sa integracijom

Operativni rad i odravanje

Verifikacija

Validacija

Slika 2.2 V model

Kao novinu, V model uvodi veze izmeu razvojnih faza, u kojima se precizira ta i kako sistem treba da radi (levi deo dijagrama), i njima odgovarajuih faza testiranja (desni deo dijagrama). Za razliku od kaskadnog modela, koji se uglavnom bavi dokumentima i meuproizvodima, V model svu panju usredsreuje na aktivnosti koje se bave ispravnim radom sistema.

Da bi ispravno radio, sistem se testira kroz tri faze: testiranje pojedinanih modula sa integracijom, testiranje integrisanog sistema i zavrno testiranje. Prve dve od navedenih faza testiranja slue za verifikovanje dizajna sistema, dok trea faza slui za validaciju sistema. Cilj testiranja pojedinanih modula uz postepenu integraciju jeste da se razvojni tim uveri da je svaki aspekt sistema ispravno implementiran. Testiranje integrisanog sistema treba da dokae da sistem kao celina radi ono to se prema projektu od njega oekuje. Kao to se vidi, ove dve faze slue za proveru da li je sistem ispravno i u potpunosti implementiran prema uraenom projektu. Zavrno testiranje proverava da li sistem ispunjava sve zahteve korisnika navedene u specifikaciji zahteva. Ovo testiranje esto sprovode naruioci softvera, jer oni mogu najbolje da procene da li sistem odgovara njihovim potrebama.

Po V modelu, proces razvoja softvera se odvija tako to se najpre sprovodi

analiza zahteva, zatim projektuju sistem i programi, a onda se prelazi na kodiranje. Nakon toga slede faze testiranja. Ukoliko se u nekoj fazi testiranja pojavi problem (bilo pri verifikaciji ili pri validaciji), prema zadatim povratnim spregama,


ponavljaju se odgovarajue aktivnosti iz faza u levom delu dijagrama. Popravke i dopune se mogu odnositi na korisnike zahteve, dizajn sistema ili organizaciju programa. Poto se unesu potrebne izmene, intervenie se u programskom kdu, a onda se ponovo sprovodi testiranje. Sistem se moe razvijati u vie iteracija, ukoliko postoji potreba da se povratne sprege koriste vie puta, dok se ne doe do konane verzije sistema koja e biti isporuena.

Zbog svoje jednostavnosti i lake primene, V model je jedan od najee

korienih modela za razvoj softvera. Prednosti V modela su sledee:

podrava povratne sprege. V model je praktino primenljiv ne samo za razvoj jednostavnijih, ve i sloenijih softverskih sistema, jer doputa povratak na prethodne faze razvoja, to je est sluaj.

omoguava verifikaciju i validaciju sistema. V modelom se moe proveriti da li je projekat dobro uraen i implementiran, kao i da li sistem ispunjava zahteve korisnika.

generie kvalitetan proizvod. V model predstavlja strogo kontrolisan proces razvoja, tako da se moe garantovati dobar kvalitet softverskog proizvoda.

vodi rauna o testiranju u ranim fazama projekta. Tim za testiranje ima uticaja i na ranije faze razvoja, to doprinosi boljem razumevanju na projektu od samog njegovog poetka. To kasnije dovodi do znaajne utede u vremenu potrebnom za testiranje.

Nedostaci V modela su:

nedovoljna fleksibilnost. U sluaju pojave nekog problema i povratka na ranije faze, nije dovoljno samo uneti izmene, ve se moraju aurirati i sve naredne faze, ukljuujui i prateu dokumentaciju.

zahteva obimne resurse. Izvoenje V modela zahteva obimne resurse i vea novana sredstava (brojniji razvojni tim), tako da ga mogu primenjivati samo vee kompanije.

2.1.3 Fazni razvoj

Velika konkurencija na tritu softvera od proizvoaa zahteva skraenje vremena potrebnog za razvoj softvera. Vie se ne moe dozvoliti da protekne dug vremenski period od definisanja zahteva do isporuke sistema. Brojne studije pokazuju da proizvoai softvera veliku veinu prihoda ostvaruju od prodaje svojih


novijih softvera (napravljenih u poslednjih par godina). Jedan od naina da se ubrza isporuivanje sistema korisnicima jeste primena faznog razvoja.

Fazni razvoj je nain projektovanja softvera koji omoguava isporuivanje

sistema u delovima, tj. fazama. Svaka faza obuhvata odreen skup funkcija definisan projektom. Kompletna funkcionalnost sistema se dobija objedinjavanjem funkcija iz svih faza. Ovakav nain razvoja podrazumeva da je u datom trenutku korisnicima na raspolaganju jedan skup funkcija, dok su ostale funkcije jo u razvoju.

Prema tome, postoje paralelno dva sistema: produkcioni i razvojni. Produkcioni sistem je sistem koji trenutno koriste naruioci ili korisnici. Razvojni sistem je sistem na kome radi razvojni tim. Razvojni sistem je, u stvari, naredna verzija sistema koja se priprema da zameni postojei produkcioni sistem.

Produkcioni i razvojni sistemi se obino oznaavaju svojim verzijama (izdanjima). Broj moguih verzija odgovara broju faza koje se isporuuju pri faznom razvoju. Ako korisnici trenutno rade na n-toj verziji produkcionog sistema, onda razvojni tim radi na (n+1)-oj verziji razvojnog sistema. Nakon isporuke ove faze, korisnici naputaju n-tu verziju produkcionog sistema i prelaze na novu (n+1)-u verziju. Razvojni tim poinje da radi na novom skupu funkcija koji predstavlja novu, (n+2)-u verziju razvojnog sistema. Slian postupak se ponavlja sve dok se ne isporui i poslednja faza, tj. dok korisnik ne dobije kompletan softverski proizvod. Na slici 2.3 dat je opti model faznog razvoja.

verzija 1

verzija 1

verzija 2

verzija 2

verzija 3

verzija 3

Raz

vojn

i tim

Kor

isni

ci

Razvojni sistemi

Produkcioni sistemi

vreme

.....

.....

Slika 2.3 Model faznog razvoja

Postoji vie pristupa organizaciji faznog razvoja. Oni se razlikuju po nainu formiranja verzija koje se isporuuju korisniku. Dva najpopularnija pristupa su: inkrementalni i iterativni razvoj.


2.1.3.1 Inkrementalni fazni razvoj

Inkrementalni fazni razvoj podrazumeva podelu sistema na podsisteme prema funkcijama definisanim u specifikaciji zahteva. Verzije se definiu kao mali funkcionalni podsistemi koji, svaki za sebe, sadre razliite skupove funkcija. Svaka isporuka nove verzije znai dalju nadogradnju sistema do njegove pune funkcionalnosti.

Inkrementalni razvoj e biti ilustrovan na jednom primeru. Neka je potrebno

realizovati softver koji podrava tri vrste funkcionalnosti: unos podataka, proraune i prikaz rezultata. Sistem se moe razvijati kroz tri verzije (faze), v1, v2 i v3, kao to je prikazano na slici 2.4.

v1 v1

v2 v3

v1

v2

Slika 2.4 Primer inkrementalnog razvoja

Nakon isporuke prve faze, korisnicima su na raspolaganju samo funkcije za unos podataka iz v1, a nakon isporuke druge faze, funkcije za unos podataka i funkcije za proraune (iz v1 i v2). Tek po isporuci tree faze, korisnici mogu da koriste sve funkcije sistema (iz v1, v2 i v3).

Prednosti koje korisnicima prua inkrementalni fazni razvoj su sledee:

brza isporuka operativnog skupa funkcija. Ve nakon isporuke prve faze, korisnici imaju na raspolaganju potpuno realizovan podskup funkcija koje e biti sastavni deo konanog proizvoda. Svaka naredna faza uveava broj funkcija koje imaju svoj finalni oblik.

vidljiv napredak na projektu. Zbog isporuke dela funkcionalnosti nakon svake faze, progres na projektu se moe vrlo lako i jednostavno pratiti. On je vidljiv ne samo preko dokumenata, ve i u praktinom radu.

permanentni odziv korisnika. Interakcija sa korisnikom koja je prisutna tokom celog ciklusa razvoja vodi ka stabilnijim meurezultatima i sistemu uopte. Poto se korisnik vrlo rano sree sa prvim operativnim funkcijama, moe na vreme da intervenie ukoliko u njima uoi neke nedostatke. Ako se ti nedostaci otklone u ranijim fazama projekta, trokovi su manji, a razvoj efikasniji.


mali projektni tim. Zbog malih verzija, razvojni tim moe da ima relativno mali broj lanova. To smanjuje ukupne trokove na projektu, ali moe da utie na kvalitet proizvoda. Naime, poto isti razvojni tim radi na svim verzijama, a poslovi se mogu bitno razlikovati od verzije do verzije, teko je obezbediti da svako u timu u dovoljnoj meri poznaje sve potrebne tehnologije. Na primer, za programera je teko ako mesec dana treba da razvija korisniki interfejs u datom okruenju, zatim da programira u C-u, da bi u sledeoj fazi radio sa bazama podataka. Ovakva dinamika rada svakako mora da utie na dobijeni rezultat. Da bi se ipak postigao potreban kvalitet, razvojnom timu je potrebno vie vremena za rad, to opet anulira poetne utede u trokovima zbog malog broja lanova u razvojnom timu.

2.1.3.2 Iterativni fazni razvoj

Iterativni fazni razvoj, slino inkrementalnom, podrazumeva podelu sistema na podsisteme prema funkcijama. Meutim, sada se u svim verzijama isporuuje potpuni sistem, s tim to se u svakoj novoj verziji menjaju funkcije svakog od podsistema. To znai da svaka nova verzija unapreuje prethodnu, dok se ne dobije kompletan sistem.

Na slici 2.5 prikazan je iterativni postupak razvoja softvera iz primera

opisanog u okviru inkrementalnog razvoja.

v1 v2 v3

Slika 2.5 Primer iterativnog razvoja

Kao to se vidi, u svim fazama se isporuuje ceo sistem. Meutim, u verziji v1 obezbeeni su primitivni oblici sve tri vrste funkcionalnosti sistema. Na primer, podaci se mogu unositi runo, prorauni su nekompletni, i moe se generisati uproena varijanta izvetaja. Nakon isporuke druge faze (v2), sistem ima istu funkcionalnost, ali je kvalitet poboljan. Na primer, jedan skup ulaznih podataka se automatski preuzima iz drugog programa, prorauni su efikasniji, a izvetaj detaljniji. Iz ovoga se vidi da je sistem unapreen. Potpuna funkcionalnost se dobija tek nakon isporuke tree faze v3.

Prednosti iterativnog faznog razvoja su sledee:


mogunost rane obuke. Poto se ve u prvoj verziji isporuuje ceo sistem, korisnici mogu odmah da ponu sa deliminom obukom. Ona se ogleda u upoznavanju sa organizacijom korisnikog interfejsa, kao i sa nainima izvravanja pojedinih funkcija. Iako funkcije nisu kompletno realizovane, korisnik saznaje ta moe da oekuje u konanoj verziji. Ovako rana obuka je dobra, jer korisnici mogu razvojnom timu na vreme da sugeriu mogua poboljanja u kasnijim verzijama.

este isporuke. Ukoliko je mogua, isporuka novih verzija u kratkim vremenskim intervalima uvek daje dobre rezultate. Problemi se brzo i lako otklanjaju zahvaljujui informacijama dobijenim od korisnika. Meutim, este isporuke zahtevaju veliku odgovornost po pitanju kvaliteta isporuene verzije.

mogunost specijalizovanih verzija. U razliitim verzijama, razvojni tim moe da se posveti usavravanju razliitih aspekata sistema. Na primer, u jednoj verziji moe da unapredi korisniki interfejs, u drugoj da unapredi performanse sistema, itd.

2.1.4 Prototipski model

Prototipski model razvoja softvera se zasniva na izradi prototipova softverske aplikacije. Pod prototipom se podrazumeva nekompletna verzija programa koji se razvija. Zahvaljujui prototipovima, u kratkom vremenskom periodu se mogu generisati kompletan sistem ili njegovi delovi u cilju pojanjavanja ili boljeg razumevanja otvorenih pitanja. Postoje prototipovi razliitih vrsta, to zavisi od toga ta se njima eli postii, tj. sa kojim ciljem se izrauju. Bez obzira na vrstu, svrha svih prototipova je da se smanje rizik i neodreenost prilikom razvoja sistema.

Protipovi mogu da budu ukljueni u finalni proizvod, ali i ne moraju. Ukoliko se ne ukljuuju, njihova uloga je da se brzo i efikasno ispitaju razliite mogunosti u fazama razvoja.

Na slici 2.6 prikazan je opti oblik prototipskog modela. Razvoj po

prototipskom modelu otpoinje definisanjem skupa zahteva koji odgovaraju potrebama korisnika ili naruioca. Zatim se analiziraju predlozi razliitih varijanti izgleda ekrana korisnikog interfejsa, naina unosa podataka, tabela sa podacima, izlaznih izvetaja i svega onoga to je direktno na raspolaganju korisnicima. Korisnici izlau svoje elje i revidiraju postojee zahteve. Posle vie iteracija, kada se postigne konani dogovor o zahtevima, kao rezultat se dobija prototip zahteva.


lista revizija

Prototip zahteva

lista revizija

Prototip projekta

lista revizija

Prototip sistema Testiranje

Zahtevi Isporueni sistem

Slika 2.6 Prototipski model Zatim projektni tim prelazi na izradu prototipa projekta. Istrauju se razliite

varijante dizajna, esto uz konsultovanje sa korisnicima. Poetni dizajn se revidira sve dok svi uesnici u projektovanju ne budu zadovoljni prototipom projekta. Ako se pri projektovanju naie na probleme koji potiu od zahteva, povratnom spregom se ostvaruje vraanje na specificirane zahteve. Oni se opet analiziraju, menjaju i dobija se novi, izmenjen prototip zahteva.

Nakon generisanja prototipova zahteva i projekta, prelazi se na kodiranje, tj. izadu prototipa sistema. Opet se razmatraju razliite varijante kodiranja, uz mogunost povratka na analizu projekta, ili ak analizu zahteva.

Na kraju se sistem testira i isporuuje korisnicima.

Prednosti prototipskog razvoja su sledee:

redukovanje vremena i trokova. Prototipski model poboljava kvalitet zahteva zbog detaljnih analiza koje se sprovode pri izradi prototipa zahteva. Rano utvrivanje ta korisnik zaista eli bitno ubrzava razvoj i smanjuje trokove na projektu koji sa vremenom eksponencijalno rastu.

intenzivna interakcija sa korisnicima. Ukljuivanje korisnika u izradu prototipova znaajno smanjuje greke koje nastaju zbog razliitih tumaenja zainteresovanih strana u projektu. Poto korisnici ipak najbolje poznaju domen problema, intenzivna interakcija poveava kvalitet finalnog proizvoda.

Prototipski razvoj ima sledee nedostatke:

nedovoljna analiza. Fokusiranje na prototipove koji predstavljaju pojednostavljene komponente sa ogranienom funkcionalnou moe da odvrati razvojni tim od detaljne analize na nivou celog projekta. Zbog toga se deava da doe do previanja boljih reenja, izrade nekompletne specifikacije ili konverzije prototipova u konana reenja koja su teka za odravanje.


konfuzija izmeu prototipova i finalnih sistema. Korisnici mogu da dobiju pogrean utisak da su prototipovi (koji su inae namenjeni analizi, a zatim se uglavnom odbacuju) u stvari finalni proizvodi koje samo treba malo doraditi. Oni, na primer, nisu svesni koliki napor treba uloiti da bi se dodala provera greaka ili mehanizmi zatite koje prototip ne podrava. To dovodi do toga da korisnici oekuju od prototipova da precizno modeluju performanse finalnog sistema, to nije namera razvojnog tima. Takoe, korisnici ponekad prihvataju svojstva ukljuena u prototip kao finalna, iako e ona kasnije biti iskljuena iz sistema, pa moe da doe do konflikta sa razvojnim timom.

2.1.5 Transformacioni model

Transformacioni model (Balzer, 1985.godine) predstavlja pokuaj automatskog modelovanja procesa razvoja softvera. Ideja je da se smanji mogunost greke u modelovanju uvoenjem niza transformacija kojima se polazna specifikacija prevodi u sistem koji moe da se isporui korisniku. Poto su transformacije unapred definisane i raspoloive, modelovanje se svodi na izbor sekvence transformacija iz zadatog skupa kojom se moe ostvariti postavljeni cilj projekta. Tipine transformacije su: prelazak sa jednog na drugi nain predstavljanja podataka, razliiti algoritmi, metodi optimizacije, prevoenje i sl.

Do istog cilja se moe doi na mnoge naine, tj. mogu se koristiti razliite sekvence transformacija. Zato je vano da se pri korienju transformacionog modela sekvence transformacija i pratee odluke uvaju u vidu formalnih zapisa u projektu sistema.

Na slici 2.7 prikazan je transformacioni model.

revizija prema

zahtevima

Formalna specifikacija transformacija i Testiranje

Zahtevi Isporueni sistem

transformacija N

transformacija 1transformacija 2

.....

.....

Formalni zapis o razvoju

Slika 2.7 Transformacioni model


Kao to se vidi, najpre se zahtevi sistema prevode u formalnu specifikaciju. To je neophodno zato to transformacije mogu da se izvravaju samo nad formalnom specifikacijom (jer su i same formalne). Nakon toga se odreuje sekvenca transformacija koja polaznu specifikaciju prevodi u sistem, koji se zatim testira i isporuuje. Ceo proces modelovanja je praen formalnim zapisima.

Transformacioni model je veoma mnogo obeavao, mada se ve moe

postaviti pitanje da li e ispuniti ta oekivanja, s obzirom da je proteklo mnogo vremena od kada je predloen. Najvei problem da ovaj model zaivi i bude ire prihvaen je u neophodnosti formalne specifikacije koju nije lako napraviti. U poslednje vreme, dosta se radi u oblasti formalnih specifikacijskih modela, to bi moglo da dovede do intenzivnije upotrebe transformacionog modela.

2.1.6 Spiralni model

Spiralni model je formulisao Boehm 1986.godine. Ovaj model zahteva da se u procesu razvoja softvera vodi rauna o postojeim rizicima. To se postie tako to se uobiajene aktivnosti razvoja softvera kombinuju sa analizom rizika. Cilj je da se omogui upravljanje rizicima, kako bi se smanjio njihov broj i olakala njihova kontrola.

Spiralni model je nastao kao rezultat napora da se objedine dobre osobine razvoja odozgo-nadole (projektovanje sistema njegovom dekompozicijom na podsisteme sa postepenim prelaskom na detalje) i odozdo-nagore (prototipsko projektovanje manjih celina koje se posle nadograuju i povezuju u kompletan sistem). Moe se rei da spiralni model kombinuje kaskadni sa prototipskim modelom. Spiralni model je namenjen razvoju velikih, sloenih i skupih sistema.

Na slici 2.8 prikazana je spirala razvoja koja se izvodi u vie iteracija, to

znai da model predstavlja iterativni razvoj. Kao to se vidi, razvoj softvera se odvija u etiri iteracije. Prva iteracija se

odnosi na zahteve i planiranje ivotnog ciklusa, druga na planiranje razvoja, trea na plan integracije i testiranja, a etvrta na implementaciju.

Svaka iteracija obuhvata jedan pun krug na dijagramu i prolazi kroz etiri kvadranta koji odgovaraju sledeim aktivnostima:

kvadrant 1: odreivanje ciljeva, alternativa i ogranienja

kvadrant 2: evaluacija alternativa, identifikacija i procena rizika

kvadrant 3: razvoj i verifikacija putem testiranja

kvadrant 4: planiranje sledee iteracije


Aktivnosti koje treba obaviti na poetku svake iteracije (kvadrant 1) su:

identifikacija ciljeva iteracije, utvrivanje razliitih alternativa za postizanje ovih ciljeva i utvrivanje ogranienja koja se u pojedinim alternativama nameu.

start

A 1

Principi rada

A alternativeO ogranienjaR analiza rizikaP prototip

Zaht

evi

Validacija

zahteva

Diza

jn

softv

era

Validacija i

verifikacija d

izajnaD

etal

jan

diza

jn

Kodi

ranj

e

Testiranje

sistema

Zahtevi, plan razvoja

Plan razvoja

Integracija i plan testiranja

O 1 R 1P 1

A 2O 2 R 2

P 2

A 3

O 3 R 3

P 3

A 4

O 4 R 4

P 4

Testira

nje

delova

Zavrno testiranjePlan isporuke

1 2

34

Slika 2.8 Spiralni model

Nakon ovih, slede aktivnosti (kvadrant 2) koje se odnose na evaluaciju

alternativa i ogranienja uz ukljuivanje neizvesnosti i rizika. Za svaku alternativu se prave prototipovi ili simulacije da bi se smanjio rizik u donoenju odluka.

Nakon toga, pristupa se razvoju softvera (kvadrant 3) prema kaskadnom modelu imajui u vidu rezultate analize rizika.

Na kraju (kvadrant 4), pristupa se planiranju naredne iteracije.

Prednosti spiralnog modela su:

redukovanje rizika. Po spiralnom modelu, sistem se razvija tako to se najpre izdvoje karakteristike sa najviim prioritetom, a zatim se na osnovu njih razvija prototip. Nakon testiranja prototipa, eljene izmene se unose u novi sistem. Ovakav nain razvoja minimizira rizike i greke pri izradi sistema.


dobra kontrola trokova. Poto su prototipovi mali fragmenti u okviru projekta, trokovi se mogu lako proceniti. Zato kupac moe da ima dobru kontrolu administriranja novog sistema.

aktivno uee korisnika. Polazei od prve do finalne faze u modelu, znanje korisnika o sistemu stalno raste. Interakcija sa korisnikom omoguava ravnomeran razvoj softverskog proizvoda koji zadovoljava potrebe korisnika.

Spiralni model ima sledee nedostatke:

ograniena primena. Spiralni model najbolje funkcionie u sluaju velikih i sloenih projekata, dok za manje projekte nije pogodan.

neophodno znanje o rizicima. Model zahteva veliku vetinu u evaluaciji neizvesnosti i rizika. Osim toga, uvoenje rizika dovodi do poveanja trokova, pa se deava da trokovi evaluacije rizika budu vei od trokova izrade sistema.

sloenost modela. Spiralni model ima striktno definisan protokol razvoja, koga je ponekad teko ispotovati.

2.1.7 RUP

RUP (Rational Unified Process) je metodologija razvoja softvera kreirana u kompaniji Rational Software 1996.godine (kompanija se od 2003.godine nalazi u sastavu IBM-a). Po prirodi, to je adaptivni proces optije namene, to znai da svaka razvojna organizacija moe da selektuje elemente RUP-a i tako formira proces razvoja koji joj najvie odgovara. RUP je iterativni postupak razvoja softvera orijentisan ka arhitekturi i voen sluajevima korienja. Proces je dobro strukturiran i jasno definie ko, ta i kako treba da uradi na projektu. Opteg je karaktera i moe se prilagoditi kako malim, tako i velikim projektima i razvojnim timovima. Prilagoavanja se izvode izborom elemenata koje nudi RUP i njihovim organizovanjem u razvojni proces koji zadovoljava konkretne potrebe.

Osnovni gradivni elementi RUP-a su:

uloge (ko), koje definiu skup povezanih vetina, sposobnosti i odgovornosti

proizvodi rada (ta), koji predstavljaju rezultat nekog zadatka, ukljuujui modele, proizvode, dokumentaciju i sl.


zadaci (kako), koji opisuju posao dodeljen ulozi koji proizvodi neki koristan rezultat

U svakoj iteraciji, zadaci su organizovani u devet disciplina, est inenjerskih (poslovno modelovanje, zahtevi, analiza i projektovanje, implementacija, testiranje i isporuka) i tri discipline za podrku (konfiguracija i upravljanje izmenama, upravljanje projektom i okruenje).

RUP posmatra ivotni ciklus projekta kroz sledee etiri faze:

faza zapoinjanja (Inception Phase)

faza razrade (Elaboration Phase)

faza konstrukcije (Construction Phase)

faza tranzicije (Transition Phase)

Navedene faze omoguavaju predstavljanje procesa razvoja na visokom nivou apstrakcije (slino kaskadnom modelu), iako je sutina razvoja, u stvari, u iteracijama koje se odvijaju u svim fazama. Organizacija RUP-a po fazama prikazana je na slici 2.9.

Svaka faza ima jasno definisane ciljeve i kritinu taku (milestone) na kraju

faze. Kritina taka podrazumeva davanje odgovora na pitanja o ispunjenosti ciljeva faze.

Svrha faze zapoinjanja je razumevanje obima i ciljeva projekta. To znai da

treba precizno utvrditi ta treba da se napravi, koliki je obim sistema, kakva je vizija, ko eli sistem i ta je za njega vano. Nakon toga se identifikuju osnovne funkcionalnosti sistema i definiu sluajevi korienja. U ovoj fazi se predlae bar jedno reenje. Takoe, razmatraju se i trokovi, kao i potencijalni rizici na projektu. Ukoliko je projekat sloen, faza zapoinjanja se odvija u vie iteracija, jer je razvojnom timu potrebno vie vremena da ga dobro razume. Na kraju ove faze je prva kritina taka u kojoj treba odluiti da li je projekat izvodljiv i finansijski prihvatljiv. Ukoliko jeste, prelazi se na narednu fazu. U suprotnom, odustaje se od projekta.

Faza razrade se bavi definisanjem osnovne arhitekture sistema na osnovu sluajeva korienja, to je preduslov za dobro projektovanje i implementaciju. Cilj ove faze je smanjenje rizika u pogledu definisanih zahteva, predloene arhitekture i izbora alata. I ova faza se moe odvijati u vie iteracija u zavisnosti od veliine projekta. Na kraju faze je druga kritina taka koja se odnosi na pitanja u vezi sa postojanjem detaljnog plana voenja projekta i preduzetim postupcima za


minimizaciju rizika. Ako je sve u redu, prelazi se na sledeu fazu. U suprotnom, ili se odustaje od projekta, ili se izvode sutinske izmene.

vreme

Zapoinjanje

Poslovno modelovanje

Elaboracija Konstrukcija Tranzicija

ZahteviAnaliza i

projektovanje

Implementacija

Testiranje

IsporukaKonfiguracija

i izmeneUpravljanje

projektom

Okruenje

F A Z E

D I

S C

I P

L I N

E

Slika 2.9 RUP faze i discipline U fazi konstrukcije razvijaju se potrebne komponente, obavljaju se testiranja i

kompletira dokumentacija projekta. Ciljevi faze su: minimizacija trokova razvoja, obezbeivanje odgovarajueg kvaliteta softverskog proizvoda i priprema za isporuivanje proizvoda korisniku. Faza se moe odvijati u vie iteracija. Na kraju se dolazi do tree kritine take koja prua odgovor na pitanje da li je finalna verzija spremna za isporuku. Ako jeste, prelazi se na poslednju fazu, a ukoliko nije, treba odluiti da li dalji razvoj ima svrhe, ili se treba vratiti na neku od prethodnih faza.

Faza tranzicije podrazumeva isporuivanje gotovog proizvoda. Tokom ove faze preduzimaju se sve aktivnosti kako bi korisnik bio zadovoljan proizvodom, jer to i jeste osnovni cilj faze. I ova faza se odvija u vie iteracija, pri emu se u svakoj od njih prikupljaju sugestije korisnika koje e biti ukljuene u narednu verziju projekta. Na kraju faze, dolazi se do poslednje kritine take u kojoj treba odgovoriti na pitanje da li je sistem kompletan, stabilan i u potpunosti spreman za isporuku. Ako jeste, sledi donoenje odluke o tome da li treba otpoeti novi ciklus razvoja. U suprotnom, treba se vratiti na neku od prethodnih faza.


Prednosti RUP-a su sledee:

visok nivo prilagodljivosti konkretnom projektu, jer RUP nita ne zahteva, ve samo preporuuje

iterativnost procesa koja omoguava postepen razvoj sistema, to vodi smanjenju trokova i vremenskim utedama

upravljanje rizicima to usmerava razvoj ka niim trokovima Glavni nedostaci RUP-a su:

neprilagoenost malim projektima kod kojih faze zapoinjanja i razrade gube na znaaju

iterativnost procesa, to moe da predstavlja i manu, ukoliko su rukovodioci i razvojni timovi neiskusni, jer tada esto dolazi do velikih propusta ije su posledice prekoraenja rokova, ili ak odustajanje od projekta

Zbog svoje fleksibilnosti, RUP je veoma koriena metodologija za razvoj softvera od strane iskusnijih razvojnih timova.

2.2 Agilne metode

Poeci agilnih procesa razvoja datiraju iz osamdesetih godina prolog veka. Meutim, zvanini nastanak agilnih metoda se vezuje za 2001.godinu i formiranje Agilne alijanse, neprofitne ogranizacije sa globalnim lanstvom, koja se zalae za primenu agilnih principa u procesu razvoja. Cilj alijanse je da softverska industrija postane produktivnija, humanija i da bude odriva.

Agilne metode su nastale kao otpor mnogim ranijim modelima procesa razvoja koji su pokuavali da nametnu neki oblik discipline u osmiljavanju softvera, projektovanju, implementaciji, testiranju i dokumentovanju. Osnovna agilna ideja je da se naglasi uloga fleksibilnosti u spretnom i brzom razvoju softvera.

Nove, agilne principe razvoja za koje se zalae, Agilna alijansa je objavila u

Manifestu agilnog razvoja softvera (Manifesto for Agile Software Development, februar 2001.). Svaki princip formulisan je tako da jasno pokazuje ta se u agilnom razvoju vie vrednuje (oznaeno kurzivom):


pojedinici i interakcije od procesa i alata. U agilnom razvoju, samoorganizovanje i motivacija lanova razvojnog tima su izuzetno vani, kao i njihova interakcija. Oni imaju primat u odnosu na procese i alate koji se koriste u razvoju. Filozofija agilnog razvoja u prvi plan stavlja kvalitet pojedinaca i kvalitet njihove saradnje. Smatra se da je dovoljno razvojnom timu obezbediti potrebne resurse, a onda treba imati poverenje u njega da e dobro odraditi svoj posao. Komunikacija u okviru razvojnog tima se ostvaruje direktno, licem u lice, a ne posredstvom dokumentacije. U agilnom razvoju je poeljno da razvojni tim bude iskusan i usklaen tokom rada na ranijim projektima, jer je tada razvoj softvera najefikasniji.

primenljiv softver od detaljne dokumentacije. Po ovom agilnom principu, bolje je utroiti vreme na izradu softvera koji radi, nego na pisanje detaljne dokumentacije. Na primer, na sastancima sa kupcem, prioritet se uvek daje prezentaciji softvera u odnosu na opise i izvetaje u papirnoj formi. Merilo uspenosti projekta je do koje mere softver realizuje potrebnu funkcionalnost.

saradnja sa kupcem od ugovornih aranmana. Poto zahtevi obino ne mogu u potpunosti da budu prikupljeni na poetku razvoja softvera, stalna saradnja sa kupcem je od velikog znaaja. Zajednikim radom, kupac se ukljuuje u glavne aspekte razvoja.

reakcija na promene od pridravanja plana. Agilni razvoj se fokusira na brzo odgovaranje na sve promene uz dalje nastavljanje procesa razvoja. Smatra se da, u sluaju potrebe za nekom izmenom, ne treba troiti vreme na replaniranje i praenje plana, ve se treba odmah usredsrediti na izvoenje izmene.

Postoji veliki broj razliitih agilnih metoda koje potuju principe navedene u Manifestu. Neke od njih su:

XP Extreme Programming. Obuhvata skup tehnika u kojima se naglaava kreativnost timskog rada uz minimizaciju prekomernog administriranja.

Scrum. Propisuje naine upravljanja zahtevima, iteracijama razvoja, implementacijom i isporukom.

Crystal. Predstavlja familiju metodologija koje se fokusiraju na razvojni tim, a ne na procese i meuproizvode. Smatra se da svaki projekat zahteva razliite dogovore i metodologije i da najvei uticaj na kvalitet softvera ima razvojni tim. Produktivnost na projektu se poveava dobrom komunikacijom i estim isporukama, ime se smanjuje potreba za meuproizvodima.

Agilne metode 35

ASD Adatptive Software Development. Zasniva se na est principa, od kojih prvi predstavlja misiju koja postavlja cilj razvoja, ali ne propisuje nain na koji e cilj biti ostvaren. Poto su za naruioca najvanija svojstva softvera, projekat se organizuje tako da realizuje komponente koje implementiraju svojstva. Razvoj se odvija u vie iteracija, pri emu sve imaju podjednaku vanost. Izmene koje treba uraditi ne posmatraju se kao greke, ve kao prilagoavanje sistema realnim uslovima razvoja. Fiksno vreme isporuke nalae razvojnom timu da redukuje zahteve u svakoj verziji sistema. Rizik se prihvata, tako da razvojni tim najpre reava najtee probleme.

2.2.1 Ekstremno programiranje

Ekstremno programiranje (XP) je agilni metod koji je predloio Kent Beck 1996.godine. Uglavnom ga koriste manji i srednji razvojni timovi koji imaju od 6 do 20 lanova. Tim koji razvija softver na ovaj nain ima dobru saradnju sa klijentima i sve napore usmerava ka kratkim iteracijama koje korisnicima daju direktan i koristan rezultat. Ovakav pristup ide na utrb planiranju i izradi obimne dokumentacije na projektu.

XP ne propisuje strogu metodologiju koje se razvojni tim mora pridravati, ve samo daje uzore koji timu ostavljaju mogunost izmene procedura ili redosleda izvoenja pojedinih aktivnosti. Ovaj nain razvoja softvera uvodi etiri elementa koji se meusobno dopunjuju: osnovne vrednosti, principe, aktivnosti i prakse. Centralni deo predstavljaju osnovne vrednosti koje se postiu prihvatanjem principa. Principi se sprovode pomou skupa mehanizama koji se koriste u praksi. Sve navedeno se ogleda u aktivnostima rada razvojnog tima.

U ekstremnom programiraju je od velikog znaaja da razvojni tim bude

upoznat sa osnovnim vrednostima razvoja i da ih prihvati. Ove vrednosti potuju agilne vrednosti i dalje ih nadograuju. U osnovne vrednosti XP-a spadaju:

komunikacija. Izrada softvera zahteva intenzivnu komunikaciju izmeu lanova razvojnog tima. Za razliku od formalnih metoda, kod kojih se komunikacija uglavnom zasniva na razmeni dokumenata, kod XP-a je cilj da se, to je mogue bre, znanje rairi meu lanovima tima, kako bi svi imali isti pogled na sistem (pogled slian korisnikovom). Uspeh projekta je mogu samo ako se znanje nesmetano prenosi unutar tima.

jednostavnost. U XP-u se uvek polazi od jednostavnih reenja koja se kasnije mogu nadograditi, ukoliko je to potrebno. Dakle, ne troi se unapred vreme na izradu optijih i sloenijih reenja, koja moda nikad


nee u potpunosti biti iskoriena. To odgovara YAGNI principu po kome ne treba praviti neto to trenutno nije potrebno.

povratna sprega. Veoma je vano da se u svakom trenutku zna u kakvom je stanju sistem koji se razvija. Ova informacija se moe dobiti jedino zahvaljujui raznim povratnim spregama: programer-sistem, programer-programer, korisnik-sistem, korisnik-programer. Povratne sprege su vie praktine nego verbalne prirode, jer neposredno ukazuju na konkretne probleme u razvoju.

hrabrost. Hrabrost podrazumeva stalno prihvatanje rizika i promena. U direktnoj je vezi sa samopouzdanjem lanova tima i poverenjem u razvojni tim. Hrabrost pomae timu da se u nekim situacijama opredeli za odbacivanje dela posla koji je ve uradio i otpone neto iznova. To je i posveenost blagovremenim i estim isporukama funkcija, to nije jednostavno. Pri svakoj isporuci mora se dobro razmisliti i proveriti ta se isporuuje.

potovanje. Svaki lan razvojnog tima mora da potuje sebe i druge. U svom radu mora da se trudi da postigne visok kvalitet ne ugroavajui rad drugih. Na primer, programer ne moe da unosi izmene koje postojee testove ine pogrenim. Ili, ne moe svojim poslom da prouzrokuje zakanjenje drugih. Niko u timu ne sme da se osea zapostavljenim ili manje vrednim.

Navedene vrednosti su meusobno povezane i imaju veliki uticaj jedne na druge. One predstavljaju osnovne kriterijume po kojima se moe sagledati uspenost posla. Ipak, suvie su opte da bi se na osnovu njih mogli definisati praktini mehanizmi koji bi obezbedili uspenost. Zato su uvedeni principi koji otkrivaju razliite alternative koje slue za odluivanje, a ukljuuju osnovne vrednosti.

Principi XP-a proistiu iz Manifesta agilne metodologije, uz dodatna

proirenja. Oni predstavljaju osnovu XP-a. Konkretniji su od osnovnih vrednosti i mogu se lake prevesti u smernice razvoja u praktinim situacijama. Principi XP-a su:

povratna sprega. U XP-u je vano da vreme potrebno za dobijanje povratnih informacija bude kratko, jer je ono kritino za sticanje novih znanja i obavljanje izmena. Zato su kontakti sa korisnicima znatno ei nego kod tradicionalnih metoda.

pretpostavljena jednostavnost. XP odbacuje planiranje i kodiranje u svrhu ponovne upotrebe kda, koji su karakteristini za tradicionalne metode. U

Agilne metode 37

XP-u, reenje svakog problema se posmatra kao ekstremno jednostavno. Vreme koje se na ovaj nain utedi, znatno prevazilazi vreme koje se izgubi u retkim sluajevima kada to nije tano. Tei se malim izmenama i estim isporukama, zato to korisnik tako ima bolji uvid u razvoj projekta, to je s druge strane korisno i za razvojni tim.

prihvatanje promena. Svaka izmena se prihvata ma koliko bila velika. Strategija menjanja nalae da se najpre izvode izmene koje reavaju najvanije probleme, a zatim se prelazi na manje vane izmene.

kvalitet rada. Uspeh projekta je jedino mogu ako se svi lanovi razvojnog tima maksimalno zalau, tj. rade svoj posao najbolje to mogu. U takvoj radnoj atmosferi, svi dobijaju nove motive, stimuliu jedni druge i postaju zadovoljniji svojim poslom.

Iz navedenih principa proistiu odluke koje se obaveznim praksama prevode u aktivnosti na projektu. Razvojni tim mora vrlo disciplinovano, tj. skoro do ekstrema, da primenjuje obavezne prakse, odakle i potie naziv ovog agilnog metoda.

Pod obaveznim praksama se podrazumeva skup praktinih mehanizama pomou kojih se izvode aktivnosti u XP procesu razvoja softvera. Ovaj skup sadri sledee prakse:

programiranje u paru. Podrazumeva rad dvoje programera istovremeno na istom raunaru. Poto reavaju isti zadatak, jedan programer pie programski kd i razmilja o detaljima konkretne implementacije, dok drugi kontrolie napisani kd imajui u vidu iri kontekst reenja. Programeri povremeno razmenjaju svoje uloge. Parovi nisu fiksni, ak je bolje ukoliko se ee menjaju lanovi para. Na taj nain, svaki lan tima upoznaje ceo sistem i delove posla koji rade drugi lanovi tima, ime se poboljava komunikacija na projektu. Dobra strana ovakvog programiranja je i ta to, ukoliko neki lan napusti tim, drugi mogu lako da preuzmu njegov posao, bez veih poremeaja na projektu.

igra planiranja. Ovo je glavni proces planiranja u XP-u. Igra se odvija na sastanku koji se odrava jednom po iteraciji (obino na nedeljnom nivou). Tokom igre se generiu mape svih buduih verzija (sadraj verzije i rokovi isporuke). Proces planiranja obuhvata dve aktivnosti. Prva je utvrivanje zahteva koji su ukljueni u dolazeu verziju i vreme njene isporuke. Ovo planiranje izvode zajedno razvojni tim i klijenti. Drugu vrstu planiranja vri samo razvojni tim. Cilj ovog planiranja je da se utvrde i rasporede dalji zadaci na projektu i procene termini do kada oni treba da budu zavreni.


razvoj voen testovima. U XP-u, testovi se piu pre pisanja kda. Ovakav pristup stimulie programere da prilikom kodiranja vode rauna o uslovima u kojima e njihov kd biti testiran. Istestiranim kdom se smatra onaj kd koji se vie ne moe nai u uslovima u kojima ne bi radio ispravno.

celovitost tima. Klijent nije samo onaj ko plaa razvoj softvera, ve i neko ko e zaista koristiti sistem. Zato u XP-u korisnik treba permanentno da bude dostupan za razna pitanja razvojnog tima. Dobro je da se u tim ukljui i neko od strane korisnika. Na primer, ako se razvija softver za finansijske poslove, u tim se moe ukljuiti raunovoa.

stalna integracija. Razvojni tim uvek treba da radi na aktuelnoj (poslednjoj) verziji softvera. Poto lanovi tima istovremeno rade na razliitim delovima kda, unete izmene i poboljanja obino uvaju na lokalnim raunarima. Zato je potrebno da se to ee (svakog sata ili na par sati) radi integracija sistema ukljuivanjem najnovijeg kda generisanog od strane svih lanova tima u aktuelnu verziju. Postoje specijalizovani softveri koji omoguavaju ovakav rad. Stalnom integracijom, izbegava se kanjenje u kasnijim fazama projekta zbog problema u integraciji.

poboljanje dizajna (refaktorizacija). Uzimanje u obzir samo trenutnih potreba i jednostavna reenja (karakteristina za XP) mogu da dovedu do problema u razvoju. Oni se manifestuju, na primer, u neophodnom multipliciranju kda pri dodavanju neke nove funkcionalnosti, ili u irokom uticaju uinjenih izmena u jednom delu kda na mnoge druge delove kda. Ako se pojave ovakvi problemi, to je u XP-u znak da treba uraditi refaktorizaciju kda uz menjanje arhitekture i njeno uoptavanje.

male verzije. Razvoj se vri u malim iteracijama, ime se smanjuju trokovi izmena i neophodnosti odbacivanja neodgovarajuih reenja. Svaka nova verzija daje se korisniku na upotrebu, ime se on aktivno ukljuuje u proces razvoja.

standardi kodiranja. Standardi kodiranja podrazumevaju specifikaciju konzistentnog stila i formata izvornog kda, uz potovanje prirode izabranog programskog jezika. Moraju da ih se pridravaju svi lanovi razvojnog tima. Uvoenjem standarda izbegnuto je prilaavanje na tui stil programiranja, to esto oduzima mnogo vremena. Standardi, takoe, doprinose i boljem razumevanju u timu.

kolektivno vlasnitvo kda. Kolektivno vlasnitvo kda podrazumeva da je svaki lan razvojnog tima odgovoran za kompletan kd. Istovremeno, svako moe da menja bilo koji deo kda u sistemu. Na ovaj nain se izbegava bavljenje pogrenim idejama i reenjima i smanjuje otpor prema

Agilne metode 39

promenama. Kd se bre razvija, jer svaku greku moe da otkloni bilo koji programer. Meutim, davanjem mogunosti svakom programeru da menja kd, uvodi se rizik da programer unese greku u sistem zbog nesagledavanja nekih zavisnosti koje postoje. To se reava definisanjem dobrih testova.

jednostavan dizajn. U XP-u, prilikom pisanja kda, programer treba uvek da se pita da li postoji jednostavniji nain da se realizuje zahtevana funkcionalnost. Ako postoji, treba izabrati taj nain. Takoe, treba koristiti i refaktorizaciju da bi neki sloeni kd postao jednostavniji.

metafora. Tim razvija svoj renik i terminologiju za obeleavanje osobina sistema i korienih elemenata. Na taj nain se olakava prepoznavanje emu koja komponenta u sistemu (klasa, metoda i sl.) slui i postie usaglaenost oko vizije rada sistema na nivou razvojnog tima. Pojaava se i oseanje pripadnosti timu.

odriv korak. Na projektu je neophodno uspostaviti harmonini ritam rada odriv u duem vremenskom periodu (dok traje projekat). To se moe postii potovanjem 40-asovne radne nedelje. Prekovremeni rad se u XP-u izbegava, jer se smatra da umorni ljudi vie gree. Ukoliko ovakvo radno vreme nije dovoljno za uspenu realizaciju projekta, onda projekat nije dobro ugovoren, tj. rokovi ili resursi nisu dobro procenjeni.

Da bi softver bio realizovan, potrebno je definisati konkretne aktivnosti koje razvojni tim treba da izvri. Aktivnosti su usmerene ka postizanju visokog kvaliteta u to kraem vremenu i uz to manje trokove. One se sprovode na nain koji je striktno propisan obaveznim praksama.

Aktivnosti ekstremnog programiranja su:

kodiranje. U XP-u, jedini zaista vaan proizvod procesa razvoja jeste programski kd. Ukoliko se ne proizvede kd, smatra se da nema nikakvog rezultata. Programski kd je vrlo jasan, precizan, nedvosmislen i zato se ne moe izvravati na vie naina. U mnogim sluajevima, kd pomae u komunikaciji, kako izmeu programera pri razjanjavanju problematinih situacija, tako i izmeu programera i raunara. Programski kd izraava ne samo ideje za reavanje problema, ve i testove za proveru ispravnosti, primenjene algoritme, itd.

testiranje. Testiranju u XP-u se posveuje velika panja zato to se smatra da ako testiranje malog obima otklanja izvestan broj greaka, testiranje velikog obima eliminie mnogo vie greaka. Generiu se jedinini testovi i testovi prihvatanja. Jedinini testovi proveravaju da li je neka osobina


sistema realizovana na odgovarajui nain. Broj ovih testova za datu osobinu nije ogranien, ve se testovi piu dok god se moe zamisliti situacija u kojoj kd ne bi ispravno radio. Testovi prihvatanja slue za proveru da li zahtevi, onakvi kako ih je razumeo programer, odgovaraju stvarnim zahtevima korisnika.

sluanje. Poto programeri u poetku ne moraju nita da znaju o poslovnoj logici koju sistem realizuje, neophodno je da aktivno sluaju klijenta kako bi se upoznali sa njom. Pri tome, programeri treba da ukazuju klijentu na to ta je lake, a ta tee, realizovati i iz kojih razloga. Iz estih razgovora sa klijentima, treba dobiti to vie korisnih informacija koje bi doprinele boljem razumevanju sistema.

projektovanje. Uproeno posmatrano, u XP-u je dovoljno sprovesti prethodne tri aktivnosti da bi se dobio finalni sistem, tj. programski kd. Meutim, u praksi, to nije tako. Moe se desiti da se proe dug put u razvoju sistema, a onda da se pojavi nereiv problem. Sistem moe da postane previe sloen, a zavisnosti u njemu vrlo nejasne. Problem se moe prevazii projektovanjem strukture koja na organizovan nain opisuje logiku sistema. Tako se otklanjaju mnoge zavisnosti u sistemu, jer je sistem tako organizovan da izmene u jednom delu ne utiu u velikoj meri na ostale njegove delove.

Ekstremno programiranje nalazi sve iru primenu u razvoju softvera. Prednosti ovakvog razvoja su evidentne kako za razvojni tim, tako i za kupce i menadment projekta.

XP doputa razvojnom timu da se fokusira na izradu softvera, ne vodei mnogo rauna o dokumentaciji i sastancima. Radna atmosfera je prijatnija, ima mnogo mogunosti za uenje i dalje napredovanje, a radno vreme je ogranieno na osam sati dnevno.

Krae vreme razvoja softvera, uz relativno malo nedostataka pogoduju kupcima. Oni mogu da promene svoje miljenje uz minimalne trokove i malo prigovora od strane razvojnog tima.

Sa stanovita menadmenta projekta, XP generie dobar softver po prihvatljivoj ceni. Rizik je smanjen time to se izmene prihvataju u svakom trenutku razvoja, uz permanentno postojanje validnog radnog kda. Osim toga, ne postoji zavisnost od pojedinaca koji bi bili nezamenljivi na projektu, to stvara bolje odnose u timu, pa lanovi tima ree odlaze.

Osnovni nedostaci ekstremnog programiranja su:

metod se teko sprovodi

Agilne metode 41

nije lako nai dovoljan broj programera koji bi prihvatili i izvodili obavezne prakse, jer to zahteva strogu disciplinu

klijentima ne mora da odgovara ideja da budu ukljueni u projekat, jer imaju druge obaveze

teko je uklopiti razliite karaktere lanova razvojnog tima u skladnu celinu koja bi mogla savreno da funkcionie

Prvi korak u procesu razvoja nekog softvera je evidentiranje zahteva koje taj softver treba da ispuni. Skup zahteva nastaje kao rezultat analize koju treba sprovesti u cilju razumevanja osnovnih problema i potreba naruioca. Analiza podrazumeva intenzivnu saradnju sa naruiocima, a posebno sa korisnicima softvera. Od uspenosti ove analize u mnogome zavisi ishod celog projekta razvoja softvera. Grupa Standish je 1994.godine obavila istraivanje u vezi sa ishodima vie od 8000 softverskih projekata u preko 350 softverskih kompanija. Doli su do saznanja da je oko 35% projekata otkazano pre nego to je zavreno, a da je samo 9% projekata isporueno na vreme i u okviru planiranog budeta. Pokazalo se da su razlozi za ovako loe rezultate uglavnom u direktnoj vezi sa definisanjem i upravljanjem zahtevima. Naime, proces definisanja zahteva je prilino sloen i ne predstavlja samo jednostavno navoenje zahteva koje softver treba da ispuni. On zahteva paljivu analizu kako bi se na pravi nain shvatili pojedinani zahtevi, kao i veze koje postoje izmeu njih. Problemi u vezi sa zahtevima mogu da nastanu iz dva razloga. Prvo, ukoliko skup zahteva nije potpun ili nije adekvatno definisan, to direktno ugroava uspenost projekta. Drugo, u praksi je esto nemogue definisati kompletan i dovoljno precizan skup zahteva na samom poetku rada na projektu, jer postoji realna mogunost pojave novih zahteva u kasnijim fazama projekta. U ovom sluaju, razvojni tim treba da bude sposoban i spreman da na pravi nain odreaguje na pojavu novih zahteva kako projekat ne bi bio ugroen. Boehm i Papaccio su 1988.godine sproveli istraivanje koje je pokazalo da otkrivanje i otklanjanje greaka u zahtevima u kasnijim fazama projekta ima vrlo visoku cenu. Naime, otklanjanje iste greke u fazi projektovanja sistema kota pet puta vie nego u fazi definisanja zahteva, u fazi pisanja programa deset puta vie, a ako je greka otkrivena nakon isporuke softvera ak dve stotine puta vie.

Zahtevi koje softver treba da ispuni mogu da budu vrlo raznovrsni, da potiu iz razliitih izvora, pa ak da budu i kontradiktorni. Stoga je vano da se pravilno

3 Analiza zahteva

44 Analiza zahteva

odabere metod specifikacije zahteva koji odgovara razmatranom projektu. Na izbor metoda utiu razni faktori, kao to su obim projekta, njegova sloenost i vanost. Od sutinskog znaaja je da na kraju ove faze u procesu razvoja softvera budemo sigurni da su zahtevi ispravno definisani i da je njihov skup potpun u skladu sa trenutnim uslovima.

Prilikom naruivanja softvera, naruilac ima optu ideju ta bi taj softver

trebalo da radi. Potreba za softverom obino nastaje u sledeim sluajevima:

kada treba automatizovati poslove koji su se do tada obavljali runo (na pr. elektronsko plaanje rauna, elektronsko naruivanje robe i sl.)

kada treba poboljati ili proiriti postojei sistem (na pr. dodavanje novih usluga u postojei telefonski sistem, proirivanje skupa moguih naina kreditiranja i sl.)

kada treba napraviti sistem koji obavlja neki posao koji do tada nije raen (na pr. automatsko kontrolisanje doziranja nekog leka, elektronsko izdavanje novina i sl. )

Bez obzira kako je nastala potreba za softverom, tj. da li se radi o potpuno

novom softveru ili o izmeni postojeeg, softver poseduje namenu i ciljeve koje treba da ispuni.

Zahtev predstavlja izraz eljenog ponaanja softvera. Prilikom definisanja

zahteva, razmatraju se osobine objekata i entiteta koji postoje u datom sistemu, stanja u kojima se objekti i entiteti mogu nai, kao i funkcije koje omoguavaju promene stanja ili osobina objekata. Na primer, pretpostavimo da je potrebno razviti softver za obraun plata u kompaniji naruioca. Jedan od zahteva bi mogao da bude da se svakog meseca tampaju liste sa obraunom zarade za svakog radnika. Drugi zahtev moe da bude mogunost uplate stimulacije za radnike koji se posebno istiu, a trei zahtev da se sistemu moe pristupati sa vie razliitih lokacija u kompaniji. Navedeni zahtevi opisuju pojedinane funkcije sistema koje su u direktnoj vezi sa optom namenom sistema, tj. obraunom plata.

Zahtevi mogu da identifikuju objekte ili entitete u sistemu (na pr. Radnik je osoba koja radi u kompaniji.), da definiu ogranienja za pojedine entitete (na pr. Radnik ne moe biti plaen za vie od 40 sati rada nedeljno.), ili da opisuju odnose izmeu entiteta (na pr. Radnika X nadgleda radnik Y, ukoliko je Y ovlaen da izmeni zaradu koju prima X.). Posebno je vano ustanoviti nain interakcije sistema sa okruenjem.

Cilj analize zahteva je da se precizno ustanovi kakvo ponaanje naruilac

oekuje od softvera. Pri tome se uopte ne vodi rauna (osim ako naruilac to

Documents

US - Razvoj Aplikativnog Softvera