1.

Informacioni sistem
1.1 Informacioni sistem: koncepti i definicije
Informatiku eru karakterie nov i bitno razliit pristup upravljanju organizacijom i njenim poslovnim
procesima. Potpuno je izmenjen znaaj i vrednost materijalne i intelektualne svojine organizacije.
Akcenat je u informatikoj eri na intelektualnoj svojini i posebno informacijama i znanju. Funkcionisanje
organizacije i upravljanje organizacijom i njenim procesima je postalo nezamislivo bez odgovarajuih
podataka, informacija i znanja. Tako oni postaju jednako znaajan resurs organizacije kakvi su sirovine,
energija, radna snaga, finansije i dr. Podaci se registruju, pripremaju, unose, organizuju, uvaju u bazama
podataka informacionog sistema. Informacioni sistem organizacije iste obrauje i obezbeuje
informacije i znanje za realizaciju poslovnih operacija i reavanje poslovnih problema organizacije.
Informacioni sistemi imaju primarni cilj da podatke na ekonomian nain obrade i transformiu u
informaciju ili znanje. Stoga je potrebno u smislu njihovog razumevanja definisati ove osnovne pojmove.
Podaci, elementarno opisuju stvari, dogaaje, aktivnosti i transakcije koji su zabeleeni, klasifikovani i
uskladiteni, ali nisu organizovani da prenesu neko konkretno znaenje. Oni mogu biti razliitih oblika:
numeriki, alfanumeriki, zvuci, slike i dr. i skladite se u bazu podataka, organizuju na nain da se lako
pronalaze.
Informacije, su organizovani podaci na nain da imaju znaenje i vrednost za primaoca. Najee se
podaci obrauju aplikativnim programima, kako bi se proizvela vea njihova korisnost od one koja se
postie u sluaju direktnog i jednostavnog pozivanja iz baze podataka.
Znanje, ine podaci ili informacije koji se organizuju i obrauju da prenesu razumevanje, iskustvo,
akumulirano uenje i strunost u primeni na odreeni aktuelni problem ili aktivnost. Podaci se posebno
obrauju na nain da reflektuju iskustvo i ekspertizu, prue primaocu organizaciono znanje visoke
potencijalne vrednosti.
Podaci, informacije i znanje su potencijalni ulazi ali istovremeno mogu biti i izlazi informacionog sistema.
Postoje tri osnovna razloga za primenu informacionih tehnologija u poslovanju, koji su u neposrednoj
(direktnoj) vezi sa tri vitalne uloge informacionog sistema, koje on moe imati za poslovnu organizaciju.
To su: podrka poslovnih procesa i aktivnosti (operativnih aktivnosti, operations) organizacije, podrka
donoenju odluka od strane zaposlenih i menadera (rukovodilaca) i podrka strategiji u realizaciji
konkurentskih prednosti.

Tekst preuzet iz udbenika Balaban N. i dr: Informacione tehnologije i

informacioni sistemi, 2007., Ekonomski fakultet Subotica.
1.1. Definicije informacionog sistema
Upravljanje ma kojom organizacijom ukljuuje donoenje odluka i reavanje problema, a u tu svrhu su
neophodne informacije i znanja. Informacioni sistemi obezbeuju informacije neophodne za svrhe
donoenja odluka i reavanja problema. Kao to je ve reeno, informacije potiu iz izvora unutar
organizacije i izvora izvan organizacije. I jedne i druge mogu da budu obraivane kako formalnim
informacionim sistemom date organizacije, tako i njenim neformalnim sistemom. Prvobitno su raunari
bili upotrebljavani za "elektronsku obradu podataka" (EOP), a kada je shvaeno da mogunosti raunara
daleko prevazilaze puku obradu podataka, iskrsle su nove svrhe i novi vidovi informacionih sistema. Tako
se, istorijski posmatrano, prvo javljaju upravljaki informacioni sistemi (Management Information
Systems - MIS), a potom sistemi za podrku odluivanju (Decision Support Systems - DSS). Pored toga, u
podruju vetake inteligencije razvijani su ekspertni sistemi - ES. Potom je usledio razvoj
automatizovane kancelarije (Office Automation - OA). Prema nekim shvatanjima (McLeod, 1990) svih
pet navedenih osnovnih oblasti primene predstavljaju jedan celoviti sistem - informacioni sistem
zasnovan na raunaru (Computer-Based Information System - CBIS).

Slika 1. Istorijski pregled razvoja kompjuterizovanih poslovnih informacionih sistema

1.2. Komponente i aktivnosti informacionih sistema

Svaki informacioni sistem je sistemska celina i sklad izmeu njegovih kljunih komponenti koje izvravaju
odreene aktivnosti. Slika 2. je model informacionog sistema, koji sistemskim prilazom pokazuje
koncepcijski okvir, najvanije komponente i aktivnosti sistema. Sistem skuplja, sreuje, obuhvata i unosi
podatke u proces obrade, organizuje, skladiti i odrava podatke u bazi podataka i, iz organizovanih i
uskladitenih podataka, derivira informacije za krajnje korisnike sistema.

Slika 2.
Model, takoe, ukazuje na relevantne odnose i objanjava kljune veze izmeu osnovnih komponenti i
aktivnosti informacionog sistema. Moe se rei da su etiri kljuna koncepta implicitna u svim vrstama
informacionih sistema (OBrian, 1999 s.43):

Ljudi, hardver, softver, podaci i raunarske mree ine pet osnovnih grupa resursa
svakog informacionog sistema;
Ljudski resurs ukljuuje specijaliste i korisnike IT (Information Technology), hardverski
resurs obuhvata raunarske ureaje i medije, softverski resurs programe i procedure,
resurs podataka baze podataka i znanja i resurs mree komunikacione medije i
raunarske mree;
Resurs podataka se transformie aktivnostima procesiranja u razliite informacione
proizvode za razliite krajnje korisnike i;
Procesiranje informacija obuhvata aktivnosti: ulaz, obradu, izlaz, memorisanje i
kontrolu.

Ulaz kao resurs podataka je aktivnost koja podatke o nastalim poslovnim transakcijama zahvata,
priprema i unosi u sistem, odnosno, bazu podataka. Krajnji korisnici informacionog sistema
nastale podatke obuhvataju, ureuju i zapisuju na medije kao to su izvorna dokumenta ili
upisuju direktno na elektromagnetne medije raunarskog sistema. Uneti podaci se transferiu

na mainski itljive medije kao to su magnetni diskovi, upisuju u bazu, uvaju, odravaju i
koriste u procesu obrade.
Obrada podataka u informacije je aktivnost procesiranja: izraunavanja, uporeivanja,
sortiranja, sumacije, klasifikacije i mnogih drugih operacija. U okviru ove aktivnosti podaci se
itaju sa elektromagnetnih medija, organizuju, analiziraju i manipulie se njima, da bi se
konvertovali u informacije potrebne korisnicima. Podaci u bazi podataka, u cilju njihovog
kvaliteta, podleu, takoe, kontinuiranom odravanju, odnosno auriranju i dodavanju novih
podataka, brisanju i menjanju postojeih.
Izlaz informacionih proizvoda u razliitim oblicima i razliitog sadraja je aktivnost iji je cilj da
zadovolji informacione potrebe korisnika razliitih profila: menadera, eksperata, tehnikog
osoblja. Najee su informacioni proizvodi poruke, izvetaji, dokumenta, grafike vizualizacije,
koji mogu biti prezentirani korisnicima putem razliitih izlaznih ureaja. Korisnici ele
informacione proizvode koji poseduju odgovarajui kvalitet. Informacije koje su neaktuelne,
nisu prispele na vreme, teko su razumljive i slino, nisu od velike vrednosti i upotrebljivosti za
korisnike. Korisnici ele informacije vieg kvaliteta, to jest, informacione proizvode ije ih
karakteristike, atributi i kvalitet ine poeljnim, korisnim i odgovarajuim za zadovoljenje
informacionih zahteva korisnika.
Memorisanje podataka je kljuna komponenta i aktivnost informacionog sistema. Podaci i
informacije stalno ostaju organizovani na odreeni nain, poeljnog kvaliteta i zapisani na
elektromagnetnim medijima za kasnije korienje. Podaci i informacije su u savremenim
informacionim sistemima organizovani kao baze podataka.
Kontrola performansi sistema je, takoe, veoma vana aktivnost informacionih sistema.
Kontrola ulaza, obrade, izlaza i memorisanja podataka, odnosno informacija, se obezbeuje
odgovarajuom povratnom spregom o stanju, procesima i kvalitetu ovih aktivnosti. Povratnom
spregom mora se kontrolisati i ocenjivati sistem sa stanovita uspostavljenih standarda
performansi uz stalno poravnavanje da bi kvalitet informacionih proizvoda bio zadovoljavajui i
prihvatljiv za korisnike.
1.3. Resursi informacionih sistema
Informacioni sistem je sociotehniki sistem koji upotrebljava, organizuje i efektivno i efikasno
koristi odreene resurse. Resursi informacionog sistema su: ljudski resursi, hardverski resursi,
softverski resursi, resursi podataka i resursi raunarskih mrea.
Ljudski resursi su neophodni za funkcionisanje informacionih sistema. IT specijalisti i krajnji
korisnici IS ine ljudske resurse. IT specijalisti su ljudi koji razvijaju, implementiraju, ocenjuju i
odravaju IS. Ljudski resursi su organizovani u IC (Informacionom centru) i zavisno od dimenzija
organizacione strukture IC, a pre svega od podele rada, mogu biti: projektanti informacionih
sistema, sistem analitiari, programeri, administratori baza podataka, softver inenjeri,
specijalisti za hardver i mree, operateri i drugi. Strunjaci ovih profila vre odreene poslove,
izvravaju konkretne radne zadatke. Krajnji korisnici su ljudi koji koriste informacioni sistem i

njegove informacione produkte u svakidanjem radu. To mogu biti menaderi, analitiari,

inenjeri, istraivai, komercijalisti, raunovoe, tehniko osoblje i drugi. Veina zaposlenih u
organizaciji su krajnji korisnici informacionog sistema.
U hardverske resurse spadaju celokupni raunarski resursi koji tehniki podravaju rad
informacionog sistema. Raunarski sistemi: serveri baza podataka (veliki i raunari opte
namene), serveri aplikacija (mini raunari), radne stanice (mikro raunari), periferne jedinice
(tampai, tastature, monitori, magnetni i optiki itai i drugi), elektromagnetni mediji za
smetaj podataka (diskovi, diskete, optiki diskovi, magnetne trake), zajedno ine integralnu
tehniku podrku i hardverski resurs informacionih sistema.
Softverski resursi ukljuuju sve vrste programskih instrukcija i procedura. Operativni sistemi,
programi prevodioci, sistemi za upravljanje bazama podataka, statistiki paketi, OLAP softver i
mnogi korisniki programi (aplikativni softver) predstavljaju resurs informacionih sistema od
ogromnog znaaja i znaajnu intelektualnu investiciju organizacije. Niz procedura koje upuuju
korisnika kako da koristi svoj IS, su takoe znaajan softverski resurs.
Podaci, informacije i znanje su resurs ne samo IS, nego i organizacije, podjednako vaan kao i
drugi resursi. Ovaj resurs se esto organizuje u bazama podataka (podaci i informacije),
dimenzionalnim bazama podataka u Data Warehouse (ekstrahirani i agregirani podaci i
informacije), bazama znanja, Knowledge Warehouse i dr.
Resursi raunarskih mrea, lokalnih i globalnih, sa aktivnom i pasivnom mrenom opremom,
ureajima i instalacijama, su okosnica telekomunikacionog podsistema informacionog sistema.
Telekomunikacione mree, kao to su intranet, ekstranet i Internet, su postale neminovnost
uspenog funkcionisanja organizacije i integralnih informacionih sistema.
Ovi resursi ukljuuju:
a) komunikacione medije, kao to su koaksijalni kablovi, fiber-optiki kablovi, mikrotalasni
sistemi, satelitski komunikacioni sistemi i drugi,
b) mrenu opremu: ruteri, svievi, modemi, habovi, razne vrste prikljuaka i druga mrena
oprema, i
c) komunikacioni kontrolni softver.
1.4. Vrste informacionih sistema
Razvijeno je mnotvo razliitih informacionih sistema zasnovanih na raunarima - computerbased information systems (CBIS) s razliitim funkcionalnim svojstvima:
a) upravljaki informacioni sistemi - management information systems (MIS);
b) informacioni sistemi za izvrno rukovodstvo - executive information systems (EIS);
c) sistemi za podrku odluivanju izvrnog rukovodstva - executive support systems (ESS);
d) sistemi za podrku odluivanju - decision support systems (DSS);
e) sistemi za podrku grupnom odluivanju group decision support systems (GDSS);
f) elektronski sistemi za odravanje sastanaka - electronic meeting systems (EMS);
g) sistemi za podrku odluivanju organizacije - organizational decision support systems (ODSS);

h) ekspertni sistemi - expert systems (ES);

i) informacioni sistemi kancelarije - office information systems (0IS);
j) inteligentni informacioni sistemi organizacije - intelligent organizational information systems
(I0IS) i dr.
G. Mentzas (Mentzas, 1994) je s ciljem uveanja preciznosti klasifikovanja informacionih
sistema zasnovanih na raunarima preduzeo domiljat pokuaj da razvije osnovni okvir za
njihovu funkcionalnu taksonomiju. On je ispitao i klasifikovao deset informacionih sistema
zasnovanih na raunarima u trodimenzionalnom prostoru s obzirom na veliinu podrke koju
pruaju trima vrstama procesa: informacionim procesima, procesima odluivanja i
komunikacionim procesima.
Pored ostalog, Mentzas je klasifikovao informacione sisteme zasnovane na raunarima prema
stepenu podrke koju pruaju na nivou individue, nivou grupe i nivou organizacije, to je
prikazano u Tabeli 2-4:

Prema jednom stanovitu savremeni informacioni sistemi organizacije bazirani na i podravani

informatikim tehnologijama mogu se podeliti na: operativne informacione sisteme i sisteme za
podrku menadmenta/menaderski IS.
1.4.1. Operativni informacioni sistemi
Informacioni sistemi koji su namenjeni za obradu podataka nastalih u poslovnim i tehnolokim
procesima i koji obezbeuju podatke i informacije za poslovne operacije, nazivaju se
operativnim informacionim sistemima. Uloga ovih sistema je podrka unapreenju i efikasnom
izvravanju poslovnih transakcija, kontrola tehnolokih procesa, automatizacija poslova u
kancelarijama, podrka u kreiranju, distribuciji i korienju znanja, podrka komunikaciji i
saradnji u organizaciji, formiranje i odravanje integralne baze podataka organizacije.
OLTP sistemi (On Line Transaction Procesing System) su sistemi koji trenutno obrauju podatke
nastale u poslovnim transakcijama. U toku dana se obrade milioni razliitih poslovnih
transakcija i automatski izvri auriranje velikih baza podataka. Ovi sistemi su bazirani na
relacionoj tehnologiji i koriste najsavremenije tehnike raunarstva. Tipini poslovni procesi su,
na primer, ovi: obrada porudbenica, fakturisanje, kontrola zaliha, obrada zarada, prodaja robe
u trgovinskim objektima, obrada transakcija u bankarskom poslovanju i slino. Dakle, OLTP
omoguavaju automatizaciju odvijanja poslovnih procesa, aktivnosti, poslova, radnih zadataka i
operacija. Oni su, takoe, osnova i sredstvo za razvoj sistema koji podravaju odluivanje u
menadmentu. Teko je, zapravo, pretpostaviti i praktino je neostvariva zamisao razvoja

upravljakih informacionih sistema, Data Warehouse-a, sistema poslovne inteligencije i drugih,

a da organizacija nije prethodno razvila i implementirala OLTP.
1.4.2. Menaderski informacioni sistemi
Menaderski informacioni sistemi su sistemi podrke odluivanju u menadmentu. Oni mogu
biti: MIS (Management Information Systems), DSS (Decision Support Systems) i EIS (Executive
Support Systems).
MIS - MIS je klasini upravljaki informacioni sistem, koji pripada drugoj razvojnoj fazi
informacionih sistema. Javlja se kao odraz potrebe da se menadmentu na adekvatan nain
obezbede neophodne informacije za odluivanje i upravljanje; pre svega, za donoenje
operativnih i taktikih odluka. Oni obezbeuju menadere i druge korisnike informacijama, koje
su im neophodne u svakodnevnom donoenju menaderskih odluka. Proizvode veoma mnogo
razliitih izvetaja koje su menaderi na osnovu istraivanja njihovih informacionih potreba
unapred definisali. Ovi sistemi pretrauju informacije o internim operacijama iz baza podataka i
kontinuirano ih auriraju OLTP sistemima. Oni, takoe, obezbeuju mnogo korisnih podataka i
informacija o relevantnom okruenju organizacije, koji dolaze iz eksternih izvora. Na primer,
menader prodaje moe:
a) koristiti web brauser da bi primio neposredno i u realnom vremenu vizuelne prikaze, na
svojoj radnoj stanici, informacije o prodaji pojedinih proizvoda, razliitim kupcima,
b) pristupiti nedeljnim, mesenim, kvartalnim ili drugim analitikim izvetajima koji
omoguavaju ocenjivanje rezultata prodaje, odnosno, postignua njegovog odeljenja u domenu
prodaje razliitih proizvoda, razliitim kupcima, na razliitim trinim segmentima.
DSS - Pod sistemima podrke odluivanju (DSS) se podrazumevaju interaktivni, na raunarima
zasnovani, informacioni sistemi koji se koriste sofisticiranim modelima anlalize podataka,
modelima odluivanja i specijalizovanim bazama podataka sa svrhom podravanja procesa
polustrukturisanog i nestrukturisanog menaderskog odluivanja (OBrian, 1999, s.61) (Laudon
& Laudon, 2000 s.44). DSS se, s jedne strane, razlikuju od sistema transakcione obrade
podataka, koji su usredsreeni na obradu podataka generisanih poslovnim transakcijama i
operacijama, a s druge strane, od MIS, koji su usredsreeni na obezbeivanje unapred
specifikovanih informacija izvetaja za menadere, koji bi trebalo da pomognu u procesu
preteno strukturisanog donoenja efektivnih upravljakih odluka, dok DSS omoguavaju
menaderima analitiko modelovanje, simulacije, eksploracije moguih alternativa i dr.
(OBrian, 1999, s.61-62). Sistemi podrke odluivanju imaju veu analitiku mo od drugih
sistema, jer se koriste mnotvom sofisticiranih modela analize i mogu saimati ogromne koliine
podataka u formu koju donosioci odluka mogu lako tumaiti i razumeti. Ovi sistemi su tako
oblikovani da se donosioci odluka njima mogu neposredno koristiti, a softver je izrazito
"userfriendly". Sistemi podrke odluivanju se koriste u interaktivnom nainu i na ad hoc osnovi
korisnik moe menjati pretpostavke, postavljati nova pitanja, ukljuivati nove podatake
(Laudon & Laudon, 2000 s.44-45).
EIS - EIS su kategorija informacionih sistema, namenjeni za podrku odluivanju izvrnim
menaderima, odnosno, vrhovnom menadmentu organizacije, mahom da bi zadovoljavali

strategijske informacione potrebe. Uzimaju podatke iz mnogih izvora, agregiraju ih,

