Knjiga Projektovanje IS PDF

prof. dr ing poliuk e.
jaroslav
projektovanje
informacionih
sistema
Poliuk E. Jaroslav: Projektovanje informacionih sistema
Prof. dr ing Poliuk E. Jaroslav

PROJEKTOVANJE INFORMACIONIH SISTEMA
Kompjuterska obrada knjige: autor

E-mail: jaroslav@cg.ac.yu
Sva prava zadrava autor.
PREDGOVOR
"Klasina predstava o svemiru, koji se sastoji od materije i energije, mora da
ustupi mjesto predstavi o svijetu sastavljenom od tri komponente: energije, materije i
informacija, jer bez informacija organizovani sistemi nisu mogui. Jedino mogue
materijalistiko tumaenje odravanja organizovanosti je neprekidno izvlaenje iz
spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima
koji se tu odvijaju" [A. Lerner, 2003].
Predvianje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA,
vodea u svijetu u analizi kretanja u oblasti globalne industrije informatike tehnologije,
glasi: Trend automatizacije informatikih tehnologija e imati veliki uticaj na razvoj
softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehniku podrku i
umreavanje. Neka informatika zaduenja e biti vea, neka e biti umanjena, neka
prebaena u druge dijelove kompanije, a neka e biti ukinuta".
Specijalizovani informatiki radnici, koji se istiu samo svojim poznavanjem
informatikih tehnologija i vjetinama vezanim za raunare, bez posjedovanja drugih
funkcionalnih znanja, bie manje potrebni, predviaju Gartner-ovi analitiari.
Prosjeno informatiko odijeljenje u srednjim i velikim kompanijama e do 2010.
godine biti za trideset procenata manje, tvrde analitiari trita kompanije Gartner, i
zakljuuju: Informatiki radnici budunosti e biti zaposleni u jednom od etiri glavna
podruja: tehnolokoj infrastrukturi, projektovanju i upravljanju informatikim
sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima.
Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, raena na
osnovu dostupne literature i obrauje savremeni pristup projektovanju IS. Izvori, na
osnovu kojih je nastala ova knjiga, jednim dijelom su navedeni u samom tekstu knjige,
dok je cjelovit pregled dan u okviru pregleda koritene literature. Zahvaljujem se
autorima iji su manji dijelovi radova, u djelimino izmijenjenom obliku, uli u sastav
ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglaeno, taj
propust e rado biti naknadno otklonjen. U pojedinim sluajevima bilo je nemogue
razgraniiti autorstvo pojedinih tekstova, jer se isti ili slian tekst mogao nai u
razliitim izvorima.
Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalistikog
studija Elektrotehnikog fakulteta u Podgorici i moe posluiti kao potrebna literatura.
Knjiga moe korisno posluiti projektantima IS, kao i svima koji se bave razvojem
savremenih IS ili ele da se detaljnije upoznaju sa ovom oblasti.
U Podgorici, septembar 2007. god.
Autor
SADRAJ
1. Opte o informacionim sistemima ...........................................................
1.1. Uvod ......................................................................................................
1.2. Pojam informacionog sistema................................................................
1.3. Elementi i osobine sistema i informacionih sistema ..............................
1.4. Vrste informacionih sistema ..................................................................
1.5. ivotni ciklus razvoja sistema ................................................................
1.6. Kompleksnost razvoja informacionog sistema ......................................
9
9
11
13
15
16
18
2. Planiranje razvoja informacionog sistema ..............................................

2.1. Modaliteti razvoja informacionog sistema .............................................
2.2. Analiza izvodljivosti, trokova i koristi projekta ......................................
2.3. Strategija i planiranje razvoja informacionog sistema ............................
2.4. Modeli razvoja informacionih sistema ....................................................
2.5. Metodologija razvoja informacionih sistema ..........................................
2.6. Savremeni postupci razvoja informacionog sistema ..............................
21
21
27
30
38
48
51
3. Uvod u projektovanje i definisanje zahtjeva za

informacionim sistemom ...........................................................................
3.1. Uvod u projektovanje i izgradnju informacionog sistema .......................
3.2. Definisanje zahtjeva za informacionim sistemom ...................................
57
57
60
4. Analiza sistema ...........................................................................................

4.1. Uvod u analizu sistema ..........................................................................
4.2. Aktivnosti analize ...................................................................................
4.3. Definisanje zahtjeva koje sistem mora posjedovati ...............................
67
67
67
69
5. Modeliranje funkcija i procesa .................................................................. 77

5.1. Uvod u modeliranje funkcija i procesa ................................................... 77
5.2. Metode strukturiranog modeliranja, analize i
dokumentovanja tehnolokih procesa ................................................... 83
5.3. Modeliranje toka podataka ..................................................................... 89
5.4. Elementarni procesi ............................................................................... 98
6. Modeliranje podataka ............................................................................... 101

6.1. Osnovni pojmovi modela podataka ...................................................... 101
6.2. Razvoj modela podataka ..................................................................... 111
6.3. Logiko modeliranje podataka ............................................................. 116
7. Modeliranje dogaaja ................................................................................. 123
7.1. Modeliranje procesa voeno dogaajima .............................................. 123
7.2. Matrica entiteti/dogaaji ......................................................................... 124
7.3. Model istorije ivota entiteta .................................................................. 128
7.4. Dijagram prelaza stanja ............................................ 129
7.5. Mape dijaloga .. 130
8. Inenjerski pristup izgradnji IS ................................................................. 132
8.1. Uvod ...................................................................................................... 132
8.2. Programsko inenjerstvo ....................................................................... 133
8.3. Informaciono inenjerstvo ..................................................................... 134
8.4. Sistemsko inenjerstvo ......................................................................... 135
8.5. CASE proizvodi ..................................................................................... 136
8.6. Reverzno inenjerstvo ........................................................................... 148
9. Oblikovanje i arhitektura informacionog sistema .................................. 151
9.1. Oblikovanje (dizajn) sistema ............................................................... 151
9.2. Arhitektura informacionog sistema ..................................................... 153
10. Dizajn baza podataka ................................................................................ 162
10.1. Uvod u dizajn baza podataka ............................................................. 162
10.2. Normalizacija ...................................................................................... 163
10.3. Denormalizacija .................................................................................. 164
10.4. Ugradnja pravila za ouvanje integriteta ............................................ 165
10.5. Podeavanje baze podataka .............................................................. 166
10.6. Trigeri u relacionim bazama podataka ............................................... 168
10.7. Implementaciono projektovanje, generisanje i
programiranje BP pomou CASE alata ............................................... 176
10.8. ifarski sistem .................................................................................... 180
10.9. Rjenik podataka katalog ................................................................ 181
11. Dizajn programske podrke .....................................................................
11.1. Specifikacija i dizajn programske podrke .........................................
11.2. Pristup oblikovanju programa .............................................................
11.3. Strukturirani dizajn .............................................................................
11.4. Dizajn interfejsa ..................................................................................
11.5. Ulanavanje procedura ....................................................................
11.6. Organizacija modula i aplikacija ........................................................
11.7. Standardizacija i modularnost programske podrke .......................
186
186
186
187
191
194
195
196
12. Implementacija informacionog sistema ..................................................

12.1. Izrada sistema ....................................................................................
12.2. Programiranje (kodiranje) ....................................................................
12.3. Pristup programiranju .........................................................................
12.4. Programski standardi i preporuke ......................................................
12.5. Provjera ispravnosti informacionog sistema .......................................
12.6. Izrada dokumentacije .........................................................................
201
201
201
202
204
209
211
13. Logiko projektovanje programa i programski jezici .............................

13.1. Dijagram toka (blok dijagram, algoritam) ............................................
13.2. Strukturirani prirodni jezik (pseudokod) ..............................................
13.3. Akcioni dijagram .................................................................................
13.4. Stablo odluivanja ..............................................................................
13.5. Tabele odluivanja ..............................................................................
13.6. Struktogram ........................................................................................
13.7. Programski jezici ................................................................................
213
213
216
221
222
224
225
226
14. Organizacija i upravljanje projektom .......................................................

14.1. Generiki modeli organizacije ............................................................
14.2. Organizacija i timski rad .....................................................................
14.3. Modeli timova .....................................................................................
14.4. Organizacija velikih projekata ............................................................
14.5. Upravljanje projektom ........................................................................
14.6. Planiranje projekata ...........................................................................
14.7. Tehnike za vremensko planiranje ......................................................
14.8. Izrada plana .......................................................................................
14.9. Prikaz plana .......................................................................................
14.10. Raspodjela zadataka .......................................................................
14.11. Evidencija projekta ..........................................................................
14.12. Praenje napretka (izvrenja) projekta ............................................
14.13. Preporuke za planiranje poslova .....................................................
233
233
233
234
235
236
236
237
238
239
240
241
242
243
15. Primjena i odravanje informacionog sistema .......................................

15.1. Uvoenje sistema u primjenu .............................................................
15.2. Obuka korisnika IS .............................................................................
15.3. Odravanje informacionog sistema ....................................................
15.4. Poboljanje sistema i reinenjerstvo ..................................................
15.5. Elementi konfiguracije ........................................................................
245
245
246
246
247
248
Literatura .......................................................................................................... 251
1. Opte o informacionim sistemima

1.1. Uvod
Projektovanje informacionih sistema (IS) je kompleksna kreativna djelatnost koja
zahtijeva sistemski pristup, metodologiju primjerenu tehnolokim mogunostima. Za
organizaciju koja modernizuje IS, i prati dostignua u tehnologiji i metodologiji
projektovanja, nije svrsishodno teiti za standardom koji bi vrsto definisao pristup,
metodu, sredstva i dokumentaciju, ne uzimajui u obzir vrstu primjene, stepen razvoja
IS, karakteristike korisnika i osobine realnog sistema u kome IS djeluje.
Brzi tehnoloki razvoj zahtjeva da se dugorono zna ta se hoe. Neophodno je
imati strategijsku sliku razvoja IS, koja e obezbjediti kompatibilnost sistema i biti
fleksibilna u prihvatanju nove tehnologije. Totalno integrisani IS je nedostian i
nepotreban. Ono to je potrebno je dovoljno slobode kako bi korisnici mogli da
razvijaju svoju inicijativu u kreiranju sistema koji im je potreban. Pri tome je potrebno
potovanje pravila koja e omoguiti da razmjenjuju podatke, ta podrazumjeva
zajedniku mreu za prenos, zajedniki model podataka i njihov standardni oblik.
U prolosti je razvoj programskih proizvoda bio oslonjen na razliite tipove alata
za programiranje. U prvoj fazi razvoja u upotrebi su bili mainski jezici (jezici 1.
generacije), ija je itljivost bila veoma mala i koji su zavisili od hardvera. U drugoj fazi
se koriste asembleri (jezici 2. generacije), koji su, takoe, bili zavisni od hardvera i
teko itljivi. Poslije jezika 1. i 2. generacije, u treoj fazi, u upotrebu su uli jezici 3.
generacije (3rd generation languages (3GL)). Jezici 3. generacije su, kao i mainski
jezici i asembleri, proceduralno orijentisani. Sa jezicima 3GL, u upotrebu je ula i
tehnika strukturiranog programiranja. Bitna karakteristika 3GL je njihova nezavisnost
od hardvera.
Osnovna prednost uvoenja u upotrebu jezika 3. generacije je bilo poveanje
produktivnosti programiranja, odnosno poveanje kvaliteta i brzine realizacije
programskih proizvoda. Sa druge strane, poveanje produktivnosti je uzrokovalo
smanjenje performansi (brzine rada) tadanjih programskih proizvoda i funkcionalnosti
(irine primjene) 3GL. Problem smanjenja performansi je rjeavan uvoenjem u
upotrebu sve monijeg hardvera, a problem smanjene funkcionalnosti je rjeavan
10
tehnikom povezivanja programa, pisanih pomou 3GL, sa asemblerskim programima,

ili daljim poveanjem mogunosti samih 3GL.
Meutim, oekivanja da e programski proizvodi, koji su razvijeni upotrebom 3GL,
pratiti potrebe krajnjih korisnika i mogunosti hardvera se ve 70-ih godina nisu
ostvarila, to je dovelo do fenomena nazvanog softverska kriza. Osnovni pojavni oblik
softverske krize je bio u tome da oekivani efekti od razvoja programskih proizvoda
brzo izostaju, bez obzira na znatno poveanje ulaganja u ovu djelatnost, to je
ilustrovano dijagramom na slici 1.1. Identifikovani su slijedei problemi kroz koje se
softverska kriza prelamala. Programiranje upotrebom 3GL je bilo neefikasno i
dugotrajno. Najvei dio programerskog vremena je odlazio na odravanje postojeih
programskih proizvoda, to je blokiralo dalji razvoj IS.
Tvrdnja da je najvei dio programerskog vremena odlazio na odravanje
postojeih programskih proizvoda se moe potkrijepiti slijedeim statistikim podacima.
Prema tim podacima 64% greaka pri razvoju IS se pravilo u toku analize korisnikih
zahtjeva i projektovanja IS, dok se preostalih 36% greaka pojavljivalo tokom
realizacije IS. Od pomenutih 64% ranih greaka, svega 30% je otklonjeno prije
isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje greaka iz poetnih faza
razvoja programskih proizvoda dovodi do eksponencijalnog rasta trokova uvoenja u
upotrebu i odravanje proizvoda. Tako, na primjer, otklanjanje strateke greke u fazi
odravanja kota 100 puta vie nego kad se greka otkrije na poetku rada na
projektu. Ovo je dovelo do jedne neprirodne raspodjele finansijskih sredstava,
uloenih u razvoj IS, prema kojoj preko 70% ukupnih sredstava uloenih u razvoj IS
odlazi na njegovo odravanje [Mogin et al. 2000].
Oekivani efekti ulaganja
Ulaganje u softver, hardver, ljudske

resurse i razvoj programskog proizvoda
Slika 1.1. Grafiki prikaz fenomena softverska kriza.

Poveanje cijene odravanja i neefikasno programiranje su doveli do velikih
zakanjenja u realizaciji projekata IS. Prema nekim podacima, veliki projekti u SAD su
11
1985. godine kasnili od 30 do 45 mjeseci. U skladu sa navedenim injenicama,

vremenom su identifikovani slijedei uzroci softverske krize:
1. Projektovanje IS bez primjene odgovarajue metodologije dovodi do loeg
projekta, pojave velikog broja greaka i prekoraenja zadanih vremenskih
rokova zavretka projekta;
2. Nedostatak softverskih alata, koji bi podrali projektovanje IS ili automatizovali
postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo, takoe,
vodi ka nekvalitetnom projektu uslijed oteanog rukovoenja projektom,
fragmentiranog i nekonzistentnog dokumentovanja i neusaglaenosti dijelova
projekta IS;
3. Nedostatak odgovarajuih softverskih alata za razvoj aplikacija IS, to vodi ka
neefikasnoj realizaciji i odravanju IS.
Svi ovi uzroci su doveli do prethodno opisanih posljedica. Rjeenje softverske
krize je, prema tome, trebalo traiti u otklanjanju navedena tri uzroka. To je vodilo ka
formalizaciji metodologija i tehnika projektovanja IS i pojavi CASE proizvoda i jezika 4.
generacije (4th generation languages (4GL)), kao podrke odgovarajuim tehnikama i
metodologijama.
1.2. Pojam informacionog sistema

Metodologija razvoja informacionih sistema (IS) treba da bude opta, primjenljiva
na sisteme bilo koje vrste, odnosno na neki "opti sistem". Zahtjeva da se precizno
definie ta se pod pojmom IS podrazumjeva, koje su njegove funkcije i kakav je
njegov poloaj u sistemu u kome djeluje. Iz tih razloga je potrebno poi od slijedeih
optih pojmova i definicija.
Sistem je skup objekata i njihovih veza (medjusobno povezanih objekata). Objekti
u sistemu se opisuju preko svojih svojstava koja se nazivaju atributima.
Objekti nekog sistema su povezani sa objektima van njegovih granica, a ovi sa
nekim drugim "daljim" i tako dalje. Granice sistema definiu skup objekata koji e se u
tom sistemu posmatrati. Zato je neophodno odrediti granice sistema koje izoluju
objekte od interesa od "okoline" sistema. Dejstvo okoline na sistem naziva se "ulaz", a
dejstvo sistema na okolinu "izlaz" sistema. Sistem na slici 1.2 moe predstavljati
poslovni sistem, mreu puteva ili ulica, sistem za prenos elektrine energije, cirkulaciju
12
dokumenata unutar nekog poslovnog sistema, kretanje materijala koji se obrauje, itd.
Objekti u sistemu mogu biti veoma razliiti, a veze izmedju objekata u sistemu i dejstvo
okoline na sistem se ostvaruje na tri naina: razmjenom materije, energije ili
informacija.
OKOLINA
ULAZ
O1
O2
O3
On
(interfejs)
IZLAZ
Slika 1.2. Opti prikaz sistema.

Rije informacija, u svakodnevnom govoru, ima smisao obavjetavanja,
objanjenja, prenoenja znanja. Za pojam informacije uobiajene su slijedee
definicije:
"Informacija je kapacitet poveanja znanja" [I. Wilson, 1975];
"Informacija je neto to ukida ili smanjuje neodreenost" [N. Winer, 1979].
Iz ugla upravljanja i donoenja odluka, informacija se moe razmatrati kao svaka
vrsta znanja ili poruka koja moe da se upotrijebi za poboljanje upravljanja u nekom
sistemu. Ako se poveu definicije pojmova sistema i informacije, moe se izvesti
slijedea opta definicija informacionog sistema:
Informacioni sistem (eng. Information System) je sistem u kome se veze
izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija.
Takoe, informacioni sistemi su sastavni deo upravljanja ("odranja eljene
organizovanosti") nekog sistema. Iz tog ugla posmatranja moe im se pridodati atribut
"upravljaki" i definisati upravljaki IS kao sistem koji prenosi, uva i obrauje podatke
pretvarajui ih u informacije potrebne za upravljanje.
Pojmovi podatak i informacija se, u svakodnevnom govoru, koriste kao sinonimi.
Medjutim, za precizno razgranienje koncepata o kojima se govori, neophodno je i ova
dva pojma precizno definisati i razgraniiti.
13
Podatak je kodirana predstava o nekoj injenici iz realnog svijeta, on je nosilac

informacije i slui za tehniko uobliavanje informacija, kako bi se one mogle sauvati
ili prenijeti.
Informacija je protumaeni podatak o pojavi koju podatak prikazuje.
Krajnje tumaenje nekom podatku daje sam primalac (ovjek), uz pomo razliitih
postupaka obrade podataka. Osnovna funkcija IS je uvanje i prenos podataka o
injenicama iz sistema i njegove okoline i njihova obrada u informacije koje zahtjeva
korisnik.
Znanje se gradi na osnovu novih informacija koje se nadovezuju na postojee
znanje.
Isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u zavisnosti o
njihovom znanju.
1.3. Elementi i osobine sistema i informacionih sistema

Mogu se izdvojiti slijedei elementi sistema i definisati njihove glavne osobine:
1. Podsistemi, odnosno komponente koje pripadaju sistemu;
2. Granice, definiu opseg i domaaj sistema;
3. Okolina je sve to je izvan granica sistema, ali se jo uvijek tie sistema;
4. Ulazi su elementi koji ulaze u sistem iz okoline;
5. Izlazi su elementi koji naputaju sistem;
6. Interfejs je veze izmeu sistema i njegove okoline;
7. Ogranienja, koja sainjavaju unutranji i vanjski inioci koji odreuju i
ograniavaju funkcionisanje sistema;
8. Karakteristike,
integrisanost.
koje
opisuju
organizaciju,
interakciju,
meuzavisnost
Organizacija je struktura i poredak, odnosno hijerarhijske veze koje odreuju

formalnu komunikaciju i upravljaki lanac (npr. ustanova, preduzee). Interakcija
predstavlja nain na koji pojedine komponente sarauju sa drugim komponentama
(npr. Nabavka sa Proizvodnjom, Proizvodnja sa Prodajom). Meuzavisnost pokazuje
14
da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati, dok je

integrisanost mjera povezanosti komponenti.
Za informacione sisteme se mogu izdvojiti bitni elementi i definisati njihovne
glavne osobine: (1) sistemi za obavjetavanje, odnosno informacioni sistemi; (2)
sistemi za upravljanje informacijama vanim za organizaciju i drutvo; (3) sistemi za
upravljanje sadrajem ljudskih aktivnosti [Checkland, 1980].
Pojam informacionog sistema podrazumijeva sisteme koji su podrani raunarom,
tj. raunarski (kompjuterizovani, kompjuterski) i sisteme koji se ne oslanjaju na
raunare, ali obrauju informacije. Namjena IS je prikupljanje i pruanje informacija
korisnicima u jednom ili vie poslovnih sistema, te se mogu nazvati organizacioni IS.
Korisnici informacionih sistema su poslovodstvo, radnici (zaposleni, osoblje), klijenti i
drugi. Upravljanje informacijama se obavlja bez obzira na vrstu sistema, a sainjavaju
ga: prikupljanje podataka, zapisivanje i pamenje podataka, obrada podataka,
skladitenje i pronalaenje informacija, kao i prikaz informacija u odgovarajuem
obliku.
Informacioni sistem je podsistem poslovnog sistema. Sainjavaju ga ulazni podaci
i izlazne informacije, procesi (obrada podataka o stanjima stvarnog sistema) i izvrioci
(osobe, programi, raunari). Poslovne sisteme sainjavaju materijalni ulazi i izlazi
(sirovine, energija, proizvodi) i informacioni tokovi (poruke, dokumenti). Ulaz u neki
poslovni sistem predstavlja izlaz iz nekog drugog poslovnog sistema. Poslovni sistemi
sadre procese (npr. obrada, prerada, proizvodnja), povratne veze (npr. poreenje
plana i realizacije), skladita podataka (informacija), izvrioce (osobe, maine, alati,
sirovine), skladita materijala, ... .
Informacioni sistem odreuju slijedee karakteristike: sloena okolina, koju je
teko u potpunosti definisati, sloeni interfejs prema okolini, koji ukljuuje razliite
ulaze i izlaze, sloene veze izmeu ulaza i izlaza (strukturno i algoritmiki), kao i veliki
obim i sloenost podataka. Problemi projektovanja, izrade i odravanja IS se
prevazilaze zbog vanosti IS za jedan poslovni sistem. Informacija je postala
upravljaki resurs jednake vanosti kao to su vlasnitvo (osnovna sredstva), ljudski
resursi ili kapital. Informacioni sistem sadri/predstavlja znanje organizacije koju
podrava. IS i aplikacije pokazuju se prijeko potrebnim za odravanje konkurentnosti ili
postizanje kompetitivnog prestia poslovnog sistema. Poslovni sistemi u kojima se IS
primjenjuju visoko su zavisni o stalnoj raspoloivosti IS kroz due vrijeme.
15
1.4. Vrste informacionih sistema

Mogu se izdvojiti slijedee vrste informacionih sistema:
1. Transakcioni informacioni sistemi (TIS) [Transaction Processing System
(TPS), sinonim Data Processing System], ija je namjena da evidentiraju i
obrauju podatke o poslovnim transakcijama;
2. Upravljaki informacioni sistemi (UIS) [Management Information System
(MIS)], koji imaju zadatak da podravaju upravljaku funkciju na osnovu
dokazanih matematikih/statistikih metoda;
3. Sistemi za podrku odluivanju (SPO) [Decision Support System (DSS)], koji
slue za odluivanje na osnovu nestrukturiranih podataka iz razliitih izvora;
4. Izvrni informacioni sistemi [Executive Information System (EIS)], koji
predstavljaju podvarijantu IS za izvrne rukovodioce;
5. Ekspertni sistemi (ES) [Expert Systems (ES)], odnosno sistemi sa ugraenim
znanjem i simulacijom zakljuivanja;
6. Sistemi za automatizaciju kancelarijskog poslovanja [Office Automation
Systems (OAS)];
7. Sistemi za grupnu podrku [Group Support System, Groupware (GSS)].
Upravljanje i nivoi IS su prikazani tabelom 1.1.
Tabela 1.1.
Informacioni sistem
Informacije, kada
Korisnici, ko
Upravljanje
Transakcioni
Nie poslovodstvo
Operativno
Upravljaki
Obrada podataka,
dnevno
Zbirne, periodino
Taktiko (trendovi)
Za podrku
odluivanju
Sintetizovane,
ad hoc
Srednje
poslovodstvo
Vie poslovodstvo,
uprava
Strategijsko
(ta ako, )
16
1.5. ivotni ciklus razvoja sistema

(Systems Development Life-Cycle (SDLC))
1.5.1. Pojam ivotnog ciklusa razvoja
Naziv ivotnog ciklusa razvoja zavisi od konteksta u kome je upotrebljen. Mogu
se izdvojiti slijedei nazivi ivotnog ciklusa: ivotni ciklus razvoja IS, ivotni ciklus
razvoja softvera i ivotni ciklus razvoja aplikacija. Praenje ivotnog ciklusa
obezbjeuje konzistentan i standardizovan nain razvoja IS. Svrha praenja ivotnog
ciklusa razvoja omoguava pravilno planiranje, izvravanje i nadzor razvojnog
projekta.
ivotni ciklus definie faze i zadatke (aktivnosti), koje nuno treba obaviti tokom
razvoja, bez obzira na veliinu sistema koji se gradi. Svaka pojedina aktivnost
proizvodi skup rezultata. Ciklus osigurava kontrolne toke za praenje napretka,
procjenu postignutih rezultata i donoenje odluka o daljnjim koracima. Projekat prolazi
kroz faze ivotnog ciklusa.
Primjer: Za ivotni ciklus razvoja softvera mogu se definisati slijedee faze i
zadaci:
Potreba analize i dizajna (Requirements Analysis & Specification);

Konceptualni/sistemski dizajn (Conceptual/System Design);
Detaljni/programski dizajn (Detailed/Program Design);
Implementacija/kodiranje (Implementation/Coding);
Pojedinano i integralno testiranje (Unit & Integration Testing);
Sistemsko testiranje (System Testing);
Predaja sistema (System Delivery).
1.5.2. ivotni ciklus i faze razvoja informacionog sistema

Za ivotni ciklus razvoja IS (slika 1.3) potrebno je definisati mnogo kompleksnije
faze.
Strategijsko planiranje razvoja IS poinje snimanjem stanja (inicijalna strategija).
Doprinosi odreivanju poslovnih ciljeva, identifikovanju problema i ideja, odreivanju
naina njihovog rjeavanja, te definisanju zahtjeva koji se postavljaju pred sistem.
Sadri studiju izvodljivosti, odnosno preglednu analizu problemskog podruja i
17
odreivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada,

odreivanja kadrova za projekat, upravljanje i nadzor projekta. Poslovni cilj je izrada
glavnog projekta informatizacije.
Analiza zahtjeva je detaljna analiza kojom se preciziraju granice projekta i
poslovni zahtjevi. Vri se detaljna analiza postojeeg sistema, problema i poslovnih
zahtjeva. Specifikacija zahtjeva je detaljni opis zahtjeva za IS, oblikovan tako da ga
razumiju dizajneri. Predstavlja model budueg sistema.
Oblikovanje sistema, odnosno dizajn (modeliranje) IS, predstavlja pogled
projektanta na budui IS. Slui za donoenje odluke o tome kako graditi sistem. Sadri
dizajn potrebnih rjeenja. Postoje rjeenja koja ne treba dizajnirati. Detaljni dizajn
predstavlja razradu rjeenja, odnosno izradu tehnolokog modela IS (pogled
izvoaa). Potrebno je izvriti dizajn arhitekture, interfejsa, pohranjivanja podataka i
programa, drugim rijeima izvriti tehniku specifikaciju sistema.
Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP), kodiranje
procesa (funkcija) novog IS, a vri se nakon odabira raunarske platforme. Testiranje
je provjera ugraenih komponenti. Integracija i provjera sistema je udruivanje dijelova
i provjera cjeline, da bi se dokazalo da sistem radi (da je ispravno napravljen), te da
radi ono to je zahtijevano (da je napravljen pravi sistem koji ispunjava zahtjeve
korisnika).
Slika 1.3. Dijagram ivotnog ciklusa i faza razvoja IS [Fertalj & Kalpi, 2005].
18
Uvoenje u primjenu sistema predstavlja prenoenje radnih aktivnosti i

konverzija podataka sa starog na novi sistem. Odravanje se sastoji od izmjena
sistema radi poboljanja njegovih radnih karakteristika (performansi), poboljanja ili
prilagoavanja naina upotrebe. Odravanje podrazumjeva i podrku dobavljaa
opreme, pomo tehnikog osoblja korisnicima informacionog sistema u toku njegove
upotrebe, kao i izradu plana odravanja.
Novi razvojni ciklus se provodi nakon preispitivanja itavog sistema i
konstatacije da su potrebne vee izmjene uslijed promjena u poslovanju ili promjena
poslovnih ciljeva. Novi razvojni ciklus, najee, predstavlja novi projekat.
Na slici 1.4 su navedene tipine faze ivotnog ciklusa razvoja softvera, bez
naglaavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima.
Slika 1.4. Prikaz faza ivotnog ciklusa razvoja softvera.
1.6. Kompleksnost razvoja informacionog sistema

1.6.1. Ciljevi i problemi razvoja informacionih sistema
Osnovni cilj razvoja informacionog sistema je izgraditi sistem koji radi i koji je
pouzdan, unutar zadanih granica. To podrazumjeva izgraditi sistem koji zadovoljava
poslovne ciljeve, prema zahtjevima korisnika, u prihvatljivom vremenu i po opravdanoj
19
cijeni. Neki od problema koji se mogu pojaviti prilikom razvoja IS su: prekoraenje
planiranog vremena i finansijskih sredstava, neispunjavanje zahtjeva, odnosno
neodgovarajui sistem, nepouzdanost, nesigurnost, neelastinost IS u primjeni, kao i
tekoe u odravanju IS. Oko 70% informacionih sistema u svijetu se smatra
neuspjenim.
Prosjeno kotanje projekta prema The CHAOS Report [Standish Group, 1994,
http://www.standishgroup.com] iznosi: velike kompanije 2,32 miliona $, srednje
kompanije 1,33 miliona $ i male kompanije 434 hiljade $. Prosjeno prekoraenje
trokova je 189%, a prosjeno prekoraenje rokova 222%. Projekti zavreni na
vrijeme, u okviru predvienih sredstava i sa predvienim funkcijama, sainjavaju
16,2%, a projekti zavreni i u funkciji, ali uz vee trokove, due trajanje i/ili reduciranu
funkcionalnost 52,7%. Prekinutih projekata je 31,1%. Procenat uspjenih i neuspjenih
projekata IS prema Standish Group, 2002. iznosi 34% uspjenih projekata i 17%
potpunih neuspjeha.
1.6.2. Neki primjeri neuspjenih projekata i sistema

London Ambulance System (1992): Nakon uvoenja u eksploataciju IS se dva
puta "raspao" zbog niza greaka, naroito zbog greaka u upravljanju razvojem IS.
Neposredni troak je bio relativno nizak (9 miliona ), ali se vjeruje da su neki ljudi
umrli, jer se do njih nije stiglo na vrijeme.
Taurus (1993): Projekat sistema automatizovanih transakcija Londonske berze
prekinut je nakon 5 godina razvoja i troka od 75 miliona , te posljedini gubitak
klijenata od 450 miliona . Ukupni gubici smatra se da su neizraunljivi.
Denver Airport (1994): Nepouzdanost softvera za upravljanje prtljagom
uzrokovala je odlaganje otvaranja vazdune luke u trajanju od 16 mjeseci, uz trokove
od 1,1 miliona $/dan.
Ariane 5 (1996): Raketa eksplodirala u lanseru radi niza softverskih greaka.
1.6.3. Uzroci neuspjeha projekata informacionih sistema

Razlozi neuspjenih projekata IS su razliiti. Mogu se izdvojiti slijedei razlozi:
sloenost aplikacija, nedostatak usmjerenosti korisniku, zanemarivanje okruenja
20
organizacije, pretjerani optimizam, izostanak praenja napretka i nedostatak

komunikacije izmeu korisnika i izvoaa.
U naem okruenju uzroci neuspjeha se, uglavnom, ne istrauju, a informacije o
neuspjenim projektima nerado se objavljuju. Meu najeim uzrocima moe se
pretpostaviti da su: loa organizacija i voenje projekata, oslonac na vanjske
projektante i savjetnike, delegirano upravljanje projektima, nerealno planiranje,
formalno izvjetavanje o napretku, formalni nadzor nad projektom, kao i podcijenjena
uloga vlastitih strunjaka. Ne treba iskljuiti i slijedee uzroke neuspjeha: loa izvedba
projekata, neodgovarajua analiza sistema, greke u dizajnu i kontroli kvaliteta,
neodgovarajui CASE alati i krivo koritenje, pa ak i svojevrsna zloporaba CASE
alata. Mnogi sistemi su propali, ili su bili odbaeni, jer su se izvoai trudili napraviti
lijepa programska rjeenja, a nisu razumjeli sutinu poslovnog sistema i poslovanja.
1.6.4. Poboljanje uspjenosti informacionih sistema

Da bi se poboljala uspjenost IS potrebno je:
projektovanje IS,
planiranje, upravljanje izvedbom, praenje napretka,
ukljuivanje korisnika.
Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe, a informatiar
upoznaje(?) poslovanje i zna(?) kako izraditi IS. Vano je da u procesu izgradnje
sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogunostima i koristima
uvoenja IS, naroito jer donosi konane (za poslovni sistem sudbonosne) odluke.
21
2. Planiranje razvoja informacionog sistema

2.1. Modaliteti razvoja informacionog sistema
2.1.1. Vlastiti razvoj informacionog sistema
Postoje razliiti modaliteti razvoja informacionog sistema. U ovoj knjizi e biti
razmatrani modaliteti razvoja koji se najee koriste. Razvoj vlastitim informatikim
snagama podrazumjeva osposobljavanje i angairanje netehnikog osoblja, kao i
povremeno ili dugorono angaovanje spoljnih saradnika. Prednosti ovakvog pristupa
su fleksibilnost, kreativnost i poveanje strunosti vlastitog osoblja. Nedostaci su da
ovaj pristup zahtijeva znaajno vrijeme i napor, razvoj je skuplji i dugotrajniji i moe
poveati gomilanje zaostalog posla.
Razvoj vlastitim snagama ima smisla kada se radi o programskoj podrci koja je
posebnost organizacije, takva da ne postoje gotova rjeenja na tritu ili takva da
organizacija pomou nje postie komparativnu prednost u odnosu na konkurenciju.
Postoje dodatni ili posebni razlozi kao to su poveana tajnost podataka i poslovnih
procesa ili poveana zatita IS.
2.1.2. Vanjski razvoj informacionog sistema

Angaovanje vanjskih saradnika za razvoj informacijskog sistema, ili njegovih
dijelova, podrazumjeva pruanje pomoi u obrazovanju radnika informatike struke,
pomo pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja.
Takoe se podrazumjeva kodiranje (generisanje) cjelovitog programskog sistema,
upravljanje izvoenjem i/ili nadzor izvoenja, kao i konsultativna pomo prilikom
ugradnje sloenih poslovnih funkcija. Varijante su slijedee: ugovoreni razvoj, odnosno
ugovara se isporuka gotovog proizvoda ili dugorona saradnja sa isporuiocem, uz
izdvajanje vlastitog informatikog odjela u glavnog izvoaa. Mogua varijanta je i
nalaenje stratekog partnera na dui vremenski period, npr. softverske kue.
Prednosti su viestruke. IS ili njegovi dijelovi izrauju se po mjeri naruioca,
sistem je prilagoen organizaciji/poslovanju, a po mogunosti treba istovremeno
poboljati organizaciju/poslovanje poslovnog sistema. Ovakav razvoj podrazumijeva
dugotrajan postupak i odgovarajuu visoku cijenu.
22
Nedostaci i rizici su takoe prisutni. Dolazi do gubitka povjerljivih informacija,

gubitka nadzora nad sadanjim i/ili buduim razvojem (zavisnost o dobavljau), kao i
gubitak vlastite strunosti.
Nuno je da upravljanje projektom informatizacije na sebe preuzme vlastito
kompetentno osoblje koje ima mogunost odluivanja.
2.1.3. Nabavka gotovih aplikacija

Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti
poslovne potrebe. Poeljno je da se mogu prilagoditi potrebama. Primjeri aplikativnih
paketa, koji se mogu nabaviti kao gotovi proizvodi, su: programski paketi za
kancelarijsko poslovanje (npr. Microsoft Office), programi za upravljanje dokumentima
(npr. Lotus Domino) ili specijalistike aplikacije za odreene namjene.
Mogu se nabaviti slijedei sistemi za upravljanje poslovanjem, koji nose
komercijalne nazive: Enterprise Resource Planning (ERP) systems, SAP, BAAN, J.D.
Edvards, Peoplesoft. Cjeloviti sistemi za podrku poslovanju, uglavnom, podravaju
slijedee aplikacije: finansijsko poslovanje (accounting), proizvodnju (manufacturing),
robno-materijalno poslovanje (material management/distribution), upravljanje ljudskim
resursima i plate (CG management, payroll).
2.1.4. Nabavka poslovnih aplikacija

Slijedei modalitet razvoja IS je nabavka i prilagoavanje postojeih domaih
poslovnih aplikacija. Prednost ovog pristupa je usklaenost vaeim uslovima, npr.
propisima, ta olakava prilagoavanje aplikacija organizaciji/poslovanju. Nedostatci
su nepostojanje ili manjkavost pojedinih komponenti, mjestimina tehnoloka
zastarjelost, prekapacitiranost dobavljaa. Modaliteti ovakvog pristupa su slijedei:
otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz
samostalno odravanje.
Nabavka gotovih stranih poslovnih aplikacija, takoe, ima svoje prednosti i
nedostatke. Prednosti su raskona funkcionalnost i kompatibilnost sa svjetskim
poslovnim standardima, dok se nedostatci ogledaju u neprilagoenosti domaim
uslovima i konkretnoj organizaciji/poslovanju, ta zahtijeva istovremeno prilagoavanje
programske opreme i promjenu organizacije/poslovanja. Prilagoavanje se obavlja
slino razvoju, ta moe uzrokovati da rjeenja gube moguu komparativnu prednost
(brzinu i lakou primjene). Glomazni paketi mogu zahtijevati angaovanje velikog broja
23
konsultanata. Mogui modalitet nabavke je da se prilagoavanje vri vlastitim

snagama uz savjetovanje i pomo dobavljaa.
2.1.5. Kriterijumi za donoenje odluke o nabavci

Opti kriterijumi za donoenje odluke o razvoju IS su:
cijena,
funkcionalnost, kapacitet, brzina, broj korisnika,
mogunost obuke i trajne podrke,
kredibilitet i odrivost dobavljaa na tritu, to se dokazuje referensama,
elastinost, tj. mogunost prilagoavanja i prepravki,
raspoloivost dokumentacije.
U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost,

interoperabilnost), tehnike mogunosti (Client-Server, OLTP, OLAP), referense
dobavljaa (prisutnost dobavljaa na lokalnom tritu) i podrka korisnicima. Pod
podrkom korisnicima se podrazumjeva: kolovanje, tehnike konsultacije, odravanje
(dinamika razvoja i mogunosti nabavke novih verzija), blagovremeno otklanjanje
problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitih aplikacija.
2.1.6. Nabavka izvedbenog programskog koda

Prednosti nabavke izvedbenog koda su: izvedbeni kd je jeftiniji, brigu i
odgovornost o njegovom odravanju preuzima isporuilac, uz izuzetak nekih opte
primjenjivih komercijalnih programa. Prednost izvedbenog koda je i ta da se ne mora
kupiti (skupi) razvojni programski alat u kojem je programski proizvod razvijan.
Mane izvedbenog koda, obzirom na korisnika, su: izvedbeni kd podrazumijeva
potpunu zavisnost od isporuioca, ne postoji mogunost prilagoavanja specifinim
vlastitim potrebama, osim putem posebnog dogovora sa isporuiocem. Dodatna
prilagoavanja lako mogu postati predmetom ucjene. Takoe, ne postoji mogunost
razvoja programske opreme vlastitim snagama.
2.1.7. Nabavka izvornog programskog koda

Prednosti nabavke izvornog programskog koda su znatne. Izvorni kd omoguava
stalni razvoj i praenje vlastitih posebnosti, to se moe pokazati kao prednost u
odnosu na konkurenciju. Osim toga, prua mogunost prilagavanja vlastitim
24
potrebama, ta daje elastinost pri promjenama organizacije poslovanja. Nema bojazni

da e nakon prve potrebne izmjene prestati upotreba IS zbog toga to isporuilac nije
trenutno dostupan, postavlja nerazumne uslove ili je u meuvremenu nestao sa trita.
Uvidom u kvalitetna gotova rjeenja pomae se razvoju vlastitih informatikih radnika.
Mane narudbe izvornog koda su, takoe, prisutne. Izvorni kd je viestruko
skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS
razvijen. Naruilac se izlae iskuenju da nekompetentno mijenja nabavljeni izvorni
kd, onesposobi aplikaciju za rad i izgubi pravo na odravanje. Odravanje je skuplje
ukoliko se radi o programskoj opremi podlonoj promjenama.
Snienje cijene izvornog koda moe se postii automatizacijom kodiranja,
upotrebom generatora izvornog koda.
Preporuke za izbor programskog koda su slijedee. Izvedbeni kd treba
preporuiti u slijedeim sluajevima:
kada se radi o standardnim, masovno prodavanim aplikacijama,
kada korisnik nema vlastite informatike strunjake,
kada se radi o visokostrunim aplikacijama koje se nee mnogo mijenjati, a
korisnik nema namjeru da se baviti detaljima te struke,
kada korisnik nema novaca ili elje za vlastiti informatiki razvoj.
Izvorni kd treba preporuiti onda:
kada programska oprema predstavlja strateku investiciju,
kada korisnik raspolae kompetentnim informatiarima ili ima motiva razvijati
vlastitu informatiku djelatnost,
kada isporuilac ne moe preuzeti obavezu odravanja ili ne moe garantovati
da e ostati na tritu,
kada na tritu ne postoji IS koji odgovara potrebama, ne moe se povoljno
kupiti slian, a korisnik raspolae vlastitim informatikim snagama dovoljnim za
projektovanje novog.
2.1.8. Izbor modaliteta razvoja

Odreivanje moguih rjeenja podrazumjeva identifikaciju rjeenja na osnovu
poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija raunarske
opreme i programske podrke, te odabrana tehnoloka arhitektura, dok su izlazi
mogua rjeenja novog sistema i njihove karakteristike.
Analiza izvodljivosti alternativnih rjeenja se sastoji od procjena alternativa
obzirom na tehniku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi su
25
karakteristike moguih rjeenja, karakteristike i cijene hardvera i softvera, referense i

uslovi dobavljaa, a izlazi analiza izvodljivosti za svako mogue rjeenje.
Prijedlog rjeenja sistema koji e se oblikovati i ugraditi se donosi na osnovu
izbora onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su
napravljena analiza izvodljivosti, plan projekta, procjena veliine projekta, a izlazi
prijedlog sistema sa usvojenim promjenama dizajna predloenog sistema.
2.1.9. Ocjenjivanje kriterijuma za izbor sistema

Na osnovu opisa karakteristika ne moe se sa sigurnou procijeniti koji je sistem
najbolji. Da bi se pravilno uporedio znaaj razliitih kriterijuma koristi se sistem
bodovanja. Procedura bodovanja kriterijuma je slijedea. Odredi se teinski faktor za
svaki kriterijum (npr. od 1 do 4). Oni kriterijumi koji su znaajniji u uporedbi sistema
dobivaju vee teinske faktore. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz
dogovorenog raspona (npr. od 0 do 5). Dodjeljena ocjena se pomnoi teinskim
faktorom kriterijuma za koji je donesena, te se dobije broj bodova [Fertalj & Kalpi,
2005].
Primjer: Analiza izvodljivosti za mogua rjeenja.
Tabela 2.1.
Karakteristike:
Operativni sistem
Baza podataka
Brzina pretraivanja i dohvat podataka
Programski jezik
Raspoloiv izvorni kod
Korisniki interfejs
Integrisani sistem pomoi (on-line help)
Dokumentacija (na papiru)
Mogunosti aplikacije
Integracija sa drugim aplikacijama
Brzina ispisa rauna
Rad sa razliitim tampaima
Rad u mrei
Vrijeme obuke korisnika
Arhiviranje podataka
Upotreba konfiguracije za druge poslove
Broj instalisanih paketa
Datum prve instalacije
Cijena paketa
Cijena raunara i sistemskog softvera
Ukupno bodova:
Teinski Super Video

Video Boss
Video
ZZ Video
faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi
2
1
4
1
1
2
2
2
4
3
4
3
1
1
2
3
1
1
2
3
4
4
5
4
0
5
5
4
5
4
2
5
5
3
5
5
3
3
2
3
8
4
20
4
0
10
10
8
20
12
8
15
5
3
10
15
3
3
4
9
171
4
4
4
5
0
5
0
0
1
3
3
5
0
5
0
5
2
3
5
2
8
4
16
5
0
10
0
0
4
9
12
15
0
5
0
15
2
3
10
6
124
1
2
1
2
5
3
0
0
2
0
5
0
0
5
5
0
5
5
4
5
2
2
4
2
5
6
0
0
8
0
20
0
0
5
10
0
5
5
8
15
97
3
1
4
2
0
3
0
4
5
0
5
0
0
3
5
3
5
5
2
3
6
1
16
2
0
6
0
8
20
0
20
0
0
3
10
9
5
5
4
9
124
26
Na kraju se saberu dodjeljeni bodovi po svim kriterijumima za svaki sistem:

n
Si = 3sij wj
j =1
gdje su: Si = ukupna vrijednost i - tog rjeenja,

sij = vrijednost j - tog kriterijuma za i - to rjeenje,
wj = vanost ili teina j - tog kriterijuma.
Najbolji je onaj sistem sa najveim brojem bodova (npr. Super Video, tabela 2.1).
esto se mogu javiti slijedee nedoumice:
ta uiniti kada su sistemi (pod)jednako bodovani?
ta uiniti ako pojedino svojstvo ima vie podsvojstava?
2.1.10. Izbor dobavljaa proizvoda ili usluga

Definisanje kriterijuma i opcija, kod izbora dobavljaa proizvoda ili usluga, vri se
na osnovu slijedeih ulaza i izlaza. Ulazi sadre specifikacije zahtjeva za programsku
podrku i raunarsku opremu: funkcionalnost, dodatna svojstva, kljune parametre
performansi, ... . Izlazi su lista potencijalnih dobavljaa proizvoda ili usluga, te
kriterijumi za izbor.
Kod prikupljanja ponuda treba potencijalnom dobavljau uputiti zahtjev za
dostavljanje referensi (kada postoje razliiti dobavljai i/ili proizvodi, a eli se odabrati
najbolje rjeenje, prikupljaju se ponude koje su skup referensi"), kao i zahtjev za
dostavljanje ponude sa informacijama o konfiguracijama, cijenama, odravanju (kada
se odreeni proizvod moe nabaviti od razliitih dobavljaa).
Izbor ponuda se obavlja slijedeim redoslijedom: (1) provjera sadraja ponuda, (2)
izrada rang liste, poeljno odvojenim ocjenjivanjem pojedinanih ponuda, (3) izbor
objektivno najboljeg ponuaa (to se, naalost, vrlo teko uklapa u zakonske odredbe
po kojima treba tano specificirati to se eli, a mora se kupiti najjeftinije).
Ugovaranje posla se zavrava sklapanjem ugovora koji definie uslove saradnje,
isporuke i naplate, integracije sa postojeim sistemom, odravanja i slino. Ugovori se
mogu raskinuti ili ne ispuniti kako je bilo zamiljeno.
Izvrilac projekta treba biti stimulisan proporcionalno ostvarenoj, u praksi
dokazanoj i od korisnika prihvaenoj, funkcionalnosti sistema.
27
2.2. Analiza izvodljivosti, trokova i koristi projekta

2.2.1. Analiza izvodljivosti projekta
Za pojedine projekte se vri analiza njihove izvodljivosti, odnosno mjerenje
korisnosti, praktinosti i isplativosti projekta IS. Ove analize treba da se vre tokom
planiranja, ali i kasnije, npr. nakon faze sistemske analize. Nakon odluke o pokretanju
projekta sloenost i opseg projekta se mogu promijeniti, te poetno izvodljiv projekat
moe postati neizvodljiv. Praktino gledano, tonost procjene izvodljivosti raste sa
dubinom analize.
Studija izvodljivosti (feasibility study) sadri: (1) detaljnu provjeru projekta, koju
provode sistem analitiari, (2) procjenu da li je projekat izvodljiv obzirom na raspoloiva
sredstva, (3) procjenjuje se da li projekat omoguava poboljanja, (4) radi se izvjetaj o
izvodljivosti i prezentira se relevantnim uesnicima radi komentara i miljenja (moe
biti dio idejnog rjeenja), (5) eventualni povratak u studiju izvodljivosti, odnosno
revidirani izvjetaj.
2.2.2. Izvjetaj o izvodljivosti projekta

Izvjetaj o izvodljivosti projekta sainjavaju slijedee analize:
organizaciono - operativna izvodljivost,

tehniko - tehnoloka izvodljivost,
vremenska izvodljivost,
ekonomska izvodljivost.
Analiza organizaciono - operativne izvodljivosti projekta sadri procjenu

hitnosti rjeavanja problema (planiranje), kao i procjenu prihvatljivosti rjeenja (kasnije
faze). Tu se neminovno nameu i slijedea pitanja: Vrijedi li rjeavati problem? i Da li
predloeno rjeenje rjeava problem? Da bi se odgovorilo na ova pitanja potrebno je
analizirati: performanse (odnosno protonost i odziv sistema u odnosu na ulaze),
informacije (da li su dovoljne, pravovremene, prikladne, aurne, tane, korisne),
ekonomiske aspekte (gdje spadaju problemi trokova i mogunosti uteda), kontrolu (u
prvom redu sigurnost i zatitu podataka), efikasnost (odnosno poboljavanje upotrebe
raspoloivih resursa: ljudi, opreme, novca, itd.), kao i usluge (poeljni i pouzdani
servisi, elastinost i mogunost prilagoavanja, zadovoljstvo).
Nita manje bitni nisu ni odgovori na slijedea pitanja: Koji je stav korisnika prema
rjeenju? i Da li e se sistem koristiti? Neophodni su podrka uprave i prihvatanje
sistema od krajnjih korisnika. Treba na vrijeme uoiti otpore ulozi ili tehnikim
28
rjeenjima sistema i predloiti naine njihovog otklanjanja. Krajnjeg korisnika treba na

vrijeme pripremiti za promjenu radnog okruenja i procedura. Procjena upotrebljivosti
sistema se najlake moe izvriti koritenjem prototipa. Potrebno je pravilno ocjeniti
potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema.
Namjeniti jednostavni interfejs za poetnike i povremene korisnike, sloenije operacije
za iskusne korisnike. Obezbjediti da korisnik daje prednost ponuenom rjeenju u
odnosu na postojei nain rada.
Analiza tehniko - tehnoloke izvodljivosti projekta sadri procjenu moguih
rjeenja i alternativa. U prvom redu potrebno je izvriti procjenu stanja na tritu
opreme, procjenu postojeih rjeenja u drugim organizacijama (tamo gdje je mogue),
kao i procjenu primjenjivosti razliitih tehnologija.
Veoma bitna osobina je da se zastupljena tehnoloka rjeenja mogu jednostavno
primijeniti. Raspoloivost tehnologije podrazumijeva da se primjenljiva tehnologija
moe nabaviti. Ako je rije o gotovom rjeenju, ima li to rjeenje potrebne
karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Nita manje bitno nije ni
injenica da li postoje potrebni strunjaci za primjenu nove tehnologije. Pri tome treba
imati na umu da se i najnovija tehnologija moe savladati.
Analiza vremenske izvodljivosti projekta treba da d odgovor da li su
predvieni rokovi ostvarivi, obzirom na raspoloivu strunost. Oekivano vrijeme
zavretka moe biti poeljno ili obavezno. Bolje je isporuiti ispravan sistem dva
mjeseca kasnije, nego neispravan ili beskoristan na vrijeme!
Ekonomska izvodljivost projekta e biti objanjena preko analiza i uporedbe
ukupnih trokova - koristi (cost-benefit analysis (CBA)). Trokovi i korist mogu biti
mjerljivi (npr. cijena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr.
zadovoljstvo korisnika, brzina odluivanja, dobra referensa).
Finansijski troak i korist se mogu izraziti formulama: (1) razlika korist troak u
nekom razdoblju (Net Present Value), (2) povrat investicije (korist troak)/troak
(Internal Rate of Return), (3) trenutak u kojem korist nadvlada troak (Payback Point).
CBA rauna trokove i korist projekta kao trenutnu vrijednost (Present Value
(PV)). Dananja vrijednost onoga to e postati $1,00 nakon n godina u budunosti,
ako se uzmu u obzir kamate I iznosi:
PV = 1/(1 + I)n = (1 + I) n
Razlika predstavlja kamatu koja se moe zaraditi tim novcem ($ oznaava
novanu jedinicu u bilo kojoj valuti).
.
Primjeri:
Trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000;
29
Korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8%

ima trenutnu vrijednost od samo:
$30.000 / (1 + 0.08)5 = $20.417
Povrat investicije (Return On Investment (ROI)) se obino dijeli sa duinom
trajanja projekta kako bi se dobio godinji ROI. Nizak ROI (~ manji od 10% godinje)
moe pokazivati da je korist preniska da bi bila isplativa. Odnos troak/korist je
prikazan tabelom 2.2 i grafikim prikazom tabele.
Primjer: Analiza troak korist [Fertalj & Kalpi, 2005].
Tabela 2.2.
30
2.3. Strategija i planiranje razvoja informacionog sistema

2.3.1. Definisanje poslovne strategije
Poslovni ciljevi zahtjevaju definisanje poslovne strategije, odnosno planiranje
akcija za postizanje ciljeva. Uprava definie viziju i misiju poslovnog sistema, tj.
strategijske ciljeve. Na osnovu strategijskih ciljeva se definiu poslovni ciljevi i odreuju
zadaci, kojima e poslovni sistem u nekom razdoblju ispuniti svoju misiju. Pri tome se
dobijaju odgovori: ta se eli postii (prepoznatljivost, kvalitet, prihodi), kako eljeno
postii (promjenom organizacije, poboljanjem sistema administracije), kako ostvariti
poveanje proizvodnje ulaganjem u nove proizvodne tehnologije, uz istovremeno
odravanje kvaliteta proizvoda, i kako osigurati zadovoljstva i radne sposobnosti
zaposlenih dokolovavanjem i mogunostima napredovanja.
inioci koji utjeu na postavljanje ciljeva su slijedei: ogranienja (organizaciona,
finansijska, zakonska), potrebe i elje uprave, poslovodstva, zaposlenih (ugled, uticaj),
vremenski okviri, gdje je kratkorono razdoblje obino manje od 2 godine,
srednjorono 2 do 5 godina i dugorono vie od 5 godina [Awad, 1985].
2.3.2. Planiranje razvoja informacionog sistema

Planiranje razvoja informacionog sistema treba da d odgovor na slijedea
pitanja:
ime se poslovni sistem bavi (grana, proizvodi, trite, konkurencija)?

Koji su problemi, zadaci i ciljevi poslovnog sistema?
Koja je eljena uloga IS u postizanju postavljenih ciljeva?
Koje aplikacije postoje, emu i kako slue, koje i kakve podatke sadre?
Postoje li aplikacije iji je razvoj u toku? U kojem su stadijumu razvojni
projekti?
Koje su potrebne aplikacije?
Koji su raspoloivi resursi (osoblje, tehnika sredstva, tehnologija)?
Razlozi zbog kojih treba planirati IS su viestruki. Na primjer, u Poslovnom

sistemu koji se sastoji od vie cjelina, kao to su Uprava, Finansije, Proizvodnja i
Informatika esto postoji vie razliitih tehnikih sistema ili aplikacija, takozvanih
informatikih ostrva. To ima za posljedicu umnoavanje informacija uz razliito
tumaenje u razliitim dijelovima, nepotpunost informacija, naroito kada svaka cjelina
prikuplja samo njoj vane informacije, problem povezivanja informacija pri pokuaju
cjelovite interpretacije, kao i problem razliitog posluivanja, razmjene podataka i
odravanja.
31
Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili

provodi se kao reakcija na promjene u poslovnoj politici. Strategojsko planiranje IS je
prikladno za stabilne poslovne sisteme. U praksi je teko izvodljivo u uslovima
preivljavanja. Sastoji se od uspostave smjera i prioriteta usklaivanja informacionih
servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u
skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podrka
promjeni poslovnog sistema i poslovnih procesa. Jo se mogu navesti primjene
metoda analize i dizajna za prouavanje poslovnog sistema, sa ciljem definisanja
opteg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi.
U praksi situacija je slijedea. Umjesto prema strategijskom planu, poslovni
sistem se "dovodi u red" tokom informatizacije i pomou informatizacije. Analizom
sistema evidentiraju se problemi i slabosti poslovnih procesa, budui da se dizajnom
sistema predlau ili nameu poboljanja.
2.3.3. Odabir i pokretanje projekta

Prvenstveno pokretai promjena su korisnici, odnosno njihovo nezadovoljstvo
aplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokuje
nedostatak podataka, to naglaava potrebu uvoenja novih funkcija. Nezadovoljstvo
podacima nastaje uslijed njihove nepouzdanosti, nedostupnosti, manjkavosti, a
nezadovoljstvo reorganizacijom nastaje uslijed promjene organizacione strukture,
promjene poslovnih procesa (npr. promjene na Univerzitetu uzrokovane novim
zakonom). Pokretai promjena mogu biti i pokazatelji poslovanja (npr. pad prodaje,
uska grla proizvodnje, neplanirano i nejasno poveanje trokova), kao i zastarila
tehnologija (npr. zastario razvojni alat i prisutan problem njihovog odravanja, zastario
interfejs Internet-a, zastarile BP).
Odabir projekta se vri na osnovu prijedloga projekta, koga sastavlja sponzor
projekta (organizator, predlaga). Prijedlog projekta sadri saetak projekta (naziv, cilj,
svrha), poslovne potrebe, oekivanu funkcionalnost, oekivanu korist, kao i posebnosti
i ogranienja. Radna grupa za odabir projekta odobrava projekat. Prije pokretanja
projekta potrebno je izvriti snimak stanja, odnosno prethodno istraivanje, tj.
istraivanje koje prethodi projektu, prepoznavanje problema i potreba, kao i traenje
odgovora na pitanje "Da li je projekt vrijedan panje?".
Slijedi faza prouavanja problema, produbljivanje snimka, postavljanje ciljeva,
prijedlozi rjeenja, procjena izvodljivosti, traenje odgovora na pitanja "Da li su
problemi vrijedni rjeavanja? i "Da li je gradnja isplativa?".
Planiranje projekta, odnosno organizacija i upravljanje projektom, sastoji se od
slijedeih aktivnosti: izrada plana rada, oformljenje projektantske ekipe (ukljuivanje
32
uesnika iz razliitih djelatnosti, npr. radnici razliitih poslovnih podruja ili

organizacijskih jedinica, uprava, vanjski konsultanti), pri emu je vano osigurati
predanost uesnika zajednikom cilju, i, na kraju, uspostava upravljanja i nadzora
projekta.
2.3.4. Snimanje stanja

Snimanje stanja omoguava brzo istraivanje i evaluaciju problema, moguih
prilika i direktiva. Pod problemom se podrazumjeva neeljena situacija koja sprjeava
potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadataka. Mogua prilika je
mogunost pozitivne promjene, ak i kada ne postoji problem, dok je direktiva zahtjev
ili ogranienje koji su nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim
uticajem (npr. zakon). Mogue je opciono provoenje procjena moguih tehnikih
rjeenja, pri emu treba imati na umu da to treba biti detaljnije provedeno u kasnijim
fazama, kao i odreivanje dosega projekta i poetnog plana projekta.
Snimanje poslovnog sistema se sastoji od pregleda poslovnih planova, ako takvi
postoje ili nisu tajna, prikupljanja informacija, najee intervjuisanjem korisnika,
vlasnika i viih rukovodilaca, kao i evidentiranja problema i prijedloga. Snimanje stanja
obuhvata identifikaciju korisnika i opsega postojeeg (postojeih) IS, uoavanje
problema i nedostataka postojeeg IS, procjenu potreba za nadogradnjom
(poboljanjima), pocjenu potreba za izmjenama (prilagoavanjem i popravkama) i
procjenu potreba za izradom novih IS ili podsistema IS (Tabela 2.3).
Primjer: Postojei problemi i prijedlozi rjeenja [Fertalj & Kalpi, 2005].
Tabela 2.3.
Kratko obrazloenje problema, mogunosti ili
direktive
1. Vrijeme odgovora na narudbu mjereno od
vremena zaprimanja narudbe do isporuke
klijentu se povealo na prosjeno 15 dana.
2. Nedavno preuzimanje kompanija: Privatna
predstava i Filmsko platno nametnulo je
poveanje zahtjeva za protokom informacija i
dokumenata.
3. Trenutno 3 razliita sistema za unos narudbi
servisiraju odjele za audio, video i video igre.
Svaki sistem ima vlastiti interfejs prema
razliitom skladinom sistemu, pa treba
objediniti skladinu evidenciju.
4. Postoji nedostatak pristupa informacijama
nunim za upravljanje i donoenje odluka. Ovo
e se jo pogorati preuzimanjem dva dodatna
sistema za obradu narudbi (iz Privatna
predstava i Filmsko platno).
5. Izraena je nedoslijednost (nekonzistentnost)
izmeu podataka u evidencijama lanova i
narudbi.
Hitnost
Vidljivost
Korist
Prioritet
HITNO
Visoka
175000
Predloeno
rjeenje
Novi razvoj
6
mjeseci
Srednja
75000
Novi razvoj
6
mjeseci
Srednja
515000
Novi razvoj
12
mjeseci
Niska
15000
3
mjeseca
Visoka
35000
Nakon razvoja
novog sistema,
pruiti korisnicima
lako savladive
alate za pisanje
izvjetaja.
Brza ispravka, a
zatim novi razvoj.

6. Sistemi datoteka u Privatna predstava i Filmsko
platno nisu kompatibilni sa onim u Zvuna
pozornica. Problemi sa podacima obuhvataju
nedoslijednosti u podacima i nedostatak
upravljanja ulazom i izmjenama.
7. Postoji mogunost uvoenja sistema naruivanja
putem Interneta, ali su sigurnost i kontrola
pristupa problematini.
8. Postojei
sistem
unosa
narudbi
nije
kompatibilan sa planiranim sistemom za
automatsku identifikaciju (tapiasti kod) koji se
razvija za skladite.
33
6
mjeseci
Srednja
nepoznata
Novi razvoj,
dodatna ocjena
koristi moe
poveati aurnost.
12
mjeseci
Niska
nepoznata
3
mjeseca
Visoka
65000
Budue verzije tek

razvijenog
sistema.
Brza ispravka, a
zatim novi razvoj.
Vidljivost: U kojoj mjeri e rjeenje ili novi sistem biti vidljivi korisnicima.
Korist:
Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo
troak u jednoj godini.
2.3.5. Planiranje projekta

Planiranje projekta podrazumjeva odreivanje namjene projekta i izdvajanje
zadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Domet i
razgranienje projekata ili podprojekata (System boundary, Constraints, Objectives,
Permissions, End products (SCOPE)) daje odgovore na slijedea pitanja:
Koje su granice sistema?

Koji e zahtjevi biti ispunjeni?
ta ne moe biti napravljeno?
ta nee biti napravljeno?
Ko e, kako i pod kojim uslovima moi koristiti rjeenje?
Kako se mjeri ili odreuje uspjeh (neuspjeh)?
Kako e se znati da je projekat gotov?
Vremensko planiranje obuhvata odreivanje prioritetnih zadataka i vremenskih

okvira prioriteta. Izrada poetnog (preliminarnog) plana razvoja IS zapoinje podjelom
projekta u manje cjeline i odreivanje redoslijeda realizacije pojedinih podprojekata.
Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada i
raspodjela poslova, kao i odreivanje prioriteta. Nastoji se pronai takva podjela posla
na cjeline da cjelinu moe obaviti jedna osoba ili ekipa, da se cjelina moe obaviti
jednom metodom i posao zavri jednim proizvodom (dokumentom, aplikacijom ili
podsistemom).
Poetni plan razvoja IS sadri nazive podprojekata i omoguava doradu i
auriranje u skladu sa napretkom projekta. Moe se koristiti za prezentaciju projekta
radi traenja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta moe
posluiti kao interni ugovor projekta (tabela 2.4).
34
Primjer: Poetni (preliminarni) plan informacionog sistema, tabela 2.4.

Tabela 2.4.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
Nabavka sistema za upravljanje bazama podataka;

Obuka opte informatike pismenosti za rukovodioce odjeljenja;
Obuka za programere u jeziku za upravljanje bazama podataka;
Obuka za administratore baze podataka;
Izrada prototipa programske podrke za i-tu fazu realizacije;
Izrada - verzije aplikacije;
Testiranje - verzije u informacionim sistemima;
Uklanjanje uoenih nedostataka i izrada - verzije programa;
Obuka za odabrane korisnike na - verziji;
Testiranje kod korisnika u paralelnom radu sa dosadanjim programom;
Uklanjanje nedostataka i izrada stabilne verzije;
Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka;
Obuka za ostale korisnike;
Uvoenje koritenja programa kod ostalih korisnika;
Obuka za upoznavanje sa mogunostima programa za odabrano poslovodstvo;
Prikupljanje primjedbi korisnika i novih zahtjeva;
Izrada slijedee faze/verzije programa. Povratak na taku 5).
2.3.6. Izvjetaj o projektu

Izvjetaj o projektu obrauje probleme i dostignua projekta, a moe imati oblik
prikazan tabelom 2.5.
Tabela 2.5.
Saetak
- Saetak prijedloga
- Kratko obrazloenje
oekivanih koristi
- Kratko objanjenje
sadraja izvjetaja
Prikupljene informacije
- Kratak opis projektnog zadatka
- Kratko objanjenje provedenih
aktivnosti
injenice i zakljuci
(moe se potkrijepiti matricom problema i
moguih rjeenja)
Problemi i analiza problema

Mogunosti i analiza mogunosti
Direktive i implikacije
Detaljan prijedlog
- Obrazloenje prijedloga
* Hitne prepravke
* Brze prepravke
* Unapreenja
* Novi razvoj
Plan projekta
* Poetni ciljevi projekta
* Poetni glavni plan
projekta (na nivou faza)
* Detaljni plan za slijedeu
fazu
Prilozi
- Zahtjev za uslugama sistema
- Matrica obrazloenja problema
- (ostala dokumentacija)
35
2.3.7. Odreivanje poslovnih ciljeva

Za projekte koji prou poetnu selekciju vri se produbljivanje analize problema.
Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rjeavanja i da li je
gradnja IS isplativa. Vri se detaljnija analiza problema, njihovih uzroka i posljedica,
imajui na umu misao: "Ne pokuavaj popraviti prije nego shvati kako radi!" Takoe je
potrebno izvriti analizu poslovnih procesa odgovarajui na pitanja:
Koji su najvei problemi?
Koja su mogua rjeenja problema?
Kako informatizacija moe pomoi?
kao i grubo modeliranje postojeeg sistema.
Mogu se koristiti razliite formalne metode, od kojih su najznaajnije:
1. Analiza kritinih faktora uspjeha (Critical Success Factors (CSF)), odnosno
inilaca, kojima poslovodstvo posveuje posebnu panju. Ti inioci treba
srazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr. brzi odgovor na
zahtjeve klijenata, odnos cijene i kvaliteta proizvoda, ... );
2. Planiranje poslovnog sistema (Business Systems Planning (BSP)) firme IBM,
odnosno analiza poslovnih procesa analizom od vrha prema dolje i uoavanje
podataka povezanih sa procesima;
3. Analiza izvodljivosti i procjena trokova - koristi.
2.3.8. Uzroci i posljedice problema, ciljevi i ogranienja

Istraivanje uzroka problema, koji mogu biti raznovrsni, se mogu ilustrovati na
slijedeem jednostavnom primjeru:
Problem:
Vidljivi znak:
Razlog:
Uzrok:
pad prodaje
poveani opoziv (storno) narudbi
nezadovoljstvo kupaca
spor sistem za naruivanje
Zadatak analitiara je da razdvoji uzroke i posljedice problema.

Drugi primjer: Dug red u videoteci nije poseban problem, a moe biti posljedica
pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak
posljedica runog unosa podataka i izdavanja rauna.
36
U razmatranom primjeru analitiar treba razmotriti da li je zahtjev vlasnika

videoteke za ubrzanjem procesa izdavanja filmova realan.
Primjeri poslovnih ciljeva mogu biti raznovrsni. Ovdje e biti navedeni, kao
primjeri, neki od moguih ciljeva: pomoi reorganizaciju u trino orijentisanom
poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima i
mjestu nastanka svakog troka u sistemu, uskladiti hijerarhiju odluivanja sa
hijerarhijom u poslovnom sistemu ili racionalizovati utroak novca za ... .
Ogranienja mogu biti slijedea: osoblje (npr. odjel informatike smije zaposliti
najvie tri stalno zaposlena radnika), materijalni troak (npr. nabavka kancelarijskog i
potronog materijala ne smije premaiti XXX ),raunarska oprema (npr. projekat se
mora obaviti bez nabavke novog hardvera ili poeljno je da troak opreme predstavlja
najmanje 33% budeta), finansijska sredstva (npr. ukupni budet projekta je XXXXX )
ili naknade izvoaima ne smiju prekoraiti XX% ukupnog iznosa).
Analiza uzroka i posljedice problema, njihovi ciljevi i ogranienja su prikazani u
tabeli 2.6 [Fertalj & Kalpi, 2005].
Tabela 2.6.
ANALIZA UZROKA I POSLJEDICA
Problem ili mogunost
Uzroci i posljedice
1. Vrijeme odgovora
na narudbu je
neprihvatljivo dugo.
1. Promet je povean, a
broj slubenika
smanjen. Vrijeme
obrade narudbe je
isto.
2. Sistem previe zavisi
o runom unosu.
Pojedine vrijednosti
se unose vie puta.
Posljedica je da se
narudbe obrauju
due nego je
potrebno.
3. Sredinji raunar radi
na maksimumu svoga
kapaciteta, ta se
ogleda u sporijem
radu aplikacije za
unos narudbi.
Budui da slubenici
pokuavaju bre
raditi, poveao se
broj greaka pri
unosu.
CILJEVI I OGRANIENJA SISTEMA

Ciljevi sistema
Ogranienja sistema
1. Smanjiti vrijeme
unosa pojedine
narudbe za 30%.
1. Broj zaposlenih u
obradi narudbi se ne
moe poveati.
2. Runi unos narudbi

svesti na 50%
ukupnog broja.
2. Novi sistem mora biti

kompatibilan sa
postojeim Windows
XX standardom.
3. Na ekranskoj formi
raunara za runi
unos smanjiti broj
potrebnih pritisaka na
tastaturu.
4. Prenijeti unos
podataka sa
sredinjeg raunara
na PC.
5. Zamjeniti postojee
obrasce za
prikupljanje narudbi
mrenim sistemom
izmeu skladita i
prodaje, tako da se
eliminie upotreba
3. Novi sistem mora biti

kompatibilan sa ve
odabranim sistemom
za automatsku
identifikaciju
tapiastim kodom.
4. Obrasci za
prikupljanje narudbi
iz skladita nisu
oblikovani za
racionalno
popunjavanje, to
dodatno usporava
unos narudbi.
37
papirne
dokumentacije.
2.3.9. Modeliranje postojeeg sistema

Svrha modeliranja postojeeg sistema je preciziranje dometa projekta, kao i
verifikacija razumijevanja problema i usaglaavanje percepcije sistema i stavova
izmeu uesnika (korisnici, informatiari). Pri tome primjeniti taktiku skrivanja zanemarivanja detalja i usredotoenje na ono to je zaista vano (npr. izbjegavanje
prouavanja tehnikih detalja u ranim fazama).
Kreirati globalni, okvirni, grubi model sistema i to: model organizacije i resursa
(kontekst, organizaciona struktura, prostorni raspored sredstava), globalni model
procesa (funkcionalna dekompozicija, tok kljunih poslovnih procesa, kruenje
dokumenata i protok informacija) i globalni model entiteti-veze (kategorije podataka,
klase podataka (ne klase objekata!)).
2.3.10. Planiranje informacionog sistema

Planiranje informacionog sistema se sastoji od analize problema, povoljnih prilika i
moguih rjeenja problema, definisanja ciljeva i zadataka informacionog sistema, kao i
procjena ogranienja. Tu spada ponovna procjena i preciziranje opsega projekta, a po
potrebi i revizija glavnog plana.
Tokom izvoenja projekta esto se dogaa polagano, ali znaajno, poveanje
obima uslijed pogrene procjene ili razliitog tumaenja ciljeva izmeu korisnika i
izvoaa, tzv. puzei domet projekta. Granice projekta moraju biti definisane to je
mogue preciznije. Time se kasnije poveanje projekta, moda, nee ukloniti, ali e se
barem moi kontrolisati.
Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i
procjena njegove uspjenosti. Planira se prototip koji se moe uspjeno i brzo
realizirati (npr. 3 do 9 mjeseci, u zavisnosti o veliini itavog projekta). Poeljno je
realizovati takav prototip koji e omoguiti procjenu moguih tehnikih rjeenja IS
38
(alternativa) i prijedlog najboljeg rjeenja, a pored toga vratiti uloenu investiciju. Na

kraju se (opet!) moe oekivati pokretanje, odbacivanje, odgaanje ili prilagavanje
(ostalih, pojedinih) projekata.
Tabela 2.7 prikazuje idejno rjeenje plana razvoja IS.
Tabela 2.7.
Saetak
- Saetak prijedloga
- Saetak problema, mogunosti i
direktiva
- Kratki navod ciljeva unapreenja
sistema
- Kratki navod sadraja izvjetaja
Poznate informacije
- Popis odranih razgovora i
kordinisanih grupnih sastanaka
- Popis ostalih izvora informacija
- Opis tehnika koritenih u analizi
Pregled postojeeg sistema
- Strategijske odrednice
- Modeli postojeeg sistema
* Model interfejsa (kontekst)
* Model resursa (prostor)
* Model procesa (funkcija)
* Model podataka (kategorije)
Analiza postojeeg sistema

* problemi, mogunosti i analiza uzroka
i posljedica za pojedine elemente
- Performanse
- Informacije
- Ekonomija
- Kontrola
- Djelotvornost
- Usluge (servisi)
Detaljni prijedlozi
- Ciljevi i prioriteti unapreenja sistema
- Preporuke unapreenja sistema
- Plan projekta
* Precizirati domet projekta
* Revidirati glavni plan
* Detaljni plan za slijedei
korak
Dodaci
- Modeli sistema (ako nisu dio
studije)
- (ostala dokumentacija prema potrebi)
2.4. Modeli razvoja informacionih sistema

2.4.1. Sekvencijalni (vodopadni) model razvoja informacionog sistema
Polazna pretpostavka metodologije ivotnog ciklusa je da se faze razvoja realizuju
strogo sekvencijalno, istovremeno za cijeli programski proizvod. Kada je rije o
informacionom sistemu, tada se svaka faza istovremeno primjenjuje na svaki od
podsistema, u okviru identifikovane arhitekture IS. Istovremeno se, takoe, projektuje i
shema baze podataka IS. Realizacija naredne faze ne zapoinje dok se tekua faza ne
zavri. Greke iz prethodnih faza, otkrivene u tekuoj, zahtjevaju da se one otklone i
dokumentuju vraanjem u prethodne i prolaskom kroz sve faze koje slijede iza faze
39
gdje je greka napravljena. Ovakav nain primjene metodologije ivotnog ciklusa i

strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primjene
metodologije ivotnog ciklusa. Dobre strane ovog pristupa su: integrisanost IS, dobra
dokumentovanost i praktino istovremeni zavretak svih podsistema IS. Zahvaljujui
dobroj dokumentovanosti pojednostavljeno je odravanje aplikacija IS. Takoe, ovaj
pristup daje dobre garancije da e, u konanom vremenu, doi do zadovoljavajueg
rjeenja programskog proizvoda, ime se smanjuje rizik od neuspjeha razvoja.
Sekvencijalni pristup, pored dobrih osobina, ne daje uvijek prave efekte kada je u
pitanju ostvarenje prethodno definisanih ciljeva. Uzroci su viestruki, a neki od njih su
slijedei [Mogin et al. 2000]:
1. U sekvencijalnom modelu primjene metodologije ivotnog ciklusa krajnji
korisnik nije dovoljno ukljuen u proces razvoja programskog proizvoda;
2. Izmeu poetka projekta i prvih operativno primjenljivih rezultata kod korisnika
vremenski interval je dosta dug;
3. esto se javlja potreba da se precizni, metodoloki kompleksni projektantski
koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih
zahtjeva;
4. Umjesto da to bude postupno, postoji potreba da se u razvoj IS odjednom
uloe znaajna finansijska sredstva.
Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za
posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani
korisniki zahtjevi esto otkrivaju tek u fazi uvoenja aplikacije u upotrebu, to je jako
kasno jer se korekcija greaka i odravanje komplikuju, a produava se vrijeme
potrebno za dobijanje konanog rjeenja aplikacije. U cilju izbjegavanja negativnih
efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni,
inkrementalni, spiralni, zvjezdasti, V model i drugi manje znaajni modeli. Mogu se
izdvojiti slijedee varijante sekvencijalnog (vodopadnog) modela: klasini vodopadni
model, pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj.
Klasini vodopadni model (slika 2.1(a)) redoslijedno (sekvencijalno) napreduje
iz faze u fazu. Nisu dozvoljene naknadne promjene rezultata prethodnih faza.
Prikladan je velikim projektima (investicijama), za dobro definisano okruenje, gdje
postoje razraene procedure rune obrade ili raunarski sistem koji treba unaprijediti.
Nedostaci ovog modela su izraeni u sluaju greaka ili novih/promijenjenih zahtjeva,
kao i u potrebi uvoenja prema gore (bottom up) modula, podsistema i sistema. Sistem
nije upotrebljiv dok nije u potpunosti gotov. Problem predstavlja i predodba o
proizvodu na osnovu pisane specifikacije.
40
Pseudostrukturirani vodopadni model (slika 2.1(b)) sadri povratnu vezu i

mogunost promjene rezultata prethodnih faza. Ovaj model razvoja IS omoguava
primjenu tehnika strukturiranog programiranja.
Analiza
Analiza
Oblikovanje
Oblikovanje
Izrada
Izrada
Evaluacija
Evaluacija
Primjena
Primjena
(a)
(b)
Slika 2. 1. Uporedni prikaz klasinog razvoja (a), pseudostrukturiranog i

radikalnog razvoja (b).
Radikalni (strukturirani) razvoj (slika 2.1(b)) omoguava da se aktivnosti
razliitih faza mogu obavljati istovremeno. Dozvoljava koritenje rjenika podataka,
programskih jezika etvrte generacije (4GL) i generatora aplikacija. Prikladan je kada
se unaprijed ne zna konani izgled sistema.
2.4.2. V model razvoja informacionog sistema

V model razvoja IS (slika 2.2) omogua definisanje rezultata (proizvoda)
pojedinih faza koji se proslijeuju u slijedee faze. Tim rezultatima se testiraju elementi
IS na razliitim stepenima razvoja.
Analiza
41
Test
prihvatljivosti
Scenariji
aplikacije
Specifikacija
zahtjeva
Testirani
sistem
Strukturirano
oblikovanje
Integracija
sistema
Ogledni
sluajevi
Testirani
softver
Model
sistema
Detaljno
oblikovanje
Ogledni
sluajevi
Dizajn
modula
Integracija
modula
Testirani
moduli
Kodiranje i
testiranje
Slika 2.2. Primjer V modela.
2.4.3. Prototipski model razvoja informacionog sistema

Uz strukturirani pristup, prototipski pristup razvoju programskog proizvoda
predstavlja koncept koji se moe primjeniti u okviru metodologije ivotnog ciklusa.
Prototipski pristup postaje u punoj mjeri praktino primjenljiv (iako je ideja o
prototipskom pristupu u softverskom inenjerstvu bila prisutna dosta rano) tek pojavom
sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided
Software Engineering) proizvoda, koji su integrisani sa okruenjem etvrte generacije.
U zavisnosti od njegove namjene, mogu se uoiti slijedee tri vrste prototipskog
modela. Model oponaanja (model u prirodnoj veliini), odnosno jednoekranski ili
42
vieekranski model kojim se prikazuje kako e izgledati dio sistema (npr. interfejs),
istraivaki model, za istraivanje dijelova sistema kako bi se provjerile neke kljune
postavke (npr. provjera performansi odreenog modula) i, na kraju, ugradbeni model,
tj. traenje razliitih naina na koje se sistem moe izgraditi (npr. koji sistem za
upravljanje BP, programski jezik, raunari).
Prototip moe postupno, inkrementalnom doradom, da postane dio zavrnog IS.
Prototipski razvoj podrazumijeva iteraktivni pristup, obino koritenjem 4GL. Radni
model daje se na uvid korisniku i omoguava korisniku stvaranje slike o izgledu
sistema. Korisnik daje primjedbe za popravak i poboljanja, ime se stie bolja slika o
zahtjevima korisnika. Ujedno se uklanjaju mogua iznenaenja na kraju razvoja.
Savremeni softverski alati omoguavaju brzu izradu prototipa. Funkcionalni
prototip dogradnjom moe da postane radni sistem (slika 2.3). Ovakav pristup razvoju
IS je prikladan za male projekte. Prednosti su u iteracijama promjena (korisnici se
smiju predomisliti), poveanju kreativnosti i brzini razvoja. Nedostaci su u tome to se
zaboravlja da prototip nije pravi sistem, mogui neuspjeh zamjene prototipa radnim
sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije
nikad nee biti napravljene, kao i nemogunost ispravne procjene i planiranja resursa.
Ogranieni/strukturirani razvoj prototipa slui kao sredstvo za odreivanje
zahtjeva. Dobija se nefunkcionalni prototip (koji se ne moe koristiti u obavljanju radnih
zadataka korisnika, a sadri izgled ekranskih formi, menia i izvjetaja), iji se razvoj u
odreenom trenutku prekida i slijedi faza oblikovanja sistema (slika 2.4).
Odreivanje zahtjeva
Dizajn prototipa
Izrada prototipa
Razvoj prototipa
Radni sistem
Slika 2.3. Dijagram brzog razvoja prototipa.
43
Odreivanje zahtjeva
Dizajn prototipa
Izrada prototipa
Razvoj prototipa
Radni sistem
Prototip
Specifikacije
zahtjeva
Dokumentovanje zahtjeva
Oblikovanje
Slika 2.4. Dijagram ogranienog/strukturiranog razvoja prototipa.

Praktini aspekti primjene prototipskog pristupa su viestruki. Rije je, uglavnom,
o injenicama proisteklim iz iskustva u praktinoj primjeni prototipskog pristupa. Zbog
toga, moe se rei da su te injenice prije savjetodavnog, nego formalno strogog
karaktera. Opte preporuke za primjenu prototipskog pristupa su slijedee [Mogin et al.
2000]:
1. Potrebno je, prije poetka primjene prototipskog pristupa, precizno definisati
standarde za izgled korisnikog interfejsa, projektovanje i programiranje.
Standarde treba usaglasiti sa mogunostima odabranog CASE proizvoda, a
generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi
za programiranje i izgled korisnikog interfejsa, a sve u cilju postizanja bolje
podrke standarda;
2. Preporuuje se dekomponovanje cjeline IS na manje projekte, a zatim
definisanje nieg stepena meusobne integracije informacionih podsistema, u
odnosu na klasinu primjenu metodologije ivotnog ciklusa;
3. Kako korisnik ne bi bio doveden u zabludu, prilikom predaje korisniku prototipa
aplikacije, obavezno ga upoznati sa injenicom da je u pitanju prototip a ne
konano rjeenje. Pri tome treba precizirati nain upotrebe prototipa od strane
korisnika;
44
4. Ne treba praviti vie od tri prototipa jedne aplikacije, ukoliko je to mogue,

kako se ne bi produilo ukupno vrijeme izrade aplikacije i dolo do zamora
krajnjih korisnika i projektantskog tima;
5. Treba se orijentisati preteno ka odbacivim prototipovima aplikacija, ukoliko se
eli postii to krae vrijeme dolaska do prototipa, jer se time izrada samog
prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatora
koda, a koristi BP ija shema ne mora biti blizu konanog rjeenja);
6. Radei sa prototipom aplikacije, korisnik treba da upotrebljava iskljuivo test
podatke. On mora biti prethodno pripremljen na injenicu da, ukoliko u
meuvremenu doe do prestrukturiranja sheme BP, uneseni test podaci mogu
biti izgubljeni. Do gubitka test podataka moe doi u situaciji kada je za njihovo
prestrukturiranje potrebno uloiti veliki napor, pa se od predstrukturiranja
svjesno odustaje, ili kada je takvo prestrukturiranje nemogue izvriti zbog
izmjena u shemi BP;
7. Prototip aplikacije moe da predstavlja rjeenje koje je dobijeno pomou
generatora koda nekog CASE proizvoda, prvenstveno na osnovu specifikacija
konceptualnog nivoa. To znai da se detalji, koji se definiu tek u
implementacionom projektu, a nisu podrani odgovarajuim generatorom, ne
realizuju u okviru prototipa aplikacije kako slijedea generisanja ne bi unitila
tako isprogramirane cjeline. Na taj nain se postie kratko vrijeme izrade
prototipskog rjeenja, ali ne i njegova potpuna funkcionalnost;
8. Ako je mogue, u prototip aplikacije treba ukljuiti i odgovarajue izvjetaje, jer
tada korisnik lake sagledava upotrebljivost aplikacije;
9. Rjeenja IS, istih ili slinih poslovnih sistema, mogu biti dobra osnova u
primjeni prototipskog razvoja.
Potekoe koje se mogu izbjei primjenom prethodno opisanih preporuka, a koje
se mogu javiti prilikom primjene prototipskog razvoja, su slijedee. Iterativni pristup
moe dovesti do zamora krajnjih korisnika i projektanata. U cilju izbjegavanja
problema, posebno treba obratiti panju na preporuke 3 i 4. Upotreba generatora koda
je mogua tek kada je formiran odgovarajui dio sheme BP, a sa druge strane treba
koristiti prototip aplikacije upravo da bi se pribavile sve relevantne informacije za
strukturiranje sheme BP, to znai da su ova dva zahtjeva meu sobom u suprotnosti.
Primjena preporuka 5, 7 i 9 vodi ublaavanju ovog konflikta. Ako se radi o neodbacivim
prototipovima (neodbacivi prototipovi se evolutivnim podeavanjem pretvaraju u
konana rjeenja aplikacija), dorada izgenerisanih aplikacija moe biti zamoran i
vremenski zahtjevan posao. U cilju pribliavanja korisnikog interfejsa i
funkcionalnosti generisane aplikacije konanom rjeenju, odnosno olakavanja
postupka dorade izgenerisanih aplikacija, vano je preduzeti mjere predviene
45
preporukom 1. Usaglaavanje podataka, unesenih putem neodbacivog prototipa sa

bitno prestrukturiranom shemom BP, je esto vremenski zahtjevan i neizvjestan posao.
U cilju izbjegavanja problema, posebno treba obratiti panju na preporuke 5 i 6.
Intervencije na prototipu kod korisnika mogu stvoriti lani utisak da je projektovanje IS
trivijalan posao. Da bi se problem izbjegao, posebno treba obratiti panju na preporuku
3. Primjena preporuke 9, ako za nju postoje uslovi, moe biti u funkciji ublaavanja
ovog problema. Ako je rije o manje iskusnim korisnicima ili projektantima, moe se
dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva,
odnosno pravovremeno identifikovanje informacionih zahtjeva, a da pri tome projektant
ne uoi takav propust na vrijeme. Primjena preporuka 8 i 9 moe pozitivno uticati na
ublaavanje ili izbjegavanje ovog problema.
Primjena prototipskog pristupa IS je pokazala da on nije primjeren razvoju
integrisanih IS, jer insistiranje na brzom uvoenju aplikacija u funkciju dovodi do
parcijalizacije IS. Zbog toga je vano obratiti panju na preporuku 2. Aplikacije koje se
razvijaju samo primjenom prototipskog pristupa mogu postati izolovana ostrva.
Imajui u vidu tu injenicu, direktna primjena iskljuivo prototipskog pristupa je mogua
u sluaju da treba razvijati skoro izolovane podsisteme sa niskim stepenom
meusobne integracije. Sa druge strane, oekuje se da prototipski pristup doivi svoju
punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primjene
metodologije ivotnog ciklusa. U tom smislu, posebno znaajnu ulogu ima evolutivni
pristup razvoju IS.
2.4.4. Evolutivni model razvoja informacionog sistema

Primjena IS mijenja pogled korisnika, a njegove potrebe se mijenjaju (rastu)
tokom primjene. Moe se zakljuiti da IS raste sa poslovnim sistemom koga podrava.
Te iste pojave su prisutne i u razvoju IS. Jedan od osnovnih principa, na kome se
zasniva primjena sekvencijalnog modela metodologije ivotnog ciklusa, je da
realizacija naredne faze ne zapoinje dok se tekua faza ne zavri. Uoava se da
upravo primjena ovog principa, kod nekih projekata, moe intenzivirati negativne
efekte primjene metodologije ivotnog ciklusa.
Evolutivni model primjene metodologije ivotnog ciklusa, nasuprot
sekvencijalnom, predvia da je za odreene faze ivotnog ciklusa programskog
proizvoda mogue da naredna faza zapone prije nego to se prethodna zavri, to
dovodi do odreenog stepena paralelizma u realizaciji tih faza. Prema tome, faze
ivotnog ciklusa poinju da se sprovode iterativno. Do ove ideje se dolo na osnovu
pretpostavke da ne treba odjednom realizovati kompletnu fazu i utroiti za to veliku
koliinu vremena i novca, u situaciji kada se projektantske aktivnosti izvode na osnovu
46
nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednu

fazu treba da obezbjedi bolju osnovu za kasniji uspjeni zavretak prethodne faze.
Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem
nedovoljno precizno identifikovanih informacionih zahtjeva, smatra se da njegova
praktina primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom, kao
metodom za tano utvrivanje informacionih zahtjeva. Za utvrivanje informacionih
zahtjeva se preteno primjenjuju odbacivi prototipovi.
Primjenjuju se dvije varijante evolutivnog pristupa. Prema prvoj, nakon utvrivanja
preciznih informacionih zahtjeva, rezultati konceptualnog i implementacionog
projektovanja BP se integriu, a projekti podsistema se usaglaavaju sa shemom
integrisane BP. Drugim rijeima, potprojekti se ponovo posmatraju kao cjelina i na njih
se primjenjuju, neto izmjenjeni, koraci konceptualnog i implementacionog
projektovanja, kao pri primjeni sekvencijalnog modela metodologije ivotnog ciklusa.
Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog
modela metodologije ivotnog ciklusa i prototipskog pristupa, ali ne rjeava probleme
dugog vremenskog intervala od poetka projekta do pojave prvih, operativno
primjenljivih rezultata kod korisnika, i potrebe ulaganja finansijskih sredstava
odjednom, a ne postupno. Prema drugoj varijanti, potprojekti se realizuju meusobno
nezavisno i mogu biti fazno pomjereni u vremenu. Na taj nain se rjeavaju problemi
dugog vremenskog intervala od poetka projekta do pojave prvih rezultata i potrebe
ulaganja odjednom finansijskih sredstava. Ovakav nezavisan rad, meutim, moe
dovesti do nieg stepena integrisanosti IS.
Analiza
Oblikovanje
Analiza
Izrada
Oblikovanje
Analiza
Analiza
Evaluacija
Izrada
Oblikovanje
Oblikovanje
Evaluacija
Izrada
Izrada
Evaluacija
Evaluacija
Slika 2.5. Mogui evolutivni model primjene metodologije ivotnog ciklusa.
47
Na slici 2.5 je prikazan mogui evolutivni model primjene metodologije ivotnog

ciklusa. Razvoj se vri u inkrementalnim koracima, dovoljno malim da se mogu
obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada,
evaluacija) vodi operatibilnom proizvodu koji se isporuuje i koji generie naredne
zahtjeve.
2.4.5. Inkrementalni model razvoja informacionog sistema

Kao i u sluaju evolutivnog modela, na poetku primjene inkrementalnog modela,
kompletno se sprovodi faza strategije metodologije ivotnog ciklusa. Nakon toga,
formiraju se relativno manji potprojekti sa niim stepenom meusobne integracije i
utvrde se slijedei parametri potprojekata: ciljevi, resursi i rok predaje u upotrebu.
Ciljevi i resursi su varijabilni parametri, koji se po potrebi mogu mijenjati u toku samog
projekta, dok je rok predaje u upotrebu programskog proizvoda obavezno fiksni
parametar. Potprojekti se realizuju meusobno nezavisno i mogu biti fazno pomjereni
u vremenu. Inkrementalni model se moe posmatrati kao posebna varijanta
evolutivnog modela ivotnog ciklusa.
2.4.6. Spiralni i zvjezdasti model razvoja informacionog sistema

Kod spiralnog modela primjene metodologije ivotnog ciklusa, na poetku svake
faze provodi se procjena rizika. Nastoje se utvditi mogui rizici i razrijeiti ih prije
nastavka (uklanjanjem ili svoenjem na najmanju moguu mjeru). U sluaju da je rizik
prevelik, projekat se prekida (slika 2.6).
Analiza rizika
ANALIZA
Verifikacija
Analiza rizika
OBLIKOVANJE
Verifikacija
PRIMJENA
Analiza rizika
IZRADA
Testiranje
Analiza rizika
INTEGRACIJA
Verifikacija
Slika 2.6. Dijagram procjene rizika.
48
Spiralni model metodologije ivotnog ciklusa prikazan je na slici 2.7(a). Y osa

predstavlja kumulativni troak, a na x osi svaka petlja spirale predstavlja jednu fazu
razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza moe biti realizovana
redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se
prolaskom kroz osu x.
kumulativni troak
integracija
Programiranje
Projektovanje
izrada
oblikovanje
Upravljanje projektom
analiza
Uvoenje u
upotrebu
1.
2.
3.
4.
Snimanje i
analiza
Analiza rizika, procjena alternativa;

Razvoj i verifikacija slijedeeg proizvoda;
Planiranje slijedee faze;
Pregled odreivanje ciljeva, alternativa i ogranienja.
(a)
(b)
Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije ivotnog ciklusa.
Zvjezdasti model, slika 2.7(b), ne uvodi stroga ogranienja u redoslijedu primjene
faza i koraka metodologije ivotnog ciklusa. To ne znai da prirodnog redoslijeda
izvravanja odreenih koraka metodologije u ovom modelu nema, ve da on zavisi od
vie faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno
inenjerstvo, ili potreba za reinenjeringom postojeeg IS, mogu zahtjevati potpuno
obrnuti redoslijed primjene faza ivotnog ciklusa (primjena "odozdo na gore").
2.5. Metodologija razvoja informacionih sistema

2.5.1. Uvod u metodologiju razvoja informacionog sistema
Metodologija se moe definisati kao metoda + idejni pristup. Sadri u sebi
kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih
filozofijom, koji potpomau izgradnju informacionih sistema [Avison & Fitzgerald, 1995].
Metodologija predstavlja skup naela izrade IS, koji se u odreenoj situaciji svodi na
metodu jedinstveno prikladnu toj situaciji [Checkland, 1994].
49
Komponente metodologije se mogu razvrstati u slijedeih pet taaka:

1.
2.
3.
4.
5.
Etape projekta;
Zadaci za svaku pojedinu etapu;
Izlazi (projektna dokumentacija);
Preporuke (vodi) upotrebe odabranih tehnika i pomagala;
Nain upravljanja projektom i nadzorom projekta.
Cilj metodologije je da omogui sistemski postupak razvoja kojim e se moi

pratiti napredak, uspostavi komunikaciju izmeu uesnika ukljuenih u izgradnju IS
(poslovodstvo, korisnici, analitiari, programeri), osigura skup tehnika koje e
omoguiti da se zadaci izvravaju na standardne i provjerene naine, osigura efikasan
nadzor sa ciljem uoavanja greaka u ranim fazama. Osim navedenog, cilj
metodologije je da omogui elastine promjene poslovanja i tehnologije (npr.
odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom e se ukloniti ad
hoc rjeavanje problema, odredi ili ukae kada i u kojoj mjeri je potrebno ukljuivanje
korisnika, te potie i omoguava ukljuivanje korisnika kada se za to ukae potreba.
Metodologija omoguava da se dovoljno panje posveti analizi poslovanja, ime e se
osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika.
Jeftinije je otkriti i popraviti greku u ranim fazama, jer je lake popraviti
dokumentaciju nego mijenjati programski kd. Izmjene u kasnijim fazama zahtjevaju
promjene rezultata prethodnih faza. Lake je pronai greku tokom faze u kojoj je
nastala, nego traiti je i popravljati na osnovu posljedinih uinaka primijeenih u
kasnijim fazama.
C
i
j
e
n
a
Plan Analiza Oblikovanje Izrada Odravanje
Slika 2.8. Relativno trajanje i cijena otkrivanja greaka u razliitim fazama.

Relativno trajanje i cijena otkrivanja greaka u razliitim fazama razvoja IS
prikazani su na slici 2.8.
50
2.5.2. Pristup razvoju informacionog sistema

Tokom projektovanja IS primjenjuju se, uglavnom, sve vrste modela metodologija
ivotnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijedei pristupi
razvoju.
Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup
jer omoguava opisivanje specifinih funkcija. Prisutan je problem odreivanja nivoa
dekompozicije (nivoa osnovnih procesa). Nedovoljna panja je posveena modelu
podataka, ta za posljedicu moe imati neodgovarajui model baze podataka i oteanu
integraciju aplikacija uslijed nekompatibilnih podataka.
Usmjerenost podacima (npr. IEM) obezbjeuje sloeniji opis strukture podataka,
ali jednostavnije tokove podataka. Procesi se definiu analizom podataka (grupiu oko
podataka) i bre konvergira kraju, jer je skup objekata (entiteta) modela konaan.
Poetak razvoja definisanjem dogaaja (npr. JSD) je primjereniji sistemima za
rad u stvarnom vremenu.
2.5.3. Komercijalne metodologije za razvoj informacionog sistema

Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih
sistema su navedeni u originalu:
AD/Cycle (Application Development Cycle),
BSP (Business System Planning),
CASE*Method,
IEM (Information Engineering Methodology, Martin),
JSD/JSP (Jackson System Development/ Jackson System Programming),
SA/SD (Structured Analysis / Structured Design),
SASS (Structured Analysis and System Specification),
SSM/M (Soft Systems Method / Multiview),
SSA (Structured System Analysis),
SSADM (Structured System Analysis and Design Method),
Yourdon (Yourdon Structured Method).
Objektno usmjerene metodologije:
Yourdon/OO (Yourdon / Object Oriented),

OMT (Object Modelling Technique),
BOOCH (Booch93),
Schlaer-Mellor,
Unified Modelling Process (Rational).
51
Primjena neke od ovih metodologija ne znai da e IS biti dobar! Zahtjevi

korisnika se mogu mijenjati u vremenu. Preporuene aktivnosti ne moraju uvijek biti
prikladne, primjenjive ili potrebne. Insistiranje na provoenju propisanih procedura vodi
u zanemarivanje stvarnih problema, to za posljedicu moe imati formalno dobro
napravljen, ali neuspjean sistem.
Veina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije
podravaju sve faze ivotnog ciklusa (npr. IEM). Metodologije treba da su podrane
odgovarajuim alatima za upravljanje i projektovanje (CASE), to nije uvijek ispunjeno
u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano
u praksi, preice do rjeenja problema zasnovane na slinim iskustvima, kao i
prilagoavanje razvojnog procesa.
2.6. Savremeni postupci razvoja informacionog sistema

2.6.1. Brzi razvoj aplikacija
Brzi razvoj aplikacija (Rapid Application Development (RAD)) je efikasna izrada
programskog proizvoda u relativno kratkom vremenu. Ovo se postie sistemskom i
vremenski saetom primjenom slijedeih tehnika i alata: aktivno i efikasno ukljuivanje
korisnika, odgovarajue upravljanje projektom, ispravna upotreba metoda i tehnika
razvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao i upravljana
izrada prototipa.
RAD se obavlja malim ekipama u trajanju od 60 do 120 dana (priblino 20
sedmica) za podsistem veliine od 25 do 30 relacija (tabela). Cijena postignutog
ubrzanja moe biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne
postane sebi svrhom, jer tada vodi u improvizaciju (izradu prirunih rjeenja) i prljavi
razvoj.
Faze brzog razvoja su:
1. JEM (Joint Enterprise Modeling ) zdrueno modeliranje organizacije,
odnosno sjednice na kojima poslovodstvo i analitiari trae naine usmjerenja
organizacije i naine kako je uiniti kompetentnom. Istrauju se ciljevi
organizacije, problemi, kritini inioci uspjeha te strategijske mogunosti;
2. JRP (Joint Requirements Planning) zdrueno planiranje zahtjeva, odnosno
analiza zahtjeva za razmatrani poslovni sistem. Prouavaju se funkcije
sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istrauju i
definiu informacione potrebe;
52
3. JAD (Joint Application Design) zdrueno oblikovanje aplikacija. Nastoji se

oblikovati sistem tako da potpuno odgovara zahtjevima. Zahtijeva tijesnu
saradnju korisnika, projektanta i menadera;
4. Konstrukcija - iterativna izrada prototipa;
5. Zavretak projekta - provjera rada, izrada dokumentacije, obuka korisnika.
Primjer: RAD projekat.
Sedmice 1-4
pokretanje projekta, istraivanje, priprema JRP sjednice, obavljanje JRP
sjednice, priprema JAD sjednice;
Sedmice 5-9
prva JAD sjednica, poetak dizajna, konsolidacija JAD dizajna i prototipa,
prototipovi za test uporabljivosti, druga JAD sjednica, zavretak dizajna;
Sedmice 10-14
razvoj i testiranje, priprema konverzije, planiranje zavretka;
Sedmice 15-20
izrada dokumentacije, priprema obuke, obuka, zavrno testiranje, zavretak
projekta.
2.6.2. Informaciono inenjerstvo

(Information Engineering (IE))
Informaciono inenjerstvo (IE) se zasniva na analizi poslovnih zahtjeva iz koje se
izdvajaju aplikacije IS i prioriteti tih aplikacija. Aplikacije postaju projekti u kojima se
provode postupci analize i dizajna da bi se razvili produkcioni sistemi. Za razliku od
klasine strukturirane analize, koja se odvija projekat-po-projekat, informaciono
inenjerstvo je procesno osjetljiva tehnika usmjerena na podatke i primjenjuje se na
organizaciju kao cjelinu ili na neki njen znaajni dio. Osnovno naelo je da se IS
moraju graditi kao to se grade drugi unikatni proizvodi, npr. u graevinarstvu ili
brodogradnji.
Faze informacionog inenjerstva su slijedee:
1. Planiranje strategije IS - Information Strategy Planning (ISP), koje obuhvata
posmatranje poslovanja kao cjeline sa ciljem definisanja opteg,
53
sveobuhvatnog plana i arhitekture za redoslijedni razvoj informacionih

(pod)sistema. Vri se izdvajanje poslovnih podruja i odreivanje prioriteta.
Pod poslovnim podrujem se podrazumjeva skup poslovnih procesa koji se
proteu organizacijom, a moraju biti visoko integrisani da bi se ostvarila
strategija ili misija;
2. Analiza poslovnih podruja - Business Area Analysis (BAA);
3. Prouavanje poslovnih podruja i definisanje poslovnih zahtjeva za visoko
organizirani i integrisani skup informacionih (pod)sistema i aplikacija podrke
poslovnog podruja;
4. Definisanje aplikacija, odnosno izdvajanje aplikacija i definisanje njihovih
prioriteta na osnovu analize poslovnih podruja. Aplikacije postaju projekti u
kojima se primjenjuju drugi postupci analize i dizajna.
Budui da je informacija proizala iz podataka, podaci moraju biti prvi planirani.
Modeliranje zapoinje modelima podataka. Nakon toga se rade modeli procesa, slino
onima u strukturiranoj analizi.
Napomena: O informacionom inenjerstvu bie jo govora u poglavlju 8.
2.6.3. Ekstremno programiranje

(eXtreme Programming (XP))
Naela ekstremnog programiranja nastala su prije desetak godina [Kent Beck,
1996]. XP zahtijeva komunikaciju u svim fazama projekta, meu svim njegovim
uesnicima. Ovdje se prvenstveno misli na komunikaciju meu lanovima razvojnog
tima, zatim na meusobnu komunikaciju lanova tima sa rukovodiocem projekta, te
komunikaciju naruioca sa izvoaima (lanovima razvojnog tima i njihovim
rukovodiocima). Dijelovi softvera, kao i njegova cjelokupna arhitektura, moraju u svakoj
fazi projekta biti jednostavni. Jednostavnost se ostvaruje kontinuiranim
prilagoavanjem programskog kda i svoenjem projektne dokumentacije na
minimalno prihvatljivi nivo.
XP nalae kontinuirane povratne informacija od svih uesnika projekta, to
znaajno podie kvalitet rada i ispunjenje rokova. Dobre povratne informacije
onemoguavaju nerazumijevanje meu uesnicima projekta, te dre projekt na
"pravom putu". U XP hrabrost podrazumijeva sposobnost provoenja tekih odluka
(npr. odbacivanja dijelova koda kada je to neophodno ili nametanja velikih promjena u
kasnoj fazi projekta) ili odluka koje u danom trenutku nisu pretjerano popularne.
Takoe, hrabrost podrazumijeva meusobnu iskrenost svih lanova projektantskog
tima.
54
XP uvaava mogunost promjene specifikacija koje definiu funkcionalnost

sistema. Prihvati promjenu! je jedan od osnovnih XP postulata. Igra planiranja definie
funkcionalnosti slijedee verzije, prije nego to njen razvoj stvarno i pone. U poetku
se kreira grubi plan koji se redefinie kroz razgovore sa naruiocima i korisnicima.
Korisnici se izraavaju "priama", tako da svaka pria definie jedan dio
funkcionalnosti sistema. Priama se dodjeljuju prioriteti i ciljano vrijeme implementacije
(1 do 3 sedmice po zahtjevu). XP preporuuje relativno esto izdavanje novih verzija
sistema, obino u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sistem
zadovoljava funkcionalnost traenu od strane naruioca. esto izdavanje novih verzija
pojaava komunikaciju, a time i dotok povratnih informacija i igru planiranja.
Metafora sistema je analogna onome to veina drugih metodologija naziva
arhitekturom sistema. Metafora mora biti jasno izraena te nedvosmisleno shvatljiva
svim lanovima projektantskog tima. XP ne definie format ili tehniku u kojoj metafora
mora biti izraena. Najei argument osporavaoca XP-a je u tvrdnji da XP
zanemaruje dizajn sistema. U stvati, dizajn arhitekture sistema je kontinuirani proces
koji se u malim koracima odvija tokom itavog razvoja.
Testiranje se sastoji od testova komponenti i testova prihvatljivosti. Prilagoavanje
programskog kda (refactoring) je tehnika kojom se pojednostavljuje programski kod
uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) sloenog koda. Programeri
rade u parovima, na nain da jedan pie kd, a drugi prati pisanje i revidira kd, pazei
da kd bude jasan i razumljiv. Zajedniko vlasnitvo se sastoji u tome da svi inenjeri
koji uestvuju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem
trenutku. XP nalae izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake
implementirane funkcionalnosti.
Zastupljeno je potovanje 40-satne radne sedmice. Smatra se da umorni
projektanti ne mogu postii maksimalnu efikasnost u radu, pa se zabranjuje
prekovremeni rad dvije sedmice zaredom. Naruilac ili predstavnik naruioca mora biti
prisutan prilikom razvoja sistema kako bi bio dostupan u sluaju potrebe za
pojanjenima, te kako bi pomogao u definisanju sistema i pisanju testova. Programeri
moraju pisati kd u skladu sa dogovorenim standardima.
2.6.4. Ujedinjeni razvojni proces

(Unified software development process (UDP))
Ujedinjeni razvojni proces, izvorno nazvan Objectory, kasnije je dobio ime
Rational Unified Process (RUP). Zastupljen je iterativni i inkrementalni razvoj, koji se
obavlja na slijedei nain:
55
1. Softver se razvija i objavljuje po dijelovima;

2. Glavne faze razvoja se obavljaju kroz niz iteracija;
3. Faza konstrukcije (izrade) slijedi nakon provoenja prethodnih faza.
Svaka iteracija se obavlja standardnim ivotnim ciklusom koji ukljuuje analizu,
oblikovanje, ugradnju i provjeru. Rezultat iteracije je proizvod zavrnog kvaliteta,
provjeren i integrisan, koji zadovoljava podskup ukupnih zahtjeva. Isporuke mogu biti
interne ili prema korisnicima. Mogu se izdvojiti slijedee glavne faze razvoja (slika 2.9).
Poetak (Inception), koga sainjavaju opravdanje razloga za pokretanje projekta,
prikupljanje najvanijih zahtjeva (10% detaljno) i odreivanje dosega projekta.
Poetak
Elaboracija
Gradnja
Prelaz
Zahtjevi
Analiza
Oblikovanje
Ugradnja
Provjera
iter.
#1
iter.
#2
iter.
#n-1
iter.
#n
Inkrementi
Slika 2.9. Dijagram glavnih faza razvoja.

Elaboracija (Elaboration), odnosno prikupljanje detaljnih zahtjeva (80%), globalna
analiza i dizajn, ustanovljavanje osnovne arhitekture i planiranje konstrukcije.
Konstrukcija (Construction), gradnja, se sastoji od prikupljanja ostalih zahtjeva
plus promjene zahtjeva, razrade arhitekture i izrade sistema, kao i kontinuirane
integracije.
Prelaz (Transition) sainjavaju beta testiranje, podeavanje performansi, obuka
korisnika, provjera prihvatljivosti i zadovoljstva korisnika.
56
Post-implementacija (Post-deployment)
ouvanje integriteta aplikacije.
je
nastavak
evolutivnog
razvoja,
Broj i trajanje iteracija za ujedinjeni razvojni proces, za projekte do 18 mjeseci, je

okvirno 3 do 6 iteracija. Uobiajeno, iteracije imaju podjednako trajanje. Trajanje
iteracije moe varirati u zavisnosti od faze. U fazi konstrukcije to vrijeme je due. Prva
iteracija je najee i najtea. Zahtijeva pripremu okruenja, ekipe i posla. Opasna je
zbog mogueg pretjeranog optimizma. Ako se krivo procjeni moe izazvati pomake i
neeljene uinke. Smanjenje broja iteracija za posljedicu ima slabije rezultate razvoja.
2.6.5. Izbor pristupa razvoju informacionog sistema

Izbor opte metodologije po kojoj e programski proizvod biti razvijen vri se
tokom ustanovljavanja projekta razvoja programskog proizvoda. Ukoliko je izabrana
metodologija ivotnog ciklusa, tada najkasnije do zavretka faze strategije, rukovodei
tim projekta mora da se opredjeli za odgovarajui model primjene metodologije
ivotnog ciklusa i izvri dodatna prilagoavanja izabranog modela potrebama projekta.
Ne postoje formalna pravila na osnovu kojih ovaj izbor treba napraviti, ve se moe
govoriti samo o preporukama. Dosta preporuka za izbor odgovarajueg modela
primjene metodologije ivotnog ciklusa proizilazi iz razmatranja danih u okviru taaka
2.4 i 2.5.
Neki od parametara, koji se mogu navesti i koji utiu na izbor modela primjene
metodologije, su slijedei: koliko je poslovni sistem sloen sa stanovita funkcija koje
se u njemu obavljaju, kakav je stepen ureenosti poslovanja u samom poslovnom
sistemu, da li je opta ekonomska i politika situacija u okruenju poslovnog sistema
stabilna ili ne, koji se ciljevi projekta smatraju prioritetnim i u kojoj mjeri su ciljevi
ambiciozno postavljeni, sa kolikim finansijskim sredstvima za realizaciju projekta se
raspolae i kakva je dinamika obezbjeenja tih sredstava. Ovom navoenju
parametara moe se dodati: kakve informacione tehnologije stoje na raspolaganju za
realizaciju projekta, da li je rukovodei i izvoaki tim projekta iskusan u primjeni
odgovarajuih informacionih tehnologija, da li je veina korisnika budueg
programskog proizvoda iskusna u upotrebi rjeenja vezanih za informacione
tehnologije ili ne, da li su rukovodee strukture iz poslovnog sistema, a dijelom i budui
korisnici, zainteresovani i stimulisani za uvoenje novog programskog proizvoda, da li
su, u cjelini, oteane ili ne mogunosti za obezbjeivanje komunikacija.
57
3. Uvod u projektovanje i definisanje zahtjeva za

informacionim sistemom
3.1. Uvod u projektovanje i izgradnju informacionog sistema
3.1.1. Redoslijed izrade fizikog i logikog modela
Fiziki i logiki model postojeeg IS, a zatim logiki i fiziki model budueg IS,
izrauje se na osnovu poslovnih zahtjeva i zahtjeva krajnjih korisnika. Fiziki model
(ugradni, implementacioni, tehniki) opisuje kako je sistem fiziki i tehniki izgraen, te
ko, gdje i kada neto radi. Logiki model (esencijalni, konceptualni, poslovni) opisuje
ta je sistem, ta radi, ta su podaci (slika 3.1). Operativni (budui fiziki) sistem
prikazuje ta, ko i kada, ali ne i gdje radi, a prema potrebi moe se razmatrati
organizacijski nivo, odnosno razliito znaenje podataka zavisno od podruja unutar
poslovnog sistema i okruenja.
Budui
fiziki IS
Postojei
fiziki IS
Postojei
logiki IS
Korisniki/poslovni
zahtjev
Budui
logiki IS
Budui
organizacijski IS
Slika 3.1. Prikaz redoslijeda izrade fizikog i logikog modela IS.
3.1.2. Modeliranje informacionog sistema

Potrebna je izrada modela koji odgovaraju dijelovima poslovnog sistema. Model je
apstrakcija ili reprezentacija dijela stvarnog svijeta. Ukoliko od ranije ne postoji IS,
potrebno je odrediti "surogat" postojeeg sistema po ugledu na istovjetne sisteme u
58
drugim poslovnim sistemima ili razvoj zapoeti sa izradom logikog modela. Tehnika
oblikovanja dijagramima odvija se na slijedei nain. Izradom modela nastoji se opisati
situacija u kojoj dogaaj iz vanjskog svijeta pokree (okida) process. Proces ima
odreeni uinak na podatke u nekom stanju. Obavljanjem procesa podaci prelaze u
novo stanje (slika 3.2).
Staro stanje
podataka
Dogaaj
Sinhronizacija
(koncept okidaa)
Proces
(naredbe i pravila)
uinak
Struktura
podataka
Novo stanje
podataka
Slika 3.2. Dijagram modeliranja IS [Fertalj & Kalpi, 2005].
3.1.3. Vrste modela informacionog sistema

Model podataka opisuje TA su podaci, odnosno TA opisuju podaci.
Konceptualni model opisuje podatke i veze izmeu podataka. Najei konceptualni
model je model entiteti-veze. Logiki model opisuje strukturu podataka i logikih
datoteka, a najei logiki model je relacioni model podataka.
Model funkcija i procesa opisuje KAKO se prikupljaju, obrauju i distribuiraju
podaci. Model funkcija se oblikuje razlaganjem (dekompozicijom) funkcija, iterativno od
vrha prema dolje (od globalnih funkcija do osnovnih procesa). Model procesa opisuje
obradu podataka posmatranog sistema. Najei model procesa je dijagram toka
podataka.
Model dogaaja opisuje KADA se podaci obrauju, odnosno razmatra uinke
koje dogaaji imaju na procese i podatke, te vri opis stanja. Kao primjer se moe
navesti dijagram promjene stanja.
Model resursa/sredstava opisuje izvrioce, odnosno KO obrauje podatke,
GDJE se podaci nalaze i GDJE se podaci obrauju.
Modeliranje programa podrazumjeva predstavljanje struktura (programskih)
modula IS, npr. strukturnim kartama.
59
3.1.4. Kljune aktivnosti i uesnici

Kljune aktivnosti, u nekim metodama, zajedno se zovu informaciono
inenjerstvo. Kao kljune aktivnosti mogu se uoiti sistemska analiza i sistemski dizajn.
Sistemska analiza (analiza sistema) prouava poslovanje sa ciljem da d preporuke za
poboljanja sistema i specifikacije zahtjeva za rjeavanje. Sistemski dizajn (dizajn
sistema) omoguava specifikaciju ili konstrukciju raunarom podranog rjeenja
identifikovanih poslovnih zahtjeva.
Uesnici (nosioci uloga) u navedenim aktivnostima su:
Korisnik (korisnik usluga, klijent, osoba ili grupa za koju se gradi IS), ta
podrazumjeva korisnika sistema i vlasnika sistema. Korisnik sistema (krajnji korisnik)
neposredno koristi IS pri obavljanju svakodnevnih poslova ili koristi informaciju
dobijenu iz IS. Vlasnik sistema (naruilac, stvarni vlasnik ili predstavnik uprave)
naruuje i plaa razvoj i odravanje sistema, postavlja prioritete i odreuje politiku
njegovog koritenja;
Projektant (dizajner sistema) je tehniki strunjak koji oblikuje sistem tako da
zadovolji zahtjeve korisnika, prevodi poslovne zahtjeve i ogranienja u tehniko
rjeenje, oblikuje datoteke, baze podataka, ulaze, izlaze, ekranske forme, mreu i
programe, integrie rjeenje, a moe biti i graditelj sistema;
Graditelj sistema (programer, projektant, strunjak koji izgrauje sistem)
provjerava njegovu ispravnost te ga isporuuje u primjenu, konstruie komponente
sistema na osnovu specifikacija koje rade dizajneri sistema.
Sistem analitiari razumiju i poslovanje i raunarsku obradu podataka. Njihov
zadatak je da provode sistemsku analizu i dizajn. Povezuju one koji trebaju raunar i
one koji poznaju informacione tehnologije (IT). Formalna definicija [Whitten et. al,
2000] sistem analitiara glasi:
Sistem analitiar pomae prouavanju problema i potreba poslovanja radi
odreivanja kako poslovni sistem i informaciona tehnologija mogu najbolje rijeiti
problem i postii unaprijeenje poslovanja. Plodovi ove aktivnosti su poboljani
poslovni procesi, poboljani informacioni sistemi te nove ili poboljane aplikacije, a
esto sve zajedno.
Sistem analitiar je istraiva, arhitekta i kontrolor, rjeavalac poslovnih problema,
zagovornik promjena, psiholog, trgovac, politiar. Veina sistem analitiara koristi
specifinost pristupa, koja se naziva ivotni ciklus razvoja sistema, odnosno
sistematian i metodian pristup rjeavanju problema sistema.
60
3.2. Definisanje zahtjeva za informacionim sistemom

3.2.1. Kljune aktivnosti
Kljune aktivnosti, koje se mogu izdvojiti u definisanju zahtjeva za informacionim
sistemom, su prikupljanje informacija, prikupljanje podataka i ustanovljavanje injenica,
to e u narednom tekstu biti detaljnije opisano.
3.2.2. Prikupljanje informacija

Jedna od aktivnosti kod definisanja zahtjeva za IS su intervjui sa kljunim
korisnicima i radne sjednice. Ako naruilac zapoljava informatiare svakako ih treba
ukljuiti u analizu. Sueljavanje korisnika i informatiara ubrzava rjeavanje
proturjenih iskaza. Kao zamjena za intervjue koriste se upitnici i ankete, koji su
pogodni i za prikupljanje informacija o resursima. Analiza dokumentacije podrazumjeva
prikupljanje cjelokupne dokumentacije znaajne za poslovanje, radi boljeg utvrivanja
pravila, poslovne politike, ciljeva poslovanja i strukture informacija.
Nuna je ocjena postojeih aplikacija i/ili raunarom podranih podataka, radi
analize podataka, ali i zbog njihove konverzije u novi sistem. Posmatranje, odnosno
neposredni uvid u poslovne procese posmatranjem radnih sredina (nain izrade i
razmjene dokumenata, procesi osnovne djelatnosti), je znaajan vid definisanja
zahtjeva za IS. Postupak analize mora biti prilagoen korisniku. Evidentiranje rezultata
analize poeljno je obaviti CASE alatima.
3.2.3. Postupak intervjuisanja

Intervju mora biti neusiljen i elastian razgovor sa ispitanikom u obliku niza pitanja
i odgovora. Ispitanik se pojavljuje u ulozi pasivnog sagovornika (!?). Sagovornici su
rukovodioci, krajnji korisnici i ostali uesnici iz poslovnog sistema. Standardno
ukljuuje dva sagovornika, ali moe i vie, i to korisnika i ispitivaa. Individualni intervju
je kada uestvuje jedan korisnik, ili uesnici koji rade isti posao, dok je intervjuisanje
grupe kada se razgovara sa vie korisnika iz razliitih podruja.
Informacije se prikupljaju nizom pojedinanih razgovora. (Prve) razgovore treba
voditi prema unaprijed dogovorenom planu i rasporedu, ta treba da obezbjedi
koordinator intervjua. Postupak intervjua je spor i neefikasan, jer se organizacija
razgovora mora obaviti za svaki pojedini razgovor. Nakon zavretka analize i sinteze
dobijenih informacija, neke razgovore (ponekad i itavu seriju) treba ponoviti da bi se
61
upotpunile dobijene informacije ili uskladili proturjeni iskazi. Ukupan broj razgovora ne
moe se unaprijed tano odrediti i treba ga prilagoditi stvarnoj situaciji.
3.2.4. Tehnika intervjuisanja

Priprema za razgovor treba da sadri utvrivanje informacija koje treba saznati,
prouavanje postojee dokumentacije i prethodnih nalaza, odreivanje dokumentacije
koju treba prikupiti i priprema pitanja koja e biti postavljena tokom razgovora.
Priprema pitanja podrazumjeva izradu jezgra tema, to jest standardnih pitanja, i izradu
sveobuhvatnog potsjetnika i izdvajanje prikladnih pitanja.
Mogui plan i obavljanje razgovora moe da se odvija na slijedei nain:
1. Trajanje prvog razgovora je 2 sata (okvirno 1,5 do 2,5 sata);
2. Poetak razgovora, koji sadri predstavljanje uesnika i upoznavanje sa
svrhom razgovora (prikupljanje informacija o );
3. Voenje razgovora, odnosno postavljanje pitanja i zapisivanje odgovora,
prikupljanje dokumentacije, ... ;
4. Zavretak razgovora je priblino 5 do10 minuta prije isteka planiranog
vremena. Prekida se redoslijed postavljanja pitanja, provjerava se da li postoji
neto to je sagovornik htjeo rei a nije bilo pitano, provjerava se da li treba
proiriti krug sagovornika, dogovara se nastavak razgovora (dopunski
razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra
da je razgovor nametnuo nova pitanja;
5. Zahvala na razgovoru.
Preispitivanje i pojanjenje sadraja se sastoji od provjera zapisanih navoda radi
upotpunjavanja biljeki: telefonom, elektronskom potom ili novim sastankom.
Dokumentovanje razgovora sainjavaju:
Samostalno pisanje zapisnika (Ko ne razumije, ne moe zapisivati.). Kada u
razgovoru sudjeluje vie analitiara, odreuje se voditelj razgovora koji je
ujedno i zapisniar, a ostali ulau primjedbe;
Zapisnik treba da sadri: naziv projekta, vrijeme i mjesto odravanja
razgovora, spisak uesnika, sadraj razgovora (tekst zapisnika), popis
prikupljene dokumentacije i ime zapisniara;
Zapisnik mora sadravati ono to je reeno i slijediti tok razgovora;
Zapisnik ne smije nametati zakljuke, jer su oni rezultat analize.
62
Autorizacija (ovjera) zapisnika se vri tako da se zapisnik dostavlja na uvid

sagovorniku, koji potvruje vjerodostojnost zapisnika. Po potrebi sagovornik moe
nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli
da su pogreno protumaeni.
3.2.5. Preporuke za voenje intervjua

Tokom provoenja intervjua treba pitati o svemu to se smatra vanim. Nita nije
samo po sebi razumljivo i svima jasno. Ne pretpostavljati da se unaprijed zna o emu
se radi. Repertoar i vrste pitanja moe biti slijedei:
1. Pitanja zatvorenog tipa: Koliko ... obraujete (u nekom razdoblju)?, Na koji
nain obraujete ... ?;
2. Pitanja otvorenog tipa: to mislite o ... ?, Koji su najvei problemi ... ?;
3. Probna pitanja:
Zato?, Moete li navesti primjer za takvu situaciju?,
Molim detaljnije objanjenje za ... .
Analizom odgovora se razdvajaju injenice od miljenja, utvruje se da li pojedine
injenice odgovaraju drugima, analiziraju injenice koje se ne poklapaju i vri provjera
odgovora razliitih sagovornika na isto pitanje.
Preporuuje se slijedee ponaanje: iskrenost i nepristranost (cilj je nai za
korisnika najprikladnije rjeenje, a ne naturati odreeno programsko rjeenje ili
raunarsku platformu), panja i jezgrovitost tj. brzo misli, jasno govori, izbjegavanje
sugestivnih pitanja, nenametanje zakljuaka i leernost (plus praenje reakcija
sagovornika). Grupno intervjuiranje je potrebno izbjegavati i po potrebi nadoknaditi
radnim sjednicama. Ovu vrstu intervjuisanja iznimno provesti kada se eli utvrditi
zajedniki interes ili protivrjenost.
3.2.6. Upitnici i ankete

Upitnik je, u sutini, pismeni intervju. Sadri pitanja koja se postavljaju tokom
razgovora (okvirno 20 pitanja). Moe se dostaviti korisniku prije ili nakon intervjua.
Nedostaci upitnika su slijedei: ispitanik moe prilagoditi (kontrolisati) svoje odgovore,
teko je procijeniti iskrenost (spontanost) odgovora, a moe i obeshrabriti ispitanika.
Anketa moe da obuhvatiti vie ispitanika. Pitanja su zatvorenog tipa, a odgovori i
obrada odgovora mogu se standardizovati. Pogodna je za popis resursa.
Na osnovu navedenog, moe se zakljuiti da

Pomou intervjua se moe vie nauiti o stavovima,
Tokom intervjua analitiar i ispitanik se nalaze jedan
moe posmatrati nain na koji ispitanik odgovara i
pitanja.
63
je intervjuisanje najelastinije!
osjeajima i motivaciji osoblja.
nasuprot drugom, pa analitiar
po potrebi proiriti ili usmjeriti
3.2.7. Prouavanje dokumenata

Prikupljaju se svi dokumenti do kojih se moe doi. U prvom redu treba prikupiti
dokumente koji su nastali kao rezultat analize procesa, tipine dokumente (pravilnici,
zakoni, obrasci, izvjetaji) i dokumente nastale analizom podataka. Poeljno je da
dokumenti budu reprezentativni, tj. popunjeni na tipian nain (tako se moe ustanoviti
koje informacije se unose i na koji nain). Reprezentativni dokumenti najee ne
ukazuju na izuzetke, to jest podatke koji se rjee biljee, ali ipak trebaju. Stalno
biljeenje nekih podataka ne mora znaiti da su ti podaci stvarno potrebni. Treba
prikupiti vie uzoraka iste vrste dokumenta!
Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko
dokumenata je niska. Praksa moe odudarati od pravilnika i administrativnih obrazaca.
Treba shvatiti zato i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni,
te ta treba promijeniti da bi se popravili (sadraj, lakoa popunjavanja i itanja).
Nuno je modele (podataka), razmatrane analizom, provjeriti kod korisnika.
3.2.8. Evidencija i analiza postojeih aplikacija

Budui da su nedostaci opreme, podrke i podataka najei razlozi za izgradnju
novog IS, potrebno ih je evidentirati i analizirati. Vri se procjena aplikacija i (baza)
podataka u primjeni, i to: koriteni programski jezici i alati, ukljuujui programe za
kancelarijsko poslovanje (npr. Excel), podrane funkcije i nain posluivanja programa,
meusobna povezanost razliitih aplikacija i podataka, postojee platforme (raunari,
operativni sistem, mrea, SUBP), kao i sastav i stepen informatike obuenosti
korisnika.
Analiziraju se nedostaci sistemske opreme i programske podrke. U prvom redu
se analizira nepovezanost aplikacija (tzv. informatika ostrva), loa programska
rjeenja (funkcionalnost, ergonomija), nepouzdanost, integritet, zatita i sigurnost
podataka. Takoe se analizira nepostojanje programske dokumentacije, tehnoloka
zastarjelost (programski jezici i alati, nemogunost rada u viekorisnikom okruenju,
grafiki interfejs).
64
Nedostaci modela podataka mogu biti razliiti. Najei nedostaci su razliitost

modela podataka postojeih aplikacija i nedostaci unutar pojedinih modela. Razliitost
modela podataka postojeih aplikacija se oituje u tome da entiteti iz stvarnog svijeta
nisu jednako zastupljeni u postojeim modelima, isti entitet iz stvarnog svijeta
pojavljuje se pod razliitim nazivima, isti entitet iz stvarnog svijeta opisan je razliitim
atributima, dva ili vie entiteta iz stvarnog svijeta su prikazani razliitim brojem entiteta
u modelu podataka. Nedostaci unutar pojedinih modela su, najee, nedefinisanost
identifikatora (primarnih kljueva), nedefinisanost veza meu podacima, najee kao
posljedica nepostojanja primarnih kljueva, nedefinisanost veza i pored postojanja
primarnih i drugih (stranih) kljueva. Navedene pojave su posljedica razvoja tokom
upotrebe i nedoslijednosti tog razvoja, naglaenog ponavljanje uvedenog prilikom
izrade zahtjevnih ili sloenih programskih rjeenja, kao i ukupne nenormalizovanosti
modela.
3.2.9. Posmatranje poslovnog sistema

Definisanje zahtjeva za IS se moe dopuniti uvidom u poslovne procese, odnosno
posmatranjem radnih sredina. Posmatra se lokacija i kretanje ljudi, tok izvravanja
poslova, fiziki ulazi i izlazi sistema, zaprimanje, izrada i razmjena dokumenata,
procesi osnovne djelatnosti, npr. proizvodnje. Prednost ovakvog pristupa je u tome to
je analitiar u stanju da realno sagleda poslovni proces. Ovaj pristup je efikasan, ako
se dobro provede, i obezbjeuje pouzdanost prikupljenih informacija. Nedostaci
posmatranja poslovnog sistema su neefikasnost, ako se dobro ne provede, znatan
utroak vremena, ometanje i nelagodnost posmatranih osoba, mogunost manipulacije
posmatraa, npr. prikrivanjem uobiajenog krenja radnih procedura.
Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani i
netani. Posmatranje na licu mjesta je najtea metoda za utvrivanje injenica.
3.2.10. Radni sastanci

Radni sastanci (sjednice) se organizuju da analitiari i korisnici zajedniki provode
analizu i oblikovanje. Cilj sjednice je (zajedniko) pronalaenje najboljeg rjeenja. Za to
je potreban poseban prostor i izolacija, moderator, dnevni red i zapisnici (slika 3.3).
Genijalnost grupe se koristi za prikupljanje ideja i definisanje informacionih
potreba, pri emu se korisnici potiu na aktivno i kreativno sudjelovanje. Izvodi se tako
da se od svakog ispitanika iz grupe trai da definie svoj pogled na idealno rjeenje.
Svaki uesnik iznosi sve to mu pada na pamet u vezi sa problemom koji se rjeava.
Od predloenih rjeenja odabira se najbolje prema realnoj izvodljivosti. Postupak je
65
koristan tamo gdje postoje korisnici koji dobro poznaju sistem, ali teko prihvataju nove
ideje.
Slika 3.3. Prostor za radne sjednice [A.Dennis & B. Haley Wixom, Systems Analysis
and Design, John Wiley & Sons, 2000].
Prednosti radnih sjednica su njihova pogodnost za projekte kojima se rjeavaju
problemi vani za cijeli poslovni sistem ili vei dio poslovanja. Njihovim organizovanjem
se izbjegavaju specifini (egzotini) i nejasni zahtjevi, preciznije se ustanovljava doseg
projekta i bolje uoava protivrjenost zahtjeva. Nedostaci radnih sjednica su pasivnost
uesnika, usitnjavanje razgovora i esto udaljavanje od tema. Sjednice treba da traju
vie dana (5 do 10) u nekoliko sedmica. Ovom zahtjevu u praksi je vrlo teko udovoljiti
zbog obaveza uesnika. Otpor sjednici je srazmjeran nivou poloaja konkretnog
uesnika. Otpor je naroito naglaen kada poslovni sistem zapoljava informatiare, jer
se podrazumijeva da je informatizacija iskljuivo njihov posao.
3.2.11. Razvoj prototipa

Razvoj prototipa se koristi kada korisnik ne moe tano da definie svoje
informacione potrebe prije nego to se izgradi informacioni sistem. Razlog tome moe
biti nedostatak postojeeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak
66
teka vizuelizacija budueg sistema. Da bi se olakala vizuelizacija budueg sistema

izgrauje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa
takvim sistemom korisnik otkriva svoje informacione potrebe, te se sistem modifikuje
kako bi se zadovoljile te potrebe. Postupak koritenje sistema i modifikovanje istog
iterativno se ponavlja, a informacione potrebe korisnika otkrivaju koritenjem sistema.
Izrada prototipa pogodna je u onim okruenjima gdje je teko definisati konkretni
model sistema, te u okruenjima gdje se informacione potrebe korisnika mjenjaju ili
razvijaju (prototipski model razvoja IS je obraen u podtaki 2.4.3).
3.2.12. Najei problemi pri prikupljanju informacija

Ponaanja korisnika esto moe da uzrokuje niz problema pri definisanju zahtjeva
za IS. Informatikim argonom su opisana ponaanja koja se mogu oekivati od
korisnika.
1. Taktika kuhinjskog sudopera: korisnik navodi (preko)brojne potrebe, gomilu
nepotrebnih izvjetaja, ekranskih formi, sortiranja, izraunavanja i sl. Ovakav
pristup obino je uzrokovan pomanjkanjem iskustva korisnika, koji ne zna ta
bi mu stvarno moglo zatrebati ili nije u stanju izdvojiti ono ta je bitno;
2. Taktika dimne zavjese: korisnik trai vie mogunosti, a zapravo mu je
potrebna samo jedna ili dvije. Dodatni zahtjevi slue za postizanje bolje
nagodbe sa analitiarom. Ova taktika obino oslikava korisnika sa dobrim
poznavanjem onoga ta eli, a zahtjeve treba reducirati na one realne i
izvodljive;
3. Taktika "Treba mi isto, ali u boljem obliku": korisniku koji koristi ovu taktiku
nedostaje volja ili znanje, a ponekad oboje. anse za uspjeno definisanje
problema su male, jer samo korisnik moe izraziti svoje potrebe i probleme.
Korisnik je sklon preutjeti izuzetke, koji su bitni (nuni!) za uspjenu realizaciju, a
obino izuzeci zahtijevaju i najvie napora tokom ugradnje: "To je naa jedina
procedura (osim kada )". Ne izjednaavati tako se uvijek radi sa tako treba
raditi!
67
4. Analiza sistema
4.1. Uvod u analizu sistema
Analiza sistema (sistemska analiza) je ralanjivanje sistema na njegove
komponente da bi se prouilo kako te komponente rade i meusobno komuniciraju.
Analiza sistema se provodi sa namjerom slijedee sinteze sistema i razvoja aplikacija.
Sinteza sistema je ponovno objedinjavanje komponenti u cjeloviti, poeljno poboljani,
sistem. Bie navedene mogue definicije analize sistema. Analiza sistema je: (1)
razmatranje i planiranje sistema i projekta, (2) prouavanje i analiza postojeeg
poslovnog i informacionog sistema, te (3) definisanje poslovnih zahtjeva i prioriteta
novog ili poboljanog postojeeg sistema [Whitten et. al, 2000].
Svrha, cilj i dubina analize sistema mogu se predstaviti slijedeim aktivnostima:
Automatizacijom poslovnih procesa (Business Process Automation (BPA)),
odnosno poveanjem efikasnosti korisnika analizom problema i uklanjanjem
uzroka;
Poboljanjem poslovnih procesa (Business Process Improvement (BPI)), tj.
poveanjem efikasnosti i djelotvornosti, analizom trajanja i kotanja poslovnih
procesa, te predlaganjem poboljanja (udruivanje procesa, paralelizam
izvedbe);
Reinenjeringom poslovnih procesa (Business Process Reengineering (BPR))
ili preoblikovanjem poslovnih procesa (Business Process Redesign (BPR)), ta
predstavlja radikalni redizajn poslovnih procesa analizom moguih posljedica,
procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih
aktivnosti, analizom trokova - koristi i analizom rizika.
4.2. Aktivnosti analize

4.2.1. Uvod u aktivnosti analize
Aktivnosti analize se mogu sistematizovati u tri nivoa, gdje svaki nivo trai
odgovor na odgovarajua pitanja.
68
1. Detaljna analiza postojeeg sistema, te utvrivanje potreba i zahtjeva: Kako

radi postojei sistem?, Na koji nain korisnici koriste sistem da bi obavili svoj
posao?, Koji su problemi pri koritenju aplikacija?
2. Detaljna specifikacija zahtjeva za IS: Koji su podaci potrebni?, Ko ih treba?,
Kada?, Od koga?, Ko ih stvara?, Koji su izlazni podaci?, Kakav im je oblik?,
Koji su izvori izlaznih podataka?, Na koji nain se podaci prikupljaju i
objedinjuju?
3. Daljnja razrada granica projekta.
Primjeri: ProtokDokumenata, RazmjenaPodataka.
Pozadinska analiza treba da pomogne razumjevanju strukture organizacije, ko u
njoj radi, ko je kome potinjen, kako sarauju razliiti odjeli, itd. Za potrebe pozadinske
analize moe se izraditi shema organizacione strukture iz koje e biti vidljivo koja
osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Za ostale elemente,
takoe, se rade odgovarajui modeli (modeliranje procesa, modeliranje podataka).
4.2.2. Postupci i tehnike analize

Moderna strukturirana analiza je procesno usmjerena tehnika modeliranja
poslovnih zahtjeva za sistem.
Informaciono inenjerstvo je procesno osjetljiva tehnika, usmjerena podacima i
prouavanju poslovnog sistema ili njegovih veih dijelova kao cjeline, a ne projekat po
projekat.
Brzi razvoj aplikacija (Rapid Application Development (RAD)) je razvoj
djelominih verzija aplikacija, koje mogu evoluirati do konanog rjeenja.
Zdrueni razvoj aplikacija (Joint Application Development (JAD)) je analiza
zasnovana na intenzivnim radnim sjednicama na kojima vlasnici, korisnici, analitiari,
dizajneri i projektanti zajedniki definiu i oblikuju sistem.
Objektno usmjerena analiza omoguava: modeliranje uaurivanjem podataka i
procesa u objekte, prouavanje postojeih objekata da bi se vidjelo mogu li se
ponovno iskoristiti ili prilagoditi za nove primjene, kao i definisanje novih ili
modifikovanih objekata koji e skupa sa postojeim objektima graditi novu aplikaciju.
Navedeni postupci se mogu komplementarno primjenjivati i pored uvrijeenog
miljenja da je rije o meusobno iskljuivim metodama!
69
4.2.3. Strukturirana analiza

Moderna strukturirana analiza i Logiki dizajn su esti sinonimi koji su u upotrebi.
Strukturirana analiza omoguava provoenje strukturiranog procesa i dobijanje
rezultatata analize. Sainjavaju je:
Tehnika modeliranja poslovnih zahtjeva za sistem, koja je usmjerena
procesima, ali se razvila tako da obuhvata i podatke. Omoguava strukturiranje
procesa, ulaza, izlaza i skladita podataka potrebnih da bi se odgovorilo na
poslovne dogaaje;
Logiki modeli kojima se prikazuje TA je sistem i TA mora raditi (a ne KAKO
radi). Koriste se dijagrami toka podataka za logiki prikaz poslovnih zahtjeva,
nezavisno od tehnikih rjeenja, ta predstavlja logiki dizajn. Ti modeli
izraavaju sutinu sistema (sinonimi: esencijalni, konceptualni ili poslovni
modeli);
Ukljuivanje odreivanja prioriteta zahtjeva.
Analiza sa ciljem automatizacije poslovnih procesa omoguava razumijevanje
postojeeg sistema, ekstenzivno prikupljanje informacija i zahtjeva, kao i oblikovanje
procesa i podataka. Osim toga, omoguava uoavanje moguih poboljanja (ako nije
uinjeno ranije), analizu problema, odnosno identifikovanje problema, ustanovljavanje
eljenih poboljanja, kao i analizu i traenje uzroka problema i prioritete njihovog
rjeavanja. Razvoj koncepata budueg sistema obuhvata prikupljanje dodatnih
informacija, reviziju i doradu modela.
4.3. Definisanje zahtjeva koje sistem mora posjedovati

4.3.1. Uvod u definisanje zahtjeva
IEEE (Institute of Electrical and Electronics Engineers) standard definie zahtjeve
koje mora posjedovati sistem kao: (1) uslov ili sposobnost koje korisnik treba da ima da
bi rijeio problem ili ostvario cilj, (2) uslov ili sposobnost koju mora posjedovati sistem
ili komponenta sistema da bi zadovoljila ugovor, standard, specifikacije ili neki drugi
ugovoreni document, (3) dokumentovanu reprezentaciju uslova ili mogunosti
definisanih pod (1) ili (2); [IEEE Std 830-1998, IEEE Std 610.12-1990].
Zahtjevi ne sadre detalje dizajna, detalje implementacije ili informacije vezane uz
planiranje projekta. Panja se usmjerava na ono TA se eli izgraditi, a ne ulazi se u
detalje kako i kada to napraviti.
70
Za 40 do 60% greaka u projektu uzrok lei u grekama napravljenim u fazi

postavljanja zahtjeva. Tipina posljedica su "prazna oekivanja", razlika izmeu onog
to oekuje naruilac i onoga ta je izvrilac mislio da treba napraviti. Naknadne
prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70 do 85% pripisivo
pogrenim zahtjevima. Nepotpuno definisani zahtjevi ine nemoguim planiranje
projekta i praenje promjena [Leffingwell, 1997].
4.3.2. Vrste zahtjeva

Zahtjevi mogu biti: poslovni zahtjevi (zato), korisniki zahtjevi (zahtjevi krajnjih
korisnika), funkcionalni zahtjevi (ta) ili nefunkcionalni zahtjevi (kako ili kako dobro).
Poslovni zahtjevi definiu ciljeve organizacije (korisniki zahtjevi na viem
nivou), odnosno daju opis problema koje treba rijeiti (npr. poslovna potreba
"Poboljanje usluge postojeim klijentima i pridobijanje novih") ili sadrani u
dokumentima u kojima se opisuje vizija i opseg projekta (npr. poslovni zahtjev
"Omoguiti Internet prodaju").
Korisniki zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik mora
moi obaviti sluei se aplikacijama ili koji su sadrani u opisima sluajeva koritenja,
tj. opisima scenarija rada.
Funkcionalni zahtjevi (ta) definiu softversku funkcionalnost (oekivano
ponaanje i operacije koje sistem moe izvoditi), koju treba ugraditi u proizvod da bi
omoguio korisnicima obavljanje njihovih zadataka. U ovu grupu zahtjeva spadaju
posebno zanimljive mogunosti programa, odnosno skup logiki povezanih
funkcionalnih zahtjeva koje korisniku omoguavaju ispunjavanje poslovnih zahtjeva.
Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi, pravila i ugovori koje
proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtjevi za performansama,
ogranienja za dizajn i implementaciju, te osobine kvaliteta koje preciziraju opis
proizvoda navodei karakteristike proizvoda u razliitim dimenzijama, a bitne su ili
korisniku ili projektantu.
Potrebno je jo naglasiti da je potrebno odrediti prioritetete pojedinih zahtjeva.
Primjer 1: Zahtjevi vlasnika sistema za studentsku subvencioniranu prehranu
[Fertalj & Kalpi, 2005].
Oekivana novana uteda: Sistem mora biti tako koncipiran da prava na
subvencioniranu prehranu moe koristiti samo student koji ih je stekao i da ih moe
koristiti samo u svrhu prehrane. Sistem mora onemoguiti: koritenje subvencije od
strane osoba koje nemaju na to pravo, zaradu ilegalnih posrednika, koritenje
subvencije za druge svrhe osim prehrane, naplatu usluga koje nisu pruene.
71
U idealnom sluaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima!

Primjer 2: Zahtjevi krajnjih korisnika.
Prehrana kod bilo kojeg izvrioca usluga: Novi sistem mora omoguiti da student
ostvaruje svoje pravo kod bilo kojeg izvrioca usluge subvencionirane prehrane.
Dosadanja praksa je bila da svaki izvrilac usluga izdaje svoje bonove koji se mogu
koristiti samo u odreenim restoranima. Ukinuti plaanje unaprijed: Treba izbjei bilo
kakvo plaanje od strane studenata za potrebe ostvarivanja prava, a naroito
unaprijed. Ukloniti nepotrebne postupke za ostvarivanje prava: Sistem mora biti tako
koncipiran da kad se studentu jednom zavedu prava na matinoj ustanovi nisu
potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod izvrioca usluga.
Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemoguiti zloupotrebu steenih
prava. Lake ostvarivanje ostalih prava iz studentskog standarda, npr. javni prijevoz po
povlatenoj cijeni, pozorita, kina, smjetaj u studentskim domovima, student - servis,
itd.
Primjer 3: Nepotpuni zahtjev.
Zahtjev "Softverski proizvod e ispisati statusnu poruku u redovnim intervalima,
ne manjim od 60 sekundi" namee slijedea pitanja: ta je statusna poruka i pod kojim
uslovima e biti ispisana?, Koliko dugo ostaje vidljiva?, Koji dio proizvoda e ispisati
poruku?, Koliko doslijedni intervali moraju biti?
Zahtjev definisan preciznije i detaljnije: Modul za nadzor e ispisivati statusnu
poruku u za to odreeni dio interfejsa. Poruka e se aurirati svakih 60 s (10 s) nakon
to zapone izvoenje pozadinskog zadatka i bie vidljiva cijelo vrijeme. Ukoliko se
pozadinski zadatak izvodi normalno, modul za nadzor e ispisivati postotak obavljenog
posla. Modul za nadzor e ispisati "Zadatak obavljen" nakon to se zadatak obavi.
Modul e ispisati poruku o greci ukoliko doe do zastoja u izvoenju. Problem je
rastavljen u vie zahtjeva budui da e svaki zahtijevati posebno testiranje. Ukoliko je
vie zahtjeva grupisano u jedan lake je previdjeti neki od njih tokom izrade ili
testiranja.
Primjeuje se da u zahtjevu nije detaljno opisano kako i gdje e se poruka
ispisivati. To e biti odlueno tokom dizajna.
Primjer 4: Neostvariv zahtjev.
Zahtjev "Softverski proizvod e se trenutno prebaciti izmeu ispisivanja i skrivanja
oznaka koji se ne mogu tampati" je neostvariv zahtjev iz slijedeih razloga: Raunari
nita ne mogu napraviti trenutno! Da li programska podrka sama odluuje kad e se
prebaciti iz jednog stanja u drugo ili je to inicirano akcijom korisnika? Na koji dio teksta
e se primijeniti promjena prikaza: da li samo oznaeni tekst, cijeli dokument ili neto
72
tree?. Uoava se i nejednoznanost: da li su "oznake koje se ne mogu tampati"

skrivene oznake, posebne oznake ili kontrolne oznake?
Bolji zahtjev glasi: "Korisnik e posebno dogovorenom akcijom, odabrati da li e
se HTML (Hyper Text Markup Language) oznake u trenutno otvorenom dokumentu
prikazivati ili ne".
Sad je jasno da je rije o HTML oznakama, te da korisnik mora moi da obavi
nekakvu akciju, ali nije tono navedeno kakvu (npr. kombinacija tipki), ta se preputa
dizajnerima.
Primjer 5: Neodreeni zahtjev.
U zahtjevu "Parser e brzo generisati izvjetaj o grekama HTML oznaka, koji
omoguava brzu ispravku greaka kada program koriste poetnici u HTML-u" uoavaju
se slijedee neodreenosti: rije "brzo" je neodreena, nije definisano ta predstavlja
izvjetaj i to ini zahtjev nekompletnim. Postavljaju se i slijedea pitanja: Kako se
ovjerava zahtjev?, Kako pronai nekoga ko se smatra poetnikom u HTML-u i zatim
vidjeti kako brzo e, uz pomo izvjetaja, ispraviti greke?, Kada se generie izvjetaj?
Bolje rjeenje glasi: Nakon to je HTML analizator obradio datoteku, generisae
izvjetaj koji sadri broj linije i tekst pronaenih HTML greaka, te opis svake greke.
Ukoliko nema greaka prilikom analize, nee se generisati izvjetaj.
4.3.3. Odreivanje zahtjeva

Poslovni zahtjevi: Sve to opisuje finansijski, trgovaki ili drugi poslovni prodor
koji korisnici, ili organizacija koja razvija sistem, mogu dobiti je, najvjerovatnije,
poslovni zahtjev.
Sluajevi koritenja ili scenariji: Opte izjave o korisnikim ciljevima ili
poslovnim zadacima, koje korisnici moraju obavljati, najvjerojatnije su sluajevi
koritenja, dok specifini opisi zadataka predstavljaju korisnike scenarije. Specifine
zadatke treba generalisati u opte sluajeve koritenja.
Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo
pojedine osobe ili uloge, pod odreenim uslovima, on moda opisuje poslovno pravilo.
Poslovna pravila su operativni principi poslovnih procesa. Ona nisu funkcionalni
zahtjevi.
Funkcionalni zahtjevi: Izjava koja poinje sa Korisnik mora moi da obavi neku
funkciju, ili Sistem treba moi da demonstrira odreeno ponaanje je najvjerovatnije
funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponaanje sistema i definiu
ta e sistem raditi. Treba svima biti jasno zato sistem mora biti u stanju da obavlja
73
odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili

neefikasne poslovne procese koji ne trebaju biti ukljueni u novi sistem.
Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su
atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne
karakteristike sistema: brzinu, jednostavnost, intuitivnost, robustnost, pouzdanost,
sigurnost i efikasnost treba razmotriti sa korisnicima, da bi se precizno utvrdilo ta oni
misle pod tim dvosmislenim i subjektivnim terminima.
Zahtjevi vanjskih interfejsa: Ova klasa zahtjeva opisuje veze izmeu sistema i
vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da ukljuuje odlomke za ove
zahtjeve, ukljuujui i interfejse, te mehanizme komunikacije za korisnike, hardver i
druge softverske sisteme.
Ogranienja su uslovi koji ograniavanju izbor rjeenja raspoloivih dizajneru ili
programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani.
Neopravdana ogranienja treba pokuati odbaciti jer onemoguavaju postizanje
najboljeg rjeenja. Takoe, mogu umanjiti primjenu komercijalnog softvera i
komponenti u rjeenju. Neka ogranienja mogu pomoi u zadovoljavaju atributa
kvaliteta. Primjer je poboljanje prenosivosti programa koritenjem samo standardnih
naredbi nekog programskog jezika.
Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti,
pretpostavljenih vrijednosti ili kompozicija sloenih struktura podataka. Sve definicije
treba pohraniti u Rjenik podataka, kao glavni orjentir za uesnike na projektu.
Ideje o rjeenju: Ako korisnik opisuje specifian nain interakcije sa sistemom,
kojom bi mogao obaviti neku akciju, npr. Korisnik odabira podatak koji eli iz padajue
liste, on predlae rjeenje, a ne zahtjev. Predloeno rjeenje moe odvui panju od
pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono to je potrebno
obaviti, a ne na nain realizacije. Treba istraiti zato korisnik predlae odreenu
ugradnju, jer to moe pomoi u razumijevanju stvarne potrebe i korisnikovih oekivanja
o nainu kako sistem treba da raditi.
4.3.4. Postavljanje prioriteta zahtjeva

Nuno svojstvo sistema namee pitanje: Da li vlasnik sistema neto stvarno
mora imati? Postoji tendencija da se previe zahtjeva proglasi nunim! Po definiciji,
ako sistem ne ukljuuje nune zahtjeve, taj sistem ne moe ispuniti svoju svrhu. Treba
testirati svaki zahtjev koji se smatra nunim i probati ga rangirati. Ako se zahtjev moe
rangirati onda nije obavezan. Potpuno obavezni zahtjevi se ne mogu rangirati, jer su
nuni za prvu verziju sistema.
74
Poeljno svojstvo sistema su funkcije koje korisnik eli na kraju da ima. Ranije
verzije sistema mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni
zahtjevi mogu i trebaju biti rangirani.
Neobvezna svojstva sistema su proizvoljni zahtjevi, svojstva i mogunosti bez
kojih se moe, iako bi lijepo bilo ih imati. To nisu pravi zahtjevi. Ovi zahtjevi, takoe,
mogu biti rangirani.
4.3.5. Dokumentovanje analize zahtjeva

Kratke definicije zahtjeva glase: (1) izjava o stanju, ogranienjima i potrebama
sistema, (2) narativni dokument namijenjen korisniku, ili ga pie korisnik, a sainjavaju
ga poslovni i korisniki zahtjevi, kao i njihovi prioriteti, uoeni problemi, kljune
pretpostavke i preporuke za njihovo rjeavanje.
Specifikacija zahtjeva, esto nazvana i funkcionalnom specifikacijom, je
strukturirani dokument sa detaljnim opisom oekivanog ponaanja sistema (tabela
4.1). Namijenjen je ugovaraima i izvriocima razvoja. Predstavlja cjeloviti i nezavisan
pogled na sistem. Sainjavaju ga funkcionalni i nefunkcionalni zahtjevi te njihovi
Tabela 4.1.
1. Uvod
1.1 Namjena
1.2 Pregled dokumenata
1.3 Ko treba itati dokumente i
savjeti za itanje dokumenata
1.4 Opseg proizvoda
1.5 Referense
2. Sveobuhvatni pregled
2.1 Kontekst proizvoda
2.2 Funkcije proizvoda
2.3 Kategorije korisnika i svojstva
2.4 Okruenje u kojem se izvodi
proizvod
2.5 Ogranienja dizajna i ugradnje
2.6 Pretpostavke i zavisnosti
3. Zahtjevi za interfejsom
3.1 Korisniki interfejs
3.2 Hardverski interfejs
3.3 Softverski interfejs
3.4 Komunikacioni interfejs
4. Svojstva sistema
4.x Svojstvo X
4.x.1 Opis i prioriteti
4.x.2 Nizovi pobuda/odziv
4.x.3 Funkcionalni zahtjevi
5. Ostali nefunkcionalni zahtjevi
5.1 Zahtjevi za performansama sistema
5.2 Zahtjevi za sigurnou korisnika
5.3 Zahtjevi za sigurnou podataka
5.4 Kvalitet programske podrke
5.5 Poslovna pravila
5.6 Korisnika dokumentacija
6. Ostali zahtjevi
Dodatak A: Rjenik
Dodatak B: Modeli i dijagrami
Dodatak C: Lista nedovrenih/neodreenih
zahtjeva
75
prioriteti, model organizacione strukture (strukturirani dijagrami), opis toka dokumenata

(dijagrami toka), model procesa (dijagrami toka podataka), kao i konceptualni model
podataka (dijagrami entiteti - veze).
4.3.6. Uzroci loeg planiranja zahtjeva

Nedovoljna ukljuenost korisnika: Bez korisnika se ne moe tono znati ta
korisnici ele. Takvi proizvodi su neprihvatljivi.
udni korisniki zahtjevi: Neopravdana promjena miljenja tokom izvedbe
uzrokuje prekoraenje predvienog roka za realizaciju, kao i degradaciju kvaliteta
proizvoda.
Nejasni (dvosmisleni) zahtjevi: Situacija u kojoj italac(i) zahtjeva taj zahtjev
tumai(e) na vie naina. To uzrokuje prepravljanje i gubljenje vremena.
Pretjerano ukraavanje: elja izvoaa da dodaju novu funkcionalnost "koja
treba da se svidi korisnicima" i zahtjev korisnika za dodacima koji dobro izgledaju ali
ne pridonose funkcionalnosti. Izrada takvih dodataka je nepotrebna i predstavlja
gubljenje vremena.
Minimalistike specifikacije: Tendencija postavljanja minimalnih zahtjeva ili
skiciranja koncepata, uz elju da ih izvoai nadopune tokom izvedbe, izaziva
frustracije izvoaa i neispunjena oekivanja korisnika.
Zanemarivanje potreba: Zanemarivanje potreba odreenih (grupa) korisnika
izaziva stvaranje opozicije projektu.
4.3.7. Svojstva dobro postavljenih zahtjeva

Svojstva dobro postavljenih korisnikih zahtjeva su definisana IEEE standardom
[1998]. Ta svojstva su: potpunost (cjelovitost), tanost, ostvarivost (izvodljivost),
nunost, poredak po prioritetima, nedvosmislenost i mogunost provjere.
Dobra specifikacija zahtjeva korisnika mora da sadri slijedea svojstva:
potpunost, konzistentnost, mogunost izmjene i mogunost praenja. Cilj je napisati
dovoljno dobre zahtjeve, na osnovu kojih se moe pristupiti dizajnu i ugradnji pojedinih
komponenata sistema, uz prihvatljiv stepen rizika.
76
Primjer dobro postavljenih korisnikih zahtjeva:

Hemiar ili lan osoblja hemijske laboratorije moe podnijeti zahtjev za jednom ili
vie hemikalija. Zahtjev moe biti udovoljen ili dostavom pakovanja hemikalije koja se
ve nalazila na zalihi hemijske laboratorije ili upuivanjem narudbe za novim
pakovanjem hemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora
imati mogunost pretraivanja kataloga hemikalija vanjskog dobavljaa dok sastavlja
narudbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kada
je ispunjen do trenutka kada je udovoljen ili otkazan. Takoe, mora pratiti istoriju svakog
pakovanja hemikalija od trenutka kada stigne u kompaniju do trenutka kad je potpuno
upotrebljen ili odbaen.
Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine

komponente sistema (procesi, podaci, dogaaji). Mogu se definisati preslikavanja
uoenih imenica i glagola u konkretne komponente analitikog modela. Mogua
preslikavanja su opisana u tabeli 4.2.
Tabela 4.2.
Tip rijei
Primjer
Komponente analitikog modela
Imenica
- Ljudi, organizacije, softverski

sistemi, jedinice podataka ili
postojei objekti
- Skladita podataka (DFD modeliranje

toka podataka)
- Entiteti ili njihovi atributi (ERD dijagram
entiteti - veze)
- Klase ili njihovi atributi (dijagram klasa)
- Akcije, ono to korisnik

moe poduzeti ili dogaaji
koji se mogu dogoditi
- Procesi (DFD)
- Odnosi (ERD)
- Prelazi (iz stanja u stanje) (STD
dijagram prelaza stanja)
- Metode klasa (dijagram klasa)
Glagol
77
5. Modeliranje fukcija i procesa

5.1. Uvod u modeliranje funkcija i procesa
Logiki procesi (koje sainjavaju funkcije, dogaaji i elementarni procesi) su akcije
koji se obavljaju bez obzira na nain ugradnje i raspoloive resurse sistema. Neke
metode poistovjeuju funkcije i procese.
Stvarni problemi su preveliki i presloeni da bi se rijeili odjednom (u komadu),
te je potrebno njihovo strukturno ralanjivanje (razlaganje). Naelo je poznato i glasi
podijeli pa s/vladaj (lat. divide et impera, eng. divide and conquer). Sistem se razlae
i opisuje hijerarhijskim modelima. Modeli sistema se oblikuju iterativnim razlaganjem sa
vrha prema dolje. Razlagati se mogu: funkcije i procesi, organizaciona struktura,
struktura podataka i
struktura programske opreme.
5.1.1. Logiki procesi

Funkcije su skup logiki povezanih trajnih poslovnih aktivnosti i zadataka (npr.
djelatnost, posao). Funkcije se obavljaju stalno (nemaju odreeni poetak i kraj).
Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline.
Primjeri funkcija: Prodaja, proizvodnja, otprema, raunovodstvo.
Funkcija se moe sastojati od desetina pa i stotina diskretnih procesa. Funkcije se
mogu hijerarhijski razloiti do nivoa diskretnih procesa, koji obavljaju odreeni zadatak
kojim odgovaraju na poslovne dogaaje.
Dogaaj je logiki dio posla koji se obavlja kao nedjeljiva cjelina. esto je u
upotrebi i naziv transakcija. Pokree se diskretnim ulazom i zavrava nakon to proces
odgovori odgovarajuim izlazom. Poslovni dogaaj moe se predstaviti jednim
procesom kojim sistem reaguje na taj dogaaj. Logiki dogaaj dalje se razlae do
elementarnih procesa kojima se prikazuje reakcija sistema na taj dogaaj.
Proces (elementarni, primitivni proces) je postupak, nain rada, doslijedna
izmjena stanja. Takoe, proces je diskretna odluka, aktivnost ili zadatak kojim se
obavlja neki posao.
78
Proces se obavlja uvijek na isti nain (za odreeni ulaz se dobija isti izlaz).
Trajanje procesa je konano i odredivo (poznati: poetak, zavretak i ponavljanje). Za
obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska).
Poslovna pravila su instrukcije i logika koji odreuju proceduru obavljanja
procesa. Ugrauju se u raunarski program (npr. preduslovi izlaska na ispit, broj
polaganja ispita, uslovi upisa).
Poslovna politika je skup poslovnih pravila. U veini poslovnih sistema
predstavlja osnovu za donoenje odluka.
5.1.2. Modeliranje funkcija

Funkcionalna dekompozicija (dekompozicija funkcija) se koristi za izradu
opteg modela funkcija (modela poslovnih funkcija) posmatranog sistema u fazi
planiranja, to predstavlja strukturirano planiranje.
Hijerarhija funkcija iterativno se razlae do nivoa procesa, tj. do trenutka kada se
pone opisivati ta se nekom funkcijom obavlja (slika 5.1).
Slika 5.1. Iterativno razlaganje hijerarhija funkcija do nivoa procesa.

Dijagram funkcionalne dekompozicije (Functional Decomposition Diagram
(FDD)) koristi istu notaciju za razlaganje bilo koje hijerarhijske strukture, pa se esto
zove samo Dijagram dekompozicije ili Mapa hijerarhije.
79
Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi.

Funkcije se oznaavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi
glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osuiti dio), spojnice su spojevi
izmeu funkcija i procesa, a vanjski spojevi su spojevi sa dijelovima dijagrama na
drugim stranicama (slika 5.2). Primjer dijagrama dekompozicije za jedan sistem
/podsistem prikazan je na slici 5.3.
Funkcija
Proces
Slika 5.2. Elementi dijagrama dekompozicije.

MARKET
Knjigovodstvo
Nabava
Evidentiranje dobavljaa
Naruivanje
robe
Izrada
narudbi
Knjienje
robe
Prodaja
Evidentiranje kupca
Fakturisanje robe
Prodaja
robe
Izrada
otpremnice
Zaprimanje
robe
Dodavanje
Auriranje
Otprema
robe
Brisanje
Slika 5.3. Primjer dijagrama dekompozicije za jedan sistem/podsistem.
80
Izrada globalnog modela funkcija moe zapoeti izradom hijerarhijske liste

funkcija po pojedinim organizacionim cjelinama.
Primjer:
NABAVA
Evidentiranje dobavljaa
Nabavka robe
- Izrada narudbi
- Zaprimanje robe
UPRAVLJANJE OSOBLJEM
Evidentiranje slube
- Prijem u slubu
- Praenje slube
redovni rad
prekovremeni rad
bolovanje
godinji odmori
- Otputanje iz slube
Obraun plata
Izrada dijagrama dekompozicije odvija se po slijedeem postupku. Polazi se od

korijena dijagrama, kome se dodjeljuje ime sistema. Slijedi razrada u podsisteme i
poslovne funkcije. Daljnja razrada je do nivoa operacionalizacije. Pri izradi dijagrama
dekompozicije potrebno je pridravati se slijedeih pravila: svaki proces je roditelj ili
dijete, roditelj mora imati barem dvoje djece, dok po veini standarda, dijete smije imati
samo jednog roditelja.
Preporuke: Izostaviti procese koji samo premjetaju ili preusmjeravaju podatke, a
pri tome ih ostavljaju nedirnute. Panju usmjeriti na procese koji: neto raunaju (npr.
prosjek ocjena), donose ili potpomau odluke (npr. odreivanje raspoloivosti robe pri
naruivanju), filtriraju ili sumiraju podatke (npr. rauni kojima je istekao rok plaanja),
organizuju podatke u korisne informacije (npr. generisanje izvjetaja), pokreu druge
procese (npr. mijenjaju modalitet rada ureaja) ili rukuju podacima (npr. stvaranje,
itanje, auriranje, brisanje i slino).
Pomou hijerarhijskih dijagrama se moe prikazati funkcionalna dekompozicija
realnog sistema. Takav jedan dijagram, dobijen pomou alata Function Hierarchy
Diagramer (Designer 2000, ORACLE), je prikazan na slici 5.4. Svaka funkcija, koja se
kreira putem navedenog alata istovremeno predstavlja i proces u buduim dijagramima
toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju
sinonime u terminologiji mnogih CASE alata.
81
Slika 5.4. Primjer dijagrama dekompozicije funkcija (procesa).

Pored osnovnih podataka za funkcije, za svaku funkciju se odreuje da li je rije o
elementarnoj funkciji ili ne. Za funkciju se kae da je elementarna ukoliko njeno
zapoinjanje podrazumjeva da e se ona u cjelosti izvriti, ili e efekti njenog
izvravanja u cjelosti biti poniteni. Elementarne funkcije se, u principu, ne moraju
dalje dekomponovati i tada one predstavljaju listove u hijerarhijskoj strukturi funkcija. U
cilju preciznijeg specificiranja, postoji mogunost da se elementarna funkcija dalje
dekomponuje na atomine funkcije, koje u tom sluaju predstavljaju listove u
hijerarhijskoj strukturi funkcija.
5.1.3. Dijagram organizacije

Dijagram organizacije (shema, mapa, karta organizacije) daje prikaz strukture
organizacije hijerarhijom pravougaonika (kuica"). Svaki pravougaonik predstavlja
odreenu ulogu ili odgovornost u organizaciji (slika 5.5.).
Osim dijagramsko orijentisanog alata, za definisanje organizacione strukture
sistema, moe se upotrijebiti alat za neposredni pristup rjeniku podataka, pomou
hijerarhijskog navigatora objekata. U ovu grupu alata spada Repository Object
Navigator (Designer 2000, ORACLE), ija je ekranska forma prikazana na slici 5.6.
82
Dekan
XXX
Sekretarica
XXX
Prodekan za
nastavu
XXX
Stud. sluba
XXX
Sekretar
XXX
Prodekan za
nauni rad
XXX
Finansijska
sluba
Prodekan za
finansije
XXX
Biblioteka
Institut
XXX
Raunarska
tehnika
Informacioni
sistemi
Slika 5.5. Dijagram organizacije.
Slika 5.6.Ekranska forma CASE alata Repository Object Navigator (Designer 2000,
ORACLE).
83
Prozor na lijevoj strani ekranske forme prikazuje hijerarhijski navigator objekata

rjenika. Elementi organizacione strukture se definiu kreiranjem pojava tipa objekta
pod nazivom Business Units, odnosno poslovne (organizacione) cjeline. Navoenjem
oznake neposredno nadreene organizacione cjeline, prilikom unoenja nove
organizacione cjeline, uspostavlja se hijerarhijska struktura organizacionih cjelina
(desna strana ekranske forme).
5.2. Metode strukturiranog modeliranja, analize i dokumentovanja

tehnolokih procesa
5.2.1. Metodologija funkcionalnog modeliranja IDEF0
Za realizaciju programa integrisane kompjuterizacije proizvodnje razraena je
familija metoda IDEF (Integrated Definition Function Modeling), koja je definisana
nizom standarda (IDEF0, IDEF1, IDEF1x, IDEF3, IDEF4, IDEF5 i IDEF9). Ova familija
metoda se uspjeno primjenjuje u najrazliitijim oblastima i pokazala kao efikasno
sredstvo za analizu, projektovanje i predstavljanje (modeliranje) tehnolokih procesa.
Metodologija funkcionalnog modeliranja IDEF0 je zamiljena kao inenjerska disciplina
za razvoj sloenih sistema, koja ukljuuje ureaje i ljude. Predstavlja metodu za
modeliranje tehnolokih procesa i funkcija. Ranije tehnike za ovu namjenu su
Structured Analysis and Design Technique - SADT i SofTech, nastale 1960-ih
godina.
Osnovni pojmovi IDEF0. U osnovi IDEF0 metodologije se nalazi pojam bloka, koji
odraava nekoliko poslovnih funkcija. etiri strane bloka imaju slijedee uloge: lijeva
strana ima ulogu ulaza, desna izlaza, gornja upravljanja i donja mehanizma.
Upravljanje
Ulaz
Poslovna
funkcija
Izlaz
Mehanizam
Slika 5.7. Prikaz bloka poslovna funkcija.
84
Uzajamno dejstvo izmeu funkcija u IDEF0 se predstavlja u obliku duge, koja

odraava tok podataka ili materijala, koji sa izlaza jedne funkcije dolaze na ulaz druge.
U zavisnosti od toga sa koje strane bloka se nalazi, tok dobija naziv ulazni, izlazni ili
upravljaki. Drugim rjeima, poslovne funkcije se mogu prikazati ICOM konceptom
(slika 5.7), koji se sastoji od:
ulaz (I = Input): neto to se troi u procesu (nije obavezan),

upravljanje (C = Control): ogranienje na izvravanje procesa (obavezno),
izlaz (O = Output): rezultat procesa (obavezan),
mehanizam (M = Mechanism): koristi se u procesu, ali se ne troi (nije
obavezan).
Principi modeliranja u IDEF0. U IDEF0 su realizovana tri osnovna principa

modeliranja procesa: princip funkcionalne dekompozicije, princip ogranienja
sloenosti i princip konteksta.
Princip funkcionalne dekompozicije se sastoji u predstavljanju sloene poslovne
funkcije skupom elementarnih funkcija, slika 5.8. Princip ogranienja sloenosti se
sastoji u tome da broj blokova na dijagramu mora biti od 2 do 6. Princip konteksta se
sastoji u tome da modeliranje poslovnog procesa poinje sa crtanjem kontekstnog
dijagrama. Na kontekstnom dijagramu se prikazuje samo jedan blok, odnosno samo
glavna poslovna funkcija sistema koji se modelira. Pri odreivanju glavne poslovne
funkcije, neophodno je imati u vidu cilj modeliranja. Jedan poslovni sistem se moe
opisati na razne naine, u zavisnosti od toga sa kog stanovita se posmatra.
Slika 5.8. Grafiki prikaz funkcionalne dekompozicije.
85
Kontekstni dijagram ima jo jednu ulogu u funkcionalnom modeliranju. On

odreuje granice modeliranja poslovnog sistema, odnosno odreuje uzajamnu vezu
izmeu sistema koji se modelira i njegovog okruenja.
Nakon upoznavanja s osnovnim pojmovima funkcionalnog modeliranja poslovnih
procesa, neminovno se postavlja pitanje kako ovo modeliranje pomae poveanju
efikasnosti i kvaliteta djelatnosti poslovnog sistema.
Postojei modeli KAKO JE. Razmatrani poslovni sistem je obavezno dio nekog
projekta izgradnje ili razvoja korporativnog IS. Izgraeni funkcionalni modeli KAKO JE
omoguavaju jasno utvrivanje koji poslovni procesi se ostvaruju u poslovnom
sistemu, koji se informacioni objekti koriste pri izvravanju poslovnih procesa i
zasebnih operacija. Funkcionalni model KAKO JE je polazna taka za analizu zahtjeva
poslovnog sistema, pojave problema i uskih grla u razradi projekta usavravanja
poslovnih procesa.
Poslovna pravila. Model parcijalnih procesa omoguava uoavanje i tano
odreivanje poslovnih pravila, koja se koriste u radu poslovnog sistema.
Instrukcija
Dokument za
rukovodstvo
Sortirati
dokumente
Neregistrovani
dokumenti
Dokumenti
za direktora
podlijeu
registraciji
Registrovati
dokumente
Registrovani
dokumenti
Prijemno
Slika 5.9. Grafiki prikaz dijela funkcionalnog modela toka dokumenata.

Na slici 5.9 je predstavljen dio funkcionalnog modela toka dokumenata (eng.
DocFlow, rus. kretanje dokumenata u organizaciji od trenutka
nastajanja ili dobijanja do zavretka koritenja ili odailjanja). Pri izvravanju operacije
sortirati dokumente koristi se poslovno pravilo: ne podleu registraciji kopirani
86
dokumenti, telegrami i pisma. Ovo pravilo je definisano u instrukciji o toku podataka.

Funkcionalni model omoguava ne samo identifikaciju postojanja pravila, nego i na
kom radnom mjestu poslovno pravilo se mora primjeniti. U okviru funkcionalnog
modela poslovno pravilo ima slijedei oblik: ukoliko je u prijemno doao dokument
namjenjen rukovodstvu, on podlijee sortiranju, a kao rezultat, na osnovu instrukcije,
se odreuje da li dokument podlijee registraciji ili ne.
Informacioni objekti. Funkcionalni model omoguava identifikaciju svih
informacionih objekata, koje koristi poslovni sistem u svojoj djelatnosti. Za razliku od
nekih informacionih modela (Data Flow Diagrams (DFD), IDEF1x), funkcionalni model
IDEF0 odreuje kako se koriste informacioni objekti u okvirima poslovnih procesa.
Izgraeni modeli KAKO E BITI. Razvoj i implementacija korporativnog IS
dovodi do promjena uslova izvravanja pojedinih operacija, kao i strukture poslovnih
procesa. To zahtjeva promjenu poslovnih pravila, promjena u poslovnom sistemu,
modifikaciju vaeih instrukcija zaposlenih. Funkcionalni model KAKO E BITI
omoguava ve u fazi projektovanja budueg IS predvianje tih promjena. Primjena
funkcionalnog modela KAKO E BITI omoguava, ne samo skraenje roka
implementacije IS, nego i smanjenje mogueg rizika uslijed neprilagoenosti korisnika
informacionim tehnologijama.
Raspodjela resursa. Funkcionalni model omoguava jasnu raspodjelu resursa
izmeu operacija poslovnog procesa, ta doprinosi efikasnosti koritenja resursa. Taj
zadatak je naroito aktuelan pri uvoenju novih poslovnih procesa u poslovnom
sistemu.
Daljnja razrada metodologije funkcionalnog modeliranja IDEF0 je razvoj slijedee
dvije tehnike, i to: tehnike za dokumentovanje tehnolokih procesa (IDEF3) i tehnike za
oblikovanje tokova podataka (DFD), koja prikazuje tok informacija.
5.2.2. Dokumentovanje tehnolokih procesa IDEF3

Metoda IDEF3 predstavlja standard za dokumentovanje tehnolokih procesa, koji
se odvijaju u poslovnim sistemima, i predstavlja alat za vizuelno praenje i modeliranje
njihovih scenarija. Pod scenarijom se podrazumjeva opis redoslijeda promjena
svojstava objekata, u okvirima razmatranog procesa (npr. opis redoslijeda etapa
obrade dijelova u radionici i promjena njihovih svojstava nakon zavretka svake
etape). Izvravanje svakog scenarija prati odgovarajui tok dokumenata, koji je dvojak:
tok dokumenata koji odreuju strukturu i redoslijed procesa (npr. tehnoloke
napomene, opis standarda) i tok dokumenata koji odraavaju hod njegovog izvrenja
(npr. rezultati testova, ekspertiza).
87
Postoje dva tipa dijagrama u standardu IDEF3, koji predstavljaju opise jednog te
istog scenarija tehnolokog procesa iz razliitih uglova posmatranja. Dijagrami prvog
tipa su Dijagrami opisa redoslijeda faza procesa (Process Flow Description Diagrams
(PFDD)), a drugi tip su Dijagrami stanja objekta i njegovi transformacioni procesi
(Object State Transition Network (OSTN)).
Primjer: Potrebno je opisati proces farbanja dijelova u proizvodnoj radionici.
Pomou dijagrama PFDD dokumentuje se redoslijed i opis faza obrade dijela u okviru
razmatranog tehnolokog procesa. Dijagrami OSTN se koriste za ilustraciju
transformacija dijela, koje se javljaju u svakoj fazi obrade. Razmatrani proces se sastoji
od farbanja i faze kontrole kvaliteta, koja odreuje da li je potrebno dio ponovo ofarbati
(u sluaju odstupanja od standarda) ili ga poslati na dalju obradu.
OFARBATI
PONOVO
OFARBATI
DIO
OSUITI
DIO
TESTIRATI
DIO
POSLATI U
SLIJEDEU
RADIONICU
Slika 5.10. Primjer PFDD dijagrama.

Na slici 5.10 je prikazan dijagram PFDD, koji predstavlja grafiku predstavu
scenarija obrade dijela. Pravougaonici na dijagramu PFDD se zovu funkcionalni
elementi ili elementi ponaanja (Unit of Behavior (UOB)) i oznaavaju aktivnosti, fazu
procesa ili primljena rjeenja. Svaki UOB se imenuje glagolskim izrazima oblika infinitiv
+ objekat i jedinstvenim brojem. Dijagrami PFDD slue za vizuelni prikaz scenarija
odvijanja procesa u realnom sistemu. Na dijagramima za veze izmeu funkcija se
koriste slijedei grafiki simboli:
- prethoenje (Precedence), prethodna aktivnost se mora zavriti da bi
slijedea zapoela (crta se slijeva nadesno ili odozgo prema dole),
- tok objekata (Object Flow), izlaz prethodne je ulaz u slijedeu aktivnost,
- relacioni (Relational Link), povezivanje uz korisniki definisani uslov.
Prelazi, veze (J - junction) su slijedee:
& (logiko I)
- svaka povezana aktivnost uvijek se obavlja/zavrava,
X (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnosti,
O (ILI)
- obavlja se jedna ili vie povezanih aktivnosti.
88
Ako je dijagram PFDD tehnoloki proces sa stanovita posmatraa, onda

dijagram OSTN omoguava posmatranje istog procesa sa stanovita objekta, slika
5.11. Stanje objekta, dijela u razmatranom primjeru, i promjena tog stanja su kljuni
pojmovi OSTN dijagrama. Stanje objekta je prikazano krugovima, a promjene stanja
usmjerenim linijama. Svaka linija je povezana sa odgovarajuim funkcionalnim blokom
UOB, a kao rezultat je prikazana promjena stanja objekta.
UOB/ Testirati
sloj boje
UOB/
Ofarbati dio
Rijetka
boja
Novi sloj
boje
Tvrda boja
na dijelu
UOB/
Osuiti dio
UOB/ Testirati
sloj boje
Ispolirati
sloj boje
Slika 5.11. Primjer OSTN dijagrama.

Na slici 5.12 je prikazana ekranska forma, sa izvodom iz jednog dijagrama, CASE
alata Process Modeller (Designer 2000, ORACLE), koji je namjenjen za izradu
dijagrama procesa. Process Modeller je zasnovan na slijedeim konceptima:
organizaciona jedinica, proces (funkcija), depozit, tok, okida (triger) i ciljni rezultat.
Organizacija dijagrama procesa prati funkcionalnu dekompoziciju IS. Za svaki proces u
hijerarhiji dekompozicije se formira jedan dijagram. Prilikom otvaranja novog dijagrama
bira se proces za koji se dijagram crta i taj proces se zove kontekstni proces. Procesi,
koji se na samom dijagramu prikazuju, su prevashodno neposredno podreeni procesi
kontekstnom procesu, ali to moe biti i bilo koji drugi proces iz funkcionalne
dekompozicije. Procesi na dijagramu se, u terminologiji ovog alata, nazivaju koracima
ili aktivnostima.
CASE alat Process Modeller omoguava oblikovanje i prikaz organizacione
strukture poslovnog sistema, pri emu se cjelokupna hijerarhija organizacionih
jedinica, ili neki njen dio, prikazuje na krajnjem lijevom dijelu dijagrama. Svaka
organizaciona jedinica, prikazana na dijagramu, ima svoju oblast nadlenosti u
89
pogledu izvoenja pojedinih aktivnosti. Oblast nadlenosti je na dijagramu prikazana u

obliku horizontalne trake, koja se protee u visini odgovarajue organizacione jedinice.
To znai da je za sve procese u danoj oblasti zaduena nadlena organizaciona
jedinica. Matrica organizacione jedinice/procesi se definie pomou dijagrama
procesa.
Slika 5.12. Dijagram procesa na ekranskoj formi CASE alata Process Modeller
(Designer 2000, ORACLE).
5.3. Modeliranje toka podataka

(Data Flow Diagram (DFD))
Dijagram toka podataka (DTP) je skup sredstava za dokumentovanje fizikog i
logikog modela sistema, omoguava prikaz protoka, strukture i obrade podataka, te
dokumentovanje logike poslovnih pravila i procedura (slika 5.13).
90
Sinonimi za dijagram toka podataka su: transformacioni grafikon, mjehurasti

grafikon, mjehurasti dijagram (Bubble Chart).
Tehnika, koja se koristi za modeliranje toka podataka, se primjenjuje pri razvoju
aplikacija, odakle je i potekla. Ne moe se koristiti za opis programske logike, opis
promjene stanja, izradu upravljakih specifikacija ili dizajn korisnikog interfejsa.
D1
Spremite
podataka
Tok podataka
a
P1
Vanjski
entitet
Tok materijala
Proces
5.13. Uproteni dijagram toka podataka.
5.3.1. Elementi dijagrama toka podataka

Tok podataka (data flow) predstavlja skupove podataka koji se kreu kroz sistem.
Tokovi ulaze u procese (ulazni), koriste se i mijenjaju u toku obavljanja procesa
(ulazno/izlazni) ili nastaju kao rezultat procesa (izlazni). Tokovima se dodjeljuju
jedinstveni nazivi oblika imenica ili pridjev+imenica, npr. Potvrena prijavnica, Izlazni
raun.
Proces predstavlja aktivnost pretvaranja podataka (ulaznog u izlazni tok
podataka). Procesi se imenuju glagolskim izrazima oblika infinitiv+objekat (npr. Prijaviti
ispit) ili glagolskom imenicom (npr. Prodaja, Prijava ispita). Nazivom treba izraziti ta
proces obavlja, to jest treba izbjegavati opte nazive (npr. Obavljanje poslova
nabavke). Opis procesa sadri opis aktivnosti (algoritam) njegovog djelovanja.
Spremite podataka (data store) predstavlja organizovani i trajni skup podataka.
Oznaava mjesto pohrane podataka, npr. dokument, registrator, datoteka, relacija
(tabela) u bazi podataka.
Promjena sadraja spremita (punjenje, auriranje,
pranjenje) i koritenje (itanje) obavlja se procesima. Spremite se oznaava
imenicom (imenicom u mnoini), npr. Prijavnica (Prijavnice).
91
Vanjski entitet (external entity, external agent) je objekat vanjskog svijeta

povezan sa posmatranim sistemom. Odreuje granice posmatranog sistema. Vanjski
entiteti predstavljaju izvorita i odredita podataka, to jest izvore i ponore podataka.
Vanjski entiteti mogu biti osobe, orgazicione jedinice, ustanove, drugi sistemi. Za
oznaavanje entiteta se koriste imenice, npr. Student, Kupac, Dobavlja.
5.3.2. Izrada dijagrama toka podataka

Dekompozicija procesa se odvija na slijedei nain. Polazni dijagram ili dijagram
konteksta hijerarhijski se razlae na poddijagrame do nivoa osnovnih procesa. Proces
na nekom nivou razrauje se dijagramom na niem nivou. Preporuuje se izrada
dijagrama koji sadre izmeu 2 i 9 procesa, a poeljno je slijediti pravilo 72 (slika
5.14)..
Slika 5.14. Primjer dijagrama toka podataka oblikovan pomou alata Dataflow
Diagramer (Designer 2000, ORACLE) .
92
Postupak se zaustavlja kada postane oigledna ugradnja (implementacija)

procesa na najniem nivou.
Preporuke za oznaavanje elemenata kojih se treba pridravati prilikom crtanja
dijagrama su slijedee. Hijerarhijski nivoi nose brojane oznake. Nivo konteksta se
oznaava 0. Nazivi spremita, izvora i odredita se oznaavaju velikim slovima,
slovne oznake, ili slovo+broj. Procesi i tokovi podataka se oznaavaju malim slovima.
Dijagram konteksta prikazuje sistem na najviem nivou hijerarhije prikaza.
Definie okruenje sistema i podruje analize. Prikazuje jedan proces i vanjske
entitete. Zapoinje se procesom koji prikazuje sistem u cjelini, a nakon toga odreuju
vanjski entiteti i njihova povezanost sa sistemom (slika 5.15).
Pregledni dijagram (initial diagram) omoguava uoavanje glavnih tokova
informacija (npr. koriteni dokumenti, potrebni podaci), odreivanje glavnih aktivnosti
sistema i njihovo prikazivanje odgovarajuim procesima.
Osim navedenog, pregledni dijagram omoguava ukljuivanje vanjskih entiteta i
tokova podataka sa dijagrama konteksta, utvrivanje sa korisnikom granica sistema,
kao i utvrivanje procesa i spremita podataka (slika 5.16).
Zahtjev za
identifikaciju
Osoba
P0
Dobavlja
Videoteka
lanska karta
Novi video
Rezultat
upita
Upit
Narudba
Identifikacija
Zahtjev za
rezervaciju
Video
lanska karta
i plaanje
lan
Slika 5.15. Primjer dijagrama konteksta: Videoteka.
93
Primjer: Pregledni dijagram, odreivanje granica sistema.
Rezervisati
video
Slika 5.16. Odreivanje dometa dijagrama toka podataka: Videoteka

U toku razrade procesa na poddijagramu, potrebno je za svaki proces sa
preglednog dijagrama identifikovati podaktivnosti. Na primjer, za proces Upisati novog
lana, podaktivnosti su: zatraiti line podatke, evidentirati novog lana i izraditi
lansku kartu (slika 5.17).
Ponavljati postupak za svaki od procesa na poddijagramu. Uspostaviti nivo detalja
slijedei pravilo 72. Na kraju je potrebno provjeriti potpunost i ispravnost modela.
Model obrazloiti korisniku, a zatim ga po potrebi aurirati. Dubinu i
uravnoteenost modela teko je odrediti. U praksi to moe znaiti doradu dijagrama u
veem broju ponavljanja, ak i kada dijagrame rade iskusni analitiari.
94
Zahtjev za
identifikaciju
Identifikacija
P1.1
Zatraiti
line
podatke
Lini podaci
P1.4
Evidentirati
novog
lana
P1.3
D1 lan
lan
lan
Izraditi
lansku
kartu
lanska karta
Slika 5.17. Odreivanje dubine i uravnoteenosti modela podataka.
5.3.3. Pravila i ogranienja kod izrade DTP

Pravilo balansa (ouvanja) tokova glasi: Koliina tokova koji ulaze u proces i
izlaze iz procesa mora odgovarati koliini tokova podprocesa na niem nivou
hijerarhije.
Nije dozvoljeno variranje tokova nekog nivoa na niim nivoima (npr. tok T na niim
nivoima prikazivati kao T1, T2).
Ogranienja i posebni sluajevi su slijedei. Svi objekti modela moraju biti
povezani. Nepovezanost pojedinih objekata ukazuje na nepotpunost modela, npr.:
postojanje procesa bez ulaza i/ili izlaza (tzv. crne rupe), izlaza za koje ne postoji
dovoljno ulaza (tzv. sive rupe) i postojanje nepovezanih spremita ili vanjskih entiteta.
Ne dozvoljava se neposredna povezanost vanjskih entiteta, spremita, spremita i
vanjskog entiteta. Nije dozvoljeno grananje toka u razliite tokove, spajanje razliitih
tokova, kao i postojanje rekurzivnih procesa.
5.3.4. Preporuke za izradu DTP

Prilikom izrade DTP treba voditi rauna o trivijalnim tokovima podataka,
neposredno povezanim procesima i procesima koji ne obavljaju pretvaranje podataka.
95
Trivijalni tokovi su izlazi iz procesa koji ne ulaze u spremita ili odredita. Obino
imaju posebno znaenje, a mogu se koristiti za prikaz posebnih stanja kao to je
dojava poruke sistema (npr. dojava greke).
Neposredno povezani procesi su kada jedan od procesa eka na zavretak
prethodnog. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok
jednak ulaznom. U tom sluaju treba preimenovati jedan od tokova ili treba obaviti
prespajanje tokova, ta je uinjeno sa tokom podataka b, slika 5.18.
Procesi se mogu odvijati istovremeno.
Slika 5.18.Primjer prespajanja toka podataka.
5.3.5. Notacije koje koriste DTP

Postoje razliite notacije koje se koriste kod izrade DTP. Najee primjenjivane
notacije su:
1. Gane/Sarson (koritena u primjerima),
2. Yourdon/DeMarco,
3. SSADM (koritena na slici 5.14),
koje su navedenim redoslijedom prikazane na slici 5.19.
96
a
P1
Vanjski
entitet
Proces
Ulazni tok
Izlazni tok
Vanjski
entitet
Proces
Ulazni tok
Spremite
podataka
Spremite
podataka
Izlazni tok
Vanjski
entitet
D1
Ulazni tok
Proces
D1
Izlazni tok
Spremite
podataka
Slika 5.19. Notacije koje se koriste kod izrade DTP.

Proirenja modela je izvreno uvoenjem okidaa (trigera), koji prikazuju
uestalost procesa (npr. tri puta dnevno), zatim posebnih simbola za prikaz
ponavljanja procesa, razdvajanje i spajanje tokova (alternativni tokovi), kao i posebnih
simbola za tok resursa, tok dokumenata ili tok upravljanja (npr. razliite linije ili ikone).
5.3.6. Opisivanje podataka

Rjenik podataka (Data Dictionary) je mjesto pohrane definicija elemenata
podataka i struktura podataka. Predstavlja strukturirano spremite meta-podataka, tj.
podataka o podacima. Prvobitno se pojavio kao proirenje dijagrama toka podataka,
za pohranu opisa spremita podataka i tokova podataka. Moe se koristiti kao
alternativna tehnika za prikaz modela podataka.
Standardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inae
koristi za opis sintakse programskih jezika, tabela 5.1.
Tabela 5.1.
=
+
()
{}
[]
|
Struktura s lijeva se sastoji od dijelova s desna (sastavljeno od)

Agregacija elemenata (logiko I)
Opcionalnost elemenata u zagradi (0 ili 1)
Ponavljanje (iteracija) elemenata u zagradi, ni jednom do konani broj puta
Alternativa (selekcija) elemenata u zagradi
Odvajanje alternativnih elemenata u [ ] izrazu
**
@
97
Poetna i zavrna vrijednost raspona definisanog [ ] izrazom

Komentar
Oznaka kljua
Primjer: Opis rauna i stavki rauna koritenjem BNF notacije.

Racun = @BrRac + DatRac + BrKupca
+ { SifArt, NazArt, Cijena, Kol, Vrijednost }
+ (IznosRac)
Moe se napisati i kao:

Racun = @BrRac + DatRac + BrKupca
+ { StavkaRac }
+ ( IznosRac )
StavkaRac = @SifArt, NazArt, Cijena, Kol, Vrijednost
Primjer: Opis podataka moe zapoeti opisom najmanje logike cjeline podataka,
odnosno elementarnih podataka. Nakon toga se opisuju grupe sainjene od
elementarnih podataka, ta definie strukturu podataka. Struktura podataka odreuje
sadraj spremita podataka, kao i tokove podataka (slika 5.20).
Elementarni
podatak
Najmanja logika
cjelina podataka
Struktura
podataka
Grupe sainjene od
elementarnih podataka
Grupe sainjene od
struktura podataka
Tok
podataka
Spremite
podataka
Slika 5.20. Primjer opisivanja podataka.
98
5.4. Elementarni procesi

Mini-specifikacije (funkcionalne primitive) se koriste za opisivanje osnovnih
procesa u dijagramu toka podataka. Mogu poprimiti razliite oblike, ali imaju nekoliko
zajednikih elemenata: naziv i broj procesa, listu podataka koji ulaze u proces (ulazni
tokovi podataka), listu podataka koji izlaze iz procesa (izlazni tokovi podataka), kao i
tijelo opisa procesa.
Opis procesa sadri algoritam zadatka koji se procesom obavlja, koji moe
poprimiti razliite oblike (dizajn programa, odnosno opis programske logike). Na
osnovu ovog algoritma moe se, u zavisnosti od alata, generisati programski kd
(tabele 5.2 i 5.3).
Mini-specifikacije kreira korisnik CASE alata. Budui da se ne kreiraju automatski
na osnovu prethodno unesenih opisa (modela procesa i modela podataka), neosjetljive
su na izmjene dijagrama [Fertalj & Kalpi, 2005].
Primjer 1: Definisanje procesa (1).
Tabela 5.2.
Proces 1:
Opis:
Ulazni tokovi:
Provjera raspoloivosti filma

Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti
Upit (Film)
Rezervacije
Posuivanje
Izlazni tokovi:
Rezultat upita (Raspoloiv | Nije raspoloiv | Ne postoji)
Logika procesa:
izraunaj broj kopija traenog filma u videoteci

ako je broj kopija vei od nule tada
ako je broj kopija vei od (broj posuivanja + broj rezervacija)
rezultat = Raspoloiv
inae
rezultat = Nije raspoloiv
inae
poruka Ne postoji
99
Primjer 2: Definisanje procesa (2).

Tabela 5.3.
Proces 1:
Opis:
Ulazni tokovi:
Izlazni tokovi:
Logika procesa:
Provjera raspoloivosti filma

Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti
Upit (Film)
Rezervacije
Posuivanje
Film nije raspoloiv, Film je raspoloiv, Ne postoji
izraunaj broj kopija traenog filma u videoteci
ako je broj kopija vei od nule tada
ako je broj kopija vei od (broj posuivanja + broj rezervacija)
rezultat = Film je raspoloiv
inae
ako lan eli rezervisati film tada
upii rezervaciju (izlazni tok Film nije raspoloiv)
inae
poruka Ne postoji
5.4.1. Primjena modela procesa

Strateko planiranje sistema predstavlja definisanje arhitekture sistema u okviru
stratekog plana, pri emu se radi model procesa poslovnog sistema (globalni model
procesa). Identifikuju se poslovna podruja i poslovne funkcije, najee u obliku
dijagrama dekompozicije funkcija ili nerazraenog DTP (npr. dijagramom konteksta
odreuju se domaaj i interfejs sistema).
Reinenjerstvo poslovnih procesa je analiza i restrukturiranje poslovnih
procesa radi poboljanja efikasnosti i uklanjanja birokratije, prije primjene
informacijskih tehnologija. Postojei procesi se analiziraju i dokumentuju prikladnim
modelima procesa. Izrauju se dijagrami toka podataka sa fizikalnim primjesama, koje
ukljuuju vremensku dimenziju, protonost podataka i trokove.
Analiza sistema razmatra aplikacione modele procesa, odnosno logike modele
procesa sistema ili aplikacije. Teorijski, mogue je proizvesti DTP povratnim
inenjerstvom postojeih aplikacija, ali e takav dijagram biti preoptereen fizikalnim
primjesama.
Dizajn sistema se bavi fizikim modelima procesa, tj. dodavanjem upravljakih
komponenti i resursa.
Prikupljanje i sreivanje informacija o funkcijama i procesima se moe obaviti
pomou tabela prije, ali i umjesto, izrade dijagrama (tabela 5.4).
100
Tabela 5.4.
Proces
Ulaz (od)
Izlaz (prema)
Vanjski entitet
Spremite
Komentar/Algoritam
Izraditi
narudbu
Podaci o
dobavljau,
Artikli za
naruivanje
...
Zahtjev za
prijem
(osoba)
Ispisana
narudba
(dobavlja)
Dobavlja
Struktura tokova ne
mora u potpunosti
odgovarati strukturi
spremita
...
Rjeenje
zahtjeva
(osoba, ... )
...
Osoba
Narudba,
Dobavlja,
Stavka,
Artikl
...
Osoba,
Tok
slube
...
Prijem u
slubu
Provjeri zahtjev
prema
Pravilniku o
zapoljavanju, pa
napii rjeenje
Dijagram toka podataka (DTP) iz stvarnog projekta prikazan je na slici 5.21.
Slika 5.21. DTP iz stvarnog projekta [Fertalj & Kalpi, 2005].
101
6. Modeliranje podataka
6.1. Osnovni pojmovi modela podataka
6.1.1. Uvod u modeliranje
Modeliranje podataka je tehnika organizovanja i dokumentovanja podataka IS.
Sinonim je modeliranje baze podataka, budui da se podaci najee pohranjuju u BP.
Prema mnogim autorima modeliranje podataka je najvanija tehnika oblikovanja
informacionog sistema. Podaci su resurs koji se dijeli izmeu veeg broja procesa i
zbog toga moraju biti organizirani na nain koji je prilagodljiv poslovnim zahtjevima.
Strukture podataka i njihova svojstva su trajniji i stabilniji od procesa. Modeliranje
podataka se zavrava bre nego modeliranje procesa i modeli podataka se bre
pribliavaju rezultatu nego modeli procesa. Pored toga, modeli podataka su bitno manji
od modela procesa. Modeli podataka postojeeg i budueg sistema meusobno su
sliniji nego modeli procesa postojeeg i budueg sistema, a i lake ih je preoblikovati,
pa se manje posla baca. Omoguavaju dobru komunikaciju sa korisnicima i lake
utvrivanje naziva.
6.1.2. Dijagram entiteti-veze

Dijagram entiteti-veze (Entity-Relationship Diagram (ERD)) se naziva jo i
dijagram objekti-veze, skraeno DOV, (slika 6.1). Postoje razliite notacije ovih
dijagrama, npr. Chen, Martin. Osim osnovnih modela, koriste se i proireni modeli, koji
su i obraeni u ovoj knjizi. Ne postoje jednoznani standardi postupka njihove izrade.
Slika 6.1. Ilustracija dijagrama entiteti-veze.
102
6.1.3. Entiteti
Entitet (entity) je neto to postoji u stvarnom svijetu i posjeduje osobine koje ga
opisuju i po kojima se razlikuje od svoje okoline. Definicije entiteta istaknutih autora su:
(1) stvar koja se moe zasebno identifikovati [Chen, 1976], (2) bilo koji objekat koji se
moe razlikovati i predstaviti u bazi podataka [Date, 1986], (3) logika reprezentacija
podatka [Finkelstein, 1989], (4) bilo ta o emu pohranjujemo informaciju [Martin,
1989].
Entitet moe biti:
osoba, npr. Ivo Ban,

objekat, npr. roman Zloin i kazna,
apstraktni pojam, npr. engleski jezik ili iskustvo (poznavanje jezika),
ustanova (ETF),
poslovni sistem (Hotel Proljee ili Elektroprivreda),
dogaaj (situacija, stanje) - proli, sadanji ili budui, npr. roenje, kolovanje,
zaposlenje, penzionisanje,
povezanost razliitih objekata stvarnog svijeta, npr. srodstvo.
Pojedinane pojave (instance), u zavisnosti o metodi, se grupiu u: skup entiteta

(entity set), tip entiteta (entity type) i klasu entiteta (entity class).
U praksi se moe poistovjetiti pojam entitet sa skupom entiteta, ako se ne
razmatraju konkretni podaci. Oznaava se imenicom (u jednini), npr. Osoba, Fakultet.
Entiteti mogu poprimiti razliite uloge u zavisnosti od konteksta, npr. Osoba je Kupac
i/ili Dobavlja, Student ili Nastavnik.
6.1.4. Atributi i domeni

Atribut predstavlja neko obiljeje, odnosno znaenje entiteta. Sinonimi za atribut
su: svojstvo (property), polje (field). Pojedinane vrijednosti atributa se pohranjuju u
bazu podataka kao elementarni podaci.
Po vrijednostima koje predstavljaju, atributi mogu biti: jednostavni atributi, kod
kojih je vrijednost pojedinani podatak: npr. Prezime, Ime, sloeni (sastavljeni) atributi,
gdje je vrijednost ureena torka ili logika grupa jednostavnih atributa: npr. datum =
(dan, mjesec, godina), vieznani atributi, odnosno atributi koji predstavljaju
ponavljajue grupe podataka, tj. atributi sa vie istovrsnih vrijednosti: npr.
Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon).
103
Obzirom na uskladitenu vrijednosti, atributi mogu biti atributi za uskladitenje i

izvedeni atributi, gdje im se vrijednost moe odrediti na osnovu vrijednosti drugih
atributa: starost = (DananjiDatumDatumRoenja).
Vrijednosti atributa definiu tip podatka (domen) i pretpostavljena ili standardna
vrijednost (default).
Tipovi podataka mogu biti netehniki (logiki) ili tehniki. Netehniki tipovi
podataka su opti tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva (npr.
broj, datum-vrijeme, znakovni niz, tekst, BLOB (Binary Large OBject)), dok su tehniki
tipovi podataka generiki tipovi podataka koji se mogu preslikati u konkretne tipove
(npr. integer, character ili konkretni tipovi char, int, byte (iz sastava SUBP
SQLserver)). Standardna vrijednost atributa je vrijednost koja se zapisuje kada je
korisnik ne specificira. Uopteno reeno, veina atributa treba da ima standardnu
vrijednost.
Domeni su skup moguih vrijednosti koje, nad njima definisani atributi, mogu
poprimiti. Domeni mogu biti jednostavni i sloeni, isto kao i atributi. Nad svakim
domenom se moe definisati po volji mnogo atributa.
Skup vrijednosti (domen) se moe definisati: tipom podatka (npr. integer),
podskupom vrijednosti tipa podatka (npr. formula CC66, interval [10-99]) ili skupom
konstanti (npr. Pol = {M, }).
Ilustracija atributa i domena dana je na slici 6.2.
8746
37528
1164
...
Identifikator
Osobe
(IdOsobe)
8746
37528
1164
765
Ford
Karson
Rock
...
Prezime
(Prezime)
Karson
Ford
Rock
Ford
Melrose place xx
Sunset boulevard 2958
Vancouver avenue 63
Alan
Bob
Kit
Ime
(Ime)
Kit
Alan
Bob
Kit
Adresa
(Adresa)
Melrose place 666

Vancouver avenue 63
Slika 6.2. Ilustracija atributa i domena.
ifra mjesta
(SifMjesta)
...
...
...
...
038
001
282
104
6.1.5. Kljuevi
Klju (key) ili identifikator (Id, @) je atribut ili skup atributa koji (svojim
vrijednostima) jednoznano identifikuju svaki od entiteta u nekom skupu entiteta. Mora
se sastojati od bar jednog atributa (jednostavni klju): npr. OSOBA = @JMBG +
Prezime + Ime; MJESTO = @ifraMjesta + NazivMjesta, a moe se sastojati od vie
atributa (sloeni, sastavljeni, ulanani klju): npr. MJESTO = @ifraDrave
+@ifraMjesta.
Klju mora zadovoljavati uslove jednoznanosti i minimalnosti. Jednoznanost se
definie na slijedei nain: u skupu entiteta ne smiju postojati dvije pojave sa istim
vrijednostima svih kljunih atributa (npr. ne smiju postojati 2 osobe sa
JMBG=2209964100028), dok minimalnost znai da ne postoji podskup atributa kljua
koji je, takoe, jednoznaan (npr. lo primjer: OSOBA = @JMBG + @Prezime + ... ,
dobar primjer: KURS = @OznakaValute + @DatumKursa + ... ).
Osim navedenih uslova, klju mora zadovoljiti i slijedee uslove: odreenost
(postojanje vrijednosti u trenutku stvaranja instance), stabilnost (otpornost na promjene
tokom vremena), raspoloivost (dostupnost svim korisnicima), neutralnost (obzirom na
znaenje vrijednosti kljua).
Identifikator
Osobe
(IdOsobe)
8746
37528
1164
765
Prezime
(Prezime)
Karson
Ford
Rock
Ford
Ime
(Ime)
Kit
Alan
Bob
Kit
ifra mjesta
(SifMjesta)
038
001
282
Adresa
(Adresa)
ifra mjesta
(SifMjesta)
Melrose place 666

Vancouver avenue 63
Potanski broj
(PostBr)
10000
20000
30000
...
...
...
...
038
001
282
Naziv mjesta
(NazMjesta)
Roma
New York
Los Angeles
Slika 6.3. Povezivanje entiteta ili skupova entiteta stranim kljuem.

Entitet moe imati jedan ili vie kljueva. Entitet mora imati barem jedan klju.
Entitet moe imati vie moguih kljueva, tj. kandidata za primarni klju, koji ne moraju
105
biti meusobno disjunktivni, tj. mogu imati atribute presjeka. Jedan od kljueva se
odabira za primarni klju (primary key): npr. Osoba.IdOsobe, Mjesto.SifMjesta. Nakon
odabira primarnog kljua, ostali mogui kljuevi postaju alternativni kljuevi (alternate
key (AK)): npr. Osoba.JMBG, Mjesto.PostBr.
Strani klju (foreign key (FK)) je skup atributa koji se odnosi na klju drugog
skupa entiteta, tj. skup atributa ije se vrijednosti odnose na vrijednosti kljua drugog
entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta).
Strani klju ukazuje na povezanost izmeu entiteta, odnosno skupova entiteta
(slika 6.3.). Moe poprimiti vrijednost primarnog kljua drugog entiteta ili nula-vrijednost
(null value).
Primjer:
Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno
Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referensira entitet Mjesto
sa IdMjesta=038.
Nula-vrijednost oznaava nepoznatu vrijednost atributa ili neodreenu vrijednost
atributa, tj. nadomjeta vrijednost atributa koji se ne koristi. Nula-vrijednost nije 0 (nula)
niti (prazan znakovni niz).
Primjer: Mogue nula-vrijednosti:
Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta

neodreena (nepoznata) vrijednost;
Vozilo (tipa putniki automobil) nepoznatog registarskog broja, nasuptot vozila
(tipa buldoer) koje se ne registruje na isti nain (neprimjenljiva vrijednost).
6.1.6. Veze
Veza (relationship) pokazuje odnos izmeu entiteta. Analogno entitetima,
pojedinana veza uspostavlja se na nivou instanci entiteta, a veze se grupiu u
skupove veza (relationship sets). Kada se ne razmatraju instance, pojam veza
podrazumijeva skup veza. Veza moe izraavati ulogu entiteta koje povezuje, a
imenuje se glagolom ili glagolskom imenicom.
Primjer: Veza i uloge:
Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta),
u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA Osobe).
106
Mjesto
Osoba
Stanuje
Stanovnik
MjestoStan
Slika 6.4. Primjer veze i uloga.

Stepen veze je broj entiteta koji sudjeluju u vezi. Uopteno, moe se povezati bilo
koji broj entiteta (pri emu treba biti oprezan!). Tako veza drugog stepena je binarna
veza, veza treeg stepena je ternarna veza, dok je, uopte, veza n-tog stepena: n-arna
veza.
Posebni sluaj je veza nekog entiteta sa tim istim entitetom. To je veza prvog
stepena: unarna veza (refleksivna, rekurzivna, involucijska). U nekim metodama se
smatra posebnim sluajem binarne veze, tj. posebnom vezom 2. stepena.
Tip, klasifikacija veze (type of relationship) oznaava nain pridruivanja pojava
entiteta u vezi:
jedan-prema-jedan (1:1),
jedan-prema-vie (1:N) - moe postojati vie (paralelnih) veza izmeu dva
entiteta,
vie-prema-vie (M:N).
Kardinalnost veze (donja i gornja granica kardinalnosti) je minimalni i maksimalni
broj pojava jednog entiteta za pojedinanu pojavu sa njim povezanog entiteta. Donja
granica moe biti 0, 1, pozitivni cijeli broj ili znak (npr. M). Kada je donja granica
jednaka nuli postoji djelomino, neobavezno pridruivanje. Ne mora postojati nijedna
instanca sa druge strane veze. Kada je donja granica razliita od nule postoji potpuno,
obavezno pridruivanje. Mora postojati barem neki broj ili openito M instanci sa druge
strane veze. Gornja granica moe biti 1, pozitivni cijeli broj ili znak (npr. N). Moe imati
konkretan broj ili openito N instanci sa druge strane veze.
Veze su dvosmjerne pa se kardinalnost definia za oba smjera veze.
Primjer: Binarna veza 1:N.
Mjesto
1,1
Stanuje
0,N
Osoba
107
Primjer: Binarna veza M:N.

OrgJed
0,M
0,N
Proizvodi
Proizvod
Slika 6.5. Primjeri binarnih veza 1:N i M:N.

Primjer: Ternarna veza.
Zanimanje
1,N
Osoba
1,N
Zaposlen
1,N
OrgJed
Primjer: Unarna veza 1:N i unarna veza M:N.
NadJed
0,1
Pripada
OrgJed
PodJed
Cjelina
0,M
Sastav
Proizvod
Dio
0,N
0,N
Slika 6.6. Primjer ternarne veze i unarnih veza 1:N i M:N.
6.1.7. Specijalizacija/generalizacija
Specijalizacija/generalizacija se zove i "je" veza (is a relationship). Ova veza
opisuje posebne sluajeve u nekom skupu entiteta, to jest odnos nekog entiteta
(nadtip) i njegovih posebnosti (podtip). Podreeni entiteti stvaraju se na osnovu njima
nadreenog entiteta sa kojim dijele zajednike atribute:
108
nadtip (supertype) - sadri zajednike atribute i predstavlja generalizaciju

podreenih entiteta,
podtip (subtype) - sadri samo njemu svojstvene atribute i predstavlja
specijalizaciju nadreenog entiteta.
Primjeri:
1. B je podtip od A ako: B je uvijek A, A je ponekad B;
2. Radnik je uvijek Osoba, Osoba je ponekad Radnik (Saradnik);
3. Igla je uvijek Proizvod, Proizvod je ponekad Igla (Avion).
Specijalizacija moe biti neekskluzivna (npr. Osoba je Radnik ili Saradnik, ali u isto
vrijeme moe biti i Radnik i Saradnik) ili ekskluzivna (Proizvod je Igla ili Avion, ali ne
moe istovremeno biti Igla i Avion).
Osoba
Proizvod
11
0,1
Radnik
NS
0,N
Saradnik
0,1
Igla
ES
0,1
Avion
Slika 6.7. Neekskluzivna i ekskluzivna specijalizacija.
6.1.8. Jaki i slabi entiteti

Jaki entitet je entitet koji postoji (egzistira) samostalno, nezavisan/dominantan
entitet, npr. Mjesto.
Slabi entitet postoji samo ako postoji jaki entitet u vezi, predstavlja
zavisan/podreen entitet. Egzistencijalno slabi entitet je entitet koji ne postoji
samostalno, entitet sa stranim kljuem (npr. Osoba). Identifikaciono slabi entitet je
entitet koji se ne identifikuje samostalno, entitet koji nema vlastiti klju nego se njegov
klju sastoji od kljua jakog entiteta i, prema potrebi, vlastitog atributa (deskriptora),
npr. Radnik, Saradnik, StavkaRacuna. Identifikaciono zavisan entitet je ujedno i
egzistencijalno zavisan. Egzistencijalno zavisan entitet nije ujedno i identifikaciono
zavisan.
109
Primjer: Egzistencijalno slab entitet Osoba.

1,1
Mjesto
0,1
Stanuje
Osoba
Primjer: Identifikaciona veza i identifikacioni slab entitet.

1,1
Racun
1,N
RacStRac
StavkaRacuna
Slika 6.8. Primjeri slabih entiteta.
6.1.9. ERD notacije

Najvie je u upotrebi Chen-ova i Martin-ova notacija dijagrama entitetveze
(ERD), slike 6.9 i 6.10.
1. Chen-ova notacija:
Mjesto
0,1
Zanimanje
Pripada
NadJed
1,1
Stanuj
1,N
0,N
Osoba
1,N
Zaposlen
0,N
PodJed
1,N
OrgJed
Proizvodi
0,M
1,1
0,N
1,1
0,N Cjelina
Raun
1,1
NS
RaStRa
0,1
Radnik
0,N
1,N
Saradnik
StavkaRauna
1,1
OdnosiSeNa
0,1
0,N
Sastav
Proizvod
1,1
Igla
ES
0,M
Dio
0,N
0,1
Avion
Slika 6.9. Primjer dijagrama entitetveze jednog preduzea (prema Chen-u).
110
2. Martin-ova notacija.
Zanimanje
Mjesto
Pripada
Stanuje
Osoba
Zaposlen
OrgJed
Sastav
Proizvod
Raun
Radnik
Saradnik
Stavka
rauna
Igla
Avion
Slika 6.10. Primjer dijagrama entitetveze jednog preduzea (prema Martin-u).
6.1.10. Izrada ERD analizom izjava korisnika

Dijagrama entitetveze (ERD) moe biti izraen na osnovu izjava korisnika. Tekst
izjave korisnika za izradu dijagrama entitetiveze za hemijsku laboratoriju moe da
glasi:
"Hemiar ili lan osoblja hemijske laboratorije moe podnijeti zahtjev za
jednom ili vie hemikalija. Zahtjev moe biti udovoljen ili dostavom pakovanja
hemikalije koja se ve nalazila na zalihi hemijske laboratorije ili upuivanjem
narudbe za novim pakovanjem hemikalije od vanjskog dobavljaa. Osoba koja
upuuje zahtjev mora imati mogunost pretraivanja kataloga hemikalija vanjskog
dobavljaa dok sastavlja narudbu. Sistem mora pratiti status svakog zahtjeva za
hemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan.
Takoe, mora pratiti istorijat svakog pakovanja hemikalija od trenutka kad stigne u
kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen".
Inventar
hemijske
laboratorije
Zahtjev za
hemikalijom
1
1
ispunjava
pohranjuje
111
M
zahtjeva
popisuje
Zahtjeva
M
M
M
M
Pakovanje
hemikalija
sadri
Hemikalija
opisuje
M
1
prati
Istorija
pakovanja
hemikalija
Dobavljaev
katalog
Slika 6.11. Primjer dijagrama entitetiveze za hemijsku laboratoriju

6.2. Razvoj modela podataka

6.2.1. Uvod u razvoj modela podataka
Moe da se razvija jedan od slijedeih modela podataka: globalni model podataka
(enterprise data model), model konteksta podataka (context data model), model
podataka sa definisanim kljuevima (key-based data model), model podataka sa
112
potpuno odreenim atributima (fully attributed data model) i potpuno opisani model
podataka (fully described data model).
Kategorije entiteta, koji ulaze u sastav modela podataka, su slijedee: osnovni
(fundamentalni, jaki entiteti), koji ne spadaju u ostale kategorije (npr. Mjesto),
asocijativni (spojni, vezni), koji proizlaze iz asocijativnih veza (npr. Zaposlenje),
atributivni, koji opisuju ili kategoriziraju druge entitete (npr. Zanimanje, Stanje) i
podtipovi specijalizacije (npr. Radnik, Saradnik, Igla, Avion).
6.2.2. Konceptualni model podataka

Globalni model podataka (npr. model podataka poslovnog sistema) se izrauje u
fazi planiranja. Dobijeni konceptualni model entiteti-veze, koji najee sadri
neodreene veze i nerazraene kategorije podataka, moe da ne sadri pojedine
veze. Definie se mogui domet sistema, kao i ukupne informacione potrebe.
Model konteksta podataka se izrauje na poetku analize. Konceptualni model,
koji sadri samo one entitete koji e biti obuhvaeni tehnikim rjeenjem, predstavlja
aplikativni model podataka. Takav model usklauje doseg bez detalja o entitetima ili
detalja o poslovnim pravilima.
ERD sa entitetima i vezama (esto nespecifinim), bez atributa ili samo sa
osnovnim atributima, sadri: obine veze, tj. veze tipa 1:N, npr. "raun ima vie stavki"
ili veze vieg stepena, npr. zaposlenje osobe u organizacionoj jedinici na radnom
mjestu, odnosno Zaposlen. Preporuka je da se izbjegavaju entiteti koji se odnose na
specifini kontekst ili ulogu.
Za konceptualno modeliranje podataka se koristi tehnika dijagrama entiteti-veze
(ERD). Na slici 6.12 je prikazana ekranska forma, sa izvodom iz jednog dijagrama
ERD, CASE alata Entity Relationship Diagramer (Designer 2000, ORACLE), koji ovu
tehniku podrava.
Koncepti tehnike ERD, koji su neposredno ili posredno povezani ovim alatom, su:
tip entiteta, slabi tip entiteta, tip veze, kardinalnost tipa veze, atribut tipa entiteta,
domen, klju tipa entiteta, veza is a i kategorizacija (koja se ovdje predstavlja
ekskluzivnim tipom veze).
ERD se oblikuju tako to se novi tipovi entiteta i tipovi veza neposredno kreiraju u
okviru izabranog aplikativnog sistema, dok se prethodno kreirani tipovi entiteta i tipovi
veza, po potrebi, preuzimaju iz rjenika podataka, bilo da pripadaju izabranom ili
nekom drugom aplikativnom sistemu. Na ovaj nain se obezbjeuje mehanizam za
oblikovanje jedinstvene konceptualne sheme BP informacionog sistema.
113
Slika 6.12. Ekranska forma, sa izvodom iz jednog dijagrama ERD, CASE alata Entity
Relationship Diagramer (Designer 2000, ORACLE).
Notacija za prikaz ERD-a u Entity Relationship Diagramer-u se razlikuje od
prethodno navedene notacije. Najbitnija razlika je u tome da se tipovi veze ovdje ne
prikazuju simbolima za romb i linijama, ve samo pomou jedne linije koja povezuje
dva tipa entiteta. Ta linija moe biti puna, isprekidana ili djelimino isprekidana i na
sebi imati dodatne oznake u zavisnosti od parametara tipa veze. Pored optih pravila
za tumaenje prikazanog ERD-a, koja se mogu nai u literaturi o BP, potrebno je
naglasiti da simbol:
"#" uz atribut (obiljeje) oznaava da je rije o atributu koje je u sastavu

primarnog kljua tipa entiteta,
"*" uz atribut oznaava da je rije o atributu koji je obavezan za unos, odnosno
korespondira ogranienju Null(N, A) = ,
"o" uz atribut oznaava da je rije o atributu koji nije obavezan za unos,
odnosno korespondira ogranienju Null(N, A) = T,
114
"|" na tipu veze oznaava da je tip entiteta na strani gdje se nalazi simbol "|"
identifikaciono zavisan od tipa entiteta na drugoj strani, to znai da e u
sastav primarnog kljua takvog tipa entiteta ui i svi atributi primarnog kljua
tipa entiteta na drugoj strani posmatranog tipa veze, a
" " na tipu veze oznaava da se pojave tipa entiteta na strani gdje se nalazi
simbol "
" ne mogu "prevezivati" za druge pojave tipa entiteta na drugoj
strani.
6.2.3. Logiki modeli podataka

Model sa definisanim kljuevima entiteta ne sadri neodreene veze. One su
nadomjetene asocijativnim entitetima. Vri se odreivanje kljueva (primarnih,
alternativnih, stranih). Ako se primarni klju (PK) ne moe odrediti, moda se ne radi o
skupu entiteta.
Odreivanje kardinalnosti veza se vri odgovaranjem na pitanja oblika: mora/
moe: ni jedan (0), barem jedan (1), vie (N), odnosno donja/gornja granica
kardinalnosti.
Primjeri:
1. Koliko stavki rauna mora/moe imati raun? odgovor je: 1 (donja granica
kardinalnosti), N (gornja granica kardinalnosti);
2. Koliko se osoba mora/moe nalaziti u mjestu? odgovor je: 0 (donja granica
kardinalnosti), N (gornja granica kardinalnosti).
Definisanje generalizacionih hijerarhija (odreivanje specijalizacija, tj. podtipova
entiteta), npr. Igla i Avion, vri se definisanjem klasifikacionog atributa nadtipa
(diskriminator podtipa), npr. Proizvod.TipProizvoda {Igla, Avion}.
Model sa definisanim atributima entiteta se dobija dodavanjem preostalih
opisnih atributa, odreivanjem podskupova podataka, definisanjem domena, logikih
tipova podataka i standardnih vrijednosti atributa (slika 6.13).
115
Slika 6.13. Primjer modela podataka sa definisanim atributima entiteta i

kljuevima entiteta (konceptualna shema).
6.2.4. Dokumentovanje i konverzija modela entiteti-veze

Potpuno opisani model podataka je ostvaren kada raspolae sa putpunim opisom
atributa, logikih tipova podataka i standardnih vrijednosti. Dodatni opisi su prava
pristupa podacima i trajnost podataka (arhiviranje). Dobijanje potpuno opisanog
modela vremenski je najzahtjevniji zadatak. Uobiajeno se provodi na kraju, ali moe
zapoeti uporedno sa izradom modela zasnovanog na kljuevima ili definisanjem
opisnih atributa.
Dalja konverzija modela se sastoji u prevoenju modela entiteti-veze u relacioni
model podataka. Faza dizajna, odnosno fiziko oblikovanje podataka, se sastoji od
konverzije logikog u fiziki model (izrada sheme baze podataka), kao i od
normalizacije i prilagoavanja uslijed tehnikih ogranienja i performansi.
116
6.2.5. Definisanje koncepata modela podataka

Definisanje entiteta podrazumjeva dodjeljivanje jedinstvenih naziva i izradu opisa
entiteta, odnosno definisanje znaenja i namjene entiteta, poslovnih zahtjeva i
ogranienja. Treba koristiti kratki naziv (kd), koji je esto potreban zbog ogranienja
alata ili programskog jezika. Izbjegavati skraenice zbog mogue pojave akronima.
Atributi kljueva i opisni atributi su vani za razumijevanje sutine modela. Voditi
rauna o tragu zahtjeva, odnosno porijeklu i primjeni entiteta. Potrebno je definisati
ovlatenja nad meta-podacima i odgovornost za podatke.
Definisanje veza se sastoji u odreivanju jedinstvenog naziva, koji se sastoji od
glagola, odnosno glagolske imenice (npr.Roditelj-Dijete). Takoe je potrebno definisati:
znaenje veze (sastavni dio dokumentacije), tip veze (identifikaciona ili
neidentifikaciona veza), modalitet i kardinalnost, kljueve, diskriminator generalizacije
/specijalizacije, kao i pravila za ouvanje integriteta pri unosu i brisanju instanci.
Odreivanje kljueva se sastoji u odreivanju kljua jakog entiteta (identifikacioni
atribut) i kljua identifikaciono slabog entiteta (klju jakog entiteta i vlastiti atribut).
Potrebno je obratiti panju na kljueve sastavljene od vie atributa, kao i na atribute
kljua koji su ujedno kljuevi drugih entiteta. Odrediti mogue zamjenitelje kljueva.
Kod stranih kljueva obratiti panju na moguu migraciju primarnog u strani klju.
Treba ukloniti neodreenosti stranih atributa.
Definisanje atributa podrazumjeva da naziv atributa mora biti jedinstven, sa
izuzetkom stranih kljueva. Treba povesti rauna o znaenju atributa, domenu atributa
i kardinalnosti atributa.
Atributi mogu biti izvedeni atributi (iz razliitih instanci) i izraunati atributi (jedne
instance).
6.3. Logiko modeliranje podataka

6.3.1. Prevoenje modela E-V u relacioni model
Osnovni koncepti koji se javljaju u modelu entiteti veze (EV) su: entiteti,
atributi, kljuevi i veze. U narednom tekstu je predstavljeno parcijalno prevoenje
modela E-V u relacioni model.
Entiteti (skup entiteta) se predstavljaju relacijama (tabelama). Stanovnici Mjesta
XX su Osobe XXX (relacije: Mjesto, Osoba).
117
Atributi mogu imati slijedee kardinalnosti preslikavanja: kardinalnost 0 - opciona

vrijednost (null), kardinalnost 1 - zahtijevana vrijednost (not null) i kardinalnost N vieznani atribut (npr. Osoba.Telefon).
Atribut Prezime entiteta Osoba se predstavlja sa Osoba.Prezime. Izvedeni atribut
je atribut koji se pamti ili se izostavlja, npr. Osoba.Staz, dok je sloeni atribut dobijen
grupisanjem, npr. grupisanjem (dan, mjesec, godina) dobija se atribut Datum (slika
6.14).
Osoba
IdOsobe
Prezime
Ime
Adresa
DatRodj
Staz
Slika 6.14. Atributi skupa entiteta Osoba.

Vieznani atribut je skup odgovarajuih atributa, npr. Osoba.Telefon:
Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon ili prikazano
kao slabi entitet, npr. Osoba.Telefon: Telefon (IdOsobe, VrstaTelefona, BrojTelefona),
slika 6.15.
Osoba
IdOsobe
Prezime
Ime
TelefonNaPoslu
TelefonKodKuce
MobilniTelefon
Adresa
DatRodj
Staz
Osoba
1,1
0,N
Telefon
VrstaTelefona
BrojTelefona
Slika 6.15. Primjeri vieznanih atributa.
Telefon
118
Kljuevi mogu biti primarni, npr. Osoba.IdOsobe, Mjesto.SifMjesta ili alternativni

(AK), koga sainjava indeks nad jedinstvenim vrijednostima (unique index) + oznaka
zahtijevane vrijednosti (not null), npr. Mjesto.PostBr (slika 6.16).
OsobaSKljucem
IdOsobe
Prezime
Ime
Adresa
DatRodj
Staz
Mjesto
SifMjesta
PostBr
<AK>
NazMjesta
Slika 6.16. Primjeri primarnog i alternativnog kljua <AK>.

Veza moe biti binarna veza 1:N sa stranim kljuem. Na slici 6.17 su prikazane
binarne veze egzistencijalno slabog entiteta sa obinim stranim kljuem i to: Stanuje
(Osoba.SifMjesta) <FK1>, Pripada (OrgJed.SifNadJed) <FK2> i RacunOsoba
(Racun.IdOsobe) <FK3>.
Mjesto
SifMjesta
PostBr <AK>
NazMjesta
Osoba
IdOsobe
Prezime
Ime
SifMjesta <FK1>
Adresa
DatRodj
Staz
OrgJed
SifOrgJed
NazOrgJed
SifNadJed <FK2>
Osoba
IdOsobe
Prezime
Ime
SifMjesta <FK1>
Adresa
DatRodj
Staz
Slika 6.17. Primjeri stranog kljua <FK>.
Racun
BrRac
DatRac
IdOsobe <FK3>
IznosRac
119
Identifikaciono slabi entitet naslijeuje klju jakog entiteta. Taj klju moe biti
spojni klju, npr. StavkaRacuna (BrRacuna, SifProizvoda, JedCijena, Kolicina) ili
kompozitni klju, npr. StavkaRacuna (BrRacuna, RbrStRac, SifProizvoda, JedCijena,
Kolicina), slika 6.18.
Racun
BrRac
DatRac
IdOsobe <FK>
IznosRac
StavkaRacuna
BrRacuna <FK1>
SifProizvoda <FK2>
JedCijena
Kolicina
Proizvod
SifProizvoda
NazProizvoda
JedCijena
TipProizvoda
StavkaRacuna
BrRacuna <FK1>
RbrStRac
SifProizvoda <FK2>
JedCijena
Kolicina
Slika 6.18. Primjeri sloenog kljua.

Binarna veza 1,1:0,1 sa stranim kljuem transformie se u identifikaciono slabi
entitet bez deskriptora: npr. Osoba (IdOsobe, Prezime, , Staz), SlikaOsobe
(IdOsobe, Slika).
Po potrebi se moe razmotriti udruivanje entiteta u binarnoj vezi 1,1:1,1 (1,1:0,1)
u jednu relaciju: Osoba (IdOsobe, Prezime, , Staz), Komentar (IdOsobe, TekstKom),
Osoba (IdOsobe, Prezime, , Staz, TekstKom).
OrgJed
0,M
0,N
Proizvodi
Proizvod
Zanimanje
1,N
Osoba
1,N
Zaposlen
DatPoc
1,N
OrgJed
0,M
Sastav
Osoba
IdOsobe
Prezime
SifMjesta <FK>
Adresa
DatRodj
Staz
Sastav
SifProizvod<FK1>
SifDjela <FK2>
BrDjelova
DatZav
Cjelina
Proizvod
Zanimanje
SifZan
NazZan
BrDjelova
Zaposlen
IdOsobe <FK1>
SifOrgJed <FK2>
SifZanim <FK3>
DatPoc
DatZav
KoefPlate
OrgJed
SifOrgJed
NazOrgJed
SifNadJed <FK1>
Proizvod
SifProizvoda
NazProizvoda
JedCjena
TipProizvoda
Proizvodi
SifOrgJed <FK1>
SifProizvod<FK2>
Dio
Slika 6.19. Primjer kljueva asocijativnog entiteta.
120
Nespecifine veze se sastoje od asocijativnog entiteta + n binarnih veza 1:N. Klju

asocijativnog entiteta je unija kljueva entiteta spojenih vezom (slika 6.19).
Primjer: Proizvodi, Zaposlen, Sastav.
Specijalizacija nadtipa u n podtipova (n binarnih veza) u kojoj je nadtip (jaki)
entitet, kome se po potrebi odreuje klasifikacioni atribut, npr. Proizvod.TipProizvoda i
podtip (identifikaciono) slabi entitet, npr. Igla, Avion (slika 6.20).
Proizvod
SifProizvoda
NazProizvoda
JedCijena
TipProizvoda
Proizvod
1,1
0,1
Igla
ES
0,1
Avion
Igla
SifProizvoda <FK>
Duzina
Promjer
Avion
SifProizvoda <FK>
BrSjedista
DoletKM
Slika 6.20. Primjer specijalizacije nadtipa u n podtipova.
6.3.2. Implementaciono projektovanje sheme BP pomou CASE alata

Implementaciono projektovanje sheme baze podataka zapoinje prevoenjem
ERD konceptualne sheme BP u relacioni model. Nakon postupka prevoenja
konceptualne sheme BP, sa slike 6.13, u relacioni model podataka i izvrene
normalizacije, dobija se implementaciona shema BP, slika 6.21. Svaki pravougaonik
na shemi predstavlja jednu relaciju (tabelu) BP, dok linije predstavljaju puteve
prostiranja primarnog kljua, odnosno ogranienja stranog kljua.
Za ovo prevoenje se moe koristiti odgovarajui CASE alat, npr. Database
Design Transformer (Designer 2000, ORACLE). Ovaj alat na osnovu konceptualne
sheme BP, opisane u rjeniku podataka, generie prvu verziju relacione sheme BP, iji
opis e se, takoe, nalaziti u rjeniku. Tako integrisana relaciona shema se dorauje
odgovarajuim editorom, npr. Design Editor (Designer 2000, ORACLE). Izgled
korisnikog interfejsa za Design Editor/Server Model, zajedno sa izvodom iz jednog
dijagrama relacione sheme, je prikazan na slici 6.22.
121
Slika 6.21. Dijagram implementacione sheme aplikacije Komercijalni poslovi.

Na osnovu implementacione sheme BP se automatski generie ORACLE/SQL (ili
ANSI/SQL) opis sheme BP, koji treba implementirati na odgovarajuem serveru BP.
Implementaciona shema slui, takoe, kao osnova za modeliranje programske
specifikacije modula i samo generisanje programskih modula, ta je detaljnije opisano
u taki 10.7.
Programska specifikacija modula za interaktivni rad sa bazom podataka, kreiranje
izvjetaja, grafikonski prikaz podataka ili bibliotekog modula, se mogu oblikovati
odgovarajuim CASE alatom, npr. Design Editor/Modules (Designer 2000, ORACLE),
slika 6.23. Pomou istog alata se formira struktura ekranskih formi aplikacije i
obezbjeuje meusobno povezivanje programskih modula, sa mogunou prenosa
podataka izmeu modula.
122
Slika 6.22. Ekranska forma CASE alata Design Editor/Server Model

Slika 6.23. Ekranska forma CASE alata Design Editor/Modules

123
7. Modeliranje dogaaja
7.1. Modeliranje procesa voeno dogaajima
Dogaaj je zgoda ili zbivanje u sistemu koja vodi ili pokree procese sistema.
Sm dogaaj nije proces, nego okida procesa koji se njime pokree.
Primjer: Kupac dostavom narudbe pokree proces provjere da li se radi o
narudbi postojeeg ili novog kupca, proces stvaranja podataka o narudbi i stavkama
narudbe, provjeru prethodnih zaduenja kupca, provjeru stanja skladita, itd.
Dogaaj moe biti vanjski, vremenski i unutranji.
Vanjski dogaaji se pokreu od strane vanjskih entiteta, koji zahtijevaju
informaciju ili auriranje podataka (ulazni tokovi podataka). Imenuje se tako da naziv
sadri naziv vanjskog entiteta, npr. zahtjev za upis studenta ili zaprimanje narudbe
kupca.
Vremenski dogaaji su vremenski uslovljeni, npr. rok, uestalost (ulazni
upravljaki tokovi). Imenuju se tako da naziv sadri vremensku oznaku, npr. istek roka
plaanja rauna, mjeseni obraun plata, zakljuivanje ispitnog roka i slino.
Unutranji dogaaji su dogaaji stanja, odnosno posljedica prelaza sistema iz
jednog stanja u drugo na takav nain da to zahtjeva obradu (ulazni upravljaki tokovi),
npr. isporuka robe sa skladita zahtijeva naruivanje nove robe.
Raspodjela dogaaja vezanih za projektovanje IS:
1. Izrada dijagrama konteksta sistema, postavljanje poetnog dometa projekta;
2. Izrada dijagrama funkcionalne dekompozicije, podjela sistema u logike
podsisteme i/ili funkcije;
3. Izrada popisa dogaaja i odziva, utvrivanje poslovnih dogaaja na koje
sistem mora odgovoriti. Elementi popisa su dogaaj, ulaz i izlaz;
4. Izrada dijagrama dekompozicije dogaaja, dodavanje procesa za rukovanje
dogaajima. Dodaje se po jedan proces za svaki utvreni dogaaj;
5. Izrada dijagrama dogaaja, odnosno razrada procesa za obradu dogaaja.
Izrauje se po jedan dijagram za svaki dogaaj;
6. Izrada dijagrama sistema, odnosno udruivanjem dijagrama dogaaja;
7. Izrada primitivnih dijagrama. Razrada dijagramom toka podataka koji sadri
osnovne procese, spremita i tokove za svaki pojedini dogaaj.
Opti prikaz dijagrama sistema izraen modeliranjem procesa voenim
dogaajima prikazan je na slici 7.1.
124
Sistem
Sistem
Funkcija 1
Dogaaj 1
Dogaaj 1
Dogaaj 2
Funkcija n
Funkcija 2
Dogaaj 3
Dogaaj 4
Dogaaj 5
Dogaaj n-2
Dogaaj 5
Dogaaj n-1
Dogaaj n
Dogaaj n
Slika 7.1. Primjer modeliranja procesa voeno dogaajima.
7.2. Matrica entiteti/dogaaji

(Entity/Event Matrix)
Matrica entiteti/dogaaji omoguava pogled na sistem usmjeren dogaajima.
Matrica sadri dogaaje (redovi) i entitete (stupci). Elementi koji prikazuju uinak
dogaaja na entitete su:
stvaranje C (reate),
itanje - R (read) (u nekim metodama se ne biljei),
auriranje - U (update) ili M (odify),
brisanje - D (elete).
Zavretak je kada se ostvari da svaki dogaaj ima uinak na barem jedan entitet,
a svaki entitet mora imati dogaaj koji ga stvara i brie.
125
Pojednostavnjeni primjer matrice dogaaj/entitet za rezervaciju sobe u hotelu

Proljee, prikazan je na slici 7.2.
Slika 7.2. Primjer matrice dogaaj/entitet.
7.2.1. Generisanje matrica CASE alatima

Generisanje matrica CASE alatima bie ilustrovano kreiranjem matrica
Funkcije/Tipovi entiteta i Funkcije/ Atributi pomou Matrix Diagrammer-a iz sastava
Designer-a 2000, ORACLE. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se
projektuju tako da se u njima pojavljuju sve elementarne funkcije.
Slika 7.3. Matrica Elementarne funkcije/Tipovi entiteta.
126
Na slici 7.3 je prikazana matrica Elementarne funkcije/Tipovi entiteta za aplikaciju

Komercijalni poslovi, a na slikama 7.4 do 7.6 su prikazane matrice Elementarne
funkcije/Atributi, za tipove entiteta KUPAC, SKLADISTE i ROBA za istu aplikaciju.
Naini upotrebe tipa entiteta u zavisnosti od funkcije, kod matrice Funkcije/Tipovi
entiteta, mogu biti:
Create (C), sa znaenjem da je zadatak funkcije formiranje nove pojave

posmatranog tipa entiteta,
Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje podataka o
postojeim pojavama tipa entiteta,
Update (U), sa znaenjem da je zadatak funkcije modifikacija podataka o
postojeim pojavama tipa entiteta,
Delete (D), sa znaenjem da je zadatak funkcije brisanje pojave tipa entiteta,
Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima
arhivira pojave tipa entiteta, i
Other (O), sa znaenjem da funkcija ima zadatke koji prethodnim nainima
upotrebe nisu pokriveni.
Slike 7.4. Matrica Elementarne funkcije/Atributi za tip entiteta KUPAC.
127
Slike 7.5. Matrica Elementarne funkcije/Atributi za tip entiteta SKLADISTE.
Slike 7.6. Matrice Elementarne funkcije/Atributi za tip entiteta ROBA.

Naini upotrebe atributa tipova entiteta u zavisnosti od funkcije, kod matrice
Funkcije /Atributi, mogu biti:
Insert (I), sa znaenjem da je zadatak funkcije da prvi put zadaje vrijednost

atributa tipa entiteta,
Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje postojee
vrijednost atributa tipa entiteta,
128
Update (U),sa znaenjem da je zadatak funkcije modifikovanje prethodno

zadane vrijednosti atributa tipa entiteta,
Nullify (N), sa znaenjem da je zadatak funkcije omoguavanje zadavanja nula
vrijednosti za atribut tipa entiteta, koji prethodno nije imao nula vrijednost,
Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima
arhivira vrijednosti atributa tipa entiteta, i
Other (O), sa znaenjem da funkcija ima, u odnosu na vrijednosti atributa tipa
entiteta, zadatke koji prethodnim nainima upotrebe nisu pokriveni.
7.3. Model istorije ivota entiteta

(Entity Life History)
Istorijat ivota entiteta je pogled na sistem usmjeren uincima dogaaja koji
uzrokuju promjene stanja. Opisuje vremenski zavisno ponaanje (jednog) entiteta,
odnosno prati promjene ponaanja entiteta koji prolazi kroz sistem. Dijagram
podudarnosti uinka (Effect Correspondence Diagram ECD), za opti sluaj je
prikazan na slici 7.7, a za rezervaciju sobe u hotelu Proljee na slici 7.8.
entitet, blok
redoslijedni
redoslijedni
dogaaj
dogaaj
(sekvenca)
(sekvenca)
alternativni
dogaaj
(selekcija)
operacije
ponovljeni
dogaaj
(iteracija)
n
Slika 7.7. Dijagram podudarnosti uinka za opti sluaj.
129
rezervacija
sobe
rezervacija,
nenajavljen
dolazak
najavljeni
dolazak
opoziv
rezervacije
ili nedolazak
potvrda
rezervacije
3
stvaranje
troka
plaanje
usluga
7
3 5
privremena
rezervacija
1
dolazak
gosta
arhiviranje
rezervacije
opoziv
rezervacije
nedolazak
gosta
poveanje
troka
1. Kreirati rezervaciju
2. Zauzeti sobu
3. Aurirati status rezervacije
4. Kreirati zaduenje
5. Ponititi zaduenje
6. Osloboditi sobu
7. Obrisati podatke o rezervaciji
Slika 7.8. Dijagram podudarnosti uinka za rezervaciju sobe u hotelu Proljee.
7.4. Dijagram prelaza stanja

(State Transition Diagram (STD))
Dijagram prelaza stanja se zasniva na ideji maine sa konanim brojem stanja,
hipotetikom mehanizmu koji u nekom trenutku moe biti u jednom od konano mnogo
diskretnih stanja. Predstavljaju grafiki prikaz promjena stanja, tj vremenski zavisnog
ponaanja sistema.
Elementi prikaza su: stanje, kumulativni rezultat ponaanja nekog objekta
(pravougaonik, krug ili elipsa), prelaz, promjena stanja uzrokovana nekim dogaajem
(usmjerena linija od jednog stanja prema drugom) i dogaaj, uslov promjene stanja i
akcija koja se obavlja (opis linije prelaza oblika dogaaj/akcija).
Dijagram prelaza stanja najee opisuje vremenski zavisno ponaanje itavog
sistema. Manji sistemi se mogu prikazati jednim dijagramom, dok vei sistemi se
razlau slino dijagramima toka podataka, pri emu stanje na nekom nivou postaje
poetno stanje dijagrama na niom nivou.
Primjenjuju se kod razvoja sistema za rad u stvarnom vremenu (real-time system),
jezike analize (parsing) i dizajna korisnikog interfejsa. Dijagrami prelaza stanja
sistema za rad u stvarnom vremenu se razlikuju po tome to sadre posebno stanje
130
"besposlen". Na slici 7.9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljee
ili Bankomata banke Montenegro, na kome su naglaena stanja ekanje.
prazni hod
(idle)
ispravna kartica/
Izaberite
kartica izvaena/
Umetnite
neispravna kartica/
Neispravna
ekanje na
vaenje kartice
izabran Kraj/
Hvala, dovienja
ekanje na
izbor
obavljen odabir/
Pokupite
izvaeno/
Jo neto?
natoeno
(izbrojano)
Slika 7.9. Dijagram prelaza stanja Sokomata hotela Proljee ili
Bankomata banke Montenegro.
7.5. Mape dijaloga

Korisniki interfejs u mnogim aplikacijama se moe promatrati kao konani
automat. Jedan element interfejsa (odabira, radna povrina, komandna linija ili dijalog
prozor) moe biti aktivan u odreenom trenutku. Korisnik moe doi do ogranienog
broja drugih elemenata u zavisnosti o akcijama koje preduzima. Broj putanji kojima
korisnik moe mijenjati dijaloge je obino vrlo velik, ali je konaan, i mogunosti su,
najee, poznate.
Mape dijaloga prikazuju sistem na visokom nivou apstrakcije. Prikazuju elemente
dijaloga u sistemu i mogunost navigacije izmeu njih, ali nita ne govore o dizajnu
ekranske forme. Korisnici i razvojni tim mogu zajedniki razmatrati dijalog mape kako
bi postigli zajedniki stav o tome kakva treba biti korisnikova interakcija sa sistemom
kako bi se izvrio odreeni zadatak.
131
Dijalog mape su, takoe, korisne kod modeliranja vizuelne arhitekture web
sjedita, pa se ponekad tako i nazivaju (eng. site maps). Navigacioni linkovi u sjeditu
pojavljuju se kao tranzicije na dijalog mapi. Koristi se notacija dijagrama prijelaza
stanja. Uslov koji pokree korisniku navigaciju prikazan je kao tekst na strelicama.
Postoji nekoliko vrsta pokretakih uslova: korisnika akcija, kao to je pritisak tastera ili
klik na link ili dugme dijalog prozora, vrijednost podataka, kao to je pogrean unos koji
pokree pojavljivanje poruke o greci, sistemski uslov, kao to je signal da je pisa
ostao bez papira i kombinacija navedenih, kao to je kucanje opcije iz ekranske forme i
pritisak na taster Enter.
Radi pojednostavnjenja mogu se izostaviti neke opte funkcije, npr. pritiskanje
tastera F1 da bi se dobila pomo ili standardni navigacijski linkovi koji se pojavljuju na
svakoj stranici.
Dijalog mape mogu prikazati alternativne putove kao grane koje odstupaju od
uobiajenog puta, npr. uobiajeni put bi bio naruiti hemikaliju od vanjskog dobavljaa,
a alternativno se hemikalija moe dobiti iz zaliha hemijske laboratorije. Prilikom analize
zahtjeva, dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom
nivou. Konkretna ugradnja moe biti drugaija.
Primjer: Korisnik inicira model koritenja odabirom opcije "zatrai hemikaliju" iz
glavnog odabiraa. Polazna taka za ovaj model koritenja je popis traenih hemikalija
koji se naziva "Trenutna lista zahtjeva".
132
8. Inenjerski pristup izgradnji IS

8.1. Uvod
Razlog za uvoenje posebne discipline u raunarstvu sa nazivom softversko
inenjerstvo je prvi uzrok pojave softverska krize, odnosno projektovanje IS bez
primjene odgovarajue metodologije. Pojam softverskog inenjerstva se javlja
poetkom 70-ih godina, prije pojave pojma CASE proizvoda. Ideja softverskog
inenjerstva je bila uvoenje metodolokog, inenjerskog pristupa pri razvoju
programskih proizvoda sa ciljem da se u zadanim vremenskim rokovima, preciznom
primjenom odgovarajuih tehnika, doe kako do dovoljno kvalitetnog projekta
programskog proizvoda, tako i do dovoljno kvalitetnog samog programskog proizvoda.
Okosnicu takvog koncepta predstavljaju metodologija ivotnog ciklusa i strukturirani
pristup razvoju programskog proizvoda.
Metodologija ivotnog ciklusa polazi od injenice da ivotni ciklus svakog
programskog proizvoda, odnosno ivotni vijek, prolazi kroz iste faze. To znai da i
razvoj programskog proizvoda treba da prati faznu logiku ivotnog ciklusa. Faze
ivotnog ciklusa programskog proizvoda su: strategija (strateko planiranje razvoja
programskog proizvoda), snimanje i analiza (detaljna analiza ponaanja realnog
sistema, korisnikih zahtjeva i konceptualno projektovanje programskog proizvoda),
projektovanje (oblikovanje izvoakog implementacionog projekta programskog
proizvoda), programiranje (realizacija programskog proizvoda), uvoenje u upotrebu i
eksploatacija sa odravanjem.
Bitno je da sve nabrojane faze prati aktivnost izrade odgovarajue projektne,
odnosno izvoake dokumentacije, dok se u fazi programiranja izrauju i uputstva za
upotrebu aplikacija, koja predstavljaju sastavni dio programskog proizvoda.
Strukturirani pristup se primjenjuje u okviru faza snimanja, analize,
projektovanja i programiranja programskog proizvoda. Predstavlja optu tehniku koja
se zasniva na slijedeim principima: postepeno dekomponovanje sloenog sistema na
podsisteme manje sloenosti, nezavisnu izgradnju podsistema, integraciju nezavisno
izgraenih komponenti u jedinstvenu cjelinu (programski proizvod, informacioni sistem)
i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.
133
8.2. Programsko inenjerstvo

(Software Engineering)
Programski proizvodi (software) se sastoji od: programske podrke, dijela
raunarskog sistema koji nema fizikih dimenzija, svih vrsta programa i programskih
jezika, preporuka, itd.
Raunarski programi, podaci i dokumentacija imaju slijedea svojstva: sloenost,
podlonost grekama, ne troe se, teko se mjere, stare, dugo se koriste i lako se
kopiraju (zajedno sa grekama).
Raunarska aplikacija je namjenski program, primjenjeni programski proizvod
(oprema), odnosno raunarom podrano rjeenje jednog ili vie poslovnih problema ili
potreba. Informacioni sistem uobiajeno sadri jednu ili vie raunarskih aplikacija.
Informaciona tehnologija (IT) je bilo koji oblik tehnologije, tj. oprema ili tehnika,
koju ljudi koriste za upravljanje informacijama (obavjetenjima). U dananje vrijeme
obuhvata raunarsku tehnologiju (hardver i softver) i telekomunikacionu tehnologiju
(mree za prenos podataka, slika i zvuka).
Programsko inenjerstvo (softverski inenjering) ima vie definicija. Bie
navedene neke od njih:
1. Programsko inenjerstvo je inenjerska disciplina koja obuhvata sve aspekte
izrade programske opreme [Sommerville, 2000];
2. Programsko inenjerstvo je inenjerska disciplina koja se bavi praktinim
problemima razvoja velikih programskih sistema [Sommerville, 1992];
3. Programsko inenjerstvo ... ima za cilj ekonomian razvoj visoko- kvalitetne
programske opreme [Pagel & Six, 1994].
Podruje programskog inenjerstva su poslovi kojima se oblikuje i razvija
programska oprema, kao i sistemska primjena prikladnih alata i tehnika na itav proces
razvoja programske opreme. Sastoji se od analiziranja i blieg opisivanja (specifikacije)
postupaka koje treba programirati, izrade programa, tehnika testiranja (provjere
valjanosti), pisanja dokumentacije, probnih izvedbi programa, analize vremenskog
izvoenja, itd.
Razvoj postupaka (metoda) programskog inenjerstva se moe hronoloki
prikazati:
godina 1968: Prva NATO konferencija o programskom inenjerstvu,
posveena problemima razvoja programske podrke (softverska kriza),
kraj '60-ih, rane 70-te: strukturirano programiranje disciplinovano
programiranje zasnovano na prikladnoj sintaksi proceduralnih jezika,
sredinom 70-ih: strukturirani dizajn - izrada hijerarhijskih sistema modularne
programske opreme, raunarom podrana dokumentacija,
134
kasne 70-te, rane '80-te: strukturirana analiza - odvajanje logikog opisa od

fizikog opisa (informacionog) sistema, oblikovanje podataka,
rane '80-te: CASE alati; izrada prototipova,
sredinom '80-ih: informaciono inenjerstvo, zdrueni razvoj aplikacija (Joint
Application Development),
kasne '80-te: brzi razvoj aplikacija (Rapid Application Development),
rane 90-te: objektno usmjereni razvoj,
kasne 90-te, rane 2000-te: automatizacija informatikih tehnologija, ... .
Raunarsku osnovu (Computing Fundamentals) softverskog inenjeringa
sainjavaju: algoritmi i strukture podataka (Algorithms and Data Structures), arhitektura
raunara (Computer Architecture), matematika podrka (Mathematical Foundations),
operativni sistemi (Operating Systems) i programski jezici (Programming Languages).
Proizvodi softverskog inenjeringa (Software Product Engineering) su: zahtjevi
softverskog inenjeringa (Software Requirements Engineering), softverski dizajn
(Software Design), kodiranje softvera (Software Coding), testiranje softvera (Software
Testing), rad softvera i odravanje (Software Operation and Maintenance).
Upravljanje softverom (Software Management) u slijedeim segmentima:
softversko upravljanje projektom (Software Project Management), softversko
upravljanje odluivanjem (Software Risk Management), softversko upravljanje
kvalitetom (Software Quality Management), softversko upravljanje konfiguracijom
(Software Configuration Manage-ment), softversko upravljanje procesima (Software
Process Management) i softverska akvizicija (Software Acquisition).
8.3. Informaciono inenjerstvo

(Information Engineering)
Informaciono inenjerstvo se bavi inenjerskim pristupom izgradnji IS i upravljanju
informacijama. IS mora biti projektovan, kao to se to ini sa drugim proizvodima.
Razvoju IS treba pristupiti kao strukturiranom i planiranom procesu podranom
raunarom. U procesu razvoja IS mora biti zastupljena sistemska primjena prikladnog
skupa metoda, tehnika i alata.
Metoda je smiljen i organizovan skup procedura izrade (modela, softvera), uz
koritenje dobro definisane notacije. Sugerie proces obavljanja i nain
dokumentovanja, a, takoe, definie primjenu tehnika i njihovo povezivanje (npr. ERD,
IDEF, DFD).
Tehnika je nain provoenja metode. Definie nain provoenja odreenog
postupka i dokumentovanja rezultata tog postupka, odnosno nain na koji se provodi
odreena aktivnost razvojnog procesa.
135
Softverski alati (tool) je instrument, sredstvo koje se koristi u razvoju IS.

Informacionu tehnologiju (Information Technology) sainjavaju: arhitektura
kompjutera (Computer Architectures), algoritmi i strukture podataka (Algorithms and
Data Structures), programski jezici (Programming Languages)), operativni sistemi
(Operating Systems), telekomunikacije (Telecommunications), baze podataka
(Database) i vjetaka inteligencija (Artificial Intelligence).
Organizacioni i upravljaki koncepti (Organizational and Management
Concepts) informacione tehnologije su: opta teorija organizacije (General
Organization Theory), upravljaki informacioni sistemi (Information Systems
Management), teorija odluivanja (Decision Theory), organizacioni postupci
(Organizational Behavior), upravljanje procesima za promjene (Managing the Process
of Change), pravni i etiki aspekti IS (Legal and Ethical Aspects of IS), profesionalizam
(Professionalism) i interdisciplinarno znanje (Interpersonal Skills).
Teoriju i razvoj sistema (Theory and Development of Systems) sainjavaju:
sistemski i informacioni koncepti (Systems and Information Concepts), pristup razvoju
sistema (Approaches to Systems Development), koncepti razvoja sistema i
metodologije (Systems Development Concepts and Methodologies), alati za razvoj
sistema i tehnike (Systems Development Tools and Techniques), planiranje aplikacija
(Application Planning), upravljanje odluivanjem (Risk Management), upravljanje
projektom (Project Management), informaciona i poslovna analiza (Information and
Business Analysis), informacioni sistemski dizajn (Information Systems Design),
implementacija sistema i strategija testiranja (Systems Implementation and Testing
Strategies), rad sistema i odravanje (Systems Operation and Maintenance) i razvoj
posebnih vrsta informacionih sistema (Systems Development for Specific Types of
Information Systems).
8.4. Sistemsko inenjerstvo

(System Engineering)
Nema opte prihvaene definicije sistemskog inenjerstva. Ipak, za sistemsko
inenjerstvo se moe rei da:
1. Sagledava sistem kao cjelinu pristupom sa vrha prema dolje (top-down);
2. Upravlja ciklusom koji sadri sve faze od dizajna do odumiranja;
3. Osigurava djelotvornost i (dovoljno) rano donoenje odluka definisanjem
zahtjeva i njihovim povezivanjem sa odgovarajuim oblikovanjem;
4. Predstavlja interdisciplinarni i/ili timski pristup oblikovanju i razvoju, kojim se
osigurava njihova djelotvornost i funkcionalnost.
136
8.5. CASE proizvodi

Nepostojanje odgovarajuih softverskih alata za podrku razvoja softverskih
proizvoda, kao i kompleksnost zadataka i tehnika koje se u metodologiji ivotnog
ciklusa i u strukturiranom pristupu primjenjuju, odnosno drugi i trei uzrok softverske
krize, predstavlja motiv za pojavu CASE proizvoda. Skraenica CASE je akronim
naziva na engleskom jeziku Computer Aided Software Engineering ili Computer Aided
System Engineering (programsko/sistemsko inenjerstvo podrano raunarom), dok je
skraenica CAISE akronim naziva Computer Aided Information System Engineering
(informaciono/sistemsko inenjerstvo podrano raunarom).
Pod CASE proizvodom se podrazumjeva bilo koji programski proizvod namjenjen
za podrku, ili automatizaciju, barem jednog zadatka u okviru ivotnog ciklusa drugog
programskog proizvoda, ili je namjenjen za kompletnu podrku projektovanju i
realizaciji drugog programskog proizvoda. Osnovni ciljevi primjene CASE proizvoda su:
obezbjeenje zadovoljavajueg kvaliteta projekta i projektne dokumentacije,
obezbjeenje zadovoljavajueg kvaliteta samog programskog proizvoda, poveanje
produktivnosti projektanata i programera, skraenje
vremena
projektovanja
i
realizacije programskog proizvoda, obezbjeenje jednostavnog i jeftinog odravanja
programskog proizvoda.
Primjena strukturiranog pristupa i metodologije ivotnog ciklusa znae upotrebu
veeg broja manje ili vie formalnih tehnika i crtanja razliitih dijagrama i matrica
zavisnosti na razliitim nivoima detaljnosti. Pri tome, izmjena na jednom nivou
detaljnosti esto zahtjeva izmjene i na drugim nivoima detaljnost. Ukoliko je rije o
projektu veeg obima, runo projektovanje i sprovoenje ovih izmjena, odravanje
konzistentne projektne dokumentacije i kontrola kompleksnosti projekta postaju
naporan posao, sa neizvjesnim ishodom. Tako, na primjer, o manuelnom
projektovanju BP ima smisla govoriti samo ako broj tipova entiteta i veza
konceptualne sheme ne prelazi nekoliko desetina, odnosno ako broj identifikovanih
atributa ne prelazi sto. Kada veliina konceptualne sheme prelazi ove granice,
pokazuje se da problem, zbog kompleksnosti prouzrokovane obimom, prevazilazi
ovjekove moi percepcije i koncentracije. Tada vrijeme i napor, potrebni za izradu
projekta, postaju teko prihvatljivi, a kvalitet rezultata nepredvidiv. U projektu se
javljaju greke u vidu: sinonima, homonima, protivrjenih ogranienja i druge. Greke
uinjene u ranijim fazama projekta se uoavaju tek u kasnijim fazama, kada ih je tee
otkloniti. Iterativno vraanje na ranije faze projekta u cilju otklanjanja greaka, moe
dovesti do pojave novih greaka, ije otklanjanje zahtjeva dodatni napor.
Strukturirani pristup zahtjeva od projektanta i programera da posjeduju visoki nivo
ekspertnog znanja iz oblasti softverskog inenjerstva i zadovoljavajui nivo znanja iz
predmetne oblasti za koju se pravi programski proizvod, to u praksi ne mora biti
uvijek obezbjeeno.
137
U skladu sa navedenim razlozima, od CASE proizvoda se oekuje da obezbjede

to vii stepen automatizacije kada se obavljaju slijedei zadaci:
izrada dokumentacije,
izrada dijagrama i matrica,
konceptualno i implementaciono projektovanje shema baza podataka,
projektovanje programskih proizvoda,
izrada (generisanje) programskih proizvoda,
obavljanje izmjena na programskim proizvodima,
integracija parcijalnih rezultata projektovanja u jedinstvenu cjelinu,
kontrola funkcionalnosti, konzistentnosti, kompletnosti i kvaliteta projekta, itd.
Da bi zadovoljili navedene zahtjeve, CASE proizvodi su organizovani tako da rade
nad jedinstvenom BP, koja se naziva Rjenik podataka CASE proizvoda. Rjenik
sadri podatke o svim konceptima (objektima, vezama, dijagramima, matricama,
dokumentaciji, itd.), definisanim u okviru jednog, ili vie projekata, koji se smjetaju u
rjenik. Svi pojedinani alati jednog CASE proizvoda koriste i smjetaju podatke u isti
rjenik podataka, ta je prikazano na slici 8.1.
Alat za modeliranje
dijagrama toka podataka
Alat za modeliranje
ER dijagrama
Alat za modeliranje
programskih specifikacija
Rjenik
podataka
Alat za modeliranje
matrica
Generatori koda
Slika 8.1. Meusobni odnos razliitih CASE alata i jedinstvenog

rjenika podataka.
Mogu se sresti razliite klasifikacije CASE proizvoda. Jedna, uobiajena i ne
suvie selektivna, je izvrena prema fazama ivotnog ciklusa koje CASE proizvod
pokriva. Prema toj klasifikaciji, razlikuju se:
138
1. Projektantski CASE proizvodi, koji su namjenjeni za podrku prve (gornje) tri

faze ivotnog ciklusa, odnosno za podrku projektovanju programskog
proizvoda (strategija, snimanje i analiza, projektovanje);
2. Programerski CASE proizvodi, namjenjeni za podrku posljednje (donje) tri
faze ivotnog ciklusa, odnosno za podrku realizacije programskog proizvoda
(programiranje, uvoenje u upotrebu, eksploatacija i odravanje);
3. Integrisani CASE proizvodi, tj. integrisani projektantski i programerski CASE
proizvodi, namjenjeni da podre svih est faza ivotnog ciklusa, odnosno
kompletan ivot programskog proizvoda.
8.5.1. Projektantski CASE proizvodi

(Upper CASE, Front-End CASE)
Za podrku prve tri faze ivotnog ciklusa koriste se projektantski CASE proizvodi.
Kod projektovanja IS, CASE proizvod koji podrava fazu strategije, treba da sadri
alate za podrku: planiranja projekta (izbora metodologije i tehnika razvoja IS, naina i
standarda za primjenu izabrane metodologije i tehnika), upravljanja projektom
(detaljnog planiranja i izdavanja zadataka, kao i vremenskog terminiranja projekta),
planiranja i upravljanja resursima (materijalnim, kadrovskim i finansijskim), praenja
realizacije projekta i sprovoenje postupaka kontrole kvaliteta.
Da bi podrao faze snimanja i analize, CASE proizvod treba da sadri alate za
izradu: strukturiranih modela sistema (model funkcionalne, organizacione i prostorne
strukture), modela procesa koji se odvijaju u realnom sistemu, dijagrama toka
podataka, konceptualne sheme BP i matrica, kojima se iskazuju meuzavisnosti
izmeu elemenata konceptualne sheme BP, kao i funkcionalne, organizacione i
prostorne strukture sistema.
Kada je u pitanju faza projektovanja, CASE proizvod moe da sadri alate za:
prevoenje konceptualne sheme BP u implementacionu shemu, implementaciono
projektovanje sheme BP, generisanje programskih specifikacija aplikacija (struktura
menia, opisa ekranskih ili tampanih formi, podshema i standardnih procedura za upite
i auriranje BP) i implementaciono projektovanje programskih specifikacija aplikacija.
Implementaciono projektovanje sheme BP se moe sprovoditi neposredno, bez
prethodne izrade i prevoenja konceptualne sheme, ili putem modifikacija prevedene
konceptualne sheme. Implementaciono projektovanje programskih specifikacija
aplikacija se moe sprovoditi neposredno, bez prethodnog generisanja programskih
specifikacija, ili putem modifikacija prethodno generisanih programskih specifikacija.
Pri razvoju savremenih projektantskih CASE proizvoda, sve je naglaeniji zahtjev
da CASE sadri inteligentne alate i alate koji u sebi ukljuuju elemente ekspertnog
znanja. To znai da alati treba da primoravaju projektanta na potovanje formalnih
139
pravila upotrebe odgovarajue tehnike, koji dani alat podrava. Na taj nain projektant
dobija tehniku pomo u radu. Pored toga, na viem nivou, oekuje se da alat prui
projektantu i ekspertnu, tj. intelektualnu, pomo u primjeni odgovarajue tehnike.
Takva pomo se ogleda u mogunosti da sam alat prua odgovarajua projektantska
rjeenja ili da je u stanju da analizira, vrednuje i ocjenjuje rjeenja, koja je napravio
projektant softverskog proizvoda.
8.5.2. Programerski CASE proizvodi

(Lower CASE, Back-End CASE)
U programerske CASE proizvode se najee svrstavaju generatori koda.
Generatori koda su u mogunosti da, na osnovu opisa implementacione sheme BP,
generiu DDL opis sheme BP za konkretni sistem za upravljanje BP, ili na osnovu
programskih specifikacija generiu 4GL programe aplikacija IS.
U smislu poveanja nivoa deklarativnosti, preglednosti i lakoe programiranja
jezici 4. generacije (4GL) predstavljaju dalju nadogradnju jezika 3. generacije. Teko je
dati preciznu definiciju jezika 4. generacije, jer on podrazumjeva iroki spektar
programerskih ili korisnikih alata, razliitih namjena i mogunosti, od jednostavnih
alata do razvijenih jezika. Zbog toga se esto govori o pojmu okruenja 4. generacije.
Na slici 8.2 su prikazani mogui elementi jednog 4GL okruenja. Treba uoiti da u
takvo okruenje ulaze i jezici 3. generacije, to znai da ova vrsta jezika i dalje ima
svoje mjesto u postupku realizacije programskog proizvoda.
Alati za programiranje
logike aplikacija
Generatori i editori
ekranskih menia
ekranskih formi
Relacioni upitni jezik

SQL
izvjetaja
Programski jezici 3.
generacije
upita
Rjenik podataka
Slika 8.2. Mogui elementi jednog 4GL okruenja.
140
Uoava se da su svi alati iz okruenja 4. generacije, iz istih razloga kao i CASE

proizvodi, oslonjeni na jedinstveni rjenik podataka. ta vie, nastoji se da ovi alati
budu integrisani sa CASE proizvodima po pitanju koritenja zajednikog rjenika
podataka, ime se obezbjeuje jedinstveno razvojno okruenje programskih proizvoda.
Da se prevazie neproduktivno i dugotrajno programiranje uz upotrebu jezika 3.
generacije razvijeni su generatori koda i 4GL okruenje. Neposredni pozitivni efekti
primjene generatora koda i 4GL okruenja se ogledaju u ubrzanju i olakanju procesa
izrade programskog proizvoda, kao i smanjenju trokova odravanja aplikacija, budui
da je olakano otkrivanje, pronalaenje i ispravljanje uoenih greaka. Posredni
pozitivan efekat je mogunost primjene prototipskog pristupa razvoju programskih
proizvoda, o emu je detaljnije bilo govora u podtaki 2.4.3.
Prisutni su i negativni efekti primjene generatora koda i jezika 4. generacije. Jezik
4. generacije ili generisana aplikacija pomou jezika 4. generacije je, na istoj
hardverskoj platformi, sporija od odgovarajue aplikacije razvijene uz pomo jezika 3.
generacije. Funkcionalnost, odnosno irina primjene, generatora koda i 4GL okruenja
je manja od funkcionalnosti jezika 3. generacije. Uoava se da ovi nedostaci
predstavljaju kontinuitet trendova koji se odnose i na uvoenje i upotrebu jezika 3.
generacije.
Prednosti i nedostaci upotrebe generatora koda i 4GL okruenja ukazuju da se
pravilnim izborom generatora koda i 4GL okruenja, jezika 3. generacije i naina
povezivanja sa 4GL okruenjem i odgovarajue (jae) hardverske platforme, mogu
obezbjediti sve prednosti upotrebe generatora koda i 4GL okruenja, uz ouvanje
dovoljno dobrih performansi izvravanja razvijene aplikacije i dovoljno dobre
funkcionalnosti za rad. To znai da se mogu postii velike utede pri realizaciji i
odravanju aplikacija IS dodatnim ulaganjima u hardver i alate za razvoj aplikacija.
Uloeni napor, potreban
za realizaciju aplikacije
Sloenost aplikacije
Slika 8.3. Problematika funkcionalnosti generatora koda, 4GL okruenja i

jezika 3. generacije [Mogin et al. 2000].
141
Problematika funkcionalnosti generatora koda, 4GL okruenja i jezika 3. generacije

ilustrovana je dijagramom na slici 8.3. Uoava se da se manje sloene aplikacije mogu
neposredno dobiti upotrebom generatora koda. Za sloenije aplikacije je, nakon
generisanja koda potrebno izvriti dodatna prilagoavanja, upotrebom alata 4.
generacije, dok se vrlo sloeni i dominantno proceduralni dijelovi aplikacija mogu
uspjeno realizovati samo upotrebom jezika 3. generacije. Iz navedenih razloga je
prethodno i naglaena potreba kombinovane upotrebe alata 4. generacije i jezika 3.
generacije.
Upotreba generatora koda ima jo jedan nedostatak. Ponovno generisanje
aplikacije, nakon ve izvrenog prilagoavanja generisanog koda pomou alata 4.
generacije, moe znaiti unitavanje prethodno izvrenih prilagoavanja. Savremeni
trendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublai na dva
naina. Prvi nain predvia pomjeranje granice upotrebljivosti generatora koda, tako
da se pomou generatora koda mogu izgraditi i sloenije aplikacije. Cilj je da se pree
granica od 80% ukupno generisanog koda, koji bi bez daljih dorada bio spreman za
upotrebu. Drugi nain se zasniva na sistematinom evidentiranju doraenih dijelova
generisanog koda u okviru rjenika podataka, tako da svako slijedee regenerisanje
uzme u obzir i postojea prilagoenja koda.
8.5.3. Integrisani CASE proizvodi

(Integrated CASE (ICASE))
Integrisani CASE proizvodi pokrivaju sve faze razvoja, a sadre i dodatne module
za povratno (reverzno) inenjerstvo, nadzor i upravljanje izvedbom, te osiguranje
kvaliteta IS. Potpuno integrirano CASE okruenje automatizuje izradu modela
poslovnog sistema, planiranje razvoja IS, kao i izgradnju i primjenu IS. Integracija
programskih proizvoda se ostvaruje usvajanjem pravila odreene metode razvoja,
upotrebom zajednikog rjenika podataka i zajednikog interfejsa, te automatizovanim
proslijeivanjem informacija iz jedne faze razvoja u drugu.
Smatra se da je samo 25 do 30% specifikacija prenosivo iz projektantskog
(gornjeg) u programerski (donji) CASE, to predstavlja ozbiljnu prepreku potpuno
automatizovanoj izradi programskih proizvoda.
8.5.4. Projektovanje shema baze podataka pomou CASE proizvoda

Za projektovanje shema baza podataka postoje samostalni CASE proizvodi. Takvi
proizvodi, uglavnom, pripadaju klasi projektantskih CASE proizvoda. Ukoliko sadre i
generatore opisa sheme BP, prilagoene konkretnim SUBP, tada pripadaju i klasi
programerskih CASE proizvoda. Integrisani CASE proizvodi, koji su nomjenjeni za
razvoj IS, obavezno sadre alate za projektovanje konceptualne, implementacione i
interne sheme BP.
142
Savremeni CASE proizvodi za projektovanje konceptualne, implementacione i

interne sheme najee omoguavaju projektovanje konceptualne sheme u modelu
entiteti veze (ER model) i automatsko prevoenje ER konceptualne u
implementacionu shemu, zasnovanu na relacionom modelu podataka. Pojedini CASE
proizvodi omoguavaju i projektovanje fizike organizacije relacione BP. Rezultat
ovakvog projektovanja je automatski generisan opis implementacione i interne sheme
u relacionom upitnom jeziku SQL.
CASE proizvod za projektovanje ER konceptualne sheme se sastoji od grafikog
editora za poluautomatsko crtanje ER dijagrama i analizatora
konzistentnosti
nacrtanih shema. Grafiki editor sadri predefinisane standardne geometrijske simbole
koncepata ER modela. Crtanje ER dijagrama se obavlja biranjem simbola i njihovim
povezivanjem, u skladu sa pravilima strukturiranja ER dijagrama. Analizator
konzistentnosti je namjenjen za provjeru usaglaenosti nacrtanog ER dijagrama sa
pravilima strukturiranja, kao i pronalaenje potencijalnih sinonima i homonima.
Mogunost definisanja funkcionalnih zavisnosti posjeduju samo pojedini CASE
proizvodi, najee u skupu tipa entiteta ili tipa veze. Nakon definisanja skupa
funkcionalnih zavisnosti, CASE proizvod vri normalizaciju relacija. Ukoliko rezultat
normalizacije pokae da posmatrani tip entiteta ili tip veze treba dekomponovati, CASE
proizvod tu izmjenu u ER dijagramu vri automatski. Meutim, u praksi se esto
deava da ovako nacrtan ER dijagram ne predstavlja lako razumljivu osnovu za
komunikaciju izmeu projektanta i korisnika. Krajnji korisnik je, prvenstveno,
zainteresovan da pomou raunara olaka, ubrza i povea kvalitet obavljanja svojih
radnih zadataka i nije spreman da se udubljuje u analizu kvaliteta konceptualne
sheme, koja je predstavljena, za njega, apstraktnom i stranom notacijom. Tek kada
dobije gotove programe, ili njihove prototipove, korisnik moe da ocjeni da li mu
rjeenje odgovara. Sa druge strane, programere interesuje podshema u
implementacionom modelu podataka. Prema tome, crtanje ER dijagrama se moe
posmatrati samo kao usputan, i ne ba jednostavan, korak u projektovanju
implementacione sheme i, u sutini, predstavlja heuristiki postupak. Nema dokaza da
paljivo projektovanje ER dijagrama, nakon prevoenja u relacioni model podataka,
uvjek rezultuje u skup relacija, koje su bar u treem normalizovanom obliku (3NO).
Na slikama 8.4, 8.5 i 8.6 su prikazani primjeri nekih aktuelnih CASE proizvoda. Na
slici 8.4 je prikazana ekranska forma integrisanog CASE alata (ICASE) Popkin System
Architect, koji podrava vie metodologija projektovanja IS (SSAD, OOAD), reverzno
inenjerstvo i generisanje programskog koda. Na slici 8.5 je prikazana ekranska forma
alata za oblikovanje BP CA AllFusion ERwin, koji je namjenjen za dizajn i reinnjerstvo
BP, podravajui razliite notacije projektovanja (IDEF1X, IE, DM). Na slici 8.6 je
prikazana ekranska forma alata za projektovanje objektno orijentisanog softvera
Rational ROSE, koji podrava OO metode (UML, OMT, Booch, ).
Slika 8.4. Ekranska forma integrisanog CASE alata (ICASE).
Slika 8.5. Ekranska forma CASE alata za oblikovanje baza podataka.
143
144
Slika 8.6. Ekranska forma CASE alata za projektovanje objektno orijentisanog

softvera.
8.5.5. Prikaz CASE proizvoda ORACLE/Designer 2000

Komercijalni CASE proizvod korporacije ORACLE (USA), pod nazivom
ORACLE/Designer 2000, namjenjen je za podrku slijedeih faza ivotnog ciklusa:
snimanje i analiza poslovnog sistema,
projektovanje IS,
programiranje korisnikih aplikacija,
uvoenje u upotrebu i eksploatacija IS,
odravanje IS.
i predstavlja sveobuhvatni programski proizvod, sa znaajnom prisutnou na tritu
informacione tehnologije u vrijeme pisanja ove knjige.
Designer 2000 radi sa jedinstvenim rjenikom podataka (rjenik podataka
programskog proizvoda Designer 2000 se na engleskom jeziku zove Repository),
implementiranom u okviru ORACLE baze podataka. Projektantsko-programerske
aktivnosti u okviru Designer-a 2000 se obavljaju u cjelinama, koje se nazivaju
aplikativni sistemi. Aplikativni sistem moe predstavljati zaokruenu cjelinu, podsistem
ili IS. Ovakvim pristupom projektovanju, IS se istovremeno razvija radom na vie
aplikativnih sistema. Razvoj IS pomou vie aplikativnih sistema omoguava veu
fleksibilnost u radu, prvenstveno u pogledu lakeg traenja podataka i sprovoenja
145
izmjena u okviru projekta. Takoe, olakava odravanje razliitih verzija projektne

dokumentacije i zatitu sadraja rjenika podataka od brisanja, nenamjernih izmjena ili
neovlatenog pristupa.
Navedeni pristup ne uvodi ogranienja koja bi negativno uticala na integrisanost
IS. Postoji i mogunost da se cjelokupni IS razvija putem samo jednog aplikativnog
sistema. Prilikom prijavljivanja za rad sa Designer-om 2000, korisnik se odluuje za
aplikativni sistem nad kojim e realizovati svoje projektantsko-programerske aktivnosti.
Odgovarajua ovlatenja za rad sa izabranim aplikativnim sistemom moraju biti
prethodno dodjeljena korisniku.
Designer-a 2000 svoju metodologiju moe da zasnovana, kako na klasinom
modelu primjene metodologije ivotnog ciklusa, tako i na bilo kojoj od kombinacija,
koja ukljuuje evolutivni, inkrementalni ili zvjezdasti model primjene metodologije
ivotnog ciklusa, kao i na prototipskom razvoju. Designer 2000 omoguava, takoe, i
primjenu tehnika reverznog inenjerstva BP i aplikacija IS. Po svom sastavu Designer
2000 je integrisani skup programskih alata, razliite namjene, slika 8.7.
Slika 8.7. Ekranska forma ORACLE/Designer-a 2000.

Za fazu strategijskog planiranja, kao i faze snimanja i analize, Designer 2000
predvia upotrebu slijedeih alata:
146
Process Modeller, koji je namjenjen za dijagramski prikaz procesa i tokova u

realnom sistemu i podrku njihovog eventualnog reverznog inenjeringa,
Function Hierarchy Diagramer - alat za modeliranje funkcionalne
dekompozicije realnog sistema i strukture programske podrke informacionog
sistema,
Dataflow Diagramer - alat za modeliranje tokova podataka unutar poslovnog i
informacionog sistema, putem dijagrama tokova podataka, i
Entity Relationship Diagramer - alat za konceptualno modeliranje sheme
baze podataka, putem dijagrama tipova entiteta i veza.
Za fazu projektovanja informacionog sistema su namjenjeni slijedeci alati:
Database Design Transformer, za prevoenje ER konceptualne sheme baze

podataka u relacionu shemu baze podataka,
Design Editor / Server Model, za projektovanje relacione, implementacione
sheme baze podataka (oblikovanje shema relacija - tabela, programiranje
procedura, funkcija, paketa procedura i funkcija, kao i trigera baze podataka),
Application Design Transformer, za inicijalno generisanje programskih
specifikacija (opisa programskih modula, podshema i strukture ekranskih
formi),
Design Editor / Modules, za implementaciono projektovanje programskih
modula (tj. programa za interaktivno auriranje baze podataka, generisanje
izvjetaja, grafiki prikaz podataka i biblioteka procedura i funkcija), kao i
struktura programskih modula (ekranskih formi aplikacija),
Design Editor / DB Admin, za projektovanje interne sheme baze podataka
(zadavanje parametara fizike organizacije podataka), i
Design Editor / Distribution, za projektovanje distribuirane sheme baze
podataka.
Kada su u pitanju faze: programiranja, uvoenja u upotrebu i eksploataciju i
odravanje informacionog sistema, Designer 2000 je opremljen slijedeim
generatorima koda:
Generate Database From Server Model, za generisanje SQL opisa
implementacione sheme baze podataka,
Generate Database Administration Objects - generisanje SQL opisa interne
sheme baze podataka,
Generate Module / Forms, za generisanje programskih modula za interaktivni
pristup bazi podataka, zasnovanih na jeziku IV generacije Developer 2000 /
Forms,
Generate Module / Reports, za generisanje programskih modula za
formiranje izvjetaja, zasnovanih na jeziku IV generacije Developer 2000 /
Reports,
147
Generate Module / Graphics, za generisanje programskih modula za grafiki

prikaz podataka, zasnovanih na jeziku IV generacije Developer 2000 /
Graphics,
Generate Module / Visual Basic, za generisanje programskih modula za
interaktivni pristup bazi podataka, zasnovanih na programskom jeziku Visual
Basic,
Generate Module / Web Server, za generisanje ORACLE WebServer
programskih modula, za pristup bazi podataka preko Internet/Web servera,
zasnovanih na HTML formatu, i
Generate Module / Help System, za generisanje programskih modula za
prezentiranje uputstava i ostalih tekstualnih informacija, zasnovanih na Forms
ili Microsoft Help korisnikom interfejsu.
Moe se konstatovati da je Designer 2000, u dijelu koji se odnosi na generatore
koda, dosta vrsto povezan i sa ORACLE-ovim okruenjem etvrte generacije
Developer 2000, u koje, izmedju ostalih, spadaju alati: Form Builder, za kreiranje
interaktivnih programskih modula (koji se jos nazivaju i "forme"), Report Builder, za
kreiranje programskih modula za izvjetavanje (koji se nazivaju i "izvjetaji") i
Graphics Builder, za kreiranje programskih modula za grafiki prikaz podataka
("grafikona").
Pored nabrojanih, Designer 2000 posjeduje i slijedee programe, koji se
svrstavaju u oblast reverznog inenjerstva:
Capture Design of Database, namjenjen za reverzni inenjering
implementacione ili interne sheme baze podataka, na osnovu stanja rjenika
ORACLE baze podataka, kao i utvrivanje i eliminisanje razlika izmeu stanja
rjenika ciljne baze podataka i rjenika Designer-a 2000,
Table To Entity Retrofit, namjenjen za prevoenje implementacione sheme
baze podataka u konceptualnu shemu baze podataka, prikazanu putem
dijagrama tipova entiteta i veza,
Capture Design of Form, namjenjen za reverzni inenjering interaktivnih
programskih modula, kreiranih u okviru alata Developer 2000/Forms,
Capture Design of Report, namjenjen za reverzni inenjering programskih
modula za izvjetaje, kreiranih u okviru alata Developer 2000/Reports,
Capture Design of Library, namjenjen za reverzni inenjering bibliotekih
modula, kreiranih u okviru paketa Developer 2000,
Capture Design of Visual Basic, namjenjen za reverzni inenjering
interaktivnih programskih modula, kreiranih pomou alata Visual Basic, i
Capture Applicatoin Logic, namjenjen za usaglaavanje implementacione
specifikacije Forms modula iz Designer-a 2000 i postojeeg Forms modula iz
Developer-a 2000.
U skupu alata opte namjene, Designer 2000 posjeduje slijedee:
148
Repository Object Navigator, namjenjen za direktni pristup objektima u

rjeniku podataka Designer-a 2000, putem hijerarhijski organizovanog
navigatora objekata,
Matrix Diagramer, namjenjen za izgradnju razliitih tipova matrinih
dijagrama,
Repository Reports, za generisanje velikog broja razliitih tipova izvjetaja,
na osnovu stanja rjenika podataka Designer-a 2000, pri emu ti izvjetaji
slue za sprovoenje odreenih kontrola i analiza kvaliteta projekta, ili samo
kao "papirna" projektna dokumentacija,
Repository Administration Utility, pomou kojeg se obavljaju administrativni
zadaci nad Designer-om 2000, kao to su: instalacija i deinstalacija rjenika
podataka, dodjela prava pristupa korisnicima, arhiviranje i dearhiviranje
rjenika podataka, obavljanje odreenih formalnih kontrola, itd,
Online Help, kao alat za prezentiranje uputstava za koritenje Designer-a
2000, i
SQL Plus, za interaktivno izvravanje SQL naredbi nad ORACLE bazom
podataka.
Kada je u pitanju objektno orijentisani pristup razvoju informacionog sistema, u
okviru Designer-a 2000 se pojavljuje alat pod nazivom:
Object Database Designer, namjenjen za projektovanje dijagrama klasa
objekata, prevoenje dijagrama klasa objekata u implementacionu shemu
baze podataka i implementaciono i fiziko projektovanje sheme baze
podataka.
8.6. Reverzno inenjerstvo

Nastanak pojma i tehnika reverznog inenjerstva je motivisan slijedeom
situacijom. U mnogim organizacijama uloena je velika koliina materijalnih,
finansijskih i ljudskih resursa u razvoj i eksploataciju IS. Jedan od zahtjeva, koji se
postavlja prilikom prelaska na nove informacione tehnologije, jeste da se u razvoj
inovirane verzije IS ne kree iz poetka. Nastoji se da se sav uloeni napor, iskustvo,
postojea rjeenja i resursi to bolje iskoriste, jer je to daleko ekonominije od
ponovnog projektovanja IS.
Poetak reverznog inenjerstva u razvoju programskih proizvoda se vezuje za
postupak runog, ili automatizovanog generisanja projektnih i programskih
specifikacija, na osnovu prethodno realizovanog programskog proizvoda. Tehnike
reverznog inenjerstva se koriste za ostvarivanje slijedea dva osnovna cilja. Prvi cilj je
generisanje projektne i programerske dokumentacije za aktuelnu verziju programskog
proizvoda, za koju prethodno takva dokumentacija nije uraena, u cilju stvaranja
osnova za odravanje tekue verzije tog programskog proizvoda. Drugi cilj je
149
generisanje projektnih i programskih specifikacija programskog proizvoda u formatu

"razumljivom" CASE proizvodu, pomou kojeg se eli razviti nova verzija tog
programskog proizvoda.
Na slici 8.8 je prikazana ekranska forma alata za reverzno inenjerstvo.
Slika 8.8. Ekranska forma CASE alata za reverzno inenjerstvo.

Tehnike reverznog inenjerstva, u domenu IS, se primjenjuju za ostvarenje
slijedeih zadataka:
1. Generisanje implementacionog opisa sheme BP, na osnovu nekih od
slijedeih parametara: realnih podataka koji postoje u BP, stanja rjenika
podataka konkretnog sistema za upravljanje bazama podataka (SUBP) pod
kojim je posmatrana BP realizovana ili opisa datoteka i formata slogova u
programskom kodu aplikacija tekue verzije IS (npr. u okviru SUBP
ORACLE/Designer 2000 reverzni inenjering implementacione sheme BP, na
osnovu stanja rjenika ORACLE baze podataka i eliminisanja razlika izmeu
rjenika ciljne BP i rjenika Designer-a 2000, obavlja program Capture Design
of Database);
2. Generisanje konceptualne sheme BP, na osnovu implementacione sheme
baze podataka (npr. u okviru SUBP ORACLE/Designer 2000 prevoenje
implementacione sheme BP u konceptualnu shemu BP obavlja program Table
To Entity Retrofit);
3. Generisanje programskih specifikacija (struktura menia, ekranskih formi ili
formi za izvjetaje, podshema i proceduralne logike) na osnovu programskih
kodova aplikacija tekue verzije IS (npr. u okviru SUBP ORACLE /Designer
150
2000 za reverzni inenjering ekranskih formi, izvjetaja i bibliotekih modula,

namjenjeni su programi Capture Design of Form, Capture Design of Report i
Capture Design of Library).
Izbor tehnike reverznog inenjerstva i njena automatizovana primjena u velikoj
mjeri zavisi, kako od prirode konkretnog zadataka koji se rjeava, tako i od kvaliteta, tj.
"informativnosti" ulazne specifikacije, na koju se tehnika reverznog inenjerstva
primjenjuje. Samim tim je i kvalitet generisanog rezultata u reverznom inenjerstvu
bitno odreen kvalitetom ulazne specifikacije. Ukoliko se, na primjer, tehnika reverznog
inenjerstva primjenjuje za generisanje implementacione sheme BP, najbolji rezultat
se, u optom sluaju, moe oekivati ukoliko se kao ulazna specifikacija koriste podaci
iz rjenika podataka sistema za upravljanje bazama podataka, a najloiji ako se kao
ulazna specifikacija koriste samo realni podaci iz BP. Ova konstatacija, medjutim, ne
mora biti uvijek tana. Ukoliko rjenik podataka konkretnog sistema za upravljanje
bazama podataka sam po sebi nije dovoljno informativan, ili se u tom rjeniku, iz
nekog razloga, ne nalaze svi potrebni podaci, tada ni izlazni rezultat reverznog
inenjerstva ne moe biti dobar.
151
9. Oblikovanje i arhitektura informacionog sistema

9.1. Oblikovanje (dizajn) sistema
Analiza sistema treba da d odgovor ta sistem mora da raditi. Dizajn sistema
daje odgovor kako sistem treba izgraditi ili kakav sistem treba biti. Daje procjenu
alternativa i detaljnu specifikaciju raunarom podranog rjeenja, odnosno tehniku
specifikaciju sistema. Omoguava izradu modela za ugradnju, kojim se opisuje kako
sistem radi, ta predstavlja fiziki dizajn.
Moderni strukturirani dizajn je procesno usmjerena tehnika razrade velikog
programa u hijerarhiju modula sa ciljem izrade programa koje je lake napraviti i
odravati. Starije varijante su oblikovanje programa sa vrha nadolje (top-down program
design) i strukturirano programiranje. Alternative i/ili nadopune su informaciono
inenjerstvo, izrada prototipa, zajedniki dizajn aplikacija (JAD), brzi razvoj aplikacija
(RAD) i objektno usmjereni dizajn.
9.1.1. Opti dizajn sistema

Opti (konceptualni) dizajn daje funkcionalne specifikacije i omoguava odabir
tehnike arhitekture sistema. Daje odgovor da li je centralizirana ili distribuirana obrada
i skladitenje podataka, nain izvrenja i koje se tehnologije koriste. Takoe, odreuje
da li je softver nabavljen, napravljen prema zahtjevima korisnika ili mjeavina.
Odreuju se i razvojni alati. Mogu se izdvojiti slijedee faze definisanja optog dizajna:
Analiza i distribucija podataka, koju sainjavaju:
1. Pretvaranje konceptualnog modela podataka u logiki model (relacioni,
postrelacioni, objektno-relacioni, objektni), ako pretvaranje nije ranije uinjeno;
2. Izrada dobrog modela podataka, koji mora biti jednostavan, neredundantan,
elastian i prilagodljiv, kao i analiza podataka i normalizacija modela;
3. Analiza dogaaja, odnosno analiza entiteta normaliziranog modela i uoavanje
dogaaja i uslova koji uzrokuju stvaranje, izmjenu i brisanje podataka i po
potrebi auriranje modela procesa.
Analiza i distribucija procesa sadri:
1. Pretvaranje logikog modela procesa u fiziki model za odabranu arhitekturu,
odnosno izrada sheme aplikacije. Fiziki procesi su: serveri, radne stanice, rad
152
koji treba obaviti, dok su fizika skladita: baze podataka, tabele (relacije) i
datoteke;
2. Grupisanje i distribucija obrade na razliite lokacije;
3. Dizajn raunarske mree, povezivanje sa drugim, postojeim, sistemima;
4. Definisanje prava pristupa logikih grupa korisnika.
Opti dizajn interfejsa se odnosi na poboljanje izgleda (ergonomija).
Izrada planova konverzije i instalacije predstavlja posljednju fazu definisanja
optog dizajna.
9.1.2. Detaljni dizajn sistema

Detaljni dizajn su tehnike specifikacije sistema. Sadri izradu fizikog modela
podataka, odnosno pretvaranje logikog modela podataka u fiziki model podataka za
odabrani SUBP, odnosno izradu sheme baze podataka.
Izrada sheme BP podrazumjeva prilagoavanje modela podataka mogunostima
i ogranienjima SUBP, odreivanje fizikih parametara (volumetrija), ugaanje baze
podataka i oblikovanje fizikih datoteka.
Dizajn programa je utvrivanje strukture programa na osnovu modela procesa.
Proces (logiki) ili skup procesa moe da se nalazi u jednom ili vie programskih
modula, te je potrebno odreivanje veza izmeu modula (standardno strukturnim
kartama). U dizajn programa ulazi i preciziranje programske logike.
Dizajn interfejsa sadri dizajn interfejsa sistema (protokoli pristupa i razmjene
podataka), kao i oblikovanje ekranskih formi i izvjetaja.
Prototipski razvoj detalja dizajna je najprihvatljiviji.
Izrada procedura za provjeru ispravnosti i konverziju sistema predstavlja
posljednju fazu detaljnog dizajna.
9.1.3. Pristupi oblikovanju i razvoju

Pristup oblikovanju i razvoju sistema moe biti cjelovit, istovremeni (tzv. frontalni)
razvoj cijelog IS. Ovakav pristup postavlja velike zahtjeve za ljudskim resursima, a
sadri problem koordinacije izvoaa.
Fazni pristup se sastoji u podjeli na podsisteme, nezavisnom razvoju pojedinih
podsistema, uz kasniju integraciju. Ovakav pristup je mogu kod velikih IS koji se daju
rastaviti. Javlja se problem rastavljanja i povezivanja podsistema.
Optimalno rjeenje je izrada jedinstvenog modela podataka, na poetku razvoja,
uz razvoj i postupnu integraciju aplikacija.
153
9.2. Arhitektura informacionog sistema

9.2.1. Dizajn arhitekture sistema
Dizajn arhitekture se sastoji od planova koji definiu pojedine komponente
sistema, u prvom redu raunarsku opremu, programsku podrku, komunikacije, sistem
zatite i globalnu podrku aplikacija. Specifikacija hardvera i softvera je podloga za
nabavku opreme.
Distribuirana prezentacija
mrea
Svi podaci na
mainframe serveru
Podaci i procesi BP
na serveru
Logika i korisniki
interfejs na PC
Distribuirani podaci i logika (3-slojna)

mrea
mrea
Korisniki interfejs na
PC klijentu
Poslovna logika na
aplikativnom serveru
Internet i Intranet
Podaci i procesi BP
na serveru
mrea
Podaci na serveru BP
Korisniki interfejs na
PC klijentu
Sva poslovna logika na

mainframe serveru
Distribuirani podaci (2-slojna)
mrea
Sigurni Intranet
provajder za pristup
podacima, logici i
Dio logike na Intranet serveru interfejsu
Sigurna konekcija na
server BP
Siguran ulaz za zatitu

aplikacija i podataka
Dio logike na
Internet serveru
Unutranji korisniki
interfejs na PC
Konekcija na spoljnji
svijet
Internet provajder
konekcija za pristup
interfejsu i dijelu logike
Slika 9.1. Primjeri arhitekture sistema.
Vanjski korisnik
PC klijent
154
Uobiajeni modeli arhitekture su:

serverski (server-based) obrada se obavlja na serveru,
klijentski (client-based) obrada se obavlja na personalnom raunaru,
klijent-server (client-server based) kombinacija prethodne dvije.
Model mree sadri prikaz glavnih komponenti sistema, njihove fizike lokacije i
nain njihovog meusobnog povezivanja.
Funkcije sistema, odnosno slojevi arhitekture, su odreeni pohranom podataka
(data storage), pristupom podacima (data access logic), elementima obrade
(application logic) i interfejsom (presentation logic).
Serveri mogu biti:
veliki raunari (Mainframe),
mali raunari (Minicomputer),
mikroraunari (Microcomputer), personalni raunari (PC).
Klijenti su klasini terminali (npr. ansi, vt220) i mikroraunari (PC), koji
omoguavaju pristup terminal emulatorima ili udaljenim radnim plohama. Tu spadaju i
terminali posebne namjene, kao to su banini terminali (bankomati), Internet kiosci,
runi raunari i sl. Na slici 9.1 su prikazani primjeri arhitekture IS.
9.2.2. Centralizovana obrada podataka

Centralizovana obrada (slika 9.2) se ostvaruje sa viekorisnikim raunarom
(mainframe, minicomputer) i terminalima. Ovom arhitekturom je omogueno
skladitenje podataka (datoteke i baze podatka), poslovna logika (programska
podrka), korisniki interfejs (uobiajeno znakovni interfejs) i interfejs sistema (mrene
i druge komponente).
Distribuirana prezentacija je proizvoljna nadogradnja centralnih aplikacija, koja se
sastoji u zamjeni znakovnog interfejsa grafikim interfejsom. Ova zamjena se,
uglavnom, izvodi na personalnim raunarima. Produava se vijek starih aplikacija, ali
se funkcionalnost ne moe znaajno poboljati.
Klijent (terminal)
Slika 9.2. Primjer centralizovane obrade.
Server Host (mainframe

raunar)
Prezentaciona logika
Aplikaciona logika
Logika pristupa podacima
Skladitenje podataka
155
9.2.3. Dvoslojna arhitektura klijent-server

Klijent je jednokorisniki raunar. Sadri interfejs, a omoguava obradu i
skladitenje podataka. Posjeduje mogunost povezivanja na servere (prema potrebi i
na druge klijente).
Klijent (mikroraunar)
Server (mikroraunar)
Aplikaciona logika
Klijent (mikroraunar)
Aplikaciona logika
Server
(mikroraunar, mali
raunar ili veliki raunar)
Logika skladitenja podataka

Slika 9.3. Dvoslojna arhitektura klijent-server.

Server je viekorisniki raunar. Omoguava rad sa dijeljenom bazom podataka,
obradu podataka i servisiranje interfejsa. Posjeduje mogunost povezivanja sa
klijentima i drugim serverima. Korisnicima izgleda kao da jedan raunar obavlja cijeli
posao.
Prednosti dvoslojne arhitekture klijent-server (slika 9.3) su u izolaciji promjena u
pojedinom sloju, kvalitetnijoj (lakoj) obradi i sredinjem upravljanju integritetom
podataka na serveru. Nedostak ove arhitekture je u oteanom odravanju aplikacione
logike (programa) na svim klijentima i pojava debelog klijenta.
Debeli klijent je onaj klijent kod koga je integrisana logika podataka. Nema
obrade podataka na serveru ili je obrada minimalna. Posjeduje minimalnu ili nikakvu
elastinost na promjenu poslovne politike.
Prednosti debelog klijenta su: brzi poetni razvoj aplikacije, vea samostalnost
klijenta i rastereenje glavnog raunara (servera). Moe imati lokalnu bazu podataka.
Kao debeli klijenti mogu se koristiti jeftini raunari sa snanim procesorima. Nedostatak
je da je poslovna logika integrisana na klijentu. Promjena poslovne logike znai
156
instalisanje nove verzije aplikacije na svim klijentima. Velika je mogunost rada sa

zastarjelim podacima. Ako sa vremenom aplikacija postane spora (zbog koliine
podataka), treba promijeniti sve klijente. Razvoj velike aplikacije sa vremenom postaje
vrlo kompleksan (sav programski kod je na klijentu).
Tanki klijent je onaj klijent kod koga se logika podataka nalazi na serveru.
Osnovna namjena tankog klijenta je prikaz podataka. Veinom se koriste u poslovnim
sistemima, a tipini primjer tankog klijenta je web pretraiva.
Prednosti tankog klijenta su: promjena poslovne logike ne znai obavezno i
promjenu u klijentskom dijelu aplikacije, promjena poslovne logike moe se obaviti
centralizovano, raunari ne moraju imati veliku procesorsku snagu, ukoliko sa
vremenom obrada postane spora (zbog koliine podataka) moe se jednostavno
poveati snaga sredinjeg raunara. Kao tanki klijent moe se koristiti npr. web
pretraiva (dobro definisano i svima dostupno). Smanjena je mogunost rada sa
zastarjelim podacima (gotovo za svaku promjenu ide se na server). Manja je
kompleksnost razvoja velikih aplikacija (kod je podijeljen na serverski dio i klijentski
dio). Nedostaci su: veliko optereenje glavnog raunara, a to znai skupi glavni
raunar. Ukoliko se kao klijent koristi web pretraiva moraju se potivati njegova
ogranienja.
9.2.4. Troslojna i vieslojna arhitektura klijent-server

Kod troslojne arhitekture klijent-server (slika 9.4) distribucija baza podataka i
poslovne logike je izvrena na zasebne servere, ime je dobijena arhitektura: server
aplikacija + server baza podataka + klijent. Namjena pojedinog sloja je slijedea:
1. Server aplikacija obavlja upravljanje transakcijama "preuzetih" sa servera
podataka. Dio ili itava poslovna logika je "preuzeta" sa klijenta;
2. Server baza podataka vri upravljanje podacima;
3. Klijent sadri korisniki interfejs. Takoe sadri dio poslovne logike, i to onaj
dio koji se ne mijenja, ili logiku linog karaktera.
Prednosti troslojne arhitekture su: bolja raspodjela optereenja, vea skalabilnost,
odnosno mogunost ekspanzije (npr. poveanja broja korisnika, bez preoptereenja ili
potrebe za promjenom procedura). Nedostaci su: sloeni (komplikovani) dizajn i razvoj,
problem raspodjele podataka, procesa, interfejsa, kao i vee optereenje mree.
Vieslojna arhitektura se koristi za razvoj sloenih aplikacija. Programski kod se
moe podijeliti u vie nivoa, npr.:
1. Kod na prezentacionom sloju - formi (GUI - Graphic User Interface);
2. Kod u sloju poslovne logike (BLL - Business Logic Layer );
3. Kod u sloju pristupa podacima (DAL - Data Access Layer);
4. Kod na bazi podataka (stored procedure).
157
esto se vri podjela u tri nivoa, i to: klijent - GUI (u web aplikaciji to je web
pretraiva), server aplikacija odnosno BLL (npr. web servis) i baza podataka (npr.
SQL Server).
Klijent
(mikroraunar)
Server aplikacija
(mikroraunar)
Aplikaciona logika
Klijent
(mikroraunar)
Server aplikacija
(mikroraunar)
Aplikaciona logika
Server BP
(mikroraunar, mali

Web server
(mikroraunar)
Aplikaciona logika
Server BP
(mikroraunar, mali

Slika 9.4. Troslojna arhitektura klijent-server.
9.2.5. Izbor arhitekture klijent-server

Izbor arhitekture moe zavisiti o raspoloivim raunarima i mrenoj infrastrukturi.
Openito, mogu se primijeniti sljedei kriterijumi (tabela 9.1):
Tabela 9.1.
Arhitekture
Aplikacije
Dvoslojne K/S
arhitekture sa
tankim klijentima
Naslijeeni aplikativni sistemi gdje je nepraktino i neisplativo odvojiti

aplikativne obrade i upravljanje podacima.
Raunarsko-zahtjevne aplikacije sa vrlo malo ili bez obrade podataka.
Podacima bogate aplikacije (pretraivanje i upiti) sa veoma malo ili bez
aplikativne obrade.
158
Dvoslojne K/S
arhitekture sa
debelim klijentima
Aplikacije gdje se aplikativna obrada izvodi na klijentu sa COTS

(Commercial Off-The Shelf Software) programskom podrkom.
Aplikacije koje zahtjevaju raunarsko zahtjevne obrade podataka (npr.
vizualizacija podataka interaktivno ili u izvjetajima).
Aplikacije sa relativno vrstom krajnje - korisnikom funkcionalno-u,
koritene u okolini gdje je dobro uspostavljeno upravljanje sistemom.
Troslojne ili
vieslojne K/S
arhitekture
Aplikacije velikog opsega sa stotinama ili hiljadama klijenata.

Sistemi u kojima su i podaci i aplikacije promjenljivi.
Aplikacije u kojima se integriu podaci iz viestrukih izvora.
Primjer 1: Sa arhitekturom klijent-server potrebno je napraviti aplikaciju koja e

prikazivati [Fertalj & Kalpi, 2005]:
kupce, prodavae i datume narudbi,
nazive artikala, jedininu cijenu i koliinu za pojedinu narudbu,
ukupnu koliinu i ukupnu vrijednost narudbe,
treba prikazivati zadnjih 20 narudbi.
Rjeenje sa debelim klijentom glasi: na klijentu napraviti SQL upit kojim se
obuhvataju podaci o zadnjih 20 narudbi, na klijentu napraviti SQL upit kojim se
obuhvataju detalji za zadnjih 20 narudbi, kad se promjeni narudba proi kroz sve
detalje i ispisati one koje pripadaju trenutnoj narudbi. Usput raunati zbirne
vrijednosti.
Rjeenje sa tankim klijentom je: na klijentu pozvati stored proceduru koja vraa
podatke o zadnjih 20 narudbi, kad se promjeni trenutna narudba pozvati stored
proceduru koja vraa detalje trenutne narudbe i zbirne vrijednosti.
Primjer 2: Promjene zahtjeva navedenih u primjeru 1: korisnik se nakon mjesec
dana rada aplikacije, naravno, predomislio i eli da se prikazuje zadnjih 50 narudbi.
Ispunjenje promjene zahtjeva se sastoji u slijedeem. Na debelom klijentu treba
promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvrnu opciju te dostaviti
aplikaciju korisnicima (sporo i skupo). Na tankom klijentu treba na serveru promijeniti
samo pohranjenu proceduru za dohvat narudbi (brzo, manje od pet minuta, i jeftino).
Primjer 3: Rjeenje razmatranog primjera u vieslojnoj arhitekturi sadri slijedee
nivoe, slika 9.5:
1. Prezentacioni sloj GUI, koji slui za prikupljanje informacija od korisnika,
vrenje osnovnih provjera unijetih podataka, njihovo slanje sloju poslovne
logike, primanje rezultata od sloja poslovne logike i prezentaciju dobijenih
rezultata korisniku u razumljivom formatu. Ovaj sloj sainjavaju HTML,
DHTML, Win32 aplikacije, klijent-server skriptovanje, Java apleti, ActiveX
kontrole, itd. Prezentacioni sloj se moe generisati generatorom koda npr.
Visual Studio.NET 2003, u programskom jeziku Visual C (C#);
159
2. Sloj poslovne logike BLL, koji je namjenjen za primanje podataka od

prezentacionog sloja, interakciju sa slojem za pristup podacima radi
procesiranja podataka i slanje obraenih informacija prezentacionom sloju.
Ovaj sloj obezbjeuje poslovna pravila i servise koji pomau tokom pisanja
skalabilnih aplikacija (npr. Web servise, transakcione i servise komponenti,
asinhrone i servise redova, serverska skriptovanja). Ovi servisi su vrsto
integrisani jedan sa drugim i sa OS i dostupni su preko komponentnog modula
(COM+). Sloj poslovne logike BLL se moe generisati generatorom koda npr.
Visual Studio.NET 2003, u programskom jeziku C#;
3. Sloj pristupa podacima DAL, koji direktno ostvaruje interakciju sa podacima
koji, obino, egzistiraju u BP kao to su SQL Server ili ORACLE. Ovaj sloj slui
za smjetanje, pronalaenje i odravanje podataka, kao i za integritet
podataka. Pristup podacima preko Windows DNA se naziva Universal Data
Access (UDA). UDA je skup modela sistemskog i aplikacionog nivoa, koji se
zovu OLE-DB, ADO i RDO. Sloj pristupa podacima DAL se moe generisati
generatorom koda npr. LLBLGen, u programskom jeziku C#.
COM+
Sistemski servisi
Administracija
Prezentacioni sloj
Mreni servisi
DHTML, Forme
Sloj poslovne logike
Alati
Zatita
Web server IIS
Transakcije MTS
Sloj pristupa podacima
Osnovni servisi
DBMS, File system, mail, txt
Slika 9.5. Arhitektura Windows DNA (Distributed interNet Aplication architecture).

Tok izrade aplikacije u vieslojnoj arhitekturi je slijedei.
1.
Prezentacioni sloj GUI (generator koda Visual Studio.NET 2003 u

programskom jeziku C#).
Prema pravilima vieslojnog programiranja na prezentacionom sloju (formi) koristi
se sloj poslovne logike (b-klasa). U razmatranom primjeru treba konstruisati b-klasu i
ispisati podatke u gridu. U konstruktoru b-klase se uitavaju podaci o narudbama.
Nakon toga se okine event, na kojem se prikazuju podatci o detaljima narudbi.
Programski kod glasi:
private void FormLastOrders_Load(object sender, System.EventArgs
e){
// Konstruisi bklasu
_bLastOrders = new BLastOrders(_connectionString);
// Postavi DataSource na oba grida
160
dataGridOrders.DataSource =
_bLastOrders.OrdersEntityCollection;
dataGridOrderDetalis.DataSource =
bLastOrders.OrderDetailsEntityCollection;
// Ispii detalje trenutno selektirane narudbe
dataGridOrders_CurrentCellChanged(sender, e);
}
Kod promjene selektirane narudbe treba osvjeiti podatke o detaljima. To se
radi tako da se pozove pripadajua metoda u b-klasi (SelectOrderDetails). Ta metoda
dohvata detalje neke narudbe, a usput rauna i zbirne podatke (ti podaci su dostupni
preko property-a b-klase). Programski kod glasi:
private void dataGridOrders_CurrentCellChanged(object sender,
System.EventArgs e) {
// Dohvati podatke o trenutno selektiranoj narudbi
_bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrde
rs[
dataGridOrders.CurrentRowIndex, 0]));
// Ispii zbirne podatke na formu
textBoxTotalPrice.Text =
_bLastOrders.TotalPrice.ToString("C");
textBoxTotalQuantity.Text =
_bLastOrders.TotalQuantity.ToString();
}
2. Sloj poslovne logike BLL (generator koda Visual Studio.NET 2003 u
programskom jeziku C#).
Bie naveden primjer konstruktora u b-klasi (sloju poslovne logike). Sloj poslovne
logike treba paljivo definisati, tako da GUI slui samo za prikazivanje podataka, a sve
vee obrade i rad sa bazom moraju se odvijati u b-klasi. U razmatranom primjeru uz bklasu postoji i sloj pristupa podacima (DAL) prije same baze podataka. U b-klase se
intenzivno koristi DAL, a iz priloenog koda se vidi da je programiranje znatno
jednostavnije nego upotrebom SQL upita. Programski kod glasi:
public BLastOrders(string connectionString) {
// Konstruiranje adaptera za pristup bazi podataka
_dataAccessAdapter = new
DataAccessAdapter(connectionString);
// Definiranje EntityCollection-a za narudbe
_ordersEntityCollection = new EntityCollection(new
OrdersEntityFactory());
SelectLastOrders();
// Definiranje EntityCollection-a za detalje narudbe
161
_orderDetailsEntityCollection = new EntityCollection(new

OrderDetailsEntityFactory());
}
Navedeni primjer sa dohvatom zadnjih 20 narudbi u b-klasi se moe promjeniti

da se dohvati zadnjih 50 narudbi.
Radi se o primjeru pristupa bazi podataka preko objekata. Mada se ne ini
jednostavnim, u praksi ima mnoge prednosti u odnosu na pisanje SQL upita. Osnovna
prednost je manja mogunost greke, kao i preglednost koda. Na slian nain bi se
rijeio i dohvat detalja pojedine narudbe. Programski kod glasi:
public EntityCollection SelectLastOrders() {
// Isprazni trenutni sadraj
_ordersEntityCollection.Clear();
// Narudbe treba sortirati prema datumu unatrag
ISortExpression sorter = new SortExpression(
SortClauseFactory.Create(OrdersFieldIndex.OrderDate,
SortOperator.Descending));
// Definisanje dodatnih staza za dohvat podataka (treba
dohvatiti podatke o kupcima i radnicima)
IPrefetchPath2 path = new
PrefetchPath2((int)EntityType.OrdersEntity);
path.Add(OrdersEntity.PrefetchPathCustomers);
path.Add(OrdersEntity.PrefetchPathEmployees);
// Dohvat podataka iz baze (uz koritenje sortera i dodatnih
staza za dohvat)
_dataAccessAdapter.FetchEntityCollection(_ordersEntityCollec
tion, null, 20, sorter, path);
// Vrati podatke dohvaene iz baze
return _ordersEntityCollection;
}
3. Sloj pristupa podacima DAL (generator koda LLBLGen u programskom
jeziku C#).
Ovaj sloj slui za pristup bazi podataka (DAL);
Programski kod se generie pomou generatora koda;
DAL se u ovom primjeru dijeli na dva dijela: DALGeneric - objekti za pristup
bazi koji su isti za sve baze i DALDBSpecific - objekti za pristup bazi koji su
specifini za pojedine baze podataka;
Prednosti rjeenja upotrebom generatora programskog koda: mogunost pristupa
bazi podataka preko objekta (nije potrebno znanje SQL-a), mogunost promjene baze
podataka, nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka,
manja mogunost greke, itd.
162
10. Dizajn baza podataka

10.1. Uvod u dizajn baza podataka
Dizajn baza podataka, u prvom redu, obuhvata izradu sheme baze podataka
(fiziki model, tehniki nacrt), kao i prevoenje modela podataka u strukture podrane
odabranom tehnologijom (SUBP). Takoe, obuhvata odreivanje primarnog kljua,
sekundarnog kljua, stranog kljua i opisnih polja. Relacione BP, koje su nezamjenljive
kod obrade poslovnih podataka, karakteriu slijedei koncepti: strukturirani upitni jezik
(SQL), okidai - trigeri (triggers), pohranjene procedure (stored procedures), dinamiki
skupovi podataka (cursor), korisniki definisani tipovi podataka i funkcije, ... . Prednosti
baza podataka su: pouzdanost - konzistentnost i integritet podataka, efikasno
rukovanje podacima, prilagodljivost na promjene zahtjeva i skalabilnost. Analizu
podataka sainjavaju priprema modela podataka za ugradnju, normalizacija, odnosno
tehnika organizovanosti atributa, dovoenje modela u odreeni normalizovani oblik
(NO), 3NO ili vii NO.
O zastupljenosti pojedinih tipova baza podataka za komercijalnu upotrebu,
najbolje govori tabela 10.1. [Internet, 2006].
Tabela 10.1.
Product
Developer
License
DB Type
Access 2002
Microsoft
Commercial Relational
Cache
InterSystems Corp.
Commercial Post-relational
DB2
IBM
eXtremeDB
McObject
Commercial Navigational
FileMaker
FileMaker
Commercial FileMaker
FoxPro
Microsoft
Informix
IBM
Matisse
Matisse Software
Commercial Object-oriented
Objectivity/DB
Objectivity
OpenInsight
Revelation Software
Commercial Multi-valued
Oracle 8i, 9i
Oracle
SQL Server 2000
Microsoft
Sybase ASE 12.5
Sybase
UniData
IBM
Commercial Nested relational
UniVerse
IBM
Commercial Nested relational
Versant enJin
Versant Corp.
163
10.2. Normalizacija
Normalizacija, odnosno tehnika organizovanosti atributa, je postupak strukturiranja
sheme relacione baze podataka tako da se ukloni to vie neodreenosti
(nekonzistentnosti). Stepen normalizacije (normalizovani oblici) se poveava od 1NO
do 5NO. Veina dizajnera se zaustavlja na 3NO ili na BCNO (Boyce-Codd NO).
Formalne definicije normalizovanih oblika glase:
a) Relacija R je u prvom normalizovanom obliku ako svi njeni atributi imaju samo
"atomske" vrijednosti. Relacija u 1NO ne moe opisivati entitete ili veze u
sistemu koji imaju vieznane atribute, ne moe za atribut imati neku drugu
relaciju.
b) Relacija R je u prvom normalizovanom obliku ako je bilo koji podskup
neprimarnih atributa funkcionalno zavisan od kljua.
c) Relacija R je u prvom normalizovanom obliku ako izmeu kandidata za klju i
ostalih neprimarnih atributa postoje slijedei tipovi preslikavanja: 1:1, 1:M, C:1
i C:M.
Relacija R je u drugom normalizovanom obliku, ako je u prvom, i ako svi njeni
neprimarni atributi potpuno funkcionalno zavise od svih kandidata za kljueve.
Relacija R je u treem normalizovanom obliku, ako je u drugom, i ako ne sadri
tranzitivne zavisnosti neprimarnih atributa od kandidata za klju.
Relacija R je u BCNO ako je svaka determinanta kandidat za klju. Determinanta
je svaki atribut, prost ili sloen, od koga neki drugi atribut potpuno funkcionalno zavisi.
Relacija R (X, Y, Z) je u etvrtom normalizovanom obliku ako postojanje
netrivijalne vieznane zavisnosti X Y uslovljava postojanje funkcionalne
zavisnosti X A za svaki atribut A relacije R.
Relacija R je u petom normalizovanom obliku ako i samo ako se svaka zavisnost

spajanja u relaciji R moe pripisati kandidatu za klju.
Informatikim argonom reeno, normalizacija se svodi na ispunjenje tzv.
"relacione zakletve" [Finkelstein, 1989]:
164
klju - 1NO: nema ponavljajuih grupa, definisan primarni klju,

cijeli klju - 2NO: svi nekljuni atributi u potpunosti zavisni o itavom PK,
nita drugo nego klju - 3NF: svaki nekljuni atribut je neposredno zavisan
samo o PK,
BCNO: svi atributi koji odreuju druge atribute ine mogue kljueve.
Prevoenje modela i normalizacija uporabom CASE alata se odvija slijedeim
redoslijedom:
1. Automatizovano dodjeljivanje stvarnih tipova podataka konkretnog SUBP;
2. Stvaranje relacija (tabela) za entitete nadtipa i podtipa;
3. Automatizovana migracija kljua i prepoznavanje tzv. viseih veza (dangling
relationships), odnosno veza na tabele koje nisu ukljuene u generisanje
modela;
4. Veina CASE alata normalizira u 1NO: zamjena veza vie-prema-vie
asocijativnim entitetima i zamjena vieznanih atributa entitetima;
5. Vii normalizovani oblici: problem prepoznavanja djelominih i tranzitivnih
zavisnosti;
6. Generisanje programskog koda okidaa (trigera).
Prije poetka kodiranja obavlja se ogranieno uvoenje konzistentnosti i ugaanje
baze podataka, zbog poboljanja elastinosti i poboljanja performansi, gdje zahvat
moe rezultirati u logiki model odreenim brojem intervencija. Denormalizacija se
svodi na ogranieno i kontrolisano naruavanje NO.
10.3. Denormalizacija
Zamjenici (surogati) kljueva su kljuevi sa samopoveavajuim vrijednostima
(serial), koji se umeu ispred kljua sastavljenog od veeg broja atributa (npr. 3). Na
originalni klju postavlja se jednoznaan (unique) kompozitni indeks. Teorijski se ne
preporuuje za asocijativne entitete, koji naslijeuju kljueve svojih roditelja, jer se time
gubi smisao identifikacione veze. Praktino, zamjenika kljua treba ugraditi kada je
relacija (tabela) u koju se ugrauje referensirana iz drugih relacija, a to nije u
suprotnosti sa poeljnim redundantnim vezama.
Primjer 1:
@IdRadnogMjesta = @IdOrgJedinice, @IdZanimanja

RadnoMjesto = @IdRadnogMjesta
Zaposlenje = @IdOsobe, @IdRadnogMjesta,
@DatZaposlenja, ... .
Primjer 2: Drzava 1:N Mjesto 1:N Osoba, pri emu je Mjesto =

@IdDrzave, @IdMjesta, ... .
165
isti dizajn je dosljedna ugradnja zamjenika kljua sa samopoveavajuim

vrijednostima u sve tabele (relacije) baze podataka, ime se pojednostavljuje ugradnja.
Dolazi do umnoavanja kljueva, zamjenik postaje primarni a originalni postaje
alternativni klju, i dolazi do gubitka izvorne vrijednosti stranog kljua.
Dijeljenje relacija je smjetanje rijetko koritenih atributa u posebnu relaciju.
Udruivanje relacija je uklanjanje pojedinih relacija stapanjem atributa obine
veze 1:1 ili udruivanje nadtipa sa podtipovima kardinalnosti 1:1, pod uslovom da su
sline strukture i sadraja.
Uvoenje konzistentnosti je dodavanje atributa za uvanje izvedenih vrijednosti.
To mogu biti atributi uvanja za izvedenu vrijednost koja se moe izraunati
agregiranom funkcijom (npr. iznos rauna kao suma iznosa stavki) ili oznake zadnje
vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u relaciji sa velikim
brojem zapisa (torki), npr. stanje skladita. Dodavanje atributa uvanja moe biti za
redundantne vrijednosti koje se inae dobijaju sloenim i/ili sporim upitima (zadnje
zaposlenje + zadnji izbor u zvanje + zadnje kolovanje) ili dodavanje atributa kao to
su zastavice za "trajno" oznaavanje zapisa.
Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to
stvarno nuno i na takav nain da ne ugroava integritet podataka, odnosno
aplikativno upravljanje integritetom.
10.4. Ugradnja pravila za ouvanje integriteta

Ouvanje integriteta, stvaranjem objekata u rjeniku BP, obuhvata entitetski
integritet i referencijalni integritet. Entitetski integritet se ostvaruje postavljanjem
primarnog kljua, dok se referencijalni integritet ostvaruje postavljanjem stranog kljua
i ogranienja na unos. Kod referencijalnog integriteta mora postojati vrijednost stranog
kljua (mandatory - not null), strani klju se smije postaviti na nul-vrijednost (optional null), domenski integritet se ostvaruje postavljanjem ogranienja na skup vrijednosti, a
alternativni kljuevi su sa obaveznim atributima i jedinstvenim indeksima.
Pravila referencijalnog integriteta, za opti sluaj, su postupci prilikom unosa,
auriranja i brisanja roditelja ili djeteta i odnose se na: zabranu (restrict), brisanje torki
koje imaju odgovarajuu vrijednost stranog kljua (cascade), auriranje odgovarajuih
vrijednosti stranih kljueva (set null) i postavljanje na standardnu vrijednost (set
default).
Ugradnja referencijalnog integriteta moe biti razliita. Neposredno upravljanje
referencijalnim integritetom od strane SUBP (DRI - Direct Referential Integrity), a svodi
se na restrikciju pri unosu, tj. obavezni unos (not null) stranog kljua i provjeru
postojanja referensirane torke pri unosu, postojanje opcionog, tj. nedefinisanog
stranog kljua (null), ili kaskadnu obradu torki koje referensiraju roditelja koji se aurira
ili brie, npr:
166
[ ON DELETE { CASCADE | NO ACTION } ]

[ ON UPDATE { CASCADE | NO ACTION } ].
Upravljanje referensijalnim integritetom okidaima (triggers) je elastiniji pristup,
koji omoguava ugradnju i ostalih postupaka prilikom unosa/izmjene/ brisanja torki
(vidjeti taku 10.6).
Aplikaciono upravljanje integritetom su postupci unosa/izmjene/brisanja podrani
programskim kodom. Javlja se problem umnoavanja programskog koda, naroito kod
hibridnih sistema (4GL + GUI).
Mjeovito upravljanje referencijalnim integritetom je kombinacija navedenih
mogunosti, sa tim da neposredno upravljanje referencijalnim integritetom od strane
SUBP (DRI) ima prednost.
Mogui problemi su viestruki. Neki atribut stranog kljua moe biti primarni
atribut. Pokuaj auriranja na nul-vrijednost stranog kljua koji je dio primarnog kljua u
suprotnosti je sa pravilom entitetskog integriteta. Prilikom auriranja stranog atributa
koji je ujedno i primarni atribut ne smije se naruiti jedinstvena vrijednost kljua.
Postupak kaskadnog auriranja ili brisanja torki treba provesti rekurzivno, da bi se
referencijalni integritet ouvao u svim dijelovima baze podataka, a ne samo na mjestu
obrade.
10.5. Podeavanje baze podataka

Postavljanje indeksa se vri radi osiguranja integriteta podataka i ubrzanja
dobijanja podataka. Koriste se slijedee preporuke za postavljanje indeksa. Indeksi
treba da su:
1. Jedinstveni indeksi nad primarnim i alternativnim kljuevima (integritet);
2. Indeksi nad stranim kljuem (ubrzanje provjere integriteta i spojnih upita);
3. Indeksi nad najee koritenim poljima, tj poljima koja se koriste za
grupisanje, sortiranje ili selekciju uz uslov (ubrzanje pretraivanja);
4. Neki sistemi implicitno kreiraju indekse za primarne i strane kljueve.
Uopteno, u tom sluaju ne treba posebno kreirati indekse. Ako su kljuevi
sloeni, pretraivanje e raditi brzo, uglavnom po prvom polju, a po potrebi
postaviti dodatne indekse nad preostalim poljima;
5. Grupni indeks (CLUSTERED INDEX), faktor popunjenosti (FILL FACTOR), ... .
Promjene podataka uzrokuju auriranje indeksa. Izbjegavati nepotrebne i indekse
koji su sastavni dio drugih indeksa! Potrebno je ukloniti indekse prilikom masovnih
obrada podataka. Preporuuje se koristiti naredbe i opcije za uvoz podataka (BULK
INSERT ... CHECK_CONSTR). Postavlja se pitanje da li treba kreirati indekse u
relacijama sa malim brojem podataka.
167
Minimizaciji nul-vrijednosti treba posvetiti nunu panju. Moe se pojaviti

problem neodreenih vrijednosti agregatnih funkcija, problem operacija sa nulvrijednostima, gdje opisna polja mogu da sadre zahtijevanu vrijednost +
pretpostavljenu vrijednost, npr. SELECT AVG(polje), gdje polje ima/nema nulvrijednosti. Moe se pojaviti problem vanjskih spojnih upita, gdje su strana polja
posebne vrijednosti u ifrarnicima, npr. 0-nepoznata vrijednost, 999-nepostojea
vrijednost.
Ubrzanje upita omoguava:
analiza plana izvoenja (Execution Plan) i odabir poeljnog plana, npr.
SELECT ... OPTION (FORCE ORDER),
primoravanje koritenja odreenog indeksa, npr. SELECT ... WITH
(INDEX(index, index...)),
primoravanje nekoritenja indeksa primjenom nekodljive funkcije nad poljem
nad kojim se uobiajeno koristi indeks, npr. WHERE NULLIF ( polje, ) = ... ,
ostale opcije, npr. SELECT ... OPTION (FAST n_rows).
Punjenje baze podataka se vri razliitim vrstama datoteka/relacija, koje mogu
biti:
matine, gdje dodani zapis ostaje zauvijek u sistemu, a moe se mijenjati,
npr. Kupac, Artikl, Predmet, OrgJedinica,
transakcione (prometne), predstavljaju zapise poslovnih dogaaja sa
ogranienim vijekom, a uklanjanje zapisa se vri uz arhiviranje, npr. Racun,
Prijavnica,
ifarnici, odnosno statiki podaci koji se koriste od razliitih aplikacija radi
ouvanja konzistentnosti podataka i poboljanja performansi, npr. Mjesto
(potanski brojevi), StatusNecega,
dokumentacione, odnosno kopije istorijskih podataka za laki dohvat i pregled
bez regenerisanja dokumenata,
arhivske, koje su uklonjene iz medija za direktni (on-line) pristup,
dnevnici (audit, log), koji predstavljaju evidenciju pristupa i promjena podataka.
Fiziku raspodjelu podataka odreuju faktor blokiranja (blocking factor), koga
odreuje broj logikih zapisa koji se obrauju jednim itanjem (fiziki zapis). Ovaj faktor
uobiajeno je odreen i automatski podeen, ali se moe i runo podeavati.
Distribucija podataka je raspodjela pojedinih relacija, zapisa i/ili polja u razliite
fizike BP ili razliite fizike segmente BP, npr. odvajanje matinih datoteka i ifarnika
od transakcionih relacija.
Replikacija podataka predstavlja umnoavanje relacija, zapisa i/ili polja u
razliite fizike BP, npr. replikacija ifarnika izmeu baze podataka na serveru i BP
debelog klijenta.
168
Smjetaj fizikih datoteka obezbjeuje poveanje sigurnosti i brzine pristupa

odvajanjem SUBP, prostora za podatke, prostora za voenje evidencije i rezervnih
kopija na razliite fizike ureaje.
Primjer: Dvije fizike jedinice, etiri logike podjele:
C:\...\binn\MSSQL.exe
D:\...\data\*.mdf
E:\...\log\*.log
F:\...\backup\*
10.6. Trigeri u relacionim bazama podataka

10.6.1. Uvod
U relacionim bazama podataka, u cilju ouvanja uslova integriteta, definiu se
automatski postupci koji se izvravaju nakon obavljanja radnji unoenja, brisanja i
auriranja podataka u relacijama. U relacionom upitnom jeziku SQL (PL/SQL) takvi
postupci se zovu trigeri (okidai).
U sastavu savremenih SUBP, kakav je ORACLE/Designer-a 2000, nalaze se
generatori aplikacija (Generate Module/Forms), koji omoguavaju brzi razvoj aplikacija
za unoenje, pretraivanje, auriranje i brisanje podataka. Umjesto da se piu
programi, dovoljno je naznaiti eljenu aplikaciju upotrebom jednostavnih ekranskih
formi. Na ovaj nain zadane instrukcije se kombinuju sa mogunostima SUBP, a kao
rezultat se dobije prototip aplikacije.
Ekranska forma, koja se dizajnira pomou generatora aplikacija, se sastoji od
blokova i svaki blok odgovara jednoj relaciji BP. Unutar bloka, slog prikazuje jedan
zapis (torku) osnovne relacije. U okviru bloka postoje polja, kao prazan prostor na
formi. Polja se koriste za prikazivanje, unoenje i ureivanje podataka. Svako polje ima
odreenu veliinu, poziciju i tip podatka, koji se u njega unosi. Korisnik odreuje
sloenost dizajnirane forme i ima potpunu slobodu da izabere blokove, postavlja polja i
vri provjere uinjenog.
Generator aplikacija sadri tri nivoa dizajniranja ekranske forme:
Prvi nivo predstavlja kreiranje blokova i polja. Najjednostavnija forma
predstavlja prozore na osnovne relacije. Svako polje se moe postaviti
pojedinano ili se moe pozvati automatski uslovni blok generatora aplikacija;
Drugi nivo predstavlja definisanje blokova i polja. Na formi se mogu dodavati
osnovne provjere ili uputstva za pruanje pomoi. Na primjer, mogu se
definisati veliine polja, uslovne vrijednosti ili pomone poruke;
Trei nivo predstavlja definisanje trigera (okidaa). Ovo je najnapredniji nivo i
mogu se napraviti sloene provjere i asistencije pisanjem kratkih SQL
programa, najee u cilju ouvanja uslova integriteta.
169
10.6.2. Razvrstavanje naredbi u trigerima

Trigeri se mogu definisati kao skup naredbi koje poinju da se izvravaju u nekom
trenutku rada forme generatora aplikacija. Svaki triger moe biti sastavljen od jednog ili
vie koraka, od kojih svaki korak sadri jednu naredbu.
Naredbe, koje se koriste u trigerima, se mogu razvrstati u tri vrste. Te naredbe se
mogu kombinovati u jednom trigeru, ali ne i u jednom koraku. Vrste naredbi su SQL
naredbe, SQL naredbe generatora aplikacija i korisnike izlazne naredbe.
1. SQL naredbe rade sa podacima iz relacija BP ili iz ekranske forme. Triger
moe pretraivati ili modifikovati bilo koju relaciju za koju korisnik ima pravo
pretraivanja ili modifikovanja. SQL sintaksa dozvoljava trigerima da prenose
vrijednosti izmeu relacija i formi. Na primjer, slijedei SQL triger automatski javlja
naziv kupca iz relacije KUPAC u polje forme:
SELECT NAZIV
INTO: NARUDZBA.NAZIV
FROM KUPAC
WHERE KUPAC.BRKUPCA =:NARUDZBA.BRKUPCA
Navedeni triger izvrava naredbu uvijek kada korisnik javlja, unosi ili mijenja broj
kupca u formi NARUIVANJE.
2. SQL naredbe generatora aplikacija simuliraju akcije funkcionalnih tastera i
drugih operacija, koje korisnik moe izvravati. Na primjer, slijedei makrotriger pomie
kursor na blok ARTIKAL i izvrava pretraivanje:
#EXEMACRO GOBLK ARTIKAL; EXEQRY;
Makrotriger moe biti vezan za funkcionalni taster, tako da korisnik moe dobiti slog
stavki pritiskom samo na jedan taster. Ovaj makrotriger se moe izvravati svaki put
kada korisnik pregleda blok NARUDBA.
3. Korisnike izlazne naredbe pozivaju korisnikove programe napisane
problemski orijentisanim programskim jezicima, kao to su: C, Pascal, COBOL i drugi.
Korisnikim izlaznim naredbama se mogu vriti raunske radnje na poljima formi,
pristupi poljima u relacijama i drugo.
10.6.3. Naini udruivanja trigera

Trigeri se mogu udruivati za obavljanje razliitih funkcija. Udruivanje trigera se
moe razvrstati u slijedeih pet grupa:
1. Unos, pri pokretanju forme ili ulaska kursora u novi blok, slog ili polje;
2. Pretraivanje, prije i nakon dobijanja sloga;
3. Promjena, nakon promjene vrijednosti i prije ili poslije prihvatanja unosa,
auriranja ili brisanja u BP;
170
4. Izlaz, pri naputanju forme ili kada kursor napusti blok, slog ili polje;
5. Pritisak na taster, kada korisnik pritisne funkcionalni taster.
Moe se izdvojiti jo jedna grupa trigera, koja se ne odnosi na naprijed navedene
sluajeve:
6. Trigeri imenovani od korisnika, obini trigeri ili podtrigeri, koji se pozivaju iz
drugih trigera.
Trigeri se mogu definisati na tri nivoa forme, i to: trigeri na nivou polja, kada su
udrueni sa odreenim poljem, trigeri na nivou bloka, kada su udrueni sa odreenim
blokom i trigeri na nivou forme, kada su udrueni sa cijelom formom. Na svakom nivou
postoje odreeni trigeri koji se mogu primjeniti.
Na nivou polja se mogu primjeniti slijedei trigeri: prije polja, poslije promjene,
poslije polja, trigeri za tastere i trigeri imenovani od korisnika.
Na nivou bloka se mogu primjeniti slijedei trigeri: prije bloka, prije pretraivanja
bloka, poslije bloka, prije sloga, poslije pretraivanja sloga, trigeri prihvatanja, prije
brisanja, poslije brisanja, prije unosa, prije auriranja, poslije auriranja, poslije sloga,
trigeri za tastere i trigeri imenovani od korisnika.
Na nivou forme se mogu primjeniti slijedei trigeri: prije forme, poslije forme,
trigeri za tastere i trigeri imenovani od korisnika.
Svaki tip trigera se moe definisati na njegovom nivou ili bilo kojem viem nivou.
Na primjer, triger "poslije promjene" se moe definisati na nivou polja, bloka ili forme.
Podruje rada trigera je odreeno nivoom na kojem je definisan. Na primjer, triger
"poslije promjene" definisan na nivou bloka e se primjenjivati na svako polje bloka,
odnosno izvravae se odmah nakon to korisnik promjeni vrijednost u bilo kojem polju
bloka, a ne samo kada korisnik naputa blok. Triger "poslije promjene", definisan na
nivou forme, e se primjenjivati na svako polje forme.
33
10.6..4. Optimalni redoslijed definisanja trigera

Da bi se trigeri definisali neophodno je navesti njegove korake i vlasnitva,
ukljuujui: koji je tip trigera, odnosno kada e se izvravati, koje naredbe e se
izvravati u svakom koraku i ta e se desiti ako korak uspije ili ne uspije.
Da se kreira novi triger, potrebno je:
1. Name (ime): imenovati triger ili upisati tip trigera koji se eli kreirati. Tip trigera
vai na nivou u kojem se definie. U sluaju potrebe dati naredbe TYPES ili
KEYS, da se dobiju LIST TYPES ili LIST KEYS prozori, koji sadre listu
moguih trigera na tekuem nivou ili listu moguih trigera za tastere na bilo
kojem nivou.
171
2. Izabrati CREATE da se prikae TRIGGER STEP prozor, gdje se mogu unijeti

naredbe koje treba izvriti.
Mogue je izvriti modifikaciju postojeeg trigera, brisanje trigera ili promjenu
njegovog imena. Pomenuti TRIGGER STEP prozor se koristi da se napiu ili promjene
koraci trigera, a TRIGGER STEP ATTRIBUTES prozor da se kontrolie ta se dogaa
kada korak uspije ili ne. Triger se sastoji od serije koraka, koji se obino, ali ne uvijek,
izvravaju u nizu. Korak se sastoji od jedne SQL naredbe, SQL naredbe generatora
aplikacija ili korisnike izlazne naredbe.
Za definisanje koraka trigera, potrebno je:
1. Seq#: upisati redoslijed za normalno izvravanje koraka;
2. Label (oznaka): ako se eli drugaiji pristup koraku u trigeru, u ovoj rubrici se
upisuje oznaka koja to omoguava;
3. Podruje trigera: u ovu rubriku se upisuje SQL naredba ili SQL naredba
generatora aplikacija, koja e se izvravati u ovom koraku;
4. Poruka ako triger ne uspije: u ovu rubriku se upisuje poruka koja e se
prikazati ako korak ne uspije;
5. Za definisanje atributa koraka trigera (neobavezno), potrebno je izabrati
ATTRIBUTES da se prikae TRIGGER STEP ATTRIBUTES prozor.
Kada je izvreno uspjeno definisanje koraka trigera, za dalji rad postoje dvije
mogunosti: da se izvri dalje pomjeranje u slijedei korak (NEXT STEP) ili da se
kreira novi korak izborom CREATE i ponovi postupak.
Atributi koraka trigera (korak 5) saoptavaju: ta se deava kada korak uspije ili
ne uspije ili koliko memorije se dodjeljuje korisniku.
Definisanje atributa koraka trigera se vri na slijedei nain:
1. Abort trigger when step fails (prekini triger kada korak ne uspije): ako je ovaj
prekida odabran, a oznaka prekida nije specifirana, neuspjeh koraka e
zaustaviti izvravanje trigera;
2. Reverse return code (obrnuto javljanje): ako je ovaj prekida izabran, normalni
kriterijum za uspjeh ili neuspjeh se obre;
3. Return success when aborting trigger (javi uspjeh kada se prekine triger): ovaj
prekida ima znaenje samo ako je izabran i Abort trigger when step fails
(prekini triger kada korak ne uspije);
4. Separate cursor data area (odvojeni prostor memorije): svakom koraku trigera
je dodjeljen vlastiti prostor u radnoj memoriji raunara;
5. Success and Failure labels (oznake uspjeha i neuspjeha): koraci trigera se
normalno izvravaju u nizu. Meutim, mogu se koristiti oznake koraka da se
promjeni redoslijed izvravanja.
172
Odreivanje uspjeha i neuspjeha trigera je prilino sloeno i zbog ogranienog

prostora nee se dalje razmatrati u ovoj knjizi.
10.6.5. Objanjenje pojmova iz sintakse trigera

Odreeni pojmovi iz sintakse trigera bie objanjeni u skladu sa izvrenim
razvrstavanjem naredbi u trigerima na: SQL naredbe, SQL naredbe generatora
aplikacija i korisnike izlazne naredbe.
SQL naredbe se zasnivaju na standardnom relacionom upitnom jeziku SQL, koji
predstavlja osnovu za rad sa podacima u BP. Osim toga, SQL naredbe u trigerima
omoguavaju da se: postave podaci u polja forme, vri raunanje sa podacima u formi,
mijenja oblik podataka u formi, provjerava da li podaci postoje u BP i provjeravaju
podaci u poljima forme.
SQL naredbe se unose neposredno u TRIGGER STEP prozor. Svaki SQL iskaz
(naredba + pomoni iskaz) je ukljuen u jedan korak trigera. SQL naredbe imaju dva
proirenja, koja omoguavaju vezu sa poljem forme:
1. Moe se upotrijebiti sintaksa :(BLOK.)POLJE da se izvri obraanje polju u
formi. Dvotaka (:) oznaava upuivanje polju forme, umjesto atributu relacije;
2. U SELECT iskazu se moe ukljuiti izraz INTO da se postave javljene
vrijednosti u polja forme. Prema tome, postavljanje dvotake (:) u INTO izrazu
je nepotrebno, ali se moe upotrijebiti radi pojanjenja.
Proirena sintaksa SELECT naredbe je:
SELECT ((relacija).(atribut_lista)|:(blok.)polje|)
(INTO (:)(blok.)polje)
FROM relacija_lista
(WHERE klauzula)
(HAVING klauzula)
(GROUP BY klauzula)
Podaci se mogu postaviti u bilo koje polje bloka. To moe biti polje koje odgovara
osnovnoj relaciji za blok (polje BP), ili ono koje ne odgovara. Takoe, to moe biti polje
koje je vidljivo, ili ono koje nije vidljivo. Ako je vidljivo, to moe biti polje koje korisnik
moe da modifikuje (dozvoljen unos i/ili dozvoljeno auriranje) ili ne, itd.
SQL naredbe generatora aplikacija, za razliku od SQL naredbi koje imaju
viestruku upotrebu, se mogu koristiti samo u koracima trigera i to za:
predefinisanje funkcionalnih tastera,

izvoenja serije akcija na formi bez pritiskanja tastera,
izvrenje trigera imenovanih od korisnika,
pozivanje druge forme,
173
rad sa varijablama, i
izvoenje naredbi operativnog sistema.
SQL naredbe generatora aplikacija se unose neposredno u TRIGGER STEP
prozor. Jedan korak trigera ukljuuje jedan iskaz (naredba + argument ili funkcija). Sve
SQL naredbe generatora aplikacija poinju znakom #. Postoje etiri naredbe koje se
mogu koristiti u koracima trigera, i to: #EXEMACRO, #COPY, #ERASE i #HOST.
#EXEMACRO naredba se koristi za izvravanje serije akcija u formi. Akcije mogu
biti korisnike funkcije (kao da korisnik pritiska odreene tastere), ili specijalne funkcije
koje se mogu izvoditi samo sa trigerima.
Makroserija naredbi se koristi da: olaka korisniku sloeno ukucavanje ili esto
ponavljanje, kontrolie tok aplikacije (npr. usklaivanje slogova iz dva ili vie blokova
forme), osigurava da se neke akcije izvode uvijek u nizu i obezbjedi pomo (npr.
pozivanjem druge forme da se proita traeni podatak).
Kada generator aplikacija izvrava korak trigera koji sadri makro, on izvodi sve
funkcije po redoslijedu. Na primjer, naredba:
#EXEMACRO NXTBLK; NXTSET; PRVBLK;
radi kao da je korisnik pritisnuo tastere <Next Block>, <Next Set of Record> i
<Previous Block> navedenim redoslijedom.
#COPY naredba se moe koristiti u koraku trigera da se kopiraju konstante,
vrijednosti polja, globalne varijable ili sistemske varijable sa izvornog na eljeno
mjesto. I izvorno i eljeno mjesto prate kljunu rije #COPY. Na primjer, slijedea
naredba dodjeljuje sadraj NARUDBA.BRNARUDBE polja varijabli GLOBAL.ID:
#COPY NARUDZBA.BRNARUDZBE GLOBAL.ID
#ERASE naredba se upotrebljava za brisanje vrijednosti globalne varijable, ije
ime dolazi iza kljune rijei #ERASE. Na primjer, slijedea naredba brie GLOBAL.ID
varijablu iz prethodnog primjera:
#ERASE GLOBAL.ID
#HOST naredba se koristi u koraku trigera da izvri neku naredbu operativnog
sistema. Iza naredbe #HOST se stavlja niz naredbi u navodnicima ili ime polja,
odnosno varijable koja sadri niz naredbi. Na primjer, slijedea naredba u operativnom
sistemu UNIX tampa datoteku dat1:
#HOST 'lpr -b dat1'
Korak trigera moe privremeno izai iz generatora aplikacija u neki drugi napisani
program. Takvi izlazi se mogu koristiti da se obrade podaci iz polja relacija i formi,
prikau poruke i izvode druge radnje koje su izvan domaaja SQL naredbi i SQL
naredbi generatora aplikacija.
174
Korisnike izlazne naredbe su mnogo komplikovanije za pisanje i izvoenje od

SQL naredbi i SQL naredbi generatora aplikacija, pa se koriste samo za one radnje
koje ove triger naredbe ne mogu izvriti, kao npr.: izvoenje sloenih provjera polja,
izvoenje sloenih rauna, izvoenje auriranja koja iniciraju vrijednosti u formi i
optimiziranje izvoenja aplikacija.
Korisniki izlazi se mogu pisati u bilo kojem od nekoliko programskih jezika,
ukljuujui C, COBOL, FORTRAN, PL/1, Pascal, Ada, a kod najnovije verzije SUBP
ORACLE 9i i u programskoim jezicima Java, XML i HTML. Kada se napie program
korisnikog izlaza, potrebno ga je ispraviti, pretkompajlirati, kompajlirati i povezati sa
trigerom.
10.6.6. Generisanje trigera CASE alatima

3
Postupak implementacionog projektovanja jednog trigera baze podataka, pomou

alata softverskog inenjeringa Designer-a 2000, ORACLE, prikazan je na slikama
10.1, 10.2 i 10.3. Rije je o trigeru PP_Stav_Nal_INS, koji je definisan nad shemom
relacije (tabele) Stav_Nal.
Hijerarhijski navigator objekata je prikazan na lijevoj strani ekranske forme, slika
10.1. Vidljivo je da je triger PP_Stav_Nal_INS direktno podreen tabeli Stav_Nal. Na
desnoj strani ekranske forme, ista slika, prikazano je tijelo trigera, iskazano putem
neproceduralnog jezika PL/SQL. Cjelokupni programski kod trigera predstavlja objekat,
odnosno PL/SQL program, pod nazivom PP_Stav_Nal_INS, koji je definisan u okviru
klase Trigger Definitions.
Slika 10.1. Postupak implementacionog projektovanja jednog trigera baze podataka u

okviru Designer-a 2000.
175
Na slici 10.2 je prikazana ekranska forma za zadavanje naziva, opisnog polja

"svrha" i naziva PL/SQL programa, pridruenog trigeru.

Slijedea ekranska forma, prikazana na slici 10.3, omoguava definisanje:
dogaaja koji pokree izvrenje trigera, trenutka okidanja trigera, kao i to da li je rije o
trigeru koji se pokree na nivou polja (iskaza), ili na nivou sloga (torke).

176
Ako se za dogadjaj izabere operacija UPDATE, tada se otvara posebna ekranska

forma, putem koje se zadaje skup obiljeja tabele (relacije), ija modifikacija dovodi do
pokretanja trigera. Ukoliko triger treba da sadri logiki (WHEN) uslov, ekranska forma
"When" omoguava zadavanje takvog uslova.
10.7. Implementaciono projektovanje, generisanje

i programiranje BP pomou CASE alata
10.7.1. Opis implementacione sheme BP
Na osnovu specifikacije implementacionog projekta sheme BP za aplikaciju
Komercijalni poslovi, ta je razmatrano u podtaki 6.3.2, vri se opis sheme BP
pomou jezika SQL. Rije je o automatski generisanom kodu, produkovanom pomou
generatora SQL koda Designer-a 2000, ORACLE. Na slici 10.4 je prikazan izvod iz
datoteke koja sadrzi SQL naredbe za kreiranje odgovarajuih relacija (tabela). Osim
SQL naredbi za kreiranje relacija BP, kreiraju se ogranienja primarnog kljua,
ogranienja torki, ogranienja stranog kljua i trigeri, ta je detaljnije opisano u
dokumentaciji SUBP.
CREATE TABLE KUPAC
(IDK NUMBER(6) NOT NULL,
NAK VARCHAR2(36) NOT NULL,
ADR VARCHAR2(62) NOT NULL),
BON NUMBER(8) DEFAULT 6 NOT NULL);
CREATE TABLE ROBA
(IDR NUMBER(6) NOT NULL,
JEM VARCHAR2(17) NOT NULL,
NAR VARCHAR2(32) NOT NULL);
CREATE TABLE SKLADISTE
(IDS NUMBER(6) NOT NULL,
NAS VARCHAR2(22));
CREATE TABLE ZALIHA
IDR NUMBER(6) NOT NULL,
ZAL NUMBER(12,4) DEFAULT 0 NOT NULL,
RAS NUMBER(12,4) DEFAULT 0 NOT NULL);
CREATE TABLE ZAG_NAL
BRN NUMBER(6) NOT NULL,
177
IDK NUMBER(6) NOT NULL,

STN VARCHAR2(17) NOT NULL,
OSN VARCHAR2(17));
CREATE TABLE STAV_NAL
BRN NUMBER(6) NOT NULL,
IDR NUMBER(6) NOT NULL,
STA VARCHAR2(17) NOT NULL,
KOL NUMBER(12,4) DEFAULT 0 NOT NULL);
Slika 10.4. Izvod iz datoteke koja sadri SQL naredbe za kreiranje

odgovarajuih relacija (tabela).
10.7.2. Generisanje programa i programiranje

Za formiranje naloga za otpremu aplikacije Komercijalni poslovi, generisanje
programa je sprovedeno upotrebom generatora modula Developer 2000 Forms,
ORACLE. Tokom postupka generisanja, koji je obino iterativne prirode, vre se
dodatne modifikacije implementacione specifikacije modula u cilju otklanjanja
eventualno uoenih nedostaka ili poboljanja izgleda dobijene ekranske forme. Izgled
ekranske forme za formiranje naloga za otpremu je prikazan na slici 10.5.
Slika 10.5. Izgled ekranske forme za formiranje naloga za otpremu.
178
Slika 10.6. Izgled prethodne ekranske forme, u trenutku kada se kursor nalazio na
polju za unos identifikacionog broja kupca (IDK).
Izgled ekranske forme, u trenutku kada se kursor nalazio na polju za unos
identifikacionog broja kupca (IDK) i kada je pozvana lista izbora vrijednosti
identifikacionog broja kupca, prikazan je na slici 10.6. U okviru ove, kao i svih drugih
lista izbora u ovom modulu, korisnik moe da zada dodatne kriterijume za prikaz
izvoda iz cjelokupne evidencije (u ovom sluaju cjelokupne evidencije kupaca).
Izgled ekranske forme za formiranje naloga za otpremu, u trenutku kada se kursor
nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvana lista izbora
vrijednosti identifikacionog broja robe, je prikazan na slici 10.7. U ovoj listi vrijednosti,
mogu se nai samo podaci o robi koja je evidentirana na zalihama onog skladita, ciji
je identifikacioni broj naveden u zaglavlju naloga. U ovom primjeru, rije je o skladitu
sa identifikacionim brojem 10.
179
Slika 10.7. Prikaz ekranske forme za formiranje naloga za otpremu.

Logika izvravanja interaktivnog modula naloga za otpremu jeste da korisnik,
nakon pokretanja programa i prijavljivanja na server BP, moe da selektira, zadaje,
modifikuje ili brie podatke o nalogu za otpremu, putem prikazane ekranske forme. Ti
podaci se smjetaju u radnu zonu programa. U sluaju da je putem ekranske forme
izvreno auriranje podataka u radnoj zoni programa, korisnik je obavezan da pokrene
postupak auriranja podataka u BP, izborom funkcije Save (Sauvaj), npr. pokretanjem
opcije menija Action/Save ili aktiviranjem odgovarajue ikone. U suprotnom treba da
odustane od izmjena podataka.
Postupak auriranja se sprovodi automatski, putem jedne transakcije, a korisnik
e, na kraju izvoenja transakcije, biti obavjeten o efektima njenog sprovoenja. Za
svaku novododanu torku u radnoj zoni programa, u okviru transakcije e automatski
biti formirana jedna SQL INSERT naredba. Isto tako, za svaku modifikovanu torku u
radnoj zoni programa, transakcija e sadravati jednu UPDATE naredbu, dok e za
svaku torku u radnoj zoni programa, koja je oznaena kao izbrisana, transakcija
sadravati jednu DELETE naredbu.
180
10.8. ifarski sistem

Serijske ifre su brojevi koji se redoslijedom dodjeljuju svakoj novo dodanoj
instanci entiteta. U modernim SUBP mogu se generirati uz opciona ogranienja, npr.
SQL Server IDENTITY [( seed , increment )].
Blok ifre su sliane serijskim iframa, s tim da su serijski brojevi grupisani prema
znaenju, npr. satelitski TV kanali: 100-199 PAY PER VIEW, 200-299 CABLE
CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ... .
Alfanumerike oznake su ogranieni skup znakovnih oznaka, esto kombinovanih
sa brojevima, npr. oznake drava: MNE, DE, IT, SLO.
Samogovoree ifre (significant position codes) su svaki broj ili grupa brojeva koji
opisuju neko svojstvo instance, npr. JMBG, a esto se koriste i u skladinoj evidenciji
(dimenzije automobilskih guma, elektrine sijalice).
Hijerarhijski kodovi predstavljaju podjelu u grupe, podgrupe itd. Kao primjeri
hijerarhijskih kodova mogu se navesti: ifra predmeta MAT03A3, sa znaenjem MAT 3
obavezni predmet u 3. semestru, ili hijerarhija vojnih sredstava n*m cifara.
Izrada ifarskog sistema je neophodna tamo gdje je nemogue preuzeti
postojee ifarnike od drugih ustanova ili iz postojeih sistema. Oznake definisane
zakonom, standardom ili drugim propisima treba preuzeti i prilagoditi. Ostale ifarnike
definisati tako da se naknadno mogu nadograivati.
Preporuke za izradu ifarnika su slijedee. ifre moraju biti dovoljno velike da
opiu eljene karakteristike, ali dovoljno male da se mogu interpretirati bez raunara.
Sistem ifriranja treba biti smislen i prikladan, kako bi dodavanje novih ifara bilo
jednostavno. Izbjegavati samogovoree ifre.
Primjer: ifarnik Studentska prehrana. Pravilnikom o studentskoj prehrani
propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu,
npr. student mora biti upisan u tekuu akademsku godinu na redovnom studiju.
Posebno se evidentira nain upisa (tabela 10.2).
Tabela 10.2.
ifra statusa
Opis statusa
Pravo prehrane
R
P
U
V
L
O
redovne studije
paralelne studije
studije uz rad
vanredne studije
paralelne studije sa pravom prehrane
studije za line potrebe
DA
NE
NE
NE
DA
DA
Primjer jedinstvene ifre: Jedinstveni matini broj akademskog graanina

(JMBAG) je jedinstveni broj u sistemu koga student dobija prilikom upisa na studije i
zadrava sve do kraja svog studija. Ako se isti student upie na dvije ili vie ustanova
181
uvijek zadrava JMBAG koji je dobio na prvoj ustanovi. Radnici u ustanovama ne

unose taj podatak, ve se on automatski generie.
JMBAG ima deset brojeva podijeljenih u dvije grupe, te kontrolni broj (deseti).
Prva etiri broja oznaavaju matinu ustanovu vlasnika. Slijedeih 5 brojeva su oznaka
vlasnika u ustanovi (matini broj vlasnika ili se generie redoslijedom). Unutar
ustanove JMBAG i matini broj (broj indeksa) su takoer jedinstveni.
Broj kartice se generie automatski, a u sebi sadri 6 grupa brojeva:
(601983) 11 (0036324986) 0
A BC
D
E
A - jedinstveni broj u meunarodnom kartinom poslovanju (IIN), glasi 601983, i
prema meunarodnom standardu ISO/IEC 7812 na jedinstven nain
identifikuje Studentsku karticu u meunarodnom sistemu kartinog poslovanja,
B - oznaka vrste kartice (1 broj) - npr: 1 - student i 4 - privremena kartica,
C - redni broj kartice koju je student dobio (1 broj),
D - JMBAG (10 brojeva),
E - Kontrolni broj kartice (1 broj).
10.9. Rjenik podataka - katalog

(Meta Modeling)
Rjenik podataka sistema za upravljanje relacionom BP je grupa relacija i pogleda
(view) koji sadre informacije o BP. To je baza podataka o bazi podataka ili meta baza.
Te relacije i poglede kreira SUBP prilikom kreiranja BP.
Rjenik podataka opisuje relacije, atribute, indekse, grupe, korisnike, privilegije i
druge koncepte iz BP. SUBP ih automatski aurira kad god se neki koncept kreira,
modifikuje ili brie. Prema tome, rjenik podataka uvijek sadri trenutni opis BP.
Relacije rjenika se mogu itati sa standardnim SQL pretraivanjem. Primjer strukture
rjenika podataka je prikazan na slici 10.8.
182
Slika 10.8. Primjer strukture rjenika podataka.

Na slici 10.9 je prikazana praktina realizacija relacija iz sastava Rjenika
podataka. Meta modeliranje moe korisno posluiti za opis poslovnih sistema i funkcija
poslovnog sistema. Na slici 10.10 je predstavljen strukturirani prikaz (meta model)
jednog poslovnog sistema, na slici 10.11 strukturirani prikaz (meta model) za primjer
Narudba, na slici 10.12 strukturirani (meta model) aplikacije Prodaja i na slici 10.13 je
prikazan primjer ekranske forme aplikacije nad meta modelom.
183
Slika 10.9. Primjer praktine realizacije rjenika podataka.

Org
cjelina
Hijerar.
(rad.mj)
Propis
Opis
procesa
Vrsta
dokumenta
Osoba
Pravna
osoba
Osoba
na dok.
Organiz.
Pravni
Inform.
Finans.
Materij.
Plan
Dokument
Doga.
na dok.
Stavka
sruktuir.
dokum.
Fizika
osoba
Vrsta
dogaaja
Zakon
Dogaaj
Osnovno
Potrono
Tehniko
***
Vrsta
sredstva
Sastavnica
sredstva
Sredstvo
Svojstvo
Svojstvo
sredstva
Slika 10.10. Strukturirani prikaz (meta model) jednog poslovnog sistema.
184
Primjer: Narudba.
Narudba MBB-Nabava za osnovno tehniko sredstvo prema preduzeu
IMB
Br. xxxx od xx.xx.200x.
Veza: Ponuda preduzea IMB br. xxxx od xx.xx.200x.
Narudbu izradio: Pero
Odobrio njegov ef: Ivo
Stavke:
Raunar IMB estium:
xx kom
MBO, CPU, RAM, HDD, CDR, FDD, CASE
Monitor 15
xx kom
tampa
xx kom
Skener
xx kom
MBB
Nabava
Pravilnik o
poslovanju
Opis
poslova
naruiv.
Narudbenica
ef
MBB,
Ivo,
Pero
Osoba
Pravna
osoba
Zakon
Plan
Broj,
Datum,
Ponuda
Narudba
estium
Monitor
tampa
Skener
Fizika
osoba
Sredstvo
Pravni
Finansij.
Menad.
Naruivanje
Osnovno
Tehniko
Vrsta
sredstva
MBO,CPU,
RAM,HDD,
CRD,FDD
Vrsta
dogaaja
Svojstvo
Svojstvo
sredstva
Slika 10.11. Strukturirani prikaz (meta model) za primjer Narudba.

Korisnik
SifMje
Zaglavlje
SifZag
VrstaDok
VrDok
StandSifPlac
StandSifOtpr
StandSifZag
StandSifNap
Napomena
SifNap
Mjesto
SifMje
185
Otprema
SifOtp
NacinPlac
SifPlac
Dokument
IdDok
Partner
SifPart
SifMje
Uplata
IdUplate
IdDok
VrDok
IdPrethDok
SifPart
SifOtpr
SifPlac
SifZag
SifNap
Parametar
SkracParam
Tarifa
TarBroj
Artikl
SifArt
TarBroj
StavkaDok
IdDok
SifArt
Slika 10.12. Strukturirani prikaz (meta model) aplikacije Prodaja.
Slika 10.13. Primjer ekranske forme aplikacije nad meta modelom.
186
11. Dizajn programske podrke

11.1. Specifikacija i dizajn programske podrke
Specifikacija programske podrke, odnosno specifikacija programa, obuhvata
navoenje svih zadataka koje program treba obaviti, meusobne povezanosti razliitih
dijelova programa i podataka, opis vrste podataka, opis ulaznih i izlaznih podataka,
kao i specifikaciju prikaza podataka.
Dizajn programske podrke, odnosno dizajn programa, sadri proces pretvaranja
zahtjeva za programsku podrku u oblik koji omoguava programiranje, opis jezikom
za oblikovanje programa (PDL - Progam Design Language (pseudokod)), pri emu
program napisan pomou PDL nema oblik izvedbenog programa.
11.2. Pristup oblikovanju programa

Pristup oblikovanju programa moe biti razliit. Tako npr. funkcionalni pristup
oblikovanju programa (Yourdon & Constantine, 1979) sainjavaju slijedee faze.
1. Strukturirani dizajn programske podrke, koji savladavanje veliine i sloenosti
programa ostvaruje razradom u hijerarhiju programskih modula. Programski
modul je grupa instrukcija, a sastoji se od paragrafa, blokova, potprograma,
subrutina.
2. Podjela programa i/ili sistema u module, ili tzv. crne kutije, omoguava veliko
unutranje prijanjanje modula (koheziju). Moduli moraju biti interno visoko
povezani, svaki modul treba obavljati jednu i samo jednu funkciju, kao i
postizanje ponovne upotrebljivosti u buduim programima. Mora biti ostvarena
mala vanjska zavisnost modula (skopanost). Moduli trebaju biti minimalno
meusobno zavisni, odnosno ostvarena minimizacija uticaja promjene jednog
modula na druge module.
Oblikovanje programa prema podacima usmjerenim pristupom (Jackson &
Warnier, 1981) zasniva se na tome da struktura podataka odreuje strukturu
programa.
Objektno usmjereni pristup se zasniva na podjeli na klase, koje istovremeno
sadre strukture podataka i procedure (metode). Procedure se obavljaju nad objektima
(instancama) klasa. Kohezija i povezivanje se, takoe, primjenjuju, a provode
kontrolisanim naslijeivanjem, interfejsom i slinostima izmeu klasa i komponenti.
187
11.3. Strukturirani dizajn

Strukturirani dizajn omoguava oblikovanje programa na osnovu dijagrama toka
podataka koritenjem strukturnih karti, transformacione i transakcione analize, kao i
plonim razlaganjem glavnog procesa u sastavne procese (slika 11.1).
Grafiki prikaz sistema
Dijagram toka
podataka sa
odreenim granicama
Dijagram toka
podataka
Strukturna karta
Pseudokod
Slika 11.1. Grafiki prikaz strukturiranog dizajna.
Strukturna karta (Structure Chart) prikazuje modeliranje programske podrke na

osnovu dijagrama toka podataka. Dijagram toka podataka prikazuje TA treba postii,
a strukturnom kartom se izraava KAKO ostvariti te zahtjeve, slika 11.2.
podatak
(data
couple)
funkcija
niz
indikator
(control
couple)
poziv
ugraena
funkcija (modul)
iteracija
selekcija
Slika 11.2. Elementi prikaza strukturne karte.
188
Prikaz hijerarhije programskih modula ukljuuje prenos podataka i upravljanja

izmeu razliitih nivoa obrade, kao i prikaz naredne, ponavljajue i uslovne obrade.
Primjer: Izvjetaj o poslovanju kompanije Gazda & ortaci, slika 11.3.
Sistem
izvjetaja o
prodaji
datum
zbir
datum
zbir
Zapii
izvjetaj
Uzmi
datum
datum
zbir
vrijednost
datum
Ispii
zbir
zbir
Uspjeh
zbir
Katastrofa
EOF
Zapii
zaglavlje
Zapii
red
datum
itaj
podatak
vrijednost
Raunaj
zbir
podatak
EOF
podatak
Pii
podatak
Slika 11.3. Strukturna karta za DTP izvjetaja o poslovanju kompanije.

Transformaciona analiza (transform analysis) je analiza promjene/ pretvaranja
podataka. Primjenljiva je na sisteme koji imaju strukturu oblika ulazsredite-izlaz, tj.
aplikacije sa jasno raspoznatljivim ulazima, sredinjom obradom i izlazima, koji se
mogu prikazati linearnim tokom podataka, slika 11.4.
Struktura dizajna, prikladna za ovakve sisteme, se sastoji od tri odgovarajua
elementa (ulaz, obrada, izlaz), tj. podsistema:
Get C, koji pribavlja podatak C,
C I, koji obradom pretvara podatak C u podatak I,
Put I, koji ispisuje rezultat I.
189
Slika 11.4. Ilustracija transformacione analize.

Transakciona analiza (transaction analysis) je analiza izvrenja/obavljanja
obrade. Primjenjuje se na sisteme sa jasno raspoznatljivim sreditima izvrenja, tj.
sisteme u kojima se donosi odluka o tome koji e se proces koristiti za pretvaranje
ulaza u izlaze (npr. interaktivne aplikacije). Ulaz se usmjerava nekom od modula
obrade, a pojedini izlazi se kasnije koriste u daljnjoj obradi, slika 11.5.
Primjer:
sredite zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajui
proces (3, 4 ili 5),
rezultirajui podatak (C1, C2 ili C3) koristi se kao izlazni tok C.
Slika 11.5. Ilustracija transakcione analize.
190
Sistemi koji nisu ni transformacioni ni transakcioni se obrauju na poseban nain.

Najee se oblikuju plonim razlaganjem glavnog procesa u sastavne procese.
Nadreeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih
podreenih procesa, te prikupiti i uvati proizvedene rezultate obrade, slika 11.6.
Primjer:
Slika 11.6. Strukturna karta za DTP razloen plonom dekompozicijom.

Stvarni sistemi su, obino, sloeni sistemi. Za oblikovanje programa se, najee,
primjenjuje kombinacija osnovnih postupaka, slika 11.7.
Slika 11.7. Prikaz sloenog sistema dobijenog kombinacijom osnovnih postupaka.
191
11.4. Dizajn interfejsa

11.4.1. Interfejsi
Korisniki interfejsi su, najee, tekstualni ili grafiki. Unos podataka moe biti
periodini za masovni unos (batch input) ili interaktivni unos (on-line), koji se obavlja na
mjestu nastanka podataka.
Automatizovani unos moe biti raznolik: biometrijski ureaji (otisci prstiju, uzorci
glasa), elektromagnetski ureaji (identifikacija objekata pomou radio talasa),
magnetski ureaji (magnetske kartice i drugo), optiki itai (optiki itai oznaka,
optiki itai teksta), pametne kartice (mikroprocesor, memorija), ureaji osjetljivi na
dodir (touch screen, touch-pad, pen-based), ... .
Izlazi (izvjetaji) mogu biti: dokumenti (prijavnice, rauni), detaljni izvjetaji
(dokumentovanje obrade, istorija i stanja evidencije), zbirni izvjetaji (grupisanje,
sortiranje, iznimke), grafiki izvjetaji (takasti, tapiasti, linijski), ... .
11.4.2. Elementi grafikog interfejsa za unos podataka

Elementi grafikog interfejsa za unos podataka su:
Text Box (i varijante) slui za unos podataka u obliku slobodnog teksta.
Radio Button slui za unos vrijednosti iz konanog malog skupa unaprijed
poznatih, meusobno iskljuivih vrijednosti (2 do 3).
Check Box omoguava unos binarnih vrijednosti, opciona vrijednost je
"nepoznato".
Drop-Down ili Combination (Combo) Box omoguava unos umjereno velikog
broja (?) poznatih (?), meusobno iskljuivih vrijednosti.
List Box namjenjen je za unos umjereno velikog broja (?) poznatih, ne nuno
iskljuivih vrijednosti.
Spin (Spinner), DomainUpDown, NumericUpDown namjenjen je za unos
nevelikog niza diskretnih vrijednosti.
Grid (mrea, matrica) predstavlja kombinaciju osnovnih elemenata.
11.4.3. Oblikovanje i standardizacija interfejsa

Organizacija interfejsa. Programska oprema mora imati standardni izgled
ekranskih formi. U svakom trenutku mora biti vidljiva informacija o dijelu obrade, vrsti
prikazanih podataka, koliini podataka te moguim akcijama. Mora postojati podruje
za navigaciju (ekranska forma za izbor ili pregled podataka), podruje za prikaz statusa
obrade i radno podruje za rad sa podacima.
192
Interfejsom moraju biti podrane razliite vrste ekranskih formi za izbor (npr.
vertikalne i krune), uz mogunost brzog odabira (funkcionalnom tipkom ili slovom
opcije). Horizontalna ekranska forma za izbor (menu bar) je uvijek vidljiva i lako
dohvatljiva. Padajue (pull-down) i kaskadne ekranske forme su "nevidljive", ali se
opcije daju grupisati. Skone forme (pop-up) nisu oigledne, skau na razliitim
mjestima. Trake sa ikonama (toolbar) su vidljivi i lako se pamte, ali postoji problem
ikona i skrivanja. Tipke za obavljanje standardnih funkcija moraju biti definisane
paljivo i jednoznano, a unaprijed treba predvidjeti i one za aktiviranje dodatnih
funkcija. Doslijednost interfejsa nuan je uslov koji programska oprema mora ispuniti.
Standardni izgled ekranske forme prikazan je na slici 11.8..
Slika 11.8. Prikaz standardnog oblika ekranske forme.

Ergonomija interfejsa. Polja ekranske forme moraju biti logiki grupisana. Unos
se mora obavljati u redoslijedu kojim su polja fiziki poredana. Treba ustrajati na
preglednosti podataka i minimizirati prekrivanje informacija (npr. u sluaju vie
istovremeno prikazanih "prozora").
Interfejs mora imati ujednaene standardne poruke, zvune signale i upozorenja,
kojima se prua dovoljna informacija, a korisnik nepotrebno ne optereuje. Poruke
moraju biti jednostavne, precizne te zavisne o kontekstu. Izbjegavati raunarski argon
193
i skraenice. Mora biti ugraena interaktivna pomo zavisna o kontekstu. Prilikom

izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. one koje
javlja SUBP) i izbjegavati strune izraze.
Na slici 11.9 je prikazana ekranska forma jednog grafikog interfejsa.
Slika 11.9. Primjer grafikog interfejsa.

Funkcionalnost interfejsa. Poeljno je da se traenje, unos i izmjena podataka
obavljaju na istoj ekranskoj formi i na isti nain. Treba omoguiti prekid akcija koje
predugo traju, pod uslovom da se tim prekidom ne naruava integritet podataka (npr.
prekid selekcija velikog broja zapisa, prekid transakcija). U svakom dijelu obrade treba
omoguiti odustajanje uz potvrdu korisnika da to stvarno eli (npr. brisanje).
Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno
dolo do promjene.
Unesene podatke treba provjeravati to ranije, po mogunosti neposredno nakon
promjene sadraja polja ekranske forme. Na polju za unos ifri treba omoguiti odabir
iz suenog skupa podataka smjetenih u ifarnik. Suenje skupa treba da se moe
obaviti na osnovu dijela tekstualnog opisa ifre, uz mogunost upotrebe meta znakova.
Korisniku treba omoguiti pregled teksta koji e biti napisan u izvjetaj. Pregled na
ekranskoj formi uklanja potrebu za ispisom na papiru i olakava prilagoavanje uslova
za selekciju podataka. Dijelove aplikacije, kojima se obavlja masovni unos podataka,
194
potrebno je prilagoditi kretanju unutar jedne ekranske forme i minimizirati potreban broj
tastera.
11.5. Ulanavanje procedura

esto se dogaa da dio rada treba ponititi zbog toga to u sistemu ne postoji
ifra koja se eli upotrijebiti, a nemogue ju je pohraniti. Problem je u tome to je
korisnik, prisiljen da ponititi do tog trenutka unesene podatke, proe kroz nekoliko
ekranskih formi za izbor do ifarnika, pohrani novu ifru, vratiti se na mjesto gdje je ona
bila potrebna, ponovi unos prije ponitenih podataka i tek tada ih pohrani.
Slika 11.10. Primjer ulanavanja procedura.

Rjeenje je da se na polju za unos vrijednosti stranog kljua omogui otvaranje
prozora, sa listom za pregled i odabir zahtijevanog podatka, uz prikaz svih zapisa u
odgovarajuoj relaciji. Takoe, treba omoguiti otvaranje liste za pregled (uz prikaz
ogranienog skupa zapisa na osnovu prethodno postavljenog uslova), aktiviranje
funkcije za unos ili izmjenu vezanog podatka i, na kraju, aktiviranje itavog modula za
obradu vezanih podataka.
Programska oprema mora slijediti poslovne procese. Gdje god je to mogue, treba
smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste
akcije. Primjer ulanavanja procedura je prikazan na slici 11.10.
195
11.6. Organizacija modula i aplikacija

Pri izradi prve globalne podjele modula i definisanju ekranskih formi za izbor, treba
paljivo grupisati poslovne procese u sisteme procedura, dati prednost uestalijim
poslovnim procesima i paziti da se grupisanje obavi po funkcionalnim cjelinama.
Postupak je slijedei. Poetni sistem je skup modula za obradu podataka u jednoj
relaciji, pri emu svaki od njih podrava standardne funkcije i poziva druge module.
Nakon toga se vri postupno udruivanje i reorganizacija modula, uz naknadno
razdvajanje sistemskih od korisnikih promjenjivih elemenata. Ovakav nain izrade
programske opreme zahtijeva vei poetni rad, ali dugorono donosi prednosti.
Poetni sistem (moduli pune i reducirane funkcionalnosti) se sastoji od poetne
ekranske forme za izbor i izvedbenih programa Pi, (i = 1, , n), koji sadre glavni
program Mi za poziv ekranske forme za izbor standardnog modula, skup standardnih
funkcija {F}i te pridrueni reducirani skup funkcija {R}i (slika 11.11).
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
Pokretaki
meni
P1
P2
Pi
Pn
M1
M2
Mi
Mn
F1
R1
F1
R1
Fi
Ri
Fn
Fn
Slika 11.11. Primjer modula pune i reducirane funkcionalnosti.

Sistem nakon reorganizacije i kodiranja modula dobija hijerarhijski oblik (slika
11.12). To je hijerarhijski ekranski meni, proizvoljne dubine, nad izvedbenih
programa, koji sadre udrueni glavni program Mj, (j) skupova standardnih funkcija,
(j) reduciranih skupova funkcija te (j) skupova runo ugraenih funkcija, (j = 1, ,
).
196
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
Hijerarhijski
meni
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
x xxxxxxx
P1
M1
F11
R11
H11
Pv
Mv
F1(j)
R1(j) H1(j)
Fv1
Rv1
Hv1
Fv(j)
Rv(j)
Hv(j)
Slika 11.12. Primjer sistema nakon reorganizacije i kodiranja modula.
11.7. Standardizacija i modularnost programske podrke

11.7.1. Standardizacija i modularnost
Standardne funkcije modula aplikacije za rad sa bazom podataka su slijedee:
1. Ulaz u modul, koji ostvaruje automatski prikaz podataka na osnovu
uslova/parametera. Moe biti prikazan niti jedan zapis, svi zapisi ili odabrani
zapisi (primarni klju je uslov za selekciju zapisa);
2. Traenje (selekcija) podataka: mora podravati traenje po uzorcima (query by
example), koje se unosi sa ekranske forme (query by form). Ako programski
jezik nema neproceduralnih naredbi za konstrukciju uslova selekcije treba ih
programski simulirati;
3. Unos novog zapisa: obavlja odgovarajuu provjeru domenskog, entitetskog i
referencijalnog integriteta. Treba omoguiti odabir, i po potrebi unos, podataka
koji se nalaze u drugim relacijama, a povezani su preko stranog kljua;
4. Izmjena postojeeg zapisa: omoguava se promjena vrijednosti prethodno
uitanog, a trenutno na ekranskoj formi prikazanog zapisa. Naelno se
zabranjuje izmjena vrijednosti identifikatora zapisa. Odabir referenciranih
podataka obavlja se kao kod unosa;
197
5. Brisanje uitanog i prikazanog zapisa uz odgovarajue integritetske provjere i

poruke. Brisanje se obavlja uz dodatnu potvrdu;
6. Pregledanje (eng. browsing) prethodno uitanih podataka: grupni pregled
veeg broja uitanih zapisa u prozoru po redovima, po stranicama, skok na
prvi/zadnji/n-ti zapis, pretraivanje liste podataka po dijelu naziva (filter) ili po
elji koji moe odabrati jedan ili vie zapisa ili onemoguiti odabir. Standardno
se prikazuju samo osnovni elementi zapisa (primarni klju i relevantni zavisni
atributi);
7. Poredak (sort) zapisa koji se prikazuju: odreivanje poretka prije selekcije ili
naknadni preraspored ve uitanih zapisa;
8. Ispisivanje izvjetaja (report): sadraj ispisa, trenutno prikazani zapis, svi
uitani zapisi, format ispisa, odnosno osnovni podatci (ifra i naziv) ili svi
podaci, odredite ispisa, npr. tampa, ekranska forma, datoteka (nova
datoteka, dodavanje na kraj postojee datoteke);
9. Izlaz iz modula: sa prenosom informacija o odabranom zapisu (primarni klju ili
cijeli zapis).
Primjer: Uitavanje po uzorku [Fertalj & Kalpi, 2005].
Pretpostavljena naredba za selekciju podataka:
SELECT Vrsta.* FROM Vrsta
ORDER BY ImenaLat
modifikuje se u:
SELECT DISTINCTROW
Vrsta.* FROM (((Vrsta) INNER
JOIN Rod ON Vrsta.IdRoda =
Rod.IdRoda) INNER JOIN
NarodnoImeVrste ON
NarodnoImeVrste.IdVrste =
Vrsta.IdVrste) INNER JOIN
NarodnoIme ON
NarodnoImeVrste.IdNarodnogImena =
NarodnoIme.IdNarodnogImena
WHERE Rod.NazRoda LIKE
"vitis*" AND
NarodnoIme.NazNarodnogImen
a LIKE "*loza*" ORDER BY
ImenaLat
198
11.7.2. Ugradnja optih programskih rjeenja

Standardni modul. Za veinu relacija u bazi podataka dovoljno je napraviti modul
sa ugraenim standardnim funkcijama. Standardne funkcije se ugrauju tako da se,
osim sa ekranskih formi unutar vlastitog modula, mogu aktivirati i iz bilo kojeg drugog
modula (slika 11.13).
Poeljno je unaprijed oblikovati standardne module i to: modul za obradu
pojedinanih zapisa, modul za tabelarnu obradu i modul tipa glava-stavke (tzv. Masterdetail).
Univerzalni modul. Alternativno, preporuuje se ugraditi univerzalni modul sa
standardnim funkcijama, koji se moe dinamiki prilagoditi tako da obrauje podatke u
razliitim relacijama. Univerzalni modul treba realizovati tako da u pogonu moe
istovremeno postojati vie instanci istog modula prilagoenih pojedinim relacijama.
U zavisnosti od projekta, univerzalni modul se moe zamijeniti i pomou polovine
standardnih modula.
Slika 11.13. Primjer osnovnog standardnog modula.

Primjer: Udruivanje standardnih modula. Forma je kreirana kao kombinacija
kopija osnovnih formi, dok se sofisticirane funkcije nadograuju runo (slika 11.14).
199
Slika 11.14. Primjer udruivanja standardnih modula.

Primjer: Univerzalni modul za tabelarnu obradu. Sadri samo osnovne objekte i
pozive na standardne procedure (metode) za obradu dogaaja vezanih uz te objekte.
U trenutku aktiviranja obavlja se prilagoavanje relacije za obradu podataka strukturi
relacije podataka (slika 11.15).
Slika 11.15. Primjer univerzalnog modula za tabelarnu obradu.
200
Primjer: Univerzalni modul za pojedinanu obradu sadri objekte za posluivanje

standardnih funkcija, te po jednu instancu objekata za prikaz/obradu podataka, koji se
prilikom aktiviranja modula dinamiki umnoavaju u skladu sa strukturom relacije.
Unaprijed se ugrauju pozivi standardnih procedura vezanih uz standardne funkcije, te
objekte za prikaz/obradu podataka (slika 11.16).
Slika 11.16. Primjer univerzalnog modula za pojedinanu obradu.
201
12. Implementacija informacionog sistema

12.1. Izrada sistema
Implementacija informacionog sistema podrazumjeva ugradnju novog, raunarom
podranog, sistema u poslovni sistem. Drugim rijeima, predstavlja izradu novog
sistema i isporuku tog sistema u eksploataciju, tj. svakodnevnu upotrebu.
Izrada IS, ukratko, se obavlja kroz slijedee faze: formiranje razvojnog tima i
dodjeljivanje odgovornosti lanovima tima, izgradnja i testiranje mrea (po potrebi),
izrada i provjera baze podataka, kreiranje baze podataka, odnosno transfer probnih
podataka i testiranje operacija nad podacima. Nakon kreiranja baze podataka vri se
instalacija i testiranje novih softverskih paketa (po potrebi), izrada detaljnog plana
programiranja, pisanje i testiranje novih programa i, na kraju, pisanje programske
dokumentacije.
12.2. Programiranje (kodiranje)

Programiranje (kodiranje) je pretvaranje detaljnog programskog opisa u stvarni
program, najee primjenom nekog formalnog programskog jezika. Runo kodiranje
je neizbjeno zbog veliine stvarnih problema i sloenosti procesa. Ovo kodiranje je
sporo i dugotrajno. Koriste se programski jezci visokog nivoa: jezici etvrte generacije
(4GL Fourth Generation Language), objektno zasnovani jezici (Object Based
Language), kao i objektno orijentisani jezici (Object Oriented Language). Poeljno je
da konkretni jezik uz prevodilac (compiler) ukljuuje interpretator (interpreter), te alat
za otkrivanje pogreaka (debugger). Automatsko kodiranje se koristi za generisanje
programskog koda, generisanje interfejsa, kao i generisanje sheme baze podataka.
Istovremeno koritenje razliitih programskih jezika, odnosno jezika razliitih
generacija, treba koristiti samo po potrebi, npr. kada se ele ukloniti neki nedostaci
osnovnog jezika kojim se obavlja razvoj (npr. 4GL + C).
Strukturirano programiranje (strukturno programiranje) je tehnika programiranja
koja podrazumijeva pristup odozgo prema dolje (top-down programming).
Upotrebljavaju se programske strukture: linijska (tj. blok naredbi sa jednim ulazom i
izlazom), uslovno grananje (npr. naredbe if, case/switch/select) i ponavljanje, tj.
programske petlje (sa uslovom na poetku, sa uslovom na kraju, sa unaprijed
poznatim brojem koraka). Kod strukturiranog programiranja treba izbjegavati
bezuslovne skokove (GOTO naredbe).
202
Proceduralno programiranje je nain programiranja koji omoguava da se

program definie kao skup programskih cjelina, poeljno takvih da se mogu ponovo
koristiti. Programska cjelina (unit) je skup programskih naredbi koje obavljaju jedan
zadatak ili jedan dio zadatka, npr. glavni program, potprogrami (procedure, funkcije).
Programski modul je skup logiki povezanih programskih cjelina. Uvoenje
programskog modula uslovljava pojavu modularnog programiranja. Komponenta je bilo
koji sastavni dio softvera. Uobiajeno se podrazumijevaju fizike cjeline.
12.3. Pristup programiranju

Monolitni pristup (build and fix) je dugotrajno kodiranje, a zatim niz ponavljanja
oblika provjera+ispravka. Odgaa otkrivanje problema (greaka u kodu i dizajnu).
Proslijeuje probleme u primjenu i odravanje.
Inkrementalni pristup (stupnjevito, postupno programiranje) je niz ponavljanja
oblika kodiranje+provjera+ispravka. Omoguava raniju provjeru i izdvajanje greaka,
raniju raspoloivost djelominih (nedovrenih) verzija programa, kao i ravnomjerniju
podjelu posla. Omoguava pristup odozgo prema dolje, odozdo prema gore, kao i
mjeoviti pristup.
Primjer: Inkrementalni pristup.
1. Izrauje se program ija je struktura prikazana slikom 12.1;
a
b
g
k
j
l
Slika 12.1. Inkrementalni pristup: struktura programa.

2. Prvo se kodiraju sve funkcije, a zatim se udruuju;
3. Pokretanje programa zavrava fatalnom grekom;
4. Problem: kako ustanoviti u kojoj funkciji se nalazi greka;
5. Rjeenje je u postupnom kodiranju i udruivanju funkcija. Prilikom izrade
funkcije koja poziva neke druge funkcije, pozvane funkcije se kodiraju kao
203
odresci ili okrajci (stub), tako da je tijelo funkcije prazno ili sadri poruku (Tu
sam B):
Funkcija A ()
poziv B()
Funkcija B()
ispis "Tu sam B"
Prilikom izrade funkcije koja e biti pozvana iz neke druge, jo neugraene
funkcije, izrauje se pogonska funkcija (driver):
Funkcija M (a, b, c, )
Program DriverM
poziv M (1, "test", 3.14, )
Programiranje od vrha prema dolje (Top-Down). Ako funkcija fGornja poziva
funkciju fDonja, onda se fGornja kodira i integrie prije fDonja. Mogui redoslijed
kodiranja: abcdefghijklm, pisanjem odrezaka (npr. bcd za a).
Alternativni redoslijed je a+beh+cdfi+gjklm. Nakon to je funkcija a napravljena i
provjerena, jedan programer izrauje beh, a drugi istovremeno radi cdfi. Nakon to su
zavreni d i odrezak f, trei programer zapoinje gjklm (slika 12.2).
Prednost ovog pristupa programiranju je bolja provjera logikih funkcija (na viem
nivou hijerarhije, u kojima se donose odluke), odnosno bre otkrivanje logikih greaka
i manji utroak odrezaka. Nedostatak je nedovoljna provjera operativnih funkcija (na
niim nivoima obavljaju stvarni posao).
a
b
g
k
j
l
Slika 12.2. Programiranje od vrha prema dolje.

Programiranje od dna prema gore (Bottom-Up). Ako se funkcija fDonja poziva iz
funkcije fGornja, onda se fDonja izrauje prije fGornja. Redoslijed kodiranja je
lmhijkefgbcda (slika 12.3): prvi programer radi heb, drugi programer radi ifc i trei
programer radi lmjkgd. Nakon to su zavrene b, c i d, pristupa se konanom
udruivanju.
204
Prednost ovog pristupa programiranju je bolja provjera operativnih funkcija i manji

utroak pogonskog koda. Nedostatak je kasno otkrivanje logikih greaka.
a
b
g
k
j
m
Slika 12.3. Programiranje od dna prema gore.

Mjeoviti (sandwich) pristup. Prvo se od vrha prema dolje izrauju logike
funkcije, npr. abcdgj. Zatim se od dna prema gore rade operativne funkcije, npr.
efhiklm (slika 12.4).
Prednost ovog pristupa programiranju je rano otkrivanje logikih greaka uz bolju
provjeru operativnih funkcija.
a
b
g
j
l
k
m
Slika 12.4. Mjeoviti pristup.
12.4. Programski standardi i preporuke

Poveanje itljivosti programa se ostvaruje: standardizacijom naziva,
programskim komentarima, tehnikom i stilom programiranja, razliitim oznaavanjem
pojedinih elemenata jezika, kao to su rezervisane rijei, identifikatori, komentari,
opcije prevodilaca (razliita boja ili "veliina" znakova), koritenjem predefinisanih
simbolikih oznaka i konstanti. Takoe je potrebno izbjegavanje programskih redova
205
koji duinom prelaze irinu ekranske forme, pisanje jedne programske naredbe u redu,
podjela nizova naredbi na odsjeke koji su u cjelini vidljivi na ekranskoj formi,
formatiranje izvornog koda, odnosno pomicanje u desnu stranu naredbi unutar
programskih struktura, tzv. "uvlaenje".
12.4.1. Smjernice za nazive

Nazivi struktura podataka treba da budu pisani u skladu sa slijedeim
preporukama:
1. Davati nazive iz kojih se vidi na ta se odnose, npr. Osoba.SifraOsobe,
Mjesto.SifraMjesta, umjesto: Osoba.Sifra, Mjesto.Sifra, Artikl.Sifra;
2. Izbjegavati upotrebu posebnih znakova koje sintaksa jezika/sistema ne
dozvoljava pri oznaavanju identifikatora, npr. operatori i znakovi kao to su:
Dat-Ro;
3. Izbjegavati prekratke nazive koji, osim u neitkost, vode u nedoslijednost ve
pri prvoj pojavi iste skraenice za razliiti pojam, npr. SifMje za Mjeru i Mjesto;
4. Izbjegavati preduge nazive, npr. Redni_broj_stavke_kalkulacije, zbog
smanjenja itljivosti, produktivnosti runog kodiranja (pojava sintaksnih
greaka izazvanih grekama u pisanju produava vrijeme ispravljanja i
prevoenja) i moguih ogranienja jezika. Duina identifikatora treba da je do
18 znakova;
5. Izbjegavati nazive dobijene rutinskim spajanjem naziva entiteta i atributa, jer
mogu djelovati nezgrapno unutar upita, npr. umjesto SELECT Posao.* FROM
Posao WHERE Posao.posao_datum bolje je SELECT Posao.* FROM
Posao WHERE Posao.DatPosla ;
6. Koristiti nazive koji se daju izgovoriti, npr. Nstvnk.SifNstvnk ... bolje je
Nastav.SifNastav ili Nastavnik.Sif Nastavnika.
Nazivi programskih varijabli treba da budu pisani u skladu sa slijedeim
preporukama:
1. Koristiti smislene nazive, odnosno izbjegavati "jednoslovne" varijable, npr. i, j,
k ili i, ii, iii, ili, x1, x2, x3, osim za indekse i dimenzije polja: i, n;
2. Nazive odabirati u skladu sa znaenjem sadraja, npr. max za najveu
vrijednost ili len za varijablu koja odreuje duinu;
3. Koristiti standardne prefikse/sufikse za srodne elemente/objekte, npr.
frmOsoba ili fOsoba za ekransku formu, repOsoba, rOsoba za izvjetaje;
4. Koristiti skraenice optih pojmova kao to su: broj, redni broj, ifra,
skraenica, oznaka, datum respektivno br, rbr, sif, skr, ozn, dat;
206
5. Razlikovati nazive globalnih i lokalnih varijabli, te formalnih argumenata koji se

odnose na isti pojam, ime se olakava snalaenje u programskom kodu i
uklanja mogua "neodreenost" sadraja, npr. gCount, sCount, lCount,
aCount.
Standardizacija naziva. Dodjeljivanje naziva objektima modela podataka
odraava se na nazive programskih varijabli. O tome treba voditi rauna ve prilikom
oblikovanja baze podataka. Poeljno je oblikovanje obaviti takvim alatom za
modeliranje, koji osim stvarnih naziva ima mogunost evidentiranja kodova koji e se
koristiti prilikom stvaranja objekata BP. Preporuuje se upotreba razliitih notacija, kao
to su: koritenje velikih i malih slova (BrojCipela), umetanje podcrte izmeu dijelova
od kojih je sastavljen pojam (broj_cipela) ili kombinovanje spomenutih notacija.
Primjeri: PascalCase, koji se koristi kod imenovanja prostora: imena, klasa,
interfejsa, pobrojanih tipova, postupaka i svojstava, static, public ili protected atributa,
zahtjeva da poetno slovo svake rijei u imenu bude veliko slovo, npr. BackColor.
Identifikator klase moe zapoeti znakom @. Dok, sa druge strane, camelCase, koji se
koristi kod zatienih atributa i lokalnih varijabli postupaka, zahtjeva da poetno slovo
prve rijei u imenu bude malo slovo, poetna slova ostalih rijei u imenu su velika
slova, npr. backColor.
Preporuke, kojih se treba pridravati: imena interfejsa uobiajeno zapoinju
slovom I, koristiti imenice za imena klasa i koristiti glagole za imena postupaka.
12.4.2. Smjernice za komentare

Programski komentari treba da budu aurni, tj. da odgovaraju stvarnom stanju. Ne
pretjerivati u pisanju komentara. Lo kd je bolje ponovo napisati, nego (bezuspjeno)
pojanjavati. Komentarisati smisao naredbi (izbjegavati prepriavanje").
Primjer: Komentar u zaglavlju potprograma.
'***************************************************************
'Function : FormatField
'Purpose :
Formats a field
'Arguments:
'
Col Index of field
'
Value Value to format
'Returns :
True if successful
'Created :
I.Ras, A.Kos, 24.08.05
'Modified : I.Ras, A.Kos, 22.09.05
'***************************************************************
Function FormatField(Col As Integer, Value As String) As Integer
Primjer: Komentar u zaglavlju modula.

'***************************************************************
'Module:
dh69libClient - C:\VbProjs\dh69cd\dh69libClient.bas
'Purpose: Client Library - Transfer related
'Modified: 14.02.2005 by N
'***************************************************************
'Public
Method
TestTransfer
'Public
Method
SetConnectVars
'Public
Method
ErrExportImport
'...
'Public
Const
EXCHANGEINPROGRESS
'Public
Const
CHECKSYSTEMDATE
'Public
Const
TRYTOEXCHANGELATER
'...
'Public
Variable ImmediateTransfer
'...
'Public
Const
FTP_APPDIR
'Public
Const
FTP_DIR
'...
'***************************************************************
Primjer: Komentar programskog redoslijeda i komentar naredbi.

hFile = FtpFindFirstFileA(hservice, RemoteFileName, FindData, 0, 0)
If hFile = 0 Then
'15.06.2005 by K
'enum FTP files to compare Case-Insensitive
Dim bFile As Long, FoundFile As String
FindData.cFileName = String(MAX_PATH, 0)
hFile = FtpFindFirstFileA(hservice, "*.*", FindData, 0, 0)
If hFile = 0 Then Exit Function 'empty directory, 05.03.2006 by K
Primjer: Blok komentar.

'#'Block Out 22.09.2005 by J
'#'Ellerman - "already changed by" request
'@
'reset Status and Flags for imported ads
'@
SQL = "UPDATE AD SET NewStatus=Status, NewCDFlag=CDFlag, " & _
'@
"NewNPFlag=NPFlag, UpdatedOnServer=True"
'@
If MinImportedAdSN > 0 Then
'@
SQL = SQL & " WHERE Ad.SN > " & MinImportedAdSN
'@
End If
'@
daoExecute SQL, IIf(QuietMode, "", "Updating local flags...")
'#'End Block Out 22.09.2005 by J
207
208
12.4.3. Programske preporuke

Na poetku izrade treba uspostaviti standarde kodiranja, a zatim odabrani stil
doslijedno primjenjivati! Tehnika i stil programiranja zahtjevaju:
eksplicitno deklarisati programske varijable,
izbjegavati programske varijable opteg tipa,
postaviti poetne vrijednosti varijabli prije upotrebe,
ugraditi podrazumijevane vrijednosti ulaznih podataka,
provjeravati zahtijeve za ulaznim podacima i valjanost ulaznih podataka,
doslijedno formatirati podatke,
olakati ispravljanje neispravnih ulaznih podataka,
pripaziti na granine vrijednosti podataka, naroito indeksiranih varijabli ... ,
provjeriti mogue numerike greke (10.0 * 0.1 nije uvijek 1.0),
izbjegavati poreenje na jednakost brojeva sa pominim zarezom,
koristiti zagrade radi naglaavanja redoslijeda izraunavanja izraza,
presloiti i pojednostaviti nerazumljive izraze,
izbjegavati nepotrebna grananja,
izbjegavati trikove (ne rtvovati jasnou radi "efikasnosti"),
ponavljajue blokove i izraze zamijeniti potprogramima,
rekurziju koristiti samo za rekurzivne strukture podataka,
prvo napraviti jasno i ispravno rjeenje, a zatim brzo rjeenje,
neefikasan kd ne usavravati, nego nai bolji algoritam,
rutinski posao i jednostavnu optimizaciju prepustiti prevodiocu,
nakon pronaene i ispravljene greke provjeriti imali ih jo,
lo kd bolje je napisati ponovno, nego ga popravljati ("krpiti"),
nedovoljno opta rjeenja bolje je reorganizovati, nego ih prilagoavati radi
viekratnog koritenja,
kodirati sa osloncem na programske prirunike.
Programski prirunici. Prije poetka kodiranja treba pripremiti programske
prirunike sa funkcijama grupisanim po namjeni. Tu spadaju funkcije za rad sa optim
tipovima podataka (npr. nizovi znakova i datumi), funkcije za rad sa podacima u bazi
podataka (npr. funkcije za upravljanje transakcijama i provjeru statusa izvedenih upita),
funkcije interfejsa (npr. sistem izbora, poruka i pomoi), funkcije za odravanje baze
podataka (npr. provjera konzistentnosti podataka i izrada rezervnih kopija), funkcije za
administriranje vanjskih ureaja (npr. terminali i pisai), kao i programski dio sistema
zatite (npr. definiranje programskih modula, funkcija i korisnika, te rukovanje pravima
pristupa programima i podacima).
Grupisanje funkcija interfejsa, te poruka i tekstova pomoi, pomae kod promjene
kodne stranice ili u sluaju potrebe za prevodom na neki drugi jezik, kada sve tekstove
treba odjednom mijenjati.
209
12.5. Provjera ispravnosti informacionog sistema

12.5.1. Cilj testiranja sistema
Provjera ispravnosti informacionog sistema, odnosno testiranja na greke i
ispitivanja programa, su uspjeni kada se dokae postojanje greaka.
Testiranje programa (provjera, ispitivanje programa). Provjera programa se vri
izvoenjem, uz uporabu ispitnih podataka, te analizom rezultata obrade. Testiranje i
ispravljanje greaka se mora obavljati redoslijedom kojim su moduli kodirani,
uobiajeno sa vrha prema dolje. Cilj testiranja na greke je utvrivanje greaka,
odnosno nedostataka unutar programa.
Nain provjere moe biti strukturalni i funkcionalni. Kod strukturalnog naina
provjere se provjerava kako cjelina radi. Probni sluajevi se izvode uvidom u
programski kd (inspekcija koda). Ovu provjeru provode programeri. Funkcionalni
nain provjere provjerava to cjelina radi, to jest da li zadovoljava postavljene zahtjeve.
Probni sluajevi se izvode iz specifikacija funkcija. Ovu provjeru provodi osoblje
proizvoaa ili korisnici.
Verifikacija (ovjera ispravnosti) je dokazivanje da je faza dobro provedena ili da je
proizvod dobro napravljen, tj. da odgovara specifikaciji zahtjeva.
Validacija (potvrda valjanosti), kojom se utvruje da je napravljen pravi proizvod,
koji odgovara korisniku i namjeni.
12.5.2. Vrste testiranja sistema

Testiranje ostataka je testiranje upravljakih struktura i vrijednosti sadranih u
kodu. Vri se ispitivanje pojedinanih cjelina (proceduralno programiranje). Nedovreni
elementi mogu se simulirati (ostaci i pogonski moduli).
Testiranje komponenti je ispitivanje pojedinih programskih komponenti.
Ispitivanje provodi programer komponente (postoje iznimke za kritine sisteme).
Testovi proizilaze iz iskustva te osobe.
Integraciona provjera je ispitivanje grupa komponenti koje integrisane ine cijeli
sistem ili neki njegov dio. Vre se slijedee provjere: test korisnikog interfejsa
(provjera svake funkcije interfejsa), test sluajeva koritenja (provjera svakog
pojedinanog sluaja), test toka podataka (provjera procesa korak-po-korak) i test
interfejsa sistema (provjera prenosa podataka izmeu sistema). Ispitivanje provodi
nezavisni tim za testiranje. Testovi su zasnovani na specifikaciji sistema.
Provjera sistema, odnosno provjera rada sistema kao cjeline, kojom se osigurava
da svi nezavisno razvijeni aplikativni programi rade ispravno u skladu sa
specifikacijama. Vre se slijedee provjere: funkcionalno testiranje (gdje se vri
210
provjera funkcionalnosti prema zahtjevima korisnika), testiranje performansi i testiranje

dokumentacije (tj. provjera korisnike dokumentacije i primjera). Testiranje performansi
(odnosno provjeru nefunkcionalnih zahtjeva) sainjavaju:
stress - verifikacija velikog broja simultanih pristupa,

volume - test na koliinu podataka, sloenost algoritama, fragmentaciju, ...,
security - provjera prava pristupa,
timing - brzina odziva,
recovery - mogunost oporavka pri forsiranom padu sistema.
Test prihvatljivosti je test sistema kojim se dokazuje da proizvod zadovoljava

korisnike zahtjeve i potrebe organizacije, te uslove pod kojima ga je naruilac
spreman preuzeti. To je sveobuhvatni i konani test sa stvarnim podacima.
Alfa-testiranje je verifikaciono testiranje. Sastoji se od probne upotrebe sistema, a
provode ga korisnici kod izvoaa. Vri se simulacija stvarnog okruenja, traenje
greaka i propusta.
Beta-testiranje je validaciono testiranje. Testiranje provode korisnici kod sebe, bez
prisustva izvoaa. Provjera se vri u stvarnim uslovima. Provjeravaju se performanse
sistema, vrna optereenja, upotrebljivost i lakoa upotrebe metoda i procedura, izrada
rezervnih kopija i oporavak sistema.
Nadzorni test se provodi prema potrebi. Predstavlja potvrdu da je sistem gotov,
ispravan i spreman za primjenu. Ovaj test provode nezavisne institucije za
osiguravanje kvaliteta.
12.5.3. Plan testiranja sistema

Testiranje mora biti sistemsko, prema unaprijed napravljenom planu, koji sadri:
identifikator programa ili dijela obrade (npr. naziv opcije sistema za ekransku formu),
naziv funkcije (npr. unos ili izmjena), vrstu preduzete akcije (npr. potvrda pohrane ili
prekid obrade), identifikator ili opis podatka koji se eli obraditi, ponaanje programa
(npr. neregularni zavretak rada, neispravni podaci, pogrean prikaz podataka), a po
potrebi i oekivani rezultat.
Preporuke za provjeru, u kojoj uestvuju poznati korisnici, su slijedee. Provjeru
obavlja ogledna skupina krajnjih korisnika koja, koristei napravljena rjeenja, nastoji
obaviti svoje svakodnevne poslove. Po elji krajnji korisnik dodatno iznosi svoja
zapaanja ili prijedloge. Primjedbe se prikupljaju dnevno, a greke uklanjaju po
mogunosti istog dana. Prikupljeni dodatni zahtjevi se procjenjuju, te se izrauje lista
prioriteta ugradnje. Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova
naknadna ugradnja.
211
12.6. Izrada dokumentacije

12.6.1. Dokumentovanje razvoja
Projektna dokumentacija treba da dokumentuje razvoj IS, kao i proizvode
pojedinih faza razvoja. Dokumentaciju po IEEE standardu sainjavaju:
1. Plan validacije i verifikacije softvera - Software Validation and Verification Plan
(SVVP);
2. Plan garancije kvaliteta softvera - Software Quality Assurance Plan (SQAP);
3. Plan softverskog upravljanja
Management Plan (SCMP);
konfiguracijom
Software
Configuration
4. Plan upravljanja softverskim projektom - Software Project Management Plan

(SPMP);
5. Specifikacija softverskih zahtjeva - Software Requirements Specification
(SRS);
6. Document za softverski dizajn - Software Design Document (SDD);
7. Izvorni kod (Source code);
8. Dokumentacija softverskog testa - Software Test Documentation (STD);
9. Korisniko uputstvo (User's manual).
Korisnika dokumentacija mora pruiti pomo korisnicima pri upotrebi sistema i
mora biti prilagoena korisnicima razliitog iskustva. Tu spadaju: upute za upotrebu
(user manual), instalacioni prirunik (installations manual), detaljni prirunik (reference
manual), upute za vjebu (training guide, tutorial), podsjetnici ili kratke upute (quick
reference guide, pocket guide, cue cards). Broj, vrsta i obim dokumenata zavisi o
aplikaciji.
Tehnika dokumentacija je namijenjena tehnikom osoblju. Potrebna je za
razumijevanje, izradu i odravanje sistema. Omoguava upravljanje projektom i
konfiguracijom sistema, budui da sadri plan razvoja, specifikaciju dizajna, opis
arhitekture sistema i specifikaciju interfejsa prema drugim sistemima.
Pored
navedenog,
tehniku
dokumentaciju
sainjavaju:
programska
dokumentacija (izvorni kd, opis baze podataka, probni podaci i rezultati provjere,
dnevnik promjena i programski prirunici), instalacioni prirunik (odnosno opis
instalacione procedure) i upute za rukovanje i odravanje (opis procedura za
pokretanje/zaustavljanje - startup/shutdown, opis izrade rezervnih kopija i vraanja
podataka - backup, restore, opis postupka ponovnog pokretanja i oporavka - restart,
recovery).
212
12.6.2. Preporuke za izradu dokumentacije

Izrada dokumentacije zahtijeva angaovanje i do nekoliko sati (3) po stranici. Mora
biti planirana i zapoeti izradu dovoljno rano, prije zavretka kodiranja i testiranja. Prije
objavljivanja dokumentacije treba provjeriti/dokazati da odgovara namjeni. Prilikom
izrade treba izbjegavati ponavljanja i neodreenosti i koristiti standardizovane
dokumente.
Izmeu ostalog, dobra dokumentacija mora biti napisana sa gledita itaoca, a ne
pisca, ta podrazumjeva konzistentnost pojmova, jednostavnost izraza, kratka
poglavlja. Dokumentacija mora biti dobro ilustrovana (slikama ekranskih formi i
njihovog redoslijeda), opisivati postupak rada, a ne samo sadraj ekranske forme (npr.
redoslijed popunjavanja ifarnika, odreivanje lozinki i prava pristupa, radne
procedure). Takoe, mora biljeiti naela (argumente odluka), odraavati stvarno
stanje opreme u primjeni (tj. biti aurna) i ukljuivati rjenik koritenih izraza.
Nepostojanje dokumentacije moe biti razlog za prestanak koritenja aplikacija,
naroito kada autor ili autori prestanu biti raspoloivi.
Preporuuje se odvojeno uvati odgovarajuu varijantu programske opreme
(alata) kojom je proizvod napravljen.
213
13. Logiko projektovanje programa i programski jezici

13.1. Dijagram toka (blok dijagram, algoritam)
Dijagrami toka (Flowcharts) omoguavaju grafiki prikaz sistema (system
flowchart) i predstavljaju zamjenu za fizike DTP, kao i grafiki prikaz programa
(program flowchart). Osim toga, dijagrami toka su usredotoeni na akcije koje
sistem/program mora obaviti.
Specifikaciju predstavlja skup simbola koji opisuju upravljaki tok. Za opis akcije ili
odluke unutar simbola moe se primijeniti bilo koja notacija, npr. pseudokod ili prirodni
jezik. Nedostaci dijagrama toka su veliki skup simbola, veliki i neprikladni dijagrami,
nedostatak formalizma, nemogunost opisa struktura podataka, nestrukturiranost,
dozvola skokova koji vode upotrebi GOTO naredbe, ali ipak predstavlja tehniku koja
(nikako ne) izlazi iz upotrebe.
Primjer 1:
Slika 13.1. Primjer dijagrama toka.
214
Primjer 2:
POETAK
Pripremne radnje
Spojite tokova
Uitav.podat.
Obrada podat.
Izlaz podat.
NE
Kontrola izlaza
iz petlje
Kraj
obrade
DA
Zavrne radnje
KRAJ
Slika 13.2. Primjer opteg oblika dijagrama toka.

Primjer 3:
Prodaja
Slika 13.3. Dijagram toka Prodaja (generator dijagrama toka Visio).
Primjer 4:
Slika 13.4. Simboli dijagrama toka.

Primjer 5:
Slika 13.5.Ekranska forma generatora dijagrama toka Code Visual

to Flowchart V3.5 (2006).
215
216
13.2. Strukturirani prirodni jezik (pseudokod)

Pseudokod je srodan viim programskim jezicima, ali ne sadri formalna pravila
jezike sintakse ni jednog od njih. Predstavlja nain opisa logikog toka algoritma
programa. Pseudokod je prilagoen strukturiranom nainu programiranja i otuda potiu
njegova osnovna sintaksna pravila. Za potrebe ovog teksta, prilagoen je naem
govornom podruju. Pri definisanju sintakse i semantike ovog pseudokoda, polo se
od slijedeih zahtjeva:
svaki element pseudokoda mora biti jednoznano definisan,
elementi pseudokoda moraju biti razumljivi itaocu, koji poznaje osnovna
pravila pisanja algoritma,
elementi algoritma ne smiju posjedovati specifinosti nekog programskog
jezika, koji se ne mogu lako izraziti putem naredbi nekog drugog programskog
jezika opte namjene,
elementi pseudokoda moraju biti tako definisani da se mogu lako prevesti na
veinu programskih jezika opte namjene,
pseudokod mora posjedovati naredbe za rad sa datotekama na eksternom
memorijskom ureaju.
Sintaksa i semantika osnovnih elemenata i osnovnih struktura pseudokoda, kao i
pravila za konstruisanje procesa i naredbe pseudokoda, specifine za rad sa
datotekama, su opisani u nastavku teksta..
13.2.1. Osnovni elementi pseudokoda

Osnovne elemente pseudokoda sainjavaju:
promjenljive,
glagoli,
operator dodjele,
aritmetiki i algebarski operatori,
komentari.
Promjenljive i njihovi tipovi se u pseudokodu posebno ne deklariu. Ako to ne

proizilazi iz njihovog naziva, opisuju se u okviru komentara. Piu se italic slovima,
nisu ograniene duinom, a ako se sastoji od vie rijei povezuju se podcrtom (_),
npr. p.
Glagoli: Svaka imperativna naredba pseudokoda poinje glagolom. Taj glagol se
pie velikim slovima, npr. POSTAVI.
217
Operator dodjele: Naredba dodjele vrijednosti promjenljivoj posjeduje dvije

komponente. To su glagol POSTAVI i strelica , koja predstavlja operator dodjele.
Naredba ima oblik:
POSTAVI p i,
gdje je p promjenljiva, kojoj se dodjeljuje vrijednost, a i neki izraz. Nakon realizacije
naredbe dodjele, promjenljiva p posjeduje vrijednost izraza i.
Aritmetiki i algebarski operatori: Aritmetiki, skupovni, logiki i relacioni
operatori se, u naredbama pseudokoda, koriste na uobiajen nain.
Komentar u pseudokodu ima slijedeu sintaksu:
( * tekst komentara * ),
gdje ( * oznaava poetak, a *) kraj komentara. Sam tekst komentara je niz
alfanumerikih znakova, koji ne smije sadravati oznake za poetak ili kraj komentara.
Primjer:
( * ovo je ispravan komentar * )
( * ovo je neispravan komentar ( ** )
( *********************************
ovo je ispravan komentar
*********************************** ).
13.2.2. Osnovne strukture pseudokoda

Osnovne strukture strukturiranog naina pisanja algoritma, predstavljaju i osnovne
strukture pseudokoda. To su sekvenca (linijska struktura), selekcija (razgranata
struktura) i iteracija (ciklina struktura).
Sekvenca je osnovni oblik strukturiranja algoritma. Predstavlja linearnu strukturu
nad skupom aktivnosti. Aktivnost je naredba pseudokoda ili struktura nad skupom
naredbi pseudokoda. Svaka aktivnost sekvence se pie u novom redu i poinje od iste
kolone. Sekvencom se opisuje niz aktivnosti, koje se bezuslovno odvijaju jedna za
drugom. Redoslijed izvravanja aktivnosti je odreen redoslijedom njihovog navoenja
u pseudokodu.
Na slici 13.6 je prikazana sekvenca, od tri aktivnosti u pseudokodu, i odgovarajui
blok dijagram. Svaka aktivnost poinje glagolom u imperativnom obliku (IZVRI),
mada aktivnost moe predstavljati i svaku od osnovnih struktura pseudokoda ili pak
strukturu nad skupom osnovnih struktura. U svakom sluaju, izvrenju aktivnosti C
mora prethoditi izvrenje aktivnosti B, a izvrenju aktivnosti B mora prethoditi izvrenje
aktivnosti A.
218
PSEUDOKOD:
BLOK DIJAGRAM
A
IZVRI A
IZVRI B
IZVRI C
B
C
Slika 13.6. Pseudokod i blok dijagram sekvence.

Selekcija je osnovna struktura koja slui za prikaz uslovnog grananja u
algoritmima. Semantika ove strukture se moe opisati na slijedei nain. Ako je
zadovoljen uslov P, tada se izvrava aktivnost A, inae se izvrava aktivnost B. Na slici
13.7 je prikazana sintaksa pseudokoda i blok dijagram selekcije. U sintaksi selekcije se
za svako AKO JE uslov TADA, pie INAE i jedno KRAJ AKO, poevi od iste
kolone kao AKO .
PSEUDOKOD:
BLOK DIJAGRAM
AKO JE P TADA
IZVRI A
INAE
IZVRI B
KRAJ AKO
da
P
A
Slika 13.7. Pseudokod i blok dijagram selekcije.

Primjer: Neka je a promjenljiva ija je trenutna vrijednost 0. Tada e promjenljiva
a imati vrijednost 1, nakon izvrenja selekcije:
AKO JE a 0 TADA
POSTAVI a a+1
INAE
POSTAVI a a-1
KRAJ AKO
219
Da je inicijalna vrijednost promjenljive a bila 1, nakon izvrenja selekcije bi imala

vrijednost a = 0.
Iteracija RADI DOK JE je algoritamska struktura u kojoj se aktivnost A
ponovljeno izvrava tako dugo dok je postavljeni uslov P zadovoljen. Svaka iteracija
ima svoje ime. Poinje glagolom RADI, a zavrava se frazom KRAJ RADI, koja se
pie od iste kolone kao i RADI.
Kada je rije o iteraciji tipa RADI DOK JE, za nju je specifino da ukoliko uslov P
nije zadovoljen kod prvog ispitivanja, aktivnost A se uopte ne izvodi. Na slici 13.8 je
prikazana sintaksa pseudokoda i blok dijagram iteracije tipa RADI DOK JE.
PSEUDOKOD:
BLOK DIJAGRAM
RADI naziv_radi DOK JE P

IZVRI A
KRAJ RADI naziv_radi
A
da
P
Slika 13.8. Pseudokod i blok dijagram iteracije RADI DOK JE.

Primjer: Neka je n = 10, tada se oduzimanje u iteraciji:
RADI oduzimanje_od_n DOK JE n > 1
POSTAVI n n - 1
KRAJ RADI oduzimanje_od_n
izvrava 9 puta. Da je, inicijalno , bilo n 1, tada se oduzimanje ni jedan put ne bi
izvrilo.
Iteracija RADI DOK NE BUDE je iteracija kod koje se, za razliku od iteracije
tipa RADI DOK JE, aktivnost A izvrava prije ispitivanja postavljenog uslova P.
Aktivnost A e se sigurno izvriti bar jedan put, bez obzira na ispunjenje uslova P.
Aktivnost A se izvrava tako dugo dok ne bude zadovoljen uslov P. Na slici 13.9 je
prikazana sintaksa pseudokoda i blok dijagram iteracije RADI DOK NE BUDE.
220
PSEUDOKOD:
RADI naziv_radi DOK NE BUDE P

IZVRI A
KRAJ RADI naziv_radi
BLOK DIJAGRAM
A
P
da
Slika 13.9. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE.

Primjer: Neka je n = 10, tada se oduzimanje u iteraciji:
RADI oduzimanje_od_n DOK NE BUDE n = 1
POSTAVI n n - 1
KRAJ RADI oduzimanje_od_n
izvrava 9 puta. Da je, inicijalno bilo n 1, tada uslov za izlazak iz iteracije ne bi nikada
bio zadovoljen.
Mogue oznake za pisanje pseudokoda:
Abc
abc
Abc
:=
#
"
s
v
M
IvI
&
Si
I&I
naziv algoritma
rezervisana rije pseudokoda za opis algoritama
ugraena ili trivijalna funkcija (procedura)
pridruivanje
zamjena vrijednosti
komentar
konstanta ili parametar
skalar
vektor
matrica
nula-vektor
modul (duina) vektora
skup
element skupa
kardinalni broj skupa
prazan skup
221
13.3. Akcioni dijagram

Akcioni dijagram (Action Diagram) je formalizovana mjeavina strukturiranog
prirodnog jezika i pseudokoda. Na slici 13.10 je prikazan primjer prikazivanja procesa
pomou akcionog dijagrama. Koriste se kod rada sa generatorima aplikacija (slika
13.11).
Slika 13.10. Primjer akcionog dijagrama za rad sa generatorom aplikacija

Advantage:Plex.
Slika 13.11. Ekranska forma generatora aplikacija Advantage:Plex.
222
13.4. Stablo odluivanja

Stablo odluivanja (Decision Tree) je binarno stablo u kojem svaki nezavrni vor
predstavlja odluku koja se donosi u tom voru. Zavisno o donijetoj odluci tok programa
prenosi se u podstablo vora. List reprezentuje rezultat niza odluka na putu od korijena
do tog lista. Stablo odluivanja je prikladno za opis sloenih grananja u postupku
odluivanja. Lako je razumljivo i predstavlja dobro sredstvo za komunikaciju sa
korisnicima.
Primjer: Posjeta zoolokom vrtu ivotinje.
ulaz za djecu do 3 godine je besplatan,

omladina do 18 godina plaa polovinu pune cijene ulaznice,
djeca ispod 12 godina u pratnji odrase osobe plaaju etvrtinu cijene,
osobe iznad 18 godina plaaju punu cijenu, osim ako su studenti ili penzioneri,
koji plaaju polovinu cijene,
posjetioci u grupi imaju 10% popusta na punu cijenu,
studentski popust ne vrijedi vikendom.
Stablo odluivanja za navedeni primjer izgleda kao na slici 13.12.
Slika 13.12. Primjer stabla odluivanja za zooloki vrt ivotinje.

Moe se uspostaviti veza izmeu stabla odluivanja i pseudokoda. Na slici 13.13
je prikazano stablo odluivanja za Videoteku i na slici 13.14 pripadajui pseudokod.
Kategorija filma:
Ukupni broj filmova

koje lan eli iznajmiti:
Hit film
bilo koliko
Politika
iznajmljivanja
filmova:
Obian film
223
Rok za vraanje
posuenog filma:
1 dan
manje od 3
1 dan
3-6
3 dana
vie od 6
3 dana
Slika 13.13. Primjer stabla odluivanja za Videoteku.

cijena = 0
ako je hit film tada
rok iznajmljivanja
= 1 dan
Slika 14.13.
Primjer pseudokoda za Videoteku.
cijena = cijena + (osnovna cijena filma x 1,5)

inae
ako je ukupni broj filmova manji od 3 tada
rok iznajmljivanja = 1 dan
cijena = cijena + osnovna cijena filma
inae
ako je ukupni broj filmova manji od 7
rok iznajmljivanja = 3 dana
inae
rok iznajmljivanja = 7 dana
ako film nije trei po redu (svaki trei obini film je besplatan) tada
Slika 13.14. Primjer pseudokoda za Videoteku.
224
13.5. Tabele odluivanja

Tabele odluivanja (Decision Tables) predstavljaju tabelarni prikaz preslikavanja
skupa ulaznih uslova u skup izlaznih akcija. Posjeduju relativno jednostavne uslove,
kao i ograniene skupove moguih odgovora, npr. da/ne ili nisko/srednje/visoko.
Neki CASE alati, koji podravaju ovaj nain izrade specifikacija, generiu
programski kd razliitih jezika (npr. C, Pascal, Fortran i Basic). Predstavljaju dobro
sredstvo za opis poslovnog odluivanja.
Primjer: Proirena tabela odluivanja za zooloki vrt ivotinje.
Tabela 13.1.
Uslovi
(condition stub)
Dob
Pratnja
Student
Vikend
Grupa
Ispunjenost uslova (condition entries)

<3
3-12
D
3-12
N
Akcije
(action stub)
Slobodan ulaz
etvrtina cijene
Polovina cijene
90% cijene
Puna cijena
12-18
>18
>18
>18
>18
>18
D
N
D
D
D
D
D
N
PEN
Izbor akcije (action entries)

X
X
X
X
X
X
X
13.5.1. Pravila izrade tabela odluivanja

Prilikom izrade tabela odluivanja preporuuje se koristiti slijedea pravila:
1. Logika odluivanja treba da bude nezavisna o tome kojim redoslijedom su
uslovi napisani;
2. Meutim, nije uvijek svejedno kojim su redoslijedom napisane akcije;
3. Potrebno je izbjegavati eventualno dupliranje izraza i znaenja;
4. U gornjem dijelu tabele treba pokuati rasporediti redove tako da oni redovi
koji sadre vie potvrda uslova (znak Y) budu to vie, dok oni koji sadre
oznake "-" budu nie;
5. Kolone u desnom dijelu tabele treba rasporediti tako da u istom redu oznake "" budu ispred oznaka Y, a ove ispred znakova N.
225
Primjer: Proirena tabela odluivanja za Videoteku.

Tabela 13.2.
Politika iznajmljivanja filmova
hit film
ukupni broj filmova vei od 6
ukupni broj filmova 3 - 6
ukupni broj filmova manji od 3
film je trei po redu
X
X
X
X
Akcije
rok iznajmljivanja je 7 dana
rok iznajmljivanja je 3 dana
rok iznajmljivanja je 1 dan
cijena = cijena + (osn. cijena filma x 1,5)
X
X
X
X
X
13.6. Struktogram
Struktogram (Nassi-Shneiderman Chart) je grafiki prikaz programskih struktura.
Znatno je prikladniji od dijagrama toka. Neprikladan je za runu izradu, naroito kada
ga je potrebno esto mijenjati.
Osnovni elementi struktograma su prikazani na slici 13.15.
Sekvenca
Selekcija
Iteracija
Slika 13.15. Osnovni elementi struktograma.

Nassi-Shneiderman dijagrami su pogodni za reverzni inenjering programa
pisanih u C programskom jeziku i za generisanje koda.
Na slici 13.16 je prikazan Nassi-Shneiderman dijagram uraen pomou CASE
alata Xper-C.
226
Slika 13.16. Ekranska forma Nassi-Shneiderman dijagrama u CASE alatu XperC.
13.7. Programski jezici

13.7.1. Programski jezici tree generacije
Jezici tree generacije (eng. 3rd generation languages - 3GL) su jezici visokog
nivoa (HLL - High Level Languages), odnosno proceduralno usmjereni programski
jezici. Moe se izvriti podjela programskih jezika po namjeni.
Jezici za numerike i naune probleme:
FORTRAN (FORmula TRANslator), prvi raireniji jezik za rjeavanje
numerikih problema,
ALGOL (ALGOrithmic Language), jezik pogodan za rjeavanje numerikih i
logikih problema,
BASIC (Beginner's All-Purpose Symbolic Instruction Code), prvobitno
jednostavan interpretator za interaktivno rjeavanje numerikih problema,
kasnije se razvio u Visual Basic.
227
Jezik za poslovne probleme:

COBOL (COmmon Business Oriented Language), jezik prikladan za poslovne
aplikacije i rad sa podacima.
Jezik orijentisan listama i redovima:
LISP (LISt Processing), nastao sa namjerom da se razvije programski jezik
pogodan za probleme iz podruja vjetake inteligencije.
Jezik vjetake inteligencije:
PROLOG (PROgramming in LOGic), namjenjen logikom programiranju.
Vienamjenski jezici:
PL/I, pogodan za numeriko-inenjerske i poslovne aplikacije,
C, razvijen radi izrade operativnog sistema iz kojeg je nastao Unix, danas
predstavlja standard kada se radi o proceduralnom programiranju,
C++, C sa svojstvima objektnog programiranja,
Pascal, nastao sa namjerom da se napravi jezik koji se moe efikasno ugraditi
na veinu raunara, a koji e biti pogodan za uenje programiranja kao logike
i sistematske discipline,
ADA, pokuaj postavljanja standarda za jezik integrisanih raunarskih sistema
(kontrola industrijskih pogona, vazduhoplova ili bolnikih sistema),
Modula-2 i Oberon, proirenje Pascal-a podrkom sistemskom programiranju,
konceptom procesa i modula koji meusobno komuniciraju.
Veina dananjih 3GL su vienamjenski jezici.
13.7.2. Programski jezici etvrte generacije

Jezici etvrte generacije (eng. 4th generation languages - 4GL) su nastali krajem
'70-ih i poetkom '80-ih godina. Neki 4GL ini skup raznorodnih pomagala povezanih u
cjelinu sa okruenjem 4. generacije (4th Generation Environment). 4GL naredbe
integriu naredbe jezika visokog nivoa, te predstavljaju jezike vrlo visokog nivoa (Very
High Level Languages).
Programski jezici etvrte generacije predstavljaju jezike posebne namjene,
specijalizovane za odreene klase problema. Zadovoljavaju potrebe za izradu 60 80% svih aplikacija.
13.7.3. Vrste i primjena 4GL

Jezici za rad sa bazama podataka su strukturirani upitni jezici. Najee je u
upotrebi SQL (Structured Query Language). Za rad sa ovim jezikom u prednjem planu
se mora nalaziti Sistem za upravljanje bazom podataka - SUBP (DBMS - DataBase
Management System).
228
Podjezici SQL-a su:

1. Jezik za opis podataka (DDL - Data Definition Language), odnosno jezik za
definisanje sheme BP u rjeniku podataka (kreiranje objekata);
2. Jezik za rukovanje podacima (DML - Data Manipulation Language), za rad sa
podacima (postavljanje upita, unos, izmjena, brisanje);
3. Jezik za upravljanje podacima (DCL Data Control Language), za kontrolu
pristupa podatcima (dodjeljivanje i ukidanje prava pristupa).
Jezici etvrte generacije (4GL) kao programski jezici se koriste za pisanje
aplikacija nad bazom podataka.
Primjer: Strukturirani upitni jezik SQL se koristi u sistemima za upravljanje
slijedeim relacionim bazama podataka: DB2, Oracle, Informix, MS SQL Server, MS
Access i drugim.
Matrini kalkulatori (Spreadsheet) su tabele organizovane kao mrea redova i
kolona. Elementi tabele su: konstante, izrazi (formule), grafiki znakovi i objekti.
Elementi jezika su aritmetike i agregatne funkcije: SUM, COUNT, AVERAGE, MIN,
MAX , logiki izrazi: OR, IF, AND, NOT, matematike funkcije: SIN, COS, TAN,
ASIN, EXP, SQRT, LN, LOG, statistike funkcije (npr. oekivanje) i finansijske funkcije
(npr. kamatni raun).
Nakon izraunavanja vrijednosti formula automatski slijedi promjena podataka,
npr. D31=ROUND(SUM(D1:D30) * 0.65;-1).
Integrisana programska podrka (Integrated Software) objedinjuje matrini
kalkulator, obradu teksta i grafiki prikaz podataka, kao i pristup bazama podataka
(postavljanje upita) i kreiranje dijaloga. Primjenjuje se za analizu, planiranje (finansije,
proizvodnja, prodaja), kao i za pomo pri donoenju odluka (problemi tipa "ta ako").
Grafiki orijentisani jezici (raunarska grafika) slue za sintezu slika pomou
raunara (dijagrami, animacija, digitalizacija). CAD/CAM (Computer Aided
Design/Computer Aided Manufacturing) su raunarom podrano projektovanje i
raunarom podrana proizvodnja. Ovdje se jo mogu svrstati simulatori, programski
paketi za prenos slika, .
Geografski IS (GIS - Geographic Information System) ukljuuju podatke o
geometriji, koncept vie slojeva, kao i koncept objekata.
Programi i jezici za prenos podataka se sreu u komunikacionim sistemima
(modem, telefax, elektronska pota ... ), kao i kod rada u mrei raunara (emulatori
terminala, programi za prenos podataka, ... ).
Programska proirenja operativnih sistema (skeleti, ljuske) predstavljaju
najraireniji pristup nadogradnje OS (npr. Unix-a). Nad istim jezgrom (kernel), mogu se
229
koristiti razliiti skeleti (shell), npr: Bourne shell, C shell, Mashey shell i dr. Skelet se
koristi kao tuma (interpreter) naredbi, npr.:
kreiranje liste argumenata prilikom poziva programa (ls *.c 1.c 2.c ... ),
sposobnost testiranja rezultata prethodno izvrene naredbe (if test prog then ...
),
redoslijedno izvoenje vie programa (cd dir, ls, cd, ... ),
obrada u pozadini (background processing) (prog &, jobs, fg),
usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat),
ulanavanje naredbi na principu "cjevovoda" (cat | more).
Elementi programskog jezika su:
prenos i zamjena parametara (script prog arg1 arg2 $1=arg1 $2=arg2),
supstitucija varijabli (set TERM=vt100, echo $TERM),
naredbe za kontrolu programskog toka (while, if-then-else, case, ... ).
Ostala programska proirenja OS se zasnivaju na primjeni raunarske grafike,
podravanju rada sa "prozorima", "ikone", ekranske forme i dr.
13.7.4. Svojstva jezika 4GL

Osnovno svojstvo jezika 4GL je neproceduralna sintaksa. Proceduralni jezici
koriste niz naredbi koji odreuje KAKO se odreena akcija obavlja, npr. "otvori
datoteku, ako nije EOF pomakni se, ... , zatvori datoteku" i sl. Neproceduralni jezici
sadre niz naredbi koji odreuje TA treba uiniti, npr. "dohvati podatke koji
zadovoljavaju uslov ".
Tipine neproceduralne naredbe su: naredbe za definisanje strukture podataka te
rukovanje podacima u BP (nema potrebe za poznavanjem imena i lokacije datoteka,
adresa, ... ), naredbe za unos ili ispis podataka putem ekranske forme (form), naredbe
za izbor posla (menu), kao i naredbe za izvjetaje (selekcija, grupisanje, sortiranje,
agregatne funkcije, ... ).
Uz neproceduralne, mnogi 4GL raspolau proceduralnim naredbama da bi se
omoguila ugradnja proceduralnih rjeenja.
Primjer 1: Opisivanje podataka (SQL).
CREATE TABLE Osoba (
IdOsobe
INTEGER NOT NULL,
Prezime
CHAR(20) NOT NULL,
Ime
CHAR(20),
Adresa
CHAR(20),
SifMjesta SMALLINT, NOT NULL
);
230
Primjer 2: Rukovanje podacima (selekcija u jeziku SQL).

SELECT * FROM Osoba, Mjesto
WHERE Osoba.SifMjesta = Mjesto.SifMjesta
AND Osoba.Prezime LIKE "K%"
Primjer 3: Definicija veze u rjeniku podataka (Zim Information Management

(ZIM)).
Stanuje := Osoba.SifMjesta = Mjesto.SifMjesta
Primjer 4: Rukovanje podacima (ZIM).

FIND ALL Osoba Stanuje Mjesto
FIND ALL Osoba (UNRELATED) Stanuje Mjesto
FIND ALL Osoba Stanuje Mjesto (COMPLETE)
Primjer 5: Ekranski meni (Informix-4GL).

MENU Osoba"
COMMAND "Dohvat" "Postavljanje uslova za dohvat zapisa"
CALL dohvat()
IF status != NOTFOUND THEN
NEXT OPTION "Slijedeci"
END IF
COMMAND "Slijedeci" "Dohvatanje slijedeeg zapisa"
CALL slijed()
...
COMMAND "Unos" "Unos novog zapisa"
CALL unos()
....
COMMAND "Kraj" "Kraj rada"
EXIT MENU
END MENU
Primjer 6: Rukovanje podacima putem ekranske forme.

DEFINE rOsoba RECORD LIKE Osoba
DEFINE rMjesto RECORD LIKE Mjesto
...
DISPLAY BY NAME rOsoba.*
...
INPUT BY NAME rOsoba.*
BEFORE FIELD SifMjesta
MESSAGE "Unijeti ifru mjesta"
AFTER FIELD SifMjesta
CALL Sel_Mjesto (rOsoba.SifMjesta)
RETURNING rMjesto.*
IF status = NOTFOUND THEN
MESSAGE "Ne postoji mjesto"
NEXT FIELD SifMjesta
231
END IF
...
END INPUT
Primjer 7: Izvjetaj (ZIM).

REPORT ALL FROM Osoba Stanuje Mjesto
SORTED BY Osoba.Prezime, Osoba.Ime
FORMAT ACROSS 2 PAGESIZE 23 PAUSE 1
PAGE HEADING
"Stranica:" $PAGE : MASK 'ZZ9' :
DETAIL LINE
Osoba.Prezime : NEWLINE : Osoba.Ime
Osoba.Adresa
: NEWLINE :
Mjesto.PostBr
: NEWLINE : Mjesto.NazGrada
ENDREPORT
Ford Alan
Vancouver avenue 63
383260 New York
Slika 13.17. Primjer izvjetaja.

Pojedina 4GL naredba zamjenjuje do nekoliko hiljada 3GL-a naredbi. Prave se
krae programske liste, jezgrovitiji i itljiviji programski kod. Kodiranje je sa manje
greaka, a ujedno je olakano otklanjanje greaka. Slinost programa strukturiranom
govornom jeziku pojednostavnjenje izradu programske dokumentacije.
Izradi programske opreme se pristupa u ranoj fazi razvoja, koristei prototipski
razvoj. Bitno je ubrzana izrada programa sa neproceduralnom sintaksom i
generatorima koda. Poveanje efikasnosti je od 6 do 60 puta (ne i skraenje vremena
izrade!). Poveanje efikasnosti se postie smanjenjem broja naredbi i pomou interne
optimizacije. Ista aplikacija napisana u jeziku SQL moe na istom raunaru biti od 5 do
20 puta bra od odgovarajue aplikacije napisane u nekom 3GL, kao to su COBOL ili
FORTRAN. Prednost se gubi u sluajevima kada se radi o aplikacijama koje ukljuuju
rjeenja proceduralnog tipa, odnosno rjeenja dobijena povezivanjem na 3GL, npr. C.
232
Prenosivost (portabilnost) programske opreme omoguavaju: oslonac na

standardne OS (MS-DOS/WINDOWS, UNIX, ... ), koritenje vienivovskih prevodilaca
(npr. 4GL-EC-C-O-4GE), upravljaki programi koji su nadgradnja OS (npr. SQLEXEC),
kao i manje dijalekata (npr. ANSI SQL standard).
Programska oprema razvijena pomou 4GL posjeduje jednostavnu i razumljivu
sintaksu, slinu govornom jeziku, kvalitetniji razvojni i korisniki interfejs. Odlikuje se
prikladnou za uenje i rukovanje jezikom i podacima. Moe se provjeriti tzv.
dvodnevnim testom (TWO DAY TEST). Veina korisnika treba da moe nauiti osnove
4GL za 2 do 3 dana. Nakon toga korisnik bi morao biti u mogunosti samostalno da
obavlja neke manje poslove. Poeljno je da korisnik nakon manjih prekida u radu (npr.
10 dana) bude u mogunosti nastaviti sa radom bez potekoa. Napred navedeno ne
vrijedi jednako za sve 4GL!
233
14. Organizacija i upravljanje projektom

14.1. Generiki modeli organizacije
Generike modele organizacije sainjavaju: projektna, funkcionalna i matrina
organizacija. Projektnu organizaciju predstavlja osoblje organizirano unutar/oko
projekta. Prednosti ove organizacije su bre odluivanje, minimiziranje potreba susreta
izmeu lanova, poticanje identifikacije osoblja sa projektom, dok su nedostaci u
upotrebljivosti ove organizacije za male projekte i minimalna raspodjela ekspertize.
Funkcionalna organizacija predstavlja organizaciju osoblja po funkcionalnim
odgovornostima. Pojedine funkcije mogu podravati vei broj razliitih projekata.
Prednosti su u potpomaganju specijalizacije (poveanju broja specijalista), a nedostaci
su u smanjenju osjeaja pripadnosti projektu, tj. koheziji projekta. Matrina organizacija
je u osnovi funkcionalna, osoblje izmijeano u razliitim projektima. Prednosti su u
tome to projektna komponenta pogoduje uspjenosti projekta, a funkcionalna
komponenta pogoduje poveanju specijalizacije. Nedostatak je mogui sukob interesa.
14.2. Organizacija i timski rad

Timski rad (teamwork). Ekipa je "samoupravljaka" jedinica, koja posluje u duhu
saradnje svojih lanova, njihove koordinacije i njima unaprijed poznatih procedura.
Prednosti timskog rada su kvalitetnije donoenje odluka, motivacija lanova,
inovativnost, sinergija i slino.
Djelovanje
Uspjenost
tima
Formiranje
Jurianje
Normiranje
Energija tima
Slika 14.1. Uticaj karakteristika tima na njegovu uspjenost.
234
Razvoj tima definiu slijedee karakteristike: formiranje (Forming), koje

podrazumjeva ljubaznost, nesklonost iznoenju stavova, preputanje voenju,
"jurianje" (Storming), koje se ogleda u neslozi, sukobu linosti, grupaenju /stranakoj
pripadnosti, pomanjkanju kvalitetne komunikacije, neuspjenosti dogovaranja,
normiranje (Norming), odnosno uvianje dobrih strana zajednikog rada, meusobno
uvaavanje i predstavljanje (Performing), djelovanje, tj. povezivanje u efikasnu
operativnu grupu. Uticaj karakteristika tima na njegovu uspjenost prikazan je slikom
14.1.
14.3. Modeli timova

Klasinu organizaciju tima (Chief Programmer Team) sainjavaju: glavni
programer (chief programmer), rezervni programer (backup programmer), mlai
(junior) programer i administrator. Glavni programer objedinjuje znanje i odluivanje
ekipe. Mora istovremeno biti dobar (vrhunski) programer i rukovodilac. U poboljanoj
(revidiranoj) organizaciji ima ulogu rukovodioca ekipe. Rezervni programer slui kao
zamjena za nekog od mlaih programera. U poboljanoj (revidiranoj) organizaciji ima
ulogu pomonika rukovodioca (slika 14.2).
Administrator
Glavni
programmer
(rukovodilac)
O
Rezervni
programmer
(pomonik)
Programer
Slika 14.2. Prikaz klasine organizacije tima.

Modernu organizaciju tima (4GL tim) sainjavaju izvrioci slijedeih radnih
zadataka: rukovodilac projekta, odnosno vii sistem analitiar, saradnju sa korisnikom
ostvaruje poslovni analitiar, konceptualno i logiko oblikovanje obavlja sistem
analitiar, a isporuku sistema/aplikacija vri poslovni analitiar. Nabavka i pogon
opreme je radni zadatak sistem inenjera za raunare, mreni servisi su zaduenje
sistem inenjera za komunikacije, programsko inenjerstvo obavlja programeranalitiar, dok izrada dokumentacije je posao razvojnog tima. Pomono osoblje se
sastoji od administrativnog koordinatora, tehniara i inovnika. Neki stvarni poslovni
sistemi koriste gornju podjelu za opis radnih mjesta.
235
Elastini model tima ima oblik: upravnik tima, koji upravlja osobljem (plate,
reije, ... ), rukovodilac tima, upravlja razvojem (organizacija posla), projektant
(analitiar - programer) je zaduen za analizu, oblikovanje i izvedbu, a programer
(programer aplikacija) vri kodiranje i testiranje aplikacija. Administrator baze podataka
je zaduen za BP, a sistem inenjer(i) obavlja(ju) odravanje mree i raunara.
Sastav tima odgovara poslovima koje treba obaviti. Raspodjela uloga konkretnim
lanovima, kao i broj lanova pojedine kategorije, zavisi o konkretnom projektu i
raspoloivosti radnika.
Primjer: Ulogu upravnika tima i rukovodioca tima moe imati ista osoba. Tim
moe imati vie programera. Uloga administratora BP i sistem inenjera moe se
dodijeliti istoj osobi. Ovakav model tima se moe primijeniti bez obzira na moguu
razliitu sistematizaciju radnih mjesta u nekom poslovnom sistemu.
14.4. Organizacija velikih projekata

Upravnik ili rukovodilac projekta (project manager, project leader) upravlja
projektom. Posao moe da obavlja vie ekipa. Upravnik je nadreen upravnicima/
rukovodiocima timova. Tim moe imati i dva rukovodioca i to: upravnika tima (team
manager) i rukovodioca tima (team leader), slika 14.3.
Upravnik tima obavlja poslove planiranja, upravljanja i nadzora, kao i rukovoenje
ostalim lanovima tima, dok rukovodilac tima se bavi tehnikim aspektima aktivnosti
koje se odnose na izradu i/ili uvoenje aplikacija/podsistema IS.
Upravnik
projekta
Upravnik Rukovodilac
tima
tima
lanovi tima
Slika 14.3. Grafiki prikaz organizacije velikih projekata.
236
14.5. Upravljanje projektom

(Project management)
Upravljanje projektom predstavlja proces organizovanja, planiranja, upravljanja i
nadzora razvoja sistema kojim e se postii prava funkcionalnost, na vrijeme i uz
minimalne trokove. Ukljuuje razliite aspekte:
plan Koje aktivnosti i u kojem vremenskom razdoblju treba obaviti?
sredstva/resursi Koji su kadrovi (osoblje) i oprema potrebni?
organizacija Koji je odnos pojedinih resursa?
raspored Koji je redoslijed aktivnosti?
upravljanje Kako usmjeriti i motivisati izvoae (tim)?
nadzor Potuje li se plan?
Elementi plana su: veliina projekta, odnosno funkcionalne take (broj linija koda),
napor izrade (odreivanje iznosa ovjek-mjeseci) i vrijeme izrade (u mjesecima).
Izgradnja IS je posao koji se, unato posebnostima, obavlja kao neki drugi
inenjerski poslovi, u planiranom vremenu i sa planiranim resursima.
Planiranje projekta mora: odrediti doseg, vremenski raspored i finansijska
sredstva, identifikovati pokroviteljstvo kao garanciju realizacije, izabrati upravnika
/rukovodioca projekta, odabrati alate za upravljanje projektom i pokrenuti projekat.
Planiranje vremena (izrada rasporeda) sainjavaju: odreivanje aktivnosti,
procjena i dodjeljivanje sredstava potrebnih za pojedinu aktivnost, procjena trajanja
pojedinih aktivnosti, odreivanje zavisnosti izmeu aktivnosti i izrada vremenskog
rasporeda za projekat.
Upravljanje (nadzor) sadri: odreivanje postupka izvjetavanja o napretku
projekta, praenje napretka redovnim revizijama, preraspodjelu sredstava i aktivnosti u
skladu sa dogaajima, kao i auriranje vremenskog rasporeda.
14.6. Planiranje projekata

Zato planirati? Duhoviti odgovor na ovo pitanje glasi: ako neto moe poi
pogreno, poi e pogreno u najgore vrijeme i na najgorem mjestu (Murphyjev
zakon). Murphy je bio optimista (Grimmov komentar).
ta je plan (a ta nije)? Plan ne predstavlja izvjesnost ili neto to e se zaista
dogoditi. Plan je najbolja procjena, zasnovana na pretpostavkama i iskustvu. Elementi
plana su aktivnosti, kljuni dogaaji, resursi (sredstva), trokovi ... .
Programerski paradoks [Brooks, 1982.]. Nakon to je odgovarajui broj osoba
pridruen nekom zadatku, dodavanje osoblja usporava razvoj, umjesto da ga ubrza.
237
Sloeni projekti zahtijevaju velike ekipe. Najbolja strategija je podijeliti projekt u

niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti.
Izrada plana sadri slijedee aktivnosti: utvrivanje kljunih aktivnosti i dogaaja,
odreivanje vremenskih redoslijeda aktivnosti i dogaaja, kao i utvrivanje potrebnih
sredstva. Potrebno je racionalizovati pripadajue trokove, povezati pojedine
podprojekte/poslove u glavni projekat, iterativno razraditi plan i revidirati plan u skladu
sa postojeim iskustvom/saznanjima.
Metode namijenjene za upravljanje projektima su mnogobrojne, a mogu se
izdvojiti PRINCE (PRojects IN Controlled Environments) i COCOMO (COnstructive
COst MOdel). Metoda PRINCE je strukturirana metoda za upravljanje projektom, za
definisanje organizacione strukture projekta, definisanje strukture i sadraja plana
projekta, definisanje skupa provjera i izvjetaja koji se koriste za nadzor realizacije.
14.7. Tehnike za vremensko planiranje

tapiasti/stupasti dijagrami - Gantogrami (Gantt Charts) omoguavaju
prikaz aktivnosti linijama. Duina linije je srazmjerna vremenu obavljanja aktivnosti.
Gantogram prikazuje predvieni poetak i kraj aktivnosi, njihovu meusobnu zavisnost
te odgovornost za izvoenje aktivnosti. Naglaava vremensko preklapanje aktivnosti,
slika 14.4.
May 1996
Slika 14.4. Primjer gantograma.

Mreni plan - PERT/CPM (Program Evaluation Review Technique/Critical Path
Method) prikazuje vremensku predstavu aktivnosti i njihovih uslovljenosti. Vidljivo je
238
koje aktivnosti se mogu vriti paralelno, a koje u nizu, ukoliko zavise o ranijim
aktivnostima. Naglaava kritini put projekta, slika 14.5.
Slika 14.5. Primjer mrenog plana PERT/CPM.

Upravljanje kljunim dogaajima se vri tabelarnim prikazima planiranih
aktivnosti i trenutnog statusa njihovog izvrenja. U odreenim vremenskim trenutcima
se razmatra stepen dovrenosti neke/nekih projektnih aktivnosti. Kljuni dogaaj je
obino kraj neke faze ili aktivnosti, kao npr. oekuje se da faza ili aktivnost bude
gotova, druge aktivnosti zapoinju nakon to se to ostvari ili pomak kljunog dogaaja
ima za posljedicu vremenski preraspored.
14.8. Izrada plana

Definisanje zadataka i njihove meuzavisnosti bie objanjeni preko slijedeeg
primjera (tabela 14.1). Zadatak T3 (npr. ugradnja komponenti) zavisi o zadatku T1
(npr. oblikovanje komponenti). Oblikovanje mora biti zavreno prije ugradnje.
Tabela 14.1.
Zadaci
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Trajanje (u danima)
8
15
15
10
10
5
20
25
15
15
7
10
Zavisnosti
T1(M1)
T2,T4(M2)
T1,T2(M3)
T1(M1)
T4(M5)
T3,T6(M4)
T5,T7(M7)
T9(M6)
T11(M8)
239
Pristupa se izradi mrenog plana na osnovu definisanih zadataka i zavisnosti

(slika 14.6). Aktivna mrea se ita sa desna na lijevo. Sve aktivnosti moraju zavravati
u kljunim takama (M1, M2, M3, M4, ... ). Tek kad se uspjeno pree kljuna taka
moe se zapoeti sa slijedeom aktivnosti. Npr. zadatak T9, ne moe zapoeti sve dok
zadaci T3 i T6 nisu zavreni. Dolazak na taku M4 pokazuje da su ti zadaci zavreni.
T12
Slika 14.6. Primjer dijagrama mrenog plana.

Kritini put. Minimalno vrijeme potrebno za zavretak projekta se moe
procjenjivati prema kritinom putu, odnosno najduem putu na aktivnoj mrei. U
navedenom primjeru to je 11 sedmica ili 55 radnih dana. (T1-T3-T9-T11-T12, slika
14.6).
Prekoraenje vremenskog roka najee je vezano uz kritini put. Aktivnosti koje
kasne, a ne lee na kritinom putu ne bi trebale uzrokovati vremensko prekoraenje
(npr. ako T8 kasni ne bi trebalo uticati na krajnji datum, jer T8 ne lei na kritinom
putu).
14.9. Prikaz plana

Gantogram je alternativni nain prikaza vremenskog rasporeda (slika 14.7). Neke
od aktivnosti su oznaene i zasjenjenim linijama, to pokazuje da postoji odreena
fleksibilnost u datumu njihovog zavravanja. Ako se aktivnost ne zavri na vrijeme,
kritini put nee biti ugroen sve do zavretka zasjenjene linije.
240
Slika 14.7. Primjer gantograma sa prikazom vremenskog rasporeda.
14.10. Raspodjela zadataka

tapiasti dijagram (gantogram), takoe, pokazuje razdoblje u kojima je osoblje
angairano na projektu (slika 14.8). Angaovanje ne mora biti kontinuirano. Za
razmatrani primjer prikazano je tabelom 14.2. Osobe mogu raditi na drugim projektima,
ii na odmor ili obavljati neke druge aktivnosti.
Tabela 14.2.
Zadaci
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
Inenjer
Nada
Ana
Nada
Pero
Mile
Ana
Igor
Pero
Nada
Ana
Pero
Pero
241
Pero
Nada
Ana
Igor
Iva
Slika 14.8. Primjer vremenskog angaovanja osoblja pomou gantograma.
14.11. Evidencija projekta

Za planiranje, upravljanje, praenje napretka, praenje istorije projekta mogu se
koristiti razliiti programski proizvodi, npr. MS Project, CA Process Continuum, CASE
alati za planiranje. Ekranske forme CASE alata za upravljanje projektima su prikazani
na slikama 14.9 i 14.10.
Slika 14.9. Primjer ekranske forme CASE alata za upravljanje projektima.
242
Slika 14.10. Drugi primjer ekranske forme CASE alata za upravljanje projektima.
14.12. Praenje napretka (izvrenja) projekta

Upravljanje projektom podrazumjeva stalni nadzor napredovanja, ta se moe
prikazati slijedeim programom, napisanom pomou pseudokoda.
Postavljanje projektnih ogranienja
Napraviti poetnu procjenu projektnih parametara
Definisanje kljunih taaka i izvjetavanje
while projekt nije zavren ili otkazan loop
Nacrtaj vremenski raspored projekta
Podijeli aktivnosti prema vremenskom rasporedu
ekaj
Provjeri napredak projekta
Revizija procijenjenih projektnih parametara
Auriranje vremenskog rasporeda projekta
Provjeri projektna ogranienja i izvjetaje
If (poveanje problema) then
Ponovni tehniki pregled i mogua revizija
end if
end loop
243
Na slici 14.11 je prikazan primjer dijagrama za praenje napretka projekta, dok je

na slici 14.12 prikazan primjer tabele za evidentiranje napretka.
P1
prilagoavanje plana
D1 plan
projekta
P2
O
rukovodilac
projekta
praenje
napretka
evidencija
lan ekipe
D2 radnih sati
Slika 14.11. Primjer dijagrama za praenje napretka.

Zadatak
Izvrioci
Planirani
poetak
Planirani
zavretak
Prioritet
Planirano
trajanje
Stvarno
trajanje
Status
%
ispunjenja
Stvarni
zavretak
Kanjenje
Komentar
Slika 14.12. Primjer tabele za evidentiranje napretka.
14.13. Preporuke za planiranje poslova

Planiranje poslova: Planovi moraju biti aurni, tj. prilagoeni stvarnom stanju.
Izbjegavati detaljno planiranje poslova koji slijede u daljoj budunosti. Takve je
dovoljno predvidjeti i najaviti, a panju usmjeriti na probleme koji se trenutno rjeavaju.
Planovi trebaju biti to krai, kako se vrijeme ne bi troilo na detaljiziranje koje zbog
mogue promjene stanja ionako nee biti istinito. Konkretno razdoblje za koje se radi
plan moe varirati u zavisnosti o veliini projekta. Naelno je dovoljan jedan plan (i
pregled realizacije) mjeseno, s tim da ukljuuje raspored nedjeljnih aktivnosti. Poslove
i zadatke treba uravnoteeno raspodijeliti. Vie panje treba posvetiti lanovima koji
zaostaju u izvrenju plana ili rjeavaju sloeniji problem u odnosu na ostale lanove.
Po potrebi treba prerasporediti postojee poslove.
244
Komunikacija moe biti: verbalna (brzo sluaj i misli, sporo i jasno govori, biljei
izreeno), pisana (sadraj, forma, uestalost), elektronska (E-mail, Chat, News),
obavjetavanje (pismenim putem, elektronskom potom), uvanje informacija (mreni
rjenik, FTP rjenik, web server) ili u obliku organizacije rjenika (Admin, Materijali,
Projekt, Backup, Tmp, itd).
Druenja moraju biti efikasna! Izbjegavati raspravu o optepoznatim ili
nevanim stvarima. Rasprave treba prekinuti u trenutku kada se pretvore u razgovor o
temama koje se ne odnose na posao.
Sastanci moraju biti pripremljeni (mjesto, vrijeme, teme, uesnici)!
Tehnike za poboljanje rada: Brainstorming (iznoenje ideja), izbjegavanje
"jedinih" rjeenja (traenje alternativa), zapisivanje odluka (zapisivanje da bi se izbjegla
pogrena tumaenja), konstruktivne povratne informacije (kritikovanje postupaka, a ne
osoba), razumijevanje neuspjeha (analiza i poboljanje svega to nije dobro),
raspodjela moi i odgovornosti (ravnopravnost, izbjegavanje hijerarhije).
245
15. Primjena i odravanje informacionog sistema

15.1. Uvoenje sistema u primjenu
Uvoenje u primjenu projektovanog informacionog sistema ukljuuje instalisanje
opreme, zavrni prenos podataka, te prelazak na novi nain rada.
Aktivnosti i preduslovi su:
1. Testiranje sistema, vidjeti taku 12.5;
2. Izrada plana konverzije (migracije) za uspjean prelazak na novi sistem.
Definisati nain uvoenja, poslove, odgovornosti, resurse i redoslijed izvedbe,
izradu plana testa prihvatljivosti ukoliko nije uraen ranije;
3. Instalacija opreme, aplikacija i baze (baza) podataka novog sistema, inicijalni
unos podataka, prenos postojeih podataka uz konverziju, uspostava sistema
zatite i odravanja;
4. Poduka tehnikog osoblja i krajnjih korisnika, koja moe biti verbalna ili putem
raspodjele dokumentacije;
5. Konverzija sistema, prelazak na novi nain rada, evaluacija projekta i sistema.
Uvoenje sistema moe biti neposredno i paralelno. Neposredno uvoenje
podrazumjeva poetak rada novog sistema uz istovremeni prestanak rada starog
sistema. Provodi se na odreeni dan, uobiajeno nakon zavretka poslovnog
razdoblja, po mogunosti na kraju sedmice. Mogui problemi su pojava greaka koje
nisu bile uoene tokom testiranja, nepredvieno preoptereenje opreme u punom
pogonu. Nedostatak je neposredna izloenost korisnika grekama sistema. Paralelno
uvoenje podrazumjeva istovremeni rad starog i novog sistema tako dugo dok se ne
pokae da novi sistem ispravno radi i da su se korisnici navikli na novi nain rada.
Bitno je manje rizian postupak u odnosu na neposredno uvoenje. Nedostatak je
potreba za dvostrukom obradom istih podataka, u starom i u novom sistemu, to stvara
otpor korisnika.
Korisnici mogu biti rasporeeni na razliitim lokacijama. Probno uvoenje je
neposredno/paralelno uvoenje sistema na jednoj lokaciji, a zatim i na ostalim
lokacijama, nakon to se utvrdi da sistem ispravno radi. Postupno uvoenje je
uvoenje grupa lokacija, dok istovremeno uvoenje predstavlja jednovremeno
uvoenje na svim lokacijama. Modularno uvoenje je postupna zamjena starog
sistema novim, uvoenjem po dijelovima. Izvodljivo je samo ako je mogu istovremeni
rad oba (nekompletna) sistema. Mogui problemi su potreba za spojnim programima, tj
programima za premoavanje.
246
Karakteristike razliitih naina uvoenja sistema u primjenu su prikazani u tabeli

15.1.
Tabela 15.1.
Uvoenje
Rizik
Troak
Trajanje
neposredno
paralelno
ostalo
visok
nizak
srednji
niski (ako uspije)

visok
srednji
kratko (ako uspije)

dugo
varijabilno
15.2. Obuka korisnika IS

Vri se obuka tehnikog osoblja korisnika i krajnjih korisnika sistema.
Obuka krajnjih korisnika moe ukljuivati optu informatiku kulturu (npr.
upotreba personalnih raunara), funkcije sistema i nain upotrebe sistema, to jest
koritenje aplikacija, ili obuku iz posebnih znanja potrebnih za obavljanje osnovne
djelatnosti (npr. operaciona istraivanja, projektovanje primjenom raunara i sl.).
Obuka tehnikog osoblja moe ukljuivati operativni sistem i uslune programe,
administriranje baze podataka, programske jezike i CASE alate.
Redoslijed obuke je slijedei. Prvo se obavlja obuka tehnikog osoblja koje e
odravati sistem i pruati podrku krajnjim korisnicima, da bi se mogla pokrenuti
primjena IS. Nakon toga treba obrazovati (nie) rukovodstvo, da bi se stekla njegova
podrka pri obuci ostalih korisnika tokom primjene. Slijedi kolovanje (krajnjih)
korisnika, koje treba prilagoditi funkcijama koje oni obavljaju u svakodnevnom radu.
Postupci i tehnike obuke su kursevi, probni rad u fazi provjere rada sistema,
kvalitetni sistem interaktivne pomoi, prikladna dokumentacija i podrka tokom
primjene. Obuku mogu obaviti radnici naruioca (npr. odjel informatike ili grupa za to
odabranih i osposobljenih radnika) ili vanjski izvoai obuke.
15.3. Odravanje informacionog sistema

15.3.1. Odravanje i nadgradnja
Odravanje je trajna aktivnost koja zapoinje odmah nakon uvoenja sistema u
primjenu. Bez obzira kako je dobro sistem dizajniran, konstruisan i testiran, greke e
se neizbjeno pojaviti! Ispravljanje greaka u primjeni se naziva odravanjem sistema
ili odravanjem programa. Odravanje samo po sebi ne podrazumijeva ugradnju
poboljanja ili novih mogunosti, ali se ona uobiajeno provode.
247
Tokom primjene i odravanja obavlja se analiza dodatnih zahtjeva, planiranje i

priprema aktivnosti koje slijede, te tako zapoinje novi ciklus razvoja.
15.3.2. Odravanje - servisiranje sistema

Preventivno odravanje sistema podrazumijeva zatitu od moguih problema.
Potrebno je vriti redovnu izradu sigurnosnih kopija (backup). Bekap se obavlja
periodino (dnevno, sedmino, mjeseno).
Pod korektivnim odravanjem se podrazumijeva popravka nakon to se problem
pojavio. Vri se vraanje podataka iz sigurnosne kopije (restore) ili uklanjanje uzroka
greke (ispravljanje programa).
Adaptivno odravanje je prilagoavanje funkcionalnosti (naina posluivanja),
prilagoavanja strukture (promjene strukture podataka) ili poboljanje performansi
(optimizacija programa).
Perfektivno odravanje je nadgradnja sistema da bi se rijeili novi problemi ili
ugradnja novih mogunosti.
15.3.3. Uklanjanje greaka i izmjene programa

Definicija i validacija problema podrazumjeva uoavanje uzroka greaka u
primjeni (bugova), odnosno problem reprodukcije greke, problem razliitog tumaenja
greke koje nastaje uslijed nerazumijevanja ili pogrenog koritenja programa.
Nepostojanje funkcije ija ugradnja nije bila planirana nije bug.
Ocjenjivanje sposobnosti. Odravanje moe imati neeljene popratne uinke na
funkcionalnost i performanse aplikacija. Prije izmjene programa, programi treba da
budu izmjereni da bi se utvrdila osnovica prema kojoj e se ocijeniti izmijenjeni
programi.
Editovanje i testiranje. Potrebno je poznavanje programa, odnosno upravljanje
verzijama, da bi se izbjegle razliite verzije u primjeni kod razliitih korisnika.
Neophodna je mogunost povratka na prethodnu verziju, ako je ta bila bolja. Takoe je
potrebno regresivno testiranje, tj. ponavljanje svih testova da bi se provjerilo da
izmjene nisu uzrokovale nove greke, kao i auriranje dokumentacije.
15.4. Poboljanje sistema i reinenjerstvo

Poboljanje sistema je dorada i nadgradnja sistema prema novim zahtjevima,
analiza novih zahtjeva i povratak u odgovarajuu fazu (analiza, dizajn, izrada). Veina
248
novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim

informacijama ili novim idejama (eljama korisnika).
Reinenjerstvo. Neke aplikacije je teko odravati (npr. uslijed zastarjelosti
tehnologije), a troak odravanja pojedinih aplikacija moe dosei troak izrade novih.
Reinenjerstvo je adaptacija sa ciljem smanjenja trokova odravanja, odnosno
prilagoavanje veim promjenama tehnologije, ispravka sistema prije nego to doe
do mogueg prekida u radu, kao i ispravka sistema koji e biti lake popraviti ako doe
do prekida.
Pisanje jednostavnih novih programa. Jednostavni program je onaj program
koji koristi samo postojee podatke. Primjeri takvih programa su pretraivanje i
pregledanje podataka, kao i generisanje izvjetaja. Ove promjene su najee i
najsigurnije.
Restukturiranje datoteka i baza podataka je promjena strukture u postojeoj
bazi podataka. Prelazak na novu tehnologiju upravljanja podacima predstavlja veliki
rizik.
Reinenjerstvo programa je reorganizacija koda, odnosno restrukturiranje
organizacije modula ili programske logike. Konverzija koda je prelazak na novi
programski jezik. Rezanje koda ili odsjecanje koda je izdvajanje dijelova programa radi
izrade odvojenog programa ili potprograma. Poboljanja i reinenjerstvo moraju biti
planski provedeni.
15.5. Elementi konfiguracije

Element konfiguracije (prema IEEE) je agregacija hardvera i/ili softvera koja
se tretira kao jedinka u procesu upravljanja konfiguracijom. Konfiguracija je imenovani
skup konfiguracijskih elemenata u odreenoj taki ivotnog ciklusa, slika 15.1.
Slika 15.1. Konfiguracija elemenata u odreenoj taki ivotnog ciklusa.
249
Verzije konfiguracije su slijedee:

verzija (version) odreeno izdanje (issue, release) proizvoda,
objava, isporuka (release) originalna verzija u primjeni, npr. zadnja v2.0,
revizija (revision) ona koja se koristi umjesto originalne, podrazumijeva
izmjene u odreenim vremenskim intervalima, npr.v1.2,
varijanta (variant) alternativa originalu (hardverska platforma, razliiti jezik),
ivi paralelno sa njim, npr. v1.1.2.1.
Na slici 15.2 shematski su prikazane navedene verzije konfiguracije.
V 1.0
V 1.1
V 1.2
V 2.0
V 1.1.2.1
V 1.1.2.2
V 1.1.4.1
V 1.1.4.2
Slika 15.2. Verzije konfiguracije.
250
251
Literatura
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Axosoft Company - http://www.axosoft.com/, 2005.

Axtools - http://www.axtools.com/, 2006.
Awad A.M.: System Analysis and Design, Irwin, 1985.
Avison, D.E. & Fitzgerald, G.: Information Systems development: methodologies,
techniques and tools, 2nd. ed. McGraw-Hill, 1998.
Blum, B.I.: A taxonomy of software development methods, Comm. Of the ACM,
vol. 37 (no. 11), 82-94, 1994.
Boehm, B.W.: Seven Basic Principles of Software Engineering, Journal of Systems
& Software, 3(1), March 1983, pp. 3-24, 1983.
Brooks, F.P.: The Mythical Man Month, AddisonWesley, 1975.
Brooks, F.P.: No silver bullet: essence and accidents of software engineering,
Computer vol. 20 (no 4), pp. 10-19, 1987
Cameron, J.R., Campbell, A. & Ward, P.T.: Comparing software development
methods: example, Information and Software Technology, Vol 33 (no. 6), pp. 386
402, 1991.
Carnegie Mellon University, Software Engineering Institute - http://www.sei.
cmu.edu/seihome, 2006.
Cattel R. G. G.: Object Data Management, Object-Oriented and Extended
Relational Database Systems, Addison - Wesley Publishing Company, 1991.
CollabNet, Inc. - http://argouml.tigris.org/, 2006.
Construx Software - http://www.construx.com/doc.htm, 2006.
Enterprise IT Management (EITM) - http://www3.ca.com/Solutions/, 2006.
ZPM & FER - http://www.zpm.fer.hr, 2005.
Grady Booch, James Rumbaugh and Ivar Jacobson: The Unified Modeling
Language (UML), User Guide, Rational Software Corporation, Original Copyright
by Addison Wesley Longman, Inc., 1999.
Harel, D.: Biting the Silver Bullet: Toward Brighter Future for System Development,
Computer, vol. 25 (no.1), pp. 8-20, 1992.
Hirscheim, R. and Klein, H.K.: Four paradigms of information systems
development, Comm. of the ACM, Vol 32 (no. 10), pp. 1199 1216, 1989.
Hoffer A. J., George F. J., Valacich S. J.: Modern Systems Analysis and Design,
3/e, Prentice Hall College Div., 2001.
Hornby, P et all: Human and organisational issues in information systems
development Behaviour and Information Technology, vol.11 (no. 3), pp. 160-174,
1992.
IEEE Std 610.12-1990: "Standard Glossary of Software Engineering Terminology"
in IEEE Software Engineering Standards Collection, New York, pp. 67, 1994.
Institute of Electrical and Electronics Engineers, Inc. - http://www.swebok.org/,
2001.
252
23. Intelligentedu.com - http://www.intelinfo.com, 2006.

24. JYACC Company - http://www.prolifics.com/do/panther.html, 2005.
25. Kim Won: Introduction to Object-Oriented Databases, The MIT Press Cambridge,
Massachusetts, London, 1992.
26. Lazarevi B., Jovanovi V., Vukovi M.: Projektovanje informacionih sistema, I
deo, Nauna knjiga, Beograd, 1986.
27. Lazarevi B., Dizdarevi P., Jovanovi V.: Projektovanje informacionih sistema, II
deo, Nauna knjiga, Beograd, 1986.
28. Maciaszek L: Requirements Analysis and System Design: Developing Information
Systems with UML, 1/e, Addison Wesley Higher Education, 2002.
29. McConnell S.: Software Project Survival Guide Microsoft Press, ISBN: 1-57231621-7, 1998.
30. McLeod R., Jordan E.: Systems Development: A Project Management Approach,
ISBN: 0-471-22089-2, Wiley Higher Education, 2002.
31. Mogin P., Lukovi I., Govedarica M.: Principi projektovanja baza podataka,
STYLOS, Novi Sad, 2000.
32. Murch R.: Project Management: Best Practices for IT Professionals, 1/e, Prentice
Hall PTR, ISBN 0-130-21914-2, 2000.
33. Object Management Group, Inc. - http://www.omg.org/uml/, 2006.
34. Objektno - orijentisani pristup razvoju informacionih sistema, Fakultet
organizacionih nauka, Institut za organizacione sisteme, Beograd, 1998.
35. Original Copyright by IBM: The Business System Planning (BSP), 1991.
36. Poliuk E. J.: Software etvrte generacije ORACLE, NIP "Tehnika knjiga",
Beograd, 1991.
37. Poliuk, E. J.: Baze podataka, Informatika literatura JEP (vlastito izdanje),
Podgorica, 2003.
38. Poliuk, E. J.: Informacioni sistemi (skripta), Elektrotehniki fakultet, Podgorica,
2004.
39. Poliuk, E. J.: Ekspertni sistemi, Informatika literatura JEP (vlastito izdanje),
Podgorica, 2004.
40. Poliuk, E. J.: Multiprocesorski i distribuirani raunarski sistemi (skripta),
Elektrotehniki fakultet, Podgorica, 2004.
41. Poliuk, E. J.: Projektovanje informacionih sistema pomoci CASE alata (skripta),
Elektrotehniki fakultet, Podgorica, 2004.
42. Poliuk, E. J.: Objektne baze podataka (skripta), Elektrotehniki fakultet,
Podgorica, 2005.
43. Poliuk E. J.: Prilog metodologiji razvoja sistema za podrku odluivanju i
ekspertnih sistema, (doktorska disertacija), Sveuilite u Zagrebu, 1992.
44. Poliuk E. Jaroslav: Neproceduralni razvoj informacionih sistema, (magistarski
rad), Postdiplomske studije informatike na Univerzitetu u Banja Luci, 1990.
253
45. Poliuk E. J.: Projektovanje informacionih sistema (skripta), Elektrotehniki

fakultet, Podgorica, 1998.
46. Poliuk E. J.: Savremeni pristup razvoju informacionih sistema, PRAKSA:
Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd,
1991.
47. Poliuk E. J.: Informatika organizacija ili "organizacija budunosti", PRAKSA:
Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd,
1992.
48. Poliuk E. J.: Novi pristup razvoju informacionih sistema, JISA INFO, asopis
Jugoslovenskog informatikog saveza , Beograd, 1996.
49. Poliscuk E. J.: Some Features of Object Data Management Concepts, INFO
SCIENCE, Journal of Information, Comunication and Computer Sciences,
Beograd, 1998.
50. Poliuk E. J.: Neke osobine sistema za objektno upravljanje podacima, IV nauno
- struni skup: Informacione tehnologije - sadanjost i budunost, Zbornik radova
sa IV nauno strunog skupa IT '99, abljak, 1999.
51. Poliuk E. J.: Koncepti hijerarhija klasa i naslijeivanje u objektno orijentisanom
modelu podataka, VI nauno - struni skup: Informacione tehnologije sadanjost
i budunost, Zbornik radova sa VI nauno strunog skupa IT 01, abljak, 2001.
52. Poliuk E. J.: Neki aspekti razvoja sistema za podrku odluivanju, III
meunarodni simpozij informacijske i komunikacijske tehnologije u uredskom
poslovanju '92 "OFFICE AUTOMATION", Sveuilite u Zagrebu, Zbornik radova
'92 OFFICE AUTOMATION, Varadin, 1992.
53. Poliuk E. J.: Informatiko obrazovanje "inenjera budunosti", V meunarodna
konferencija "Informatika u obrazovanju i nove informacione tehnologije",
Univerzitet u Novom Sadu, Zbornik radova I, Novi Sad, 1995.
54. Poliuk E. J.: Neki problemi korienja informacione tehnologije, VI meunarodna
konferencija
"Informatika u obrazovanju i nove informacione tehnologije",
Univerzitet u Novom Sadu, Zbornik radova, Apatin, 1996.
55. Poliuk E. J.: Koncepti objektno orijentisanog modela podataka, IX meunarodna
konferencija "Informatika u obrazovanju, kvalitet i nove informacione tehnologije",
Univerzitet u Novom Sadu, Zbornik radova, Zrenjanin, 2000.
56. Poliscuk, E. J.: The Analysis Of Experimental Results Of Machine Learning
Approach, Journal of Information and Organizational Sciences, ISSN 0351-1804,
vol. 27, No. 1, pp. 29-42, 2003.
57. Poliscuk, E. J. and Stojanovic, D. R.: The Intelligent Agent: An Analysis of the
Experimental Results, WSEAS Transactions on Systems, ISSN 1109 - 2777, Issue
10, Vol. 3, pp. 3248 3253, 2004.
58. Poliscuk, E. J.: The Machine Learning Method: Analysis of Experimental Results,
Journal of Quantitative Linguistics, Taylor & Francis Group, ISSN 0929 6174,
Vol. 11, No.3, pp. 215-233, 2004.
254
59. Poliuk, E. J.: Automatic Programming Systems Dedicated for Proving of

Theorems, WSEAS Transactions on Computers, ISSN 1109 - 2750, Issue 2, Vol.
5, pp. 261-266, 2006.
60. Poliscuk, E. J.: Intelligible Automated Reasoning: Systems with the Resolution,
Induction and Symmetry, Journal of Applied Computer Science, ISSN 1507-0360,
vol.13, No.2, pp. 7-28, 2005.
61. Poliuk, E. J.: Adaptive Machine Reinforcement Learning, Centrum ksiazki
akademickiej i naukowe, Motto.Pl-Ksiegarnia Internetowa, http://www.motto.pl/,
Krakow, 2005.
62. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results,
Taylor & Francis Group, http://www.citeulike.org/article/84531/, London 2005.
63. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results,
Universita di Milano, Biblioteca di informatica, http://fantomas.usr.dsi.unimi.it/,
Milano, 2005.
64. Poliuk E. J.: Automatic Theorem Proving: Situation Management and Decision
Making, Emerging Technologies, Robotics and Control System, International
Society for Advanced Research, Vol. 2, pp. 154-167, 2007.
65. Popkin Software - http://www.popkin.com/, 2005.
66. Pressman R.S.: Software Engineering: A Practitioner's Approach, 5/e, McGrawHill, ISBN 0-07-249668-1, 2001.
67. ProxySource, Inc. - http://www.proxysource.com/, 2003.
68. Rational Software Corporation - http://www.rational.com, 2006.
69. R.S. Pressman & Associates, Inc. - http://www.rspa.com/docs/index.html, 2006.
70. R.S. Pressman & Associates, Inc. - http://www.rspa.com/apm/index.html, 2006.
71. School of Computing at Queen's University Canada - http://www.qucis.queensu.ca
/Software-Engineering/ tools. html, 2006.
72. SOFTEAM - http://www.objecteering.com/, 2006.
73. Software Engineering Environments at Auburn University - http://www.pittarese.
com/Auburn/cse625/case.htm, 1998.
74. Sommerville, I.: Software Engineering, Addison-Wesley Publishing Company,
2000.
75. Sparx Systems Pty Ltd. - http://www.sparxsystems.com.au/, 2006.
76. Standish Group International, Inc. - http://www.standishgroup.com, 2006.
77. Steve McConnell's: Software Project Survival Guide (Microsoft Press, 1998).
78. http://www.construx.com/survivalguide/, 2005.
79. Visible Systems Corporation - http://www.visible.com/, 2004.
80. Visual Paradigm International - http://www.visual-paradigm.com, 2006.
81. Whitten J. L., Bentley L. D., Dittman K. C.: Systems Analysis & Design Methods,
McGraw-Hill/Irwin; ISBN 0-07-25523-60; 5th ed., 2001.

Knjiga Projektovanje IS PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Knjiga Projektovanje IS PDF

Uploaded by

Copyright:

Available Formats

prof. dr ing poliuk e.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Prof. dr ing Poliuk E. Jaroslav

Kompjuterska obrada knjige: autor

Sva prava zadrava autor.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

U Podgorici, septembar 2007. god.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2. Planiranje razvoja informacionog sistema ..............................................

3. Uvod u projektovanje i definisanje zahtjeva za

4. Analiza sistema ...........................................................................................

5. Modeliranje funkcija i procesa .................................................................. 77

Poliuk E. Jaroslav: Projektovanje informacionih sistema

6. Modeliranje podataka ............................................................................... 101

Poliuk E. Jaroslav: Projektovanje informacionih sistema

12. Implementacija informacionog sistema ..................................................

13. Logiko projektovanje programa i programski jezici .............................

14. Organizacija i upravljanje projektom .......................................................

15. Primjena i odravanje informacionog sistema .......................................

Literatura .......................................................................................................... 251

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1. Opte o informacionim sistemima

Poliuk E. Jaroslav: Projektovanje informacionih sistema

tehnikom povezivanja programa, pisanih pomou 3GL, sa asemblerskim programima,

Oekivani efekti ulaganja

Ulaganje u softver, hardver, ljudske

Slika 1.1. Grafiki prikaz fenomena softverska kriza.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1985. godine kasnili od 30 do 45 mjeseci. U skladu sa navedenim injenicama,

1.2. Pojam informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Slika 1.2. Opti prikaz sistema.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Podatak je kodirana predstava o nekoj injenici iz realnog svijeta, on je nosilac

1.3. Elementi i osobine sistema i informacionih sistema

Organizacija je struktura i poredak, odnosno hijerarhijske veze koje odreuju

Poliuk E. Jaroslav: Projektovanje informacionih sistema

da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati, dok je

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.4. Vrste informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.5. ivotni ciklus razvoja sistema

Potreba analize i dizajna (Requirements Analysis & Specification);

1.5.2. ivotni ciklus i faze razvoja informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

odreivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada,

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Uvoenje u primjenu sistema predstavlja prenoenje radnih aktivnosti i

Slika 1.4. Prikaz faza ivotnog ciklusa razvoja softvera.

1.6. Kompleksnost razvoja informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.6.2. Neki primjeri neuspjenih projekata i sistema

1.6.3. Uzroci neuspjeha projekata informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

organizacije, pretjerani optimizam, izostanak praenja napretka i nedostatak

1.6.4. Poboljanje uspjenosti informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2. Planiranje razvoja informacionog sistema

2.1.2. Vanjski razvoj informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Nedostaci i rizici su takoe prisutni. Dolazi do gubitka povjerljivih informacija,