US - Razvoj Aplikativnog Softvera

0NIvERZITETSINuIB0N0N
violeta Tomasevic
RAZVOJ APLIKATIVNOG
SOFTVERA
Pivoizuanje
Beogiau,2u12.
RAZVOJ APLIKATIVNOG SOFTVERA
Autor:
ui violeta Tomasevic
Recenzenti:
ui Bosko Nikolic
ui Bejan Zivkovic
ui Iiina Bianovic
lzJovoc
0NIvERZITETSINuIB0N0N
Beogiau,BanijelovaS2
www.singiuunum.ac.is
Zo izJovoco
ui Nilovan Stanisic
Pripremozotompu:
violeta Tomasevic
0izojnkorico:
Aleksanuai Nihajlovic
6oJinoizJonjo:
2u12.
Tiro
Suupiimeiaka
tampa:
Nlauostuiup
Loznica
ISBN:978-86-7912-4S7-1
Copyiight:
2u12.0niveizitetSingiuunum
Izuavac zauiava sva piava
Repiouukcijapojeuinihuelovailicelineovepublikacijenijeuozvoljeno.

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
A
n
a
l
i
z
a

p
r
o
b
l
e
m
a
S
i
n
t
e
z
a

r
e
e
n
j
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:
x neovlaena upotreba sistema
x trite softvera
x 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:
x kupac
x razvojni tim
x 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:
x 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.
x projektant projektuje, tj. dizajnira sistem prema zadatim funkcionalnim
zahtevima, tako da kasnije programeri mogu lako da ga implementiraju.
x programer pie programski kd na odgovarajuem programskom jeziku
koristei predvieno razvojno okruenje. Kd mora da odgovara projektu
sistema uraenom na osnovu korisnikih zahteva.
x 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

x 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:
x 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.
x 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.
x 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.
x izrada programa. Ovo je faza direktne izrade softvera u kojoj programeri
piu programski kd prema uraenom projektu.
x 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.
x isporuka sistema. U ovoj fazi, sistem se isporuuje naruiocu, softver se
instalira u radnom okruenju i obavlja se obuka neposrednih korisnika.
x 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:
x 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
x modelovanje odraava ciljeve razvoja; na osnovu modela, projektni tim,
pre pisanja softvera, moe da oceni predviene aktivnosti sa aspekta
njihove usklaenosti sa postavljenim zahtevima
x modelovanje pomae u nalaenju nedoslednosti, suvinih ili izostavljenih
elemenata, to poboljava efikasnost procesa razvoja
x 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:
x jednostavnost. Visok nivo apstrakcije modela olakava komunikaciju sa
kupcima koji ne moraju da budu upoznati sa procesom razvoja softvera.
x 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.
x 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:

x 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).
x 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).
x 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.
x 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:
x 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.
x 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.
x generie kvalitetan proizvod. V model predstavlja strogo kontrolisan
proces razvoja, tako da se moe garantovati dobar kvalitet softverskog
proizvoda.
x 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:
x 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.
x 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
R
a
z
v
o
j
n
i

t
i
m
K
o
r
i
s
n
i
c
i
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:
x 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.
x 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.
x 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.

x 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:

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

x 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 1
transformacija 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 alternative
O ogranienja
R analiza rizika
P prototip
Z
a
h
t
e
v
i
V
a
lid
a
c
ija

z
a
h
te
v
a
D
i
z
a
j
n

s
o
f
t
v
e
r
a
V
a
lid
a
c
ija
i
v
e
rifik
a
c
ija
d
iz
a
jn
a
D
e
t
a
l
j
a
n

d
i
z
a
j
n
K
o
d
i
r
a
n
j
e
T
e
s
tir
a
n
je

s
is
te
m
a
Zahtevi,
plan razvoja
Plan razvoja
Integracija i
plan testiranja
O 1 R 1
P 1
A 2
O 2 R 2
P 2
A 3
O 3 R 3
P 3
A 4
O 4 R 4
P 4
T
e
s
t
i
r
a
n
j
e

d
e
l
o
v
a
Zavrno
testiranje
Plan isporuke
1 2
3 4

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

x 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.
x 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:
x ograniena primena. Spiralni model najbolje funkcionie u sluaju velikih
i sloenih projekata, dok za manje projekte nije pogodan.
x 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.
x 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:
x uloge (ko), koje definiu skup povezanih vetina, sposobnosti i
odgovornosti
x proizvodi rada (ta), koji predstavljaju rezultat nekog zadatka, ukljuujui
modele, proizvode, dokumentaciju i sl.

x 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:
x faza zapoinjanja (Inception Phase)
x faza razrade (Elaboration Phase)
x faza konstrukcije (Construction Phase)
x 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
Zahtevi
Analiza i
projektovanje
Implementacija
Testiranje
Isporuka
Konfiguracija
i izmene
Upravljanje
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:

x visok nivo prilagodljivosti konkretnom projektu, jer RUP nita ne zahteva,
ve samo preporuuje
x iterativnost procesa koja omoguava postepen razvoj sistema, to vodi
smanjenju trokova i vremenskim utedama
x upravljanje rizicima to usmerava razvoj ka niim trokovima

Glavni nedostaci RUP-a su:
x neprilagoenost malim projektima kod kojih faze zapoinjanja i razrade
gube na znaaju
x 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):

x 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.
x 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.
x 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.
x 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:
x XP Extreme Programming. Obuhvata skup tehnika u kojima se naglaava
kreativnost timskog rada uz minimizaciju prekomernog administriranja.
x Scrum. Propisuje naine upravljanja zahtevima, iteracijama razvoja,
implementacijom i isporukom.
x 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

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

x 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.
x 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.
x 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.
x 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.
x 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.
x 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.
x 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.
x 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.
x 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.
x 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:
x 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.
x 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.
x 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.
x 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:
x metod se teko sprovodi
Agilne metode 41

x nije lako nai dovoljan broj programera koji bi prihvatili i izvodili
obavezne prakse, jer to zahteva strogu disciplinu
x klijentima ne mora da odgovara ideja da budu ukljueni u projekat, jer
imaju druge obaveze
x 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:
x kada treba automatizovati poslove koji su se do tada obavljali runo (na pr.
elektronsko plaanje rauna, elektronsko naruivanje robe i sl.)
x kada treba poboljati ili proiriti postojei sistem (na pr. dodavanje novih
usluga u postojei telefonski sistem, proirivanje skupa moguih naina
kreditiranja i sl.)
x 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
Analiza zahteva 45

eksplicitno ne zahteva) o tome kako e to ponaanje biti implementirano u sistemu.
To znai da se u ovoj fazi ne razmatra izbor tehnologije u kojoj e sistem biti
realizovan, izbor baze podataka, arhitekture sistema koja e se koristiti i sl.
Tokom analize, zahtevi se obino izraavaju opisima iz realnog okruenja
naruioca, bez upotrebe strunih termina koji e biti korieni u sistemu. Na
primer, zahtevi u vezi sa obraunom plata referiu se na radnike, stimulacije i dr., a
ne na sistemske procedure i podatke. Razlog za ovakvo izraavanje zahteva je u
elji da se ostvari to bolje razumevanje sa naruiocem, kako bi se izbegla razliita
tumaenja istih osobina i pojava. Naruiocu je lake da svoje potrebe iskae u
kategorijama sopstvenog poslovanja, dok projektanti moraju da se prilagode
naruiocu. Meutim, i projektanti ovakvim pristupom dobijaju odreene
pogodnosti. Njima je ostavljena maksimalna fleksibilnost u odluivanju kako e
sistem ispuniti postavljene zahteve (bez ikakvog uticaja naruioca).

Analizu zahteva izvodi analitiar zahteva. Tokom analize, analitiar zahteva
treba da obavi sledee aktivnosti:
x prikupljanje zahteva. Analitiar prikuplja zahteve kroz razgovor sa
naruiocem, itanjem dostupnih materijala koji su od interesa,
posmatranjem aktuelnih ponaanja u okruenju i dr.
x modelovanje ponaanja. Evidentirane zahteve analitiar analizira i formira
model ili prototip ponaanja sistema. Model mu pomae da bolje razume
zahteve i njihove meusobne veze. U ovoj aktivnosti esto se otvaraju nova
pitanja koja je potrebno razmotriti sa naruiocem, a koja nisu bila predmet
prethodne aktivnosti.
x specifikacija zahteva. Poto je postignuto dobro razumevanje zahteva,
prelazi se na izradu specifikacije u okviru koje se definie koji e delovi
zahtevanog ponaanja biti implementirani u softveru.
x validacija i verifikacija zahteva. U ovoj aktivnosti se proverava da li
specifikacija odgovara onome to naruilac oekuje od softverskog
proizvoda. Ovde se mogu otkriti propusti u modelu ili specifikaciji koji se
reavaju ponovnom posetom naruiocu ili vraanjem na neku od
prethodnih aktivnosti.

Rezultat analize zahteva sprovedene kroz navedene aktivnosti je Specifikacija
softverskih zahteva (Software Requirements Specification SRS) koja se dalje
koristi za komunikaciju sa razvojnim timom. Postupak definisanja skupa zahteva je
prikazan na slici 3.1.

46 Analiza zahteva

Prikupljanje
zahteva
Modelovanje
ponaanja
Specifikacija
zahteva
Validacija
zahteva
Specifikacija
softverskih
zahteva
Faza: Analiza zahteva Rezultat faze

Slika 3.1 Definisanje skupa zahteva

U nastavku je detaljno razmotrena svaka od navedenih aktivnosti.

3.1 Prikupljanje zahteva

Prikupljanje zahteva predstavlja izuzetno vanu aktivnost u procesu
definisanja zahteva, jer se tokom nje utvruje ta naruioci i korisnici stvarno ele.
Tehnike koje se tom prilikom koriste mogu biti razliite.
Ukoliko narueni softver treba da automatizuje neki posao koji se do tada
obavljao runo, ili se radi o poboljanju postojeeg sistema, do skupa zahteva moe
se doi na relativno lak nain. Analitiar zahteva treba najpre da proui proces
obavljanja posla, a zatim da, postavljanjem pravih pitanja, od korisnika dobije
odgovore koje moe da pretoi u zahteve.
Meutim, ako je problem potpuno nov, neophodna je intenzivnija saradnja sa
naruiocima i korisnicima, poto oni nemaju praktina iskustva u vezi sa
problemom. Naruilac poznaje svoj posao, ali ne moe uvek na pravi nain nekome
sa strane da opie svoje poslovne probleme. Nekad mu je teko da dovoljno
precizno iskae ono to mu treba, pri tome moe da koristi argonske rei ili
pretpostavke sa kojima drugi nisu bliski. S druge strane, ni analitiar zahteva ne
moe uvek dovoljno dobro da shvati tue poslovne probleme, jer ne mora dobro da
poznaje domen poslovanja. I on moe da koristi sopstveni argon ili strune
termine koji nisu bliski naruiocu. Imajui ovo u vidu, u ranoj fazi projekta, deava
se da su zahtevi nedovoljno dobro formulisani ili pogreno shvaeni.
Da bi se dolo do dobro definisanog skupa zahteva, neophodno je najpre, u
zajedniom dogovoru, uskladiti korienu terminologiju. Ukoliko se ne postigne da
i naruilac i analitiar tumae isti termin na isti nain, projekat je osuen na
neuspeh.
Prikupljanje zahteva 47

Iako veina analitiara smatra da treba da se tei formiranju to potpunijeg i
doslednijeg skupa zahteva, postoje i drugaija miljenja. Easterbrook i Nuseibeh su
1996.godine dokazivali da je esto bolje tolerisati nedoslednosti koje se pojave
prilikom definisanja zahteva, a u nekim sluajevima ih ak i podsticati. Oni
smatraju da je u ranoj fazi procesa definisanja zahteva besmisleno ulagati veliki
trud u rezreenje nadoslednosti, jer to moe biti teak, skup, a ponekad i nemogu
posao. Razlog za ovakvo miljenje je u tome to se tokom projekta kod svih
uesnika akumulira znanje iz date oblasti, ime se poboljava razumevanje
problema. Nedoslednosti treba uoiti, ali se njima ne treba baviti dok ne bude
dovoljno informacija za donoenje prave odluke. Na ovaj nain se izbegavaju i
greke vezane za fazu projektovanja sistema.

U procesu prikupljanja zahteva, osim ve pomenutih, naruioca, korisnika i
analitiara zahteva, vanu ulogu mogu da imaju i drugi zainteresovani subjekti, kao
na primer, strunjaci iz konkretne oblasti primene razmatranog softvera (pri
obraunu zarada mogu se konsultovati poreski strunjaci), istraivai trita
(odreuju budue trendove i potrebe potencijalnih korisnika), softverski inenjeri
(mogu naruiocu da preporue nove funkcionalnosti koje su dostupne zahvaljujui
novim hardverskim i softverskim tehnologijama) i dr. Svaki od ovih subjekata ima
svoj pogled na sistem, pri emu ovi pogledi ponekad mogu da budu i protivreni.
Na primer, korisnik moe da zahteva lako korienje sistema, a da to povlai za
sobom znatno sporiji rad, to je neprihvatljivo sa inenjerskog aspekta posmatranja.
Analitiar zahteva mora da razume svaki pogled i da formulie zahteve tako da
odraavaju interese svih uesnika. Pri tome, treba da ima u vidu i brojne
predrasude, kako korisnika i naruioca, tako i projektanata sistema. Na primer,
korisnici obino misle da projektanti ne razumeju operativne probleme, stavljaju
preveliki naglasak na tehnika pitanja, pokuavaju da korisnicima nametnu kako
treba da rade svoj posao i sl. Nasuprot tome, projektanti esto vide korisnike kao
nedovoljno sposobne da formuliu svoje potrebe, da im dodele prioritete, da
preuzmu odgovornost za sistem i sl. Iz ovoga sledi da dobar sistem analitiar najpre
mora da ima izuzetno dobre meuljudske odnose sa svim uesnicima u projektu, a
takoe, da ima i odgovarajua tehnika znanja i sposobnosti.

U fazi prikupljanja zahteva, analitiar zahteva koristi razliite tehnike:
x razgovor sa zainteresovanim subjektima, uz postavljanje pitanja i dobijanje
odgovora; dobra praksa je razgovor u grupama, jer uesnici postaju
inspirisani idejama drugih
x pregledanje raspoloive dokumentacije, kao to su dokumentovane
procedure, korisnika uputstva za rad, razne vrste ema, i dr.
48 Analiza zahteva

x upoznavanje postojeeg sistema u cilju prikupljanja informacija o tome
kako korisnici zaista obavljaju predviene aktivnosti; vrlo je bitno
sagledati sistem u celini kako se ne bi desilo da se nakon isporuke novog
sistema pojedine aktivnosti i dalje obavljaju runo, jer ih projektanti
sistema nisu predvideli
x uenje posla od korisnika; dobro je da se analitiar detaljnije upozna sa
poslovima koje korisnik izvrava dok ih on radi
x upotreba strategija specifinih za datu oblast podrazumeva korienje
poznatih teorijskih znanja (na pr. strategija PIECES Wetherbe 1984. u
oblasti informacionih sistema) sa ciljem da zainteresovani subjekti vie
vode rauna o specifinostima zahteva u njihovoj konkretnoj situaciji
x poreenje sa slinim, ranije razvijenim sistemima ija iskustva mogu
znatno da poboljaju kvalitet softvera

3.1.1 Vrste zahteva

Prilikom formulisanja skupa zahteva, analitiar zahteva mora detaljno da
analizira ne samo potrebnu funkcionalnost sistema, ve i razne vrste ogranienja
koje sistem mora da ispuni. Mogu se izdvojiti sledee vrste zahteva:
x funkcionalni zahtevi. Ovi zahtevi opisuju ponaanje sistema, tj. daju
odgovore na pitanja ta sistem treba da radi, koje usluge treba da prui,
kakav je format ulaznih i izlaznih podataka, kako sistem treba da reaguje
na odreeni ulazni podatak, kako se menja ponaanje sistema u vremenu,
itd. Na primer, u sluaju obrauna plata, funkcionalni zahtevi definiu koji
su ulazni podaci neophodni za bi plate mogle biti obraunate, koliko esto
e biti tampani listii za plate, pod kojim uslovima se moe promeni iznos
za isplatu, koji su razlozi uklanjanja radnika sa platnog spiska i sl.
Funkcionalni zahtevi odreuju granice prostora reenja razmatranog
problema.
x zahtevi u pogledu kvaliteta. Ovi zahtevi opisuju koje osobine treba da ima
softver da bi se moglo rei da je prihvatljiv sa stanovita kvaliteta. Na
primer, moe se rei da je softver kvalitetan ukoliko ima kratko vreme
odziva, ako je pogodan za uenje i korienje, ako je pouzdan, ima niske
trokove odravanja i sl. Zahtevi u pogledu kvaliteta mogu da budu vrlo
detaljni i da se odnose na:
o performanse sistema (vreme izvrenja, vreme odziva, protok
podataka i dr.)

o upotrebljivost sistema (lakoa korienja, mogue vrste obuke,
mogunost neadekvatne upotrebe sistema i sl.)
o bezbednost sistema (kontrola pristupa, izolovanost podataka po
korisnicima, ifrovanje podataka, fizika bezbednost i sl.)
o pouzdanost i raspoloivost sistema (detekcija greaka, srednje vreme
izmeu otkaza, vreme za pokretanje sistema nakon otkaza,
povremeno pamenje kopija podataka i dr.)
o odravanje sistema (ispravljanje greaka, lakoa izvoenja manjih
izmena, mogunost znaajnijih izmena u cilju poboljanja sistema,
mogunost prelaska na drugu platformu i dr.)
o preciznost i tanost podataka.
x projektna ogranienja. Ova ogranienja nastaju kao posledica donetih
odluka na projektu. Na primer, jedno ogranienje je izabrana platforma na
kojoj e softver raditi. Projektna ogranienja se mogu odnositi na:
o fiziko okruenje (lociranje opreme, potrebni atmosferski uslovi u
smislu temperature, vlanosti i sl., napajanje, grejanje, klimatizacija i
dr.)
o povezivanje sistema sa okolinom (format ulaznih i izlaznih podataka,
interakcija sa drugim sistemima, nain preuzimanja i prosleivanja
podataka i sl.)
o implementaciju (izbor platforme, izbor programskog jezika,
koriene tehnologije i dr.)
x procesna ogranienja. Ova ogranienja se odnose na tehnike i resurse koji
e biti korieni u izgradnji sistema. Na primer, naruilac moe da insistira
na primeni agilnih metoda kako bi to ranije mogao da koristi odreene
delove sistema. Procesna ogranienja po pitanju resursa utvruju koji
materijali e biti korieni u realizaciji, koje osoblje e biti angaovano na
projektu, koje sposobnosti su neophodne za obavljanje odreenih poslova,
itd. Procesna ogranienja proistiu i iz odluke o potrebnoj dokumentaciji
(tipovi dokumenata, obim dokumenata, dokumentovanje na raunaru, u
papirnoj formi, ili oba).

Potovanje navedenih vrsta zahteva doprinosi suavanju prostora moguih
reenja problema, tako to se neka od njih proglaavaju prihvatljivim za realizaciju,
dok se druga mogu proglasiti neupotrebljivim.

50 Analiza zahteva

3.1.2 Razreavanje konflikata

Prilikom formulisanja skupa zahteva, analitiar zahteva pokuava da ispuni
elje svih zainteresovanih subjekata. Meutim, deava se da pojedini subjekti imaju
razliita miljenja o tome kakvi zahtevi treba da budu. Stoga je neophodno
ustanoviti mehanizam za razreavanja ovakvih konflikata.
Da bi nastali konflikti bili to jednostavnije reeni, potrebno je od naruioca
zahtevati da odredi prioritete postavljenih zahteva. U zavisnosti od prioriteta,
zahtevi se mogu klasifikovati u tri kategorije:
x sutinski zahtevi. Ovi zahtevi moraju da budu ispunjeni u konanoj verziji
softvera.
x poeljni zahtevi. Ispunjenje ovih zahteva nije neophodno, ali bi bilo dobro
kada bi sistem mogao i njih da ispuni.
x opcioni zahtevi. Ovi zahtevi se mogu ispuniti, ali se mogu i izostaviti iz
konane verzije sistema.

Na primer, kod obrauna plata, sutinski zahtev bi bio proraun iznosa koji
treba da bude isplaen svakom radniku. Poeljan zahtev bi bio da iznos za isplatu
bude razloen na stavke koje utiu na njega, dok bi opcioni zahtev bio da se tekst
platne liste tampa u crnoj boji sa naglaenim odbircima u crvenoj boji.
Dodeljivanje prioriteta zahtevima je vrlo korisno zato to pomae svim
uesnicima na projektu da bolje razumeju ta je stvarno potrebno realizovati. Osim
toga, ako na projektu postoje stroga vremenska ogranienja po pitanju njegovog
zavetka, ili organienja po pitanju predvienog budeta, prioriteti zahteva se mogu
iskoristiti da bi se ova ogranienja ispunila. Na primer, ako je vreme za razvoj
kratko, ili nema dovoljno novca, obino se opcioni zahtevi izostavljaju, dok se
poeljni zahtevi analiziraju sa ciljem eliminisanja nekih od njih ili odlaganja
njihove realizacije za kasnije verzije.

Konflikti se najee javljaju kod zahteva u pogledu kvaliteta. esto se deava
da nikakvom optimizacijom nije mogue zadovoljiti dva kontradiktorna zahteva
ovog tipa. Na primer, teko je istovremeno zadovoljiti zahteve za lakim
odravanjem sistema i kratkim vremenom odziva, jer se lako odravanje obino
ostvaruje enkapsulacijom i razdvajanjem nadlenosti, to usporava sistem. Ili,
prilagoavanje sistema za efikasan rad na jednoj platformi ugroava njegovu
prenosivost na druge platforme. Dodeljivanje prioriteta zahtevima od strane
naruioca pomae projektantima da na razuman, ako ne i optimalan nain ree
nastale konflikte, tako to izlaze u susret zahtevima koji su za naruiocima
najvaniji.


Ukoliko projektanti nikako ne mogu da razree nastale konflikte po pitanju
zahteva, moraju prei na pregovaranje i ponovno ocenjivanje pogleda svih
zainteresovanih subjekata. To nije nimalo jednostavan proces, jer zahteva
toleranciju, strpljenje i iskustvo kako bi se dolo do svima prihvatljivog reenja.
Subjekti se retko razilaze po pitanjima vezanim za funkcionalnost sistema. Sukobi
nastaju uglavnom oko ogranienja vezanih za reavanje problema (na pr. koji e
sistem za upravljanje bazama podataka biti korien, koji algoritmi za ifrovanje,
koja vrsta korisnikog interfejsa i dr.). Najvei problemi nastaju kada ne postoji
saglasnost oko dodeljenih prioriteta. Na primer, univerzitetski odseci mogu da
zahtevaju da razliita pravila ocenjivanja vae za razliite odseke, dok bi
administrativnoj slubi vie odgovaralo da su pravila ujednaena. U ovom sluaju,
treba najpre tano utvrditi razloge nepopustljivosti obe strane i sa njima upoznati
sve subjekte. Na taj nain e svi zainteresovani subjekti bolje razumeti probleme i
potrebe drugih i proceniti da li su oni vei ili manji od njihovih sopstvenih
problema i potreba. Na kraju dobro voenog pregovarakog procesa, obino se
dobijaju reenja koja su prihvatljiva za sve uesnike.

3.1.3 Prototipovi zahteva

U procesu definisanja zahteva, naruioci esto nisu sigurni ta tano ele i ta
im je potrebno. Tada se kao rezultat dobija lista zahteva sa veoma malo detalja i
bez naznake da li je skup zahteva potpun. Meutim, kada softverski proizvod bude
gotov, naruioci uglavnom znaju da li sistem zadovoljava njihove potrebe ili ne i
tada moe da doe do problema. Do ovoga dolazi i zato to je lake kritikovati
postojei proizvod, nego detaljno zamisliti novi. Ukoliko naruilac nije u stanju da
jasno ukae na zahteve, jedini nain da se sazna vie detalja o proizvodu jeste da se
napravi njegov prototip, a zatim da se od naruioca zahteva povratna informacija o
tome da li taj prototip zadovoljava njegove zahteve. Pod prototipom se
podrazumeva delimino razvijen proizvod koji omoguava sagledavanje razliitih
aspekata sistema. Na osnovu prototipa, korisnik moe da uoi koja su poboljanja
neophodna, koje osobine nisu dovoljno korisne, koja funkcionalnost nedostaje, itd.
Prototip moe da pomogne i projektantu da ispita izvodljivost predloenog reenja,
kao i mogunost optimizacije zahteva sa aspekta njihovog kvaliteta.

Izrada prototipa je u nastavku objanjena na jednom primeru. Pretpostavimo
da su naruioci softvera psiholozi i predavai koji izvode vebe, a korisnici sistema
njihovi klijenti, tj. oni koji rade vebe. S obzirom da korisnicima ovog sistema
raunari ne moraju biti bliski, od izuzetne vanosti je kako je izraen korisniki
interfejs. Na primer, neka korisnici treba da unesu datume izvoenja vebi.
Ukoliko predavai nisu sigurni kako bi taj unos trebalo da izgleda, pogodno je
izraditi prototip koji demonstrira mogunosti unosa. Na slici 3.2 a) prikazan je prvi
52 Analiza zahteva

prototip u kojem korisnik mora da unese dan, mesec i godinu kada veba. Laki
nain za unos je dat u prototipu 3.2 b) u kome korisnik samo miem treba da
selektuje odreeni datum.

b)
a)
Dan:
Mesec:
Godina:
P
1
8
15
22
29
U S P S N
2 3 4 5 6 7
9 10 11 12 13 14
16 17 18 19 20 21
23 24 25 26 27 28
30 31
Avgust 2011.

Slika 3.2. Prototipovi korisnikog interfejsa za unos datuma

Izrada prototipova u ovom primeru pomae da se odabere pravi izgled ekrana
za interakciju sa korisnikom. Oni vizualizuju zahtev i time olakavaju donoenje
odluke (lake je doneti odluku na osnovu prototipa nego na osnovu opisa datog
reima).

Pri izradi prototipova mogu se primeniti dva pristupa: izrada ilustrativnog
prototipa i izrada evolutivnog prototipa. Ilustrativni prototip predstavlja softver
koji se razvija radi boljeg upoznavanja sa problemom i on ne ulazi u softver koji se
isporuuje korisniku. Pri izradi ovog prototipa, ne mora se voditi rauna o kvalitetu
izraenog softvera, njegovoj strukturiranosti, efikasnosti, proveri greaka i sl. On
jednostavno predstavlja samo fasadu koja implementira eljenu funkcionalnost i
brzo dovodi do sutine problema ili predloenog reenja. Kada se dobiju eljeni
odgovori, ilustrativni prototip se odbacuje i pristupa se inenjerskom poslu na
izradi softvera koji e biti isporuen. Za razliku od ilustrativnog, evolutivni prototip
predstavlja softver koji se razvija ne samo da pomogne u nalaenju odgovora na
odreena pitanja, ve da postane sastavni deo softverskog proizvoda koji e biti
isporuen. Zato evolutivni prototip mora vrlo paljivo da se razvija tako da
zadovolji zahteve u pogledu kvaliteta (na pr. brzinu odziva, modularnost, itd.).

Modelovanje ponaanja 53

3.2 Modelovanje ponaanja

Modelovanje ponaanja sistema na osnovu prikupljenih zahteva doprinosi:
x boljem razumevanju zahteva
x lakem uoavanju pitanja koja treba postaviti naruiocu ili korisniku
x lakem nalaenju nedostataka u smislu nepoznatog ponaanja u pojedinim
situacijama
x lakem otkrivanju nedoslednosti u zahtevima (na primer, ako se ponovnim
dovoenjem istog ulaznog signala dobijaju razliite vrednosti na izlazu)

Tokom procesa modelovanja, osim podizanja nivoa razumevanja problema,
svi uesnici stiu i nova znanja, jer neki aspekti problema postaju jasniji i
oigledniji tek tokom modelovanja.

U literaturi postoji veliki broj metoda i notacija za modelovanje zahteva.
Meutim, mnoge od ovih metoda imaju velike slinosti, pa se mogu izdvojiti samo
desetak razliitih paradigmi. U nastavku su opisane tri od njih.

3.2.1 ER dijagrami

U ranoj fazi definisanja zahteva, korisno je napraviti konceptualni model
problema koji podrazumeva identifikovanje relevantnih objekata i entiteta u
sistemu, uoavanje njihovih osobina i meusobnih odnosa. ER dijagram (Entity-
Relationship diagram) je grafika notacija za predstavljanje konceptualnih modela
koju je 1976.godine uveo Chen. Ovaj metod se moe koristiti ne samo za
modelovanje zahteva, ve i za modelovanje dizajna sistema, strukture softverskog
proizvoda, baze podataka, itd.

Izrada ER dijagrama e biti ilustrovana na primeru softverski kontrolisane
obrtne kapije na ulazu u zooloki vrt, koji su 1995.godine dali Jackson i Zave.
Obrtna kapija radi tako to, kada se u predvieno mesto na kapiji ubaci novi,
kapija se otkljuava i posetilac moe da je gurne i ue u vrt. Nakon to kapija
zarotira i omogui jedan ulazak, ponovo se sama zakljuava, tako da sledei
posetilac ne moe da ue u vrt ukoliko na plati kartu, tj. ponovo ubaci novi.

Osnovni elementi na ER dijagramu su: entitet, atribut i relacija. Pod entitetom
se podrazumeva skup objekata (klasa objekata) iz realnog sveta koji imaju
zajednike osobine i ponaanje. U datom primeru sa obrtnom kapijom, entiteti
54 Analiza zahteva

mogu biti Posetilac, Novi, OtvorZaNovi i Rampa. Oni se na ER dijagramu
predstavljaju pravougaonicima. Atributima se opisuju svojstva entiteta. Tako,
atribut entiteta Novi moe biti vrednost, atributi entiteta Rampa mogu biti
zakljuana i broj_ulazaka, a atribut entiteta OtvorZaNovi, cena_ulaznice.
Relacije definiu tip odnosa izmeu dva entiteta i na dijagramu se predstavljaju
linijom koja spaja dva entiteta na ijoj sredini se nalazi romb u kome je naveden tip
veze. Na krajevima relacija esto se prikazuje kardinalnost veze koja oznaava broj
entiteta koji mogu uestvovati u vezi. Na primer, relacija izmeu entiteta Novi i
OtvorZaNovi moe biti ubaen. Poto se novii mogu ubacivati samo u jedan
otvor, kardinalnost na kraju relacije prema entitetu OtvorZaNovi je 1. Meutim,
u zavisnosti od vrednosti raspoloivih apoena i cene ulaznice, posetilac moe da
ubaci jedan ili vie (m) novia u otvor. To se opisuje kardinalnou m na strani
entiteta Novi. ER dijagram za sluaj obrtne rampe prikazan je na slici 3.3.

Posetilac
Novi
Rampa
OtvorZaNovi
ulazi
ima ubaen
zakljuana
broj ulazaka
vrednost
1
n
1
1
m m
cena ulaznice

Slika 3.3 Model obrtne rampe predstavljen ER dijagramom

ER dijagrami se smatraju stabilnim jer preko entiteta ukljuuju sve uesnike.
Mogue izmene u zahtevima obino se odnose na promenu ponaanja jednog ili
vie entiteta u skupu, dok se sam skup entiteta retko menja. Ovakav nain
modelovanja deluje jednostavno, ali esto nije ba tako. Naime, nivo detalja
modelovanja nije uvek lako odrediti. Na primer, moe se postaviti pitanje da li
otvor za novac i rampa treba da budu predstavljeni pomou dva entiteta (kao na
slici), ili jednim apstraktnijim entitetom kao to je Obrtna_rampa. Takoe, nije
lako odluiti koji podaci predstavljaju entitete, a koji atribute. Uvek postoje
argumenti za i protiv svakog mogueg izbora. Osnovni kriterijumi za donoenje
odluka treba da budu: da li neka mogunost pojanjava opis i da li izabrana
mogunost bez potrebe uvodi neka ogranienja.
ER notacija se esto koristi u sloenijim pristupima. Na primer, u UML jeziku
za modelovanje, ER notacija se koristi u dijagramu klasa, pri emu klase
predstavljaju realne entitete bitne za reavanje problema.

3.2.2 Tragovi dogaaja

ER dijagrami pruaju strukturiran pogled na problem, ukazujui na entitete
vane za njegovo reavanje, osobine entiteta i odnose koji postoje izmeu njih.
Meutim, ova notacija ne govori nita o ponaanju entiteta. Stoga je bilo potrebno
razviti nove notacije za modelovanje ponaanja sistema. Jedna od njih su tragovi
dogaaja.
Tragovi dogaaja predstavljaju grafiki opis niza dogaaja koji se u stvarnosti
razmenjuju izmeu entiteta. Opis se sastoji od vertikalnih i horizontalnih linija.
Vertikalne linije odgovaraju vremenskim osama na ijim vrhovima se nalaze nazivi
entiteta na koje se linije odnose. Horizontalne linije predstavljaju same dogaaje, tj.
interakciju izmeu entiteta, i mogu se shvatiti kao poruke koju pojedini entiteti
alju drugim entitetima. Vreme du ose tee odozgo na dole. Svaki dijagram
prikazuje po jedan trag koji predstavlja jedno od vie moguih ponaanja. Na slici
3.4 data su dva traga za sluaj obrtne rampe. Na levoj strani slike, dat je trag koji
opisuje uobiajeno ponaanje rada rampe. Na desnoj strani je trag koji prikazuje
neuobiajeno ponaanje, tj. situaciju kada posetilac pokua da u otvor za novi
ubaci neto drugo, tj. eton.

posetilac
novi
guranje
rotacija
novi
guranje
rotacija
obrtna rampa posetilac
eton
eton
eton
novi
guranje
rotacija
obrtna rampa

Slika 3.4 Model obrtne rampe predstavljen tragovima dogaaja

Projektanti i naruioci esto primenjuju notaciju tragova dogaaja jer ona ima
preciznu semantiku i laka je za razumevanje. Jednostavnost notacije potie od
mogunosti dekompozicije zahteva na scenarije, pri emu se onda svaki scenario
moe modelovati posebnim tragom.
Tragovi dogaaja se ne koriste za modelovanje celokupnog zahtevanog
ponaanja, jer bi u tom sluaju broj scenarija bio vrlo veliki. Uglavnom se koriste u
poetnoj fazi projekta kada je potrebno postii usaglaenost po pitanju kljunih
zahteva na projektu i identifikovati najvanije entitete.
56 Analiza zahteva

Kao i ER dijagrami, i tragovi dogaaja se esto koriste u sloenijim
pristupima. Na primer, u UML jeziku za modelovanje, tragovi dogaaja se koristi u
dijagramu sekvence.

3.2.3 Konani automati

Konani automat predstavlja grafiki opis komunikacije izmeu sistema i
njegovog okruenja. On objedinjuje sve tragove dogaaja u okviru jedinstvenog
modela.
Notacija se sastoji od vorova koji predstavljaju stanja u kojima konani
automat moe da se nae. Stanju odgovara stabilan skup uslova koji vae u
intervalu izmeu dva dogaaja. vorovi su povezani granama koje oznaavaju
prelaze iz stanja u stanje. Do promene stanja dolazi usled pojave nekog dogaaja
koji menja uslove u sistemu. Zato je svaki prelaz iz jednog stanja u drugo oznaen
pobudnim dogaajem, a ponekad i izlaznim dogaajem (u dijagramu mu prethodi
simbol /).
Konani automati se koriste za definisanje dinamikog ponaanja, tj. promena
u ponaanju sistema nastalih usled odvijanja nekih dogaaja. Ovaj metod je
posebno pogodan za modelovanje razliitog ponaanja izlaza sistema kada se na
njegov ulaz dovede fiksna vrednost. Naime, postoje sistemi kod kojih izlaz zavisi
ne samo od ulaza, ve i od veliina koje definiu tekue stanje sistema.
Na slici 3.5 dat je model konanog automata za sluaj obrtne rampe.

zakljuana otkuljuana
rotira
eton/zvuk
novi
rotirana guranje

Slika 3.5 Model obrtne rampe predstavljen konanim automatom

Kao to se vidi, po datom modelu, obrtna rampa moe biti u tri stanja:
zakljuana, otkuana i rotira. Ponaanje rampe zavisi od pobudnog dogaaja.
Ukoliko se desi neki neregularan dogaaj, na primer guranje kada je rampa u
stanju zakljuana, taj dogaaj e biti odbaen jer ga nema u modelu. Ovaj pobudni
dogaaj bi se mogao uvesti kao prelaz iz stanja zakljuana u stanje zakljuana.
Meutim, ukljuivanje ovakvih prelaza ne bi imalo nikakvog efekta, ve bi samo

opteretilo sistem, i zato se oni i ne uvode. Ima smisla ukljuiti samo one prelaze
koji imaju vidljiv efekat, kao na primer, generisanje nekog izlaznog dogaaja.
Putanja prelazaka konanog automata iz stanja u stanje, poevi od nekog
inicijalnog stanja, predstavlja tragove dogaaja u sistemu. U modelu na prethodnoj
slici, mogui tragovi su:

novi, guranje, rotirana, novi, guranje, rotirana, ...
eton, eton, eton, novi, guranje, rotirana, ...

Razmatrane notacije modelovanja opisuju probleme sa razliitih aspekata.
Jedne modeluju entitete i odnose izmeu njih, druge tragove dogaaja, tree
mogua stanja tokom izvravanja, etvrte funkcije, itd. Zbog razliitih pogleda na
isti problem, nijedna notacija nije uspela da se izdvoji kao dominantna. U stvari, u
praksi se pokazalo da je najbolje koristiti kombinaciju vie razliitih notacija. Tako
se dolo na ideju o formulisanju jezika za specifikaciju zahteva koji bi ukljuivali
vie notacija. Meu dananjim jezicima za specifikaciju, kao najpopularniji se
izdvojio UML (Unified Modeling Language). Osim za specifikaciju zahteva, UML
se efikasno koristi i u ostalim fazama razvoja softvera (pri projektovanju,
implementaciji), pa su zato njegove osnove izdvojene u poglavlju 5.

3.3 Formulisanje zahteva

Bez obzira na to koji je metod izabran za definisanje zahteva, neophodno je da
zahtevi budu dobro dokumentovani. To podrazumeva dobru organizaciju zahteva,
jasne tekstualne opise i preciznu prateu dokumentaciju u vidu raznih dijagrama i
ilustracija. Posebna panja se mora posvetiti kvalitetu zahteva.

3.3.1 Dokumentovanje zahteva

Definisane zahteve koriste razliiti subjekti na projektu za razliite namene.
Analitiari zahteva, naruioci i krajnji korisnici koriste zahteve da opiu ponaanje
sistema. Za projektante, projektni zahtevi su ogranienja vezana za usvojeno
reenje. Tim za testiranje koristi zahteve da formulie zavrne testove koji treba da
uvere naruioca da isporueni sistem odgovara sistemu koji je naruio. U fazi
odravanja sistema, tim za odravanje odrava (ispravlja greke) i unapreuje
sistem (dodaje nove osobine) potujui definisane zahteve kako se ne bi odstupilo
od originalne namene sistema.
Iako dokument sa zahtevima moe biti jedinstven za sve uesnike na projektu,
esto se izrauju dva dokumenta:
58 Analiza zahteva

x definicija zahteva. Ovaj dokument je namenjen poslovnom auditorijumu,
kao to su kupci, naruioci i korisnici.
x specifikacija zahteva. Ovaj dokument je namenjen tehnikom
auditorijumu, kao to su projektanti, timovi za testiranje, timovi za
odravanje i rukovodioci projekata.

Sadraj navedenih dokumenata e biti ilustrovan na ranije opisanom primeru
softverski kontrolisane obrtne kapije na ulasku u zooloki vrt.

Definicija zahteva predstavlja kompletan spisak zahteva koje naruilac eli da
budu ispunjeni. Ona nastaje kao rezultat zajednikih napora analitiara zahteva i
naruioca/korisnika. U dokumentu su, osim zahteva, opisani i entiteti iz okruenja
u kome e sistem biti instaliran, kao i ogranienja vezana za te entitete. Poto
zahtevi treba da budu realizovani u praksi, vrlo je bitna njihova povezanost,
odnosno interakcija sa okruenjem. U razmatranom primeru, mogu se postaviti dva
zahteva: 1) niko ne moe da ue u zooloki vrt bez plaanja ulaza i 2) sistem ne
moe da sprei onoga ko je platio ulaz da ue. Loginija formulacija drugog
zahteva bi bila da svakome ko plati kartu treba obezbediti da ue u zooloki vrt, ali
ovaj zahtev ne bi bilo mogue realizovati. Naime, ne postoji nain da sistem sprei
neki spoljanji faktor da onemogui posetioca koji je platio kartu da ue u vrt. Na
primer, moe da se desi da jedan posetilac ubaci novi, a drugi ga gurne i on ue u
vrt, ili posetilac moe da ubaci novi i onda se predomisli i ode na drugu stranu.

Specifikacija zahteva sadri zahteve o ponaanju softverskog sistema. Ona,
takoe, uzima u obzir i okruenje u kome e sistem raditi, s tim to se referie samo
na entitete iz okruenja kojima moe da se pristupi preko odgovarajuih interfejsa
iz sistema. Ovaj dokument pie analitiar, a koriste ga svi uesnici u razvoju
softvera. Analitiar mora da uspostavi jednoznanu vezu izmeu svakog zahteva
navedenog u definiciji zahteva i zahteva u specifikacionom dokumentu. Pri tome
ne sme da doe do gubitka informacije ili njene izmene prilikom pretvaranja
definicionog zahteva u specifikaciju. Na slici 3.6 prikazan je odnos opisanih
dokumenata. Eliptiki oblici predstavljaju okruenje i sistem. Oni imaju zajedniki
interfejs koji se nalazi u preseku elipsi. Zahtevi mogu biti definisani bilo gde u
domenu okruenja, ukljuujui i interfejs sistema, dok se specifikacija ogranienja
nalazi uvek u preseku domena okruenja i domena sistema.

Formulisanje zahteva 59

Sistem
Okruenje
Specifikacija
Zahtevi

Slika 3.6 Formulisanje zahteva

U primeru obrtne kapije, prvi zahtev je bio da niko ne moe da ue u zooloki
vrt bez plaene ulaznice. Poto se na kapiji nalazi otvor za ubacivanje novia,
sigurno se moe detektovati da li je odgovarajui apoen ubaen. Meutim, sam
dogaaj ulaska u vrt (ko e ui) ne moe da bude kontrolisan od strane sistema.
Stoga, prvi zahtev iz definicije zahteva mora se pretoiti u neto drugaiji zahtev u
specifikaciji zahteva, koji, opet, mora da odslikava sutinu polaznog zahteva.
Sistem moe da realizuje zahteve iskljuivo na osnovu dogaaja koje kapija moe
da detektuje, a to su: da li je kapija otkljuana ili zakljuana, i da li je posetilac
gurnuo kapiju ili nije. Stoga, prvi zahtev u definiciji zahteva u specifikaciji zahteva
postaje:

Kada posetilac gurne otkljuanu obrtnu kapiju, ona se automatski rotira
za jedan polukrug nakon ega se sama zakljuava.

Ovakva specifikacija predstavlja opis originalnog zahteva koji se moe
realizovati u sistemu.

Radi lake izrade navedenih dokumenata, u nastavku je dat predlog njihovog
sadraja.

Pri definisanju zahteva treba uraditi sledee:
x skicirati optu namenu i opseg sistema, ukljuujui relevantne ciljeve, veze
sa drugim sistemima, uz uvoenje terminologije, oznaka, skraenica i sl.
x navesti razloge za razvoj sistema (zato je postojei sistem
nezadovoljavajui, pa treba razvijati novi, koje delove postojeeg sistema
treba zameniti, a koje ne i dr.)
60 Analiza zahteva

x opisati osobine reenja koje se predlae kroz prikaz njegovih osnovnih
funkcionalnosti na nivou sluajeva korienja; opis obuhvata i analizu u
pogledu kvaliteta reenja (tanost, brzina, prioriteti i sl.)
x opisati okruenje u kome e sistem da radi (navoenje svih hardverskih i
softverskih komponenata sa kojima e sistem biti u interakciji, analiza
korisnikog interfejsa prema sposobnostima korisnika, njihovom iskustvu,
znanju, obrazovanju i dr.)
x navesti pretpostavke vezane za ponaanje okruenja, ukoliko one postoje
(uslovi koji mogu dovesti do otkaza sistema, kao i eventualne promene u
okruenju koje mogu dovesti do promena zahteva)

Pri izradi specifikacije zahteva potrebno je uraditi sledee:
x detaljno opisati sve ulaze i izlaze (interfejs sistema), ukljuujui izvore
ulaza, odredita izlaza, dozvoljene opsege i formate ulaznih i izlaznih
veliina, protokole razmene podataka, vremenska ogranienja, i sl.
x prikazati zahtevanu funkcionalnost pomou ulaza i izlaza korisnikog
interfejsa, ukljuujui provere ispravnosti ulaznih i izlaznih veliina; prikaz
mora da bude potpun, odnosno, za sve mogue vrednosti na ulazu, mora
biti poznata vrednost na izlazu; ovde se mogu koristiti razliite tehnike
modelovanja (konani automati, tragovi dogaaja i dr.)
x utvrditi usklaenost svakog zahteva sa kriterijumom koji naruilac
postavlja u pogledu kvaliteta

Rezultat izrade dokumenata sa definicijom i specifikacijom zahteva je detaljan
opis sistema koji razvojni tim treba da proizvede. Neke organizacije, kao to su
IEEE (Institute of Electrical and Electronic Engineers) i Ministarstvo odbrane
SAD poseduju standarde koji definiu sadraj i format dokumenata o zahtevima.
Na slici 3.7 dat je primer IEEE standarda za specifikaciju softverskih zahteva.

1. Uvod u dokument
1.1. Namena proizvoda
1.2. Opseg proizvoda
1.3. Akronimi, skraenice, definicije
1.4. Reference
2. Opti opis proizvoda
2.1. Kontekst proizvoda
2.2. Funkcije proizvoda
2.3. Karakteristike korisnika
2.4. Ogranienja
2.5. Pretpostavke i zavisnosti
3. Specifini zahtevi
3.1. Zahtevi spoljanjih interfejsa
3.1.1. Korisniki interfejsi
3.1.2. Hardverski interfejsi
3.1.3. Softverski interfejsi
3.1.4. Komunikacioni interfejsi
3.2. Funkcionalni zahtevi
3.2.1. Klasa 1
3.2.2. Klasa 2
...
3.3. Zahtevi u pogledu performansi
3.4. Projektna ogranienja
3.5. Zahtevi u pogledu kvaliteta
3.6. Ostali zahtevi
4. Dodaci

Slika 3.7 IEEE standard za specifikaciju zahteva

62 Analiza zahteva

3.3.2 Kvalitet zahteva

Poto se prilikom izrade softvera realizuju samo oni zahtevi koji su navedeni u
specifikaciji zahteva, vrlo je vaan njihov kvalitet. Procena kvaliteta zahteva
zasniva se na davanju odgovora na sledea pitanja:
x Da li su zahtevi ispravni? Nakon dokumentovanja zahteva, analitiar i
naruilac treba jo jednom detaljno da pregledaju zahteve kako bi se uverili
da su oni usklaeni sa stvarnim potrebama i odgovaraju shvatanjima
naruioca.
x Da li su zahtevi dosledni? Doslednim se smatraju dva zahteva koja mogu
biti istovremeno ispunjena. U suprotnom, zahtevi su nedosledni. Na
primer, ako se u jednom zahtevu navodi da sistem moe da koristi najvie
deset korisnika u jednom trenutku, a u drugom zahtevu da postoje situacije
u kojima sistem moe da ima i dvadeset korisnika, onda su ova dva zahteva
nedosledna.
x Da li su zahtevi nedvosmisleni? Ako vie osoba koje analiziraju dokument
sa zahtevima doe do istih interpretacija, tj. shvatanja nekog zahteva, onda
je on nedvosmislen. Meutim, moe se desiti i da razliite osobe ispravnim
razmiljanjem dou do razliitih interpretacija zahteva. Tada je zahtev
neprihvatljiv jer je vieznaan. U tom sluaju, potrebno je obazbediti nove
informacije kako bi zahtev bio precizniji. Na primer, zahtev moe da kae
da e neki sklop raditi ako je odstupanje njegove osovine od osnovnog
poloaja malo. Pojam malo se moe razliito shvatiti. Stoga je potrebna
dodatna informacija koja preciznije definie mogue odstupanje (na pr.
0,5mm).
x Da li su zahtevi kompletni? Skup zahteva se smatra kompletnim ako
odslikava zahtevano ponaanje sistema za sve mogue kombinacije ulaza u
svim moguim stanjima sistema, potujui sva ogranienja. Na primer, u
sluaju sistema za obraun plata, potrebno je definisati ta se dogaa ako
radnik uzme neplaeno odsustvo, dobije poviicu, ili zatrai akontaciju
plate.
x Da li su zahtevi izvodljivi? Ponekad se deava da reenje koje bi
odgovorilo potrebama naruioca u sutini i ne postoji. To se obino deava
kada naruilac postavlja dva ili vie zahteva u pogledu kvaliteta. Na
primer, on moe da zahteva jeftin sistem koji analizira ogromne koliine
podataka za vrlo kratko vreme.
x Da li je svaki zahtev relevantan? Ponekad zahtevi nepotrebno oteavaju
posao razvojnom timu, pa razvojni tim mnogo vremena troi na realizaciju

nebitnih aspekata sistema, umesto da se usredsredi na sutinsku
funkcionalnost. Na primer, ukoliko se razvija simulator tenka, moe se
zahtevati da se posadi tenka omogui da alju elektronsku potu vojnicima,
iako je osnovna namena tenka da savlada neravan teren. Stoga je potrebno
da se prilikom definisanja zahteva sprei eksplozija mogunosti (uvek
moemo dodavati neto novo), kako bi se pomoglo zainteresovanim
subjektima da izdvoje sutinske i poeljne zahteve.
x Da li je zahteve mogue testirati? Pojedini zahtevi se mogu testirati pre
realizacije softvera. To se radi pravljenjem odgovarajuih testova koji
jasno demonstriraju kako bi zahtev bio zadovoljen u konanoj verziji
softvera, tj. u realnim uslovima. Na primer, moe se napraviti test kojim bi
se ispitalo koliko korisnika moe istovremeno da radi na sistemu.
x Da li zahtevi mogu da se prate? U dokumentima, zahtevi moraju da budu
dobro organizovani i sistematizovani, sa jedinstvenim oznakama u cilju
lakeg referenciranja na njih.

Odgovori na navedena pitanja se mogu, takoe, posmatrati kao neka vrsta
prateih zahteva u pogledu kvaliteta. Oni mogu da pomognu analitiaru zahteva da
odredi kada je zahtev dobro definisan, a kada je potrebno prikupiti jo informacija
o njemu. Stepen do koga su ovi zahtevi zadovoljeni utie na sveobuhvatnost
reenja, izbor jezika za specifikaciju zahteva, kao i na proces validacije i
verifikacije.

3.4 Validacija i verifikacija zahteva

Dokumenti o zahtevima detaljno opisuju softverski proizvod koji treba da
bude isporuen naruiocu. Oni su vrlo bitni, kako za naruioca, tako i za budue
projektante. Pre nego to analitiar zahteva prosledi ove dokumente projektantima,
neophodno je da jo jednom, zajedno sa naruiocem, proveri njihov sadraj. Ta
provera obuhvata validaciju zahteva i verifikaciju specifikacije. Validacijom se
dokazuje da se razvija pravi sistem (onaj koji je potreban naruiocu), dok se
verifikacijom potvruje da se sistem razvija na pravi nain.

3.4.1 Validacija zahteva

Validacija zahteva podrazumeva proveru da li definicije zahteva tano
odraavaju zahteve naruioca. Ovo je sloen proces u kome nije dovoljno samo
64 Analiza zahteva

rei da li je zahtev ispravan ili ne, ve treba dati i odgovarajuu argumentaciju za tu
tvrdnju.

Validacija zahteva se sprovodi po sledeim kriterijumima:
x ispravnost zahteva
x doslednost zahteva
x nedvosmislenost zahteva
x potpunost zahteva
x relevantnost zahteva
x mogunost testiranja zahteva
x mogunost praenja zahteva

Veina navedenih kriterijuma, kao to su ispravnost, relevantnost, potpunost
ili nedvosmislenost zahteva, podleu subjektivnoj proveri. Proveru zahteva po
ovim kriterijumima mogu da urade samo zainteresovani subjekti, ako im se da na
uvid odgovarajui dokument. Provere po kriterijumima, kao to su doslednost ili
mogunost praenja zahteva, drugaije su prirode i one se mogu automatizovati.

Postoje razliite tehnike za sprovoenje validacije zahteva. U
najjednostavnijem sluaju, validacija se moe svesti na itanje dokumenata i
formiranje izvetaja o uoenim grekama.
Drugi nain validacije je prolazak kroz dokumenta tako to jedan od autora
dokumenata izlae zahteve svim zainteresovanim subjektima i od njih trai
miljenje i komentare. Ovaj metod je efikasan ako postoji veliki broj
zainteresovanih subjekata, pa bi bilo nepraktino da svaki od njih detaljno analizira
dokumente.
Formalna inspekcija je postupak validacije u kome se revizori stavljaju u
odreene uloge (na pr. prodavac, raunovoa i dr.) i prate propisana pravila.
est nain validacije je ocenjivanje zahteva. Ocenjivanje se radi po raznim
aspektima, kao to su ocenjivanje postavljenih ciljeva, namene softvera, okruenja,
predloenih funkcija, rizika, itd. Ocenjivanje rade kako predstavnici naruioca,
tako i oni koji su realizovali softver. U predstavnike naruioca spadaju krajnji
korisnici, oni koji e obezbediti ulazne podatke za sistem, kao i oni koji e koristiti
izlazne rezultate. Ovde mogu biti ukljueni i rukovodioci. S druge strane,
ocenjivanje rade i lanovi razvojnog tima, tima za testiranje i operativnog tima koji
se bavi odravanjem.

Validacija i verifikacija zahteva 65

Izbor validacione tehnike koja e biti primenjena zavisi od notacija koje su
koriene pri definisanju zahteva, kao i od afiniteta i iskustava zainteresovanih
subjekata koji rade validaciju.
Kada se tokom validacije uoi neki problem, on se najpre dokumentuje
(navede se u emu je problem i ta mu je uzrok), a zatim se prosledi analitiaru
zahteva. Analitiar ima zadatak da rei problem. Na primer, validacijom se moe
otkriti da postoji kontradiktornost zahteva u smislu da naruilac zahteva
pouzdanost i raspoloivost softvera za koje projektni tim smatra da je nemogue
postii. Ovakvi zahtevi moraju da budu razreeni pre nego to pone projektovanje.

3.4.2 Verifikacija specifikacije

Verifikacija u optem smislu predstavlja proveru da li je jedan element u
projektu saglasan sa drugim. Na primer, moe se proveriti da li je programski kd
saglasan sa projektnim reenjem, ili da li je projektno reenje u saglasnosti sa
specifikacijom zahteva.
U kontekstu projektnih zahteva, verifikacija se radi u cilju provere da li
specifikacija zahteva odgovara definiciji zahteva. To je vrlo bitno zato to
projektanti razvijaju sistem na osnovu dobijene specifikacije. Verifikacija prua
sigurnost da e sistem koji je realizovan prema datoj specifikaciji u potpunosti
zadovoljiti zahteve korisnika.
Verifikaciju nije jednostavno uraditi. Treba dokazati da specifikacija obuhvata
sve funkcije, dogaaje, aktivnosti i ogranienja koji su izneti u zahtevima. Sama
specifikacija retko moe da prui dovoljno argumenata za ovo dokazivanje, jer je
ona fokusirana na sistemski interfejs, dok je esto potrebno dokazati neto iz
okruenja, to je van ovog interfejsa. Na primer, specifikacija sadri podatak o sili
kojom treba delovati na obrtnu rampu da bi ona napravila polukrug i dozvolila
posetiocu da ue u zooloki vrt, a potrebno je da se prebroji koliko je ulazaka u vrt
bilo. Ovaj nesklad se prevazilazi tako to se, osim specifikacije, uzimaju u obzir i
pretpostavke o ponaanju okruenja, pa se onda proveravaju zahtevi naruioca.
Za verifikaciju se esto koriste specijalizovani programi koji pretrauju
prostor izvravanja specifikacije. Ovi programi su prilino sloeni i troe znaajne
raunarske resurse.

Nakon obavljene validacije i verifikacije projektnih zahteva, trebalo bi da i
naruilac i projektant budu zadovoljni formulisanim zahtevima, tako da projektant
moe da nastavi sa projektovanjem sistema.

Rezultat analize zahteva, koju analitiar zahteva sprovodi u saradnji sa
naruiocima i korisnicima softverskog sistema, predstavljaju dva dokumenta:
definicija zahteva i specifikacija zahteva. Kao to je reeno u prethodnom
poglavlju, specifikacija zahteva je dokument namenjen projektantima sistema i u
njemu je problem opisan korienjem tehnike terminologije bliske projektantima.
Ovaj dokument predstavlja osnovu za projektovanje sistema, iji je cilj generisanje
reenja koje zadovoljava potrebe naruioca. Dakle, pod projektovanjem sistema se
podrazumeva kreativni proces prevoenja datog problema u njegovo reenje.
Iako je problem precizno definisan specifikacijom, broj moguih reenja je
obino vrlo veliki (ponekad i neogranien). Svaki projektant reava problem na
svoj nain i dobija drugaije reenje. Zajedniko za sva reenja je da zadovoljavaju
sve postavljenje zahteve korisnika. Reenja se meusobno razlikuju po aspektima
problema kojima posveuju veu panju. Priroda reenja se moe menjati u svim
fazama projekta, ukoliko za to postoji realna potreba. Deava se da naruioci u
toku projekta uoe neto to bi im bilo bitno da imaju u konanoj verziji sistema
(bilo da su to zaboravili ranije, ili da su u meuvremenu doli do saznanja da bi to
bilo korisno dodati), pa imaju potrebu da promene zahteve. Tada bi im trebalo izai
u susret, jer nije dobro da dobiju softver koji im ne odgovara.

Da bi zahteve pretoili u sistem koji radi, projektanti moraju da zadovolje
elje i naruioca i tima koji implementira softver. S jedne strane, naruilac zna ta
sistem treba da radi, dok sa druge strane, tim koji pravi softver zna kako sistem to
treba da radi. Imajui ovo u vidu, projektovanje se moe shvatiti kao iterativni
proces koji se sastoji iz dve celine: konceptualnog projekta i tehnikog projekta.
Konceptualni projekat ili konceptualni dizajn detaljno opisuje klijentu ta e
sistem da radi. On identifikuje sve entitete u sistemu, njihove atribute i meusobne
veze, i prua odgovore na sledea pitanja:
x Odakle i na koji nain se dobijaju ulazni podaci?

4 Projektovanje sistema

x Kako se obrauju ulazni podaci?
x Kako e izgledati korisniki interfejs?
x Kakav je vremenski tok dogaaja u sistemu?
x U kom obliku e biti predstavljeni rezultati?

Konceptualni projekat opisuje funkcije sistema na jeziku razumljivom klijentu
i ne zavisi od naina implementacije sistema. Na primer, u njemu se moe rei da
se neke poruke alju sa jednog mesta na drugo, ali se ne objanjava koji e mreni
protokol biti korien prilikom tog slanja.
Kada klijent odobri konceptualni projekat, sledi njegovo prevoenje u mnogo
detaljniji, tehniki projekat. Tehniki projekat ili tehniki dizajn omoguava timu
koji razvija softver da utvrdi koji hardver i koji softver su potrebni za
implementaciju reenja, kako e se obavljati komunikacija u sistemu, definie ulaze
i izlaze sistema, opisuje mrenu arhitekturu sistema i dr. Odnos konceptualnog i
tehnikog dizajna prikazan je na slici 4.1.

Konceptualni
dizajn
ta sistem radi?
Projektanti
Tehniki
dizajn
Kako sistem radi?
Kupci Programeri

Slika 4.1 Opti prikaz procesa projektovanja

Konceptualni i tehniki projekat se mogu objediniti u jedan, sveobuhvatan
dokument. To se radi u sluaju kada su klijenti profesionalci u datoj oblasti i mogu
da razumeju i ta sistem radi i kako sistem radi.
Proces projektovanja je iterativan zato to projektanti naizmenino rade na
analizi zahteva, predlaganju moguih reenja, testiranju izvodljivosti pojedinih
aspekata reenja i dokumentovanju reenja za programere.

Modularnost u projektovanju 69

4.1 Modularnost u projektovanju

Proces projektovanja podrazumeva utvrivanje skupa komponenata od kojih
e sistem biti napravljen, kao i definisanje veza koje treba da postoje izmeu njih.
Postoji mnogo naina da se napravi dobar projekat koji zadovoljava zahteve
korisnika. Izbor projekta koji e biti implementiran zavisi od razliitih faktora, kao
to su: sklonosti projektanata, zahtevana struktura sistema, raspoloiv skup ulaznih
podataka i dr. Bez obzira na to koji e projekat biti izabran za realizaciju, u svakom
projektu postoji neki oblik modularnosti.
Wasserman je 1995.godine predloio da se proces projektovanja izvodi na
jedan od sledeih naina:
x modularnost na nivou funkcionalnosti. Ovaj metod se zasniva na tome da
se izdvoje komponente u sistemu tako da svaka ima svoju funkcionalnost, a
da sve zajedno u potpunosti funkcionalno opisuju sistem. Projektant polazi
od opteg opisa funkcionalnosti svake komponente, a zatim ga detaljno
razrauje. Za svaku komponentu, projektant utvruje ta ona sadri, kakva
joj je organizacija, u kakvoj je vezi sa ostalim komponentama i sl.
x modularnost na nivou podataka. Ovaj pristup se zasniva na strukturama
podataka. Projektant na optem nivou definie globalnu strukturu podataka,
a zatim navodi kako e podaci biti korieni i kakve veze postoje meu
njima.
x modularnost na nivou dogaaja. U ovom pristupu, projektant uoava
mogue dogaaje u sistemu, a zatim analizira kako oni menjaju stanje
sistema. Najpre se formira opti opis koji sadri skup moguih stanja,
nakon ega se daje detaljan opis kako se prelazi iz jednog stanja u drugo.
x projektovanje spolja ka unutra. Ovaj metod se zasniva na podacima koje
korisnik unosi u sistem. Projektant najpre formira opti opis u kome navodi
koje sve podatke korisnik moe da unese u sistem, a zatim detaljno
objanjava ta se u sistemu deava sa unetim podacima, ukljuujui kako
meurezultate, tako i konane rezultate.
x objektno-orijentisano projektovanje. Ova vrsta projektovanja podrazumeva
definisanje klasa objekata u sistemu i njihovih meusobnih veza. Najpre se
na optem nivou opisuju tipovi objekata, a zatim se detaljno daju njihova
svojstva i akcije koje mogu da izvre.

Bez obzira na korieni pristup, kao rezultat projektovanja dobija se
hijerarhija komponenata ili modula sa vie nivoa, kao to je prikazano na slici 4.2.


najvii nivo
prvi nivo
drugi nivo

Slika 4.2 Nivoi modularnosti

Svaki sledei nivo sadri vie informacija od prethodnog. Za sistem se kae da
je modularan ukoliko svaku aktivnost u njemu obavlja jedna komponenta sa dobro
definisanim ulazima, izlazima i osobinama. Ulazi su dobro definisani ako svi imaju
uticaja na funkcionisanje komponente, tj. ne postoje ulazi koji se ne koriste.
Takoe, ne sme se dozvoliti ni da neki od ulaza nedostaje, jer onda komponenta ne
bi bila u stanju da obavi svoju funkciju u celosti. Izlazi su dobro definisani samo
ako se svi mogu proizvesti nekom od akcija sistema.
Modularnost prua mogunost da se na viem nivou apstrakcije buduim
klijentima, nabavljaima, podizvoaima prikae dizajn sistema, a istovremeno
sadri i detalje potrebne timu koji razvija sistem.

4.2 Strategije projektovanja

Proces projektovanja obino poinje posmatranjem sistema odozgo, tj. sa
opteg aspekta, a zatim se ide na dole uvoenjem sve vie detalja koji se odnose na
izgled i funkcionisanje sistema. Obrnuti nain projektovanja, odozdo na gore, je
znatno tei i neizvesniji i esto dovodi do nereivih problema. Shaw i Garlan su
1996.godine predloili da se projektovanje obavlja na tri nivoa:
x projektovanje arhitekture sistema
x projektovanje programskog kda
Strategije projektovanja 71

x zavrno projektovanje

Arhitektura sistema podrazumeva povezivanje mogunosti sistema koje su
navedene u specifikaciji zahteva sa komponentama sistema koje e biti
implementirane. Komponenete obino predstavljaju pojedinane module u sistemu.
Osim modularne strukture, arhitektura opisuje i veze koje treba da postoje izmeu
modula, kao i naine kako se od manjih podsistema generiu sloeniji sistemi bitni
za formiranje konanog softverskog proizvoda.
Projektovanje programskog kda obuhvata izbor programskog jezika koji e
biti korien u implementaciji, izbor struktura podataka u kojima e se uvati
relevantni podaci, kao i izbor algoritama za obradu i manipulaciju podacima.
Takoe se utvruje skup programskih modula, tj. datoteka pomou kojih e sistem
biti implementiran, potrebne procedure i funkcije sistema.
Zavrno projektovanje jo detaljnije opisuje implementaciju navoenjem
informacija o formatima podataka koji e biti korieni, ablonima, primenjenim
protokolima, dodeli memorije, itd.
Iako bi bilo korisno projektovati po nivoima u redosledu u kome su oni
navedeni, iskustva pokazuju da u praksi projektanti naizmenino prelaze sa jednog
nivoa na drugi kako vie upoznaju reenje i njegove posledice. Na primer, grupa
projektanata moe da odlui da bi sistemom trebalo upravljati pomou tabela.
Meutim, kada naprave prototipove tabela, mogu da zakljue da sistem nema
potrebno vreme odziva, tj. da radi presporo. Zato ponovo projektuju bri sistem
kojim bi se upravljalo pomou matrica umesto tabela. Na ovaj nain, oni prelaze sa
prvog na drugi, a onda se ponovo vraaju na prvi nivo. Slino, dok projektanti
istrauju neke aspekte sistema, mogu u komunikaciji sa programerima ili onima
koji testiraju sistem da dou do nekih zakljuaka koji ukazuju na to da bi trebalo
promeniti dizajn kako bi se unapredili implementacija, mogunosti testiranja ili
odravanje. Prema tome, projektanti moraju postepeno da rade na arhitekturi,
programima i zavrnom dizajnu u skladu sa sopstvenim poznavanjem reenja i
svojom kreativnou.

Na poetku razvoja sistema potrebno je izabrati arhitekturu koja e biti
primenjena. Mnogi sistemi imaju slinu strukturu. Na primer, distribuirani sistemi
obino imaju klijent-server strukturu u kojoj klijent upuuje upite, a server
procesira te upite i odgovara na njih. Dosadanja iskustva po pitanju arhitekture
sistema dovela su do pojave razliitih stilova u projektovanju. Stil podrazumeva
strukturalnu organizaciju softverskog sistema. On ukljuuje izbor komponenata
(podsistema), kao i definisanje njihovih uloga. Na primer, u klijent-server
arhitekturi razlikuju se dva podsistema: klijent (kojih moe biti vie) i server (koji
je jedinstven). Uloga klijenta moe biti prikazivanje korisnikog interfejsa
korisniku, a uloga servera procesiranje brojnih zahteva i zatita podataka vanih za
korisnika. Stil, takoe, odraava i veze izmeu podsistema, tj. nain njihovog

povezivanja, uz eventualna ogranienja. Na primer, veza izmeu klijenta i servera
se ostvaruje tako to klijent postavlja pitanja, a server odgovara na njih.
Nekoliko najee korienih stilova su:
x cevi i filtri (pipe-filter)
x slojevita (layers) arhitektura
x klijent-server (client-server) arhitektura
x ravnopravan (peer-to-peer) pristup
x arhitektura zasnovana na dogaajima (event-bus)
x objektno-orijentisani (object-oriented) pristup

4.2.1 Cevi i filtri

Cevi i filtri predstavljaju strukturu koja se koristi u sistemima baziranim na
tokovima podataka. Svaki korak u postupku procesiranja podataka izdvojen je u
jednu filtarsku komponentu. Filtri rade nezavisno i nisu svesni postojanja drugih
filtara u sistemu. Podaci prolaze kroz cevi koje povezuju filtre. Cevi se mogu
koristiti za memorisanje ili za sinhronizaciju.
Primer dizajna koji se zasniva na ovom stilu su komande u Unix operativnom
sistemu:

cat file | grep xyz | sort | uniq > out

Zadatak u vidu izvoenja niza komandi podeljen je u vie uzastopnih koraka.
Koraci su povezani tokovima podataka tako da izlaz jednog koraka predstavlja ulaz
narednog. U datom primeru, cat filtar ita datoteku file i prosleuje njen sadraj
grep filtru. Filtar grep selektuje linije koje sadre xyz i alje ih sort filtru. Ovaj
filtar sortira linije i prosleuje ih uniq filtru koji brie duple linije i alje rezultat na
izlaz out. Opisani postupak prikazan je slici 4.3, gde krugovi predstavljaju filtre, a
linije sa strelicama cevi.
file cat grep sort uniq out
s
a
d
r
a
j
l
i
n
i
j
e

s
a

x
y
z
s
o
r
t
i
r
a
n
e

l
i
n
i
j
e
b
e
z

p
o
n
o
v
l
j
e
n
i
h

l
i
n
i
j
a

Slika 4.3 Primer arhitekture sa filtrima i cevima


Arhitektura sa cevima i filtrima ima prednosti, ali i nedostatke. Prednosti se
ogledaju u tome to se sistem lako modifikuje dodavanjem novih filtara, ili
uklanjanjem postojeih. Filtri predstavljaju nezavisne komponente koje se lako
samostalno razvijaju. Dalje, filtri se mogu koristiti vie puta, tj. mogue je
generisati razliite tokove kombinovanjem datog skupa filtara. Ovaj stil
omoguava konkurentno procesiranje zato to filtri rade nezavisno i obavljaju
svoju funkciju kada prime potrebne podatke, ne ekajui da se svi podaci uitaju ili
obrade drugim filtrima. Znaajna prednost je i u jednostavnoj analizi ponaanja
ovakvih sistema. Na primer, ako je ulaz u sistem x, a ponaanje prvog filtra se
moe opisati funkcijom g, ponaanje drugog filtra funkcijom f, rezultat procesiranja
se moe opisati pomou

f (g (x)).

Na osnovu ovog izraza, moe se analizirati propusna mo sistema (koja je
odreena najsporijim filtrom), kao i mogunost pojave nereivih situacija
(deadlocks). Ove situacije se mogu desiti ukoliko neki filtar, da bi generisao izlaz,
mora da ima sve procesirane podatke, a nema dovoljan bafer da ih prihvati. Primer
ovakvog filtra je sort Unix filtar.
Glavni nedostatak arhitekture sa cevima i filtrima je u tome to podstie
paketnu obradu i nije pogodna za interaktivne aplikacije. Drugi nedostatak je
nepotrebni gubitak vremena u transformacijama podataka. Na primer, deava se da
filtar procesira realne brojeve, a ulaz i izlaz su mu u tekstualnom formatu. Trei
nedostatak je taj to se moe desiti da filtri ponavljaju pripremne funkcije drugih
filtara, to utie na pad performansi i poveanje stepena sloenosti sistema. Na
primer, poto su realizovani nezavisno, svi filtri u sistemu koji obrauje datumski
objekat, moraju da provere ispravnost datuma, tj. da li je mesec u opsegu od 1do
12, a dan od 1 do 31, tako da se ova provera nepotrebno vri vie puta.

4.2.2 Slojevita arhitektura

Slojevita arhitektura dekomponuje aplikaciju u vie apstraktnih nivoa. Svaki
nivo predstavlja jedan sloj koji sadri grupu zadataka. Slojevi su hijerarhijski
rasporeeni tako da svaki sloj prua usluge sledeem viem sloju u hijerarhiji.
Takoe, usluge u jednom sloju implementiraju se korienjem usluga koje prua
prvi nii sloj u odnosu na posmatrani.
Ideja iz koje je nastao ovaj stil zasniva se na tome da se konceptualno razliiti
delovi aplikacije implementiraju odvojeno, s tim da slojevi na viim nivoima
apstrakcije koriste samo usluge niih slojeva.


Primer sistema sa ovom arhitekturom je sistem za bezbednost datoteka dat na
slici 4.4. Ovaj sistem se sastoji iz etiri sloja. Najnii sloj je kriptografija koji
sadri funkcije za ifrovanje/deifrovanje. Drugi sloj koristi klju za
ifrovanje/deifrovanje datoteke. Trei sloj je zaduen za generisanje digitalnog
potpisa i davanje prava pristupa datoteci, dok etvrti sloj identifikuje korisnika
putem korisnikog imena i lozinke i proverava autentinost.

Kriptografija
ifrovanje/deifrovanje
datodeke
Digitalni
potpis
Provera
autentinosti

Slika 4.4 Primer slojevite arhitekture

Prednosti slojevite arhitekture su:
x nii slojevi mogu biti vie puta korieni od strane razliitih viih slojeva
x postojanje slojeva ini lakom standardizaciju zadataka
x razvoj i testiranje jednog sloja se obavljaju nezavisno od drugih slojeva,
poto se veze (interfejsi) izmeu slojeva ne menjaju, ve se sve promene
obavljaju unutar sloja

4.2.3 Klijent-server arhitektura

U klijent-server arhitekturi, serverska komponenta prua usluge veem broju
klijentskih komponenata. Klijentske komponente zahtevaju usluge od servera.
Serveri su stalno aktivni i oslukuju da li ima zahteva od klijenata. Zahtevi se alju
komunikacionim kanalima koji zavise od maina na kojima se server i klijent
nalaze. Opti izgled ove arhitekture prikazan je na slici 4.5.

Tipini primeri klijent-server arhitekture su aplikacije sa udaljenim pristupom
bazama podataka (kada klijentska aplikacija zahteva uslugu od servera baze
podataka), udaljeni fajl sistemi (klijentska aplikacija pristupa datotekama na

serveru i u lokalu transparentno), ili web aplikacije (itai zahtevaju podatke od
web servera).

Klijent
Server

Slika 4.5 Klijent-server arhitektura

Prispeli zahtevi se obino opsluuju u odvojenim nitima na serveru. U
komunikaciji esto ima praznog hoda koji nastaje kako zbog saobraaja na
mrei, tako i zbog neophodnog transformisanja zahteva i rezultata u formate koji su
esto razliiti na serverskoj i klijentskog strani. U distribuiranim sistemima sa vie
servera koji obavljaju istu funkciju, mora se obezbediti transparentnost, to znai
da klijenti ne treba da razlikuju servere. Na primer, ako se u Google pretraivau
zahteva neki podatak unoenjem URL adrese, klijent ne treba da zna na kojoj tano
maini je taj podatak lociran, koja je platforma primenjena, ili koja je putanja
koriena.
4.2.4 Ravnopravni pristup

Arhitektura koja se zasniva na ravnopravnom pristupu moe se shvatiti kao
simetrina klijent-server arhitektura. U ovoj arhitekturi, ista komponenta moe da
radi i kao klijent (zahteva usluge od drugih komponenata) i kao server (prua
usluge drugim komponentama). Takoe, komponenta moe i da zadri samo jednu
funkcionalnost, bilo klijentsku, ili serversku. Osim toga, komponenta moe
dinamiki da menja svoju ulogu izmeu navedene tri.
Prednost ove arhitekture je u tome to komponente mogu da koriste ne samo
svoje, ve i kapacitete kompletne mree u kojoj se nalaze. Takoe, administriranje
je jednostavnije, zato to su ovakve, ravnopravne mree samoorganizujue.
Sistem koji podrava ovu arhitekturu je skalabilan i otporan na otkaze pojedinih
komponenata. Konfiguracija sistema se moe menjati (ukljuivanje i iskljuivanje
komponenata) dinamiki u toku rada.
Nedostatak ove arhitekture je u tome to nema garancije u pogledu kvaliteta
pruenih usluga, poto komponente sarauju na dobrovoljnoj osnovi. Zbog ovoga,

teko je obezbediti sigurnost mree. Performanse ovakvih sistema rastu sa
poveanjem broja komponenata, ali i opadaju sa njegovim smanjenjem.

4.2.5 Arhitektura zasnovana na dogaajima

Model sistema koji se zasniva na dogaajima radi na principu difuzionog
emitovanja poruka. Sistem funkcionie tako to komponente (izvori dogaaja) alju
poruke o tome da je nastupio neki dogaaj na magistralu dogaaja. Ostale
komponente koje su prikljuene na magistralu mogu dogaajima da pridruuju
procedure i taj proces se naziva registrovanjem procedura. Zatim sistem poziva sve
registrovane procedure.
Generisanje poruka i pridruivanje procedura su asinhronog karaktera. Nakon
to neka komponenta generie poruku o dogaaju, ona prelazi na neki drugi posao,
ne ekajui da ostale komponente prime poruku.
Arhitektura zasnovana na dogaajima koristi se u aplikacijama za
monitorisanje, trgovinu, u okruenjima za razvoj softvera (videti sliku 4.6) i dr.

Alat za
editovanje
Alat za
razvoj
Alat za
testiranje
Magistrala dogaaja
izmena
kda
izmena
kda
test u
redu
izmenjen
projekat

Slika 4.6 Primer arhitekture zasnovane na dogaajima

4.2.6 Objektno-orijentisani pristup

Veliki broj savremenih sistema je razvijen delimino, ili u potpunosti na
osnovu objektno-orijentisanog (OO) pristupa. Po ovom pristupu, problem i njegovo
reenje se organizuju kao skup objekata kojima se opisuju ne samo podaci, ve i
ponaanja. OO reprezentacija se prepoznaje po sledeim karakteristikama:
x identitet. Proistie iz injenice da su podaci organizovani u diskretne celine
koje se nazivaju objektima. Objekat ima svoja stanja i ponaanja (na
primer, ako je objekat brana, stanja mogu biti potpuno_otvorena ili
potpuno_zatvorena, dok ponaanje moe biti zvuno_upozorenje kada
branu treba otvoriti). Objekat ima ime koje ga identifikuje.

x apstrakcija. Predstavlja razliite aspekte sistema. Skup apstrakcija formira
hijerarhiju koja prikazuje meusobne odnose razliitih pogleda na sistem.
x klasifikacija. Podrazumeva grupisanje objekata sa zajednikim svojstvima i
ponaanjem. Jedna grupa se moe smatrati klasom kojoj se mogu dodeliti
odreena svojstva (atributi) i ponaanja (operacije). Nain grupisanja zavisi
od shvatanja osobe ili tima koji grupie objekte (na primer, avioni i bicikli
mogu predstavljati zasebne grupe, a mogu pripadati i istoj grupi prevozna
sredstva). Dva potpuno razliita grupisanja mogu se pokazati podjednako
ispravnim i korisnim. Za svaki objekat se kae da je primerak ili instanca
neke klase. Svaka instanca ima svoje vrednosti atributa, a sa ostalim
instancama iz klase ima samo zajednika imena atributa.
x enkapsulacija. Predstavlja tehniku pakovanja informacija tako da se spolja
vidi ono to treba da bude vidljivo, a ne vidi se ono to treba da bude
sakriveno. Klasa enkapsulira atribute i ponaanja objekta skrivajui
implementacione detalje.
x nasleivanje. Podrazumeva organizovanje klasa u hijerarhiju na osnovu
njihovih slinosti i razlika. Najpre se definie klasa sa sveobuhvatnim
osobinama, a zatim se rafinira u specijalizovane potklase. Potklasa moe da
nasleuje kako strukturu i atribute, tako i ponaanje nadreene klase.
x polimorfizam. Predstavlja osobinu da se isto ponaanje razliito
manifestuje kod razliitih klasa i potklasa. Pod ponaanjem se
podrazumeva akcija koju vri objekat ili akcija koja se vri nad objektom.
Metod klase predstavlja implementaciju operacije klase. U sistemu sa
polimorfizmom, vie razliitih metoda implementira istu operaciju.
x perzistencija. Predstavlja sposobnost da ime, stanje i ponaanje objekta
opstanu u vremenu, tj. da se ouvaju i nakon promene objekta. Takav
objekat je trajan. Ovo se koristi ukoliko se vrednost nekog atributa esto
menja, a potrebno je sauvati sve njegove vrednosti (na primer, kako bi se
kasnije napravio dijagram promene vrednosti tog atributa).

OO pristup se koristi u celom procesu razvoja, poevi od definisanja zahteva,
projektovanja sistema, programske implementacije, pa do testiranja. Ta
konzistentnost u terminologiji predstavlja vanu razliku OO pristupa od ostalih
tradicionalnijih pristupa. Poto OO pristup koristi enkapsuliranje informacija,
mnogi projektanti posmatraju klase i objekte sa stanovita mogunosti njihovog
ponovnog korienja u drugim projektima.

OO analiza zahteva obino se iskazuje jezikom bliskim korisniku i opisuje
pojmove i mogua scenarija iz posmatranog domena. Pojmovi obuhvataju razne

informacije, usluge i odgovornosti. Specifikacija zahteva koja odraava OO pristup
moe da predstavlja prve korake u projektovanju sistema. To je zato to se
identifikuju objekti u sistemu i definiu njihove meusobne veze. Pri projektovanju
sistema, vano je da se prepoznaju objekti realnog sveta, tj. objekti iz domena
problema, njihova svojstva i ponaanja. Takoe, treba uoiti i meusobna dejstva i
odnose meu objektima, kao to su asocijacije, nasleivanje i sl. Projekat sistema
predstavlja visok nivo apstrakcije onoga to e biti sadrano u projektu programa.
Projektanti programa na osnovu projekta sistema uvode niz detalja bitnih za
implementaciju, kao to su razna izraunavanja, proraun performansi, analiza
bezbednosti i dr. Nakon projektovanja programa, sistem je opisan na vrlo niskom
nivou apstrakcije pomou objekata. Sledi proces programiranja kojim se modeli
prevode u kd na nekom OO programskom jeziku. Prilikom kodiranja, tei se
uoptavanju sistema kako bi iste klase i objekti mogli kasnije ponovo da se koriste.
Po zavretku kodiranja, sledi testiranje programa. Najpre se testira ispravnost
pojedinanih modula, zatim se proverava ispravnost integrisanog sistema, i na
kraju se vri zavrno testiranje, kako bi se utvrdilo da li sistem ispunjava
postavljene zahteve.

Programeri implementiraju sistem (piu programski kd) na osnovu projekta
programa koji sadri ne samo klase i objekte iz projekta sistema, ve i neke
dodatne objekte. Ovi objekti nastaju kao rezultat dodatnih razmatranja:
x nefunkcionalnih zahteva sistema, kao to su potrebne performanse ili
ogranienja po pitanju izgleda korisnikog interfejsa
x ponovne upotrebljivosti komponenti iz ranije projektovanih sistema
x primenljivosti razmatranih komponenti u buduim sistemima
x zahteva po pitanju korisnikog interfesja
x struktura podataka koje e biti koriene i nainima upravljanja podacima

U projektu programa pojavljuju se mnogi objekti koje korisnik ne vidi, jer za
njih ne postoje odgovarajui objekti u realnom svetu. Na primer, u projektu sistema
moe da postoji opis na viem nivou kako su podaci organizovani i kako im se
pristupa. Meutim, u fazi projektovanja programa, moraju se doneti konkretne
odluke o strukturama u kojima e se uvati podaci (na primer, o matricama,
nizovima i sl.) jer su one neophodne kako bi programeri mogli da pristupe
kodiranju. Ovde se vidi jasna razlika izmeu nivoa apstrakcije prisutnog u
projektovanju sistema (visok nivo) i projektovanju programa (nizak nivo).

UML (Unified Modeling Language) je nastao 1996.godine objedinjavanjem
tri, u to vreme najuticajnije metode modelovanja: Booch-ove, OMT (Object
Modeling Technique, Rumbaugh) i OOSE (Object Oriented Software Engineering,
Jacobson). Ideja je bila da se prevazie problem neusaglaenosti postojeih metoda
i formira jedinstven jezik za modelovanje koji bi bio opte prihvaen kao standard.

UML predstavlja skup grafikih notacija zasnovanih na jedinstvenom
metamodelu. Pod grafikom notacijom podrazumeva se skup grafikih elemenata
koji definiu sintaksu jezika. Metamodel je dijagram koji opisuje koncepte jezika
za modelovanje. UML je iroko prihvaen u praksi, izmeu ostalog, i zbog toga to
se ni grafika notacija, ni metamodel ne moraju strogo primenjivati. Oni
predstavljaju samo pokuaj uvoenja discipline, ali je korisnost modela uvek na
prvom mestu.

UML standard obuhvata vei broj dijagrama za modelovanje (u veziji UML
2.4 iz 2011.godine ih je 14) i OCL jezik za specifikaciju ogranienja.
U nastavku su opisani osnovni UML dijagrami koji se koriste u razliitim
fazama procesa razvoja softvera. Za svaki dijagram navedena je njegova uloga,
osnovni elementi i nain njegovog generisanja.

5.1 Dijagrami sluajeva korienja

Svaki softverski sistem ima svoje korisnike iz spoljanjeg okruenja. To mogu
biti pojedinci, grupe ljudi, ali isto tako i drugi raunari ili ureaji. Zato je u procesu
modelovanja neophodno utvrditi granice sistema i precizno definisati naine na

5 UML modelovanje
80 UML modelovanje

koje sistem ostvaruje interakciju sa spoljanjim svetom. Tako se prikupljaju
funkcionalni zahtevi sistema. Nakon identifikacije svih moguih uesnika u
interakciji, za svakog od njih treba ustanoviti postupak same interakcije.

Sluaj korienja predstavlja opis postupka interakcije izmeu korisnika i
sistema. Treba ga razlikovati od funkcije sistema, jer mu je namena drugaija.
Funkcije opisuju sistem, a sluajevi korienja opisuju kako se sistem koristi.
Svaki sluaj korienja ima svoj jedinstveni cilj. Do tog cilja ne moe se uvek
doi samo na jedan nain, tj. jednom putanjom. Stoga je uveden pojam scenarija.
Scenario predstavlja niz sukcesivnih koraka kojima se opisuje interakcija korisnika
sa sistemom. Sluaj korienja moe da sadri vie scenarija, pri emu svi scenariji
moraju da budu voeni istim ciljem.
Nain pisanja sluaja korienja nije standardizovan, tako da se mogu
primenjivati razliiti formati. Meutim, uobiajeno je da se sluajevi korienja
piu na prirodnom jeziku u obliku prie. Najpre se navodi osnovni, uspeni
scenario u vidu numerisanih koraka, a zatim sva odstupanja od osnovnog scenarija
(takoe u vidu numerisanih koraka) sa jasnim referisanjem na mesta povratka u
osnovnom scenariju (ukoliko ih ima). Svaki korak predstavlja jedan deo
interakcije. Opis koraka mora da bude jasan i da ukazuje na njegovog izvrioca.
Korak pokazuje nameru uesnika, a ne nain na koji se neto ostvaruje. Postupak
pisanja sluaja korienja bie ilustrovan na jednom primeru.

Neka sluaj korienja Kupovina proizvoda treba da modelira postupak kako
kupac kupuje neki proizvod. Najpre treba napisati osnovni uspean scenario. On
sadri uobiajene korake u kupovini, kao to je dato na slici 5.1. Nakon toga treba
uoiti mogua odstupanja od osnovnog scenarija, bilo da je re o moguim
grekama (pogreno uneti podaci) ili o dodatnim mogunostima. U datom primeru,
u okviru proirenja, dodata su dva nova scenarija: jedan opisuje ta treba raditi
ukoliko je kupac redovan, pa ima odreene povlastice, dok drugi scenario govori o
tome ta se deava u sluaju kada kupac unese pogrean broj platne kartice. Pri
pisanju sluaja korienja, bitno je da se preciziraju koraci u osnovnom scenariju u
kojima dolazi do odstupanja, kao i mesta povratka iz dodatnih scenarija.

Sluaj korienja moe da bude prilino sloen u zavisnosti od postavljenog
cilja. U tom sluaju je pogodno razloiti ga na vie jednostavnijih sluajeva
korienja, koji se onda ukljuuju u polazni sluaj korienja. Ne postoji
standardan nain za ukljuivanje jednog sluaja korienja u drugi. Ipak, za
povezivanje se esto koristi hiperveza u vidu teksta koji je podvuen punom
linijom (videti korak 1 u osnovnom scenariju). Kada se u nekom sluaju korienja
pojavi hiperveza, to znai da je negde definisan ukljuen sluaj korienja na koji
ukazuje hiperveza. U datom primeru, postoji posebno definisan sluaj korienja
koji opisuje pregled kataloga.
Dijagrami sluajeva korienja 81

Kupovina proizvoda

Osnovni uspean scenario:
1. Kupac pregleda katalog sa proizvodima.
2. Kupac iz kataloga bira proizvod koji hoe da kupi.
3. Kupac unosi podatke o isporuci (adresu i uslove isporuke).
4. Sistem prikazuje podatke o trokovima.
5. Kupac unosi podatke o platnoj kartici.
6. Sistem proverava podatke o nainu plaanja.
7. Sistem potvruje prodaju.
8. Sistem alje kupcu priznanicu elektronskom potom.

Proirenja:
3a. Kupac je redovan.
1: Sistem prikazuje podatke o isporuci, cenama, trokovima.
2: Kupac potvruje ili menja vrednosti, povratak na korak 6.
6a. Podaci o platnoj kartici nisu ispravni.
1: Sistem nudi kupcu mogunost da ponovo unese podatke o kartici
ili se rad prekida, povratak na korak 7.

Slika 5.1 Sadraj sluaja korienja Kupovina proizvoda

Ukljueni sluajevi korienja su pogodni za opisivanje sloenih koraka koji
bi zauzeli puno prostora u osnovnom scenariju (detaljni opisi se teko itaju).
Takoe se koriste i ukoliko se isti koraci javljaju u vie razliitih sluajeva
korienja. Da se isti koraci ne bi vie puta puta ponavljali, mogu se izdvojiti u
poseban, ukljueni sluaj korienja, koji bi se onda povezao sa svim ostalim
nadreenim sluajevima korienja. Meusobnim povezivanjem sluajeva
korienja moe se ostvariti vie nivoa ugnjedavanja, ali preglednosti radi, ne sme
se preterati u broju nivoa.

Osim sadraja, sluajevi korienja mogu da poseduju i neke dodatne
informacije, kao to su:
x preduslov (pre-condition) koji opisuje ta treba da bude ispunjeno pre nego
to sistem dopusti izvravanje sluaja korienja
x garancija (guarantee) koja opisuje stanje sistema nakon izvoenja sluaja
korienja
x okida (trigger) koji definie dogaaj koji dovodi do zapoinjanja
izvoenja sluaja korienja

82 UML modelovanje

Ukljuivanje ovih dodatnih mogunosti moe da doprinese efikasnijem radu,
ali direktno ima uticaja i na potencijalne rizike. Stoga dodatne informacije treba
oprezno uvoditi, jer se one onda moraju strogo potovati.

Svaki softverski sistem podrava vei broj opcija, to znai da se moe
koristiti na razliite naine. Zato je prilikom njegovog modelovanja potrebno
definisati vei broj sluajeva korienja. Osim sadraja ovih sluajeva korienja,
vano je naglasiti i veze koje postoje izmeu njih, kao i njihove izvrioce. Jedan
sluaj korienja moe da ima vie izvrioca (ili uesnika actors). Tada je jedan
uesnik glavni (primary actor) i to je onaj koji trai uslugu od sistema. Ostali
uesnici sa kojima sistem komunicira su sporedni (secondary actors). Takoe,
jedan uesnik u sistemu moe da izvodi vie sluajeva korienja.

Dijagram sluajeva korienja predstavlja grafiki prikaz skupa svih
sluajeva korienja u sistemu ili delu sistema. On ukazuje na granice sistema i
njegovu interakciju sa spoljanjim svetom. Na dijagramu se mogu uoiti sledei
grafiki elementi:
x elipse koje prikazuju sluajeve korienja
x pojednostavljeni simboli oveka koji prikazuju uesnike, tj. izvrioce
sluajeva korienja
x pune linije koje povezuju sluaj korienja sa njegovim izvriocem
x isprekidanje linije sa strelicom koje povezuju ukljuene sa ostalim
sluajevima korienja
Na slici 5.2 dat je primer jednog dijagrama sluajeva korienja koji sadri
sluaj korienja Kupovina proizvoda iji je sadraj ranije opisan.

Slika 5.2 Primer dijagrama sluajeva korienja
Direktor
Kupac
Menader
Prodavac
Definisanje
povlastica
Kupovina
proizvoda
Prijavljivanje
na sistem
Izrada
kataloga
Pregled
kataloga

include
Dijagrami sluajeva korienja 83

Zbog mogueg velikog broja sluajeva korienja u sistemu, oni se
razvrstavaju u tri nivoa:
x osnovni nivo (sea-level). Ovom nivou pripadaju centralni sluajevi
korienja koji obino predstavljaju interakcije glavnog uesnika sa
sistemom.
x nii nivo (fish-level). Na ovom nivou se nalaze sluajevi korienja
ukljueni u sluajeve korienja na osnovnom nivou.
x vii nivo (kite-level). Ovaj nivo obuhvata uglavnom poslovne sluajeve
korienja koji pokazuju kako se sluajevi sa osnovnog nivoa uklapaju u
iri kontekst poslovnih interakcija.

Najvei broj sluajeva korienja u sistemu pripada osnovnom nivou.

5.2 Dijagrami klasa

Dijagrami klasa opisuju tipove entiteta u sistemu, razliite vrste statikih veza
koje postoje izmeu entiteta, kao i ogranienja u nainu njihovog povezivanja.
Zbog svog sadraja, ovi dijagrami se generiu praktino u svim fazama razvoja,
tako da predstavljaju najee koriene UML dijagrame. Ovi dijagrami imaju
najbogatiji skup tehnika za modelovanje od svih UML dijagrama.

Osnovni grafiki element u dijagramu klasa je model klase. On se sastoji od tri
komponente: imena klase, svojstava klase i operacija klase, kao to je prikazano na
slici 5.3.

Slika 5.3 Model klase

Svojstva klase opisuju strukturne karakteristike klase. Svojstva se pojavljaju u
dva oblika, kao atributi klase i kao asocijacije. Izmeu atributa i asocijacija postoje
velike slinosti, tako da se veina informacija moe modelovati i na jedan i na
Naziv klase

Svojstva klase

Operacije klase
84 UML modelovanje

drugi nain. Ipak, postoje i male razlike koje idu u prilog asocijacijama, a koje e
biti iznete u nastavku.
Poto se ista informacija moe modelovati na dva naina, postavlja se pitanje
kada koristiti koji od njih. Atributi prikazuju svojstvo u tekstualnom obliku, dok
asocijacije daju grafiki prikaz koji je uvek ilustrativniji. Stoga se atributi obino
koriste za opis jednostavnijih i manje vanih svojstava, kao to su datumi,
vrednosti logikih promenljivih i dr., dok su asocijacije pogodne za vizuelno
naglaavanje vanijih osobina klasa. Prema tome, izbor naina za prikaz nekog
svojstva zavisi prvenstveno od toga da li elimo da to svojstvo posebno istaknemo
(tada koristimo asocijacije) ili ne (tada koristimo atribute).

Atribut opisuje svojstvo u vidu reda teksta unutar klase. Potpuni oblik zapisa
atributa je
vidljivost ime:tip kardinalnost = podrazumevana_vrednost {opis_svojstva}

pri emu:
vidljivost oznaava da li je atribut javni (+), privatni (-), paketni (~) ili
zatieni (#)
ime predstavlja naziv atributa u klasi
tip ukazuje na to da postoji ogranienje po pitanju vrste objekata koji imaju
atribut
kardinalnost pokazuje na koliko objekata se odnosi svojstvo
podrazumevana_vrednost predstavlja vrednost atributa u novom objektu,
ukoliko se drugaija vrednost ne zada tokom generisanja objekta
opis_svojstva omoguava definisanje novih osobina atributa (na primer,
ako se koristi {readOnly} znai da nije dozvoljeno menjanje svojstva)

Kardinalnost se definie zadavanjem donje (DG) i gornje (GG) granice u
obliku DG..GG. DG moe biti pozitivan ceo broj ili nula, a GG pozitivan ceo broj
ili * koja oznaava da nema ogranienja sa gornje strane. Najee se sreu sledei
oblici kardinalnosti.
x 1, to oznaava da su DG i GG jednake; ekvivalentan zapis je 1..1 (na
primer, ovako se definie kardinalnost za sluaj Jedna porudbina mora da
ima tano jednog kupca.)
x 0..1, to oznaava da se svojstvo primenjuje na jedan ili nijedan objekat (na
primer, na ovaj nain se modeluje da Firma moe da ima posebnog
predstavnika, ali i ne mora.)
Dijagrami klasa 85

x *, to predstavlja skraeni zapis za 0..*; (na primer, ovako se modeluje da
Kupac ne mora da poalje porudbinu, ali ako eli, moe da poalje
neogranien broj porudbina.)

Asocijacija opisuje svojstvo punom linijom izmeu dve klase, usmerenom od
izvorne ka odredinoj klasi. Ime svojstva, kao i kardinalnost, navode se na
odredinom kraju asocijacije. Sama odredina klasa odreuje tip svojstva.

Definisanje atributa i asocijacija e biti ilustrovano na jednom primeru. Neka
klasa Porudbina poseduje tri svojstva: datumNaruivanja, (opisuje da li je i kada
porudbina poslata), plaenoUnapred (ukazuje na to da li je uplata izvrena) i
stavke (definie skup naruenih stavki, pri emu je svaka stavka opisana klasom
StavkaPorudbine koja mora biti posebno definisana). Ova svojstva se mogu u
okviru klase definisati javnim atributima kao to je dato na slici 5.4.

Slika 5.4 Modelovanje svojstava primenom atributa

Isti skup svojstava moe se predstaviti i na drugi nain, tj. pomou asocijacija
kao na slici 5.5.

Date Boolean Porudbina
StavkaPorudbine
+datumNaruivanja
+plaenoUnapred
stavke
{ordered}
0..1
*
1
1

Slika 5.5 Modelovanje svojstava primenom asocijacija

Kao to se vidi sa slike, kardinalnost moe biti zadata na oba kraja asocijacije
to, u odnosu na opis pomou atributa, predstavlja izvesnu prednost. Tako je u
datom primeru kardinalnou 1 opisano da jedna stavka porudbine moe da
pripada samo jednoj porudbini, a kardinalnou * (na drugom kraju asocijacije) da
porudbina moe da ima neogranien broj stavki.

Porudbina

+ datumNaruivanja: Date [0..1]
+ plaenoUnapred: Boolean [1]
+ stavke: StavkaPorudbine [*] {ordered}
86 UML modelovanje

Operacije klase opisuju aktivnosti koje klasa moe da obavi. Sintaksa
operacija je sledea:
vidljivost ime (lista_parametara) : tip_rezultata {opis_svojstva}

pri emu:
vidljivost ima isto znaenje kao u sluaju atributa
ime predstavlja naziv operacije
lista_parametara ukazuje na parametre operacije
tip_rezultata pokazuje kog je tipa rezultat operacije, ukoliko operacija ima
rezultat
opis_svojstva opisuje svojstva operacije

Parametri iz liste parametara definiu se sledeom sintaksom:
smer ime: tip = podrazumevana_vrednost

pri emu:
ime, tip i podrazumevana_vrednost imaju isto znaenje kao u sintaksi za
definisanje atributa
smer ukazuje na to da li je parametar ulazni (in), izlazni (out) ili ulazno-
izlazni (inout); ako smer nije oznaen, podrazumeva se da je parametar
ulazni (in)

U UML-u se razlikuju dve vrste operacija: upiti i modifikatori. Upiti samo
itaju neku vrednost iz klase ne menjajui vidljivo stanje sistema (stanje koje se
moe uoiti spolja). Oni nemaju sporednih efekata i obino se oznaavaju opisom
svojstva {query}. Redosled izvravanja upita se moe promeniti, a da se ne
promeni ponaanje sistema. Modifikatori su operacije koje menjaju stanje sistema.
Uobiajeno je da oni ne vraaju nikakav rezultat.

Dijagramom klasa moe se modelovati i generalizacija. Ona podrazumeva
smetanje zajednikih osobina vie klasa u optu klasu koja predstavlja nadtip. Sve
to vai da klasu koja je nadtip, vai i za klase koje su podtipovi (videti sliku 5.6).

Dijagrami klasa 87

Nadtip
Podtip 1 Podtip 2

Slika 5.6 Generalizacija

Generalizacija se realizuje pomou nasleivanja (inheritance). Vane
posledice nasleivanja su:
x zamenljivost, koja omoguava da se umesto objekta klase koja je nadtip
moe koristiti objekat bilo kog podtipa te klase
x polimorfizam, koji omoguava da objekat klase koja je podtip moe na
neke komande odgovoriti drugaije od objekta klase koja je nadtip, pri
emu je to transparentno za klijenta

Dijagramom klasa se mogu predstaviti i zavisnosti izmeu elemenata. Dva
elementa su zavisna ako promena definicije jednog elementa (davaoca)
prouzrokuje promenu definicije drugog elementa (klijenta). Zavisnost izmeu klasa
se javlja u sluajevima kada:
x jedna klasa alje poruku drugoj klasi (ako se promeni interfejs neke klase,
moe se desiti da poruke koje su joj upuene ne budu vie ispravne)
x jedna klasa sadri drugu klasu
x objekat jedne klase prosleuje objekat druge klase kao paramatar neke
operacije
Upravljanje zavisnostima je od izuzetnog znaaja za sistem. Poto su promene
u sistemu este, one se propagiraju kroz sistem tako to utiu na pojedine elemente.
to je vei broj elemenata koje treba promeniti, to je proces izmena tei. Poto se
izmene u klasama uglavnom reflektuju samo preko interfejsa, zavisnosti na nivou
interfejsa treba vrlo paljivo definisati.
U dijagramima klasa, zavisnosti se koriste uvek kada treba pokazati kako
promene jednog elementa menjaju drugi element. Na slici 5.7 prikazane su
zavisnosti (date isprekidanim linijama) u primeru vieslojne aplikacije.

Definisane su etiri klase: Pregled bonusa (koja pripada prezentacionom
sloju), Zaposleni (iz oblasti problema), Podaci o zaposlenima i Podaci o bonusima
88 UML modelovanje

(iz oblasti ponaanja sistema, tj. pravila poslovanja). Jednosmerna zavisnost
povezuje klasu Pregled bonusa sa klasom Zaposleni. To znai da promene u klasi
Pregled bonusa nee uticati na klasu Zaposleni (kao ni na ostale klase), dok
promene u klasi Zaposleni utiu na klasu Pregled bonusa samo ako se radi o
promeni interfejsa klase Zaposleni. Klasa Pregled bonusa nema direktnu zavisnost
od klasa sa podacima. Ukoliko se klase sa podacima promene, to moe dovesti do
promene klase Zaposleni. Meutim, uticaj ovih promena se tu zavrava, ukoliko se
menja samo realizacija klase Zaposleni, a ne i njen interfejs.

Pregled bonusa
Zaposleni
Podaci o
zaposlenima
Podaci o
bonusima

Slika 5.7 Primer definisanja zavisnosti

Ogranienja u sistemu se uglavnom modeliraju osnovnim elementima u
dijagramu klasa, kao to su: atributi, asocijacije, ili generalizacija. Meutim, ne
mogu se sva ogranienja prikazati na ovaj nain. UML doputa definisanje
proizvoljnih ogranienja, uz potovanje samo jednog pravila, a to je da opis
ogranienja mora biti dat unutar vitiastih zagrada ({}).

Za predstavljanje ogranienja mogu se koristiti:
x prirodni jezik - ovaj nain je neprecizan jer moe da dovede do razliitih
tumaenja, ali se ipak preporuuje
x neki od programskih jezika
x OCL (Object Constraint Language) UML-ov formalni jezik ogranienja
koji je dovoljno precizan, ali je neophodno poznavanje ovog jezika da bi se
razumelo ogranienje

Ogranienju se moe dodeliti ime koje je odvojeno dvotakom. Primer
ogranienja napisanog na prirodnom jeziku je:

{onemoguiti neregularnost ispita: student mora poloiti ispit pre unosa ocene}

Dijagrami sekvence 89

5.3 Dijagrami sekvence

Dijagrami sekvence opisuju saradnju objekata u obavljanju neke aktivnosti
vodei rauna o vremenskoj komponenti. Obino prikazuju scenario u okviru
sluaja korienja koji obuhvata izvestan broj objekata i poruka koje objekti
meusobno razmenjuju.
Na dijagramu sekvence, svaki uesnik u poslu prikazuje se pravougaonikom
sa nazivom uesnika. Iz pravougaonika polazi vertikalna isprekidana linija ivota
(lifeline) koja oznaava da je uesnik kreiran, tj. da postoji u sistemu. Uesniku
stiu poruke (messages) koje se na dijagramu predstavljaju horizontalnim punim
linijama sa strelicom na vrhu i itaju se odozgo na dole. Kada uesniku stigne
poruka, to znai da on treba da se ukljui u neki posao. Od mesta prispea poruke,
du linije ivota se generie pravougaonik koji predstavlja traku aktivnosti
(activation bar). Traka aktivnosti pokazuje da je uesnik aktivan u interakciji.
Trake odgovaraju izvravanju metoda uesnika. Na slici 5.8 dati su osnovni
elementi dijagrama sekvence.

Uesnik

Slika 5.8 Elementi dijagrama sekvence

Isti scenario sluaja korienja moe se pomou dijagrama sekvence
modelovati na razliite naine. Mogu se izdvojiti dva opta pristupa:
centralizovano i distribuirano upravljanje. Pristupi se razlikuju po nainu saradnje
uesnika u realizaciji datog scenarija.

Navedeni pristupi bie predstavljeni na primeru jednog scenarija. Neka je data
porudbina koja obuhvata vie stavki. Svaka stavka sadri: naziv proizvoda koji je
naruen, koliinu koja je naruena i jedininu cenu proizvoda. Po posmatranom
scenariju, porudbina prima poruku kojom se trai izraunavanje vrednosti cele
porudbine. Da bi izvrila ovaj zahtev, porudbina mora da pregleda sve svoje
stavke i izrauna njihove vrednosti na osnovu naruenih koliina i jedininih cena
proizvoda. Na kraju, porudbina treba da izrauna popust na osnovu pravila koja
90 UML modelovanje

vae za konkretnog kupca. Ovaj scenario se moe modelovati kao to je prikazano
na slici 5.9.

porudbina stavka porudbine proizvod kupac
raunajOsnovnuCenu
raunajCenu
uzmiKoliinu
uzmiProizvod
uzmiCenu
uzmiPopuste
raunajPopuste
proizvod

Slika 5.9 Primer centralizovanog upravljanja

Kao to se vidi, na dijagramu postoje etiri uesnika: porudbina, stavka
porudbine, proizvod i kupac. Primljena poruka raunajCenu formira traku
aktivnosti na liniji ivota uesnika porudbina. Ovaj uesnik alje poruku
uzmiKoliinu uesniku stavka porudbine i trai od njega podatak o naruenoj
koliini proizvoda. Zatim, na slian nain zahteva i podatak o vrsti proizvoda.
Nakon toga, alje uesniku proizvod poruku uzmiCenu da bi imao na raspolaganju i
taj podatak. Pozivom svoje metode, na osnovu dobijenih podataka, uesnik
porudbina najpre rauna cenu porudbine, a zatim i popust. Poto mu nedostaje
informacija o popustima, zahteva je od uesnika kupac slanjem poruke
uzmiPopuste.
Moe se videti da je na dijagramu nacrtana samo jedna povratna strelica
(isprekidana linija). Iako sline veze postoje za svaku poslatu poruku, preglednosti
radi, povratne veze ne moraju da budu nacrtane na dijagramu.
Opisani postupak modelovanja naziva se centralizovanim upravljanjem zato
to jedan uesnik (porudbina) obavlja obradu, a drugi uesnici ga snabdevaju
potrebnim podacima. To znai da uesnici nisu podjednako optereeni, tj. nemaju
isto uee u poslu. Ipak, ovakav nain modelovanja je vrlo pregledan i
jednostavan, pa je pogodan za poetnike.

Isti primer moe se modelovati i na nain prikazan na slici 5.10.


raunajCenu
raunajCenu
uzmiCenuSaPopustom(porudbina)
cenaSaPopustom
uzmiCenu(koliina:number)
uzmiOsnovnuCenu

Slika 5.10 Primer distribuiranog upravljanja

U ovom sluaju, uesnici sarauju na drugaiji nain. Nakon prijema poruke
raunajCenu, uesnik porudbina prosleuje poruku uesniku stavka porudbine i
trai od njega da izrauna sopstvenu cenu. Meutim, i ovaj uesnik preputa
izraunavanje cene drugom uesniku (proizvod), s tim to mu u poruci prosleuje
parametar o koliini naruenog proizvoda. Kada dobije informaciju o vrednosti
porudbine, uesnik porudbina alje poruku uesniku kupac traei od njega da
izrauna popust. Poto nema informaciju o vrednosti porudbine, kupac upuuje
povratnu poruku uesniku porudbina kako bi dobio potrebni podatak.
Ovakav nain modelovanja naziva se distribuiranim upravljanjem zato to je
obrada rasporeena izmeu vie uesnika, od kojih svaki izvrava svoj deo posla.
Kao to se vidi, preglednost dijagrama je manja nego u sluaju centralizovanog
upravljanja, ali je postignuto ravnomernije optereenje uesnika. Osim toga, ovaj
nain upravljana je efikasniji, ali zahteva iskusnije projektante.

Paljivom analizom, moe se primetiti da na oba data dijagrama sekvence
postoji jedan nedostatak. Naime, u oba sluaja se rauna cena samo jedne stavke u
porudbini. To je zato to nigde ne postoji petlja u okviru koje bi se prolazilo kroz
sve stavke porudbine.
Dijagrami sekvence mogu da modeluju petlje, ali se ne preporuuje njihovo
korienje u tu svrhu. Oni su prvenstveno namenjeni vizualizaciji interakcije
izmeu objekata, a ne modelovanju logike upravljanja.
Ipak, u UML-u je definisana notacija za modelovanje petlji u dijagramu
sekvence. Petlje se opisuju pomou okvira interakcije. Okvirom se ograniava deo
prostora na dijagramu sekvence koji obuhvata ono to treba da se izvri u petlji. U
92 UML modelovanje

uglu okvira navodi se operator loop, a desno od njega (u uglastim zagradama) opis
iteracije.
Kompletan dijagram sekvence za dati primer prikazan je na slici 5.11.

raunajOsnovnuCenu
raunajCenu
uzmiKoliinu
uzmiProizvod
uzmiCenu
uzmiPopuste
raunajPopuste
proizvod
loop
[for each stavka]

Slika 5.11 Modelovanje petlje

Na dijagramu sekvence, uesnici se mogu kreirati i brisati. Objekti se briu
kada nisu vie potrebni kako ne bi optereivali sistem.
Kreiranje uesnika se vri tako to se nacrta poruka povezana neposredno sa
nazivom uesnika. Ako kreirani uesnik odmah zapoinje neku aktivnost, traka
aktivnosti se crta kao da izlazi iz uesnika, a ako ne, crta se linija ivota kao to je
uobiajeno.
Brisanje uesnika se oznaava ukrtenim linijama X. Uesnika moe da
izbrie drugi uesnik ako poalje poruku ija strelica ulazi u X na kraju linije ivota
uesnika koji se brie. Uesnik moe i samog sebe da izbrie navoenjem X na
kraju svoje linije ivota.

Na primer, neka je potrebno da se iz baze podataka proita neki podatak (slika
5.12). Uesnik Upravlja dobija poruku da izvri ovu aktivnost. Da bi to uradio, on
moe da kreira uesnika Upit koji odmah poinje sa radom. Kreira novog uesnika
NaredbaBP i alje mu poruku izvri. Ovaj uesnik izvrava upit i dobijeni rekord
set prosleuje uesniku Upit. On poziva svoj metod koji iz rekord seta izdvaja
traeni podatak. Nakon toga alje poruku zatvori kojom brie nadalje nepotrebnog
uesnika NaredbaBP. Poto prosledi naeni podatak uesniku Upravlja, Upit
brie i samog sebe.


Upravlja
Upit
NaredbaBP
upitNadBazom
nov
nov
izvri
rekord set
izdvoj
rezultate
zatvori
rezultati

Slika 5.12 Generisanje/brisanje uesnika

5.4 Dijagrami aktivnosti

Dijagrami aktivnosti prikazuju tok posla koji treba obaviti kroz opisivanje
njegovih logikih procedura i postupaka.
Dijagram modelira aktivnost koja se sastoji od niza akcija. To znai da je
aktivnost iri pojam od akcije. Akcije se izvravaju u odreenom redosledu koji
zavisi od izgleda dijagrama. Dijagram aktivnosti poinje poetnim, a zavrava se
zavrnim vorom.

Najvanija uloga dijagrama aktivnosti je ta to omoguava modelovanje i
paralelnih i uslovnih ponaanja. Pod paralelnim ponaanjem podrazumeva se
izvravanje vie poslova istovremeno, dok uslovno ponaanje oznaava izbor posla
koji e se izvriti prema zadatom uslovu.

Paralelno ponaanje se na dijagramu predstavlja pomou grananja (fork) i
spajanja (join), iji su grafiki simboli dati na slici 5.13 a). Grananje ima jedan
ulazni tok i vie paralelnih izlaznih tokova. Svaki izlazni tok sadri akcije koje
treba izvriti u redosledu u kome su navedene. Meutim, redosled izvravanja
akcija koje pripadaju razliitim tokovima nije bitan (paralelno ponaanje). Kada se
izvre sve akcije u jednom izlaznom toku, dolazi se do spajanja. Spajanje ima vie
ulaznih tokova i jedan izlazni. Ulazni tokovi spajanja odgovaraju izlaznim
tokovima grananja. Da bi se prolo kroz spajanje, potrebno je ostvariti
94 UML modelovanje

sinhronizaciju svih ulaznih tokova, tj. sve akcije u svim tokovima moraju da budu
izvrene.

Akcije Akcije Akcije Akcije
a) b)
grananje odluka
spajanje stapanje
uslov

Slika 5.13 Osnovni elementi dijagrama aktivnosti

Za predstavljanje uslovnog ponaanja na dijagramu aktivnosti, koriste se
odluka (decision) i stapanje (merge), iji su grafiki simboli dati na slici 5.13 b).
Odluka ima jedan ulazni i vie izlaznih tokova. Svakom izlaznom toku je pridruen
uslov u vidu logikog izraza. Pri svakom nailasku na odluku, mogue se nastaviti
samo jednim od izlaznih tokova, tako da uslovi moraju da budu meusobno
iskljuivi. Rezervisana re else koristi se kao uslov koji ukazuje na tok kojim treba
nastaviti ukoliko su svi ostali uslovi odluke netani. Kroz stapanje se prolazi im se
izvre sve akcije u toku iji je uslov ispunjen.

Paralelno i uslovno ponaanje ilustrovani su primerom datom na slici 5.14.

Primer modelira aktivnost obrade narudbenice. Kada se primi narudbenica,
da bi se obradila, potrebno je obaviti dva posla: isporuiti naruene proizvode
kupcu i naplatiti ih. Navedeni poslovi su meusobno nezavisni (obavljaju ih
razliite slube) i mogu se obavljati istovremeno. Zato se modeluju pomou dva
paralelna toka, to je na dijagramu aktivnosti predstavljeno grananjem i spajanjem.
Isporuka proizvoda (tok levo) zahteva najpre pripremu naruenih proizvoda, a
zatim i njihovo slanje kupcu. Meutim, poto se, u zavisnosti od prioriteta
narudbenice, proizvodi mogu slati hitnom ili obinom isporukom, to se modeluje
uvoenjem odluke. Nakon izbora naina isporuke, prolazi se kroz stapanje i dolazi
do spajanja. Naplata vrednosti narudbenice (tok desno) izvodi se izvravanjem
akcija Slanje fakture i Naplaivanje. Kroz spajanje se prolazi tek kada su oba posla
izvrena (akcije iz oba toka). Tek tada postoje uslovi za zakljuivanje
narudbenice, ime se aktivnost zavrava.

Dijagrami aktivnosti 95

Primljena
narudbenica
Priprema
proizvoda
Hitna
isporuka
Obina
isporuka
Slanje
fakture
Naplaivanje
Zakljuivanje
narudbenice
[prioritetna
narudbina] [else]

Slika 5.14 Primer dijagrama aktivnosti

Akcije u dijagramu aktivnosti mogu same po sebi da budu sloene.
Modelovanje ovakvih akcija dovodi do uslonjavanja dijagrama aktivnosti i
smanjenja njegove preglednosti i jasnoe. Zato UML prua mogunost razlaganja
akcija na podaktivnosti. Razlaganje podrazumeva izradu novog dijagrama
podaktivnosti kojim se opisuje akcija. Naziv dijagrama podaktivnosti odgovara
imenu akcije. Dijagram podaktivnosti ima iste ulazne i izlazne parametre kao i
akcija koju opisuje. U glavnom dijagramu aktivnosti, nazivu akcije koja se razlae
pridruuje se simbol rave. On oznaava da za tu akciju postoji posebno definisan
dijagram podaktivnosti.

U primeru obrade narudbenice, moe se razloiti akcija koja se bavi izborom
naina isporuke proizvoda, kao to je prikazano na slici 5.15.

Dijagram pod a) odgovara ranije datom dijagramu aktivnosti u kome je
simbolom rave naglaeno da je akcija Isporui narudbinu razloena. Dijagram
podaktivnosti koji modelira razloenu akciju je dat pod b).

96 UML modelovanje

Primljena
narudbenica
Priprema
proizvoda
Hitna
isporuka
Obina
isporuka
Slanje
fakture
Naplaivanje
Zakljuivanje
narudbenice
[prioritetna
narudbina]
[else]
Isporui
narudbinu
Narudbenica Narudbenica
Isporui narudbinu
a) b)

Slika 5.15 Primer razlaganja akcije

Kao to je ranije reeno, obino se podrazumeva da spajanje dozvoljava
izvravanje izlaznog toka kada svi ulazni tokovi dou do take spajanja. Meutim,
nekad je korisno uvesti neko sloenije pravilo. Ono se moe predstaviti
specifikacijom spajanja.

Specifikacija spajanja je logiki izraz pridruen simbolu spajanja. Vrednost
izraza se rauna svaki put kada neki tok doe u fazu spajanja. Ukoliko je uslov dat
u specifikaciji ispunjen (a svi tokovi su stigli do spajanja), prelazi se na sledeu
akciju.
Primer upotrebe specifikacije spajanja dat je na slici 5.16.

Sipanje pia
Biranje pia
Ubacivanje novca
A
B
{joinSpec = A i B i vrednost ubaenog novca >= cena izabranog pia}

Slika 5.16 Primer specifikacije spajanja

Pretpostavimo da treba modelovati aktivnost uzimanja pia iz automata. Da bi
automat dao pie, oslukuje se da li je neko izabrao vrstu pia i da li je ubacio

novac u automat. Kada se izvre ove dve akcije, dolazi se do spajanja. Meutim, ne
sme se prei na sledeu akciju sipanja pia sve dok se ne proveri da li ubaeni
novac odgovara ceni eljenog pia. Ovaj uslov je modelovan specifikacijom
spajanja datom u vitiastim zagradama.

Dijagrami aktivnosti opisuju poslove koji treba obaviti, ali ne kazuju ko e te
poslove uraditi. Poto to moe da bude vrlo vana informacija, uvedena je
mogunost podele dijagrama aktivnosti na particije. Particije pokazuju koja klasa
ili organizaciona celina izvrava koje akcije. Postoje razliite mogunost podele na
particije. Najjednostavnija je jednodimenzionalna podela prikazana na slici 5.17
(za primer obrade narudbenice). Ova podela se, zbog slinosti, esto naziva
plivaka staza.

Primljena
narudbenica
Priprema
proizvoda
Slanje
fakture
Naplaivanje
Zakljuivanje
narudbenice
Isporui
narudbinu
Magacin Korisnika sluba Raunovodstvo

Slika 5.17 Primer podele na particije

Kao to se vidi, magacinska sluba se bavi pripremom i slanjem naruenih
proizvoda, korisnika sluba prijemom i zakljuivanjem narudbenice i slanjem
fakture, dok je raunovodstvo zadueno za naplatu.
Osim navedene, postoji i podela na particije u vidu dvodimenzionalne mree,
ili jednodimenzionalna hijerarhijska podela.
98 UML modelovanje

Mnogi sistemi ostvaruju interakciju sa spoljanjim procesima. U dijagramu
aktivnosti, ova interakcija se modelira pomou signala koje akcije primaju iz
spoljanjeg sveta ili ih alju u svet.
Aktivnost koja prima signal spolja, neprestano oslukuje signale, a na
dijagramu se prikazuje kako e aktivnost reagovati na prispeli signal. Primer
prijema signala dat je na slici 5.18.

Polazak na
aerodrom
Dolazak taksija
dva sata pre
poletanja
Pakovanje
stvari

Slika 5.18 Primer prijema signala

Primer modeluje odlazak na putovanje avionom. Kao to se vidi, dva sata pre
poletanja treba poeti sa pakovanjem stvari. To je predstavljeno peanim satom
koji oznaava vremenski signal, tj. signal koji nastaje zbog protoka vremena (ne
dobija se iz spoljanjeg sveta). Istovremeno se oekuje signal iz spoljanjeg sveta
da je stigao taksi, to je predstavljeno posebnim grafikim simbolom za prijem.
Spajanje se prolazi tek kada je stigao taksi, a i stvari su spakovane, pa postoje
uslovi da se krene na aerodrom.

Primer na slici 5.19 ilustruje slanje signala u okruenje. Slanje signala je
korisno kada treba saekati odgovor pre nego to se posao nastavi. To je standardan
nain za opisivanje isticanja dozvoljenog vremena.

Potvrda
putovanja
Slanje plana
ekanje 48 sati
Rezervacija
mesta
Potvren plan
Odustajanje
od putovanja

Slika 5.19 Primer slanja signala


U datom primeru, nakon rezervisanja mesta, alje se plan i oekuje signal o
njegovoj potvrdi. Kao to se vidi, simbol za prijem signala moe da ima i ulazni
tok koji oznaava da oslukivanje zapoinje tek kada ulazni tok aktivira prijem. Po
prijemu potvrde plana, potvruje se i putovanje. Istovremeno (paralelno), eka se
48 sati da stigne potvrda plana. Ako u tom periodu potvrda ne stigne, odustaje se
od putovanja. Prema tome, paralelni tok koji prvi stigne do zavretka, prekida drugi
tok.

Veze izmeu akcija u dijagramu aktivnosti predstavljaju se tokovima ili
ivicama. Postoje etiri ekvivalentna naina za povezivanje akcija:
x punom linijom koja se zavrava strelicom (slika 5.20 a)). U ovom sluaju
ivici se moe dodeliti ime, ali ne mora.
x parovima konektora (slika 5.20 b)). Konektori u jednom paru moraju biti
obeleeni istom oznakom da bi se znalo da ine par. U svakom paru, jedan
konektor ima ulazni, a drugi izlazni tok. Konektori se koriste u velikim
dijagramima aktivnosti kada treba povezati dve akcije na udaljenim
krajevima dijagrama. Da se ne bi povlaile linije preko celog dijagrama,
crtaju se konektori koji direktno povezuju akcije.
x prosleivanjem objekata du ivice crtanjem simbola klase (slika 5.20 c)).
x prosleivanjem objekata du ivice uz dodavanje noica simbolima akcija
(slika 5.20 d)). O noicama e biti rei u nastavku.

Akcija 1
Objekat
Akcija 2
Akcija 1 Akcija 2
Akcija 1 Akcija 2
Akcija 1 Akcija 2
Klasa
A A
Objekat
a)
b)
c)
d)

Slika 5.20 Naini povezivanja akcija

Akcije mogu da imaju parametere. Parametri se mogu prikazivati na
dijagramu aktivnosti, ali i ne moraju. Ukoliko je potrebno prikazati informacije o
100 UML modelovanje

parametrima, za njihovo modelovanje se koriste noice. Na dijagramu, noice se
crtaju u vidu kvadratia oslonjenih na simbol akcije.
Pri preciznom crtanju dijagrama aktivnosti, izlazni parametari jedne akcije
moraju da odgovaraju ulaznim parametara naredne akcije. Ukoliko to nije sluaj,
neophodno je definisati transformaciju parametara. Ona ukazuje na postupak
dobijanja ulaznih parametara naredne akcije na osnovu izlaznih parametara
prethodne akcije. Transformacija ne sme da proizvodi sporedne efekte.
Na slici 5.21 prikazan je primer korienja noica.

Otkai pregled
Obavesti pacijenata
transformation
pregled.pacijent
transformation
pregled.obavetenjeOOtkazivanju
Pacijent Poruka
Pregled

Slika 5.21 Primer upotrebe noica

Primer opisuje aktivnost otkazivanja lekarskog pregleda. Prilikom zakazivanja
pregleda, definie se objekat koji sadri osnovne informacije o pregledu:
identifikacioni broj pregleda, ime pacijenta, termin pregleda, itd. U sluaju da
pregled treba da bude otkazan, potrebno je o tome obavestiti pacijenta
odgovarajuom porukom. Otkazivanje pregleda se u dijagramu aktivnosti modeluje
pomou dve akcije: Otkai pregled i Obavesti pacijenta. Prva akcija ima jedan
izlazni parametar, Pregled, koji sadri informacije o pregledu. Druga akcija ima
dva ulazna parametra: poruku koju treba poslati i ime pacijenta. Poto se parametri
ovih akcija razlikuju, definisane su transformacije koje iz skupa informacija o
pregledu izdvajaju samo one koje je potrebno proslediti akciji Obavesti pacijenta.

U mnogim aktivnostima javlja se situacija u kojoj nakon neke akcije treba vie
puta izvriti neku drugu akciju. Najbolji nain za modelovanje ove situacije je
korienje oblasti primene.
Oblast primene predstavlja deo dijagrama aktivnosti u kome se akcije
izvravaju po jednom za svaki element ulazne kolekcije. Svako pojedinano
izvravanje akcija proizvodi odgovarajui element izlazne kolekcije. Oblast
primene se naputa nakon kompletiranja izlazne kolekcije. Broj elemenata u
ulaznoj kolekciji moe, ali ne mora da odgovara broju elemenata u izlaznoj

kolekciji. Ako su ovi brojevi elemenata razliiti, oblast primene se ponaa kao
filtar.
U oblasti primene, elementi ulazne kolekcije se mogu obraivati na dva
naina:
x paralelnom obradom, u kojoj se elementi obrauju istovremeno (oznaava
se rezervisanom reju concurrent)
x iterativnom obradom, u kojoj se elementi obrauju jedan za drugim

Na slici 5.22 dat je primer korienja oblasti primene.

Izbor tema
Napii tekst
lista tema
Pregledaj tekst Objavi bilten
concurrent

Slika 5.22 Primer upotrebe oblasti primene

Primer modeluje aktivnost objavljivanja biltena. Da bi se objavio bilten,
potrebno je na zadate teme napisati odgovarajue lanke, pregledati ih i od
prihvaenih tekstova sainiti bilten. Skup tema predstavlja ulaznu kolekciju.
Elementi (pojedinane teme) ulazne kolekcije obrauju se paralelno, zato to
lanke piu razliiti autori. Svaka tema se obrauje kroz dve akcije: Napii tekst i
Pregledaj tekst. One se nalaze u oblasti primene (ovalni pravougaonik) zato to se
ponavljaju vie puta. Svaki prihvaeni lanak uvruje se u izlaznu kolekciju.
Dakle, u ovom primeru brojevi elemenata u ulaznoj i izlaznoj kolekciji ne moraju
biti jednaki. Kada se kompletira izlazna kolekcija, prelazi se na akciju objavljivanja
biltena.

U dijagramu aktivnosti postoji mnotvo tokova. Svaki tok moe da se prekine
zavretkom toka, bez prekidanja cele aktivnosti. Zahvaljujui zavretku toka,
oblasti primene ostvaruju svoju filtarsku ulogu. Na slici 5.23 prikazano je kako se u
prethodnom primeru objavljivanja biltena postie filtriranje.

102 UML modelovanje

Izbor tema
Napii tekst
lista tema
Pregledaj tekst
Objavi bilten
concurrent
prihvaen
odbijen

Slika 5.23 Primer upotrebe zavretka toka

Kao to se vidi, ukoliko se lanak ne prihvati za objavljivanje, tok se zavrava.

5.5 Dijagrami komponenata

Dijagrami komponenata opisuju fiziku organizaciju softverskih komponenata
u sistemu i zavisnosti koje postoje izmeu njih. Oni daju statiki pogled na
implementaciju sistema. Komponente mogu biti biblioteke, paketi, datoteke, i sl.
Jednim dijagramom se obino ne moe predstaviti ceo sistem, pa se zato pravi
kolekcija ovih dijagrama. Ova vrsta dijagrama se najee koristi u fazi
implementacije, ali je korisna i prilikom odravanja sistema.

Na dijagramima komponenata se pojavljuju stvari i relacije. Stvari ine
komponente, klase, atrefakti, interfejsi, portovi, podsistemi, dok relacije obuhvataju
zavisnosti, generalizacije, asocijacije, realizacije.

Komponenta je apstrakcija fizikog, zamenljivog dela sistema. Ona kapsulira
neki sadraj koji je okruenju vidljiv samo kroz interfejse. Na slici 5.24 data je
grafika notacija komponente (verzija UML 2) u dve varijante.

Komponenta
component
Komponenta

Slika 5.24 Grafiki prikaz komponente

Dijagrami komponenata 103

Komponenta moe da sadri deo u kome su navedene klase koje realizuje, kao
to je prikazano na slici 5.25.

Komponenta
realizations
Klasa1
Klasa2
Komponenta
Klasa1
Klasa2

Slika 5.25 Komponenta sa klasama koje realizuje

Izmeu komponente i klase postoje slinosti i razlike. Slinosti su u tome to
obe imaju imena, realizuju interfejse i imaju elemente zavisnosti generalizacije i
asocijacije veza. Razlike su u tome to je klasa logika apstrakcija, dok je
komponenta fizika realizacija (u svetu bitova). Komponente predstavljaju fiziko
pakovanje razliitih logikih apstrakcija. Osim ovoga, klase imaju atribute i
operacije, a komponente samo operacije koje su dostupne preko interfejsa.

Mnoge vrste sistemskog softvera (na primer, operativni sistemi ili programski
jezici) podravaju koncept komponenata. Primeri komponenata su JavaBean, EJB,
CORBA, .NET assembly, itd.
U UML-u su definisani sledei standardni stereotipovi za komponente:
x executable oznaava komponentu koja se moe izvravati
x library oznaava statiku ili dinamiku objektnu biblioteku
x file oznaava datoteku sa proizvoljnim sadrajem
x document oznaava dokument
x script oznaava skript
x source oznaava datoteku sa izvornim kdom

Artefakt je fizika informacija koja nastaje ili se koristi u procesu razvoja,
procesu izvravanja programa, ili pri isporuci softvera. Na primer, u procesu
razvoja, nastaju artefakti u vidu modela, izvornog kda, raznih dokumenata, a
koriste se resursi. Prilikom izvravanja programa, mogu da nastanu objekti kreirani
iz DLL-a. Pri isporuci, artefakti mogu biti datoteke sa ekstenzijom .dll, .exe, .jar,
razne tabele i sl.
Primer grafikog prikaza artefakta (u dve varijante) dat je na slici 5.26.

104 UML modelovanje

artifact
obrada.jar
obrada

Slika 5.26 Primer artefakta

Artefakt moe da predstavlja manifestaciju komponente, kao to je prikazano
na slici 5.27.

artifact
obrada.jar
obrada
manifest

Slika 5.27 Artefakt kao manifestacija komponente

Interfejs je skup operacija koji specificira servise komponente. Jedna
komponenta moe da realizuje jedan ili vie interfejsa. Interfejs se na dijagramu
komponenata predstava u vidu kanonike (slika 5.28 a)) ili skraene forme (slika
5.28 b)).

Komponenta
Interfejs
Komponenta
interface
Interfejs
a) b)

Slika 5.28 Grafiki prikaz interfejsa

Komponente, kao osnovni gradivni elementi softverskog sistema, treba da
budu slabo povezane, kako se izmena u jednoj komponenti ne bi odraavala na
ostatak sistema. Da bi se to postiglo, uvedeno je da se komponentama moe
pristupati samo preko interfejsa. Interfejsi, u stvari, odvajaju implementaciju od
ponaanja komponente. Jedna komponenta moe, bez ikakvih popravki, da bude
zamenjena drugom komponentom sa istim interfejsom.
Postoje dve vrste interfejsa: eksport i import interfejsi. Eksport interfejs je
interfejs koji komponenta realizuje. On obezbeuje servis drugih komponenata. Za
razliku od njega, import interfejs predstavlja interfejs koji komponenta koristi i on
omoguava njenu nadgradnju. Zato se eksport interfejs naziva i ponuenim, a
import interfejs, zahtevanim interfejsom. Ponueni interfejs pokazuje koje servise
komponenta nudi drugim komponentama. Zahtevani interfejs ukazuje na servise
koji su datoj komponenti potrebni od strane drugih komponenata za njeno
Dijagrami komponenata 105

funkcionisanje. Komponenta moe da ima vie interfejsa obe vrste. Na slici 5.29
prikazane su obe vrste interfejsa.

Komponenta
ponueni
zahtevani

Slika 5.29 Vrste interfejsa

Kombinacijom grafikih oznaka za ponueni (loptica) i zahtevani (postolje)
interfejs, dobija se veznik sklopa (assembly connector). Primer interakcije
ostvarene na ovaj nain dat je na slici 5.30.

Exe Dll

Slika 5.30 Primer primene veznika sklopa

Zavisnosti opisuju veze izmeu komponenata i na dijagramu se predstavljuju
usmerenom isprekidanom linijom, kao na slici 5.31. Prema slici, komponenta
Modul 1 koristi neke servise koji su obezbeeni u komponenti Modul 2.

Modul 1 Modul 2

Slika 5.31 Zavisnosti izmeu komponenata

Port predstavlja taku interakcije sa okruenjem. Komponenta moe da
ispoljava interfejse preko porta. Naime, portu se mogu pridruiti interfejsi koji
specificiraju prirodu interakcije komponente sa okruenjem. Na dijagramu
komponenata, port se grafiki predstavlja kao na slici 5.32.

component
Komponenta
imePorta:TipPorta

Slika 5.32 Grafiki prikaz porta

Podsistemi predstavljaju fizike podsisteme u sistemu. Oni mogu da sadre
komponente ili druge podsisteme. Najee reprezentuju direktorijume u sistemu
106 UML modelovanje

datoteka. Grafiki prikaz podsistema koji obuhvata komponente za uvanje
podataka dat je na slici 5.33. Slian je prikazu komponente, s tom razlikom to se
koristi druga rezervisana re.

subsystem
uvanjePodataka

Slika 5.33 Grafiki prikaz podsistema

Primer dijagrama komponenata prikazan je na slici 5.34. U datom sistemu
postoje etiri komponente: Proizvod, Kupac, Nalog i Raun. Eksport interfejse
realizuju komponente Proizvod i Kupac, a import interfejse, komponenta Nalog.
Zavisnou se mapiraju detalji koji se odnose na raun pridruen kupcu sa import
interfejsom Plaanje koga realizuje komponenta Nalog.

Nalog
Proizvod
Kupac
Raun
Plaanje
DetaljiORaunu
DetaljiOKupcu
KdProizvoda

Slika 5.34 Primer dijagrama komponenata

5.6 Dijagrami rasporeivanja

Dijagrami rasporeivanja opisuju fiziku organizaciju sistema, prikazujui
njegovu hardversku i softversku arhitekturu. Na njima je jasno navedeno koje
hardverske i softverske komponente postoje u sistemu, kao i koja softverska
Dijagrami rasporeivanja 107

komponenta se izvrava na kojoj hardverskoj komponenti. Takoe su definisane i
veze izmeu razliitih delova sistema.

Osnovni elementi dijagrama su vorovi, artefakti i veze.

vor je apstrakcija fizikog objekta koji predstavlja resurs obrade. To moe da
bude neki ureaj (na primer, raunar ili mobilni telefon) ili neko izvrno okruenje,
tj. softver koji opsluuje neki drugi program (na primer, operativni sistem,
kontejnerski procesi, vituelna maina i sl.). vorove esto predstavljaju web
serveri, serveri baze podatka, aplikativni serveri, itd. vorovi se na dijagramu
rasporeivanja prikazuju u vidu kutija sa imenom vora. Oni mogu da imaju i
instance, to se naznaava podvlaenjem imena instance. Na slici 5.35 pod a) je dat
primer vora, dok je pod b) prikazana instanca vora koja predstavlja odreeni
raunar.

Raunar
A1 sala:
Raunar
a) b)

Slika 5.35 Primer vora i instance vora

Artefakti su softverske komponente koje se izvravaju u vorovima. To su
obino datoteke, koje mogu biti izvrne (.exe, .dll, .jar, itd), datoteke sa podacima,
konfiguracione datoteke, HTML dokumenti i dr. Artefakti se na dijagramu
predstavljaju u vidu pravougaonika unutar vorova (kutija) na koje su alocirani, na
nain prikazan na slici 5.36.

Raunar
artifact
main.c

Slika 5.36 Primer artefakta

esto se deava da vie fizikih vorova obavljaju logiki srodne poslove. Oni
se mogu grupisati u pakete. Na slici 5.37 prikazani su paketi servera (pod a)) i
klijenata (pod b)) koji se koriste u sistemu.

108 UML modelovanje

WebServer
a)
b)
AplikativniServer ServerBazePodataka
Serveri
Klijenti
Laptop Desktop

Slika 5.37 Primeri paketa vorova

vorovi mogu da budu i ugnjedeni, tj. jedan vor moe da sadri drugi. To se
na dijagramu predstavlja kao na slici 5.38.

device
Server Baze Podataka
execution environment
RDBMS

Slika 5.38 Ugnjedeni vorovi

Veze predstavljaju komunikacione putanje izmeu razliitih delova sistema.
Za njihovo prikazivanje na dijagramu rasporeivanja, koriste se asocijacije.

Primer dijagrama rasporeivanja dat je na slici 5.39. On modeluje arhitekturu
web aplikacije kojoj moe da se pristupa preko PDA (Personal Digital Assistent)
ureaja za upravljanje linim informacijama. Aplikativni server je povezan sa
MySQL bazom podatka.

Dijagrami rasporeivanja 109

device
Web server
artifact
Web sajt
device
PDA
device
Aplikativni server
artifact
IMS.jar device
Server BP
artifact
MySQL server
device
Terminal
artifact
IMSClient.jar
artifact
ORM.jar

Slika 5.39 Primer dijagrama rasporeivanja

Implementacija ili kodiranje podrazumeva softversku realizaciju reenja
razmatranog problema. Rezultat implementacije je skup programa koji ispunjavaju
zadate funkcionalne zahteve. Osnovu za implementaciju predstavlja projekat
programa. Meutim, sistem se uvek moe realizovani na mnogo razliitih naina:
mogu se koristiti razliiti programski jezici, razvojna okruenja, hardverske
platforme, itd. Cilj ovog poglavlja je da ukae na opte principe implementacije, tj.
na praktine elemente softverskog inenjerstva koje treba imati na umu prilikom
pisanja programa.
Iako na prvi pogled proces implementacije izgleda jednostavan, jer je sve
ranije definisano modelima, obino to nije tako. Najpre, treba imati u vidu da
postoji mogunost da projektanti nisu uzeli u obzir sve specifinosti platforme ili
razvojnog okruenja koji e biti korieni. Drugo, strukture podataka je ipak
jednostavnije predstaviti tabelama ili graficima nego napisati ekvivalentan
programski kd. Tree, programi moraju da budu razumljivi ne samo onima koji
su ih pisali, ve i drugima koji uestvuju u procesu razvoja (onima koji testiraju
sistem, onima koji ga odravaju i dr.). etvrto, treba teiti ka tome da se napisani
kd moe jednostavno ponovo iskoristiti, ukoliko se za to ukae prilika.

U zavisnosti od vrste projekta, proces implementacije moe da bude razliit.
Programeri mogu da budu u prilici da analiziraju postojei tui kd kako bi ga
izmenili, dogradili, ispravili uoene greke, ili ga iskoristili u sklopu neke druge
aplikacije. Takoe, mogu i da analiziraju ili generiu sopstveni kd u okviru
realizacije nekog novog modula. Bez obzira na okolnosti u kojima rade, programeri
su uvek deo tima koji razvija softver. To znai da je neophodno obezbediti visok
nivo saradnje i koordinacije izmeu svih lanova tima kako bi softverski proizvod
bio kvalitetan.

6 Implementacija softvera

U razvoju softvera moraju se potovati standardi koji vae u konkretnom
okruenju. Mnoge kompanije zahtevaju da programski kd bude usklaen po
pitanju stila, formata, sadraja i drugih parametara, kako bi sm kd i pratea
dokumentacija bili jasni svakome ko ih ita. Ovakav pristup ima brojne prednosti,
kao to su:
x primena standarda i procedura pomau programerima da uspostave
sistematinost u svom radu
x standardizovana dokumentacija omoguava lake i bre tumaenje kda
x olakano je pronalaenje greaka u kdu
x novonastale izmene se mogu jednostavnije uneti u sistem, jer je jasno koji
deo kda implementira koju funkcionalnost
x strukturiranjem kda prema standardima odrava se usklaenost elemenata
iz dizajna sa elementima iz implementacije
x olakan je nastavak rada na projektu ukoliko je iz nekog razloga projekat
morao da bude prekinut na neko vreme

U procesu implementacije najvanije je potovati standard koji se tie
usklaenosti elemenata iz projekta sa elementima iz implementacije. Ukoliko se
modularnost pristupa iz faze projektovanja ne prenese na fazu implementacije,
onda dolazi do degradacije celog projekta. Osobine projekta, kao to su slaba
spregnutost komponenata, ili dobro definisane veze izmeu komponenata treba da
budu i osobine napisanih programa. Samo na taj nain je mogue lako praenje
implementiranih algoritama, struktura podataka i funkcija unutar kda u smislu
njihove usklaenosti sa projektom.

Tokom pisanja svog dela kda, programer treba da vodi rauna o tome da e
njegov kd najverovatnije koristiti druge osobe na razliite naine. Na primer, ako
programer nije lan tima za testiranje, neko drugi e testirati njegov kd. Ili, moda
e neko drugi integrisati njegov modul sa ostalim programima u sistemu. ak i u
sluaju da je napisani kd samostalan, moe se javiti potreba za nekim izmenama,
bilo zbog neke greke, ili zbog promena koje zahteva kupac. U svakom sluaju,
bitno je da kd bude dobro organizovan, jasan i dobro dokumentovan
odgovarajuim komentarima.

Pisanje programa 113

6.1 Pisanje programa

Pisanje programa je kreativan proces u kome programer prevodi opise sistema
date u projektu u programski kd na konkretnom programskom jeziku. Pri
implementaciji, programer ima veliku slobodu, jer se ista funkcionalnost uvek
moe realizovati na razliite naine. Ponekad, specificirani zahtevi ili projekat
uslovljavaju izbor programskog jezika.
Da bi se postiglo da programski kd odraava dizajn sistema, potrebno je
potovati nekoliko optih smernica za pisanje programa:
x lokalizacija ulaza i izlaza
x korienje pseudokda
x revidiranje kda
x viekratna upotrebljivost

Pod lokalizacijom ulaza i izlaza podrazumeva se izdvajanje delova
programskog kda koji se odnose na uitavanje ulaznih podataka ili generisanje
izlaznih veliina u posebne specijalizovane komponente u okviru sistema. Na taj
nain se dobija sistem koji se lake moe modifikovati, ukoliko se za to ukae
potreba. Ove specijalizovane komponente odraavaju osobine trenutno korienog
hardvera i softvera. Ukoliko doe do promene hardvera ili softvera, najverovatnije
e biti potrebno da se i komponente koje opisuju ulaze i izlaze izmene, pa je zato
dobro da budu izdvojene od ostatka sistema.
Lokalizacija vodi uoptavanju sistema. Osim unosa podataka, ulaznim
komponentama mogu se dodati i druge funkcionalnosti, kao to su provera
ispravnosti unetih podataka, formatiranje unetih podataka i sl. Na ovaj nain se
ostale komponente u sistemu rastereuju poslova vezanih za ulaze. Slino ovome,
objedinjavanje izlaznih funkcija u jednu komponentu vodi lakem razumevanju i
menjanju sistema.

Prilikom projektovanja neke komponente, njen dizajn ne mora da bude strogo
povezan sa nekim programskim jezikom, ili konkretnom strukturom podataka
kojom e ona biti predstavljena. Dizajn je obino samo okvir koji ukazuje na to ta
ta komponenta treba da radi. Da bi se dizajn pretoio u kd, potrebni su znanje i
individualna kreativnost programera. Da ne bi dolo do loe realizacije, korisno je
da se od dizajna ka kdu ne ide naglo, ve u fazama.
Pre konane realizacije komponente u izabranom programskom jeziku, dobro
je ispitati vie alternativa kako bi se utvrdilo koja je implementacija najbolja. Za to
se moe koristiti pseudokd. Pod pseudokdom se podrazumeva kd napisan
obinim jezikom koji se koristi u datoj oblasti. Pseudokd je slobodnijeg stila, i u

njemu se, osim opisa, esto koriste i sintaksni elementi postojeih programskih
jezika (zagrade, strukture za kontrolu toka, itd). Sledi primer pseudokda koji
realizuje funkciju za raunanje faktorijela.

funkcija faktorijel (ceo broj n)
{
ceo broj rezultat = 1
dok je n vee od 1 {
rezultat = rezultat * n
smanjiti n za 1
}
vratiti rezultat
}

Zbog svoje deskriptivnosti, pseudokd se jednostavno i brzo analizira i menja,
pa se njegovom primenom znaajno tedi vreme potrebno za donoenje odluke o
tome kako e komponenta zaista biti realizovana. Tokom analize razliitih varijanti
pisanih pseudokdom, mogu se uoiti i korisne izmene u dizajnu. O tome treba
obevestiti projektante, kako bi se dobila njihova saglasnost o predloenim
izmenama. Na ovaj nain se odrava usklaenost izmeu dizajna i kda.
Pseudokd predstavlja dobru osnovu za lako pisanje kda na izabranom
programskom jeziku.

Prilikom pisanja kda najpre se pravi gruba skica, a zatim se taj kd revidira i
ponovo pie sve dok se ne postigne eljeni rezultat. Ukoliko se programeru ini da
je kd nerazumljiv i zamren, ili ne moe da rei neke probleme (grananja, petlji i
sl.), neophodno je da ponovo razmotri dizajn. Tako e utvrditi da li je problem u
dizajnu (tada treba da konsultuje projektante) ili u njegovom prevoenju dizajna u
kd. Ako je problem u prevoenju, onda programer treba da preispita nain
predstavljanja i strukturiranja podataka, primenjene algoritme i dr.

Dobra praksa pri pisanju kda je da se komponente realizuju tako da mogu
ponovo da se primene, a takoe je dobro i da se koriste ranije implementirane
komponente. Viekratno upotrebljive komponente ubrzavaju proces pisanja kda i
smanjuju broj potencijalnih greaka (ranije realizovane komponente su ve
istestirane).

Prilikom generisanja viekratne komponente, treba voditi rauna o sledeem:
x komponenta treba da bude opta i da radi u to fleksibilnijim uslovima
x u okviru komponente treba izdvojiti delove podlone promenama (zbog
promene radnih uslova) od delova koji se najverovatnije nikada nee
menjati

x interfejs komponente treba da bude opti i dobro definisan
x pri imenovanju veliina treba primenjivati jasne i logiki intuitivne
konvencije
x neophodno je dokumentovati strukture podataka i algoritme koriene pri
izgradnji komponente
x potrebno je navesti informacije o otkrivenim i ispravljenim grekama

Da bi se ranije implementirana komponenta ponovo koristila, potrebno je
proveriti sledee:
x da li ona obavlja funkciju koja je potrebna
x ako je potrebna manja izmena komponente, da li je bolje uraditi tu
promenu ili napraviti novu komponentu
x da li je komponenta dobro dokumentovana, tako da je potpuno jasna njena
funkcija
x da li postoji evidencija o testiranju i revizijama komponente koja bi
garantovala da u njoj nema greaka

Pri ugraivanju viekratne komponente, treba proceniti i koliko kda bi
trebalo napisati da bi sistem mogao da sarauje sa ovom komponentom.

Bez obzira na korieni programski jezik, realizacija svake programske
komponente zahteva utvrivanje struktura podataka, algoritama i kontrolnih
struktura koji e biti primenjeni.

6.1.1 Strukture podataka

Pre pisanja programa, potrebno je uraditi neke pripremne radnje kako bi se
sm proces pisanja pojednostavio, a napisani kd bio efikasniji. Jedna od njih je
osmiljavanje struktura podataka u kojima e se uvati podaci bitni za rad
komponente koju program realizuje. Strukture podataka se biraju tako da se
podacima u njima lako upravlja i manipulie. Nakon utvrivanja struktura podataka
koje e biti koriene u realizaciji, program se organizuje u skladu sa njima.

Izbor struktura podataka moe se preuzeti iz dizajna, tj. projekta (ukoliko su
tamo definisane odgovarajue strukture), ili se moe napraviti u fazi
implementacije na osnovu manipulacija koje treba izvriti nad podacima u okviru
komponente.

Izabrane strukture podataka direktno utiu na sloenost i efikasnost programa.
Na primer, pretpostavimo da komponenta rauna porez na dohodak. Ulazni podaci
u komponentu su iznos dohotka koji treba da se oporezuje i sledea pravila:

a) Za prvih 100000 din. dohotka, poreska stopa iznosi 10%.
b) Za sledeih 100000 din. dohotka (iznad 100000 din.), poreska stopa iznosi 12%.
c) Za sledeih 100000 din. dohotka (iznad 200000 din.), poreska stopa iznosi 15%.
d) Za sledeih 100000 din. dohotka (iznad 300000 din.), poreska stopa iznosi 18%.
e) Za dohodak iznad 400000 din., poreska stopa iznosi 20%.

Na osnovu datih pravila sledi da neko ko je imao oporezovani dohodak u
iznosu od 350000 din. plaa 10% od prvih 100000 din. (to iznosi 10000 din.),
zatim 12% od sledeih 100000 din. (12000 din.), 15% od sledeih 100000 din.
(15000 din.) i 18% od preostalih 50000 din. (9000 din.), to ukupno iznosi 46000
din.
Kd u programskom jeziku C koji realizuje komponentu za raunanje poreza
na dohodak moe da ima sledei izgled:

int racunanje_poreza(int dohodak) {
int porez = 0;

if (dohodak == 0) return porez;
if (dohodak > 100000) porez = porez + 10000; // 10% na prvih 100000 din.
else {
porez = porez + 0.1 * dohodak;
return porez;
}
if (dohodak > 200000) porez = porez + 12000; // 12% na drugih 100000 din.
else {
porez = porez + 0.12 * (dohodak 100000); // 12% na preko 100000 din.
return porez;
}
if (dohodak > 300000) porez = porez + 15000; // 15% na trecih 100000 din.
else {
return porez;
}
if (dohodak > 400000)
// 18% na cetvrtih 100000 din. i 20% na preko 400000 din.
porez = porez + 18000 + 0.2 * (dohodak 400000);
else
return porez;
}


Neka je definisana tabela sa podacima o poreskim stopama u zavisnosti od
intervala u kome se nalazi iznos oporezovanog dohotka, kao to je prikazano u
tabeli 6.1.

Donja granica opsega (dgo) Stopa (s)
0 0.10
100000 0.12
200000 0.15
300000 0.18
400000 0.20

Tabela 6.1 Tabela sa podacima o poreskim stopama

Algoritam za raunanje poreza moe se znatno uprostiti ukoliko se koristi data
tabela:

int racunanje_poreza(int dohodak) {
int porez = 0;
if (dohodak == 0) return porez;
for (i = 0; i < 4; i++) {
if (dohodak > dgo[i+1])) {
porez = porez + s[i]*100000;
if (i == 3) porez = porez + s[i+1] * (dohodak dgo[i+1]);
}
else {
porez = porez + s[i] * (dohodak dgo[i]);
return porez;
}
}
return porez;
}

Usvojene strukture podataka, u nekim sluajevima, mogu da utiu i na izbor
programskog jezika. Na primer, programski jezik LISP je projektovan za rad sa
listama, za predikatski raun pogodan je Prolog, dok Ada i Eiffel omoguavaju
obradu nedozvoljenih stanja, tj. izuzetaka. Pascal je pogodan za implementaciju
rekurzivnih struktura podataka, kao to su stabla.

6.1.2 Algoritmi

U projektu programa obino su definisani algoritmi koje treba upotrebiti za
realizaciju date komponente. To mogu, na primer, da budu algoritmi za sortiranje,

optimizaciju, viekriterijumsko odluivanje, itd. Iako su algoritmi poznati, postoji
velika fleksibilnost u pogledu njihove realizacije, zavisno od ogranienja koje
postavljaju korien programski jezik i raspoloiva hardverska platforma. Razliito
realizovani algoritmi imaju razliite performanse, kao i efikasnost.

Prilikom implementacije algoritama, veina programera pokuava da generie
kd koji zadati algoritam izvrava to je mogue veom brzinom. Iako je brzina
vaan pokazatelj od koga svakako zavise performanse komponente, ipak treba
obratiti panju i na mogue posledice ovog ubrzanja:
x bre izvravanje algoritma moe da prouzrokuje sloeniji kd koji zahteva
vie vremena za generisanje
x sloeniji kd zahteva vie primera za testiranje za koje treba obezbediti
odgovarajue ulazne podatke
x potrebno je vie vremena za tumaenje i razumevanje kda to je on
sloeniji
x budue potencijalne izmene je tee sprovesti ako je kd sloeniji

Imajui u vidu navedeno, pitanje vremena potrebnog za izvravanje algoritma
trebalo bi razmatrati zajedno sa postavljenim zahtevima i kvalitetom uraenog
projekta. Posledica ubrzanja ne sme da bude smanjenje jasnoe i ispravnosti rada
komponente.

Ukoliko je brzina znaajan faktor u implementaciji, potrebno je detaljno
prouiti na koji nain prevodilac za izabrani programski jezik optimizuje kd. Na
taj nain se izbegava situacija da optimizacija koju je programer primenio u cilju
ubrzanja, u stvari uspori naizgled bri kod. Na primer, pretpostavimo da treba
napisati kd koji implementira trodimenzionalni niz. Da bi ubrzao postupak,
programer moe da koristi jednodimenzionalni niz i sm izraunava indeks, tj.
poziciju elementa u trodimenzionalnom nizu. Neka se indeks, na primer, rauna
kao:

indeks = 2*i +4*j + k;

Dakle, u programu se svaka pozicija u trodimenzionalnom nizu rauna
mnoenjem i sabiranjem nekih vrednosti. Meutim, moe se desiti da prevodilac,
da bi skratio vreme, za indeksiranje niza koristi registre, a ne izraunavanja. U tom
sluaju, korienje jednodimenzionalnog niza bi produilo vreme izvrenja, iako je
polazna ideja bila da ga smanji.


6.1.3 Kontrolne strukture

Kontrolne strukture upravljaju tokom izvravanja programa. Veliki broj
kontrolnih struktura je ve predloen u dizajnu sistema. Nezavisno od primenjene
arhitekture, prilikom prevoenja dizajna u programski kd treba ouvati to je
mogue vie kontrolnih struktura, jer je tada lake pratiti usklaenost dizajna i
kda.
Prilikom pisanja kda, preporuljivo je da se koriste one kontrolne strukture
koje omoguavaju lako itanje kda odozgo nadole. To znai da treba izbegavati
velike skokove sa jednog na drugo mesto u programu, praeno obeleavanjem
mesta za povratak, jer se onda uvek postavlja pitanje da li se ide pravom putanjom.
U tumaenju kda, primarno treba da bude ta program radi, a ne sm tok kontrole.

Kontrolne strukture mogu znaajno da utiu na razumljivost programa. Na
primer, neka je dat program:

dobit = d;
if (prihod < 20000) goto A;
dobit = d + 5*nagrada;
goto C;
A: if (prihod < 15000) goto B;
dobit = d + 2*nagrada;
goto C;
B: if (prihod < 10000) goto C;
dobit = d + nagrada;
C: return dobit;

Kao to se vidi, u ovom programu ima mnogo skokova, to ga ini
nepreglednim, pa je teko pratiti njegovo izvravanje. Isti rezultat se moe postii
primenom drugaije strukture toka na sledei nain:

if (prihod < 10000) dobit = d;
elseif (prihod < 15000) dobit = d + nagrada;
elseif (prihod < 20000) dobit = d + 2*nagrada;
else dobit = d + 5*nagrada;

Iako se pri pisanju programa uvek tei da on bude itljiv odozgo nadole, to
nije uvek mogue postii. Na primer, est je sluaj da izlazak iz petlje narui
ovakav poredak. Meutim, kad god je to mogue, korisno je da naredna akcija
bude to blie uslovu koji do nje vodi.
Pri pisanju kda treba voditi rauna o tome da on ne bude previe
specijalizovan i prilagoen konkretnoj primeni, ve da ima optiji karakter. Na
primer, neka je potrebno napraviti komponentu koja ispituje da li se u prvih 10

karaktera nekog teksta pojavljuje *. Ova komponenta moe da se realizuje kao
funkcija iji je jedini argument tekst, a onda se u telu funkcije proverava prvih 10
karaktera i vraa odgovarajua logika vrednost. Meutim, ovako realizovana
funkcija teko da bi mogla da se primeni u bilo kojoj drugoj situaciji. Stoga je bolje
da realizacija navedene funkcije bude optijeg karaktera, tj. da, osim argumenta
koji predstavlja tekst, ima jo dva ulazna parametra: broj karaktera u okviru kojih
se obavlja pretraivanje i sm karakter koji se trai. Ovako realizovana funkcija bi
mogla kasnije da se koristi za pretraivanje delova teksta proizvoljne duine
(zadate argumentom koji predstavlja broj karaktera) i za proizvoljan znak (zadat
argumentom koji predstavlja karakter). Ipak, tenja ka uoptavanju ne sme da
ugrozi performanse komponente ili razumljivost kda.

Kao i u fazi projektovanja, i u fazi implementacije, modularnost predstavlja
poeljnu osobinu. Izgradnjom programa u modularnim blokovima dobija se
razumljiviji sistem koji se lake testira i odrava. Svaka komponenta je odgovorna
za svoj deo posla (koji je skriven za ostatak sistema), dok ostale komponente samo
koriste rezultat njenog rada. Modularne komponente se mogu ponovo iskoristiti u
drugim aplikacijama, a njihove izmene i eventualna prilagoenja su lokalnog
karaktera. Izmeu komponenata treba da postoje dobro definisane veze. Dobra
praksa u pisanju kda je da postoji konzistentnost u imenovanju parametara kojima
se komponente povezuju (izlazni parametar jedne komponente je ulazni parametar
druge komponente). Ovakvim pristupom, zavisnost izmeu komponenata postaje
vidljivija.

6.2 Programska dokumentacija

Pod programskom dokumentacijom podrazumeva se skup opisa u tekstualnoj
formi kojima je objanjeno ta program radi i na koji nain. Postojanje
odgovarajue programske dokumentacije omoguava kasnije korienje,
odravanje ili unapreenje softvera.
Programska dokumentacija obuhvata, uslovno reeno, unutranju i spoljanju
dokumentaciju. Pod unutranom dokumentacijom podrazumevaju se opisi
pridrueni programskom kdu u vidu komentara i oni se nalaze u datotekama sa
programima. Spoljanja dokumentacija sadri sve ostale opise (van datoteka) koji
se odnose na dati sistem.

Programska dokumentacija 121

6.2.1 Unutranja dokumentacija

Unutranja ili interna dokumentacija ima veliki znaaj, ne samo za programera
koji je pisao dati program, ve i za programere koji e ga u budunosti koristiti.
Ona je namenjena svakome ko ita napisani kd, jer sadri informacije koje treba
da pomognu da se kd lake shvati i protumai.
Da bi programski kd bio itljiv, mora, pre svega, da bude jasno i pregledno
napisan. To se postie sistematinim pristupom pisanju koji podrazumeva
uvlaenje redova u zavisnosti od mesta naredbe u hijerarhiji programa. Na primer,
kd koji sledi ne prati navedenu preporuku:

if (prihod < 1000000)
rezultat = 1;
elseif (prihod == 1000000)
if (cena < 50)
rezultat = 2;
else rezultat = 3;
else rezultat = -1;

Kao to se vidi, dati kd nije lak za praenje. Isti kd se moe napisati na
mnogo jasniji i itljiviji nain:

if (prihod < 1000000)
rezultat = 1;
elseif (prihod == 1000000)
if (cena < 50)
rezultat = 2;
else rezultat = 3;
else rezultat = -1;

Dobra praksa je da se na poetku svakog dokumenta sa kdom ispie
komentar u vidu zaglavlja u kojem se opisuje funkcionalnost programskog kda
koji sledi, njegove veze sa okruenjem, oekivani ulazni i izlazni podaci. Zaglavlje
uglavnom sadri sledee informacije:
x ulogu komponente i njeno mesto u sistemu
x naziv komponente
x ime autora komponente
x datum kada je komponenta napisana ili revidirana
x nain na koji se pristupa komponenti


Na poetku zaglavlja bi trebalo ukratko opisati svrhu komponente i eventualno
njeno mesto u sistemu, posmatrano u odnosu na druge komponente. Naziv
komponente mora da bude uoljiv da bi se lake ustanovilo gde se ona poziva u
ostatku sistema. Ime autora ukazuje na to kome se treba obratiti ako ima nekih
pitanja u vezi sa realizacijom date komponente. Komponente se esto auriraju i
revidiraju bilo zbog izmena u zahtevima, ili zbog ispravljanja uoenih greaka.
Bilo bi dobro da u dokumentaciji postoji hronologija izvrenih promena sa
naznaenim vremenima i imenima autora koji su te promene izvrili. Vaan deo
zaglavlja ini objanjenje kako se pristupa komponenti. Ono treba da sadri
informaciju o broju ulaznih i izlaznih parametara, ukljuujui i njihove tipove.
Pogodno je za svaki parametar dati kratak opis koji objanjava njegovu ulogu u
komponenti. Osim ovoga, u duim zaglavljima navode se i ime, tip i svrha svake
vee strukture podataka ili promenljive, kratak opis logikog toka i algoritama,
naini obrade greaka i dr.
Primer uobiajenog zaglavlja sa minimalnim skupom informacija dat je na
slici 6.1.

*****************************************
* Komponenta za sabiranje elemenata niza
* Ime komponente: SUBARR
* Programer: E.Maric
* Verzija: 1.0 (2.februar 2012.)
*
* Poziv procedure: CALL SUBARR(A, R)
* Ulazni parametar: numericki niz A ciji su elementi celi brojevi
* Izlazni prametar: R - zbir elemenata niza A
*
*****************************************

Slika 6.1 Primer zaglavlja

Prednosti pisanja zaglavlja su sledee:
x zaglavlje prua informacije o funkcionalnosti kda koji sledi, to naroito
pomae onima koji odravaju softver
x u situaciji kada se trai gotova komponenta koja bi se ponovo iskoristila,
na osnovu zaglavlja moe se zakljuiti da li kd koji sledi realizuje traenu
komponentu
x u sluaju otkaza, zaglavlje daje dovoljno elemenata za procenu da li je
uzrok otkaza u posmatranom dokumentu ili ne


Nakon zaglavlja, koje predstavlja uvod u program, slede dodatni komentari
koji usmeravaju itaoca u tumaenju programa. Oni mu pomau da shvati kako su
navodi iz zaglavlja implementirani u kdu. Koliina dodatnih komentara zavisi od
procene smog programera. Ukoliko se u programu koriste ilustrativna imena
promenljivih, ako su naredbe jasne i dobro strukturirane, program je sm po sebi
izvor informacija prilikom tumaenja koda. U tom sluaju, broj dodatnih
komentara ne mora da bude veliki. Meutim, komentari imaju svoju ulogu ak i u
dobro napisanom kdu, jer se njima mogu opisati dodatne informacije koje nisu
vidljive iz kda. Na primer, ako kd implementira neki postupak, u komentaru se
moe navesti odakle je taj postupak preuzet:

// Postupak obracunavanja cene je definisan u saradnji sa kupcem.
int obracun(...) {
.
}

Osnovna uloga komentara je da daje korisnu informaciju o delu programskog
kda kome je pridruen. To znai da svaka promena u kdu zahteva auriranje
postojeeg komentara. Pod korisnom informacijom podrazumeva se informacija
koja nije oigledna iz kda, ve daje neko vano objanjenje. Na primer, komentar

// sabrati a sa 1
a = a + 1;

je nepotreban, jer je njegov sadraj oigledan iz kda. Za razliku od ovog,
komentar

// podesiti indeks narednog clana u nizu
a = a + 1;

prua vanu informaciju o tome da se oekuje korienje narednog lana niza.

Dobra praksa je da se komentari piu istovremeno sa kdom, jer e tada u
njima biti najvie korisnih informacija. Naknadno pisanje komentara vodi ka
izostanku nekih bitnih zamisli programera koje je on u meuvremenu zaboravio.
Ukoliko je programeru teko da iskomentarie kd, to je znak da je dizajn previe
sloen i da ga treba uprostiti.

Prilikom pisanja kda, posebnu panju treba posvetiti izboru imena struktura
podataka. Imena treba da opisuju ulogu strukture. Na primer, programski kd

vrednost = cena_proizvoda * kolicina_proizvoda;


je mnogo jasniji od kda

v = c * k;

tako da je za poslednji primer svakako potrebno napisati odgovarajui komentar.

Weinberg (1971.g.) preporuuje da se programski kd i komentari ne meaju,
tj. da se u dokumentu formatiraju tako da se kd nalazi na levom delu stranice, a
komentari na desnom. Na primer, sledei kd je dobro iskomentarisan:

void zamena (int a[], int i, int j) {
int tmp = a[i]; // privremeno cuvanje kolicine proizvoda u i-tom magacinu
a[i] = a[j]; // prebacivanje prozvoda iz j-tog u i-ti magacin
a[j] = tmp; // prebacivanje proizvoda iz i-tog u j-ti magacin
}

6.2.2 Spoljanja dokumentacija

Spoljanja ili eksterna dokumentacija opisuje sistem sa opteg aspekta i daje
odgovore na pitanja ko, ta, kako, zato, kada i gde u sistemu neto radi. Za razliku
od unutranje dokumentacije koja je prvenstveno namenjena programerima,
spoljanja dokumentacija je, osim programerima, namenjena i projektantima. Na
osnovu spoljanje dokumentacije, projektanti mogu da analiziraju sistem i predlau
njegove budue izmene i unapreenja. Spoljanja dokumentacija sadri znatno ire
i detaljnije opise od onih koji se mogu nai u komentarima u programu.
Poto se softverski sistem sastoji od veeg broja meusobno povezanih
komponenata, spoljanja dokumentacija obino sadri sledee:
x pregled svih komponenata u sistemu
x podelu komponenata po grupama, ukoliko ima potrebe za tim (u sloenijim
sistemima mogu se izdvojiti komponente sa slinom funkcijom, na primer,
komponente korisnikog interfejsa, komponente za pristup bazama
podataka, komponente za obradu podataka, ulazno/izlazne komponente,
itd.)
x dijagrame kojima se opisuju pojedinane komponente sa odgovarajuim
tekstualnim objanjenjima
x dijagrame iz kojih se jasno vidi kako se podaci koriste u sistemu, tj. koje
komponente koriste koje podatke, kako ih razmenjuju i modifikuju
x opis klasa objekata i njihovu hijerarhiju nasleivanja (ukoliko se
primenjuje objektno-orijentisani pristup u reavanju problema)

Spoljanja dokumentacija komponente se pie u skladu sa strukturom
komponente koja je ve opisana u dizajnu sistema, uz dodavanje tekstualnih opisa
o pojedinostima iz programskog kda kojim je komponenta realizovana.
Na poetku ove dokumentacije daje se opis problema koji komponenta reava.
Ovaj opis ne podrazumeva ponavljanje ranije postavljenih zahteva, ve
postavljanje nove osnove u smislu kada se komponenta poziva i zato je ona
potrebna. Zatim slede razmatranja razliitih opcija moguih reenja problema, uz
navoenje razloga zbog kojih je konkretno reenje izabrano.
Nakon izbora reenja, sledi opis algoritama koji se koriste u komponenti. U
opisu se navode primenjene formule, postavljeni uslovi i ogranienja, reference na
korienu literaturu, itd. Opisi algoritama su vrlo detaljni i ukljuuju analizu svih
posebnih sluajeva do kojih u algoritmu moe da doe. Svaki sluaj se posebno
razmatra. Opisuje se kako se sluaj obrauje ili, ako se smatra da se neki sluaj
nikada ne moe pojaviti, onda se obrazlae zato je to tako. Na primer, ako se u
nekom algoritmu javlja formula sa deljenjem dve promenljive, u dokumentaciji bi
trebalo navesti u kom sluaju imenilac moe da ima vrednost 0, i kako se u kdu
reaguje na njega.
Spoljanja dokumentacija komponente treba da odslikava tok podataka na
nivou komponente, to se obino predstavlja odgovarajuim dijagramima.

6.3 Kvalitet programiranja

Sve do nedavno se smatralo da e na osnovu dobrog dizajna svaki programer
napisati dobar kd. Meutim, Whittaker i Atkin (2002.g.) istiu da kvalitet
programskog kda u mnogome zavisi i od znanja, vetine, matovitosti i iskustva
programera u reavanju problema.
Smatra se da pronalaenje dobrog reenja zahteva prolazak kroz sledee faze:
x razumevanje problema
x osmiljavanje plana reenja
x izvravanje plana i provera reenja

Razumevanje problema podrazumeva njegovu detaljnu analizu, tj. precizno
utvrivanje uslova u kojima problem mora da se reava. Pre svega, treba ustanoviti
gde je granica sistema u odnosu na okruenje, tj. ta su ulazni podaci (u kom su
obliku i kako se do njih moe doi), a ta izlazni (u kom obliku i kome se oni
isporuuju). Osim toga, moraju se uoiti i sva organienja i uslovi koje sistem treba
da ispuni. Programeri esto koriste grafiki prikaz kako bi bolje razumeli problem.
Crtaju dijagrame tokova koji im pomau u prepoznavanju razliitih uslova koji

moraju da budu ispunjeni. Ovi dijagrami mogu da ukau i na mogunost
dekomponovanja problema na jednostavnije podprobleme koji se lake reavaju.
Sledei korak u pronalaenju reenja je osmiljavanje plana. Plan se moe
relativno lako napraviti ako je problem dobro shvaen i ako je oigledno kako se
postavljeni uslovi mogu ispuniti. Meutim, esto nisu sve veze u sistemu odmah
vidljive, pa se javljaju mnoge nepoznanice. U tom sluaju, da bi se pronaao pravi
plan, preporuuje se isprobavanje sledeih tehnika:
x prepoznavanje slinih problema (ispitivanje da li se ve postojei algoritmi,
biblioteke funkcije, podaci i sl. mogu upotrebiti za reavanje razmatranog
problema)
x preformulisanje problema (ispitivanje da li se mogu uvesti neke
pretpostavke koje bi pojednostavile reenje, ili da li se problem moe
konkretizovati, ili ak uoptiti u istom cilju)
x razlaganje problema (ispitivanje da li se mogu izdvojiti delovi koji bi se
obraivali zasebno jedan od drugog)

Prilikom pravljenja plana, dobro je da se omogui grupna diskusija
zainteresovanih uesnika u projektu, iji bi cilj bio analiziranje moguih opcija i
prepoznavanje najboljeg reenja.
Nakon utvrivanja plana, treba ga sprovesti u delo. To podrazumeva proveru
ispravnosti reenja, korak po korak. Za svaki korak se procenjuje da li se on moe
sprovesti na osnovu prethodnog koraka i da li omoguava postizanje uslova za
izvrenje narednog koraka. Na primer, ako se u koracima pojavljuju neki logiki
iskazi, treba proveriti da li su oni dobro povezani, tj. da li se mogu izvravati jedan
posle drugog. Kada se doe do reenja, ponovo se pregleda svaki deo plana i
analizira da li je reenje viekratno, tj. da li se moe primeniti vie puta, da li je
korisno i u drugim situacijama (i kojim), da li moe da postane osnova za neki
ablon, itd.

U procesu razvoja softvera, nakon faze implementacije, sledi faza testiranja
napisanih programa. Testiranje ima veliki znaaj, jer se nakon ove faze softver
isporuuje naruiocima. Obaveza svakog proizvoaa softvera je da isporui
kvalitetan softver. To je u interesu ne samo krajnjeg korisnika, ve i smog
proizvoaa, jer kvalitet isporuenog softvera direktno utie na ugled proizvoaa
na tritu softvera i mogunosti dobijanja novih poslova u budunosti.
Postoje razliite tehnike testiranja softvera koje obezbeuju da se kupcima
isporui kvalitetan sistem koji zadovoljava njihove zahteve. Cilj testiranja je
otkrivanje greaka u softveru. Meutim, ova faza nije jedina u procesu razvoja koja
se bavi identifikovanjem i ispravljanjem greaka. Skoro u svim fazama koje
prethode testiranju ulau se napori da se smanji broj nedostataka u sistemu. Tako,
potencijalni skup greaka u softveru ukljuuje greke u projektnim zahtevima, u
dizajnu, implementaciji, greke u dokumentaciji, kao i loe ispravke detektovanih
problema u softveru. U svim fazama se tei da se potencijalni problemi uoe kako
bi se to pre prevazili. Dokazano je da otklanjanje nekog nedostatka vie kota to
se on kasnije otkrije.
Iako svaki proizvoa tei da napravi softver bez greaka, to je praktino
nemogue. Programeri mogu da budu izuzetno dobri (imaju znanje i veliko
iskustvo), ali ne mogu da garantuju da e njihov program raditi ispravno svaki put
kada se pokrene i u svim situacijama. Greke se javljaju iz sledeih razloga:
x mnogi softverski sistemi su sloeni, tako da prolaze kroz veliki broj stanja,
koriste zahtevne algoritme, sloene formule i sl. i nije jednostavno
obezbediti ispravan rad sistema u svim situacijama u kojima on moe da se
nae

7 Testiranje softvera

x pri implementaciji sistema esto se koriste alati koji su na raspolaganju
programerima, ili alati koje programeri dobro poznaju, a moda nisu
najpogodniji za realizaciju te vrste sistema
x deava se da ni kupcima, tj. naruiocima nije potpuno jasno ta im je
potrebno, pa samim tim moe da doe do neusklaenosti funkcija
pojedinih delova sistema
x u sloenim projektima uestvuje veliki broj ljudi (projektanata,
programera, onih koji testiraju programe,...), pa su vee mogunosti pojave
meusobnog nerazumevanja

Kao to se vidi, na veinu od navednih razloga programer ne moe da utie, pa
samim tim ne moe ni da bude siguran da e njegov program raditi u svim
moguim uslovima. U svakom sluaju, programer se uvek trudi da dobro sagleda
kontekst problema koji reava i da to pre uoi to vie nedostataka.

7.1 Greke i otkazi

Nedostaci koji se pojavljuju u sistemu manifestuju se kroz greke i otkaze.
Terminoloki posmatrano, ova dva pojma se meusobno razlikuju. Greka
predstavlja uzrok zbog koga je dolo do pojave nekog neeljenog efekta, a otkaz je
sm taj neeljeni efekat. Neeljeni efekat je situacija kada softver ne radi ono to je
predvieno projektnim zahtevima. Moe se rei da je otkaz dogaaj koji ukazuje na
to da u softveru postoji greka, jer je on u stvari posledica, tj. manifestacija te
greke. Na primer, ako je u projektnim zahtevima definisano da sistem treba da
prui neku informaciju samo za to ovlaenom korisniku, a on je prua i
neovlaenim korisnicima, onda je re o otkazu. Ukoliko je do ovakvog ponaanja
sistema dolo zato to neki parametar u softveru nije dobro postavljen, onda je to
greka u programu. Prilikom testiranja, greke se moraju ispraviti, dok je
otklanjanje otkaza poeljno, ali nije uvek u potpunosti izvodljivo. Treba
napomenuti da nije uvek jednostavno otkriti greku (ili greke) koja je
prouzrokovala neki otkaz.

Mnogi otkazi se detektuju tek nakon isporuke sistema. Uzroci otkazivanja
mogu da budu razliiti:
x nepotpuna ili pogrena specifikacija zahteva (na primer, kupac nije
eksplicitno izneo svoj zahtev da u sistemu treba da postoji vie nivoa
ovlaenja)
Greke i otkazi 129

x nemogunost implementacije nekog zahteva na postojeoj hardverskoj ili
softverskoj platformi
x greka pri projektovanju sistema (projekat ne odgovara u potpunosti
postavljenim zahtevima)
x greka u programskom kdu, tj. neodgovarajua implementacija zahteva

Poto razlozi otkaza mogu da budu vrlo raznovrsni i da potiu iz razliitih faza
razvoja, da bi se utvrdilo ta je pravi izvor otkaza, najjednostavnije je poi od
provere ispravnosti napisanog kda. To bi najverovatnije zahtevalo najmanje
izmena u postojeem sistemu.

Mnogi programeri testiranje programa shvataju kao dokazivanje da ti
programi ispravno rade. Meutim, svrha testiranja je upravo obrnuta. Cilj testiranja
je nalaenje greaka u programima, pa se uspenim smatra onaj test tokom koga je
identifikovana neka greka, ili je dolo do nekog otkaza. Ispravno shvatanje uloge
testiranja doprinosi poboljanju kvaliteta softvera, jer u potpunosti angauje
programera u njegovim naporima da pronae greku u softveru.
U sluaju pojave otkaza, problem se prevazilazi tako to se najpre prepozna
greka koja je dovela do otkaza, a zatim se u sistem unesu potrebne izmene koje
otklanjaju tu greku. Pri detekciji greaka mora se voditi rauna o tome da su one
mogle da nastanu kako u softveru, tako i u hardveru. Softverske greke su uvek u
programskom kdu i one su postojane. To znai da one postoje od trenutka kada je
taj deo kda napisan, a postojae i dalje sve dok se taj deo kda ne modifikuje.
Greke u hardveru su drugaije prirode. Naime, hardverske komponente su
podlone habanju, tako da vremenom mogu da promene svoju funkcionalnost i
dovedu do neke vrste otkaza.

7.1.1 Klasifikacija greaka

Nakon implementacije neke programske komponente, programer najpre
pregleda napisani kd kako bi video da li u njemu postoji neka oigledna greka.
Zatim pristupa testiranju komponente, pri emu pokuava da pronae greku tako
to osmiljava, najpre jednostavne, a onda sve sloenije uslove u kojima oekuje da
program ne radi na odgovarajui nain. Pri osmiljavanju uslova, vano je da
programer zna koju vrstu greaka trai.

S obzirom da je broj moguih greaka veoma veliki, pokazalo se korisnim da
se one klasifikuju. Tako se mogu izdvojiti:

x sintaksne greke. Ove greke nastaju zbog pogrene upotrebe iskaza
programskog jezika koji je korien. Na primer, to moe da bude izostanak
zareza na kraju naredbe, pogrean naziv kontrole toka, pokuaj korienja
nepostojeeg tipa podataka, nepotovanje propisane strukture petlje, itd.
Mnoge od ovih greaka prevodioci otkrivaju u toku kompajliranja
programa i o njima obavetavaju programera, navodei vrstu greke i njenu
tanu poziciju u datoteci. Meutim, moe se desiti da je sintaksna greka
takva da samo menja funkcionalnost. Takva greka ne moe biti otkrivena
prevoenjem, a moe da dovede do teih posledica (Mayers je 1976.god.
istakao da je prvi let SAD na Veneru doiveo neuspeh zato to je u jednoj
petlji napisanoj u programskom jeziku Fortran nedostajao zarez).
x greke u postupku obrade. Ove greke nastaju kada nain obrade ulaznih
podataka nije ispravno implementiran. Uobiajene greke ovog tipa su:
prevremeno ili prekasno grananje u programu, ispitivanje pogrenih uslova,
neodgovarajua inicijalizacija promenljivih, pogreno zadati parametri
petlje, izostanak razmatranja nekih sluajeva (na primer, deljenje nulom),
poreenja promenljivih razliitih tipova i sl. Ove greke se mogu otkloniti
detaljnim itanjem programa, ili testiranjem programa za ulazne podatke
izabrane tako da su za njih poznati izlazni podaci koje program treba da
generie. U poslednjem sluaju, programer moe da otkrije greku
praenjem izvravanja programa i poreenjem dobijenih meurezultata sa
oekivanim.
x greke u preciznosti. Ukoliko se u programu koriste formule koje ne mogu
da izraunaju rezultate sa potrebnom preciznou, to moe da dovede do
pogrenog rada programa. Takoe, do neoekivanih rezultata moe da
doe i ako je formula dobra, ali su podaci nad kojima ona operie
neodgovarajueg tipa, pa dolazi do odsecanja i smanjenja preciznosti
izraunatih vrednosti. Ove greke se prevazilaze paljivom proverom
podataka i analizom naina primene formule.
x greke zbog prekoraenja. U mnogim sistemima postoje razna ogranienja
koja se moraju ispotovati. Na primer, moe biti ogranien broj korisnika u
sistemu, intenzitet njihove meusobne komunikacije, propusnost kanala za
prenos podataka, itd. U fazi projektovanja, na osnovu ovih ogranienja,
potrebno je podesiti ponaanje sistema za maksimalno optereenje. To
znai da postavljena ogranienja treba preneti na komponente dizajna. Na
primer, treba odrediti dimenzije nizova, tabela (ukoliko se koriste), veliine
bafera, duine redova ekanja i sl. Ukoliko prilikom izvravanja programa
doe do prepunjavanja struktura podataka predvienih za opsluivanje
ogranienja (na primer, prepuni se bafer), onda dolazi do greaka zbog
prekoraenja.
Greke i otkazi 131

x greke zbog performansi. Ove greke nastaju kada sistem ne postie
performanse koje su predviene projektnim zahtevima. Na primer, sistem
moe da radi neprihvatljivo sporo, posebno u uslovima koji se pribliavaju
postavljenim granicama po pitanju optereenja. Da bi se ove greke
izbegle, programi moraju da budu istestirani u ekstremnim uslovima.
Performanse se svakako moraju proveriti za maksimalno optereenje, a
poeljno je utvrditi (ako konfiguracija sistema to dozvoljava) i ta bi se
desilo ako se sistem optereti i preko maksimuma. Na primer, ako je u
zahtevima specificirano da sistem treba da opsluuje istovremeno 24
korisnika, sistem se mora testirati u uslovima kada je svih 24 korisnika
aktivno. Dobro bi bilo i da se proveri ta bi se desilo kada bi broj korisnika
bio i vei, jer bi to bila korisna informacija za eventualno budue
proirenje sistema.
x greke u dokumentaciji. Programski kd se implementira na osnovu
odgovarajue dokumentacije. Meutim, u nekim situacijama moe da doe
do njihove meusobne neusklaenosti (na primer, ako neka funkcija nije
dobro implementirana). Prilikom traenja greaka, programeri esto
analiziraju dokumentaciju kako bi napravili potrebne izmene u kdu. To
moe da dovede do propagacije postojeih i pojave novih greaka. Ove
greke se mogu prevazii samo ponovnom proverom i usklaivanjem kda
i programske dokumentacije.
x greke u vremenskoj koordinaciji. U sistemima koji rade u realnom
vremenu veoma je vana vremenska koordinacija procesa koji se
izvravaju. U zavisnosti od prirode samih procesa, neki od njih se mogu
izvravati istovremeno, dok se drugi moraju izvravati sukcesivno u tano
zadatom redosledu. U svakom sluaju, deo programskog kda mora da
bude posveen usklaivanju redosleda izvravanja procesa. Ukoliko ovaj
deo kda nije dobro implementiran, pri izvravanju programa se javljaju
greke, koje se obino teko identifikuju i ispravljaju. Problemi u detekciji
ovih greaka nastaju iz dva razloga. Prvo, nije lako predvideti sva mogua
stanja u kojima sistem moe da se nae, a drugo, zbog velikog broja
parametara koji utiu na redosled procesa ponekad nije mogue ponoviti
iste uslove u kojima se greka pojavila, pa se neka detaljnija analiza i ne
moe sprovesti.
x greke zbog nepotovanja standarda. U mnogim kompanijama propisane
su standardne procedure koje se moraju potovati prilikom izrade softvera.
Ukoliko se programer na pridrava ovih procedura, mogu se pojaviti
greke. Ove greke mogu da utiu na rad programa, ali i ne moraju. ak i u
sluaju da ne remete rad programa, ove greke mogu da stvore probleme

onima koji testiraju ili odravaju program ako ne razumeju logiku rada ili u
kdu ne mogu da pronau podatke ili funkcije koje su im potrebne.

Sve navedene vrste greaka direktno su povezane sa programskim kdom i u
nadlenosti su programera. Meutim, postoje i greke koje nisu posledica loe
napisanog kda, ve drugih inioca u sistemu. To su, na primer, greke u hardveru
ili greke u sistemskom softveru. U mnogim sistemima, u okviru specifikacije
zahteva navode se hardverski i softverski resursi koji e biti korieni. Sve
komponente u sistemu projektuju se u skladu sa raspoloivim resursima. Greke
mogu da nastanu ako isporueni hardver ili softver ne funkcioniu kako se to od
njih oekuje. U tom sluaju, treba proveriti u prateoj dokumentaciji da li dati
hardver ili softver uopte mogu da rade u potrebnim operativnim uslovima (ako ne
mogu, onda je greka napravljena prilikom izbora hardvera/softvera), pa ukoliko
mogu, onda se treba obratiti proizvoau kako bi on pomogao u reavanju
problema.

Pri izradi softvera, posebna panja se mora posvetiti oporavku sistema nakon
razliitih vrsta otkaza. Na primer, potrebno je utvrditi ta e se desiti sa sistemom
ako tokom neke obrade nestane napajanje. Razliiti sistemi mogu da se oporave na
razliite naine: neki e nastaviti sa radom uz ukljuivanje sopstvenih strujnih
agregata, drugi mogu da zapamte datoteke pre otkaza, trei za sauvaju skup
poslednjih transakcija koje e biti ponovljene nakon dolaska napajanja, i sl. U
svakom sluaju, nakon otkaza, sistem bi trebalo da se oporavi na prihvatljiv nain.
Ukoliko se to ne obezbedi, nastaju nekontrolisane greke usled otkaza ije
posledice ne mogu uvek da se sagledaju.

7.2 Vrste testiranja

Testiranje sistema je formalni proces koji izvodi tim za testiranje sa ciljem da
utvrdi logiku ispravnost i svrsishodnost testiranog programa. Testiranje se
sprovodi na raunaru uz potovanje odreenih test procedura koje se primenjuju na
odreene test sluajeve. Znaaj testiranja je veliki zato to se na taj nain znaajno
smanjuju gubici koje proizvoai softvera imaju usled greaka i otkaza softvera
nastalih nakon njegove isporuke kupcu. Glavni zadatak svakog lana tima za
testiranje je da otkrije to je mogue vie nedostataka, posebno ozbiljnijih koji
mogu da imaju katastrofalne materijalne, informacione, bezbednosne i druge
posledice. Proces testiranja je skup u dugotrajan i zato svi proizvoai softvera
ulau velike napore da ga uine to efikasnijim.

Mnogi programeri programiranje shvataju vrlo lino, kao odraz njihovog
znanja, inteligencije i mogunosti. Stoga svaku kritiku na raun programa koje su
Vrste testiranja 133

napisali doivljavaju kao kritiku linih sposobnosti, pa im je teko da potisnu lina
oseanja i sujetu. Ovakvi stavovi mogu da ugroze projekat. Da bi se to izbeglo,
mnogi proizvoai softvera (koji imaju mogunosti za to) formiraju specijalne
timove za testiranje. To znai da jedan ovek pie programski kd, a drugi ga
testira. Na ovaj nain se izbegava konflikt izmeu vlastitog oseanja odgovornosti
za greke i potrebe da se pronae to vie greaka u kdu.
Postojanje timova za testiranje prua jo neke prednosti. Prvo, moe se desiti
da programer nesvesno pogreno protumai dizajn, tj. napravi greku u tumaenju
rada komponente ili u postupku implementacije nekog algoritma. Naravno, on ne
bi dao svoj program na testiranje ako bi mislio da on nije u skladu sa datom
specifikacijom. Meutim, poto je previe blizak svom kdu, programer nije u
stanju da bude objektivan i sagleda napravljenu greku. Vea je verovatnoa da e
to uiniti onaj ko testira dati program. Drugo, postojanje timova za testiranje uvodi
paralelizam u radu na projektu, ime se mogu postii znaajne vremenske utede.
Naime, kada programer zavri implementaciju jedne komponente, on je daje na
testiranje, i nastavlja sa radom na sledeoj komponenti. Tako se proces
programiranja i proces testiranja uvek obavljaju paralelno, ime se ne samo tedi
vreme, ve se i ranije uoavaju greke.

Testiranje se sprovodi imajui u vidu dva cilja: verifikaciju i validaciju
sistema. Verifikacija sistema treba da prui odgovor na pitanje da li se sistem
razvija (gradi) na pravi nain, dok validacija treba da odgovori na pitanje da li je
sistem koji se razvija zaista ono to je korisniku potrebno. Da bi se dobili odgovori
na ova pitanja, potrebno je proi kroz sledee faze u procesu testiranja:
x jedinino testiranje (testiranje pojedinanih modula). U ovoj fazi se svaka
programska komponenta testira nezavisno od ostatka sistema. Testiranje se
svodi na proveru funkcionalnosti komponente za unapred definisan skup
ulaznih podataka koji reflektuje sve mogue situacije u kojima komponenta
moe da se nae. Testiranjem se proverava da li se za dati skup ulaznih
podataka dobijaju oekivani rezultati na izlazu ili se izvravaju oekivane
akcije. Ova vrsta testiranja obuhvata i proveru korienih struktura
podataka, logike primenjenih procedura, kao i opsega ulaznih i izlaznih
podataka.
x integraciono testiranje. Poto su pojedinane komponente u sistemu dobro
implementirane, u ovoj fazi se testira saradnja izmeu ovih komponenata.
Proverava se da li su veze izmeu komponenata dobro definisane i
realizovane, tj. da li komponente komuniciraju na nain opisan u projektu
sistema i programa. Rezultat ove faze je kompletan (integrisani) sistem koji
radi.

x sistemsko testiranje (zavrno testiranje). Nakon dobijanja sistema koji radi,
u ovoj fazi se testira da li sistem odgovara zahtevima korisnika. Proverava
se da li sistem izvrava sve funkcije opisane u projektnim zahtevima
specificiranim u saradnji sa kupcem. Takoe se vri i testiranje performansi
sistema da bi se videlo da li su one u skladu sa postavljenim zahtevima po
pitanju hardvera i softvera. Rezultat ove faze je kompletan sistem koji se
moe isporuiti korisniku.

Jedinino testiranje i integraciono testiranje omoguavaju verifikaciju sistema,
dok zavrno, sistemsko testiranje proverava validnost sistema.

Pre nego to se sistem isporui, proizvoa softvera treba da obavi i zavrni
test prihvatanja sistema, u kojem, sada zajedno sa kupcem, proverava usklaenost
sistema sa postavljenim zahtevima. Nakon ovog testa, prihvaeni sistem se instalira
u realnom radnom okruenju i konano, instalacionim testom se proverava da li
sistem i dalje ispravno funkcionie. Na slici 7.1 prikazane su sve faze u procesu
testiranja kroz koje treba proi da bi sistem bio u upotrebi.

Integraciono
testiranje
Jedinino
testiranje
Jedinino
testiranje
kd kd kd
Jedinino
testiranje
Sistemsko
testiranje
Test
prihvatanja
Instalacioni
test
.....
Sistem u
upotrebi

Slika 7.1 Proces testiranja

7.2.1 Jedinino testiranje

Modul predstavlja najmanju programsku celinu koja se testira izolovano od
ostatka sistema. Jedinino testiranje je metod u kome se individualni moduli
programskog kda testiraju kako bi se ustanovilo da li odgovaraju svojoj nameni.

Iako se testiraju izolovano, pojedinani moduli nisu nezavisni od sistema. Njih
pozivaju neki drugi moduli, a i oni sami pozivaju neke module. Prema tome, da bi

se obavilo samostalno testiranje jednog modula, neophodno je razviti odgovarajue
programsko okruenje, kao to je prikazano na slici 7.2.

Rezultati
Test
primeri
Drajver
Modul
Stab 1 Stab 2

Slika 7.2 Okruenje za testiranje modula

Drajver (driver) predstavlja glavni program koji prihvata ulazne podatke iz
test primera, prosleuje ih modulu koji se testira i generie rezultate testa. Dakle,
on simulira komponentu koja poziva modul koji se testira. Stab (stub) je program
koji simulira module koje poziva modul koji se testira. On koristi interfejse
pozivajuih modula, izvrava minimalnu obradu podataka, daje rezultat i vraa
kontrolu modulu koji se testira.

Da bi se pronale greke u nekom programskom modulu, treba uraditi sledee:
x proitati kd sa ciljem pronalaenja oiglednih greaka u sintaksi,
podacima, algoritmima, itd.; pri ovome se moe pogledati i specifikacija
dizajna kako bi se proverilo da li kd uzima u obzir sve relevantne
sluajeve
x prevesti kd pomou prevodioca (kompajlera), ime se uklanjaju preostale
sintaksne greke
x generisati test procedure za test sluajeve kojima se moe proveriti da li se
ulazni podaci pravilno konvertuju u eljene izlazne podatke

Programer pie programski kd na osnovu dizajna, tj. dokumentacije u kojoj
je reima i slikom opisano ta konkretna komponenta treba da radi. To znai da

programski kd predstavlja programerovo tumaenje dizajna. Poto ovo tumaenje
moe da bude i pogreno, dobro je da se formira objektivna grupa koja bi jo
jednom pregledala kd. U njoj bi se, osim autora kda, nalazilo i nekoliko
nezavisnih strunjaka. Grupa bi trebalo da utvrdi da li je kd napisan u skladu sa
dokumentacijom, ili je dolo do nekih nesporazuma, pogrenih tumaenja,
nekonzistentnosti ili drugih propusta.

Pregled kda moe da se obavi na dva naina: letiminim pregledom ili
inspekcijom kda.
Letimini pregled se odvija u nezvaninoj atmosferi. Programer prezentira kd
koji je napisao ostatku grupe i onda dolazi do diskusije. lanovi grupe postavljaju
pitanja, programer na njih odgovara, zajedniki analiziraju pojedine aspekte
realizacije koje smatraju bitnim i pokuavaju da pronau greke. Tokom ovog
pregleda, rasprava je usmerena iskljuivo na kd, a ne na ocenjivanje sposobnosti
njegovog autora.
Inspekcija kda je metod koji je prvi uveo Fagan 1976.godine u IBM-u. Ova
vrsta pregleda odvija se u zvaninoj atmosferi. Grupa za pregled proverava
programski kd i dokumentaciju prema prethodno pripremljenoj listi pitanja.
Pitanja se odnose na razliite aspekte realizacije. Na primer, ona mogu da budu u
vezi sa proverom:
x definicija i naina korienja struktura i tipova podataka u komponenti
x ispravnosti i efikasnosti primenjenih algoritama i drugih izraunavanja
x ispravnosti interfejsa komponente
x korektnosti napisanih komentara, tj. njihove usklaenosti sa kdom
x performansi (brzina obrade, efikasnost korienja memorije i dr.)

Da bi se obavila inspekcija kda, grupa se najpre sastaje da utvrdi ciljeve
inspekcije i grubo pregleda kd. Nakon toga, svaki lan grupe pojedinano
prouava kd i prateu dokumentaciju i pokuava da pronae greke. Na kraju, svi
lanovi grupe se ponovo sastaju i podnose svoje izvetaje o uoenim nedostacima.
Zatim cela grupa analizira pronaene greke i donosi odluku o tome koji nedostaci
predstavljaju greke koje treba ispraviti, a koji ne predstavljaju problem. Svim
sastancima rukovodi voa grupe koji vodi rauna i o tome da se (kao i kod
letiminog pregleda) diskutuje iskljuivo o kdu, a ne o autoru kda.

Istraivanja pokazuju da je inspekcija kda efikasnija od letiminog pregleda
(jer je i detaljnija). Fagan je radio studiju u kojoj su dve grupe pregledale kd
korienjem navedenih metoda. Dobijeno je da je u toku prvih sedam meseci rada
aplikacije 38% manje greaka uoeno kod grupe koja je radila inspekciju kda

nego kod grupe koja je radila letimian pregled. U drugom Faganovom
eksperimentu, od ukupnog broja greaka otkrivenih tokom razvoja sistema, 82% je
pronaeno tokom inspekcije.

Iako autorima kda svakako nije prijatno da neko drugi pregleda njihov kd,
pregledanje kda se pokazalo vrlo korisnim, tako da su ga mnoge kompanije
uvrstile u svoje standardne procedure. Pregled na nivou komponenata olakava
nalaenje greaka, jer su uzroci problema jasniji u ovoj, nego u kasnijim fazama
razvoja. Ispravljanje greka u ranim fazama razvoja je, takoe, mnogo jeftinije
nego u kasnijim.

Nakon to je programer napisao kd koji realizuje neku komponentu, i nakon
to je taj kd pregledala odgovarajua grupa strunjaka i utvrdila da on odgovara
dizajnu, prelazi se na sledei korak u procesu testiranja. To je analiza kda na
sistematian nain, pomou test procedura, kako bi se utvrdila njegova ispravnost.
Kd je ispravan ako implementira funkcionalnost i veze prema drugim
komponentama zahtevane u dizajnu.

U optem sluaju, procesu testiranja modula moe se pristupiti na dva naina:
metodom crne kutije ili metodom bele kutije.

Metodi crne kutije i bele kutije predstavljaju dve krajnosti, jer se u prvom
sluaju nita ne zna o procesu obrade podataka, dok se u drugom sluaju zna sve.
Pri donoenju odluke o nainu testiranja, ne mora se izabrati samo jedan metod.
Metodi se mogu kombinovati u zavisnosti od mogunosti koje postoje u
konkretnom sluaju. Na izbor naina testiranja utie vie faktora:
x priroda ulaznih podataka
x broj moguih logikih putanja koje treba proveriti
x koliina izraunavanja
x sloenost primenjenih algoritama

7.2.1.1 Metod crne kutije

Po metodu crne kutije, program se shvata kao zatvorena (crna) kutija
nepoznatog sadraja kod koje su vidljivi samo ulazi i izlazi. Funkcionalnost
programa se odreuje samo posmatranjem dobijenih izlaznih podataka na osnovu
odgovarajuih, poznatih ulaznih podataka. Prilikom testiranja, na osnovu zadatih
ulaznih podataka, dobijeni izlazni podaci se uporeuju sa unapred oekivanim i na
taj nain se proverava ispravnost programa. Kao to se vidi, u ovom pristupu svi

testovi potiu iz specifikacije programa i ne vri se nikakvo razmatranje
programskog kda.
Prednost metoda crne kutije je u tome to je testiranje osloboeno brige o
ogranienjima koja proistiu iz unutranje strukture komponente i logike njenog
rada. Glavni nedostatak ovog metoda je u tome to je detaljno testiranje svih
kombinacija razliitih ulaznih podataka za veinu programa praktino neizvodljivo.
Ovo vai ak i ako se posmatra ispravnost samo osnovnih elemenata, kao to su
ispravnost unetih vrednosti, vreme unosa, redosled unosa, itd.
Na primer, neka je napisan program koji ima tri ulazna parametra (a, b i c), a
kao rezultat daje dva reenja kvadratne jednaine

ax
2
+ bx + c = 0 ili poruku Nema realnih reenja.

Oigledno je da se ovaj program ne moe testirati proverom svih moguih
vrednosti ulaznih parametara, jer ima beskonano mnogo kombinacija. Zato onaj
ko testira program mora da izabere reprezentativne kombinacije (a, b, c) tako da
moe da dokae da e i ostale mogue kombinacije program pravilno obraditi. U
posmatranom sluaju, kao reprezentativne kombinacije mogu se uzeti sve
kombinacije pozitivnih, negativnih vrednosti i nule za ulazne parametre (ukupno
27 kombinacija). Ili, ako onaj ko testira program bolje poznaje problematiku
problema (a uz to zna i koji problem implementira komponenta), moe uzeti
triplete (a, b, c) tako da je diskriminanta b
2
4ac pozitivna, negativna ili jednaka
nuli. Meutim, i u sluaju da uspeno prou svi testovi nad reprezentativnim
ulaznim podacima, nema garancije da komponenta zaista ne sadri greke. Na
primer, moe se desiti da komponenta nekad da pogrean rezultat zbog greke u
zaokruivanju, ili zbog neusklaenosti tipova podataka i sl.
Mogue su i situacije kada onaj ko testira program nije u stanju da napravi
skup reprezentativnih sluajeva na osnovu koga bi dokazao pravilno funkcionisanje
komponente generalno. To se deava kada je nedovoljno poznat nain obrade koji
se odvija u unutranjosti komponente. Na primer, ako komponenta rauna porez na
prihod, a ulazni podatak je vrednost bruto prihoda koji se oporezuje, teko je
definisati reprezentativne vrednosti zato to nisu poznate poreske kategorije (one su
ugraene u komponentu), pa se ne zna ta treba da se oekuje kao rezultat. Ovaj
problem se moe prevazii metodom bele kutije.

Metod crne kutije je bio osnova za formulisanje vie tehnika funkcionalnog
testiranja, od kojih e tri biti opisane u nastavku:
x podela na klase ekvivalencije
x analiza graninih vrednosti
x uzrono-posledini grafovi

Podela na klase ekvivalencije

Tehnika podele na klase ekvivalencije polazi od ideje da se ulazni podaci
mogu razvrstati u reprezentativne klase tako da se za sve pripadnike jedne klase
program ponaa na slian nain. Te reprezentativne klase su nazvane klasama
ekvivalencije. U idealnom sluaju, klase ekvivalencije su meusobno disjunktne i
pokrivaju ceo prostor vrednosti ulaza.
Testiranje se obavlja samo za jednu reprezentativnu vrednost ulaza iz svake
klase ekvivalencije, zato to se smatra da je to jednako delotvorno kao i testiranje
bilo kojom drugom vrednou iz iste klase. Naime, oekuje se da bi se u svim ovim
sluajevima pronala ista greka u programu.

Klase ekvivalencije se formiraju na osnovu svih uslova iz specifikacije koji se
odnose na ulaze programa. Za svaki uslov se posmatraju dve grupe klasa prema
zadovoljenosti tog uslova:
x legalne klase koje obuhvataju dozvoljene situacije
x nelegalne klase koje obuhvataju sve ostale situacije

Na primer, ako je u specifikaciji naznaeno da ulazni podatak p treba da bude
broj izmeu 0 i 100 (ukljuujui i njih), definiu se:
x jedna legalna klasa ekvivalencije (1 p 100) i
x dve nelegalne klase ekvivalencije (p < 1) i (p > 100).

Ako ulazni podatak p treba da ima fiksnu vrednost 15, definiu se:
x jedna legalna klasa ekvivalencije (p = 15) i
x dve nelegalne klase ekvivalencije (p < 15) i (p > 15).

Ako ulazni podatak p treba da uzme vrednost iz zadatog skupa {a, b, c}, pri
emu se za svaku vrednost iz skupa program razliito ponaa, definiu se:
x tri legalne klase ekvivalencije (p = a), (p = b) i (p = c), i
x jedna nelegalna klasa ekvivalencije (van skupa), na primer (p = d).

Ukoliko se javi sumnja da se program ne ponaa isto za svaki element klase
ekvivalencije, onda tu klasu treba podeliti na vie manjih.

Nakon odreivanja klasa ekvivalencije, formiraju se test primeri za:

x sve legalne klase ekvivalencije (cilj je da se jedan test primer primeni na
to vie legalnih klasa)
x sve nelegalne klase ekvivalencije (za svaku nelegalnu klasu mora se
napisati poseban test primer, kako bi se izbeglo da jedan neregularan ulazni
podatak maskira neki drugi, takoe neregularan, zbog provera unetih u
kd).

Pretpostavimo da razmatranom tehnikom treba testirati deo programa koji
ispituje ispravnost unetog telefonskog broja. Neka je dozvoljeni format broja:

+|00 (nnn) nn nnn nnn

gde n predstavlja numeriki simbol, a | ilioperator. Grupa (nnn) oznaava dravu
i pripada skupu {381}, a grupa nn oznaava telefonskog operatera i pripada skupu
{11,12,13}. Analizom svakog od navedenih uslova, mogu se dobiti legalne i
nelegalne klase ekvivalencije (oznake klasa date su u zagradama) date u tabeli 7.1:

Uslov Legalne klase Nelegalne klase
Poetni simbol (1) +, 00 (8) sve ostalo
Oznaka drave (2) 381 (9) sve ostalo
Broj simbola u oznaci operatera (3) 2 (10) > ili < od 2
Prvi simbol u oznaci operatera (4) 1 (11) sve ostalo
Drugi simbol u oznaci operatera (5) 1,2,3 (12) 1,2,3 ili nenum. simbol
Separatori izmeu grupa simbola
(6)
(13) bilo koji drugi simbol
Br. simb. u poslednje dve grupe (7) 3 (14) 3

Tabela 7.1 Klase ekvivalencije

Na osnovu date tabele, mogu se napraviti sledei test primeri:

+(381) 11 284 667 zadovoljava sve legalne klase, (1) do (7)

(381) 12 224 017 zadovoljava nelegalnu klasu (8)
00(368) 18 284 667 zadovoljava nelegalne klase (9) i (12)
+(381) 111 284 667 zadovoljava nelegalnu klasu (10)
+(381) 11 / 284 / 667 zadovoljava nelegalnu klasu (13)


Analiza graninih vrednosti

U radu sa klasama ekvivalencije esto se deavaju greke zbog neadekvatnog
definisanja njihovih granica. Na primer, programer moe umesto oznake
pogreno da iskoristi oznaku <. Stoga je uvedena analiza graninih vrednosti koja
se primenjuje pri generisanju test primera u cilju potpunije podele opsega ulaznih
podataka.
Analiza graninih vrednosti se radi tako to se test primeri biraju na granicama
razliitih klasa ekvivalencije. Pri tome se vodi rauna, ne samo o ulaznim
uslovima, ve i o izlaznim podacima iz programa.

Majersove preporuke za obavljanje ove analize su:
x ako ulazni uslov predstavlja opseg vrednosti, testove treba napisati za
krajeve opsega i za vrednosti odmah do krajeva; na primer, za ulaz u
opsegu -1.0 do 1.0, treba testirati vrednosti: -1.0, 1.0, -1.0001 i 1.0001
x ako ulazni uslov precizira broj moguih vrednosti, testove treba napisati za
minimalan i maksimalan broj vrednosti i za jedan ispod i jedan iznad broj;
na primer, ako ulazna datoteka moe da sadri 1 do 255 zapisa, treba
napisati testove za 1, 255, 0 i 256 zapisa
x prvu preporuku treba primeniti i na izlazne uslove
x drugu preporuku treba primeniti i na izlazne uslove; na primer, ako na
stranu izvetaja staje 65 redova, treba napisati testove za 64, 65 i 66 redova
x ako je ulaz (ili izlaz) programa ureen skup (neka datoteka, lista, niz), treba
obratiti panju na prvi i poslednji element u skupu
x upotrebiti sopstvene mogunosti za nalaenje drugih graninih uslova koje
bi trebalo testirati

Analiza graninih vrednosti e biti ilustrovana na jednostavnom primeru
pisanja formata datuma u godini koja nije prestupna: dd.mm, gde dd predstavlja
dan, a mm mesec u godini.
Kao to je poznato, za mesece januar, mart, maj, jul, avgust, oktobar i
decembar, dd pripada opsegu 1 do 31, za februar opsegu 1 do 28, a za ostale
mesece opsegu 1 do 30. Slino ovome, mm pripada opsegu 1 do 12. Ovo su legalne
klase u primeru i na osnovu njih mogu se napisati test primeri sa graninim
vrednostima za:

dan 01.04. 30.04. 23.09.

mesec 04.01. 04.12. 24.08.

Nelegalne klase predstavljaju vrednosti van navedenih opsega. Za njih se
mogu napraviti sledei test primeri sa graninim vrednostima za:

dan 00.05. 32.05.

mesec 06.00. 06.13.

Uzrono-posledini grafovi

Testiranje softvera bi bilo znatno olakano ako bi test primeri mogli da se
automatski generiu na osnovu zahteva. Da bi se to postiglo, potrebno je analizirati
zahteve i preformulisati ih u logike relacije izmeu ulaza i izlaza. Rezultat ovoga
moe se predstaviti uzrono-posledinim grafom. Ova tehnika se ne moe
primeniti u sistemima sa vremenskim ogranienjima i sistemima sa konkurentnim
procesima.

Uzrono-posledini graf se konstruie na sledei nain:
x specifikacija se najpre podeli na radne delove (ime se ograniava veliina
grafa)
x zatim se identifikuju uzroci (u vidu ulaznih uslova ili klasa ekvivalencije
ulaznih uslova) i posledice (u vidu izlaznih podataka ili unutranjih
promena stanja sistema)
x analiziranjem znaenja specifikacije, generie se uzrono-posledini graf

Graf se sastoji od vorova koji predstavljaju uzroke, posledice i meuvorove.
Na slici 7.3 dati su primeri elementarnih uzrono-posledinih grafova.

vorovi uzroka se obino crtaju na levoj strani grafa, a vorovi posledica na
desnoj. vorovi su povezani granama u skladu sa relacijama koje postoje izmeu
uzroka i posledica. Zavisno od relacija, mogu se dodavati novi vorovi, tj.
meuvorovi. U granama grafa mogu se definisati zavisnosti tipa AND (), OR
(V) i NOT (~).


A
C
B
V
~
A
C
B
A B
If (A and B) then C If (A or B) then C
If (not A) then B
V

Slika 7.3 Tipovi zavisnosti u uzrono-posledinim grafovima

Da bi se generisao skup test primera, najpre se uzrono-posledini graf mora
transformisati u tabelu odluivanja. Ova tabela predstavlja dvodimenzionalnu
strukturu koja mapira uzroke u posledice.
Tabela odluivanja ima po jednu vrstu za svaki uzrok i posledicu. Po vrstama,
podeljena je u dva dela. U prvom delu se navode uzroci (uslovi), a u drugom
posledice (akcije). U poljima tabele mogu se pojaviti sledee vrednosti: T (true), F
(false) i * (oznaava da sadraj polja nije bitan). Znaenje T i F zavisi od dela
tabele u kome se pojavljuju. U prvom delu tabele:
x T oznaava da uslov mora da bude ispunjen kako bi se postiglo pravilo
x F oznaava da uslov ne sme da bude ispunjen kako bi se postiglo pravilo

U drugom delu tabele, znaenje T i F je sledee:
x T oznaava da e akcija biti izvrena
x F oznaava da akcija nee biti izvrena

Kolone tabele odgovaraju pravilima na osnovu kojih se generiu test primeri.
Broj kolona u tabeli zavisi od broja uzroka, a sadraj kolona se dobija analizom
vorova koji predstavljaju posledice u grafu. Naime, u kolonama se navode sve
kombinacije uzroka koje mogu da izazovu posmatranu posledicu.
Korienjem tabele odluivanja, broj test primera se znaajno smanjuje, to
tedi vreme potrebno za testiranje komponente.

U nastavku je dat primer generisanja skupa testova primenom uzrono-
posledinog grafa. Neka je data funkcija koja obrauje podizanje novca sa rauna.
Funkcija ima tri ulaza (koliina novca koji se podie, tip rauna i trenutno stanje na

raunu) i dva izlaza (novo stanje na raunu i kd akcije). Tip rauna moe biti p
(potanski) i c (klasini). Kd akcije moe da bude D&L (obradi podizanje novca i
poalji pismo), D (obradi podizanje novca), S&L (blokiraj raun i poalji pismo) i L
(poalji pismo). Funkcija radi prema sledeoj specifikaciji:

Ukoliko ima dovoljno novanih sredstava na raunu ili bi novo stanje bilo u
granicama dozvoljenog minusa, podizanje novca se obrauje. Ukoliko bi podizanje
novca dovelo do prekoraenja dozvoljenog minusa, podizanje novca nije mogue. U
tom sluaju, ukoliko je u pitanju potanski raun, vri se njegovo privremeno
blokiranje. Pismo se alje za sve obavljene transakcije u sluaju potanskog rauna,
kao i za klasini raun ukoliko na njemu nema dovoljno novanih sredstava (tj. raun
vie nije u plusu).

Na osnovu specifikacije, mogu se identifikovati sledei uzroci:
U1. Novo stanje je u plusu.
U2. Novo stanje je u dozvoljenom minusu.
U3. Raun je potanski.
Uoene posledice su:
P1. Obrada podizanja novca.
P2. Privremeno blokiranje rauna.
P3. Slanje pisma.

Veze izmeu uzroka i posledica mogu se predstaviti uzrono-posledinim
grafom prikazanim na slici 7.4.

U2
V
V
U1
U3
P2
P1
P3
V

Slika 7.4 Uzrono-posledini graf za primer uzimanja novca sa rauna

Da bi se generisao skup test primera, dati uzrono-posledini graf mora se
transformisati u tabelu odluivanja 7.2.


vorovi 1 2 3 4 5 6 7 8
U1. Novo stanje je u plusu. F F F F T T T T
U2. Novo stanje u dozvoljenom minusu. F F T T F F T T
U3. Raun je potanski. F T F T F T F T
P1. Obrada podizanja novca. F F T T T T * *
P2. Privremeno blokiranje rauna. F T F F F F * *
P3. Slanje pisma. T T T T F T * *

Tabela 7.2 Tabela odluivanja za primer uzimanja novca sa rauna

Kao to se vidi, tabela ima 8 (2
3
) kolona za pravila zato to ima 3 uzroka. U
prvom delu tabele navedene su sve mogue kombinacije za uzroke. Drugi deo
tabele je popunjen na osnovu vrednosti uzroka i logike funkcije. Za pravila 7 i 8
akcije nisu definisane zato to te kombinacije uzroka nisu mogue (novo stanje ne
moe istovremeno da bude i u plusu i u dozvoljenom minusu).
Na osnovu pravila u tabeli odluivanja, mogu se generisati test primeri dati u
tabeli 7.3:

Test
primer
Tip
rauna
Dozvoljeni
minus ()
Trenutno
stanje()
Suma za
podizanje()
Novo
stanje()
Kd
akcije
T1 c 100 -70 50 -70 L
T2 p 1500 420 2000 420 S&L
T3 c 250 650 800 -150 D&L
T4 p 750 -500 200 -700 D&L
T5 c 1000 2100 1200 900 D
T6 p 500 250 150 100 D&L

Tabela 7.3 Tabela odluivanja za primer uzimanja novca sa rauna

Ovi test primeri u potpunosti pokrivaju prostor uzroka-posledica. Poto su
pravila 7 i 8 nemogua, za njih nisu definisani test primeri.

7.2.1.2 Metod bele kutije

Metod bele kutije testira i analizira izvorni programski kd i zahteva dobro
poznavanje programiranja, korienog programskog jezika, kao i dizajna konkretne
programske komponente. U ovom metodu, program se shvata kao otvorena (bela)
kutija ija je unutranjost poznata. Plan testiranja se formira na osnovu strukture
programa. Tako se mogu generisati testovi koji izvravaju sve naredbe u programu,
pozivaju sve funkcije i prolaze kroz sve tokove kontrole unutar komponente. Na
ovaj nain se moe proveriti skoro celokupan kd. Specifinim testovima moe se

proveriti postojanje beskonanih petlji ili izvravanje kda koji u regularnim
uslovima ne bi trebalo nikada da se izvri.
Glavni nedostatak ovog metoda je u tome to i ova vrsta pristupa moe da
bude praktino neizvodljiva. Na primer, ako komponenta sadri mnogo grananja ili
petlji, broj putanja koje treba proveriti moe da bude ogroman (reda milijardi). ak
i u sluaju jednostavnijih logikih struktura, teko je detaljno testirati komponentu
sa velikim brojem iteracija ili rekurzija. U ovim sluajevima, treba usvojti neku
strategiju testiranja u kojoj bi se petlje ili rekurzije izvravale manji broj puta nad
reprezentativnim, paljivo odabranim vrednostima. Strategija moe da se zasniva
na podacima, funkcijama, kontrolnim strukturama ili nekim drugim kriterijumima.

Slino metodu crne kutije, i metod bele kutije je posluio kao osnova za
razvoj vie tehnika strukturnog testiranja. To su:
x pokrivanje iskaza
x pokrivanje odluka
x pokrivanje uslova

Pokrivanje iskaza

Pri testiranju programa, test primeri se prave tako da se svaki iskaz u
programu bar jednom izvri, jer se drugaije ne moe znati da li u njemu postoji
greka. Meutim, ako se iskaz ispravno izvri za jednu ulaznu vrednost, to ne znai
da e se dobro izvriti i za neku drugu ulaznu vrednost. Ovo je glavni nedostatak
razmatrane tehnike.
Pretpostavimo da treba proveriti ispravnost programa koji realizuje Euklidov
algoritam za nalaenje najveeg zajednikog delioca brojeva x i y:

int euklid(int x, int y) {
while (x != y) { // uslov IF-1
if (x > y) then // uslov IF-2
x = x y; // iskaz I1
else
y = y x ; // iskaz I2
}
return x; } // iskaz I3

Pre generisanja test primera, dati algoritam je pogodno predstaviti pomou
dijagrama toka, kao na slici 7.5.


Poetak
Kraj
Ulaz: x,y
IF-1
IF-2
I1 I2
T
T
I3
Izlaz: x

Slika 7.5 Dijagram toka za primer Euklidovog algoritma

Na osnovu dijagrama toka, mogu se napisati test primeri koji pokrivaju sve
iskaze u programu. Na primer, prvi test (T1) pokriva sluaj kada uslov IF-1 nije
ispunjen, pa se izvrava izkaz I3. Na slian nain su formirani i ostali testovi koji
su navedeni u tabeli 7.4:

Test primer x y Pokriveni iskazi
T1 3 3 IF-1, I3
T2 4 3 IF-1, IF-2, I1
T3 3 4 IF-1, IF-2, I2

Tabela 7.4 Test primeri za pokrivanje iskaza

Pokrivanje odluka

Tehnika pokrivanja odluka podrazumeva projektovanje test primera tako da se
svaka od razliitih grana uslovnog iskaza izvri bar jednom. Ovo je jai metod od
pokrivanja iskaza zato to pokrivanje odluka garantuje pokrivanje iskaza.
Odluivanje se vri na osnovu iskaza:

if A then B else C

Ako je uslov A ispunjen, pokrivaju se svi iskazi B koji se nalaze u
odgovarajuoj grani, dok se posebno mora napisati test kada uslov A nije ispunjen,
kako bi se pokrili i iskazi C.
Program koji realizuje Euklidov algoritam moe se testirati i ovom metodom.
Najpre se generie dijagram toka (kao ranije), a zatim se piu test primeri (isti su
kao i kod tehnike pokrivanja iskaza).


Pokrivanje uslova

U tehnici pokrivanja uslova, test primeri se piu tako da svaka elementarna
komponenta nekog sloenog uslova uzima vrednost iz dozvoljenog i
nedozvoljenog skupa vrednosti. Elementarni uslovi se posmatraju potpuno
nezavisno jedan od drugog. Ovaj metod ne garantuje pokrivanje svih odluka, pa
samim tim ni pokrivanje svih iskaza u programu.

Na primer, neka je dat logiki izraz:

(( c1 and c2) or c3)

Test primeri se formiraju tako da u njima c1, c2 i c3 imaju obe logike
vrednosti: tano (T) i netano (F):

T1: c1 = T c2 = T c3 = F
T2: c1 = F c2 = F c3 = T

Postoji i tehnika pokrivanja viestrukih uslova koja podrazumeva pokrivanje
svih moguih kombinacija elementarnih uslova u sloenim izrazima. Na primer,
neka je uslov:

if (c == A || c == B) c = X

Elementarni uslovi su: c == A i c == B. Test primeri sa svim moguim
kombinacijama na ulazu (c) dati su u tabeli 7.5:

Elementarna
komponenta
Test primeri
c = A c = B c = X c = ?
c == A T F F T
c == B F T F T

Tabela 7.5 Test primeri za pokrivanje uslova

Kao to se vidi, ne postoji ulaz za koji bi oba elementarna uslova bila tana.

Ako se sloeni uslov sastoji od n elementarnih komponenata, potrebno je
napisati 2
n
test primera. Ova tehnika je praktino izvodljiva samo za male vrednosti
n.


7.2.2 Integraciono testiranje

Po zavretku testiranja pojedinanih modula, pristupa se njihovom
povezivanju u jednu celinu koja predstavlja sistem namenjen korisniku. Integracija
sistema se radi postepeno, ukljuivanjem komponenata za koje je utvreno da
ispravno rade. To znai da u datom trenutku, posebno kod sloenijih sistema, neke
komponente su u fazi kodiranja, druge u fazi jedininog testiranja, a tree se
povezuju sa drugim komponentama i testiraju kao celina. Pri integraciji sistema
treba potovati usvojenu strategiju. Strategija pokazuje kako i zato se komponente
povezuju i kako se sistem testira. Ona utie na redosled kodiranja i vremenski
raspored ukljuivanja komponenata, a samim tim i na trokove na projektu.
Iako su pojedinane komponente istestirane i potvreno je da ispravno rade, to
nije garancija da e ispravno raditi i u sprezi sa drugim komponentama. Razloga za
to ima mnogo. Najpre, moe se desiti da jedan modul nepovoljno utie na drugi
modul, pa dolazi do gubitka nekih podataka. Osim toga, korienje globalnih
struktura podataka od strane vie modula moe da bude neadekvatno. Nepreciznost
u vrednostima podataka koja je prihvatljiva u jednom modulu, moe da naraste na
naprihvatljivo velike vrednosti u drugom modulu.

Integraciono testiranje se obavlja po planu u okviru koga su definisani testovi
kroz koje prolaze moduli koji su proli jedinino testiranje. Rezultat integracionog
testiranja je integrisani sistem koji je spreman za sistemsko testiranje.

Postoje razliiti pristupi integracionom testiranju:
x integracija po principu velikog praska
x integracija od dna ka vrhu
x integracija od vrha ka dnu
x sendvi integracija

Prvi pristup predstavlja metod nepostupne integracije, dok ostala tri metoda
integriu sistem postupno.

7.2.2.1 Integracija po principu velikog praska

Testiranje po principu velikog praska moe se izvriti u sluaju kada su sve
komponente od kojih se sastoji sistem uspeno prole jedinino testiranje. Ovo
testiranje je pokuaj da se ceo sistem povee u celinu ukljuivanjem svih

komponenata odjednom, a zatim da se isproba da li e sve raditi kako treba. Primer
ovakvog testiranja dat je na slici 7.6.

Testiranje:A
Testiranje: A,B,C,D,E,F
Testiranje:B
Testiranje:C
Testiranje:D
Testiranje:E
Testiranje:F

Slika 7.6 Testiranje po principu velikog praska

Na slici su pojedinane komponente oznaene velikim slovima abecede, a
sistem je dobijen povezivanjem ovih komponenata u jednu celinu.
Primena ovog pristupa testiranju se ne preporuuje iz vie razloga. Najpre,
verovatnoa je izuzetno mala da sistem odmah proradi. Drugo, da bi sve
komponente prole jedinino testiranje, potrebno je napraviti mnogo lanih
procedura. Tree, kada se otkrije greka, poto su sve komponente integrisane
odjednom, vrlo je teko pronai njen uzrok. Poseban problem je to se greke u
vezama izmeu komponenata teko razlikuju od ostalih greaka u sistemu.
Ipak, mnogi programeri koriste ovaj metod kod malih sistema, dok se kod
velikih sistema on praktino ne primenje.

7.2.2.2 Integracija od dna ka vrhu

Integracija od dna ka vrhu je esto korien pristup integracionog testiranja.
Ovaj metod polazi od toga da su komponente sistema organizovane u hijerarhiju na
ijem vrhu se nalazi glavni program. Testiranje otpoinje jedininim testiranjem
svih komponenata koje se nalaze na najniem nivou u hijerarhiji. Zatim se testiraju
komponente na sledeem nivou koje pozivaju prethodno istestirane komponente.
Postupak se ponavlja sve dok kroz njega ne prou sve komponente sistema.
Pretpostavimo da se integraciono testiranje treba izvriti nad sistemom ije su
komponente povezane u hijerarhiju datu na slici 7.7.


A
B C
D E F

Slika 7.7 Primer hijerarhije komponenata

Testiranje od dna ka vrhu poinje testiranjem komponenata na najniem
nivou, tj. D, E i F. Poto njih pozivaju komponente na viem nivou koje jo nisu
proverene, potrebno je napisati poseban programski kd (drajver) kao pomo pri
integraciji. Ovaj kd je obino vrlo jednostavan, ali treba paziti da se u njemu
dobro definie interfejs prema komponenti koja se testira. U datom primeru, kd se
pie za pozivanje komponenata D, E i F. Kada se utvrdi da navedene komponente
ispravno rade, prelazi se na sledei nivo u hijerarhiji. Za razliku od najnieg nivoa,
na ovom nivou, komponente se ne testiraju pojedinano, ve zajedno sa
komponentama koje pozivaju (za koje je ve utvreno da dobro rade). Tako se
zajedno testiraju B, D i E, kao i C i F. Ako se, na primer, pri testiranju C i F pojavi
greka, zna se da ona moe da potie samo od C ili je u interfejsu izmeu C i F. Na
slici 7.8 prikazan je redosled testiranja za dati primer.

Testiranje:D Testiranje:E Testiranje:F
Testiranje:B,D,E
Testiranje:A,B,C,D,E,F
Testiranje:C,F

Slika 7.8 Testiranje od dna ka vrhu

est je sluaj, posebno u sloenijim sistemima, da se komponente na najniem
nivou ne testiraju pojedinano, ve se funkcionalno grupiu u klastere (grozdove)
kao to je prikazano na slici 7.9.


M
M1 M2
G
H I
A B
C
D
E
F
D1 D2 D3
K1 K2 K3

Slika 7.9 Testiranje pomou klastera

Da bi se obavilo testiranje klastera, potrebno je za svaki klaster napisati
odgovarajui drajver, tj. kontrolni program za testiranje. U primeru sa slike,
uvedena su tri klastera: K1, K2 i K3. Drajver D1 slui za testiranje klastera K1
koga ine komponente A, B, C i D. Na slian nain definisani su i drajveri D2 i D3.
Po zavretku testiranja klastera K1, drajver D1 se uklanja i klaster K1 direktno
povezuje sa nadreenim modulom M1. Slino se postupa i sa drajverima D2 i D3.
Na kraju se M1 i M2 integriu sa M.

Testiranje od dna ka vrhu ima svoje nedostatke. Najvei nedostatak je taj to
se komponente najvieg nivoa, koje su obino najvanije, testiraju poslednje.
Naime, komponente na najniem nivou uglavnom realizuju ulazne i izlazne
funkcije ili neka izraunavanja koja se ponavljaju. S druge strane, komponente na
viim nivoima upravljaju glavnim aktivnostima u sistemu. Stoga, mnogi projektanti
smatraju da se ovakvim postupkom testiranja nalaenje znaajnih greka odlae do
zavretka testiranja, to nije dobro, jer greke mogu da nastanu kao posledica loeg
dizajna, pa bi ih trebalo to pre ispraviti.
Integracija od dna ka vrhu se koristi kada veina komponenata na najniem
nivou predstavlja funkcije opte namene koje se pozivaju iz drugih modula, zatim
kod objektno-orijentisanog pristupa, ili kada se u sistemu nalazi vei broj
nezavisnih komponenata sa viekratnom upotrebom.

7.2.2.3 Integracija od vrha ka dnu

Integracija od vrha ka dnu je postupna integracija pri kojoj se polazi od
testiranja glavnog programa koji se nalazi na vrhu hijerarhije komponenti. Zatim se
komponente koje on poziva kombinuju i testiraju kao celina, sve dok se ne
istestiraju sve komponente ukljuujui i one na najniem nivou.
U ovom pristupu, komponenta koja se testira moe da poziva komponentu na
niem nivou koja jo nije proverena. Stoga je potrebno napisati stab, tj. kontrolni
program za testiranje, koji simulira neproverenu komponentu. Stab odgovara na
pozivanje i daje izlazne podatke tako da obezbeuje kontinuitet testiranja.

Komponente se u proces testiranja mogu ukljuivati na dva naina:
x strategijom po dubini
x strategijom po irini

Strategija po dubini podrazumeva da redosled ukljuivanja komponenata u
proces testiranja prati glavnu kontrolnu putanju u strukturi programa. Izbor glavne
putanje je donekle proizvoljan i zavisi od specifikacije softvera.
Strategija po irini u proces testiranja ukljuuje komponente redom po
nivoima, sukcesivno.
Na primer, neka se sistem sastoji od hijerarhije modula kao to je dato na slici
7.10.
M1
M2 M4 M3
M5 M6
M8
M7

Slika 7.10 Primer modularnog sistema

Ovaj sistem se testira strategijom po dubini tako to se najpre proveravaju
moduli u putanji levo, tj. M1, M2 i M5. Zatim se integrie modul M8, ili M6 (radi
ispravnog funkcionisanja M2). Na kraju se integriu moduli na srednjoj (M1, M3 i
M7) i krajnje desno putanji (M1 i M4).


Isti sistem se primenom strategije po irini testira tako to se najpre ispituje
modul M1, a onda M2, M3 i M4. Zatim se integriu moduli na treem nivou, tj.
M5, M6 i M7, i na kraju modul M8.

Integraciono testiranje od vrha ka dnu izvodi se na sledei nain:
x najpre se testira glavni modul sa vrha hijerarhije, pri emu se svi moduli
koje on poziva zamenjuju stabovima
x u zavisnosti od koriene strategije, podreeni stabovi se (nakon uspenog
prolaska kroz testove) u odgovarajuem redosledu zamenjuju stvarnim
komponentama
x postupak se ponavlja dok se u sistem ne integriu sve komponente

Prednost integracije od vrha ka dnu je u tome to se u ranoj fazi testiranja
mogu ispitati kljune funkcije sistema. Svaka funkcija se testira poevi od
najvieg nivoa kontrole, po odgovarajuoj putanji do dna hijerarhije. Problem kod
ovog naina testiranja moe da bude u generisanju velikog broja stabova koji
moraju da podre sve mogue uslove u kojima simulirana komponenta treba da
radi. Zato stabovi mogu u velikoj meri da utiu na ispravnost celog sistema.

7.2.2.4 Sendvi integracija

Sendvi integracija kombinuje dva ranije opisana pristupa integraciji: od
dna ka vrhu i od vrha ka dnu. Po ovom postupku, sistem se organizuje u tri sloja
(slino sendviu). U sredini se nalazi ciljni sloj koji obuhvata komponente izabrane
na osnovu karakteristika i hijerarhije sistema. Gornji sloj sadri komponente koje
se testiraju od vrha ka dnu, a donji sloj komponente koje se testiraju od dna ka
vrhu. To znai da, s obzirom na ovakvu organizaciju, testiranje uvek konvergira ka
srednjem sloju. U donjem sloju se obino nalazi veliki broj pomonih komponenata
opte namene.

Neka je sistem predstavljen hijerarhijom kao na slici 7.11. Sendvi
integracija poinje testiranjem najpre komponente A, a zatim proverom modula E,
F i G. Testiranje gornjeg i donjeg nivoa moe da se radi paralelno. Nakon toga,
testiraju se zajedno A, B, C i D, pa B, E i F, onda D i G i na kraju sve komponente
u sistemu.

Sendvi integracija objedinjuje dobre osobine integracije od vrha ka dnu i
od dna ka vrhu, tako to u ranoj fazi testira i kontrolne komponente i pomone
programe.

A
B C
E F G
D
gornji sloj
srednji sloj
donji sloj

Slika 7.11 Struktura sistema po slojevima

7.2.3 Sistemsko testiranje

Sistemsko testiranje je najvii, zavrni nivo testiranja. Njime se proverava da
li se sistem, kao celina, ponaa u skladu sa specifikacijom zahteva koje je postavio
kupac. Poto je veina funkcionalnih zahteva ve proverena na niim nivoima
testiranja, sada je naglasak na nefunkcionalnim zahtevima, kao to su brzina,
pouzdanost, efikasnost, veze prema drugim aplikacijama i okruenju u kome e se
sistem koristiti.
Testiranje sistema se obavlja u drugaijim uslovima nego kod jedininog ili
integracionog testiranja. Kod jedininog testiranja, pojedinac koji testira imao je
potpunu kontrolu nad procesom. Sm je generisao test primere, pisao test
procedure i vrio testiranje. Prilikom integracije komponenata, postojala je saradnja
sa drugim lanovima tima za testiranje ili tima za razvoj. Kada se testira sistem, u
proces se mora ukljuiti ceo razvojni tim pod kontrolom rukovodioca projekta.
Za razliku od ranije opisanih nivoa testiranja iji je cilj bio da se ispita da li
napisani kd radi ono to od njega oekuju projektanti, kod sistemskog testiranja se
proverava da li sistem radi ono to eli kupac.

Testiranje sistema obuhvata nekoliko koraka:
x funkcionalno testiranje
x testiranje performansi
x testiranje prihvatljivosti
x instalaciono testiranje

Svaki od navedenih koraka ima drugaiju svrhu, kao to je prikazano na slici
7.12.

Funkcionalno
testiranje
Testiranje
performansi
Testiranje
prihvatljivosti
Instalaciono
testiranje
Integrisani
sistem
Sistem u
upotrebi Sistem
funkcionie
Sistem je
verifikovan i
validan
Sistem je
odgovarajui

Slika 7.12 Postupak sistemskog testiranja

Ulaz u proces sistemskog testiranja je integrisani sistem koji je proao
jedinino i integraciono testiranje. U procesu sistemskog testiranja, najpre se
proverava funkcionalnost integrisanog sistema prema zahtevima koje je postavio
kupac. Na primer, ako je softver namenjen analizi investicija, proverava se da li
pravilno obraunava trokove osnovnih i obrtnih sredstava, kredite, trokove
amortizacije i dr. Kada se zavri funkcionalna provera, prelazi se na proveru
nefunkcionalnih zahteva po pitanju performansi. U datom primeru, to moe da
bude ispitivanje brzine izraunavanja, preciznosti dobijenih reenja, preduzetih
mera bezbednosti, vremena odziva, itd. Po zavretku ovog koraka dobija se
verifikovan i validan sistem. Meutim, do sada su u procesu testiranja uestvovali
samo oni koji su razvijali sistem, tako da sistem predstavlja rezultat njihovog
shvatanja problema. Kupci, takoe, testiraju sistem i proveravaju da li on odgovara
njihovom shvatanju zahteva. Ovaj test se naziva testom prihvatljivosti. Test
prihvatljivosti moe da se radi na mestu gde je softver razvijan, ili na krajnjoj
lokaciji gde e raditi. Ukoliko se testira tamo gde je raen razvoj, potrebno je
naknadno uraditi instalacioni test na krajnjoj lokaciji. U svakom sluaju, testiranje
se mora obaviti i u operativnom okruenju (na krajnjoj lokaciji), kako bi korisnici
jo jednom ispitali funkcionisanje sistema i prijavili dodatne probleme, ako se
pojave.

7.2.3.1 Funkcionalno testiranje

Funkcionalno testiranje se izvodi po principu slinom crnoj kutiji. Njime se
proverava da li sistem obavlja neku funkciju, ne vodei rauna o tome koja je
komponenta u sistemu za nju odgovorna. Mnoge funkcije su ve proverene u
ranijim fazama testiranja.
Sistemi obavljaju neki skup funkcija. Kod sloenijih sistema, ovaj skup moe
da sadri veoma veliki broj funkcija. Efikasnost funkcionalnog testiranja u znatnoj
meri zavisi od redosleda u kome se funkcije testiraju. Pri odreivanju redosleda
treba voditi rauna o prirodnoj ugnjedenosti funkcija.


Funkcionalno testiranje obavlja tim nezavisan od projektanata i programera
koji su realizovali sistem. Timu su poznati ulazi i oekivani izlazi ili akcije i on
testira sistem kako za ispravne, tako i za neispravne ulazne podatke. Verovatnoa
otkrivanja greaka kod ove vrste testiranja je velika. Uglavnom se detektuju greke
koje bi korisnik sm otkrio prilikom upotrebe softvera.
Tokom funkcionalnog testiranja nije dozvoljeno da se sistem menja kako bi se
testiranje olakalo. Poto se testira jedna po jedna funkcija, funkcionalno testiranje
moe da pone pre nego to je ceo sistem realizovan.

Test primeri kod funkcionalnog testiranja se prave na osnovu specifikacije
zahteva. Na primer, softver za obradu teksta moe da se testira tako to se
proverava kako obavlja sledee funkcije:
x kreiranje dokumenata
x modifikovanje dokumenata
x brisanje dokumenata

U okviru svake od navedenih funkcija, testira se skup odgovarajuih
podfunkcija. Na primer, modifikovanje dokumenata moe se testirati sledeim
skupom podfunkcija:
x dodavanje/brisanje karaktera
x dodavanje/brisanje rei
x dodavanje/brisanje pasusa
x izmena tipa/veliine fonta, itd.

7.2.3.2 Testiranje performansi

Nakon to se ustanovi da sistem radi prema specificiranim zahtevima
korisnika, prelazi se na testiranje nefunkcionalnih zahteva. Testiranje performansi
se bavi proverom naina na koji se funkcije izvravaju. Performanse sistema se
mere o odnosu na ciljeve koje je postavio kupac. Na primer, ako je jedna
funkcionalnost sistema da izrauna neki statistiki parametar za veliki uzorak
podataka, ispravnost realizacije statistikog metoda se proverava tokom
funkcionalnog testiranja, dok se brzina odgovora, preciznost izlaznog parametra i
slino, porede sa performansama koje je dao kupac.

Testiranje performansi izvrava tim za testiranje koji zatim dobijene rezultate
prezentira kupcu. Ova vrsta testiranja obuhvata sledee vrste testova:

x testovi konfiguracije. Ovim testovima se ispituje ponaanje softvera u
razliitim hardversko/softverskim okruenjima nadevenim u zahtevima.
Postoje sistemi koji imaju ceo spektar konfiguracija namenjenih razliitim
korisnicima. Na primer, moe se definisati minimalna konfiguracija
sistema koja opsluuje pojedinanog korisnika. Ona se dalje moe
nadograivati generisanjem novih konfiguracija za druge vrste korisnika.
Testovi ispituju sve konfiguracije i proveravaju da li one zadovoljavaju
sistemske zahteve.
x testovi optereenja. Ovo su testovi kojima se ocenjuje rad sistema kada se
on optereti do svojih operativnih granica u kratkom vremenskom periodu.
Na primer, ako se zahteva da sistem treba da opslui odreen broj
korisnika ili ureaja, testovi optereenja analiziraju performanse sistema
(najee protok i vreme odziva) kada su istovremeno aktivni svi ti
korisnici ili ureaji. Testovi su posebno vani kod sistema koji uglavnom
rade ispod maksimalnog optereenja, ali u datim trenucima trpe vrlo veliko
optereenje. Ovim testovima se mogu ispitivati i porediti i sistemi sa
razliitim konfiguracijama pri istom optereenju.
x testovi kapaciteta. Ovi testovi proveravaju kako sistem obrauje velike
koliine podataka. To podrazumeva ispitivanje da li su strukture podataka
(nizovi, tabele, liste i sl.) definisane tako da imaju dovoljan kapacitet da
mogu da prihvate podatke u svim moguim situacijama. U istom smislu se
proveravaju i duine polja, zapisa, datoteka, itd. Ovim testovima se,
takoe, ispituje ispravnost rada sistema u sluaju kada skupovi podataka
dostignu svoje maksimalne vrednosti.
x testovi kompatibilnosti. Ovi testovi se koriste kada sistem ostvaruje spregu
sa drugim sistemima iz okruenja. Testovima se proverava da li je
realizacija interfejsa u skladu sa zahtevima. Na primer, ako sistem treba da
pristupa drugom sistemu radi pribavljanja nekog podatka, testovi ispituju
brzinu i preciznost pronalaenja podatka.
x testovi bezbednosti. U nekim sistemima, bezbednost je od velikog znaaja.
Ovi testovi ispituju da li su odreene funkcije dostupne iskljuivo onim
korisnicima kojima su namenjene. Takoe se testiraju i dostupnost,
integritet i poverljivost razliitih vrsta podataka.
x regresivni testovi. Ova vrsta testiranja podrazumeva da se jednom razvijen
test primer primeni vie puta za testiranje istog softvera. To se obino radi
posle neke izmene u softveru, kako bi se proverilo da nije dolo do loeg
rada nekih funkcija koje nisu bile obuhvaene izmenom. Regresivni testovi
se koriste i kada testirani sistem treba da zameni postojei sistem, kao i
prilikom faznog razvoja softvera.

x vremenski testovi. Ovi testovi proveravaju zahteve koji se odnose na
vremena izvrenja pojedinih funkcija i vremena odziva. Obino se rade u
kombinaciji sa testovima optereenja, kako bi se ispitalo da li su
vremenska ogranienja zadovoljena i u ekstremnim uslovima rada, tj. pri
maksimalnom optereenju.
x testovi okruenja. Svrha ovih testova je da analiziraju sposobnost sistema
da radi na lokaciji na kojoj je instaliran. Ako su u zahtevima postavljene
granice tolerancije na temperaturu, vlagu, elektrina i magnetna polja,
prisustvo hemikalija, radioaktivnost i sl., ovim testovima se proverava da
li su te granice ispotovane.
x testovi oporavka. Ovi testovi ispituju kako sistem reaguje na pojavu
greaka u smislu gubitka napajanja, gubitka podataka, ureaja ili usluga.
Ispitivanja se rade tako to se sistem izlae gubitku odreenog resursa, a
zatim se posmatra kako se od toga oporavlja.
x testovi upotrebljivosti. Testovi analiziraju zahteve vezane za interakciju
korisnika sa sistemom. Ocenjuju estetski aspekt aplikacije kroz izgled
ekrana, konzistentnost korisnikog interfejsa, informativnost poruka koje
se daju korisniku, formate izvetaja, itd. Osim ovoga, ispituje se da li
korisnike procedure zadovoljavaju zahteve po pitanju lakoe korienja.
x testiranje dokumentacije. Ovom vrstom testiranja se proverava da li su svi
predvieni dokumenti zaista napisani. To su uglavnom uputstvo za
korisnika, uputstvo za odravanje i tehnika dokumentacija. Osim to se
proverava da li postoje, analizira se i sadraj dokumenata kako bi se
utvrdilo da li su konzistentno i precizno napisani, tj. da li su upotrebljivi.
Ukoliko se u zahtevima precizira format dokumenata, potrebno je proveriti
i da li je on ispotovan.
x testovi odravanja. Ako postoji zahtev da se obezbede logike eme,
dijagnostiki programi, snimci memorije, praenje transakcija i druga
pomagala koja olakavaju nalaenje greaka, potrebno je sprovesti testove
odravanja. Njima se proverava da li ova pomagala postoje i da li ispravno
rade.

7.2.3.3 Testiranje prihvatljivosti

Funkcionalno testiranje i testiranje performansi garantuju da sistem
zadovoljava sve funkcionalne i nefunkcionalne zahteve koji su navedeni u poetnoj
fazi razvoja softvera. Ostaje da se kupac konsultuje za miljenje.

Testiranje prihvatljivosti podrazumeva da se kupcima i korisnicima omogui
da se sami uvere da li napravljeni softver zaista zadovoljava njihove potrebe i
oekivanja. Testove prihvatljivosti piu, izvode i procenjuju korisnici, a uesnici u
razvoju softvera im pruaju pomo oko tehnikih pitanja, ukoliko se to od njih
zahteva.

Kupac moe da proceni sistem na tri naina:
x referentnim testiranjem
x pilot testiranjem
x paralelnim testiranjem

Kod referentnog testiranja, kupac generie tzv. referentne test sluajeve koji
predstavljaju uobiajene uslove u kojima sistem treba da radi kada bude instaliran.
Ove testove izvode obino stvarni korisnici (ili poseban tim) koji su dobro upoznati
sa zahtevima i mogu da procene performanse sistema.
Referentno testiranje se koristi kada kupac ima posebne zahteve. Na primer,
kupac moe da angauje dva razvojna tima za realizaciju softvera prema njegovoj
specifikaciji. Kada sistemi budu gotovi, kupac moe nad njima da sprovede
referentno testiranje. Iako oba sistema moda zadovoljavaju zahteve, referentno
testiranje moe da pokae da je jedan sistem bri ili laki za upotrebu. Rezultati
testiranja pomau kupcu da odabere sistem koji e koristiti.

Pilot testiranje podrazumeva instalaciju sistema na probnoj lokaciji. Zatim
korisnici rade na sistemu kao da je on ve u upotrebi. Kod ove vrste testiranja, ne
prave se posebni test sluajevi, ve se testiranje sprovodi simulacijom
svakodnevnog rada na sistemu. Iako kupac moe da pripremi spisak funkcija koje
bi korisnik trebalo da ukljui u tipian svakodnevni posao, testiranje je ipak manje
zvanino.
Kod sistema koji se isporuuju velikom broju korisnika, pilot testiranje se
obino sprovodi u dve faze. Sistem najpre testiraju korisnici iz organizacije koja je
razvila sistem (alfa test), a zatim pilot testiranje radi stvarni korisnik (beta test). Na
primer, ako je re o novoj verziji nekog operativnog sistema, alfa test se radi u
prostorijama onoga ko je razvio softver, a beta test kod posebno izabrane grupe
kupaca.

Paralelno testiranje se koristi u faznom razvoju, kada jedna verzija softvera
zamenjuje drugu, ili kada novi sistem treba da zameni stari. Ovaj nain testiranja
podrazumeva da paralelno (istovremeno) rade dva sistema (stari i novi). Korisnici
se postepeno privikavaju na novi sistem, ali i dalje koriste i stari. Tako korisnici

mogu da uporede ova dva sistema i provere da li je novi sistem efikasniji i
delotvorniji od starog.

Izbor naina na koji e se obaviti test prihvatljivosti zavisi od konkretnog
sistema i od elja kupca.

7.2.3.4 Instalaciono testiranje

Zavrnu fazu procesa testiranja predstavlja instalaciono testiranje. Ono se
sprovodi instaliranjem softvera na lokaciji na kojoj e se stvarno koristiti.
Instalaciono testiranje otpoinje konfigurisanjem sistema u skladu sa
okruenjem. Zatim se sistem povezuje da potrebnim brojem ureaja iz okruenja i
uspostavlja se komunikacija izmeu njih. Sledi alokacija potrebnih datoteka i
postavljanje kontrole pristupa pojedinim funkcijama sistema.
Instalacioni testovi se rade u saradnji sa korisnicima da bi se utvrdilo ta je
potrebno posebno proveriti na datoj lokaciji. Ispituje se da li uslovi koji postoje na
lokaciji utiu na neke funkcionalne ili nefunkcionalne osobine sistema. Moe se
izvriti i regresiono testiranje kako bi se proverilo da li je sistem ispravno instaliran
i da li i na licu mesta radi ono to je radio prilikom ranijeg testiranja.
Test sluajevi potvruju kupcu da je sistem ispravan i kompletan. Kada kupac
postane zadovoljan rezultatima, testiranje se zavrava i sistem se formalno
isporuuje.

7.3 Proces testiranja

Proces testiranja softvera moe da bude vrlo zahtevan i sloen. Tekoe mogu
da nastanu iz razliitih razloga. One mogu da budu posledica koriene hardverske
ili softverske platforme, ili da potiu iz postupaka implementiranih u samom
sistemu. Posebno teko moe da bude testiranje sloenijih sistema, kao to su
distribuirani sistemi ili sistemi koji rade u realnom vremenu. Kod projekata na
kojima radi veliki broj ljudi, dodatan problem predstavlja koordinacija razvojnog
tima i tima za testiranje. Da bi se tekoe uspeno prevazile, testiranju se mora
pristupiti na sistematian i dobro organizovan nain. Potrebno je definisati
standardizovane propise i procedure naina rada tima za testiranje, kao i ostalih
uesnika u razvoju. Sve aktivnosti tima za testiranje moraju da budu
dokumentovane.


Tim za testiranje moe da ima razliit broj lanova u zavisnosti od sloenosti
projekta. Vei projekti zahtevaju vie ljudi sa dobro definisanim zaduenjima. U
brojnijim timovima za testiranje mogu se izdvojiti sledee uloge:
x menader kvaliteta
x lan tima koji razvija testove
x lan tima koji testira softver
x menader zahteva za izmenama

Menader kvaliteta je odgovoran za planiranje testiranja. On kontrolie proces
testiranja, proverava rokove realizacije i predlae potrebne korekcije. Obezbeuje
neophodan materijal timu za testiranje, formira izvetaje i ostalu neophodnu
dokumentaciju. Takoe informie rukovodstvo projekta o rezultatima rada tima za
testiranje.
lan tima koji razvija testove generie test primere i serije testova. lan tima
koji testira softver izvrava ove testove (kako na nivou pojedinanih modula, tako i
na nivou celog sistema) i alje izvetaje sa prijavljenim grekama i otkazima.
Menader zahteva za izmenama analizira rezultate testova i na osnovu njih
formira zahteve za potrebnim izmenama, dodeljuje im prioritete i planira redosled
njihovog sproveenja po iteracijama.

Proces testiranja softverskog proizvoda sprovodi se kroz sledee aktivnosti:
x izrada plana testiranja
x specifikacija testova
x realizacija testiranja
x evaluacija rezultata testiranja

Navedene aktivnosti ukljuuju eksplicitno zadavanje odgovornosti i zaduenja
po pitanju planiranja testova, njihovog sprovoenja i evaluacije dobijenih rezultata
testiranja. One ukazuju na vrste testova koji e biti primenjeni, njihove ciljeve i
raspored izvrenja testova.

7.3.1 Plan testiranja

Plan testiranja je dokument u kome je opisana organizacija procesa testiranja.
Zahvaljujui njemu, tim za testiranje moe da bude siguran da je sistem istestiran
Proces testiranja 163

sveobuhvatno i na odgovarajui nain. Svaki korak u procesu testiranja mora da
bude dat u planu.
Plan testiranja se pravi na osnovu poznavanja projektnih zahteva, dizajna
sistema i projekta kda. Testiranje prolazi kroz razliite faze poevi od jedininog,
preko integracionog, do sistemskog testiranja.

Za svaku fazu u planu, najpre se navodi cilj. U zavisnosti od ciljeva,
identifikuju se zahtevi za testiranjem koji ukazuju na to ta treba da bude
istestirano. Zahtevi se odnose na funkcije sistema, performanse sistema i
pouzdanost sistema. Zahtevi za testiranje funkcija sistema izvode se iz ranije
utvrenih funkcionalnih zahteva. Dobra praksa je da se za svaki sluaj korienja
generie bar po jedan funkcionalni zahtev. Zahtevi za testiranjem performansi
obino ukljuuju proveru vremena odziva i potronje resursa u razliitim reimima
rada. Zahtevi za pouzdanou se izvode na osnovu nefunkcionalnih zahteva
projektne i implementacione dokumentacije. Na osnovu zahteva, projektuju se test
sluajevi, o emu e biti rei u narednom poglavlju.
Sledea stavka u planu testiranja jeste utvrivanje redosleda testiranja. Da bi
se formirao redosled, potrebno je odrediti prioritete komponenata koje e biti
testirane. U tome moe da pomogne procena rizika. Najrizinije komponente u
pogledu otkaza treba da budu testirane meu prvima. Dalje, to se komponenta
ee koristi, posebno od strane razliitih korisnika, trebalo bi da ima vei prioritet.
Tako se mogu definisati prioriteti komponenata, kao to su H (high) za najvei
prioritet, M (medium) za srednji i L (low) za najnii prioritet. Sada se redosled
testiranja pravi tako to se komponente sa H prioritetom prve testiraju i to
obavezno, zatim bi trebalo testirati komponente sa M prioritetom, dok se
komponente sa L prioritetom mogu testirati, ali tek poto se istestiraju prethodne
dve kategorije.
U planu testiranja, za svaki test treba navesti ta e se njime ispitivati, koji je
kriterijum uspenosti testa, koja osoba e raditi testiranje, kog dana i u koje vreme.
Takoe je potrebno navesti i alate koji e biti korieni za testiranje (na primer,
raunarska konfiguracija Intel Core i5 Quad Core 2.5 GHz, 4 GB RAM, 1333MHz
DDR3, Mac OS X Snow Leopard), kao i standarde i procedure.
Na kraju, treba definisati kriterijume za zavretak testiranja. Oni odreuju u
kom trenutku se neki program moe proglasiti dovoljno dobrim da nisu potrebna
dalja testiranja.

7.3.1.1 Zavretak testiranja

Pitanje zavretka testiranja je vrlo vano, posebno kada se ima u vidu da je
praktino nemogue napraviti softver bez greaka. Odgovori na pitanje kada treba
prestati sa testiranjem mogu da budu razliiti. Trivijalni odgovori, kao to su kada

istekne vreme planirano za testiranje, ili kada se uspeno izvre svi planirani test
primeri, pokazali su se loim. Bolje je kao kriterijum postaviti izabrane metode
testiranja kroz koje sistem mora da proe. Ipak, ni ovo nije dovoljno dobro, jer su
neke metode pogodnije za jedne, a druge metode za druge sisteme.

Efikasniji kriterijum je da se sistem testira dok se ne pronae zadati broj
greaka. Naravno, ovaj broj greaka nije proizvoljan, ve se dobija na osnovu
iskustva, ili iz matematikih modela. Jednu od tehnika za odreivanje broja greaka
u programu razvio je Mills 1972.godine. To je sejanje greaka.

Sejanje greaka je metod koji se izvodi tako to jedan lan tima za testiranje
namerno ubaci (poseje) poznati broj greaka S u program koji se testira. Zatim
ostali lanovi tima za testiranje pokuavaju da pronau to je mogue vie greaka.
Neka su oni otkrili s posejanih greaka. Po ovom metodu, smatra se da je odnos
otkrivenih posejanih greaka prema broju posejanih greaka isti kao i odnos
otkrivenih neposejanih greaka n prema ukupnom broju neposejanih greaka u
programu N, tj. vai:

N = Sn/s

Na primer, ako je u programu posejano 100 greaka, a u testiranju pronaeno
samo 70, na osnovu jednaine sledi da u programu ima oko 30% neotkrivenih
izvornih greaka.

Iako je metod sejanja greaka vrlo jasan i jednostavan, da bi bio koristan,
trebalo bi da posejane greke budu iste vrste i iste sloenosti kao stvarne greke u
programu. Meutim, poto je nemogue znati kakve greke postoje u programu
dok one ne budu pronaene, vrlo je teko posejati reprezentativne greke.
Da bi se poveala verovatnoa da greke budu dovoljno reprezentativne, mogu
se koristiti istorijski podaci o grekama prikupljeni u ranijim slinim projektima.
Ako ovi podaci ne postoje, onda se metod sejanja greaka moe modifikovati
uvoenjem dve nezavisne grupe koje testiraju isti program. Neka je prva grupa
otkrila x, a druga y greaka od moguih n i neka su obe grupe pronale q
zajednikih greaka (q x i q y). Efikasnost grupe se moe shvatiti kao njena
sposobnost da pronae greke iz datog skupa postojeih greaka. U skladu sa ovim,
efikasnosti (E) grupa su

E1 = x/n i E2 = y/n

Ako se uzme da grupe podjednako efikasno pronalaze greke u svakom delu
programa, onda vai i


E1 = x/n = q/y
E2 = y/n = q/x

pa se dobija da je ukupan broj greaka

n = q/(E1E2)

Na primer, ako je prva grupa pronala 25, a druga 30 greaka, s tim to su obe
grupe pronale 15 zajednikih greaka, onda su efikasnosti grupa:

E1 = q/y = 15/30 = 0,5
E2 = q/x = 15/25 = 0,6

pa je ukupan broj greaka n = 15/(0,5*0,6) = 50.

U sluaju da broj pronaenih greaka ne moe da dostigne zadati broj, moe
se primeniti jo jedan efikasan kriterijum, a to je voenje evidencije o pronaenim
grekama u odreenom vremenskom intervalu. Tada se prave dijagrami zavisnosti
izmeu broja pronaenih greaka i broja nedelja. Na slici 7.13 data su dva primera
ovih dijagrama.

vreme
(nedelje)
broj
greaka
1 5 10 1 5 10
10
20
30
10
20
30
broj
greaka
vreme
(nedelje)
a) b)

Slika 7.13 Praenje broja greaka u vremenu

Kao to se vidi, u sluaju pod a) broj greaka se poveava iz nedelje u nedelju,
tako da se testiranje mora nastaviti. Kriva pod b) pokazuje da se nakon 9 nedelja
broj greaka dovoljno smanjio da testiranje moe da bude okonano.

Najbolji rezultati se postiu kombinovanjem svih navedenih kriterijuma,
izuzimajui trivijalne.


7.3.2 Specifikacija testova

Specifikacija testova podrazumeva identifikaciju i opis skupa test primera za
verifikaciju sistema, kao i test procedura koje opisuju nain izvrenja test primera.
Specifikacija se pravi na osnovu projektnih zahteva, modela sistema i projektne
dokumentacije.

Skup testova se formira na osnovu projektnih zahteva. Jedan od naina da se
to uradi jeste da se generie tabela povezanosti testova i zahteva (tabela 7.6). U
vrstama ove tabele nabrajaju se funkcije sistema koje treba da budu predmet
testiranja. U kolonama se navode pojedinani zahtevi.

Test Zahtev 6.1:
Rad sa bazom podataka
Zahtev 6.2:
Dohvatanje podataka
Zahtev 6.3:
Izrada izvetaja
1. Izrada indeksa X
2. Menjanje polja X
3. Brisanje polja X

Tabela 7.6 Tabela povezanosti testova i zahteva

Kao to se vidi, uz svaki zahtev navodi se broj zahteva u dokumentu. Svaka
navedena funkcija povezana je sa onim zahtevom u ijoj koloni se nalazi oznaka X
za tu funkciju.

Data tabela opisuje funkcije sistema koje e biti proverene testovima. Na
slian nain se mogu opisati i testovi performansi, s tim to se tada u tabeli, umesto
funkcionalnih zahteva, navode zahtevi u pogledu brzine pristupa, protoka,
bezbednosti i dr.
esto se jedan test sastoji od nekoliko manjih testova koji svi zajedno treba da
ispune neki zahtev. U ovom sluaju, specifikacija ukazuje na veze manjih testova
sa zahtevom.

Za svaki pojedinani test, pravi se posebna specifikacija. Na poetku
specifikacije navode se zahtevi iju realizaciju test treba da proveri, tj. daje se
svrha testa. Zatim se utvruje skup metoda pogodnih za izvravanje konkretnog
testa. Ukoliko postoje neka ogranienja za primenu ovih metoda (usled realne
situacije u kojoj se vri testiranje), navode se i stvarni uslovi testiranja. Na primer,
uslovi mogu da budu:
x da li se pri testiranju koriste ulazni podaci prispeli iz stvarnog sistema, ili
se oni generiu samo za testiranje

x da li postoje ogranienja za testiranje u smislu vremena, opreme, osoblja i
dr.

Za svaki test se, takoe, daje na koji nain e se proceniti da li je on
kompletan. Navode se kriterijumi na osnovu kojih se zna kad je test zavren i da li
su ispunjeni relevantni zahtevi. Ako je pre procene potrebno na neki nain obraditi
podatke (na primer, svesti veu koliinu podataka na manju, kako bi procena bila
jednostavnija), u specifikaciji se navodi i nain obrade. Na kraju se predlae metod
za procenu. To moe da bude, na primer, da se rezultati testiranja sakupe i runo
urede, a zatim daju na pregled timu za testiranje. Tim moe da koristi i
automatizovane alate za procenu nekih podataka i pregled zbirnih izvetaja, ili da
proverava stavku po stavku i poredi je sa oekivanim rezultatima.

Centralni deo specifikacije je opis testa. Dokument opisa testa treba da bude
napisan na jasan i razumljiv nain, i da sadri dovoljno detalja, tako da bude
koristan pri testiranju. On sadri:
x sredstva kontrole koja e se koristiti pri testiranju
x podatke bitne za testiranje
x procedure koje e se primenjivati pri testiranju

Dokument zapoinje optim opisom testa. Zatim se navode sredstva kontrole
testiranja, u smislu da li e se testiranje pokretati i kontrolisati runo ili automatski
(na primer, da li se ulazni podaci unose preko tastature, ili e se preuzimati iz
nekog programa).
Podaci bitni za testiranje obuhvataju: ulazne podatke, ulazne komande, ulazna
stanja, izlazne podatke, izlazna stanja i poruke koje sistem alje. Svaku vrstu
podataka potrebno je detaljno opisati. Na primer, pri opisu ulaznih komandi treba
objasniti kako se test pokree, zaustavlja, prekida, ponavlja, nastavlja i sl.
Na kraju se opisuju procedure koje treba primeniti u testu. Navode se
vrednosti koje treba uneti, radnje koje treba obaviti, ispravni, tj. oekivani rezultati
ili odzivi (u tekstualnom ili grafikom obliku), kao i opis aktivnosti koje treba
obaviti nakon zavretka testa (na primer, tampanje rezultata, brisanje nekih
podataka, iskljuivanje delova opreme i sl.).

Sledi primer opisa testa za funkciju AVG koja rauna srednju vrednost
elemenata datog niza.

INPUT DATA:
Ulazni podaci se preuzimaju iz programa GEN_NIZ.
Program generie niz od N prirodnih brojeva iz opsega 1 do 100.

Program se poziva sa GEN_NIZ(N) u pokretau testiranja.
Izlaz se smeta u globalnu promenljivu A.
Skup podataka za testiranje:
sluaj 1: Upotrebiti GEN_NIZ sa parametrom N = 100
INPUT COMMANDS:
Program AVG rauna srednju vrednost elemenata niza A.
Program AVG se poziva sa AVG().
OUTPUT DATA:
Rezultat se tampa na ekranu raunara.
SYSTEM MESSAGES:
Dok traje raunanje, na ekranu se ispisuje poruka:
Calculating....
Po zavretku raunanja, na ekranu se ispisuje poruka:
Calculation is completed.
Testiranje se moe prekinuti pre zavrne poruke pristiskom na Ctrl-C na
tastaturi.

7.3.3 Realizacija testiranja

Realizacija testiranja obino polazi od razvoja test skriptova koji odgovaraju
test primerima. Test skriptovi moraju redovno da se auriraju, kako bi uvek bili
konzistentni sa test primerima.
Test skriptovi predstavljaju uputsvo iz koga se jasno vidi kako se korak po
korak izvrava testiranje. Oni obezeuju potpunu kontrolu nad testiranjem, tako da
se, ukoliko doe do nekog otkaza, uslovi testiranja mogu ponoviti i sistem ponovo
dovesti do tog otkaza. To je neophodno da bi se ustanovio uzrok nastalog
problema.
U tabeli 7.7 dat je primer test skripta sa aktivnostima koje treba preduzeti da
bi se tekst napisan u programu Microsoft Word boldovao.

Testiranje rade zadueni pojedinici iz tima za testiranje polazei od
specifikacije testa. Testovi se mogu izvravati runo ili automatski. Tokom
testiranja, dobijeni rezultati se unose u izvetaj koji e kasnije biti analiziran kako
bi se procenila uspenost testa. Izvetaj sa rezultatima testiranja je koristan iz vie
razloga:
x izvetaj dokumentuje rezultate testova
x ukoliko doe do otkaza, izvetaj prua informacije potrebne za ponavljanje
testa, to je vano zbog utvrivanja uzroka otkaza

x izvetaj prua osnovu za stvaranje poverenja u sistem u pogledu
performansi
x izvetaj sadri informacije na osnovu kojih se moe utvrditi da li je razvoj
zavren

Korak Instrukcija Oekivani rezultat Stvarni
rezultat
Komentar
1 Aktivirati aplikaciju MS
Word.
MS Word je
aktivan.
U redu. Za test se koristi
MS Word 2003.
2 Kreirati novi dokument. Prazan dokument je
na ekranu.
U redu.
3 Ispisati tekst This is what
bold text looks like.
Reenica je uneta u
dokument.
U redu.
4 Selektovati re bold. Re bold je
oznaena.
U redu.
5 Pritisnuti Ctrl-B na
tastaturi.
Re bold je
boldovana.
U redu.

Tabela 7.7 Primer test skripta

U okviru izvetaja postoje razliiti obrasci koji sadre podatke relavantne za
pojedine aspekte testiranja. Jedan od njih je obrazac za izvetaj o grekama. U
njemu se navode sve pronaene greke. Svaka greka ima svoj identifikacioni broj
i detaljan opis koji sadri:
x datum identifikovanja greke
x identitet lana tima za testiranje koji je pronaao greku
x datum kada je pronaen i otklonjen uzrok greke
x broj asova potreban za ispravljanje greke (ako postoje drugi problemi
vieg prioriteta, greka ne mora da se ispravlja odmah po otkrivanju)
x cenu otklanjanja greke
x vrstu greke
x identifikator dela sistema, tj. naziv modula ili dokumenta u kome je
pronaena greka
x fazu u razvoju u kojoj je nainjena greka (analiza zahteva, projektovanje,
implementacija, itd.)
x vrsta poruke ili aktivnost koja je dovela do otkrivanja greke
x opis otkaza koji je greka prouzrokovala

x mehanizam koji ukazuje na to kako je izvor greke nastao, kako je otkriven
i ispravljen
x vrstu ljudskog propusta koja je dovela do greke
x ozbiljnost otkaza do koga je dolo ili je moglo da doe

U tabeli 7.8 dat je primer dela izvetaja o grekama koji sadri neke od
navedenih podataka.

Identifikator
greke
Nedelja
prijave
Podruje
greke
Vrsta
greke
Nedelja
reenja
Trajanje
ispravljanja
... ... ... ... ... ...
F256 92/14 C2 P 92/17 4,5
F257 92/15 C5 I 92/16 3
... ... ... ... ... ...

Tabela 7.8 Obrazac za izvetaj o grekama

7.3.4 Evaluacija rezultata testiranja

Nakon svake faze testiranja radi se evaluacija dobijenih rezultata. Sprovedena
testiranja mogu se analizirati i procenjivati na razliite naine.

Jedan od naina je utvrivanje delotvornosti ili uinka testa. Graham je
1996.godine predloio da se uinak testa meri odnosom broja greaka koje su
pronaene u datom testu i ukupnim brojem otkrivenih greaka (ukljuujui i greke
pronaene po zavretku datog testa). Na primer, ako je tokom integracionog
testiranja otkriveno 36 greaka, a ukupan broj naenih greaka je 90, onda je
efikasnost integracionog testiranja 40%. Meutim, ukoliko je do isporuke sistema
naeno 90 greaka, a zatim (nakon isporuke) jo 30 greaka za prva tri meseca
korienja softvera, onda se efikasnost integracionog testiranja smanjuje na 30%,
jer je od moguih 120 greaka u ovoj fazi pronaeno 36. Sa protokom vremena,
uinak datog testa moe samo dalje da se smanjuje.

Opisani nain ocenjivanja testa moe da se pobolja uzimanjem u obzir
injenice da nisu sve greke podjednako ozbiljne. U tom smislu, svakom otkazu se
moe dodeliti stepen ozbiljnosti, koji bi zatim imao udela u raunanju uinka testa.
Uinak testa bi se posebno raunao za razliite stepene ozbiljnosti, pa bi se, na
primer, moglo dobiti da je uinak integracionog testiranja u otkrivanju greaka koje

dovode do kritinih otkaza 30%, a u otkrivanju greaka koje dovode do manjih
otkaza 70%.

Osim uinka, korisno je proceniti i efikasnost neke faze testiranja. Efikasnost
testiranja se odreuje kao odnos broja greaka pronaenih pri testiranju i rada koji
je uloen u to testiranje. Stoga se efikasnost izraava u broju greaka po
ovek/satu. Efikasnost testiranja se koristi za izraunavanje trokova nalaenja
greaka.

U okviru evaluacije, moe se uraditi i analiza pronaenih greaka sa ciljem da
se ukae na este i zajednike greke tima koji razvija softver. Na osnovu ove
analize, mogu se predloiti aktivnosti koje bi poboljale proces razvoja softvera,
kao na primer, pohaanje odreenih kurseva, sticanje naprednijih znanja, promena
alata korienih u razvoju, itd.

Isporuka softvera i njegovo odravanje predstavljaju zavrne faze u procesu
razvoja softvera. One slede nakon faza u kojima je problem identifikovan, reenje
isprojektovano, implementirano i provereno. Poto je softver kompletan, moe se
isporuiti kupcu i pustiti u rad, nakon ega sledi njegovo odravanje.
Isporuka softvera se esto shvata kao formalnost u smislu instaliranja softvera
na radnoj lokaciji, to nije dobra praksa. Ova faza je mnogo sloenija. Od nje zavisi
kako e korisnici prihvatiti sistem i u kojoj meri e njime biti zadovoljni. Cilj
isporuke je, osim instaliranja softvera, da se korisnicima pomogne da u potpunosti
razumeju kako softverski proizvod funkcionie da bi se oseali udobno pri radu u
novom okruenju. Ukoliko isporuci nije posveena dovoljna panja, moe se desiti
da korisnici ne primenjuju softver na najbolji nain, to moe da umanji njihovu
produktivnost i efikasnost.
Nakon isporuke, ivotni vek softvera se nastavlja sve dok je on u upotrebi. U
tom periodu, softver neprestano evoluira kako kroz otklanjanje zaostalih greaka,
tako i kroz razna poboljanja i modifikacije koji su predmet odravanja.

8.1 Isporuka sistema

Tokom razvoja sistema, mora se imati u vidu injenica da je svaki softverski
proizvod pre svega namenjen krajnjem korisniku. Da bi krajnji korisnik mogao
lako i efikasno da upotrebljava sistem, potrebno je ranije isplanirati i razviti
sredstva koja bi mu u tome pomogla. Sredstva koja najvie mogu da doprinesu
boljem i lakem radu korisnika su: obuka za korienje softvera i pratea
dokumentacija.

8 Isporuka i odravanje softvera

8.1.1 Obuka korisnika

Softverski sistemi obino imaju dve vrste korisnika: krajnje korisnike i
operatere (administratore). Krajnji korisnici izvravaju osnovne funkcije sistema u
cilju reavanja problema opisanih u projektnim zahtevima. Operatori izvravaju
pomone funkcije sistema koje slue za podrku osnovnim funkcijama. Na primer,
krajnji korisnici mogu da izvravaju aktivnosti predviene reenjem nekog
problema (ukljuujui razna izraunavanja i algoritme), da unose i analiziraju
podatke, generiu izvetaje, dijagrame i sl. Operateri pruaju administrativnu
podrku u smislu odobravanja prava pristupa pojedinim delovima sistema,
periodinog pravljenja kopija datoteka bitnih za sistem, instaliranja novih ureaja i
softvera, izvravanja aktivnosti za oporavak sistema nakon nekih neregularnih
stanja (nestanka napajanja, nehotinog brisanja delova sistema, itd.). U nekim
situacijama krajnji korisnik i operator mogu da budu ista osoba.
Poto krajnji korisnik i operator imaju razliite zadatke, obuci se pristupa sa
dva aspekta u zavisnosti od toga kome je namenjena.

Obuka krajnjeg korisnika podrazumeva njegovo upoznavanje sa nainom
pokretanja i izvoenja osnovnih funkcija sistema. U tom smislu, korisnik se najpre
upoznaje sa korisnikim interfejsom, rasporedom opcija, izgledima ekrana i
znaenjem pojedinih oznaka na ekranu (na primer, boja, simbola i sl.). Iako se
smatra da krajnji korisnici u dovoljnoj meri poznaju domen i funkcionalnost
sistema, deava se da sistem implementira i neke nove funkcije sa kojima treba
upoznati korisnika. Za krajnjeg korisnika je vano da razume funkcije sistema i da
naui kako da ih koristi. On ne mora da poznaje unutranji rad sistema. Na primer,
korisnik mora da zna da moe da sortira neke podatke po eljenim kriterijumima,
ali ne mora da poznaje algoritme koji su korieni za sortiranje. Takoe, krajnji
korisnik ne mora da bude upoznat ni sa funkcijama podrke koje obezbeuju bolje
performanse sistema. Na primer, za korisnika nije bitno ko, osim njega, trenutno
pristupa sistemu, ili na kom serveru se nalazi deo aplikacije.
U praksi se esto stari sistem zamenjuje novim. U ovim sluajevima, tokom
obuke krajnjeg korisnika, moe da doe do problema u vezi sa prihvatanjem novog
sistema. Naime, korisnici su esto prisiljeni da odbace ono to znaju i na ta su se
ve navikli, pa da prihvate neto novo. Tada se kod njih moe stvoriti odbojnost
prema novom sistemu, koja moe da utie na normalan rad. U ovim situacijama,
mora se korisnicima dati dovoljno vremena da postupno prihvate novi nain rada,
uz davanje objanjenja zato je novi pristup bolji od starog.

Obuka operatera ima za cilj da operater ovlada funkcijama za podrku radu
sistema. Tokom obuke, operater se upoznaje sa organizacijom sistema, a ne sa
funkcijama za reavanje problema iz domena za koji je softver napravljen. To znai
Isporuka sistema 175

da operater ne mora da zna ta sistem radi (domen problema), ve kako radi (nain
funkcionisanja).
Obuka operatera obuhvata dva aspekta: uspostavljanje uslova za normalan rad
sistema i podrku krajnjim korisnicima. Operateri najpre moraju da naue:
x da aktiviraju novi sistem i puste ga u rad
x da konfiguriu sistem, tj. podese zadati skup parametara od kojih zavisi
efikasnost rada sistema
x da administriraju prava pristupa sistemu
x da raspodeljuju resurse korisnicima (zadatke, prostor na disku i sl.)
x da nadgledaju i podeavaju performanse sistema

Operateri, takoe, treba da naue kako da pomognu krajnjim korisnicima u
sluaju pojave nekih neregularnih situacija, kao to su neeljeni gubitak podataka
ili datoteka, otkazi, problemi u komunikaciji, problemi u obraanju drugim
sistemima, itd.

Obuka korisnika se obavlja putem kurseva na kojima se postupno, ali detaljno
polaznici upoznaju sa sistemom. Obuka se moe izvoditi na razliite naine u
zavisnosti od prirode sistema, sposobnosti predavaa ili afiniteta polaznika. U
izvoenju obuke mogu biti od koristi sledea sredstva:
x dokumentacija
x lekcije i demonstracije
x struni korisnici

Da bi bio kompletan, svaki sistem mora da ima prateu formalnu
dokumentaciju. U dokumentima su date sve informacije potrebne za ispravan i
efikasan rad sistema. Iako je dokumentacija prvenstveno namenjena za korienje u
fazi eksploatacije sistema, moe da bude korisna i u fazi obuke. Meutim,
istraivanja su pokazala da samo 10-15% polaznika obuke ita dokumentaciju koja
im se stavi na raspolaganje. Nakon est meseci od obuke, ustanovljeno je da vie
niko ne ita dokumentaciju.
Polaznici obuke znatno ee koriste pomo u elektronskoj formi (Help),
ukoliko im je dostupna na raunaru. Na taj nain tede vreme koje bi potroili na
pretraivanje dokumenata u papirnoj formi.
Istraivanja su pokazala da se obuka znatno pojednostavljuje ukoliko se
korisniki interfejs softvera projektuje tako da funkcije budu razumljive i da im se
lako pristupa. Najpogodniji nain za pristup funkcijama su ikone. One se pamte

lake od opcija u menijima (slika se povezuje sa temom), a jednostavnije se i
pokreu (dvostrukim pristiskom na dugme mia).

Bez obzira na eventualnu elektronsku pomo, polaznici obuke rado sluaju
lekcije i demonstracije koje slue za predstavljanje pojedinih aspekata sistema
putem niza kratkih prezentacija ili predavanja. Lekcije i demonstracije su vrlo
dinamine i fleksibile (iva re), pa su zato zanimljivije od itanja dokumentacije.
Funkcije sistema se najpre objanjavaju u okviru lekcija, a zatim se isprobavaju
putem demonstracija. Efikasnost demonstarcija se poveava ako se one izvode na
raunaru ili na web-u. Neki programi obuke ukljuuju i multimedijalne elemente
(audio i video snimke). Obuka se obino izvodi u raunarskim uionicama, pri
emu svaki polaznik raspolae sopstvenim raunarom. Postoje specijalizovani
softveri koji omoguavaju predavaima da nadgledaju ta svaki od polaznika radi
na svom raunaru, kao i da preuzmu kontrolu nad korisnikim raunarom kako bi
ukazali na niz komandi koje polaznik treba da izvri.
Lekcije i demonstracije su obino vrlo uspene, jer predava odmah dobija
povratne informacije od polaznika, pa moe da im pomogne u prevazilaenju
nastalih problema.

Znaajnu pomo pri obuci mogu da prue i struni korisnici. To su pojedinici
koji su se pre obuke obuili da rade na sistemu, pa na obuci imaju ulogu
demonstratora ili pomonika predavaa. Struni korisnici su obino dobro
prihvaeni od strane korisnika, jer korisnici u njima nalaze sline sebi. Korisnici su
znatno oputeniji u radu sa strunim korisnicima, postavljaju im pitanja, diskutuju
sa njima o problemima, i to je takoe vano, shvataju da je neko drugi ve
savladao rad na sistemu, to im uliva samopouzdanje. Osim ovoga, struni
korisnici mogu da ukau na mesta gde su oni imali najvie problema i kako su te
probleme prevazili.
Struni korisnici najbolje razumeju potrebe korisnika, tako da mogu da daju
najbolje izvetaje o tome koliko su korisnici zadovoljni sistemom, da li ima potrebe
za dodatnom obukom, ta je bilo najtee, a ta najlake u savladavanju naina
funkcionisanja sistema i sl.

Obuka se smatra uspenom ukoliko zadovolji potrebe polaznika. Meutim, i
smi polaznici mogu znatno da se razlikuju. Na primer, mogu da imaju razliita
predznanja, da im odgovaraju razliite metode uenja (itanje, sluanje,
ponavljanje i dr.), da imaju razliite vetine (kucanje na tastaturi, poznavanje
principa rada na raunaru). Stoga bi bilo dobro (ako je mogue) da se obuka u
odreenoj meri prilagodi individualnim polaznicima. To se moe postii podelom
prezentacija u manje celine, tako da korisnici ne bi morali da ue ono to ve znaju.


Iako se tokom obuke polaznici detaljno upoznaju sa celim sistemom, deava
se da neto propuste ili ne shvate. Takoe, ako nakon obuke pri radu ne koriste
pojedine funkcije, vremenom ih zaborave. Na primer, ako operater radi arhiviranje
nekih podataka jednom godinje, moe se desiti da sledee godine zaboravi
proceduru arhiviranja. Ovi problemi se prevazilaze ili ponovnom obukom (moe i
ponavljanjem dela obuke) ili itanjem dokumentacije.

8.1.2 Dokumentacija

Softverski proizvod je u potpunosti zavren tek ako ima prateu
dokumentaciju namenjenu korisnicima. Iz ove dokumentacije, korisnici se mogu
informisati o svim karakteristikama sistema. Dobra dokumentacija, takoe, prua
pomo korisnicima u prevazilaenju neregularnih situacija do kojih moe da doe
u radu sistema.
Za dokumentaciju je vano da bude napisana na jasan, jednostavan i pregledan
nain, da bude konzistentna (usaglaena) i aktuelna (mora u potpunosti da
odgovara sistemu koga dokumentuje). Dobra preglednost se postie uvoenjem
indeksa u vidu kljunih rei uparenih sa brojevima stranica na kojima se kljune
rei nalaze u dokumentima.

Dokumentaciju moe da ini veliki broj dokumenata u zavisnosti od njene
namene i realnih potreba. Pre izrade dokumentacije, treba utvrditi skup potrebnih
dokumenata i kome su oni namenjeni: korisnicima, operaterima, osoblju iz
sistemske podrke, itd. U nastavku je opisano nekoliko vrsta dokumenata koji se u
praksi najee koriste.

Uputstvo za korisnika je dokument namenjen onima koji treba da koriste
sistem, tj. izvravaju njegove funkcije.
Na poetku uputstva za korisnika je naslovna strana (cover page) sa naznakom
o kom dokumentu se radi i strana sa informacijama o autorskim pravima (copyright
page). Nakon toga, sledi predgovor u kome se opisuje svrha uputstva. Ovo je vrlo
bitna informacija, jer se na osnovu nje korisnik uverava da e u dokumentu zaista
nai ono to mu je potrebno. U predgovoru se, takoe, daju i detalji o dokumentima
i informacijama bitnim za korienje uputstva. Radi lake upotrebe, navode se
skraenice, akronimi i specijalni termini koji se koriste u priruniku. Zatim sledi
sadraj dokumenta. Posle sadraja, pristupa se opisivanju sistema. Najpre se u
nekoliko pasusa daje opti pregled sistema navoenjem sledeih stavki:
x namena i ciljevi sistema
x osobine i prednosti sistema

x funkcionalne mogunosti sistema (ukljuujui veze koje postoje izmeu
funkcija)

Radi lakeg razumevanja rada sistema, osim teksta, u opisima se esto koriste
i slike, tabele, dijagrami i druga sredstva. Na primer, struktura sistema na optem
nivou se moe efikasno predstaviti dijagramom u kome su jasno naznaeni ulazni
podaci i njihovi izvori, izlazni podaci i njihova odredita, kao i osnovne funkcije
sistema. Takoe, funkcije sistema se mogu razvrstati po nivoima i prikazati
tabelarno.
Nakon preglednog upoznavanja sa sistemom, sledi predstavljanje pojedinanih
funkcija. Funkcije se opisuju sa stanovita korisnika, tj. tako da korisnik moe da
shvati ta se njima postie i na koji nain. Detalji o tome kako sistem izvrava
funkcije ne navode se u uputstvu za korisnika. To znai, da korisnik treba da naui
ta, ali ne i kako sistem radi.

Opis pojedinane funkcije treba da sadri sledee stavke:
x naziv funkcije
x opis svih ulaznih podataka koje funkcija oekuje
x opis svih izlaznih podataka koje funkcija generie
x redosled opcija koje treba aktivirati tokom izvravanja funkcije
x prikaz ekrana koje korisnik dobija nakon svake aktivirane opcije
x detaljno objanjenje svakog ekrana koje ukljuuje njegovu namenu, svrhu
svakog podatka na njemu, mogue izbore na ekranu i njihove uloge

Funkcije se u uputstvu obino tematski grupiu. Na primer, najpre se opisuju
sve statistike, a zatim sve grafike funkcije.
Vaan aspekt koji treba da bude ukljuen u uputstvo za korisnika je deo koji
se odnosi na ukazivanje na greke do kojih moe da doe u radu sistema i metode
za njihovo prevazilaenje.
Uputstvo za korisnika je veoma vaan dokument, jer od njegove razumljivosti
i sistematinosti u velikoj meri zavisi kako e se korisnik oseati dok upotrebljava
sistem. Ako korisnik teko pronalazi potrebne informacije u priruniku, poee
sm da trai reenja za svoje probleme, to e sigurno imati za posledicu smanjenje
efikasnosti njegovog rada. Zato se uputstvo mora pisati vrlo paljivo, uz korienje
raznih tehnika za poveanje itljivosti i laki pristup informacijama. Korisne
tehnike su: odgovarajua numeracija, primena razliitih boja po temama,
korienje renika, tabela, dijagrama, unakrsno referenciranje i sl. Na primer, ako
treba objasniti funkcije nekih tastera, bolje je tastere prikazati slikom sa pridodatim

tekstualnim objanjenjima i strelicama koje uparuju objanjenje i taster, nego samo
tekstualno opisati raspored tastera i njihove funkcije.

Uputstvo za operatera je tehniki dokument namenjen onima koji treba da
prue podrku radu sistema. Format ovog dokumenta je slian uputstvu za
korisnika, ali mu je sadraj drugaiji. U uputstvu za operatera se ne opisuju
funkcije sistema, ve se navode:
x konfiguracija sistema (kako hardverska, tako i softverska)
x postupci dodeljivanja prava pristupa pojedinim grupama korisnika
x performanse sistema i naini njihovog podeavanja
x postupci arhiviranja podataka od interesa
x procedure prikljuivanja i uklanjanja perifernih ureaja iz sistema i dr.

Uputstvo za operatera poinje isto kao i uputstvo za korisnika. I ono sadri
naslovnu i stranu sa informacijama o autorskim pravima, kao i predgovor i sadraj.
Nakon sadraja, u uputstvu za operatera daje se opti pregled sistema sa stanovita
podrke, a zatim i detaljan opis funkcija za podrku. Praksa pokazuje da je dobro
da donekle postoji preklapanje uputstava za operatera i korisnika, jer to moe da
pomogne operateru da razume da li greka koju je prijavio korisnik moe da bude
otklonjena primenom neke funkcije za podrku, ili je neophodno da o njoj obavesti
osoblje zadueno za odravanje sistema.

Uputstvo za instalaciju je tehniki dokument u kome je detaljno, korak po
korak, opisan postupak instalacije softvera. U njemu se navode i uslovi neophodni
za regularan rad softvera, ukljuujui hardversku i softversku platformu, parametre
sredine, osobine okruenja, itd.

Osim navedenih dokumenata, korisniku se moe isporuiti i opti vodi kroz
sistem u kome se opisuje ta radi sistem, bez detaljnog opisa pojedinanih funkcija.
Na osnovu ovog vodia, kupac treba da bude u stanju da proceni da li sistem u
potpunosti odgovara njegovim potrebama. U vodiu se moe koristiti unakrsno
referenciranje navoenjem referenci na strane korisnikog uputstva na kojima se
moe pronai vie informacija o nekoj funkciji.
Uputstvo za programere je dokument u kome su detaljno opisane programske
komponente i njihov odnos prema funkcijama sistema. Ono pomae programeru da
lake pronae deo programskog kda koji implementira neku funkciju.
Pronalaenje funkcije je esta potreba, bilo zbog pojave nekog otkaza ili izmene i
unapreenja postojee funkcije. Uputstvo za programere, osim funkcija sistema,

sadri i opise funkcija za podrku, to olakava onima koji odravaju sistem da
pronau izvor problema.

Mnogi korisnici, umesto itanja dokumenata u papirnoj formi, vie vole da
sistem upoznaju kroz praktino izvravanje njegovih funkcija. Za njih se mogu
razviti automatizovana uputstva za uenje i pregled sistema. U ovim uputstvima se
kombinovanjem teksta i akcija prikazuju funkcije sistema na ilustrativan nain,
korak po korak.

8.2 Odravanje sistema

Odravanje sistema je aktivnost koja poinje nakon isporuke sistema i traje
sve dok je sistem u upotrebi. Potreba za odravanjem postoji zato to sistem stalno
evoluira. Pod odravanjem se podrazumevaju sve aktivnosti vezane za izmene
sistema dok je on u fazi eksploatacije.
Odravanje softverskog sistema se razlikuje od odravanja ureaja ili
hardverskih reenja. Za razliku od njih, softver nije podloan habanju tokom
vremena, pa stoga ne zahteva periodino odravanje.

Ciljevi odravanja softvera su sledei:
x otklanjanje greaka koje se pojavljuju nakon isporuke softvera
x izvoenje izmena koje su neophodne zbog promena u hardveru, softveru ili
u vezama sa okruenjem
x predlaganje izmena u sluaju kada korisnici imaju problema u korienju
softvera
x praenje rada i predvianje potencijalnih problema u funkcionisanju
sistema
x evidentiranje izmena u poslovanju koje zahtevaju promene u softveru

Odravanje sistema izvodi tim za odravanje koji obino nije isti kao tim koji
je razvijao sistem. Ako razvojni tim zna da e neko drugi odravati njihov sistem,
onda lanovi razvojnog tima mnogo vie panje posveuju standardima
programiranja i izradi dokumentacije. Ponekad se u tim za odravanje ukljui i
neko iz razvojnog tima, to je dobro, jer smanjuje mogue nesuglasice oko
razumevanja naina rada sistema. Tim za odravanje je objektivniji od razvojnog
tima u sagledavanju onoga ta sistem zaista radi u odnosu na ono to bi trebalo da
radi.
Odravanje sistema 181

Odravanje sistema zahteva intenzivnu komunikaciju tima za odravanje sa
korisnicima, kupcima, operaterima i dr. Tim obino dobija od korisnika
informaciju o nastalom problemu. lanovi tima najpre pokuavaju da shvate
problem iskazan jezikom korisnika, a zatim da ga transformiu u zahtev za
izmenom. Zahtev obuhvata opis sadanjeg naina rada, opis naina na koji korisnik
eli da sistem radi i opis izmene koju treba izvriti da bi se sa sadanjeg prelo na
eljeni naina rada. Zatim se pristupa izvravanju izmene kroz modifikovanje
odgovarajueg programskog kda. Ukoliko je to potrebno, na kraju se moe
sprovesti i kraa obuka korisnika koja se odnosi na uvedene izmene.
Aktivnosti koje spadaju u delokrug tima za odravanje su vrlo raznovrsne.
One obuhvataju:
x detaljno upoznavanje sa sistemom kako bi se u potpunosti razumeo nain
njegovog rada
x davanje informacija o radu sistema
x upoznavanje sa dokumentacijom da bi se u njoj brzo i lako pronala
potrebna informacija
x auriranje dokumentacije prema potrebama
x pronalaenje uzroka otkaza i njihovo otklanjanje
x prepoznavanje potencijalnih problema u sistemu i njihovo predupreivanje
x izvoenje potrebnih izmena u sistemu (u dizajnu, kdu, testovima)
x oslobaanje sistema od komponenata koje vie nisu u upotrebi

8.2.1 Vrste odravanja

Proces odravanja se bavi razliitim aspektima evolucije sistema. On obuhvata
odravanje svakodnevnih funkcija sistema, odravanje uvedenih izmena, rad na
poboljanju postojeih funkcija i speavanje degradacije sistema po pitanju
performansi na neprihvatljiv nivo. U tom smislu su se izdvojile razliite vrste
odravanja koje e biti opisane u nastavku.

Korektivno odravanje se bavi kontrolom svakodnevnog rada sistema i
otklanjanjem problema nastalih zbog pojave greaka u softveru. Tim za korektivno
odravanje registruje izvor problema i koriguje greku predlaui potrebne izmene
u zahtevima, dizajnu, implementaciji ili testovima, zavisno od mesta nastanka
greke. Sprovedena ispravka esto ne predstavlja najbolje reenje i privremenog je
karaktera. Njen cilj je da sistem nastavi sa normalnim radom. Trajno reenje

problema moe da zahteva znatno vie vremena, posebno ako se u okviru njega
reavaju i optiji problemi u dizajnu ili programskom kdu. Na primer, ako se neki
troak rauna po algoritmu koji nije implementiran u kdu, a potreban je za dalji
rad sistema, moe se korisniku dati mogunost da ga runo unese. Zatim, tim za
odravanje implementira pomenuti algoritam u okviru kritinog dela kda kako bi
sistem ubudue ispravno radio bez intervencije korisnika.

Adaptivno odravanje se primenjuje u situaciji kada izmena u jednom delu
sistema zahteva izmene u drugim delovima sistema (sekundarne izmene) da bi
sistem ispravno radio. Implementacija sekundarnih izmena predstavlja adaptivno
odravanje. Na primer, pretpostavimo da dati softver komunicira sa drugim
softverom koji treba da bude zamenjen svojom novom verzijom. Ukoliko nova
verzija ima promenjen broj ili znaenje parametara u interfejsu, ova promena se
mora reflektovati i na dati sistem. Adaptivne izmene koje tada treba izvriti ne
odnose se na ispravljanje greaka, ve na dalju evoluciju sistema i njegov
napredak.
Adaptivno odravanje je uglavnom potrebno nakon izmena u hardveru,
softveru ili radnom okruenju. Na primer, ako se sistem planiran da radi u
stabilnom okruenju premesti u novi prostor sa izraenim vibracijama ili bukom,
potrebno ga je prilagoditi novim uslovima.

Odravanje u cilju unapreenja sistema podrazumeva sprovoenje izmena
radi poboljanja nekog dela sistema. Izmene ne moraju da budu posledica greaka,
ve se uvode na predlog tima za odravanje koji stalno preispituje dizajn sistema,
programski kd, primenjene testove i dokumentaciju traei mogua poboljanja.
U ove izmene spadaju, na primer, promene u testovima kako bi oni bili
sveobuhvatniji, ili promene u dokumentaciji radi pojanjenja onih delova teksta
koji nisu dovoljno dobro objanjeni. Izmene mogu da budu i u kdu ili dizajnu. Na
primer, tim za odravanje moe da uoi da zbog prikljuivanja nekog ureaja i
promene naina na koji on alje podatke sistemu (paralelno ili serijski), treba
promeniti strukturu u kojoj se uvaju ti podaci.

Preventivno odravanje predstavlja modifikovanje softvera u cilju detekcije i
korekcije prikrivenih greaka pre nego to se one ispolje. To znai da je cilj
preventivnog odravanja predvianje moguih problema i uvoenje izmena u
softver kako bi se otkazi preduhitrili. U okviru preventivnog odravanja, moe se,
na primer, poboljati mehanizam upravljanja grekama kako bi to vei broj
greaka bio identifikovan i opsluen na odgovarajui nain. To se postie
dodavanjem novih kdova greaka u iskaz koji analizira greke (case ili catch).

Svaka vrsta odravanja zahteva odreeno vreme. Rezultati istraivanja
sprovedenih u cilju utvrivanja koja vrsta odravanja najdue traje, pokazali su da

se najvei rad ulae u odravanje u cilju unapreenja sistema (oko 50% ukupnog
vremena posveenog odravanju), a zatim u adaptivno odravanje (oko 25%).

8.2.2 Problemi odravanja

Odravanje softverskog sistema je teak i sloen proces iz sledeih razloga:
x sistem je ve u eksploataciji
x mogu se javiti personalni i organizacioni problemi
x mogu se javiti tehniki problemi

Sistem koji se odrava je ve u upotrebi. To znai da svako njegovo
modifikovanje mora da se uskladi sa potrebama korisnika. Neki sistemi doputaju
da izvesno vreme ne budu aktivni, jer time ne ugroavaju poslovanje (na primer,
sistem za obraun plata). Meutim, ima sistema ija priroda zahteva permanentnu
dostupnost (na primer, sistem za dovod kiseonika pacijentu). U tim sluajevima,
tim za odravanje mora pronai neko alternativno reenje kojim ne bi ugrozio
korisnika, a mogao bi da sprovede predviene izmene u softveru. Tada se obino
koristi rezervni sistem, a zatim se istestirani deo kda prebacuje u sistem u
upotrebi.

U procesu odravanja, esto su prisutni problemi personalne i organizacione
prirode. Problem razumevanja je jedan od najizraenijih. Jedna analiza je pokazala
da se 47% rada na odravanju softvera troi na razumevanje sistema. Dobro
shvatanje sistema je preduslov za efikasno sprovoenje izmena. I najmanja izmena
(na primer, jednog reda kda) moe da zahteva izvoenje na desetine testova kako
bi se proverio njen uticaj na druge delove sistema.
Poseban problem predstavlja nedovoljno razumevanje naina funkcionisanja
sistema i nedostatak potrebnih vetina od strane korisnika. Deava se da zbog
ovoga korisnici timu daju nepotpune ili ak pogrene podatke u vezi sa nekom
grekom ili otkazom. Ovi problemi se donekle mogu reiti kvalitetnom obukom i
dokumentacijom.
Problemi mogu da nastanu i ukoliko se javi nesklad izmeu prioriteta
rukovodstva i korisnika. Deava se da rukovodstvo, koje je usredsreeno
prvenstveno na poslovanje, zahteva od tima za odravanje este izmene sistema
radi dopune funkcionalnosti. Pri tome, rukovodstvo ne uvia da je sistem ve toliko
izmenjen da bi bilo bolje zameniti ga novim sistemom koji bi korisnicima
omoguio ugodniji i efikasniji rad.
Veliki broj proizvoaa softvera i velika konkurencija na tritu zahtevaju sve
bri razvoj softvera. Za proizvoaa je vano da njegov proizvod to pre izae na

trite, tako da prelazi preko injenice da takav softver nije dovoljno istestiran. Ovo
pravi mnogo problema timu za odravanje, jer se takav proizvod teko razume i
modifikuje.
Veliki znaaj u odravanju ima moral tima za odravanje. Studije pokazuju da
11% problema u odravanju potie od niskog morala, a samim tim i niske
produktivnosti lanova tima. Glavni razlog niskog morala je taj to postoje
predrasude da je posao odravanja drugorazredni u odnosu na posao razvoja.
Pojedinici smatraju da je potrebno vie znanja, kreativnosti i vetine da se sistem
isprojektuje i implementira, nego da se odrava. Meutim, to nije tako. Programeri
iz odravanja se bave mnogim problemima kojih projektanti nisu ni svesni. Na
primer, oni moraju da budu ne samo obueni za pisanje kda, ve i za rad sa
korisnicima, za predvianje potencijalnih problema, preprojektovanje sistema,
izvoenje izmena, itd. Za praenje problema od njegovog izvora, preko predloga
izmena, do njihovog sprovoenja u praksi potrebni su velika vetina, istrajnost i
sistematinost. Problem morala se reava rotiranjem programera iz razvojnog tima
u tim za odravanje i obrnuto. Meutim, tada se deava da jedan programer radi na
vie projekata i poslova, to ga spreava da se u potpunosti posveti jednom
problemu i da ga efikasno rei.

Posebnu grupu problema pri odravanju ine tehniki problemi. Oni nastaju
zbog naina projektovanja i implementacije sistema, kao i zbog izabranih
hardverskih i softverskih platformi korienih u realizaciji.
Ukoliko softver nije dobro i fleksibilno isprojektovan, to stvara velike
probleme timu za odravanje. Tim ne moe lako da shvati strukturu i
funkcionisanje sistema, pa mu je teko da proceni da li predloena izmena moe da
se implementira i na ta bi sve to uticalo. Primer loeg projektovanja je bio
ograniavanje polja za predstavljanje godine na dve cifre, to je prouzrokovalo
probleme u mnogim aplikacijama na prelasku izmeu dva veka.
Problemi mogu da nastanu i kada je softver realizovan na
hardverskoj/softverskoj platformi koja je nepouzdana i podlona otkazima. Osim
toga, ukoliko softver dodeljuje ograniene resurse korisnicma, to moe da pravi
probleme prilikom nekih izmena. Na primer, ako je korisniku dodeljena neka
koliina memorijskog prostora, a izmena je takva da on u taj prostor treba da
smesti veu koliinu podataka, tim za odravanje je taj koji mora da rei problem.
Tim za odravanje moe da ima problema i sa testiranjem izmena. Naime,
moe se desiti da tim nema na raspolaganju odgovarajue ulazne podatke da bi
izmena mogla da bude istestirana na pravi nain. Na primer, ako se izmena odnosi
na uvoenje analize neke snimljene slike, a kamere jo nisu instalirane u okruenju,
onda softver nema realne ulazne podatke, ve ih mora generisati simulacijom.


8.2.3 Trokovi odravanja

Odravanje je poslednja faza u ivotnom veku softvera. Ono obezbeuje da
softver u svakom trenutku bude auran, tj. usklaen sa radnim okruenjem. Nakon
isporuke proizvoda, sve promene u okruenju, kao i u korisnikim zahtevima, kroz
odravanje se implementiraju u softveru, to vodi njegovom modifikovanju i
stalnom unapreivanju.
Proces odravanja u velikoj meri zavisi od prethodnih faza u razvoju softvera,
i zato se tokom celog razvoja softverskog proizvoda mora voditi rauna i o
mogunostima odravanja. U fazi projektovanja, strukturu sistema treba planirati
tako da moe lako da se izmeni. U fazi implementacije, programski kd se pie
tako da bude razumljiv i itljiv i da moe lako da se modifikuje. Ako su ranije faze
dobro uraene, odravanje e biti lake i efikasnije.

Efikasnost odravanja je vaan cilj kome se uvek tei, zato to je u direktnoj
vezi sa trokovima odravanja. Trokovi odravanja ukljuuju potroeno vreme,
uloeni rad i novac. Nekad se deava da trokovi odravanja budu tako veliki da se
postavlja pitanje da li je bolje napraviti novi sistem ili nastaviti sa odravanjem
starog. Van Vliet je 2000.godine uradio studiju koja je pokazala da najmanje 50%
ukupnih trokova u ivotnom veku projekta odlazi na trokove odravanja. Procena
je da e se trokovi odravanja u budunosti poveati i do 80% ukupnih trokova.
Trokovi se razlikuju po vrstama odravanja. Najvei trokovi su kod odravanja u
cilju unapreenja sistema (oko 50% trokova odravanja), zatim adaptivnog (oko
25 %) i korektivnog odravanja (oko 20%), dok na preventivno odravanje odlazi
samo oko 5%.

Karakteristike softverskog proizvoda koje utiu na trokove odravanja su:
x veliina sistema. Vei sistemi se tee odravaju od manjih, zato to je
potrebno znatno vie vremena da se upozna njihov rad u toj meri da bi se
mogle izvesti potrebne modifikacije. Vei sistemi sadre veliki broj
raznovrsnih funkcija, pa je i verovatnoa pojave greaka vea.
x ivotni vek softvera. Stariji sistemi zahtevaju vie napora pri odravanju od
novijih, zato to vremenom sistem raste, postaje loije organizovan zbog
brojnih promena i manje razumljiv (posebno ako je dolo do promena u
timu za odravanje). Ovo je manje uoljivo kod softvera iji je ivotni vek
krai nego kod dugoronih projekata.
x vrsta aplikacije. Neke vrste aplikacija su, zbog svoje prirode, teke za
odravanje. Modifikacija vremenski kritinih aplikacija je sloena, jer
zahteva sinhronizovanje svih komponenata u sistemu koje su u vezi sa

izmenjenom komponentom, bilo direktno ili posredno. Distribuirani
sistemi se, takoe, teko odravaju zbog svoje razuene strukture.
x programski kd. Krai kd se lake odrava. Na primer, manji su trokovi
ako se menja 10% od 200 linija kda u nekom modulu, nego ako se menja
20% od 100 linija kda u drugom modulu, iako se u oba sluaja radi o 20
linija. Programski jezik na kome je sistem implementiran, takoe, utie na
trokove odravanja. Programi pisani na jezicima vieg nivoa se lake
odravaju od programa pisanim na jezicima nieg nivoa.
x strukturiranost sistema. Trokovi odravanja su manji ako je sistem dobro
struktiriran. To znai da su njegove komponente u velikoj meri nezavisne,
ali kompaktne, i sa dobro definisanim vezama prema ostatku sistema. U
tom sluaju, izmena jedne komponente se moe lako kontrolisati, i
uglavnom ne zahteva promene u drugim komponentama.

Martin i McClure su 1983.godine izdvojili faktore koji utiu na smanjenje
trokova odravanja:
x primena strukturiranog projektovanja. Precizno definisana i osmiljena
struktura projekta omoguava bolje razumevanje sistema i lako praenje
izmena i njihovih posledica.
x primena savremenih softverskih tehnika. Pogodnosti koje nude savremene
softverske tehnike treba u to veoj meri ukljuivati u sistem kako bi
njegov rad bio fleksibilniji i efikasniji.
x korienje automatskih alata. Automatski alati, s jedne strane, ubrzavaju
rad, a sa druge stane, smanjuju mogunost greke usled ljudskog faktora.
Zato ih treba koristiti u svim fazama razvoja gde je to pogodno (pri
implementaciji, testiranju, itd.)
x iskusan tim za odravanje. Trokovi odravanja su manji ako je tim za
odravanje dobro organizovan i ako njegovi lanovi ve imaju iskustva u
slinim poslovima.

U razvoju softvera primenjuju se razliiti postupci, tehnike, metode i alati da
bi se postigao postavljeni cilj, tj. dobilo softversko reenje zadatog problema.
Donoenje brojnih odluka predstavlja sastavni deo procesa razvoja. Odluivanje je
prisutno pri izboru tehnika razvoja, izboru alata, resursa, itd. Pri donoenju odluke,
uvek se moe postaviti pitanje da li je jedna tehnika bolja od druge, da li je
efikasniji jedan ili drugi metod, i sl.
Nakon zavretka softverskog proizvoda, potrebno je proceniti njegov kvalitet.
On se procenjuje sa razliith aspekata, koji ukljuuju ne samo proizvod, ve i
proces njegovog razvoja (ispravnost donetih odluka), njegovu primenu, koriene
resurse, i dr. Procenom kvaliteta se utvruje ispunjenost postavljenih funkcionalnih
zahteva, stepen produktivnosti, performanse sistema i druge nefunkcionalne
osobine.
U narednim poglavljima, opisani su mogui pogledi na kvalitet softvera i
odabrani modeli kvaliteta.

9.1 Pogledi na kvalitet softvera

Procena kvaliteta softverskog proizvoda zavisi od konteksta u kome se
proizvod posmatra. Isti nedostatak se ne moe tretirati na isti nain u svakom
softveru. Na primer, nedostatak u softveru za obradu teksta nema isti znaaj, a ni
posledice, kao kada se pojavi u softveru namenjenom zatiti podataka, gde moe da
ugrozi ceo sistem.
U zavisnosti od gledita, kvalitet softvera se moe posmatrati na tri naina:
kroz kvalitet proizvoda, kvalitet postupka izrade proizvoda i kvalitet sa stanovita
poslovnog okruenja u kome se softver koristi.

9 Kvalitet softvera
188 Kvalitet softvera

9.1.1 Kvalitet proizvoda

Procena kvaliteta proizvoda podrazumeva utvrivanje da li je softver
kvalitetan ili nije na osnovu njegovih karakteristika. Meutim, ako bi se isti softver
dao veem broju osoba da procene njegov kvalitet, one bi pri tome verovatno
razmatrale razliite karakteristike. To je tako zato to svako posmatra softver sa
svog stanovita.
Za korisnika, softver je kvalitetan ako ima potrebnu funkcionalnost,
jednostavnu obuku i lako se koristi. Moe se rei da korisnik posmatra softver
spolja, tj. sa aspekta upotrebe. Kada meri kvalitet softvera, korisnik procenjuje
broj otkaza, kao i vrste otkaza. esto otkaze klasifikuje u minorne, glavne i otkaze
sa katastrofalnim posledicama. to je vei broj katastrofalnih i glavnih otkaza,
softver je nekvalitetniji.
Softver procenjuju i projektanti i drugi uesnici u razvoju, posebno tim za
odravanje koji treba da nastavi sa radom na softveru. Oni obino analiziraju
interne karakteristike softverskog proizvoda, tj. posmatraju softver iznutra. To
podrazumeva procenu nedostataka u zahtevima, u projektu, u programskom kdu,
itd. Uesnici u razvoju mere kvatitet softvera, takoe, kroz njegove nedostatke, ali
su ti nedostaci drugaije prirode od nedostataka koje meri korisnik.
Svaki od navedena dva pogleda na softver ima svoj znaaj i ne moe se
zanemariti. Iako i korisnici i projektanti imaju svoje argumente, njihovi zakljuci
po pitanju kvaliteta softvera mogu se razlikovati. Na primer, ako se neki softver
teko ui i koristi, korisnik moe da ga proceni kao lo, iako on ima funkcionalnost
koja je nova i vredna, to mu svakako predstavlja kvalitet i daje mu prednost u
odnosu na konkurentske softvere.
Da bi se postigla jedinstvena i objektivna ocena kvaliteta softverskog
proizvoda, neophodno je objediniti spoljanji pogled korisnika sa unutranjim
pogledom uesnika u razvoju softvera. Ovaj cilj je ostvaren uvoenjem modela
kvaliteta. U poglavlju 9.2 opisani su najee primenjivani modeli kvaliteta.

9.1.2 Kvalitet procesa razvoja

Kvalitet procesa razvoja softvera je podjednako vaan kao i kvalitet
proizvoda. Tokom razvoja, izvravaju se mnoge aktivnosti koje imaju uticaja na
kvalitet finalnog proizvoda. Ako neka od aktivnosti krene u pogrenom smeru,
smanjuje se kvalitet proizvedenog softvera.
Proces modelovanja razvoja softvera znatno doprinosi boljem kvalitetu
softvera. Modelovanjem je omoguena pravovremena analiza sistema, uz
Pogledi na kvalitet softvera 189

uoavanje i otklanjanje postojeih nedostataka i nalaenje naina za dalja
unapreenja sistema. Tokom modelovanja, znaajno vreme se troi na analizu
nedostataka, to direktno utie na kvalitet. Ova analiza daje odgovore na pitanja
gde i kada e se verovatno pojaviti nedostaci, kako ih pronai to pre, da li se moe
ugraditi tolerancija na greke kako one ne bi prele u otkaz, itd. Analizi mogu biti
podvrgnute sve faze u procesu razvoja. Metodi modelovanja opisani su u poglavlju
2.

9.1.3 Kvalitet sa stanovita okruenja

Svaki softver namenjen je korienju u datom poslovnom okruenju. Ukoliko
to nije sluaj, smatra se da softver nema smisla. Nakon isporuke, softver ulazi u
fazu upotrebe, uz povremeno odravanje. To uvodi jo jedan pogled na kvalitet
softvera, a to je pogled sa aspekta poslovanja. Za razliku od ocenjivanja kvaliteta
proizvoda i procesa razvoja, koji se mere brojem otkaza, vremenom potrebnim za
njihovo otklanjanje i dr., kvalitet sa aspekta poslovanja se posmatra u zavisnosti od
proizvoda i usluga koje prua okruenje u kome softver radi.
Imajui ovo u vidu, moe se smatrati da softverski proizvod poseduje svoju
tehniku i poslovnu vrednost. Tehniku vrednost ine karakteristike proizvoda i
procesa razvoja. One zavise od naina izrade softvera, tj. od tehnikog aspekta. S
druge strane, poslovna vrednost predstavlja poslovne efekte koje softver proizvodi
u radnom okruenju. To su ekonomske kategorije, kao na primer produktivnost,
trokovi, period povratka investicije, itd. Ove dve vrednosti su meusobno zavisne.
Poveanje tehnike vrednosti proizvoda svakako utie na poslovnu vrednost.
Odnos tehnike i poslovne vrednosti proizvoda prikazan je na slici 9.1.

Kvalitet
prozvoda
TEHNIKA
vrednost
proizvoda
Kvalitet
procesa
razvoja
produktivnost
trokovi
period
povratka
investicije
.....
POSLOVNA
vrednost
proizvoda

Slika 9.1 Tehnika i poslovna vrednost proizvoda


Tehnika vrednost proizvoda je vana za direktne korisnike softvera, jer utie
na njihovo prihvatanje softvera. Za rukovodstvo kompanije, bitnija je poslovna
vrednost. Oni kvalitet mere kroz ostvarenu dobit (ostvarenu zbog uvoenja
softvera), trokove odravanja, trokove izmena, odnos vremena operativnog rada i
zastoja, i dr.

9.2 Modeli kvaliteta

Modeli kvaliteta su nastali zbog potrebe ukljuivanja razliitih aspekata
posmatranja u procenu kvaliteta proizvoda. Bez obzira na veliki broj modela
kvaliteta opisanih u literaturi, svi modeli podravaju isti pristup. Svaki model
definie skup karakteristika proizvoda koje smatra vanim. Ove karakteristike
potiu kako od spoljanjeg, tako i od unutranjeg pogleda na softver. One su
meusobno povezane na odgovarajui nain i imaju udela u postupku ocene
kvaliteta.
Mnogi modeli kvaliteta su nedoreeni, tj. ne preciziraju u potpunosti postupak
procenjivanja kvaliteta proizvoda, ve uglavnom daju okvire i smernice koji se
mogu koristiti u proceni. Takoe, ne navode se razlozi zato su pojedine
karakteristike ukljuene u model, a druge ne. Nema objanjenja ni zato se neka
karakteristika nalazi ba na konkretnom mestu u modelu, a ne na nekom drugom.

U narednim poglavljima opisani su najpoznatiji modeli kvaliteta: Mc Call-ov
model, Boehm-ov model, Dromey-ov model i ISO 9126.

9.2.1 McCall-ov model

McCall-ov model je jedan od najpoznatijih i najstarijih modela. Predloio ga
je McCall 1977.godine i izvorno je bio namenjen amerikoj vojsci. Model
predstavlja pokuaj prevazilaenja razlika u shvatanjima korisnika i razvojnog tima
po pitanju kvaliteta softvera.
McCall-ov model ini hijerarhija faktora, kriterijuma i metrike kojima se
proizvod opisuje, kako sa spoljanjeg, tako i sa unutranjeg aspekta. Faktori
predstavljaju razliite vrste karakteristika koje opisuju ponaanje sistema. Svakom
faktoru pridruen je skup kriterijuma, koji odgovaraju atributima faktora. Svaki
kriterijum se moe ukljuiti u jednu ili vie metrika. Metrika omoguava merenje
kvaliteta i upravljanje njime. Model obuhvata tri perspektive, kao to je prikazano
na slici 9.2.

Modeli kvaliteta 191

McCall-ov model
kvaliteta
Perspektiva 1 Perspektiva 2 Perspektiva 3
Faktor 1 Faktor 2 Faktor N
Kriterijum 1 Kriterijum 2 Kriterijum M
Metrika 1 Metrika 2 Metrika P
.....
.....
.....

Slika 9.2 Struktura McCall-ovog modela kvaliteta

U modelu postoji 11 faktora koji definiu kvalitet proizvoda sa stanovita
korisnika i 23 kriterijuma koji opisuju kvalitet sa stanovita onih koji razvijaju
sistem. Svaki faktor je povezan sa dva do pet kriterijuma. U zavisnosti od znaenja,
faktori su rasporeeni u tri perspektive:
x operativnost proizvoda (Perspektiva 1 na slici), sadri faktore koji se
odnose na upotrebu proizvoda
x revizija proizvoda (Perspektiva 2), sadri faktore koji opisuju mogunosti
menjanja proizvoda
x tranzicija proizvoda (Perspektiva 3), sadri faktore o prilagodljivosti
proizvoda radu u novom okruenju

Perspektiva operativnost proizvoda sadri sledee faktore:
x ispravnost, pokazuje u kojoj meri funkcionalnost sistema odgovara
specifikaciji
x pouzdanost, ukazuje na uestalost pojave greaka

x efikasnost, odnosi se na nain korienja resursa i ukljuuje efikasnost
izvravanja, kao i efikasnost pamenja podataka
x integritet, ukazuje na sposobnost zatite od neovlaenog pristupa softveru
x upotrebljivost, opisuje lakou korienja softvera

Perspektiva revizija proizvoda obuhvata:
x mogunost odravanja, ukazuje na trud potreban za lociranje i otklanjanje
greaka u programu unutar radnog okruenja
x fleksibilnost, pokazuje lakou izvoenja izmena potrebnih zbog promena u
radnom okruenju
x mogunost testiranja, odnosi se na lakou testiranja programa

Perspektivu tranzicija proizvoda ine faktori:
x prenosivost, ukazuje na napor potreban za prenos softvera iz jednog u
drugo okruenje
x mogunost ponovnog korienja, opisuje mogunost ponovnog korienja
softvera u drugom kontekstu
x interoperabilnost, odnosi se na mogunosti spezanja softvera sa drugim
sistemima

U tabeli 9.1 navedeni su kriterijumi za faktore perspektive operativnost
proizvoda (pod a)) i perspektive revizija proizvoda (pod b)).

Perspektiva Faktor Kriterijum
operativnost proizvoda ispravnost praenje i razumljivost
potpunost
konzistentnost
pouzdanost konzistentnost
preciznost
tolerancija na greke
efikasnost efiksanost izvravanja
efiksanost pamenja
integritet kontrola pristupa
revizija pristupa
upotrebljivost operativnost
obuka
komunikacija
a)

Perspektiva Faktor Kriterijum
revizija proizvoda mogunost odravanja jednostavnost
konciznost
samoopisivost
modularnost
fleksibilnost samoopisivost
proirivost
optost
mogunost testiranja jednostavnost
instrumentacija
samoopisivost
modularnost
b)

Tabela 9.1 Sadraj McCall-ovog modela kvaliteta

Osnovni cilj McCall-ovog modela je formiranje strukture faktora i kriterijuma
koja daje potpunu sliku o kvalitetu softvera i primena metrika na tu strukturu radi
procene kvaliteta softvera.

McCall definie skup metrika u vidu izraza za raunanje uticaja pojedinanih
elemenata na kvalitet. Opti oblik izraza za faktore kvaliteta je:

F
q
= c
1
m
1
+ c
2
m
2
+ ... + c
n
m
n

gde je F
q
faktor kvaliteta, m
i
kriterijumi od kojih faktor zavisi, a c
i
koeficijenti
uticaja (teinski koeficijenti). Vrednost koeficijenata c
i
zavisi od konkretnog
softverskog proizvoda. Priroda mnogih kriterijuma je takva da se njihova
ispunjenost moe proceniti samo subjektivno. Skup metrika se moe definisati i u
vidu tabele sa oznaenim zavisnostima izmeu faktora i kriterijuma bitnih za taj
faktor. Deo skupa dat je u tabeli 9.2.

Pri merenju kvaliteta softvera koristi se metod odgovaranja sa da ili ne na
postavljena pitanja. Na primer, da bi se utvrdio uticaj nekog kriterijuma, postavlja
se vei broj pitanja u vezi sa njim. Ako je isti broj odgovora da i ne, smatra se
da se kriterijum dostie sa 50%. Metrike se mogu formirati po kriterijumima,
faktorima, ili po proizvodu.


K R I T E R I J U M I
F

A

K

T

O

R

I

i
s
p
r
a
v
n
o
s
t

p
o
u
z
d
a
n
o
s
t

e
f
i
k
a
s
n
o
s
t

i
n
t
e
g
r
i
t
e
t

u
p
o
t
r
e
b
l
j
i
v
o
s
t

o
d
r
a
v
a
n
j
e

f
l
e
k
s
i
b
i
l
n
o
s
t

t
e
s
t
i
r
a
n
j
e

p
r
e
n
o
s
i
v
o
s
t

p
o
n
.

k
o
r
i
e
n
j
e

i
n
t
e
r
o
p
e
r
a
b
i
l
n
o
jednostavnost X X X X
konzistentnost X X X X
optost X X X X
modularnost X X X X X X X
tolerancija na greke X

Tabela 9.2 Veza faktora i kriterijuma u metrici

9.2.2 Boehm-ov model

Boehm-ov model je nastao neposredno posle McCall-ovog modela, 1998.
godine. I ovaj model opisuje kvalitet proizvoda u vidu hijerarhije karakteristika
koje ukljuuju oekivanja i korisnika i uesnika u razvoju. Meutim, Boehm-ov
model ima iri pristup od McCall-ovog, zato to ukljuuje i trokove i efikasnost
odravanja.
Za Boehm-a i ostale autore modela, primarna karakteristika kvaliteta je opta
korisnost. Softver, pre svega, mora da bude koristan. Ako to nije sluaj, onda je
njegov razvoj bio gubitak vremena, novca i rada. Sm model se sastoji od tri nivoa:
visokog, srednjeg i niskog nivoa karakteristika. Na dnu hijerarhije se nalaze
metrike pridruene karakteristikama najnieg nivoa, kao to je prikazano na slici
9.3.

Visok nivo karakteristika opisuje osnovne zahteve po pitanju kvaliteta koji
moraju da budu zadovoljeni. Ovaj nivo sadri tri karakteristike:
x upotrebljivost (v_karakteristika 1 na slici). Pokazuje koliko efiksano, lako i
pouzdano se softver moe koristiti (onakav kakav je trenutno).
x mogunost odravanja (v_karakteristika 2). Ukazuje na mogunost lakog
razumevanja, modifikovanja i ponovnog testiranja softvera.
x prenosivost (v_karakteristika 3). Odnosi se na mogunost korienja
softvera u sluaju izmenjenog okruenja.


Boehm-ov model
kvaliteta
metrika 1 metrika 2 metrika P
.....
.....
v_karakteristika 1 v_karakteristika 2 v_karakteristika 3
s_karakteristika 1 s_karakteristika 2 s_karakteristika N
.....
n_karakteristika 1 n_karakteristika 2 n_karakteristika M

Slika 9.3 Struktura Boehm-ovog modela kvaliteta

Na srednjem nivou se nalazi sedam karakteristika koje opisuju ta se po
pitanju kvaliteta oekuje od softverskog sistema. To su:
x prenosivost. Softver moe dobro da radi u raunarskom okruenju
drugaijem od postojeeg.
x pouzdanost. Softver na zadovoljavajui nain izvrava funkcionalnost koja
se od njega oekuje.
x efikasnost. Sistem efikasno koristi resurse.
x upotrebljivost. Softver je pouzdan, efikasan i pogodan za korienje.
x mogunost testiranja. Uspostavljeni su kriterijumi validacije i evaluacija
performansi.
x razumljivost. Svrha softvera je jasno naznaena.
x fleksibilnost. Softver omoguava lako ukljuivanje izmena u sistem.

Niski nivo obuhvata petnaest karakteristika koje su povezane sa
karakteristikama srednjeg i visokog nivoa na nain prikazan na slici 9.4.

Kao to se vidi, za razliku od McCall-ovog modela, Boehm-ov model
predstavlja hijerarhiju koja na najviem nivou ima karakteristike bitne za krajnjeg
korisnika, a na dnu karakteristike tehnikog tipa. Karakteristike na najniem nivou
predstavljaju osnovu za definisanje metrika kvaliteta. Pod metrikom, Boehm
podrazumeva meru obima ili stepena do koga softverski proizvod poseduje neku
karakteristiku kvaliteta. Merljive karakteristike se odnose na visoko tehnike
detalje kvaliteta koje teko mogu da razumeju ne-tehniki uesnici u projektu.

Opta
korisnost
Mogunost
odravanja
Upotrebljivost
Pouzdanost
Efikasnost
Ljudsko
inenjerstvo
Testiranje
Razumljivost
Fleksibilnost
Prenosivost
Saetost
Strukturisanost
Samoopisivost
Komunikativnost
Pristupanost
Efikasnost ureaja
Odgovornost
Doslednost
Robustnost/integritet
Potpunost
Tanost
Samosadrivost
Nezavisnost od ureaja
itljivost
Proirivost

Slika 9.4 Sadraj Boehm-ovog modela kvaliteta

9.2.3 Dromey-ov model

Dromey-ov model kvaliteta potie iz 1995.godine. On se zasniva na
proizvodu. Uoeno je da postupak procene kvaliteta treba da se razlikuje od

proizvoda do proizvoda. Stoga je potrebno razviti vie ideja, kako bi se one mogle
primeniti na razliite sisteme.
Model kvaliteta proizvoda se sastoji od etiri njegove osobine. Za svaku
osobinu, definisan je odreen broj atributa kvaliteta. Opta struktura Dromey-ovog
modela data na je slici 9.5.

Dromey je predloio generiku tehniku za izgradnju modela kvaliteta. Po
njemu, kvalitet proizvoda zavisi od izbora komponenata od kojih je proizvod
nainjen, osobina tih komponenata i njihove kompozicije. Po pitanju komponenata,
Dromey je razvio razliite modele koji se mogu koristiti za evaluaciju kvaliteta
zahteva, dizajna i smog softvera. Ideja je bila da se tokom celog ivotnog ciklusa
proizvode elementi kvaliteta, tako da se na kraju dobije finalni proizvod koji
ispoljava atribute visokog kvaliteta.

Dromey-ov model
kvaliteta
Softverski proizvod
Osobina 1 Osobina 2 Osobina 3
Atribut 1 Atribut 2 Atribut N
.....
Osobina 4

Slika 9.5 Struktura Dromey-ovog modela kvaliteta

Na slici 9.6 prikazan je sadraj Dromey-ovog modela.

Kao to se vidi, izdvojene su etiri osobine proizvoda: ispravnost i unutranja,
kontekstualna i opisna svojstva. Osobine su povezane sa atributima kvaliteta
visokog nivoa, tj. atributima sa najveim prioritetom (prioriteti atributa se razlikuju
u razliitim projektima).


Implementacija
Unutranja sv.
Funkcionalnost
Ispravnost Kontekstualna sv. Opisna sv.
Pouzdanost
Odravanje
Efikasnost
Pouzdanost
Odravanje
Re-upotreba
Prenosivost
Pouzdanost
Odravanje
Efikasnost
Pouzdanost
Upotrebljivost

Slika 9.6 Sadraj Dromey-ovog modela kvaliteta

Primena modela obuhvata sledeih pet koraka:

1. Izabrati skup atributa kvaliteta visokog nivoa.
2. Identifikovati komponente sistema.
3. Identifikovati najznaajnija svojstva koja doprinose kvalitetu svake komponente.
4. Odrediti kako svako svojstvo utie na atribute kvaliteta.
5. Uraditi evaluaciju modela i identifikovati njegove nedostatke.

9.2.4 Model ISO 9126

Model ISO (International Standardization Organization) 9126 iz 1991.godine
nastao je kao rezultat pokuaja da se u softverskom inenjerstvu uspostavi
konsenzus po pitanju terminologije vezane za procenu kvaliteta proizvoda. Ideja je
bila da ovaj model postane svetski standard za procenu kvaliteta softvera. Kasnije
su se pojavile brojne proirene verzije ovog standarda.
ISO 9126 model, osim modela kvaliteta, definie i niz uputstava za merenje
karakteristika kvaliteta koje se pojavljuju u modelu.

ISO model ukazuje na tri aspekta kvaliteta softvera:
x kvalitet sa aspekta upotrebe. Predstavlja korisniki pogled na kvalitet
softvera kada je softver u upotrebi u datom okruenju i datom kontekstu.

Njime se meri obim u kome korisnici mogu da ostvare svoje ciljeve u
datom okruenju, ne vodei rauna o osobinama samog softvera.
x spoljanji kvalitet. Odreen je ukupnim spoljanjim karakteristikama
softvera koji se izvrava. Obino se meri tokom testiranja u simuliranom
okruenju sa simuliranim podacima primenom spoljanjih metrika.
x unutranji kvalitet. Odreen je ukupnim unutranjim karakteristikama
softvera. Kvalitet softvera se moe poboljati tokom kodiranja, pregledanja
i testiranja.

Navedeni aspekti su meusobno povezani. Atributi bitni za unutranji kvalitet
utiu na atribute spoljanjeg kvaliteta, a oni, dalje, utiu na atribute kvaliteta sa
aspekta upotrebe.
ISO 9126 se moe smatrati dvodelnim modelom kvaliteta, koga ine sledei
delovi:
x spoljanji i unutranji model kvaliteta
x model kvaliteta upotrebe

Spoljanji i unutranji model kvaliteta se zasniva na McCall-ovom i Boehm-
ovom modelu. To je model koga ine tri nivoa. Prvi nivo sadri 6 karakteristika
kvaliteta, drugi 27 podkarakteristika kvaliteta, a trei mere kvaliteta. Model je
prikazan na slici 9.7.

.....
karakteristika 1 karakteristika 2 karakteristika N
podkarakteristika 1 podkarakteristika 2 podkarakteristika P
Spoljanji i unutranji
kvalitet
.....

Slika 9.7 ISO 9126 model za spoljanji i unutranji kvalitet

U okviru standarda, predloeno je vie od 100 mera spoljanjih i unutranjih
karakteristika, mada taj skup nije potpun, ve se mogu koristiti i druge mere. Ove
mere su opisane u vie dokumenata.
U nastavku su opisan sadraj modela, tj. znaenja svih njegovih karakteristika
i podkarakteristika:

x funkcionalnost sposobnost softverskog proizvoda da obezbedi potrebne
funkcije pri radu u zadatim uslovima. Sadri sledee podkarakteristike:
pogodnost sposobnost softvera da obezbedi odgovarajui skup
funkcija za specificirane zadatke i korisnike ciljeve
preciznost sposobnost softverskog proizvoda da obezbedi prave i
dogovorene rezultate ili efekte sa potrebnim stepenom preciznosti
sigurnost sposobnost softvera da zatiti informacije i podatke tako da
neautorizovane osobe ili sistemi ne mogu da im pristupaju, a
autorizovani mogu
interoperabilnost sposobnost softvera da ostvari interakciju sa drugim
sistemima
funkcionalna usaglaenost sposobnost softverskog proizvoda da
potuje standarde, dogovore ili zakonske regulative povezane sa
funkcionalnou
x pouzdanost sposobnost softverskog proizvoda da postigne zadati nivo
performansi kada se koristi u zadatim uslovima. Sadri sledee
podkarakteristike:
zrelost sposobnost softvera da prevazie nedostatak nastao kao
rezultat greke u softveru
tolerancija na greke sposobnost softvera da odri potreban nivo
performansi u sluaju pojave softverskih greaka
mogunost oporavka sposobnost softvera da ponovo uspostavi
potreban nivo performansi i oporavi podatke direktno ukljuene u
nastanak nekog problema
usaglaenost pouzdanosti sposobnost softverskog proizvoda da
potuje standarde, dogovore ili zakonske regulative povezane sa
pouzdanou
x upotrebljivost sposobnost softverskog proizvoda da se lako usvaja,
razume, ui i koristi kada se primenjuje pod zadatim uslovima. Sadri
sledee podkarakteristike:
razumljivost sposobnost softvera da korisniku omogui da lako shvati
da li je sistem odgovarajui, kako se koristi i pod kojim uslovima
mogunost uenja sposobnost softvera da korisniku prui mogunost
uenja aplikacije

operativnost sposobnost softvera da omogui korisniku da radi i
kontrolie sistem
atraktivnost sposobnost softvera da bude privlaan za korisnika
upotrebna usaglaenost sposobnost softverskog proizvoda da potuje
standarde, dogovore, uputstva ili zakonske regulative povezane sa
upotrebljivou
x efikasnost sposobnost softverskog proizvoda da prui odgovarajue
performanse, u skladu sa korienim resursima, u zadatim uslovima rada.
Sadri sledee podkarakteristike:
ponaanje u vremenu sposobnost softvera da pri izvravanju funkcija
proizvede eljeni odziv u zadatom vremenu i uz predviene protoke
(pod specificiranim radnim uslovima)
ponaanje u vezi sa resursima sposobnost softvera da koristi
odgovarajue koliine i vrste resursa pri izvravanju svojih funkcija
usaglaenost efikasnosti sposobnost softverskog proizvoda da potuje
standarde i konvencije povezane sa efikasnou
x mogunost odravanja sposobnost softverskog proizvoda da bude
modifikovan. Modifikacije ukljuuju mogue korekcije, poboljanja ili
prilagoenja u skladu sa promenama u okruenju, promenama u zahtevima
ili funkcionalnim specifikacijama. Sadri sledee podkarakteristike:
mogunost analize sposobnost softvera da dijagnostikuje nedostatke i
njihove uzroke, kao i da identifikuje delove koje treba modifikovati
promenljivost sposobnost softvera da se u njemu implementira
potrebna modifikacija
stabilnost sposobnost softvera da izbegne neoekivane efekte zbog
izmena u softveru
mogunost testiranja sposobnost softvera da omogui validaciju
nakon modifikacije softvera
usaglaenost odravanja sposobnost softverskog proizvoda da potuje
standarde i konvencije povezane sa odravanjem
x prenosivnost sposobnost softverskog proizvoda da se prenese iz jednog
okruenja u drugo. Sadri sledee podkarakteristike:
prilagodljivost sposobnost softvera da se prilagodi razliitim
okruenjima bez dodatnih akcija (ili sredstava) u odnosu na one koje su
ve predviene u softveru za tu svrhu

mogunost instaliranja sposobnost softvera da bude instaliran u
specificiranom okruenju
koegzistencija sposobnost softvera da radi u zajednikom okruenju
sa drugim nezavisnim softverima, delei sa njima iste resurse
zamenljivost mesta sposobnost softvera da bude upotrebljen umesto
drugog softvera sa istom svrhom i u istom okruenju
usaglaenost prenosivosti sposobnost softverskog proizvoda da
potuje standarde i konvencije povezane sa prenosivou

Iz opisanog sadraja modela moe se zapaziti da se svaka podkarakteristika
odnosi na tano jednu karakteristiku (to nije sluaj kod McCall-ovog i Boehm-
ovog modela). Osim toga, podkarakteristikama je opisan korisnikov pogled na
softver, a ne interni pogled projektanta.
Model kvaliteta upotrebe sadri etiri karakteristike kvaliteta vezane za
upotrebu softvera, kao to je prikazano na slici 9.8.

Efektivnost Produktivnost Zadovoljstvo
Kvalitet upotrebe
Bezbednost

Slika 9.8 ISO 9126 model kvaliteta upotrebe

203

Dodatak je namenjen samo studentima Univerziteta Singidunum koji polau
predmet Razvoj aplikativnog softvera. U okviru ovog predmeta, kao sastavni deo
ispita, predviena je izrada projekta. Cilj projekta je da studenti u praksi, tj. na
primeru generisanja konkretnog softvera, prou kroz sve faze ivotnog ciklusa
softvera u onoj meri u kojoj fakultetsko okruenje to doputa. Na ovaj nain,
studentima se prua mogunost da provere svoja teorijska znanja usvojena na
predavanjima, kao i da steknu prva praktina iskustva u izradi softvera.
Projekat se radi timski na zadatu temu primenom poznatih tehnologija koje su
raspoloive na fakultetu. Podrazumeva se da studenti vladaju razvojnim
okruenjem, programskim jezikom i tehnikama programiranja koji e biti korieni
u realizaciji softvera. Osim softvera, kao rezultat projekta oekuje se i dokument u
pisanoj formi u kome e detaljno biti opisano izvoenje projekta po razvojnim
fazama. Ovaj dokument sadri samo delove koji su izvodljivi u datom okruenju. U
zavisnosti od vrste projekta, dokument sadri samo stavke primerene datom
projektu.

U optem sluaju, dokument sa opisom projekta treba da prati sledeu
strukturu:

Naslovna strana

Na naslovnoj strani navesti naziv projekta, autore projekta i vreme izrade
projekta.

1. Kratak opis projekta

Ukratko predstaviti temu i cilj projekta.

Dodatak

204
2. Postupak razvoja softvera

Izabrati jednu od tradicionalnih metoda modelovanja koja e biti primenjena u
procesu razvoja konkretnog softvera (poglavlje 2.1). Preporuuju se kaskadni ili V
model.
U skladu sa izabranom metodom, predloiti detaljan plan projekta u kome
treba:
x definisati kritine take (milestones) koje pokazuju ta treba da bude
uraeno na projektu i do kada
x navesti uloge svih lanova projektog tima uz precizan opis ta ko od njih
treba da uradi i do kada
x navesti planirane rezultate za svaku kritinu taku; rezultati mogu biti
softverski moduli, modeli, dokumentacija, kratka korisnika uputstva i sl.

3. Analiza zahteva

Izraditi specifikaciju softverskih zahteva. Posebnu panju posvetiti:
x funkcionalnim zahtevima sistema
x zahtevima kojima se definiu veze sistema sa okruenjem
x zahtevima po pitanju performansi koje sistem treba da ispuni

Specifikacija moe, prema potrebi, da sadri tekstualne opise zahteva, UML
dijagrame, snimke ekrana, predloge izvetaja, tabela i dr.

4. Projektovanje sistema

Isprojektovati sistem sa aspekta njegove arhitekture i programskog kda.

Predstaviti arhitekturu sistema u vidu modularne hijerarhije iz koje se jasno
vidi koje komponente postoje u sistemu i kako su one meusobno povezane. Pri
tome koristiti odgovarajui stil projektovanja (poglavlje 4.2).
Izabrati programski jezik koji e biti korien pri implementaciji i obrazloiti
njegov izbor. Opisati strukture podataka i algoritme koji e biti primenjeni.
Napraviti strukturu programskih modula, tj. datoteka pomou kojih e sistem biti
implementiran. Navesti potrebne procedure i funkcije u okviru svakog
programskog modula.

Pri projektovanju intenzivno koristiti sve vrste UML dijagrama date u
poglavlju 5.

205

5. Implementacija softvera

Na izabranom programskom jeziku napisati programski kd koji realizuje
sistem. Datoteke sa izvornim kdom dopuniti odgovarajuom unutranjom
dokumentacijom, tj. komentarima. Na jednoj strani, priloiti primer dobro
dokumentovanog programskog kda (poetak datoteke sa zaglavljem).

6. Testiranje softvera

U okviru jedininog testiranja po modulima, opisati sve testove koji su
sprovedeni u cilju provere ispravnosti napisanog programskog kda.
Navesti koji je princip integracionog testiranja korien (poglavlje 7.2.2) i
dati hijerarhiju koja pokazuje redosled u kome su moduli testirani.
Nacrtati dijagram zavisnosti broja pronaenih greaka u softveru po
nedeljama.

7. Isporuka softvera

Napisati deo Uputstva za korienje koji se odnosi na jednu (izabranu)
funkcionalnost sistema.

1. S. L. Pfleeger, J. M. Atlee, Softversko inenjerstvo:teorija i praksa, prevod
Raunarski fakultet, Beograd, 2006.

2. A.Bijlsma, B.J.Heeren, E,E,Roubtsova, S.Stuurman, Software Architecture,
Free Technology Academy, 2011.

3. I. Mari, Software Engineering, Department of Electrical and Computer
Engineering, Rutgers, State University of New Jersey, 2012.

4. Rational Software, Rational Unified Process: Best Practices for Software
Development Teams, 2011.

5. M. Flowler, UML ukratko, prevod Mikro knjiga, 2004.

6. D. Boji, Testiranje softvera, skripta, Elektrotehniki fakultet Beograd, 2010.

7. K. Erdil, E. Finn, K. Keating, J. Meattle, S. Park, D. Yoon, Software
Maintenance As Part of the Software Life Cycle, Department of Computer
Science, Tufts University, USA, 2003.

8. R. E. Al-Quataish, Quality Models in Software Engineering Literature: An
Analytical and Comparative Study, Journal of American Science 6(3), 2010.

9. R. Fitzpatrick, Software Quality: Definitions and Strategic Issues, Staffordshire
University, 1996.

10. D.C.Rajapakse, Practical Tips for Software-Intensive Student Projects, 3rd
edition, 2010.

Literatura

US - Razvoj Aplikativnog Softvera

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

US - Razvoj Aplikativnog Softvera

Uploaded by

Copyright:

Available Formats

0NIvERZITETSINuIB0N0N

You might also like