kompariraju, analiziraju raznovrsnim analitikim postupcima i vre njihovu vizualizaciju prema
zahtevima menadera. Obezbeuju selektivno, brzo i lako razumljive informacije o kljunim
faktorima koji su kritini za postizanje strategijskih ciljeva organizacije. Mnogi ih smatraju
podskupom DSS.
Ovi glavni tipovi informacionih sistema na razliitim organizacionim nivoima meusobno
razmenjuju podatke a pri tom je sistem transakcione obrade podataka osnovni izvor za ostale
informacione sisteme. Sve je izrazitija potreba za odjedinjavanjem, integrisanjem razliitih
tipova informacionih sistema u organizaciji i sve je uoljiviji holistiki pristup organizaciji I
njenim informacionim sistemima.
1.5 Integracija informacionih sistema
Informacioni sistem organizacije treba da je integralan, da integrie sve funkcije, procese i sve
vrste informacionih sistema. Integracija se postie, pre svega, kroz kompozitni ili cross/function
sistem, koji daje potporu svim poslovnim funkcijama, procesima, aktivnostima, operacijama i
podrava odluivanje svih nivoa menadmenta i koji ima integrisane informacione resurse koje
koriste sve aplikacije i korisnici. Mnogi autori smatraju da MIS ukljuuje sve navedene vrste
informacionih sistema. Meutim, prema nekim shvatanjima (McLeod, 1990; Laudon & Laudon,
2000), sve navedene osnovne vrste IS i oblasti primene IT predstavljaju doista jedan celoviti
sistem - informacioni sistem zasnovan na raunaru (Computer-Based Information System CBIS). CBIS se u tom kontekstu koristi kao "kiobran" za sve vrste informacionih sistema
podravanih informatikim tehnologijama.

1.2 Informacioni sistem: klasifikacija

Tekst dat u posebnom fajlu (Turban_IS.pdf)

1.3 Nain obezbeenja informacionog sistema

Razvoj informacionog sistema u organizaciji sa sopstvenim resursima odnosno zaposlenim
specijalistima za informacione sisteme, je najee koriena strategija u razvoju informacionog
sistema. I pored toga, ona se mora prilikom svakog opredeljenja detaljno razmotriti iz razliitih uglova i
aspekata, kao jedna od moguih alternativa, jer je veoma esto neizvodiva. Razlozi zbog kojih se i druge
strategije obezbeenja informacionog sistema moraju uzeti u razmatranje su sledei:
a. Broj specijalista za informacione sisteme u organizaciji, koji se moe angaovati u razvoju
informacionog sistema, je uobiajeno nedovoljan da bi im se poverio celovit proces razvoja. ak i
kada je njihov broj dovoljan, veina je previe uposlena na odravanju postojeeg sistema ili
pruanju pomoi korisnicima u reavanju njihovih svakodnevnih problema. Stoga se u razvoju
informacionog sistema sopstvenim resursima angauje i vei broj specijalista iz okruenja, meutim
oni znaajno poskupljuju proces razvoja.
b. Specijalisti za informacione sisteme u organizaciji veoma esto ne poseduju neophodna znanja i
vetine potrebne za razvoj odreenog tipa informacionog sistema. Naravno da se u okruenju mogu

pronai specijalisti sa odgovarajuim u organizaciji nedostajuim znanjima i vetinama, ali ovo

reenje takoe znaajno poveava trokove razvoja.
c. Specijalisti za informacione sisteme u organizaciji su prezaposleni i nemaju dovoljno vremena da
razviju sve komponente sistema koji se u organizaciji zahtevaju. Stoga se komponente rangiraju i
utvruje im se prioritet jer uobiajeno nisu sve od stratekog znaaja sa efektima na celu
organizaciju, ve mogu biti od minorne koristi i sa efektima na organizacioni deo ili samo deo
zaposlenih u organizacionom delu. Reenje u ovakvim kompleksnim situacijama bi morao dati
rukovodilac organizacione jedinice za informacione sisteme, vodei pri tome rauna da se svi
korisnici informacionog sistema podjednako podre, ak i kada se veina specijalista angauje na
komponentama sistema sa najviim prioritetom.
d. Razvoj informacionog sistema je proces veoma visokog stepena rizika. Promenljivi korisniki
zahtevi, razvoj i uvoenje novih tehnologija, ogranienja budeta i fluktuacija zaposlenih su samo
neki od razloga mogueg neuspeha. Istovremeno, veoma je teko predvideti bliu ili dalju
budunost procesa i njegovih rezultata, odnosno kako e sistem izgledati ili bi mogao da izgleda na
zavretku procesa.
Alternative razvoju informacionog sistema sopstvenim resursima mogu biti: obezbeenje gotovog
reenja informacionog sistema izvan organizacije, "outsourcing" i razvoj informacionog sistema od
strane korisnika (korisniki razvoj).
Kupovina gotovog postojeeg reenja informacionog sistema od dobavljaa predstavlja alternativu
obezbeenja reenja informacionog sistema izvan organizacije. Realizacija ove alternative
podrazumeva prethodnu analizu finansijskih sredstava koja e se za ovu namenu utroiti i zahteva koji e
se kupovinom zadovoljiti. Ukoliko je prethodna analiza detaljnija i sadrajnija, ona znaajno pomae u
smanjivanju potencijalnog broja moguih opcija za nabavku, a time i skraenju vremena potrebnog za
izbor. Naime, uporeenjem ponuenih reenja informacionog sistema na tritu sa identifikovanim
zahtevima organizacije, omoguuje se izbor onog reenja koje od svih moguih najvie i najbolje
zadovoljava potrebe. Sigurno je veliki broj postojeih reenja koja mogu kvalitetno zadovoljiti
identifikovane zahteve organizacije, pa je evaluacija neophodna. Veoma esto se koriste i test
mogunosti da bi se informacioni sistem proverio u neposrednom okruenju organizacije, kao i da bi se
videla reakcija potencijalnih korisnika na budui sistem. Tako se na najbolji nain ocenjuje obim
zadovoljenja zahteva organizacije i smanjuje rizik uvoenja odabranog sistema.
Postupak u obezbeenju gotovog reenja informacionog sistema izvan organizacije se realizuje putem
nekoliko koraka. Najee, to su sledei koraci koji se izvode kako bi organizacija obezbedila najbolje
reenje po najnioj ceni:

Identifikacija, selekcija i planiranje sistema

Analiza sistema

Razvoj "request for proposal" (zahtev za ponudom)

Vrednovanje ponuda

Izbor dobavljaa
Prva dva koraka su identina i nezavisna od toga da li se informacioni sistem razvija sopstvenim
resursima ili se obezbeuje kao gotovo reenje izvan organizacija. Tek u treem koraku se dve strategije
odnosno alternative razlikuju.
Razvoj zahteva za ponudom ili predlogom je izvetaj kojim se dobavljau od strane organizacije
saoptavaju zahtevi i trae od njega informacije na koji nain e postavljene zahteve zadovoljiti. Zahtev

se dostavlja svim potencijalnim dobavljaima koji bi mogli biti isporuioci informacionog sistema. Sadraj
zahteva za ponudom ine: pregled i opti prikaz postojeeg sistema i aplikacija; zahtevi u pogledu
pouzdanosti, zatite i servisa; zahtevi u pogledu performansi i karakteristika sistema; pregled kriterijuma
na osnovu kojih e se izvriti vrednovanje ponuda; vremenska ogranienja budeta. Nakon to se zahtev
prosledi, povratno moe uslediti veliki broj ponuda dobavljaa koje treba evaluirati ili mali broj ponuda
pa je potrebno ponovno analizirati zahteve. Uobiajeno su zahtevi mnogo vei nego to su raspoloiva
sredstva (budeta) za njihovo zadovoljenje ili su vremenski rokovi jako ogranieni (kratki) pa ih je
potrebno revidirati.
Vrednovanje (Ocena) ponuda je etvrti korak u kojem se detaljno analiziraju elementi ponude svakog
dobavljaa. Ocena moe ukljuivati prikaz (demonstraciju) sistema, ocenu njegovih performansi,
ispitivanje kriterijuma znaajnih za organizaciju i odluivanje (prosuivanje) koliko ponueni sistem
zadovoljava kriterijume. Prikaz sistema je pogodan nain da se osete pogodnosti koje pojedini sistemi
pruaju. lanovi tima dobavljaa, prikazuju osobine sistema, trokove i nain njegovog funkcionisanja.
Prezentacija se moe odvijati u organizaciji ili kod dobavljaa odnosno neposredno nekog od korisnika
njegovog sistema. Prezentacija je korisna i pomae da se razumeju karakteristike razliitih sistema, ali je
nedovoljna da bi se izvrilo konano opredeljenje. Tako se najee izvodi benchmarking-a, koji
predstavlja upotrebu standardizovanog testa performansi u komparaciji sistema. Komparira se brzina
izraunavanja, brzina pristupa podacima u bazi podataka unapred definisanog broja korisnika, vreme
sortiranja, vreme pretraivanja, vreme izrade datog izvetaja, vreme itanja seta podataka i dr. Ovi
podaci se mogu pronai i u popularnim asopisima iz ove oblasti kao i web stranama udruenja. Konano
u upotrebi su i prethodno pominjani i posebno definisani kriterijumi koji se odnose na hardver, softver i
ostalo.
Izbor dobavljaa je poslednji korak u procesu obezbeenja gotovog reenja informacionog sistema izvan
organizacije. Uobiajeno, vie informacionih sistema zadovoljava postavljene zahteve, stim da neki to
ine bolje, dok drugi slabije. Upravo zbog toga se definie nain njihovog rangiranja. Najei oblik je
putem unapred definisanih kriterijuma, kojima se veliinom njihove apsolutne vrednosti daje
odgovarajui znaaj u rangiranju. U prikazanom primeru na slici 9.25 iz 70572 se vidi da je najbolji
informacioni sistem za organizaciju onaj koji ima najveu sumu dobijenih vrednosti po pojedinim
kriterijumima. Prikazani proces izbora dobavljaa je potpuno formalizovani proces, mada se u praksi
primenjuju i manje formalizovani (kontrolni popis ili checklist) ak i potpuno subjektivni procesi izbora.
"Outsourcing" je druga alternativa obezbeenja gotovog reenja informacionog sistema izvan
organizacije. Prethodno opisanom alternativom, organizacija se opredeljuje i kupuje jedan sistem od
dobavljaa. Meutim, "outsourcing" je praksa kojom se prenosi odgovornost za razvoj celog sistema ili
samo njegovih komponenti na spoljnu organizaciju. To je nain korienja usluga spoljne organizacije u
razvoju informacionog sistema umesto angaovanja sopstvenih resursa. Spoljna organizacija moe razviti
ceo ili komponente informacionog sistema i instalirati ih na svoj raunar ili na raunar organizacije
naruioca. Danas je ovaj vid obezbeenja informacionog sistema veoma popularan, a zasniva se na
ugovornom odnosu kojim se preciziraju svi neophodni detalji ugovorenih usluga.
Za ovo reenje se organizacije opredeljuju jer im je nepraktino i neekonomino da se u razvoju
informacionog sistema oslonjaju uglavnom na sopstvene resurse, obzirom na tekoe koje se uestalo
javljuju kod zapoljavanja veeg broja angaovanih na projektu nakon implementacije informacionog
sistema. Alternativa outsourcing-u je zajedniko izvrenje aktivnosti razvoja u kojem uestvuju pored
zaposlenih iz spoljne organizacije i zaposleni specijalisti za informacione sisteme iz organizacije naruioca
odnosno interno osoblje.

"Outsourcing" se koristi iz sledeih razloga:

Spoljna organizacija je specijalizovana da prui odabrane usluge vieg nivoa kvaliteta uz nie trokove
od internog osoblja.

Spoljne organizacije su uobiajeno veoma mone organizacije koje lako pridobijaju rukovodioca
organizacione jedinice za informacione sisteme da im prepusti razvoj pojedinih ili svih funkcionalnosti
informacionog sistema.

Interno osoblje ne poseduje fleksibilnost i strunost kako bi pratilo uestale promene na tritu i
implementiralo reenja koja zahtevaju nove i jo nedovoljno ispitane tehnologije;

Spoljna organizacija moe da zadovolji potrebe organizacije naruioca na vreme i na zahtevani nain;

Spoljna organizacija moe obezbediti usluge konzistentne sa zahtevima organizacije naruioca;

Politiki i organizacioni problemi, koji su teki za premoavanje od specijalista za informacione
sisteme u organizaciji, se lako reavaju u "outsourcing"-u.

Tenzije izmeu krajnjih korisnika i specijalista za informacione sisteme se znaajno smanjuju ili ak
eliminiu, prebacujui razvoj na spoljnu organizaciju, ali se javlja novi antagonizam krajnjih korisnika i
isporuilaca usluga razvoja informacionog sistema.

Orijentacija na "outsourcing" usluge omoguuje organizacijama naruiocima da se fokusiraju samo na
osnovnu delatnost u poslovanju.
Postoji vie potencijalnih podruja za outsourcing usluga u razvoju informacionog sistema. Njihov
obim se kree od kompletnog outsourcing-a razvoja svih funkcionalnosti sistema do outsourcing-a
komponenti sistema, to zavisi od zahteva organizacije naruioca. U nastavku se navode funkcije koje
mogu biti realizovane sa internim osobljem u odnosu na one koje mogu biti realizovane putem
outsourcing-a.
a) Funkcije koje se realizuju putem internog osoblja:

Koordinacija projekta izmeu naruioca i outsourcing isporuioca;

Obezbeenje kvaliteta kroz ivotni ciklus razvoja sistema;

Definisanje funkcionalnih zahteva;

Razvoj logikog dizajna za aplikacije;

Upravljanje outsourcing isporuiocima.
b) Funkcije koje se realizuju putem outsourcing isporuioca:

Izgradnja sistema;

Implementacija sistema;

Testiranje aplikacija;

Obuka za korienje aplikacija;

Izrada sistemske i korisnike dokumentacije;

Odravanje i unapreenje sistema;

Integracija sistema.
Ako se ispravno planira i upravlja uslugama, outsourcing nudi brojne prednosti naruiocu:

Trokovi usluga mogu biti predvieni i fiksni tokom odreenog vremenskog perioda. Outsourcing
usluge mogu biti unapred precizno definisane i merene.

Naruilac usluga ima mogunost da se fokusira samo na osnovnu delatnost poslovanja. Za potrebe
upravljanja zahtevima informacionih sistema se posebno angauje isporuilac usluga, koji treba da
omogui da se performanse i nivoi usluga obezbede pravovremeno i na trokovno efektivan nain.

Nivoi usluga se mogu kontrolisati na regularnim osnovama.


Ako se radno optereenje poveava nije neophodno poveanje broja zaposlenih. Spoljna organizacija
obezbeuje fleksibilnost organizaciji naruiocu da izvede dodatni rad ako postoji poveana poslovna
aktivnost. Partnerski pristup sa isporuiocem outsourcing-a obezbeuje mogunost prenoenja
vika radnog optereenja, ako postoji prihvatljiv nivo usluga po konkurentnoj ceni.

Ugovorene usluge mogu se esto proveravati, npr. svake ili svake druge godine. Po isteku ugovora sa
spoljnom organizacijom vri se analiza dobijenih usluga. Trajanje ugovora zavisi od vie faktora (tip
usluge, trokovi i rizik koji su povezani sa promenom spoljne organizacije, pouzdanost spoljne
organizacije u pogledu ispunjenja obaveza).

Obraun usluga moe biti direktno povezan sa njihovim performansama i nivoima. Neprihvatljive
performanse trebale bi biti predmet novanog kanjavanja. Spoljna organizacija treba da obezbedi
usluge po trinoj ceni. Kako su usluge odreene i merljive, vano je da se njihovi nivoi prate i da se o
njima dobija izvetaj. Tipine mere nivoa usluge su: blagovremenost, dostupnost, vreme odziva i
kvalitet.

(1) Blagovremenost - Ako se ugovorom o odravanju zahteva da se usluga izvri u roku od etiri sata
od momenta prijavljivanja, onda ova aktivnost moe biti merena i o njoj izraen izvetaj. Ukoliko
nivo usluge nije zadovoljen, mogu biti odreene novane kazne.
(2) Dostupnost Ako se ugovorom zahteva da usluge isporuioca budu raspoloive 24 asa na dan, 7
dana u sedmici onda dostupnost moe biti merena i praena. U sluaju neispunjenja usluge
aktiviraju se novane kazne.
(3) Vreme odziva - Ovo je takoe znaajna mera za odreivanje efikasnosti usluga i treba biti sastavni
deo ugovora. Mogue ju je izmeriti i pratiti.
(4) Kvalitet - Mada je teko izmeriti nivo kvaliteta usluge, on se odreuje na osnovu iskustva korisnika.
Kvalitet ukljuuje: odgovornost i obim ispunjenja zahteva, sposobnost ispunjenja dogovorenih
vremenskih rokova, pripremljenost korisnika za promene pre nego to se softversko reenje
implementira, nivo iztestiranosti proizvoda pre uvoenja, obezbeenost podrke putem servisa za
reavanje problema itd. Kvalitet usluge se moe izmeriti anketiranjem, npr. jednom godinje treba
odrediti neko podruje problema i omoguiti da se o njemu vodi rasprava.
Nedostaci "outsourcing"-a se sistematizuju na sledei nain:

Trokovi outsourcing-a se poveavaju kroz dui vremenski period ako spoljna organizacija u
odreenom momentu potrai dodatne prihode.

Spoljna organizacija moe zahtevati dodatna sredstva za ispunjenje zahteva koji nisu predvieni
ugovorom.

Moe se stvoriti problem prilikom prenoenja znanja sa spoljne organizacije na korisnika, a to se
najee deava kada spoljna organizacija nije kooperativna.

Mogu nastati tekoe u merenju i upravljanju kvalitetom.

Sa veim obimom posla koji se prenosi na spoljnu organizaciju poveava se mogunost da neki od
interesantnijih poslova bude otuen, a to moe uticati na pad morala zaposlenih u organizaciji
naruiocu.

Spoljna organizacija moe zadrati kontrolu iznad odreenog nivoa i kvaliteta usluga.

Pojavljuje se vei rizik u realizaciji, ukoliko doe do promena u spoljnoj organizaciji.

Kada organizacija naruilac odlui da promeni spoljnu organizaciju tada ista podie cene svojih usluga
(cena konverzije i migracije, cena obuke, cena koordinacije i dr.).
Trea alternativa obezbeenja informacionog sistema je razvoj informacionog sistema od strane
korisnika (korisniki razvoj). To je poslednja alternativa, u kojoj korisnici samostalno razvijaju aplikacije

koje e sami koristiti. Pri ovoj alternativi, specijalisti za informacione sisteme u organizaciji, pomau i
ubrzavaju takav razvoj. Ovakav razvoj, poseduje prednosti ali i nedostatke.
Prednosti korisnikog razvoja su:

Trokovi radne snage se sniavaju, ukoliko se korisnicima prue sredstva koja su im potrebna i sa
kojima oni samostalno obavljaju aktivnosti razvoja, uz eventualna uputstva i usluge organizacionog
dela za informacione sisteme.

Vremenski period razvoja se skrauje, posebno zbog toga to se uoeni problemi tokom razvoja
reavaju mnogo bre jer ih uoava i otklanja ista osoba korisnik.

Odravanje postojeeg sistema je pojednostavljeno i bre. Naime, razvoj uvek ima prioritet u odnosu
na odravanje, tako da se esto sistem koristi na takav nain da ne zadovoljava korisnike potrebe.
Preputanjem odravanja korisniku, on je vie zainteresovan i prioritet su mu aplikacije koje
neposredno upotrebljava da odrava u stanju potrebnom za poslovanje.

Poveava se broj onih koji uestvuju u razvoju informacionog sistema, a na taj nain smanjuje njihov
obim angaovanja. Ova konstatacija se posebno odnosi i na zauzetost specijalista za razvoj
informacionog sistema.
Sigurno da je ova alternativa razvoja sistema posebno dobila na znaaju od pojave jezika etvrte
generacije. Ipak, uz brojne prednosti, treba naznaiti i neke nedostatke. Meu prvima je problem
primene standarda u razvoju, koje specijalisti nalau, a koje veina krajnjih korisnika zanemaruje ili o
njima ne vodi brigu. Odsustvo standarda samo po sebi nije problem dok se pojedine aplikacije ne pokau
nesigurne sa aspekta podataka, kada se ispoljava problem. Takoe, nedostatak kontinuiteta u razvoju,
moe predstavljati nedostatak ove alternative razvoja. U razliitim delovima organizacije, mogu biti
razvijene sline ili iste aplikacije, razliitog nivoa sloenosti za obavljanje istih ili slinih poslova. Da bi se
ovaj problem sveo na najniu moguu meru, u organizacijama se formiraju informacioni centri koji
koordiniraju ovakav korisniki razvoj informacionog sistema.

2. Proces razvoja informacionih sistema

Proces razvoja informacionih sistema ini ureeni skup zadataka odnosno niz koraka koji ukljuuju
aktivnosti, ogranienja i resurse u razvoju informacionih sistema. To je kompleksan i kreativan proces
koji je zasnovan na razvojnim principima, a uobiajeno ukljuuje metode, tehnike i sredstva. Takoe,
proces poseduje odreene karakteristike, od kojih je bitno istai sledee:

proces propisuje sve glavne aktivnosti razvoja,

proces koristi resurse koji su uvek na odreeni nain ogranieni i rezultira meuproizvodima i
gotovim proizvodima,

proces moe da se sastoji od meusobno povezanih potprocesa, koji mogu biti u hijerarhiji,

aktivnosti procesa poseduju uslove za pokretanje i terminiranje, kao i uputstva koja objanjavaju
ciljeve i nain njihovog izvravanja,

aktivnosti su organizovane u sekvence, tako da je jasno kada se jedna aktivnost izvrava u odnosu
na drugu,

procesi poseduju ogranienja i kontrole koje se primenjuju na aktivnosti, resurse ili proizvod.

Procesi omoguavaju strukturisanje i konzistentno predstavljanje aktivnosti. Njihovo postojanje je

viestruko znaajno, jer omoguuje da se jednom dobro izvrene aktivnosti u razvoju ponove
neogranieni broj puta, kao i da se pozitivna i negativna iskustva u izvrenju aktivnosti evidentiraju radi
izmene ve primenjenih procesa u budunosti. Proces je sloeniji pojam od procedure, koja je ustvari
recept ili ureeni nain kombinovanja metoda, tehnika i alata u cilju izrade proizvoda. Proces je ureeni
skup procedura, organizovanih da bi se njihovom realizacijom dobio proizvod unapred postavljenih
ciljeva i standarda. Proces moe sugerisati izbor izmeu vie razliitih procedura, sve dok se njihovom
realizacijom moe ostvariti postavljeni cilj.
Koristei se analogijom sa ivim organizmima smatra se da informacioni sistemi nastaju, rastu, sazrevaju
i nestaju, pa se taj proces naziva izrazom "ivotni ciklus sistema", koji u pojedinim sluajevima moe
trajati samo nekoliko meseci, a u drugim nekoliko godina.
Procesi izrade nekog proizvoda, pa i softvera kao jedne od komponenti strukture informacionog sistema,
se nazivaju ivotni ciklus razvoja softvera jer opisuje njegov "ivot" od planiranja, analize, projektovanja
(dizajna), implementacije do odravanja.
Proces razvoja informacionih sistema mogao bi se uopteno opisati putem sledeih faza odnosno
aktivnosti:
 Identifikacija i izbor projekata
 Inicijalizacija i planiranje projekta
 Analiza sistema
 Projektovanje / Dizajn sistema
 Implementacija sistema
 Odravanje sistema

Identifikacija i izbor potencijalnih projekata Izvor potencijalnih projekata su: pojedinci koji
upravljaju poslovnim podrujima ili organizacionim delovima, pojedinci specijalisti i grupe za
planiranje. Putem razliitih metoda i tehnika se pokuavaju identifikovati potencijalni projekti
znaajni za razvoj u organizaciji. Pri tome, nekonzistentni projekti sa optim organizacionim
ciljevima i projekti redundantni po funkcionalnosti se odmah odbacuju. Sigurno da se na ovaj nain
identifikuje veliki broj potencijalnih projekata, od kojih bi trebalo odabrati one koji e se
realizovati. Da bi izbor bio kvalitetan, neophodno je projekte klasifikovati i rangirati. Prilikom
klasifikacije i rangiranja upotrebljavaju se brojni kriterijumi: potencijalna korist, raspoloivost
resursa, veliina i vreme trajanja projekta, potencijalni rizik, strateka usklaenost, organizaciono
okruenje i dr. Po obavljenoj aktivnosti projekti se prihvataju, odbacuju ili uslovno prihvataju sa
obavezom da se dorade.

Inicijalizacija i planiranje projekta Najznaajnije aktivnosti inicijalizacije su: izgradnja projektnog
tima, izgradnja plana projekta, izgradnja upravljakih procedura, izgradnja okruenja za upravljanje
projektom. Planiranje projekta pak podrazumeva: opis podruja projekta, alternativa, izvodljivosti,
strukturiranje na zadatke koji se mogu izvesti, procena potrebnih resursa, razvoj programa, razvoj
plana komunikacija, identifikovanje i procena rizika, postavljanje osnovnog plana projekta i dr. U
ovoj fazi razvoja se generie najoptiji pogled na osnovnu strukturu eljenog projekta razvoja
softvera i odreuju njegovi najoptiji ciljevi, koji e posluiti za definisanje informacionih zahteva u
narednoj fazi. Ocenjuje se izvodljivost i rizici na projektu. Studija izvodljivosti slui da se projekat

prezentira top menadmentu, kako bi se pridobila njihova naklonost u realizaciji odnosno

finansiranju. Projekti se tipino ocenjuju sa aspekta ekonomske, operativne i tehnike izvodljivosti.
Planiranje projekta razvoja takoe slui da bi se lake pratila njegova realizacija i ocenila uspenost
izvrenja pojedinih aktivnosti projektantskog tima. Rezultati faze su: plan upravljanja
konfiguracijom softvera, plan obezbeenja kvaliteta softvera i plan projekta sa detaljnim spiskom
aktivnosti (programom).

Analiza sistema: Ovom fazom se u planu definisani ciljevi razvoja prevode u jedan ili vie
korisnikih zahteva. Na taj nain se definiu glavne funkcije buduih softverskih aplikacija,
operativna podruja podataka i inicijalni entiteti podataka. Glavne funkcije ukljuuju kritine
procese poslovnog sistema, kritine inpute, outpute i izvetaje koje je neophodno obezbediti. Pre
svega se raznim dijagramima analizira postojee stanje po delovima (segmentima) sistema. Analiza
i definisanje zahteva je faza u kojoj se identifikuju problemi koje je potrebno reiti novim
softverskim proizvodom. Aktivnosti u ovoj fazi su: identifikacija zahteva, analiza i predstavljanje
zahteva i razvoj kriterijuma i procedura za prihvatanje novog softverskog proizvoda. Posebno je
bitno istai neophodnost uea buduih korisnika u konanom definisanju zahteva. Rezultati ove
faze su: dokumenat (specifikacija) zahteva koji sadri kompletne i detaljne opise svih zahteva
softveru, matrica povezanosti dokumenata koja prethode i koja slede u realizaciji zahteva
Requirements Traceability matrix (RTM) i auriran plan projekta.

Dizajn sistema: U ovoj fazi se na osnovu identifikovanih zahteva i specifikacije funkcija struktuira
softverski proizvod na takve delove kojima se moe upravljati, a koji predstavljaju logike celine.
Za svaki identifikovani zahtev u dokumentu (specifikaciji) zahteva se projektuje niz elemenata
dizajna. Oni detaljno opisuju osobine budueg informacionog sistema: funkcije, operacije, ulazne
ekranske forme, bazu podataka, izlaze, procesna pravila ili procedure putem kojih se potrebni ulazi
podataka transformiu u zahtevane izlaze i dr. Tako se dobija detaljan opis softvera za novi
informacioni sistem, kao kolekcija podsistema i modula. Takoe, definiu se meusobne veze
izmeu delova strukture i resursi interfejsa izmeu modula sistema na nain koristan za njihov
detaljni dizajn i upravljanje celokupnom konfiguracijom. Elementi dizajna imaju za cilj da opiu
softver dovoljno detaljno da bi se isti mogao razviti bez posebnih napora u narednim fazama
razvoja. Rezultati ove faze su: dokumenat dizajna (specifikacija dizajna) koji sainjavaju prikaz
arhitekture sistema, specifikacija softvera, specifikacija interfejsa, specifikacija komponenti,
specifikacija strukture podataka, specifikacija programskih procedura ili algoritama, aurirana
matrica povezanosti dokumenata koja prethode i koja slede u realizaciji zahteva Requirements
Traceability matrix (RTM) i auriran plan projekta.

Implementacija sistema: U ovoj fazi se na osnovu definisanog dokumenta dizajna u kojem su
detaljno opisani elementi dizajna, izgrauju (proizvode, razvijaju) za svaki od elemenata, niz od
jednog ili vie artifakata budueg softvera. Drugim reima programiraju se dizajnirane programske
procedure obrade. Takoe, za svaki niz funkcionalnosti budueg softvera se razvijaju test sluajevi
i odgovarajui sistem pomoi (help system) korisnicima u njihovoj interakciji sa sistemom. Svaki
razvijeni artifact je povezan sa odreenim elementom dizajna i svaki od njih ima jedan ili vie
korespondentnih test sluajeva. Rezultati ovih aktivnosti faze su: potpuno funkcionalan softverski
proizvod, koji zadovoljava korisnike zahteve i dokumentom definisane elemente dizajna. Pored
toga, rezultat predstavlja i online sistem pomoi korisnicima, sa detaljnim opisom svih operacija u
softverskom proizvodu; implementaciona mapa koja identifikuje primary code entry points for all
major system functions, plan testiranja koji opisuje sve test sluajeve koje je neophodno koristiti
da bi se ocenila korektnost i kompletnost proizvoda; aurirana matrica povezanosti dokumenata

koja prethode i koja slede u realizaciji zahteva Requirements Traceability matrix (RTM) i auriran
plan projekta.

Tokom faze implementacije, obavlja se testiranje i integracija, kao drugi niz aktivnosti ove faze.
Artifakti softvera, online sistem pomoi korisnicima i test podaci se iz razvojnog okruenja prenose
u test okruenje. Svi test sluajevi se aktiviraju da bi se proverila korektnost i kompletnost
softverskog proizvoda. Testiraju se pojedinano razvijeni segmenti i njihove logike celine, kao i
prihvatljivost softvera od strane korisnika. Uspeno izvrenje testa potvruje robustnost i
mogunost potpune migracije na novi softverski proizvod. U ovoj fazi se afirmie i odrava
celokupna integralnost komponenti softvera putem verifikacije konzistentnosti i kompletnosti
uvedenih podsistema i modula, verifikuje se interfejs i veza razvijenih segmenata informacionog
sistema sa specifikacijama, uporeuju performanse sistema, podsistema i modula sa zahtevima.
Vri se obuka korisnika koja e uz pripremljena uputstva odnosno sistem pomoi obezbediti
korisnicima razumevanje mogunosti i ogranienja u cilju efektivne upotrebe sistema. Rezultati
ovih aktivnosti faze implementacije su: integrisani softverski proizvod, online sistem pomoi
korisnicima, implementaciona mapa, plan uvoenja u proizvodnju (produkciju) koji referencira
izvorni kod, opisuje standarde i konvencije kodiranja, kao i izvrne procese, bazu podataka i njene
tabele, plan prihvatanja koji sadri konaan skup test sluajeva i auriran plan projekta.

Poslednja grupa aktivnosti faze implementacije je instalisanje i prihvatanje. Ovo je finalna grupa
aktivnosti faze razvoja inicijalnog softverskog proizvoda, u kojoj se isti stavlja u produkciju i poinje
koristiti u aktuelnom poslovanju. Svi proizvodi dobijeni (proizvedeni) u procesu razvoja softvera artifakti, online sistem pomoi korisnicima, inicijalni podaci za obradu (produkciju) se postavljaju
na produkcioni server. Takoe se svim test sluajevima jo jednom proverava korektnost i
kompletnost proizvoda. Uspean zavretak provere je pretpostavka prihvatljivosti proizvoda od
strane korisnika. Nakon to se korisnik uveri da su rezultati obrade (produkcije) korektni i da su svi
testovi sa zadovoljavajuim rezultatima, on formalno prihvata isporuku softvera. Naravno, u ovom
poslednjem delu faze se proverava sistemska dokumentacija i uputstva za korisnika, obzirom da su
ona po formi pogodna za proveru i kao podrka sistema. Proizvodi ovih aktivnosti faze su: softver
spreman za produkciju, kompletiran test prihvatanja i memorandum o prihvatanju softvera od
strane korisnika. Konano, projekat se zakljuuje, arhiviraju se svi proizvodi dobijeni u procesu
razvoja softverskog proizvoda, implementaciona mapa, izvorni kod i dokumentacija koja je pratila
razvoj proizvoda.

Odravanje sistema: Ova faza u razvoju softvera podrava operacije sistema u ciljnom okruenju
obezbeujui potrebna unapreenja, proirenja, popravke, zamene i dr. Odravanje je stalni
proces koji se realizuje putem iteracija aktivnosti koje mu prethode.

3. Principi i modeli razvoja informacionih sistema

Razvojni principi ili drugim reima paradigme, predstavljaju opte prihvaene naine obavljanja
aktivnosti u razvoju informacionih sistema, koji omoguuju uoptavanje osobina i zakonitosti objektivne
stvarnosti. Osnovni razvojni principi su: princip modelovanja, princip iteracija, princip simulacije, princip
dokumentovanja i dr. To su opte poznati i prihvaeni principi u razliitim podrujima rada, koji se samo i
u razvoju softvera primenjuju.
 Modelovanje - koje podrazumeva izbor modela, rukovanje razliitim nivoima detaljnosti
modela, vezu modela prema stvarnosti, nezavisnost pogleda na celoviti sistem.
 Apstrakcija - kao rezultat modelovanjem steenih rezultata, daje specifikaciju modela koja je
nedvosmislena, razumljiva, jedinstvena, nezavisna od sistema i lako izmenljiva.

 Iteracija - ponovljiv ciklus aktivnosti koji je uzrokovan razliitim razlozima: nemogunost

definisanja informacionih zahteva u jednom prolazu usled nepoznavanja ili stalnog usavravanja
zahteva od korisnika, veliki broj neoekivanih situacija, duina perioda razvoja, potreba za finim
usaglaavanjem, doterivanjem i preciziranjem, podizanje nivoa kvaliteta proizvoda, ....
 Arhitektura - dekomponovanje sloene strukture proizvoda na njegove segmente odnosno
arhitekturu bilo u analizi i dizajnu, bilo u odravanju. Razlozi za strukturiranje su: laka
razumljivost sloenih sistema, jednostavnije organizovanje razvojnog procesa, laka ugradnja
elemenata u celinu sistema, upravljivost kompleksnih i sloenih sistema. Arhitektura izraava:
elemente sistema, njihovu organizaciju, ponaanje strukturnih elemenata, zajedniko ponaanje,
nain meusobne povezanosti, organizovanje u sloenije celine i dr.
 Dokumentovanje - podrazumeva neophodnost istovremene izrade dokumentacije u toku
realizacije pojedinih aktivnosti razvoja. Na taj nain dokumentacija obezbeuje njihovo
nesmetano odvijanje. Dokumentacija doprinosi kvalitetnijoj komunikaciji i razmeni informacija
izmeu svih uesnika razvoja, kao i njihovoj meusobnoj usaglaenosti. Takoe, ona prua
osnovu za kontrolu procesa razvoja. Dokumentacija je jednako potrebna ekspertima u procesu
razvoja informacionog sistema, kao i krajnjim korisnicima budueg sistema. Upravo zbog toga se
proces izrade dokumentacije, sadraj dokumentacije, nain izrade, upravljanja i uvanja
dokumentacije ureuju meunarodnim standardima.

Kao to je ve istaknuto u kratkom opisu ivotnog ciklusa, razvoj informacionih sistema podrazumeva
veliki broj aktivnosti, koje se fazno realizuju. Tokom viefaznog razvoja informacionih sistema, pojedine
aktivnosti se izvravaju na razliite naine u zavisnosti od naina razmiljanja onih koji ih sprovode i
osobina objektnog sistema za koji se informacioni sistem razvija. Posebna se panja posveuje logikom
redosledu realizacije pojedinih faza i aktivnosti, obzirom da se u odreenom toku pojedine aktivnosti
meusobno uslovljavaju, upotrebljavaju rezultate aktivnosti koje im prethode, i semantiki se jedna na
drugu oslanjaju.
Model razvoja je apstraktna (teorijska) predstava procesa razvoja. Svaki model predstavlja proces na
poseban i jedinstven nain, te tako obezbeuje samo delimine informacije o njemu. Modeli razvoja se
meusobno razlikuju po tome koliki znaaj pridaju pojedinim fazama i aktivnostima u razvoju
informacionih sistema, koliko ih detaljno posmatraju i u kojem redosledu ih izvravaju.
Model razvoja se bira u zavisnosti od prirode zadatka odnosno projekta, tehnike orijentacije osoba koje
uestvuju u razvoju, metoda i alata koji se upotrebljavaju pri razvoju, naina kontrole i prirode samog
proizvoda koji se zahteva.
Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki sistemi. Oni pruaju
razliite poglede na proces razvoja informacionih sistema. Osnovni razlog njihove pojave je bila elja da
se obezbedi uoptena ema razvoja informacionih sistema, koja bi sluila kao osnova u planiranju,
organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju aktivnostima razvoja informacionih
sistema. Najee, modeli se strukturiraju na sledei nain:
 Model vodopada,
 Modifikovani model vodopada,
 Inkrementalni model,
 RAD model.

 Model prototipskog razvoja,

 Spiralni model,
 Model zasnovan na komponentama,
 Model unificiranog procesa razvoja (Unified Process)
 Modeli agilnog razvoja (Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic
Systems Development Method (DSDM), Scrum, Feature Driven Development (FDD), Agile Modeling
(AM),
 Kombinovani modeli.

3.1 Model vodopada (Waterfall)

Model vodopada je uveo W. Royce 1970. godine, a naziv je dobio obzirom na tok izvoenja aktivnosti i
nain prenosa rezultata iz jedne faze u drugu, koji podsea na vodopad. Ovaj model razvoja, zahteva
sistematian pristup aktivnostima razvoja koje se realizuju po strogo definisanom sekvencijalnom
redosledu, postepenim prevoenjem rezultata od prve do poslednje faze razvoja. Svaka faza poseduje
taku poetka i taku zavretka, sa poznatim rezultatima za narednu fazu. Veoma esto se naziva i
modelom ivotnog ciklusa razvoja softvera.
Razvoj se odvija putem sledeih faza:

Analiza i specifikacija zahteva - Obzirom da softver predstavlja samo deo nekog sistema, rad na
razvoju proizvoda zapoinje definisanjem zahteva prema svim elementima sistema i alociranjem
jednog dela adekvatnih i odreenih zahteva prema softveru. U ovoj fazi identifikuju se problem i
ciljevi koji se ele postii razvojem proizvoda, zahtevane funkcije, performanse i njihove meusobne
veze. Takoe, identifikuju se potencijalna ogranienja u razvoju. Zahtevi se analiziraju i pregledaju
sa korisnicima i na kraju dokumentuju. Specifikacija zahteva jednoznano i jasno definie funkcije
budueg proizvoda.

Projektovanje Projektovanje ili dizajn proizvoda je faza razvoja, kojom se definie celokupna
arhitektura sistema. Nju ini vie aktivnosti, a koje se fokusiraju na nekoliko aspekata razvoja
softvera: korisniki interfejs, ulazne ekranske forme, izlaze, bazu podataka, procedure obrade i
sistemsku kontrolu. Ova faza prevodi zahteve korisnika definisane u specifikaciji zahteva u odreeni
softverski proizvod koji se moe oceniti sa aspekta kvaliteta pre nego to zapone implementacija.
Kao i u prethodnoj fazi analize i specifikacije zahteva, rezultati projektovanja se detaljno
dokumentuju.

Implementacija Ovom fazom se izvrava zadatak prevoenja rezultata projektovanja u mainski
prepoznatljivu formu. Nju ine aktivnosti programiranja, testiranja, konverzije i obuke korisnika.
Ukoliko je projektovanje uraeno dovoljno detaljno, tada se programiranje obavlja relativno
mehaniki. Testiranjem se proveravaju sve programske jedinice i identifikuju semantike,
sintaksike i algoritamske greke. Istovremeno, utvruje se da li svaka programska jedinica tj.
program zadovoljava specifikovane zahteve.

Integracija - Kada se jednom izgeneriu pojedini programi, oni se moraju integrisati i testirati da bi
se utvrdilo da li sistem kao celina zadovoljava specifikaciju zahteva. Nakon toga, proizvod je
spreman za predaju korisniku na upotrebu.

Funkcionisanje i odravanje Ovo je najdua faza razvoja, tokom koje se proizvod stalno inovira.
Potrebe za izmenama se javljaju iz vie razloga, a najee zbog proirenja funkcija ili performansi

koje zahteva korisnik, zbog potreba da se proizvod prilagoava promenama koje uzrokuje
promenjeno okruenje, zbog razvoja tehnologija koje se upotrebljavaju, zbog ispravki greaka koje
nisu uoene tokom testiranja i zbog unapreenja njegove efikasnost.

Svaka od navedenih faza u modelu poseduje specifinosti, rezultira izvesnim proizvodom i omoguuje
reviziju postignutih rezultata. Aktivnosti faze se izraavaju neophodnim ulazom, procesom i realizovanim
izlazom. Razvoj softverskog proizvoda tako prolazi kroz niz koraka koje su sukcesivne odnosno povezane
kao susedne. Rezultat realizacije svake faze razvoja su njeni konkretni proizvodi i odreena
dokumentacija koji se verifikuju i koji se koriste kao ulazi u sledeu fazu. Prema tome, naredna faza
razvoja uvek moe zapoeti, samo kada je prethodna faza u celosti zavrena i svi njeni proizvodi i
dokumentacija raspoloivi.
U stvarnosti, razvoj nikad nije tako eksplicitno i linearno odreen. Zbog toga razvijeni proizvodi u svakoj
fazi zahtevaju proveru i reviziju pre prihvatanja, kao i odreenu vrstu zamrzavanja rezultata pre prelaska
u narednu fazu, jer naknadne promene rezultata prethodnih faza nisu doputene.
Model vodopada je najstariji model razvoja koji je najvie i najire primenjivan do danas. Uspeno se
kombinuje sa drugim modelima razvoja. Veoma je mnogo kritikovan, ali se ipak zadrao na visokim
pozicijama sa stanovita primene. Model je posebno efikasan u struktuiranju i upravljanju malim
projektima razvoja softvera u organizacijama, kada korisnik jednoznano moe definisati svoje zamisli i
zahteve u odnosu na proizvod i kada se isti tokom razvoja radikalno ne menjaju. Takoe, preporuuje se
prilikom razvoja proizvoda koji je po osnovnim karakteristikama jedinstven i ima zadatak da zadovolji

posebne zahteve korisnika, koji jo do tada nisu realizovani u sistemima drugih organizacija i ne mogu se
ire upotrebiti.
Prednosti modela vodopada su:

strogo definisani i kontrolisani proces, kojeg karakteriu standardizovane i detaljno opisane
aktivnosti u svim fazama razvoja,

ukljueno testiranje odnosno verifikacija izvrenih aktivnosti i dobijenih rezultata na kraju svake
faze razvoja,

detaljna i kvalitetna dokumentacija, koja se generie u svim fazama razvoja, istovremeno kada se
izvravaju pojedine aktivnosti i

relativno laka zamena pojedinih uesnika u procesu razvoja.
Nedostaci modela vodopada su:

nefleksibilna podela aktivnosti razvoja u posebne faze i nedostatak povratne sprege izmeu faza,

greke koje se ne otklone u pojedinim fazama razvoja kada se vri testiranje ili verifikacija
proizvoda, mogu imati stravino distorziono dejstvo na razvoj u celini,

nemogunost obavljanja iteracija tokom realizacije razvoja jer iste izazivaju ozbiljne probleme i
konfuziju u primeni modela,

teka prilagodljivost neizvesnosti koja uglavnom egzistira na startu projekta, kada je korisniku
veoma teko da eksplicitno navede sve svoje zahteve prema softveru,

dugotrajan proces razvoja te korisnik mora biti veoma strpljiv i istrajan jer su mu radne verzije
softvera dostupne tek na kraju aktivnosti razvoja, a do tada postoji samo pisana specifikacija
funkcionalnosti budueg softvera,

samo potpuno gotov proizvod je upotrebljiv od korisnika,

visoki razvojni trokovi.

3.2 Modifikovani model vodopada

Modifikovani model vodopada je razvijen da bi se otklonila dva najvea nedostatka klasinog linearnog
modela vodopada. To je mogunost preklapanja aktivnosti razvoja i realizacija povratne sprege izmeu
faza razvoja. Uvoenjem iteracija, posebno je istaknut znaaj aktivnosti verifikacije i validacije
(vrednovanja) rezultata na zavretku svake od njih. Verifikacijom se proverava da li se razvoj odvija na
pravi nain, dok se vrednovanjem proverava da li je razvoj u skladu sa zahtevima korisnika.
Ovako modifikovani model vodopada, prua mogunost povratka iz bilo koje faze razvoja na bilo koju od
ranije realizovanih faza, i tako onemoguuje prenoenje u bilo kojoj fazi uoenih ozbiljnijih greaka kroz
sve faze razvoja do samog kraja. Greke se permanentno otklanjaju i samo se u retkim sluajevima
prenose.

3.3 Inkrementalni model

Inkrementalni model je nastao kao evolucija modela vodopada i predstavlja kombinaciju klasinog
modela vodopada sa iterativnim mogunostima razvoja. U ovom modelu se prvobitno potpuno razvija
inicijalni podskup funkcija proizvoda, a zatim se sukcesivnim koracima razvijaju, stalno novije i
komplikovanije verzije. Definisanje osnovnih funkcionalnosti proizvoda je potrebno veoma rano i po
mogunosti celovito, dok se njihova realizacija odvija odloeno, putem inkremenata. Analiza proizvoda i
projektovanje njegove opte arhitekture se izvodi u prvom koraku, a detaljno projektovanje,
implementacija, integracija i testiranje softvera se odvijaju sukcesivnom razradom inicijalnog podskupa.
Svakim inkrementom se razvijaju nove funkcionalnosti koje se dodaju ve razvijenom proizvodu, pri
emu se postojee funkcionalnosti zadravaju. Proizvod je razvijen kada zadovolji sve identifikovane
korisnike zahteve odnosno sve funkcionalnosti. Meutim, on je upotrebljiv i nakon razvijenog prvog
inkrementa i bez razvijenih svih ostalih funkcionalnosti. Razvoj se moe prekinuti pri razvoju bilo kojeg
inkrementa bez rizika za njegovu trenutnu upotrebljivost. Inkrementalni model razvoja je posebno
popularan i koristi se u softverskim kuama.
Prednosti inkrementalnog modela su:

obezbeuje transparentan razvoj proizvoda, sa stalno vidljivim razultatima,

uvek raspoloiv funkcionalno upotrebljiv proizvod, koji zadovoljava odreeni podskup korisnikih
zahteva,

lako razumevanje i testiranje novorazvijenih inkremenata proizvoda jer oni samo dodaju nove
funkcionalnosti postojeem upotrebljavanom softveru i na taj nain premoavanje traumatskih
efekata uvoenja kompletno novog proizvoda odjednom,

postojanje povratne sprege i permanentne mogunosti ugradnje bogatog korisnikog iskustva u
redefinisani proizvod na manje skup nain, putem novih inkremenata odnosno novih
funkcionalnosti proizvoda,

umanjeni rizik od neuspeha razvoja celine, jer se problemi uglavnom uoavaju u pojedinim
inkrementima,

skromniji obim kapitalnih ulaganja u razvoj proizvoda i bri povrat investicija,

manji broj angaovanih osoba u procesu razvoja.
Nedostaci inkrementalnog modela su:


dekompozicija proizvoda na inkremente, da bi se oni mogli integrisati, nije trivijalan zadatak, kao
ni sam proces integracije, a da se pri tome ne ugrozi kvalitet ve postojeeg proizvoda,

specifikacija detaljnih korisnikih zahteva se kod svakog inkrementa izrauje neposredno pre nego
to se on razvija,

integracija moe uvek doneti neoekivane probleme i potrebe za reorganizacijom, koja moe imati
posledice po efikasnost i odravanje,

korisnici imaju stalnu elju da menjaju svoje zahteve.
Software
concept
Requirements
Analysis
Architectural
Design
Stage 1: Detailed design, code, debug, test
and delivery
Stage 2: Detailed design, code, debug, test
and delivery
Stage n: Detailed design, code, debug, test
and delivery

Slika : Inkrementalni model

3.4 RAD model

RAD je inkrementalni model procesa razvoja, koji omoguuje da se upotrebljivi proizvod izgradi u
kratkim razvojnim ciklusima, koji traju od 60 do 90 dana. Rezultat svakog ciklusa, odnosno iteracije, je
proizvod odreene funkcionalnosti. RAD modelom se proizvod razvija sa malim i integrisanim timovima
u kojima se pored onih koji neposredno razvijaju proizvod nalaze i korisnici. Mali timovi, kombinovani sa
kratkim iterativnim razvojnim ciklusima, efektivne neformalne komunikacije, jedinstvo vizije i ciljeva,
primarne su karakteristike ovog modela razvoja.
RAD je model u kojem su faze analize, projektovanja odnosno dizajna, implementacije i testiranja
komprimovane (stisnute, saete) u nizove kratkih iterativnih razvojnih ciklusa. Iteracije omoguuju
efektivnost i samokorekciju procesa razvoja. Studije pokazuju da ovek skoro nikad sloene zadatke ne

izvede perfektno u prvom pokuaju. ak naprotiv, nakon solidnog poetka, veoma uspeno izvodi mala i
uestala unapreenja. to znai da je bolje prihvatiti takva iskustva nego se protiv istih boriti.
Razvoj se odvija putem realizacije sledeih koraka:

Modelovanje organizacije faza u kojoj se istrauju ciljevi organizacije, problemi organizacije,
kritini faktori uspenosti i strateke mogunosti. Razmatraju se na zajednikim sednicama
rukovodstva organizacije i projektanata naini usmeravanja organizacije kako bi ona postala
kompetitivnija.

Planiranje zahteva faza u kojoj se analiziraju zahtevi sa obzirom na poslovni sistem. Prouavaju
se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne. Takoe, istrauju se i definiu
informacione potrebe, obim u kojem e se one zadovoljiti i vri analiza opravdanosti razvoja novog
proizvoda.

Dizajn aplikacija faza u kojoj se vri detaljna analiza funkcionalnosti predloenog sistema i
oblikuje sistem koji e potpuno odgovoriti zahtevima. Kljuni korisnici na radnim sastancima, vre
dekompoziciju poslovnih funkcija i definiu tipove entiteta, da bi procese povezali sa podacima.
Nakon toga vri se dizajn kritinih procedura, dizajn preliminarnog izgleda ekranskih formi i
priprema plan implementacije sistema.

Konstrukcija faza u kojoj mali razvojni timovi rade neposredno sa korisnicima na finaliziranju
dizajna i izgradnji proizvoda. Ovu fazu ini serija koraka tokom kojih korisnici imaju prilike da
koriguju svoje zahteve i ispitaju razvijeni proizvod. Proizvod se razvija iterativno i prototipski.
Nakon izgradnje, proizvod se testira, generiu se dokumentacija i uputstva za korienje novog
proizvoda kao i rutine i procedure za stavljanje proizvoda u funkciju.

Implementacija je faza tokom koje se implementira novi proizvod i upravlja prelaskom sa starog
na novi. Uspostavljaju se relacije izmeu starog i novog proizvoda, vri konverzija podataka i
obavlja trening korisnika.
Prednosti RAD modela su:

poveana brzina razvoja proizvoda putem primenjenih metoda prototipskog razvoja,

umanjena funkcionalnost proizvoda za krajnjeg korisnika (proistekla iz suenog fokusa dizajna) i
kao posledica njegova umanjena kompleksnost (sloenost),

vei naglasak na jednostavnost i upotrebljivost dizajna korisnikog interfejsa.
Nedostaci RAD modela su:

umanjena skalabilnost i umanjene karakteristike, kada ovim modelom razvijene softverske
aplikacije startuju kao prototipovi i razvijaju se u gotove aplikacije,

skromnije karakteristike proizvoda, koje su posledica skraenja vremena razvoja, jer se zbog
kratkog vremenskog okvira izrade mnoge karakteristike potiskuju u kasnije verzije,

cena postignutog ubrzanja procesa razvoja, veoma esto je gubitak pregleda nad celinom sistema,

brzina razvoja moe postati svrha sama sebi, pa tada vodi improvizaciji razvoja i izradi samo
prirunih i privremenih reenja,

kod velikih projekata, model zahteva dovoljno resursa za formiranje pravog broja razvojnih
timova,


projekti su bezuspeni, ukoliko ne postoji obaveza razvojnog tima ili korisnika da aktivnosti,
neophodne za kompletiranje sistema, ne realizuju u mnogo kraim vremenskim intervalima,

ukoliko se proizvod nemoe adekvatno modularizovati, izgraene komponente su problematine u
smislu povezivanja.

3.5 Model prototipskog razvoja

Model prototipskog razvoja je iterativan model, u kojem se pored projektanata u razvojnom timu
pojavljuju i korisnici. Upotrebljava se da bi se za potrebe korisnika razvio inicijalni model budueg
proizvoda, koji simulira njegove stvarne funkcije, a sa ciljem da korisnik da svoje miljenje i odlui koji i
kakvi su njegovi zahtevi. Kod razvoja proizvoda po ovom modelu korisnik ve u najranijem periodu moe
videti na koji e se nain zadovoljiti njegovi zahtevi. Najee se razvija samo korisniki interfejs, ija
implementacija obezbeuje povratnu spregu od korisnika.
Ovaj razvojni model obino prihvata neku vrstu funkcionalne specifikacije proizvoda kao ulaz, koja
omoguuje da se aktivnosti dizajna proizvoda inicijalno preskoe. Takoe, omoguuje da se brzo izgrade
njegove primitivne verzije, koje korisnik moe i sam kasnije razvijati. Uee korisnika se ostvaruje
putem povratne sprege u redefinisanju specifikacije zahteva i dizajna.
Model prototipskog razvoja je onaj model razvoja u kojem se prototip inicijalno razvija, testira i kasnije
po potrebi dorauje, dok se ne dobije konano njegova prihvatljiva verzija kao podloga za razvoj celine
proizvoda.

Ovaj model je pogodan kao model razvoja kada se na poetku razvojnog ciklusa ne poznaju potpuno i svi
zahtevi korisnika, ve ih je potrebno sukcesivno saznati. Zatim, kada je mogue izvesti simulaciju rada
proizvoda, kako bi korisnik mogao videti na koji nain e budui proizvod funkcionisati. I kada razvojni
timovi ele proveriti efikasnost ugraenih algoritama ili adaptibilnost proizvoda.

START

Izg
p rad
r
o
tot nja
ipa

nje
isa
n
i
f
de tipa
Re roto
p

i
Brz jn
a
diz

In
i
pro njers
izv ki
od

ST
OP

Prikupljanje i
selektiranje
zahteva

Evaluacija
prototipa od
korisnika

Slika : Model prototipskog razvoja

Model prototipskog razvoja zapoinje prikupljanjem osnovnih zahteva korisnika. Razvojni tim i korisnici,
zajedniki definiu opte ciljeve razvoja proizvoda, identifikuju sve njima poznate zahteve i odreuju
podruja na kojima su obavezne dalje aktivnosti preciznijeg definisanja. Sledi "brzi" dizajn u kojem se
fokusira na realizaciju onih aspekata proizvoda koji e biti vidljivi za korisnika (ulazni i izlazni formati i
dr.). Nakon takvog dizajna, razvija se prototip. On slui da bi se preistili zahtevi prema proizvodu koji se
razvija. Preiavanje je iterativno i odvija se dok prototip ne zadovolji zahteve korisnika i istovremeno
omogui projektantu potpuno razumevanje potreba koje mora zadovoljiti. Idealno, prototipski razvoj i
slui kao mehanizam za identifikovanje korisnikih zahteva. Ukoliko prototip u korisnikoj evaluaciju
zadovolji, prelazi se u zavrnu fazu razvoja konanog proizvoda za upotrebu.
Prednosti primene modela prototipskog razvoja su:

poveana brzina i kreativnost u razvoju,

stalno obezbeene radne verzije proizvoda, koje mogu posluiti za analizu funkcionalnosti,
performantnosti, adaptibilnosti i trokova razvoja,

korisnik je maksimalno angaovan na razvoju, moe permanentno menjati svoje zahteve, to
unapreuje kvalitet celokupnog procesa.
Ovaj model ima i svoje nedostatke odnosno primena modela prototipskog razvoja moe biti diskutabilna
iz vie razloga:


nemogunost kvalitetne i tane procene i planiranja resursa,

korisnik uoava radnu verziju proizvoda neznajui na koji su nain delovi proizvoda meusobno
povezani, neznajui da u brzini realizacije nisu razmatrani aspekti kvaliteta ili odravanja u duem
vremenskom periodu. Kada doe do informacija da je potrebno izvriti "remont" ili dalju
dogradnju jo ne uvedenog proizvoda, korisnik se osea prevarenim i insistira da se putem izvesnih
intervencija brzo realizuje njemu potreban proizvod. Upravljanje razvojem softvera u ovakvim
situacijama postaje nekontrolisano,

projektant esto ini kompromise u implementaciji sa ciljem da izgraeni prototip to pre stavi u
funkciju. Neadekvatan operativni sistem ili programski jezik se jednostavno upotrebljavaju samo
zato to su raspoloivi ili poznati; neefikasan algoritam se primenjuje pak da bi se demonstrirale
pojedine funkcionalnosti proizvoda. Nakon izvesnog vremena, zaboravlja se na nain odabira i
njihove uzroke, te ovako manje idealna reenja ili bolje reeno manje kvalitetna reenja ostaju
integralni deo konanog proizvoda,

velika verovatnoa da se zamena prototipa sa pravim sistemom zavri neuspeno,

dokumentacija, koja nastaje procesom izrade pravog proizvoda, uglavnom retko bude napravljena.
Zbog toga, znaajno je da se projektant i korisnik, u cilju efikasne primene ovog modela, dogovore i
definiu "pravila igre" na poetku procesa razvoja proizvoda. Drugim reima, oni se moraju sloiti da se
prototip razvija kao sredstvo za definisanje zahteva, za prikaz izgleda budueg proizvoda, a nakon toga
se prekida njegov razvoj i razvija pravi proizvod u cilju zadovoljenja kriterijuma kvaliteta i mogunosti
odravanja.

3.6 Spiralni model

Spiralni model je razvijen od. B Boehma 1988. godine, da bi se objedinile dobre osobine modela
vodopada i modela prototipskog razvoja uz istovremeno ukljuivanje aktivnosti analize rizika. Inicijalno
namenjen razvoju velikih, skupih i sloenih projekata.
Model se predstavlja spiralom na kojoj su definisane etiri faze razvoja:

planiranje faza koju ine aktivnosti uspostavljanja efektivne komunikacije projektanata i
korisnika i aktivnosti odreivanja ciljeva, projektnih alternativa i ogranienja u razvoju,

razvoj alternativa i analiza rizika faza koju ine aktivnosti analize alternativa i identifikovanja
tehnikog i menaderskog rizika,

inenjering faza razvoja novih nivoa proizvoda, testiranja i instaliranja uz podrku korisnicima
putem izrade dokumentacije i treninga,

procene korisnika faza procene realizovanih rezultata razvoja i instalacije proizvoda.
Posmatranjem spirale, svakom iteracijom se progresivno razvijaju kompletnije i sloenije verzije
proizvoda. Tokom prvog ciklusa kretanja spiralom, prikupljaju se zahtevi i planira projekat razvoja, da bi
se izvrila analiza rizika inicijalnih zahteva. Ukoliko analiza rizika indicira neizvesnosti u zahtevima, tada
se moe upotrebiti prototipski razvoj da bi se zahtevi detaljnije spoznali. U iste svrhe, mogu se koristiti
simulacija ili druge vrste modela.
Nakon to se donese odluka o daljem razvoju, obavlja se ininjering u svakom ciklusu spirale i to
odabranim modelom razvoja softvera (model vodopada i-ili model prototipskog razvoja). Broj aktivnosti
u inenjeringu raste, ukoliko se ciklusi udaljuju od centra spirale. Istovremeno, aktivnosti su sloenije i
uvek sa mnogo vie detalja i manje apstrakcije.

Kumulativni trokovi

Planiranje

Razvoj alternativa i analiza rizika

Prikupljanje zahteva
i planiranje projekta

Analiza rizika
inicijalnih zahteva
Analiza rizika na
korisnikim reakcijama

Planiranje na korisnikim
komentarima

Donoenje odluke DA - NE
Procene korisnika
Inicijalni prototip
Naredni nivo
Razvijeni sistem

Procene korisnika

Ininjering
(razvoj narednog nivoa proizvoda)

Slika : Spiralni model

Po zavretku svakog ciklusa razvoja, korisnik ocenjuje proizvod i daje sugestije za njegovu modifikaciju.
Zasnovana na korisnikom inputu, inicijalizuje se faza planiranja novog ciklusa razvoja i analiza rizika.
Svaki ciklus razvoja na spirali, zahteva analizu rizika i donoenje odluke "nastaviti" ili "ne nastaviti" sa
daljim razvojem. Ukoliko je rizik isuvie visok i ulaganja nesrazmerno velika u odnosu na efekte koji se
oekuju, terminira se dalji rad i zadrava u upotrebi proizvod nastao u prethodnom ciklusu ili
prethodnim ciklusima. Svaki novozapoeti ciklus spirale donosi kompletniji proizvod, ali i znaajno vie
trokove.
Rezimirajui izloeno treba podvui da model ukljuuje multiplikovane iteracije kroz cikluse, koji
analiziraju rezultate prethodnih faza odreujui procenu rizika za budue faze. U svakoj od faza, razvijaju
se alternative u skladu sa ciljevima i potrebama, koje zajedno ine bazu za sledei ciklus u spirali. Svaki
ciklus se zavrava ocenom. Model podrazumeva da se svaki deo proizvoda ili svaki nivo proizvoda na
istovetan nain provlai kroz ovu spiralu odnosno ocenu.
Osnovna premisa modela je da se odreeni redosled koraka ponavlja u razvoju i odravanju proizvoda.
Koraci se prvo izvravaju sa visokim stepenom apstrakcije, da bi se postepeno prelo na detalje.
Prednosti primene spiralnog modela su:

u kratkom vremenskom intervalu realizacija funkcionalnog proizvoda,

fleksibilnost u upravljanju fazom ininjeringa i mogunost kombinovanja razliitih pristupa u
razvoju proizvoda,

mogunost izvoenja procene rizika u svakom trenutku i nivou apstrakcije, to obezbeuje
pravovremenu reakciju na uoene rizike i primenom prototipskog modela razvoja prua
mehanizam za njihovo smanjenje. Primenom ovog modela rizici se mogu smanjiti pre nego to
izazovu vee probleme i velike trokove.


model podrava sistematski pristup preuzet iz modela vodopada uz mogunost izvoenja iteracija.
Nedostaci primene spiralnog modela su:

odsustvo veze prema postojeim standardima, odnosno ne postojanje standarda za ovaj model
razvoja softverskog proizvoda,

model zahteva vie uniformnosti i konzistentnosti u razvoju,

relativno skup model za primenu u razvoju malih projekata, jer analize rizika zahtevaju specifine
ekspertize,

velike probleme stvara situacija kada se na vreme ili uopte ne otkriju rizici, koji onda proizvode
multiplikativno dejstvo u razvoju,

relativno kratko vreme njegove primene, pa e trebati jo dosta vremena da se sa vie sigurnosti i
verovatnoe prie njegovoj ozbiljnijoj primeni.
Analiza odnosno procena rizika, kao kljuna razlika ovog modela razvoja u odnosu na ostale, je veoma
pozitivna i korisna u procesu razvoja, ali samo kod izgradnje velikih informacionih sistema jer se za njih
vezuju veliki trokovi i kada njeno izvoenje ne predstavlja preveliki relativni troak u odnosu na ukupne
trokove razvoja.

3.7 Model zasnovan na komponentama

Osnovni pristup u ovom modelu je konfigurisati i specijalizirati ve postojee komponente proizvoda u
novi proizvod. Meutim, osobine komponenti zavise od njihove veliine, kompleksnosti i funkcionalnih
mogunosti. Veina pristupa pokuava da iskoristi sline komponente obzirom na zajednike strukture
podataka sa algoritmima za njihovu manipulaciju. Drugi pristupi pokuavaju da iskoriste komponente
funkcionalno slinih kompletnih sistema ili podsistema kao to su korisniki interfejs. Postoje i brojni
naini iskoriavanja softverskih komponenti za razvoj softverskih sistema. Svi ovi pokuaji i nastojanja
zagovaraju inicijalnu upotrebu ve uraenih komponenti u specificiranju strukture ili detaljnom dizajnu
komponenti radi ubrzavanja postupka implementacije. Ove komponente se mogu upotrebiti i pri
prototipskom razvoju proizvoda ukoliko je raspoloiva takva tehnologija.

Model softver
komponenti

Model softver
komponenti

"A"

Komponente softvera
za ponovnu upotrebu

"B"

"C"

Komponente softvera
za ponovnu upotrebu

Model softver
komponenti

Viestruko korienje proizvoda je proces kojim se u novi proizvod ukljuuju pojedine komponente:

prethodno testiranog koda,

prethodno proverenog dizajna,

pretnodno razvijene i koriene specifikacije zahteva i

prethodno korienih procedura za testiranje.
Koristi koje sobom donosi ponovno korienje komponenti razvijenog softvera su sledee:

podie robustnost proizvoda,

poveava produktivnost izrade proizvoda i smanjuje trokove razvoja,

podie kvalitet proizvoda jer su mu komponente viestruko proverene i u vie navrata
unapreene,

tedi odnosno skrauje vreme izrade,

obezbeuje adekvatnu dokumentaciju i lake razumevanje proizvoda,

olakava odravanje proizvoda.

3.8 Model unificiranog procesa razvoja

Model unificiranog procesa (UP) razvoja je u upotrebi od 1999 godine, a njegovi autori su: Ivar Jacobson,
Grady Booch i James Rumbaugh. Ovaj model opisuje razvoj putem upotrebe UML - objedinjenog jezika
za modelovanje, a zasnovan je na iterativnom i inkrementalnom procesu. Model ne predstavlja samo
obian proces, ve promenljivi i prilagodljivi okvir razvoja softvera u razliitim organizacijama i u raznim
projektima.
Model je inicijalno zamiljen za razvoj velikih softverskih projekata, ali je svoju primenu naao i u
srednjim i malim softverskim projektima. Softverski timovi, naroito veliki, znatno unapreuju svoju
produktivnost korienjem ovog modela. UP omoguuje svakom lanu razvojnog tima lak uvid u bazu

znanja, zasnovanu na uputstvima, templejtima i uputstvima za korienje alata, to predstavlja znaajnu

podrku u svim kritinim razvojnim aktivnostima. Istovremeno, omoguuje da svi lanovi razvojnog tima,
bez obzira na aktivnosti koje obavljaju, imaju zajedniku metodologiju, jezik i pogled na proces razvoja.
Ovaj model proces razvoja softvera postavlja izmeu dve dimenzije, vremenske i sadrajne. Vremensku
dimenziju ine etiri faze: inception, elaboration, construction i transition, dok je sadrajna dimenzija
podeljena u est osnovnih i tri pomone discipline. Osnovne discipline su: disciplina poslovnog
modelovanja, disciplina zahteva, disciplina analize i dizajna, disciplina implementacije, disciplina
testiranja i disciplina rasporeivanja. Pomone discipline su: disciplina konfigurisanje i upravljanje
promenama, disciplina upravljanje projektom i disciplina okruenje.
Navedene dve dimenzije se mogu posmatrati i kao: dinamika dimenzija u kojoj se proces opisuje kroz
ivotni ciklus razvoja proizvoda i statika dimenzija u kojoj se opisuju aktivnosti i rezultati aktivnosti
podeljeni na uloge.
Ukoliko se model posmatra putem dinamike strukture, razvoj softvera ine etiri napred navedene
faze. Faze u procesu razvoja se ne izvravaju u jednom prolazu, ve se svaka od njih izvrava u nekoliko
iteracija. Model ne predvia taan broj iteracija. Do tanog broja iteracija po fazama se dolazi prilikom
prilagoavanja modela sopstvenim potrebama, tj. prilikom definisanja konkretnog procesa razvoja.
Svaka iteracija se obavlja modelom ivotnog ciklusa koji ukljuuje faze analize, dizajna, implementacije i
testiranja. Rezultat iteracije je inkrement konanih osobina kvaliteta, proveren i integrisan, kojim se
uveava funkcionalnost softverskog proizvoda, a koji zadovoljava podskup ukupnih zahteva korisnika.
Zavretak svake faze su kljune take u procesu razvoja. Kljune take predviaju, na osnovu izvrene
integracije inkremenata realizovanih u posmatranoj fazi, njene krajnje rezultate.

Disciplines

Faza inception predstavlja prvu i najkrau fazu razvoja. Njen primarni cilj je definisanje obima i granica
projekta, odnosno opravdanje razloga zbog kojih se pokree projekat. Tokom ove faze se definie vizija
sistema, opisuje sistem i prikupljaju najvani zahtevi. Nakon toga se identifikuju kljune funkcionalnosti

sistema i daje predlog najmanje jednog mogueg reenja arhitekture proizvoda. Procenjuju se trokovi,
utvruje preliminarni plan realizacije projekta i identifikuju mogui rizici. Na kraju, razrauje se proces
razvoja i odreuju alati koji e se upotrebljavati u razvoju softverskog proizvoda.
Faza elaboration predstavlja drugu fazu u ivotnom ciklusu razvoja proizvoda. Osnovni zadatak ove faze
jeste uspostavljanje takve arhitekture sistema koja obezbeuje vrste osnove za veinu aktivnosti
dizajna i implementacije koje e biti realizovane u fazi konstrukcije. Takoe, zadatak ove faze je i
identifikovanje kljunih rizika. Identifikuju se rizici vezani za zahteve, rizici vezani za arhitekturu, rizici
vezani za trokove i rizici vezani za sam postupak izvrenja procesa razvoja i za primenu izabranih alata.
Aktivnosti koje se obavljaju u fazi elaboration su: prikupljanje detaljnih korisnikih zahteva; globalna
analiza i dizajn, ustanovljavanje osnovne arhitekture sistema i njena ocena; planiranje konstrukcije sa
izradom detaljnog plana projekta i prorauna trokova; usavravanje razvojnog procesa i razvojnog
okruenja
Fazu construction, kao treu fazu ivotnog ciklusa, ine detaljni dizajn, implementacija i testiranje
sistema. Faza konstrukcije predstavlja najobimniju fazu i u vremenskom rasporedu zauzima preko
polovine ukupnog vremena predvienog za projekat. Meutim, ukoliko su prethodne faze kvalitetno
odraene, rizici za narednu fazu prelaenja su svedeni na minimum. U fazi konstrukcije mogu se izdvojiti
sledee aktivnosti: prikupljanje preostalih ili izmenjenih zahteva; detaljna razrada arhitekture i izrada
sistema; kontinuirana integracija komponenti i testiranje sistema; izrade uputstava i materijala za
trening korisnika, konverzija podataka i dr
Faza transition ima za cilj prenoenje softverskog proizvoda u ruke krajnjih korisnika. U fazi konstrukcije
se u ruke korisnika predaje beta verzija softverskog proizvoda, tako da ova faza poinje sa beta
testiranjem. Kao rezultat beta testiranja dobijaju se povratne informacije od korisnika o prihvatljivosti
proizvoda i njegovom zadovoljstvu. Takoe, podeavaju se performanse proizvoda i vri obuka korisnika.
Model unificiranog procesa razvoja softvera poseduje sve one prednosti i nedostatke, koji se ispoljavaju
kod inkrementalnog modela, stim da dodatno poseduje pozitivne osobine spiralnog modela, jer
podrava iteracije i permanentnu analizu rizika.

3.9 Agilni modeli razvoja

esto probijanje vremenskih rokova i budeta u realizaciji projekata razvoja softverskih proizvoda,
permanentni rast sloenosti tehnologije i uestale promene korisnikih zahteva, doveli su krajem
dvadesetog veka do pojave novih modela razvoja. Nastali su agilni modeli, po osobinama mnogo gipkiji i
prilagodljiviji promenama, koji omoguuju korisnicima aktivno uee tokom svih faza i aktivnosti
razvoja.
Agilni pristup se dakle suoio sa osnovnim problemom savremenog i ujedno brzog razvoja proizvoda.
Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme
i trokove razmene informacija izmeu osoba koje uestvuju u razvoju na nain da skrate vremenski
period od donoenja odluke do povratne informacije o posledici te odluke.
Polazne pretpostavke agilnih modela su bile da je turbulentnim poslovnim i tehnolokim okruenjima
neophodan proces razvoja softvera koji istovremeno kreira promene, ali brzo i odgovara na iste.
Istovremeno, proces koji ukljuuje odgovorne uesnike i njihovu dobru organizaciju. Uesnicima
odnosno njihovom talentu, vetinama i sposobnostima, kao i njihovoj meusobnoj komunikaciji se
poklanja posebna panja. Usmerenost na uesnike je i najznaajnija osobina agilnih modela, prema
pojedincima se prilagoava i kompletan proces razvoja.

U agilnim razvojnim timovima, kompetencije pojedinaca predstavljaju kritian faktor uspenosti

projekta. Prema agilnim modelima, ukoliko su pojedinci na projektu dovoljno kvalitetni, tada oni mogu
uz bilo koji proces razvoja realizovati oekivani cilj. U suprotnom, nema procesa razvoja koji moe
nadomestiti njihovu nekompetentnost. Istovremeno, nedostatak korisnike podrke moe lako unititi
projekat razvoja, kao to i neadekvatna podrka moe spreiti zavretak projekta.
Agilni procesi istiu jedinstvene sposobnosti pojedinaca i timova. Naime, procesi ne mogu premostiti
nedostatak kompetencija pojedinaca. Timovi su samoorganizovani, sa intenzivnim komunikacijama u
okviru i van organizacionih granica. Ovi timovi mogu u svakom trenutku promeniti svoju strukturu kako
bi se prilagodili promenama. Agilnost podrazumeva da tim ima zajedniki cilj, uzajamno poverenje i
potovanje, zajedniki i brz postupak donoenja odluka i sposobnost savladavanja svih dvosmislenosti.
Agilan tim koji radi u okviru krute organizacije ima potekoa, kao to ih ima svaki pojedinac koji radi u
krutom timu. U ovim timovima, dominira saradnja svih nivoa upravljanja. Za donoenje odluke nije
vano ko donosi odluke, ve je vana saradnja i obezbeenje informacija za donoenje odluka. U
projektu razvoja uestvuju osobe razliitih vetina, talenta i sposobnosti, koje rade u bliskom fizikom
okruenju i potuju organizacionu kulturu. Osobe, okruenje i kultura su u strogoj meuzavisnosti.
Agilni razvoj nije prikladan za sve situacije. Nametanje agilnih principa procesno usmerenim i
nekooperativnim organizacijama ne dovodi do uspeha. Nametanje izuzetno promenljivog procesa
mirnim i staloenim timovima, vodi sigurno raspadu tima. Takoe, agilni razvoj se teko izvodi u
timovima sa veim brojem lanova. Najvie uspeha u agilnom razvoju pokazuju timovi do devet lanova.
Agilni razvoj se pokazao kao uspean u specifinim, kompleksnim i visoko-promenljivim projektima.
Okruenje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na
ljude i saradnju.
Postoji veoma veliki broj razvijenih modela agilnog razvoja. To su: Extreme Programming (XP), Adaptive
Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, Feature Driven
Development (FDD), Agile Modeling (AM) i drugi. Svi oni su zasnovani na agilnim principima, ali se
istovremeno i znaajno meusobno razlikuju po nainu realizacije procesa razvoja.

3.10 Kombinovani modeli

Napred opisani modeli su uglavnom prikazivani kao alternativni, a manje kao komplementarni modeli
razvoja. U mnogim situacijama modeli se mogu kombinovati tako da se postignu prednosti od svih na
samo jednom projektu. Spiralni model je i sam primer dobre kombinacije dva modela, kao to je i model
unificiranog procesa razvoja. Meutim, i drugi modeli mogu posluiti kao osnova na koju e se integrisati
neki modeli.

Prikupljanje i selekcija zahteva

Analiza

Prototip

Spiralni
model

4GT

Dizajn

4GT
Iteracije

Kodiranje

Iteracije

4GT

Testiranje

Sistem

Odravanje

Ne treba biti dogmatian u izboru odreenog modela u razvoju informacionog sistema. Priroda aplikacije
e diktirati model koji bi trebalo primeniti. Kombinovanjem modela, rezultat postignut u celini moe biti
povoljniji nego to bi to bio prosti zbir rezultata postignutih pojedinim modelima.

4. Metodi i tehnike razvoja informacionih sistema

Metodi predstavljaju neophodan i uz odreene pretpostavke propisani sistematizovani nain na koji se
izvravaju pojedini zadaci odnosno aktivnosti razvoja informacionog sistema. Metodi pokrivaju iroki
spektar aktivnosti meu kojima su: planiranje i procenjivanje projekata, analiza sistemskih i softverskih
zahteva, projektovanje strukture podataka, definisanje arhitekture programa, kodiranje, testiranje i
odravanje. Oni su bazirani na jednom ili vie principa realizacije.
Proceduru razvoja informacionih sistema je celishodno realizovati primenom odreenih metoda i
tehnika. Izabrati odgovarajui metod i tehniku, koji e se primeniti u razvoju nije jednostavno, obzirom
da su raspoloive brojne mogunosti. Metodi i tehnike se mogu meusobno kombinovati nezavisno od
toga koji je metod i tehnika najpogodnija za reavanje datog problema. Najznaajnija tenja prilikom
pravilnog izbora je minimizacija trokova razvoja i obezbeenje visoko kvalitetnog proizvoda.
Metodi i tehnike u razvoju informacionih sistema uvek uvode specijalne jezike ili grafike notacije i
grupe kriterijuma u definisanju kvaliteta softvera. Oni treba da budu nezavisni od podruja primene.
Drugim reima, moraju obezbediti reenje razliitim problemima, na razliite naine. Metodi i tehnike

razvoja su know-how koji se moe uspeno primeniti u razvojnom procesu pri izvrenju pojedinih
aktivnosti.
Naravno, ne postoji takav razvoj kojem nedostaju principi i metodi, ali ne postoje ni metodi koji se mogu
primeniti u reavanju svakog problema. U tom smislu, primarni i veoma odgovoran zadatak je izabrati za
korisnika, sistem i proces razvoja najpogodniji i najprilagodljiviji metod i tehniku. Pravilan izbor ne
podrazumeva definisanje jednog odreenog metoda i tehnike, ve u zavisnosti od kompleksnosti i vrste
problema kombinaciju vie razliitih metoda i tehnika.
Metodi i tehnike razvoja informacionih sistema se mogu grupisati prema razliitim kriterijumima, ali ih je
veoma teko jednoznano razvrstati. Najee se ipak grupiu s obzirom na faze razvoja informacionih
sistema u kojima se primenjuju.
Kao izraz potreba za reavanjem sve sloenijih problema putem raunara, razvijene su metodologije.
One predstavljaju jedinstveni sistem metoda, ijim povezivanjem je omogueno projektantima da na
sistematizovani nain pokriju vie ili sve faze razvoja softvera.

5. Sredstva razvoja informacionih sistema

Sredstva razvoja obezbeuju automatizovanu ili poluautomatizovanu podrku u primeni metoda. Oni
predstavljaju pomo neophodnu da bi se automatizovale aktivnosti razvoja informacionih sistema kao:
upravljanje projektom odnosno planiranje, procenjivanje, terminiranje, rasporeivanje, modeliranje,
analiza, projektovanje (dizajn), kodiranje, dokumentovanje, testiranje, integracija elemenata sistema,
upravljanje konfiguracijom, kontrola kvaliteta softvera i dr.
U praksi, danas svaki metod poseduje odreeno pomono sredstvo, instrument, alat. Kada su alati na
takav nain integrisani u jedan sistem da se rezultati kreirani od jednog alata mogu upotrebiti i od
drugog alata, tada govorimo o CASE tehnologijama. U nastavku su od sredstava upravo odabrane za
detaljniji prikaz CASE tehnologije i UML - alati za vizuelno modelovanje.

5.1 Automatizacija procesa razvoja - CASE tehnologije

Pojam, osobine i struktura CASE tehnologije
Computer Aided Software Engineering (CASE) tehnologije oznaavaju softver koji se upotrebljava u
razvoju drugih softverskih proizvoda. To je softver kojim se automatizuju aktivnosti ivotnog ciklusa
razvoja softverskih proizvoda i koji obezbeuje informacije o razvijenom softverskom proizvodu. U
najoptijem sluaju, pojam CASE se upotrebljava za svaki softver namenjen za automatizaciju bilo koje
aktivnosti procesa razvoja softvera. Saglasno tome, CASE tehnologije pokrivaju dijapazon od
pojedinanih alata za automatizaciju odreenih aktivnosti, do kompletnih softverskih alata za
automatizaciju veine koraka metodologije razvoja informacionih sistema. CASE tehnologije ne
predstavljaju zamenu za bilo koji metod ili tehniku razvoja, ve samo dodatak metodu ili tehnici u
generisanju kvalitetnog proizvoda. Njihovo korienje je interaktivno, prilagoeno korisniku uz naglasak
na upotrebu grafike.
CASE je akronim koji je prva koristila Nastec Corporation 1982. godine. Akronim poseduje dva znaenja.
CASE se koristi za oznaavanje pojma computer-aided software engineering, ali takoe i za oznaavanje
pojma computer-aided systems engineering. U nastavku ovog teksta, CASE e oznaavati pojam
Computer - Aided Software Engineering, koji se moe prevesti kao ininjerski razvoj softvera (i
informacionih sistema) uz pomo raunara.

CASE tehnologije su razvijene kao rezultat nastojanja osoba, koje se bave razvojem softvera i
informacionih sistema da unaprede sopstvenu produktivnost. Naime, ironinom se smatrala situacija da
se primenom informacionih tehnologija tei poveati produktivnost rada drugih, ignoriui pri tome
potencijal raunara za unapreenje sopstvene produktivnosti. Pored poveanja produktivnosti, osnovni
ciljevi primene CASE tehnologije su: skraenje vremena realizacije projekata razvoja informacionih
sistema, poveanje kvaliteta i nivoa performansi informacionih sistema putem stroge primene principa,
metoda, tehnika i procedura razvoja. Da bi se navedeni ciljevi postigli bila je neophodna disciplinirana
primena konzistentne metodologije, ije faze odnosno aktivnosti bi se realizovale uz primenu raunara.
Jednom reju, reenje se trailo u automatizaciji postupaka razvoja informacionih sistema primenom
CASE tehnologija.
CASE tehnologije se usled brzog razvoja i trenutnog stanja razvijenosti ne mogu shvatati kao prost zbir
alata koji su namenjeni razvoju informacionih sistema, ve kao sistemi koji integriu: (a) hardver, (b)
softver, (c) bazu podataka, (d) procedure i (e) kadrove. U CASE terminologiji integralna celina
hardverskih i softverskih komponenti se naziva CASE alatom. Procedure se nazivaju CASE
metodologijom, a baza podataka CASE skladite (repozitorijum) enciklopedija.
Uspena primena CASE tehnologije pretpostavlja prethodno opredeljenje i usvajanje odgovarajue
metodologije razvoja informacionih sistema. Naime, CASE tehnologije, posebno one koje su
strukturirane od vie CASE alata, mogu biti zavisne ili nezavisne od metodologije razvoja. Kada su zavisne
od metodologije, one su restriktivne i zahtevaju strukturirano okruenje: tehnikih i ljudskih resursa,
propisanih standarda i procedura, kao i jedinstenog metodolokog pristupa. Meutim, kada su
nezavisne od metodologije, omoguuju primenu razliitih metodologija, jednostavnije su i lake za
primenu, ali zbog manje standarda i propisanih procedura mogu proizvesti veoma negativne posledice u
razvoju. Veoma esto ne podravaju ni kritine prelazne take izmeu razvojnih faza.
CASE tehnologije zahtevaju disciplinovani pristup razvoju informacionih sistema, odnosno CASE
tehnologije moraju biti odabrane i primenjene u onim aktivnostima za koje su i namenjene. Osobe koje
rade sa njima moraju biti na adekvatan nain obuene. Naime, CASE tehnologije su samo alati u rukama
projektanata ili drugih korisnika, iji efekat zavisi ne samo od kvaliteta CASE tehnologije ve i od njihove
sposobnosti i znanja. CASE tehnologije automatizuju veinu rutinskih aktivnosti razvoja. Jo uvek je
njihovo uvoenje u podrci kreativnijih aktivnosti razvoja neuspeno. Takoe, i elja da se podri timski
rad u razvoju informacionih sistema CASE tehnologijama je delimino ostvarena.
Optu strukturu CASE tehnologije ine:

Alati za dijagramiranje slue za grafiko predstavljanje procesa, podataka i kontrolnih struktura i
ine osnovu veine tehnologija.

Alati za generisanje formi i izvetaja slue za automatizovani razvoj raunarskih formi i izvetaja
putem kojih e korisnici biti u interakciji sa novim sistemom.

Alati za analizu slue u upravljanju kompleksnim razvojem velikih sistema, generiu izvetaje
putem kojih se automatski proveravaju nekompletne, nekonzistentne ili nekorektne specifikacije u
dijagramima, formama i izvetajima.

Alati za projektovanje slue za izgradnju komponenata sistema.

Alati za generisanje dokumentacije slue u izradi tehnike i korisnike dokumentacije u
standardnim formatima.

Alati za generisanje koda slue za automatizovano generisanje koda programa i koda definicije
baze podataka direktno iz dizajniranih dokumenata, dijagrama, formi i izvetaja.


CASE skladite (enciklopedija).

Dijagrami

Forme
i
Izvetaji

Dokumentacija

CASE
skladite
Rezultati
analize i
dizajna

Informacije
o projektu

Izvorni i
objektni kod

Standardna
biblioteka

Treba naglasiti, da ne poseduju sve CASE tehnologije navedenu optu strukturu, mada softverske
kompanije uglavnom tee da razviju u sopstvenoj reiji ili putem saradnje odreene CASE tehnologije
koje ine zaokruene celine. Takoe, one nemaju ni istu mo, pa se u primeni najee kombinuju alati
razliitih CASE tehnologija. Upotrebljavaju se tako alati iz jedne tehnologije u realizaciji jedne faze
razvoja, a drugi alati iz druge tehnologije u realizaciji druge faze razvoja.
Ovakva primena CASE tehnologije stvara odreene probleme jer ne postoji definisana standardna
struktura CASE enciklopedije. Podaci u enciklopediji koje pruaju odreeni alati uglavnom su
nekompatibilni sa podacima u enciklopediji potrebnim za druge alate. Razliite tehnologije i alati imaju
razliite standarde i formate podataka, pa se o tome pri izboru mora posebno voditi rauna.
Najznaajnija korist upotrebe CASE tehnologije se svakako postie ukoliko se integriu svi alati koji ine
njenu strukturu, da bi se njihovim povezivanjem integrisali i svi podaci kojima isti upravljaju. Integrisani
alati se oslanjaju na zajedniku terminologiju, notaciju, metode i tehnike za razvoj sistema. Kompletno
integrisani alati imaju zajedniki korisniki interfejs i zajedniko skladite podataka za sve alate, tako da
se informacije mogu lako deliti izmeu pojedinih alata i aktivnosti ivotnog ciklusa razvoja bez
prevoenja podataka iz jednog formata u drugi.

CASE skladite
CASE skladite, kao centralna baza podataka, je jezgro i najbitniji segment za integraciju alata koji se
koriste kroz razliite faze ivotnog ciklusa razvoja. Ono predstavlja centralnu komponentu strukture

CASE tehnologije, sponu izmeu svih nabrojanih komponenti strukture CASE tehnologije, i ne samo to,
ve prua mogunost da se putem nje pojedine faze razvoja softverskog proizvoda automatski
meusobno nadovezuju i pri tome rezultati iz odreene faze istovremeno stavljaju na raspolaganje
alatima u narednim fazama procesa razvoja. to znai, da CASE skladite sadri kompletne informacije
potrebne za kreiranje, izmenu i ocenu softverskog proizvoda od iniciranja i planiranja projekta do
njegovog odravanja.

CASE skladite ine dva primarna segmenta: skladite informacija i renik podataka.
Skladite informacija kombinuje poslovne informacije organizacije i njen aplikacioni portfolio i na taj
nain omoguuje automatizovanim alatima da upravljaju i kontroliu pristup podacima u skladitu.
Poslovne informacije su smetene u korporativnu bazu podataka, dok se aplikacioni porfolio sastoji od
aplikativnih softverskih reenja (programa) koja se koriste za upravljanje poslovnim informacija.
Renik podataka je softverski alat koji se koristi za upravljanje i kontrolu pristupa skladitu informacija.
On prua mogunost da se snime, uvaju i obrade opisi relevantnih podataka organizacije, kao i resursi
obrade podataka. Osobine renika podataka u okviru CASE skladita su posebno od koristi za sistem
analitiara zbog unakrsnog povezivanja podataka. Unakrsno povezivanje obezbeuje da svaki podatak
bude jedinstveno opisan u reniku podataka i da istom mogu pristupati svi pojedinci (sistem analitiari i
korisnici). To znai da postoji i upotrebljava se samo jedna definicija (opis) svakog podatka. Ovakav opis
pomae da se izbegne dupliranje podataka i ujedno ini razvoj i odravanje sistema efikasnijim. Takoe,
u okruenju integrisanih CASE alata, svi dijagrami, forme, izvetaji i programi se mogu automatski
aurirati jednom promenom u definiciji (opisu) renika podataka.
Svaki elemenat u reniku podataka ima standardnu "definiciju" koja ukljuuje informacije kao to su:

naziv elementa i pseudonim

tekstualni opis elementa

lista elemenata sa kojima je u vezi

tip elementa i format

interval prihvatljivih vrednosti


ostale informacije jedinstvene za odgovarajuu obradu elementa.

Pored napred navedenog efekta korienja CASE skladita, koji se postie integracijom podataka svih
povezanih alata, treba istai da CASE skladite obezbeuje i dodatne efekte, u aktivnostima upravljanja
projektima i ponovnom korienju izgraenih komponenata softvera.
Obzirom da razvoj softverskih proizvoda podrazumeva izvrenje velikog broja aktivnosti i zahteva
ukljuenje veeg broja uesnika u realizaciji projekta, neophodno je koristiti tehniku upravljanja
projektom putem koje bi se najefikasnije koordinirale aktivnosti i uesnici razvoja. CASE skladite
obezbeuje bogatstvo informacija za menadere projekata i omoguuje im da obavljalju odgovarajuu
kontrolu na njima. Putem CASE skladita, projektni menader moe ograniiti pristup lanovima
razvojnog tima samo onim delovima projekta i aktivnostima za koje su oni odgovorni i tako redukovati
sloenost sistema za dati tim i obezbediti sigurnost od nepaljivo izmenjenih i izbrisanih podataka.
Podela dozvoljava da vie timova radi paralelno na razliitim aspektima jednog sistema, redukujui
krajnje vreme razvoja sistema.
Takoe, CASE skladite obezbeuje odreene efekte u ponovnom korienju izgraenih komponenti
softvera (reusability). U velikim organizacijama sa mnogo softverskih reenja, vie od 75% programskih
aplikacija sadri znaajan broj identinih funkcija. Prema tome, lak put za projektante i programere
sistema da poveaju svoju produktivnost je da prestanu da reinvestiraju u funkcije. Ukoliko bi sva
softverska reenja bila kreirana korienjem CASE tehnologije sa zajednikim skladitem, bilo bi mogue
da se ponovo koristi znaajan deo ranije izgraenih komponenti sistema u razvoju novih. Postoje brojne
komponente razvoja koje bi se mogle ponovo upotrebiti, a ijom upotrebom bi se skratilo vreme, snizili
trokovi i poboljao kvalitet razvijenih softverskih proizvoda.
Postoji tri tipa CASE skladita pasivna, aktivna i dinamina. Pasivna CASE skladita nisu u interakciji sa
procesom razvoja aplikacija, i ne odravaju se automatski sa meta podacima kreiranim tokom razvoja.
Svako auriranje skladita se izvodi nezavisno i direktno od strane korisnika. Aktivna CASE skladita se
auriraju automatski u pozadini (background modu) dok se realizuju druge razvojne aktivnosti.
Dinamika CASE skladita su povezana i auriraju se tokom izvrenja aplikacija.
Klasifikacija CASE tehnologija
Klasifikacije CASE tehnologija slue da bi se lake razumeli i spoznali pojedini tipovi CASE tehnologija i
njihove uloge u podrci razvoju softvera i informacionih sistema. Postoje brojni kriterijumi za klasifikaciju
CASE tehnologija. Svaki od kriterijuma prua razliite poglede na iste. Tako se one najee klasifikuju:
obzirom na funkcije koje poseduju, obzirom na aktivnosti koje u procesu razvoja podravaju i obzirom na
nain kako su organizovani u integrisane celine za podrku jedne ili vie aktivnosti procesa razvoja.
Klasifikacija CASE tehnologija obzirom na funkcije koje poseduju je prikazana u tabeli 1.
Tab.1.
Tipovi CASE tehnologija
Alati za planiranje
Alati za editovanje
Alati za upravljanje konfiguracijom
Alati prototipskog razvoja
Alati za podrku metoda
Alati za procesiranje jezika
Alati za analizu programa

Primeri
PERT alati, alati za predvianje, spregnute tabele
tekst editori, dijagram editori, procesori teksta
sistemi za upravljanje verzijama, alati za izgradnju
sistema
generatori korisnikog interfejsa, jezici visokog
nivoa
renici podataka, generatori koda
kompajleri, interpreteri
statiki analizatori, dinamiki analizatori,
generatori unakrsnih zavisnosti

Alati za testiranje
Alati za pronalaenje greaka
Alati za izradu dokumentacije
Alati za reininjering

generatori test podataka, alati za uporeivanje

datoteka
interaktivni sistemi pronalaenja greaka
alati za definisanje izgleda, editori za slike
sistemi za programsko restruktuiranje, sistemi
unakrsnog povezivanja

Jedan od moguih kriterijuma pri klasifikaciji je i kompletnost CASE tehnologije, koja ukazuje na broj
aktivnosti razvoja softvera i informacionih sistema, iju automatizaciju CASE tehnologija podrava.
Prema ovoj klasifikaciji diferenciraju se:

Upper CASE - CASE tehnologije namenjene za automatizaciju aktivnosti faze strategijskog
planiranja i aktivnosti faze upravljanja projektima.

Middle CASE - CASE tehnologije namenjene za automatizaciju aktivnosti faze analize i aktivnosti
faze dizajna.

Lower CASE - CASE tehnologije za automatizaciju aktivnosti faza programiranja, testiranja i
uvoenja informacionog sistema.

Prema integralnosti CASE tehnologije se strukturiraju na:

CASE tool - CASE alati koji automatizuju pojedine aktivnosti u fazama razvoja informacionih
sistema. Oni mogu biti opte primenljivi, nezavisni/samostalni (standalone) ili povezani/grupisani
u CASE workbench.

CASE workbench - CASE tehnologije koje slue za automatizaciju aktivnosti pojedinih faza razvoja
informacionih sistema. Oni se obino sastoje od kolekcije tj. vie CASE alata sa manjim ili veim
stepenom integracije.

CASE environments CASE okruenje slui za podrku celog ili najznaajnijeg dela procesa razvoja
informacionih sistema. Okruenje uobiajeno ukljuuje nekolicinu integrisanih CASE workbenchova.

U zavisnosti koje faze ivotnog ciklusa razvoja sistema pokrivaju, CASE tehnologije se strukturiraju na:
Avison D.E., Fitzgerald G.

Projektanski CASE - automatizuju prve tri faze ivotnog ciklusa: strategijsko planiranje, analizu i
dizajn;

Programerski CASE - automatizuju naredne tri faze ivotnog ciklusa: programiranje,
implementaciju i eksploataciju i odravanje;

Integrisani CASE (i-CASE) - podrava sve faze ivotnog ciklusa razvoja sistema.
Konano, CASE tehnologije se razlikuju i po tome koliko su zavisne od metodologije razvoja, pa se
razlikuju:

Zavisne CASE tehnologije - zahtevaju strukturirano okruenje, u smislu tehnikih resursa, ljudskih
resursa, propisanih standarda i procedura i jedinstveni metodoloki pristup. Ukljuuju veoma
ogranieni i mali broj alata.

Nezavisne CASE tehnologije - su pod manjim uticajem odreene metodologije i zato se
jednostavnije i lake primenjuje. S druge strane rezultat primene ovakvog niza alata, koji podrava
razliite metodologije, uz manje propisanih standarda i procedura moe imati katastrofalne
posledice. Poto su alati dizajnirani za razliite faze razvoja, oni esto ne podravaju kritine
prelazne take izmeu pojedinih faza, pa se rezultati nemogu prenositi i povezivati.

Primena CASE tehnologije u organizacijama

Osnovna svrha CASE tehnologije je da uini mnogo lakom implementaciju filozofije pojedinanog
pristupa razvoju softvera i informacionog sistema u organizaciji sa mnogo projekata, sistema i ljudi. CASE
moe podravati veinu aktivnosti ivotnog ciklusa razvoja. Nezavisno od toga to se CASE tehnologije
koriste na mini i mainframe (velikim) raunarima, skoranji razvoj PC raunara uinio ih je
predominantnim CASE workstation (radnim stanicama). CASE tehnologije automatizacijom celokupnog
procesa razvoja softvera i informacionog sistema, pomau projektantima da upravljaju kompleksnim
projektima razvoja informacionih sistema i da obezbede izgradnju sistema visokog kvaliteta, na vreme i
u okviru budeta.

Ciljevi primene:
 Poveanje produktivnosti projektanata i programera.
 Skraenje vremena razvoja softverskog proizvoda.
 Vii nivo kvaliteta: projekta, softvera i dokumentacije.
 Visoka integrisanost razvojnih aktivnosti putem metodologije koju podrava i ujedno
standardizovanost razvoja.
 Nii trokovi razvoja softverskog proizvoda.
 Jednostavnije, lake i jeftinije odravanje i dalji razvoj softverskog proizvoda.
 Reusability modula i dokumentacije
Najee navoeni razlozi primene CASE tehnologije u organizacijama su:

unaprediti kvalitet razvijenog sistema,

poveati brzinu dizajniranja i razvoja sistema,

olakati i unaprediti proces testiranja putem upotrebe automatizovane provere,

unaprediti povezivanje razvojnih aktivnosti putem odabrane zajednike metodologije,

unaprediti kvalitet i celovitost (kompletnost) dokumentacije,

unaprediti znanje uesnika u procesu razvoja,

pomoi u standardizaciji procesa razvoja,

unaprediti upravljanje projektima razvoja sistema,

pojednostaviti odravanje programa,

promovisati ponovno korienje razvijenih komponenti softvera i dr.
Brojna empirijska istraivanja, meutim, identifikuju i veliki broj prepreka za uvoenje CASE tehnologija.
Meu njima su neke iz perspektive pojedinaca, dok je mnogo vei broj onih iz perspektive organizacije.
Najee se navode sledee:

visoki trokovi nabavke CASE tehnologije,

visoki trokovi obuke,

neizvesnost efekata od uvoenja CASE tehnologije,


nezrelost CASE tehnologije,

nedostatak podrke menadmenta,

otpor analitiara i programera promenama koje CASE tehnologija donosi, posebno u sluaju
potrebe usvajanja nove metodologije, metoda i tehnika,

tekoe u menjanju postojee prakse i nepostojanje standarda razvoja u organizaciji u kojoj se
CASE tehnologija eli primeniti.
Efekti primene CASE tehnologije
Pri razvoju CASE tehnologije, specijalna panja se posveuje automatizaciji prve tri faze ivotnog ciklusa.
Razlog za to su visine relativnih trokova otklanjanja greke u pojedinim fazama ivotnog ciklusa. to se
greka kasnije otkrije, to vie kota njeno otklanjanje.
Efektivna primena CASE tehnologije znaajno doprinosi kvalitetu procesa razvoja softvera i
informacionog sistema. CASE tehnologije su korisne jer u izvrenju svoje funkcije, tede vreme, tede
radnu snagu, tede novac ili omoguuju neto to je bez njih teko ili uopte ne izvodivo. Produktivnost
organizacije se poveava, a greke u razvoju se znaajno smanjuju. CASE tehnologije u razvoju softvera i
informacionih sistema doprinose nizu pozitivnih efekata:

grafika prezentacija modela sistema,

detekcija greaka i korekcija nekonzistentnosti,

interaktivna izrada prototipa sistema,

identifikacija komponenti sistema koji se mogu ponovo upotrebiti u razvoju,

efektivno upravljanje razvojem sistema,

efikasna kontrola utroenog vremena u razvoju,

kontrola troenja sredstava predvienih za razvoj,

automatizovano generisanje uvek aurne dokumentacije i drugi.
Upravo zbog navedenih efekata, CASE tehnologije se preporuuju kao reenje mnogih problema
svojstvenih tradicionalnom nainu razvoja sistema, kao to su kanjenje u realizaciji aktivnosti i faza,
netanost, teko sprovoenje izmena i loa dokumentovanost. Za sada, period primene CASE tehnologija
je relativno kratak da bi se mogli tanije proceniti efekti. Empirijska istraivanja pokazuju da se
poboljanja kreu u irokom intervalu, od neznatnih do veoma znaajnih. Bez obzira na razliite rezultate
istraivanja dobijene u razliitim studijama, ohrabruje da veina ukazuje na bitna poboljanja. Poveanje
produktivnosti, izgradnja mnogo kvalitetnijih sistema u kraem vremenskom intervalu, uticali su na one
koji se bave razvojem sistema da izmene ili kompletno restruktuiraju svoje metodologije razvoja softvera
i informacionih sistema kako bi implementirali CASE tehnologije.
Osobine CASE tehnologije
Generalno posmatrano, razvoj CASE tehnologije zavisi od specifinosti zahteva korisnika, okruenja u
kojem se ista eli primeniti i ideja o tome kako bi tehnologija mogla da funkcionie. Standardi u izgradnji
CASE tehnologija ne postoje. CASE tehnologije su brojne i pokrivaju veinu aktivnosti faza razvoja
softvera i informacionih sistema.
Osobine koje treba da poseduju CASE tehnologije koji pripadaju klasi kvalitetnih tehnologija su sledea:

1. Jednostavno i lako korienje - Ova osobina predstavlja meru efektivnosti tehnologije u odnosu na
korisnika. Nezavisno od funkcionalnosti i potpunosti, CASE tehnologija treba da je tako kreirana da je
korisnik moe lako, jednostavno i bez puno razmiljanja i neizvesnosti koristiti u reavanju projektantskih
zadataka. Ukoliko to nije sluaj, tada korisnik svoje vreme provodi u razmiljanju kako bi tehnologiju
koristio ili kako tehnologija uopte radi, a to znai da ista svojom ulogom ne pomae ve samo
predstavlja smetnju ili ak prepreku u radu.
2. Tehnologija treba da poseduje mogunost da otkriva greke korisnika, a poeljno je da sama te greke
i otklanja. Tehnologija treba da omogui interakciju sa korisnikom putem dijaloga koji je razumljiv i
prihvatljiv za korisnika. Ona treba da je fleksibilna i da se moe kombinovati sa drugim tehnologijama
kako bi se zadovoljili razliiti zahtevi korisnika. Posebno je znaajno da se minimiziraju ili potpuno
iskljue nepredviena reagovanja tehnologije, koja obino rezultiraju nezadovoljstvom korisnika. CASE
tehnologija ne bi smela svojim izlazima da iznenauje, zbunjuje i blokira rad korisnika. Naredbe koje
korisnik upotrebljava treba da su jasne, jednostavne i konzistentne.
3. Podobnost - Kvalitetna je ona tehnologija koja poseduje takav nivo podobnosti i performansi da moe
da podri reavanje velikog broja aktivnosti u razvoju informacionih sistema. Podobnost se izraava kroz
obim kojim jednostavne naredbe tehnologije mogu uzrokovati njene glavne efekte. Uz ovo obeleje
pridruuje se i zahtev da CASE tehnologija treba da bude u mogunosti da prua informacije o
sopstvenom stanju. Dobra tehnologija moe impresionirati i mnogo veom podobnou nego to je ona
ustvari, ukoliko poseduje vie znanja o sopstvenom stanju.
4. Velika snaga tj. mo - Snaga tehnologije se ocenjuje na osnovu kombinacije sledeih faktora:

pouzdanost tehnologije,

osobine tehnologije koje se ispoljavaju pri oskudnim ili loim uslovima,

funkcionisanje,

teina posledica nedostataka tehnologije,

konzistentnost aktivnosti u funkcionisanju tehnologije i

nain na koji se tehnologija integrie u okruenje.
5. Pouzdanost je znaajan zahtev koji se ispoljava kao sposobnost alata da rastereti korisnika od rizika
greke koju sam napravi. CASE tehnologija treba da otkriva odnosno otklanja greke i posledice koje
zbog istih nastanu. Tehnologija treba da poseduje sopstveni mehanizam samotestiranja koji obezbeuje
njegovo pravilno funkcionisanje.
6. Konzistentnost aktivnosti tehnologije potvruje veliinu tj. obim njene snage. Konzistentnost
podrazumeva dobro definisanu sintaksu i semantiku. Istovremeno, tehnologija mora biti tako razvijana
da podrava kompatibilnost izmeu pojedinih verzija.
7. Funkcionalnost - Ova osobina nije definisana samo zadatkom zbog kojeg je tehnologija dizajnirana ve
i metodima koji se upotrebljavaju u izvrenju zadataka. Broj tehnologija koje podravaju metodologije je
veoma velik. Efikasnost koju ispoljava tehnologija u podrci metoda moe neposredno doprineti
razumevanju i definisanju osobina tehnologije, kao i odreenju kvaliteta i korisnosti izlaza koje
obezbeuje.
8. CASE tehnologije integriu metode i povezuju ih sa metodologijom. Pojedine tehnologije podravaju
jednu, vie ili sve faze metodologije i prenose rezultate izmeu njih. Koncepcija i struktura CASE
tehnologije je odreena izabranom metodologijom i njoj pripadajuim metodama i tehnikama.
Tehnologija mora da obezbedi konzistentnu primenu metodologije i metoda na kojima se zasniva. Tako

ona mora funkcionisati korektno i kontrolisati da li se metodologija sprovodi u potpunosti. Pored toga,
CASE tehnologija mora generisati izlaze koji su korektni i striktno definisani metodologijom.
9. Lako povezivanje sa postojeim sistemom - CASE tehnologija se mora lako i nesmetano uvesti u
postojei informacioni sistem. Ona se jednostavno instalira i omoguuje da se postojee strukture
datoteka ili baze podataka koriste na isti nain kao i pre njene upotrebe. CASE tehnologija mora
omoguiti i prenos podataka odnosno njihovu razmenu izmeu razliitih CASE tehnologija koje se ve
koriste u organizaciji.
10. Kvalitet podrke CASE tehnologije - Prilikom vrednovanja tehnologije sa aspekta kvaliteta podrke,
znaajno je sagledati i sledee elemente podrke:

reputacija dobavljaa,

zrelost tehnologije i njena rasprostranjenost,

mogunost smanjenja trokova pri kupovini vie kopija,

mogunost iznajmljivanja tehnologije,

mogunost vraanja tehnologije uz povrat sredstava,

mogunost dobijanja punih prava i pristupa izvornom kodu,

mogunost i uslovi odravanja,

vreme odziva u odravanju,

pruanje pomoi u obezbeenju problematinih odgovora,

da li korisnik raspolae pravom na nove verzije tehnologije bez naknade,

koji je rok garancije,

koji su rokovi isporuke,

kakvi su uslovi obuke za korisnike tehnologije,

da li postoje efikasni programi obuke i

kakva su struna i pedagoka svojstva kadrova koji vre obuku.
CASE tehnologije obezbeuju integralno razvojno okruenje koje prua podrku svim aktivnostima od
planiranja, preko dizajna do odravanja softvera i informacionog sistema. Pri tome, omoguujui
optimalno funkcionisanje sistema uz najmanji mogui procenat greaka.
Zahtevi i naini integracije CASE tehnologija
Ve je ranije pomenut znaaj i potreba integracije CASE tehnologija. Integracijom se obezbeuje
povezivanje CASE alata na nain da su svima raspoloive prema potrebi sve informacije nastale u
procesu razvoja, da je upotreba alata integrisana i da im je filozofija razvoja integrisana putem primene
standardizovanog procesa u kojem se primenjuje savremena praksa i proverene metode i tehnike.
Integrisana CASE tehnologija mora zadovoljiti sledee zahteve:

obezbediti mehanizam za podelu svih informacija nastalih u procesu razvoja izmeu alata u
njenom okruenju,

omoguiti da se svaka promena odreene informacije po potrebi reflektuje na ostale informacije
sa kojima je ona u vezi,


obezbediti kontrolu verzija za sve informacije nastale u procesu razvoja,

dozvoliti direktan pristup svakom alatu koji je deo integrisane CASE tehnologije, odnosno njenog
okruenja,

omoguiti korisnicima svih alata konzistentan pogled i upotrebu korisnikog interfejsa,

podrati komunikaciju izmeu uesnika razvoja,

prikupiti tehnike parametre koji se mogu upotrebiti za unapreenje procesa ili proizvoda i dr.
CASE tehnologije se mogu na razliite naine integrisati. Mali je broj alata koji su potpuno nezavisni i
tako se koriste. Takvi alati kreiraju samostalno izlaze u vidu dokumenata, programa, podataka i njihova
veza prema ostalima u okruenju je papir koji prenosi projektant. U praksi, CASE tehnologije se povezuju
i razlikujemo sledee naine integracije:
Razmena podataka (Data exchange) - je najei sluaj i mogunost koju poseduje veina alata, da se iz
njih eksportuju podaci koje oni poseduju, tako to se kreira nestrukturirana datoteka u formatu tampe.
Na taj nain se vri neposredna razmena podataka izmeu dva alata, uobiajeno posredstvom
prenosnog filtera. Ovaj oblik integracije omoguuje da se zatite podaci alata, eliminie potreba
ponovnog unoenja podataka i spree tamparske greke. Brojni prevodioci se razvijeni za potrebe ove
razmene. Uglavnom su oni poreklom od isporuilaca alata, ali su takoe i od strane konsultanata i
korisnika.
Nedostatak ovog naina je to se uglavnom samo deo prevedenih podataka moe prihvatiti i koristiti u
drugom alatu, poto nisu kompatibilni. Takoe, nedostatak je i to stalni razvoj softvera zahteva da se i
nakon manjih izmena podaci prevode i prenose, a to je vremenski zahtevno. Brojne verzije mogu lako
dovesti do odsustva sinhronizacije. I ukoliko se koristi veliki broj alata na jednom projektu, neprihvatljivo
je da se masovno prenose i prevode podaci. Prenos podataka je jednosmeran, jer ne postoje mogunosti
da se vre izmene obostrano, a to znai da dolazi u pitanje odravanje integralnosti konfiguracije kroz
nizove alata koji se upotrebljavaju.
Zajedniki pristup alatima (Common Tool Access) - predstavlja sledei nivo integracije, koji omoguuje
korisniku da poziva vei broj razliitih alata na isti nain, npr. iz pull-down menija. U multitasking
okruenju to znai da korisnik moe simultano otvarati alate, runo koordinirati ulaze u njih i uporeivati
izlaze dizajna na nain kako eli. Npr. korisnik moe istovremeno prikazati dijagrame tokova podataka,
dijagrame strukture, renik podataka i izvorni kod koje odravaju razliiti alati. U ovom okruenju,
razmena podataka izmeu alata moe biti uproena uvoenjem procedure prevoenja obinim
izborom menija ili izborom makro funkcije.
Zajedniko upravljanje podacima (Common Data Management) - predstavlja nain integracije pri kojoj
se podaci iz razliitih alata odravaju u jednoj logikoj bazi podataka, koja moe biti fiziki centralizovana
ili distribuirana. Integracija na ovaj nain uproava razmenu informacija i podie nivo integralnosti
deljenih podataka, poto svaki alat ima stalni i trenutni pristup aurnim podacima. Istovremeno, prava
pristupa podacima se mogu kontrolisati, a moe se upravljati i verzijama alata, manuelno putem
procedura prijavljivanja i odjavljivanja. Tipino, postoji funkcija integrisanja podataka koja omoguuje
projektantima koji rade na razliitim delovima aplikacija da kombinuju svoje poslove. Ukoliko ovakva
grupa alata poseduje karakteristiku provere na projektu, tada je mogue utvrivanje nekonzistentnosti
izmeu rezultata pojedinih autora.
Mada se podacima iz razliitih alata upravlja zajedno na nivou zajednikog upravljanja podacima, alati ne
poznaju meusobno interne strukture podataka i semantiku predstavljanu u dizajnu. Konkretno,

potreban je i dalje korak prevoenja koji se manuelno aktivira da bi se jednom alatu omoguilo
korienje izlaza drugog alata.
Podela podataka (Data Sharing) - je nain integracije pri kojem alati poseduju kompatibilne strukture
podataka i semantiku i mogu direktno upotrebljavati meusobno podatke bez prevoenja. Svaki alat je
tako dizajniran da bi bio kompatibilan sa ostalima u uslovima podele podataka. Zbog toga, podela
podataka se javlja uglavnom kod alata istog proizvoaa ili kod vie proizvoaa koji su se strateki
povezali upravo da bi proizveli takav proizvod (ak moda i na zahtev jednog korisnika). Za realizaciju
ovog naina povezivanja, kljunu ulogu su odigrali standardi koji obezbeuju dobru osnovu za integraciju
CASE alata.
Meusobna operatibilnost (Interoperability) - je najvii nivo integracije pojedinanih alata i javlja se
ukoliko je realizovan zajedniki pristup alatima i podela podataka.
Puna integralnost (Full Integration) - Da bi se postigla puna integrisanost CASE okruenja, neophodna su
jo dva dodatna elementa: upravljanje meta podacima i sredstva kontrole. Meta podaci su informacije o
procesu softverskog inenjeringa proizvedene od pojedinih CASE alata. Meta podaci ukljuuju:

definicije objekata (tip, atribute, veze),

veze i zavisnosti izmeu objekata proizvoljne detaljnosti,

pravila dizajna softvera,

tokove procesa, procedure i dogaaje.
Sredstva kontrole omoguuju pojedinanim alatima da obaveste ostatak okruenja (ostale alate,
rukovodioca podataka,...) o znaajnim dogaajima i poalju zahteve za akcijom ostalim alatima i
servisima putem trigera. Npr. alat za dizajn bi morao obavestiti alat za upravljanje konfiguracijom da je
kreirana nova verzija dokumenta dizajna i da je potrebno da ovaj izvri proveru konzistentnosti. Sredstva
kontrole pomau u odravanju integriteta okruenja i obezbeuju sredstva za automatizaciju
standardnih procesa i procedura.

Ocena i izbor CASE tehnologije

Proces ocene vrednosti i izbor CASE tehnologije se izvodi od strane organizacije koja ga eli nabaviti.
Svaka organizacija ima sopstvene potrebe i zahteve pri nabavci tehnologije. Proces procene ine sledei
metodoloki koraci:

analiza potreba i zahteva korisnika,

analiza postojeeg okruenja,

identifikovanje potencijalne liste CASE tehnologija i

primena kriterijuma za ocenu kvaliteta i izbor tehnologije.
Analiza potreba i zahteva korisnika predstavlja veoma znaajan korak u izboru CASE tehnologije.
Organizacija treba da opredeli koji model razvoja softvera e primeniti, koji su osnovni tehniki i
upravljaki zadaci. Tano se moraju identifikovati oni zadaci koji se ele potpuno ili delimino realizovati
uz pomo automatizovanih alata.
Analiza postojeeg okruenja je u potpunosti povezana sa prethodnim metodolokim korakom. CASE
tehnologija mora potpuno da bude prikladna okruenju. Ogranienja su mogua i ona se moraju uzeti u
obzir. Tako npr. novac, vreme, iskustvo zaposlenih, dosadanja praksa, odnosi sa dobavljaima i dr. Ova
ogranienja ne samo da se identifikuju nego se i analiziraju sa aspekta njihove mogue promene ili
otklanjanja.

Identifikovanje potencijalne liste CASE tehnologija predstavlja korak kojim se potrebama i zahtevima
korisnika pridruuju mogue tehnologije koje bi iste zadovoljili. Trenutno je izbor tehnologija veoma
velik, a poseduje tendenciju daljeg brzog razvoja. Prezentacije, reklamni materijali i dr. obezbeuju
inicijalne informacije o postojeim tehnologijama.
Poslednji korak ove metodologije je sigurno najznaajniji. Svi identifikovani kriterijumi se primenjuju na
svaku od CASE tehnologija koje su identifikovane u potencijalnoj listi. Kriterijumi se postavljaju za
potrebe najobjektivnije selekcije. Trokovi i vreme su pri tome na vrhu liste. Ukoliko postoji mogunost
nije na odmet da se dobavlja poseti i na licu mesta tehnologija upozna i testira.
Beleke i zapaanja sa testa treba da su opredeljujui u odreenju koliko tehnologija zadovoljava
postavljene kriterijume. Posebna panja se pridaje kriterijumima koji su najvie rangirani. Konana
odluka treba da se bazira i na miljenju zaposlenih u organizaciji koji bi trebali da ostvare najveu korist
od primene tehnologije.
U tabeli xxxxx su dati nazivi poznatijih CASE tehnologija i njihovih proizvoaa:
CASE
tehnologija
IEW

Metodologije
razvoja
Warnier-Orr

Promod PLUS

Yourdon,
de Marco,
Hatley/Pirbhai
J. Martin,
de Marco,
Ernst & Young
Yourdon,
Coad,
Constantine,
Ross
Yourdon,
de Marco,
Chen
Ward-Mellor,
de Marco,
Chen,
SSADM
Martin-Odell,
OOAD
Rumbaugh OMT,
Martin-Odell, OOIE,
Booch OOAD,
Coad, Yourdon,
Shalaer-Mellor,
AOOD

Uniface Six,
Source Pilot,
C, Fortran
Uniface Six,
CASE Generator
SQL, Forms
C, C++, Fortran,
Cobol, Magic

Martin-Odell OOAD
Rumbaugh OMT,
Booch OOAD,
Jacobson Objectory
Use Case,

C++
C, C++, Fort, Java,
SmallTalk,
PowerBuilder,
Gupta

Oracle CASE

Synthesis

Westmount
ISEE
Westmount
I-CASE

PTECH
Paradigm Plus

PTECH
Rational CASE
family

Tehnike i razvojni
alati

Sistemi upravljanja
bazama podataka
SQL, DB2,
IMS-DL/1, Oracle
Sybase, Oracle,
Informix, Ingres,
OCM
Oracle, DB2

Novell Btrieve,
SQL, Sybase,
Oracle, Informix

Ingres 4GL,
Informix 4GL,
Uniface Six
Ingres 4GL,
Informix 4GL

Ingres, Informix,
Sybase

sopstveni ugraeni
C++ generator koda
ProtoScrpt, C, C++,
Ada, SmallTalk,
PowerBuilder, SQL,
JAVA, Corba IDL,
Visual Basic

OODBMS

Ingres, Informix,
SQL

ORACLE 7, dBase,
DB2, uniSQL,
Access, Centura,
SQLB ase,
Sybase/SQL,
objectStore,
gemStone
OODBMS
Oracle 7, Sybase,
SQLBase,
SQLServer,
Watkom SQL,

UML
System
Architect

ObjectMaker

GDPro

StP Software
Through
Pictures

Gane-Sarson,
Ward-Mellor,
Catalyst, CoadYourdon,
OOA/OOD,
deMarco, ShlaerMellor, OMT,
Martin IE, Booch
OpenOML, Colbert,
OMT, Booch, CoadYourdon
ER/Studio

Booch, OMT

SQLWindows,
VisualBasic
C++, Java,
SmallTalk, Corba,
Delphi, Gupta,
ADA, Magic,
PowerBuilder,
VisualBasic

Ansi SQL
DB2, dBase,
SQLServer, Oracle,
Sybase, InterBase,
SQLBAse, Watkom,
Progress

C, C++, AAD

Oracle, SQL

C++, Java, CorbaIDL, VisualBasic

Access,
OOParabase
Repository
Sybase

C++, Java, ADA,

Corba-IDL,
Forte/tool

5.2 Vizuelno modelovanje - UML

Akronim UML je danas meu najpoznatijim u informatikom svetu i oznaava termin Unified Modeling
Language, to u prevodu znai jedinstveni jezik za modelovanje. UML predstavlja jedinstveni jezik za
vizuelizaciju, specifikaciju, konstrukciju i dokumentovanje softverskih reenja.
Grafiki jezici poput UML-a se koriste ve due vremena u razvoju softvera. Meutim, ono to je
specifino za sve njegove pretee, jeste njihova neusaglaenost, koja je i bila kljuna za nastanak i razvoj
UML-a.
UML je nastao objedinjavanjem vie objektno orijentisanih grafikih jezika za modelovanje. Tvorci UML-a
su trojica strunjaka, poznata u informatikom svetu pod nadimkom tri amigosa, Grady Booch, Jim
Rumbaugh i Ivar Jacobson. Svaki od njih je razvijao sopstveni objektno orijentisani jezik za modelovanje,
da bi se udruili pod okriljem firme Rational (danas u sastavu IBM-a) i miksom pojedinanih jezika stvorili
UML. Prva zajednika verzija UML-a, nastala radom ova tri autora, jeste verzija 1.0 lansirana na trite
1997. godine, koja je posedovala osobine standarda i bila opteprihvaena od svih uesnika u razvoju
informacionih sistema. Od tada brigu za UML preuzima grupa OMG, tj. grupa za upravljanje objektima
(Object Management Group, OMG).
Trenutno aktivna verzija UML-a jeste 2.0. U njoj postoji 13 vrsta dijagrama, strukturiranih u dve osnovne
grupe: dijagrami ponaanja i dijagrami strukture. U procesu razvoja softvera pojavljuju se razne uloge
koje koriste razliite tehnike dijagramiranja, za reavanje razliitih problema. To u stvari znai da brojni
uesnici u procesu razvoja razgovaraju istim jezikom. Da ne bi dolo do zabune, potrebno je
napomenuti da se proces razvoja ne moe obaviti samo sa UML-om. Meutim, standardizacijom i
optim prihvatanjem UML-a stvoreni su preduslovi da sve aktivnosti koje se ne realizuju UML-om budu
usaglaene sa aktivnostima koje se realizuju pomou njega. U nastavku se ukratko opisuju 13 vrsta UML
dijagrama.

UML dijagrami

Dijagrami ponaanja

Dijagrami
sluajeva
upotrebe

Dijagrami
aktivnosti

Dijagrami
sekvenci

Dijagrami strukture

Dijagrami
maine stanja

Dijagrami
saradnje

Dijagrami
interakcije

Dijagrami
klasa

Dijagrami
pregleda
interakcija

Vremenski
dijagrami

Dijagrami
objekata

Dijagrami
sloene
strukture

Dijagrami
rasporeda

Dijagrami
komponenti

Dijagrami
paketa

Vrste UML dijagrama u verziji 2.0

Dijagrami sluajeva upotrebe (Dijagram korisnikih funkcija)

Dijagrami sluajeva upotrebe slue za grub opis funkcionalnosti posmatranog sistema ili posmatranog
dela organizacije. U principu se moe konstatovati da postoje dve vrste ovih dijagrama: dijagrami
sluajeva upotrebe (Use Case Diagrams) i dijagrami sluajeva upotrebe poslovnog procesa (Business Use
Case Diagrams). Dijagrami sluajeva upotrebe treba da daju odgovor na pitanje ta sistem radi?, dok
dijagrami sluajeva upotrebe poslovnog procesa treba da daju odgovor na pitanje ta organizacija
radi?. Pomou dijagrama sluajeva upotrebe predstavljaju se funkcije sistema koje e biti
automatizovane, a pomou dijagrama sluajeva upotrebe poslovnog procesa i automatizovane i
manuelne funkcionalnosti.

Pregled racuna

Operater

Pretplatnik

Podnosenj e zahtev a za
pregled racuna

Komponente ovih dijagrama su akteri, uloge, sluajevi upotrebe i relacije. Akteri predstavljaju nekoga ili
neto to se nalazi izvan sistema ili organizacije (u zavisnosti od vrste dijagrama), a u interakciji je sa
njim. Uloge se koriste samo prilikom izrade dijagrama sluajeva upotrebe poslovnog procesa i
predstavljaju nekoga ili neto to se nalazi unutar organizacije i u interakciji je sa funkcionalnostima
posmatranog dela organizacije. Sluajevi upotrebe i sluajevi upotrebe poslovnog procesa slue da bi se
prikazale konkretne funkcionalnosti sistema, odnosno organizacije. Ovi dijagrami predstavljaju vodilju za

kompletan proces razvoja softvera, pa se esto za razvoj zasnovan na UML-u kae da je usmeravan
sluajevima upotrebe.
Dijagrami aktivnosti
Dijagrami aktivnosti slue za opisivanje logike procedura, poslovnih postupaka i toka posla. Tokovi
funkcionalnosti predstavljeni dijagramima sluajeva upotrebe se opisuju dijagramima aktivnosti, koji
prikazuju sve aktivnosti koje se odvijaju u okviru posmatrane funkcionalnosti. Pomou jednog dijagrama
aktivnosti mogue je prikazati vie potencijalnih scenarija koji se mogu desiti pri izvravanju neke
funkcionalnosti. Ukoliko se na dijagramima sluajeva upotrebe sluaj upotrebe posmatra kao crna
kutija, na dijagramima aktivnosti se prikazuje redosled izvravanja aktivnosti u okviru te crne kutije.
Dijagrami aktivnosti sadre: stanja aktivnosti i stanja akcije, tranzicije, objekte, grananja, poetnu
(oznaava se crnim krugom) i krajnju taku (oznaava se crnim krugom u belom krugu). Izmeu poetne
take i prve akcije navodi se dogaaj koji je pobuuje. Tranzicije povezuju poetnu taku, akcije i krajnju
taku i predstavljaju se usmerenim linijama. Ukoliko se tranzicije granaju, taka u kojoj se vri grananje
prikazuje se rombom.Stanja aktivnosti i akcija navode se u elipsama, a za objekte vai standardna
notacija.

Prikuplj anj e
zahtev a

[Korektni zahtevi]

Obrada
zahtev a

Pristigle zahtevi

[Nekorektni zahtevi]

Dijagrami stanja maine

Ovi dijagrami slue za prikazivanje ponaanja dela sistema, odnosno ponaanje objekta kao instance
posmatrane klase. Na njima se predstavljaju stanja posmatranog objekta, tranzicije izmeu stanja i
dogaaji koji uzrokuju tranzicije objekta iz jednog u drugo stanje. Crtanje dijagrama stanja maine se ne
preporuuje za sve klase sistema. Najee se crtaju za najznaajnije klase sistema ili se uopte ne crtaju
ukoliko razvojni tim informacije koje se dobijaju ovim dijagramima dobije na drugi nain.
Predstavljaju uoptenje dijagrama aktivnosti. Pomou dijagrama stanja se modeluju dinamiki aspekti
sistema koji se projektuje. Koriste se za modelovanje ivotnog veka objekta, a najee se modeluju
stanja objekata koji reaguju.
Na dijagramu se, u obliku konanog automata, prikazuje odvijanje upravljanja od stanja do stanja. Ovo
se prikazuje tako to se stanje prikazuje pravougaonikom sa zaobljenim ivicama, dok je tranzicija relacija
izmedju dva stanja i prikazuje se strelicom, a stanje od kojeg poinje kreiranje ovog konanog automata
se prikazuje crnim kruiem.

Neaktiv an

Pov ezan

Obrada
Poziv anj e

Dijagrami sekvenci i dijagrami saradnje

Ove dve vrste dijagrama prikazuju iste informacije iz razliitih perspektiva. Pomou njih se predstavljaju
objekti koji se pojavljuju u okviru sluaja upotrebe i poruke koje oni razmenjuju. Razlika izmeu ovih
dijagrama je u tome to dijagrami sekvenci u prvi plan stavljaju vremensku dimenziju, tj. razmenu
poruka sa aspekta vremena, dok dijagrami saradnje zanemaruju vremensku dimenziju i prikazuju
saradnju objekata kroz razmenu poruka. CASE alati pomou kojih se crtaju ovi dijagrami omoguavaju
automatsko generisanje jedne vrste dijagrama, na osnovu nacrtanog dijagrama druge vrste.
Dijagram sekvence predstavlja specijalni sluaj dijagrama interakcije, a njime se prikazuje skup poruka
razmenjenih izmeu objekata koji sarauju, da bi se realizovala odreena operacija ili dobio neki
rezultat. Ovaj dijagram se prikazuje u dve dimenzije: vertikalna dimenzija prikazuje vreme, a
horizontalna odreene objekte.
Na dijagramu se prikazuju poruke koje se razmenjuju u definisanom vremenskom redosledu izmeu
uoenih objekata. Meu objektima se uspostavljaju veze, a dijagramom se prikazuje linija ivota svakog
prikazanog objekta. Isto tako ovi dijagrami sadre fokus upravljanja kojim se prikazuje vremenski period
u kojem objekat vodi neku akciju.

Pretplatnik

Transakcija

Upisi klijenta(a,b,c)

Uradjeno

Prekini

Elementi dijagrama sekvenci se predstavljaju na sledei nain:


objekti se prikazuju na ranije opisani nain,

veze izmeu objekata su poruke, koje se prikazuju poloenim usmerenim linijama,

linija ivota objekta je vertikalna isprekidana linija,

fokus upravljanja se predstavlja uzanim, vertikalno postavljenim pravougaonikom.
Dijagrami saradnje su semantiki ekvivalentni dijagramima sekvence. Pomou njih se istie strukturna
organizacija objekata koji uestvuju u interakciji. Za razliku od dijagrama sekvence, dijagrami saradnje ne
sadre liniju ivota objekta niti fokus upravljanja, ve sadre objekte iz interakcije sa vezama koje sadre
poruke izmeu njih.
Objekti se prikazuju kao vorovi grafa, a poruke izmeu ovih objekata peikazuju se kao grane grafa.
Poruke mogu imati svoje redne brojeve (sa prefiksom), a koji oznaavaju redosled razmene poruka. Ovaj
redosled formira putanju poruka, koja se takoe oznaava i usmerenim strelicama na granama grafa.

Pretplatnik

1. Upisi klijenta (a, b, c)

Transakcij a

2. Uradjeno

3. Prekini

Dijagrami pregleda interakcija

Dijagrami pregleda interakcija su jedna od novina verzije 2.0. Predstavljaju kombinaciju dijagrama
aktivnosti i dijagrama sekvenci. Mogu se posmatrati kao dijagrami aktivnosti u kojima su aktivnosti
zamenjene sa dijagramima sekvenci.
Vremenski dijagrami
Vremenski dijagrami su takoe novina u verziji 2.0. Iako se odavno koriste pri reavanju elektrotehnikih problema, tek su u verziji 2.0 uvrteni u UML. Ova vrsta dijagrama je slina dijagramima stanja
maine, sa tom razlikom to se vreme pojavljuje kao inicijator promene stanja objekta. Pored
mogunosti praenja promena stanja jednog objekata mogue je pratiti i uporeivati promenu stanja
vie objekata. Dakle, ovi dijagrami prikazuju stanja u koja objekti dolaze nakon unapred predefinisanog
vremenskog intervala.
Dijagrami klasa
Dijagrami klasa predstavljaju kljune dijagrame za opisivanje strukture sistema. Klasa predstavlja osnovni
pojam u objektnom razvoju, te kao takva predstavlja i osnovnu komponentu objektno razvijanog
sistema. Ovi dijagrami opisuju klase sistema i to kroz opis njima pripadajuih atributa, operacija i relacija
izmeu klasa.
Atributi predstavljaju obeleja koja opisuju svojstva klase. Navode se u okviru klase, a svaki atribut moe
da poseduje sledea svojstva: vidljivost, ime, tip, multiplicitet, podrazumevanu vrednost, kao i opis nekih
dodatnih svojstava atributa (npr. itljivost). Operacije opisuju poslove koje e objekat, kao konkretna
pojava klase, znati da obavi. Kada se od objekta zahteva da obavi neki posao, to se moe zahtevati samo
preko operacije koju on poseduje. I operacije, kao i atributi poseduju odgovarajua svojstva, i to:
vidljivost, ime, listu parametara, tip rezultata operacije, itd. Relacije slue da bi se prikazao meusobni

odnos klasa. Izmeu klasa mogu da postoje sledee vrste relacija: asocijacija, agregacija, zavisnost i
generalizacija.
Dijagrami objekata
Dijagrami objekata su postojali i u ranijim verzijama UML-a, ali kao neformalni dijagrami. Od verzije 2.0
zvanino postaju UML dijagrami. Slue da prikau objekte posmatranog dela sistema u posmatranom
trenutku. Najsliniji su dijagramima saradnje, ali bez tretiranja poruka koje objekti razmenjuju. Koriste se
da bi se dodatno opisala struktura sistema, u situacijama kada dijagrami klasa ne daju dovoljno
kvalitetan opis iste.
Dijagrami komponenti
Dijagrami komponenti slue da bi se prikazale komponente sistema. Pod komponentama se
podrazumevaju takvi delovi sistema koji se mogu samostalno isporuivati krajnjim korisnicima. Naravno
da sve ove komponente moraju biti tako meusobno usaglaene da dodavanje nove komponente u
sistem ne izazove poremeaje kompletnog sistema. Uobiajeno svaka komponenta se sastoji od jedne ili
vie klasa i predstavlja nezavisnu celinu, koja je povezana sa ostatkom sistema pomou interfejsa. Na
ovakav nain se postie da promene u jednoj komponenti ne deluju destruktivno na ostatak sistema, jer
interfejs i dalje uva integritet komponente i ostatka sistema. To su, u stvari, dijagrami klasa kod kojih je
panja usmerena na komponente sistema. Na taj nain se prikazuje konstrukcija izvrnih softverskih
sistema.
index.html find.html
find.exe

dbasic.dll

nateng.dll

Dijagrami paketa
Paketi predstavlju mehanizme za grupisanje UML elemenata. Iako se najee koriste za grupisanje
klasa, mogu se koristiti i za grupisanje drugih elemenata, npr. za grupisanje sluajeva upotrebe, za
grupisanje entiteta ili za grupisanje komponenti sistema. Predstavljaju se pomou pravougaonika sa
jezikom u levom gornjem uglu, na kojem je ispisan naziv paketa. Izmeu paketa se povlae relacije
zavisnosti, koje govore da se neki od elemenata smetenih u pakete izmeu kojih postoji zavisnost
nalaze u meusobnom odnosu.
Ukoliko govorimo o paketima klasa, tada bi do njihovog kreiranja moglo doi, npr. radi grupisanja
hijerarhijske strukture klasa ili grupisanja klasa ije su instance u meusobnoj zavisnosti predstavljenoj
na dijagramima sekvenci ili dijagramima saradnje. Mogue je takoe praviti pakete na osnovu
stereotipova klasa. Dakle, ukoliko se klase nalaze u logikoj ili fizikoj povezanosti mogue ih je smestiti u
paket klasa i predstaviti vie takvih paketa na dijagramu paketa. Ovi su dijagrami, iako ranije nezvanino
korieni, novina u UML verziji 2.0.

Dijagrami sloene strukture

Dijagrami sloene strukture prikazuju saradnju klasa, interfejsa ili komponenti u cilju opisa strukture
zaduene za izvravanje posmatrane funkcionalnosti. Ovi dijagrami su slini dijagramima klasa. Razlika je
u tome to dijagrami klasa prikazuju statiku strukturu sistema, kroz prikaz klasa sa njihovim atributima i
operacijama, a dijagrami sloene strukture prikazuju izvrnu arhitekturu, relacije izmeu njenih
gradivnih elemenata i odnos posmatrane arhitekture sa okruenjem, u cilju prikazivanja informacija koji
se ne mogu prikazati pomou statikih dijagrama. Dijagrami sloene strukture su takoe novina u verziji
UML-a 2.0.
Dijagrami rasporeivanja
Dijagrami rasporeivanja slue za predstavljanje hardverske arhitekture sistema. Oni prikazuju delove
sistema rasporeene po fizikim lokacijama. Ovi dijagrami se mogu posmatrati i kao prikaz
arhitekturalnog reenja celokupnog sistema. Pomou njih se prikazuje konfiguracija procesnih vorova u
toku izvravanja i komponenti koje se nalaze u njima. Predstavljaju posebnu vrstu dijagrama klasa
namenjenih statikom prikazu rasporeenosti hardvera sistema. Sastoje se iz vorova, koji se prikazuju u
obliku kvadra, kao i relacija izmeu ovih vorova.
Opisani UML dijagrami mogu se koristiti u razliitim fazama razvoja softvera. U fazi analize najee se
koriste: dijagrami sluajeva upotrebe, dijagrami aktivnosti i dijagrami stanja maine, dok se u fazi
projektovanja uobiajeno koriste: dijagrami klasa, dijagrami sekvenci i saradnje, dijagrami paketa,
dijagrami rasporeivanja.

Internet
server za
keiranje

server za
keiranje

lokalna mreza

primarni
server

server

server

server