US - Poslovni Informacioni Sistemi

UNIVERZITET SINGIDUNUM
Prof. dr Angelina Njegu
POSLOVNI
INFORMACIONI SISTEMI
TREE IZDANJE
Beograd, 2009.
POSLOVNI INFORMACIONI SISTEMI

Autor:
Prof. dr Angelina Njegu
Recenzenti:
Prof. dr Milan Milosavljevi
Prof. dr Mladen Veinovi
Izdava:
UNIVERZITET SINGIDUNUM
Beograd, Danijelova 32
www.singidunum.ac.rs
Za izdavaa:
Prof. dr Milovan Stanii
Tehnika obrada:
Novak Njegu
Dizajn korica:
Aleksandar Mihajlovi
Goran Latinovi
Tira:
250 primeraka
tampa:
Mladost Grup
Loznica
ISBN: 978-86-7912-231-5
Copyright:
2009 Univerzitet Singidunum
Izdava zadrava sva prava.
Reprodukcija pojedinih delova
ili celine ove publikacije nije dozvoljena.
Mojim roditeljima, Gospavi i Vuksanu Njegu

za venu ljubav, strpljenje i podrku.
Sadraj
DEO I
UVOD U POSLOVNE INFORMACIONE SISTEME
1. OSNOVNI KONCEPTI POSLOVNIH

INFORMACIONIH SISTEMA
1.1. OPTA TEORIJA SISTEMA
2
2
1.2. INFORMACIONI SISTEMI
1.3. INFORMACIONA TEHNOLOGIJA

1.4. AUTOMATIZOVANI ALATI I TEHNOLOGIJE
1.4.1. Evolucija CASE tehnologije
1.4.2. Automatizovani alati
5
6
8
8
2. ARHITEKTURA INFORMACIONIH SISTEMA

2.1. BLOKOVI ZNANJA
2.2. BLOKOVI PROCESA
2.3. BLOKOVI KOMUNIKACIJE
11
12
15
17
3. POSLOVNI INFORMACIONI SISTEMI

3.1. ERP SISTEMI
3.2. KORISTI OD ERP SISTEMA
3.3. ERP MODULI
3.4. ANALIZA TROKOVA I KORISTI ZA ERP
3.5. POSLOVNI INFORMACIONI SISTEMI I
STRATEKA PREDNOST
20
21
23
25
27
29
DEO II
RAZVOJ POSLOVNIH INFORMACIONIH SISTEMA
35
4. METODOLOKE OSNOVE RAZVOJA

36
III
4.1. MODELI I MODELIRANJE

4.2. STRATEGIJE SISTEMSKE ANALIZE
4.3. REINENJERING I MODELIRANJE PROCESA
4.3.1. Dijagram toka podataka
4.3.2. Renik podataka
4.3.3. IDEF0 funkcionalno modeliranje
4.4. MODELIRANJE PODATAKA I ANALIZA
4.4.1. Osnovni pojmovi modela podataka
4.4.2. Modeliranje podataka
4.4.3 IDEF1X standard za modeliranje podataka
4.4.4. Analiza modela podataka
Prva normalna forma
Druga normalna forma
Trea normalna forma
Boyce-Coddova normalna forma
etvrta normalna forma
Peta normalna forma
Normalna forma kljueva i domena (DK/NF)
Sinhronizacija sistemskih modela
4.5. OBJEKTNO-ORIJENTISANA ANALIZA I
MODELOVANJE
4.5.1. Jedinstveni jezik modelovanja - UML
4.5.2. Proces objektnog modelovanja
5. RAZVOJ POSLOVNIH REENJA PREMA MSF OKVIRU
5.1. MSF DISCIPLINE
5.1.1. MSF procesni model
5.1.2. MSF timski model
5.1.3. Upravljanje kompromisima
5.2. TEHNIKE PRIKUPLJANJA INFORMACIJA I
ANALIZIRANJE POSLOVNIH PROBLEMA I ZAHTEVA
5.2.1. Tehnike za prikupljanje informacija
5.2.2. Analiza poslovnih problema
5.2.3. Analiza zahteva
5.3. MODELOVANJE SISTEMSKIH ZAHTEVA
SLUAJEVIMA KORIENJA
IV
37
40
41
45
53
56
61
61
69
71
75
77
80
81
82
84
85
86
87
88
92
105
108
109
112
113
115
116
119
125
130
132
5.3.1. Model sluajeva korienja

5.3.2. Modelovanje zahteva sluajevima korienja
5.4. ANALIZA IZVODLJIVOSTI REENJA I
UPRAVLJANJE RIZICIMA
5.4.1. Faza denisanja vizije
5.4.2. Analiza rizika
5.4.3. Kategorije izvodljivosti projekta
5.5. KREIRANJE FUNKCIONALNE SPECIFIKACIJE
POSLOVNOG REENJA
5.5.1. Faza planiranja prema MSF-u
5.5.2. Konceptni dizajn
5.5.3. Logiki dizajn
Analiza kandidatnih tehnologija
Dokumentovanje logikog dizajna
Optimizacija logikog dizajna
5.5.4. Fiziki dizajn
Projektovanje sloja prezentacije
Projektovanje sloja aplikacije
Projektovanje sloja podataka
Projektovanje bezbednosti
Kompletiranje faze planiranja
5.6. STABILIZACIJA I UVOENJE REENJA
5.6.1. Voenje pilot reenja
5.6.2. Faza uvoenja reenja
6. METODOLOGIJA IMPLEMENTACIJE ERP REENJA
6.1. PROCES RAZVOJA ERP SISTEMA
6.2. ASAP METODOLOGIJA IMPLEMENTACIJE
SAP SISTEMA
132
134
147
147
159
162
168
170
172
179
180
183
187
187
197
201
204
218
222
225
230
231
233
233
237
DEO III
ANALITIKI POSLOVNI INFORMACIONI SISTEMI
7. SKLADITE PODATAKA
7.1. RAZVOJ SKLADITA PODATAKA
249
250
253
V
7.2. PRIMENA SKLADITA PODATAKA
258
8. OLAP SISTEMI
8.1. ARHITEKTURE OLAP SISTEMA
8.1.1. Viedimenzioni OLAP (MOLAP)
8.1.2. Relacioni OLAP (ROLAP)
8.1.3. Hibridni OLAP (HOLAP)
261
267
267
268
270
9. OTKRIVANJE ZNANJA I DATA MINING

9.1. TEHNIKE DATA MINING-A
9.2. WEB MINING
272
274
284
10. POSLOVNA INTELIGENCIJA

10.1. KORACI RAZVOJA BI PROJEKTA
286
288
DEO IV
MODULI POSLOVNIH INFORMACIONIH SISTEMA
VI

11. ERP SISTEMI: PRODAJA I MARKETING
11.1. MODULI PRODAJE I MARKETINGA U
ERP SISTEMIMA
11.2. ERP I UPRAVLJANJE ODNOSIMA SA
KLIJENTIMA (CRM)
317
318
12. ERP SISTEMI: RAUNOVODSTVO I FINANSIJE
324
13. ERP SISTEMI: PROIZVODNJA I UPRAVLJANJE

MATERIJALIMA
13.1. SAP R/3 ERP REENJE
326
331
14 .ERP SISTEMI: LJUDSKI RESURSI
336
15. MENADMENT LANCA SNABDEVANJA I

ELEKTRONSKO TRITE
337
320
322
Predgovor
ZATO PROUAVATI POSLOVNE INFORMACIONE SISTEME?
Informacione tehnologije (IT) ne spadaju vie u resurse organizacije, ve postaju poslovno okruenje. Informacioni sistemi (IS) formiraju
jedan integralni deo moderne organizacije i poslovanja. Informacioni
sistemi se koriste kao podrka svim aspektima organizacionih funkcija i
aktivnosti. Meutim, koristi od novih tehnologija se mogu postii jedino
ukoliko su usmereni ka organizacionim ciljevima.
Moderno poslovno okruenje zahteva i novi tip menadera koji
kombinuje menaderske vetine sa ekspertizom u oblasti IT-a. Takav
menader treba da:
denie strategiju IS bilo za radnu grupu, odeljenje ili kompaniju;
identikuje potencijalnu potrebu za IS kako bi poboljao performanse kompanije;
izabere i nabavi novi IS od odgovarajuih vendora;
nadgleda razvoj i implementaciju novih sistema;
upravlja IS kako bi se obezbedila efektivnost u pruanju kvalitetne
informacije krajnjim korisnicima.
CILJEVI
Knjiga Poslovni informacioni sistemi treba da poslui kao vodi u
odabiru pravih poslovnih informacionih reenja za organizaciju, njihovom adekvatnom razvoju i efektivnom upravljanju. Knjiga je zamiljenja da bude jedini izvor za studente dodiplomskih studija Fakulteta za
poslovnu informatiku Univerziteta Singidunum, koji prouavaju poslovne informacione sisteme, bez potrebe da nabavljaju razliite knjige
koje pokrivaju teme kao to su Sistemska analiza i projektovanje, Strategije razvoja IS, Enterprise Resource Planning (ERP), Analiza zahteva
i denisanje arhitekture reenja, Modeliranje informacionih sistema,
Data warehousing, OLAP sistemi, Data Mining i dr.
VII
Nakon savladavanja ove knjige, studenti e se osposobiti da:

razvijaju projektni plan razvoja i implementacije poslovnog reenja;
analiziraju faktore rizika uvoenja poslovnog reenja;
procenjuju i izaberu adekvatno IT reenje;
aktivno uestvuju u svim segmentima IT projekta;
analiziraju module poslovnog reenja i njihove veze;
efektivno komuniciraju sa IT strunjacima sa kojima sarauju na
projektu;
koriste IT da bi pristupali izvorima informacija.
STRUKTURA KNJIGE
Knjiga je podeljena u etiri dela, gde svaki deo pokriva razliite aspekte upotrebe poslovnih informacionih sistema unutar organizacije:
Deo 1: Uvod u poslovne informacione sisteme fokusira se na
osnovne koncepte i termine koji opisuju komponente poslovnih
informacionih sistema; sagledava se arhitektura IS i analiziraju
karakteristike, koristi, moduli i strateka prednost poslovnih informacionih sistema.
Deo 2: Razvoj poslovnih informacionih sistema bavi se prouavanjem razliitih metodologija i okvira razvoja IS, polazei od
prikupljanja informacija i analize poslovnih problema i zahteva,
preko modelovanja sistemskih zahteva, reinenjeringa poslovnih
procesa, analize izvodljivosti reenja i upravljanja rizicima, kreiranja logikog i zikog dizajna do implementacije, stabilizacije i
uvoenja IS u poslovno okruenje. U ovom delu se takoe razmatraju metodologije implementacije gotovih poslovnih reenja.
Deo 3: Analitiki poslovni informacioni sistemi - opisuje analitiki deo poslovnih informacionih sistema koji obuhvata data
warehousing, data mining, OLAP sisteme, odnosno jednom reju
poslovnu inteligenciju (Business Intelligence) organizacije.
Deo 4: Moduli poslovnih informacionih sistema - prikazuje
modularne poslovne informacione sisteme kao to su prodaja i
marketing, raunovodstvo i nansije, proizvodnja i upravljanje
materijalima, ljudski resursi i uopte menadment lanca snabdevanja i elektronsko trite.
VIII
Plan knjige
IX
DEO I:
UVOD U POSLOVNE
INFORMACIONE SISTEME
CILJEVI POGLAVLJA
Sve organizacije razvijaju informacione sisteme. Bez obzira na vae
zanimanje u bilo kom poslovanju, zasigurno ete uestvovati u nekom
od segmenata razvoja informacionog sistema, bilo kao klijent ili korisnik tih sistema bilo kao sistem analitiar, programer ili sl. Metode koje
ete nauiti, itajui ovu knjigu, mogu se primeniti na razliite domene
problema, a ne samo na one koji ukljuuju raunar. Sistemski razvoj nije
magija koja reava sve probleme, ne postoji savreni alati, tehnike niti
metode koje garantuju da e projekat razvoja IS biti uspean. Meutim,
kompletna i konzistentna primena ovih vetina vodi ka dugoronoj strategiji uspenosti poslovanja.
Pre nego to krenete da uite odreene metode, tehnike, alate i tehnologije, neophodno je da razumete osnovne pojmove, koncepte i da
uopte steknete globalnu sliku o razvoju informacionih sistema. Prvi deo
ove knjige vas uvodi u fundamentale koncepte, lozoje i trendove koje
ine osnovu za dalju nadogradnju i primenu praktinih alata i tehnika
koje ete nauiti u drugom delu ove knjige.
Nakon prouavanja ovog poglavlja, znaete da:
objasnite ta su sistemi, informacioni sistemi i informacione tehnologije;
objasnite ta su CASE alati;
ukratko objasnite sve procese (blokove) razvoja celokupnog informacionog sistema prema razliitim fokusima na sistem;
obrazloite pojam poslovnih informacionih sistema i ERP reenja;
sagledate module ERP reenja, analizirate trokove i koristi za ERP
sistem;
sagledate strateke prednosti implementiranjem poslovnog informacionog sistema.
1. Osnovni koncepti poslovnih informacionih

sistema
1.1. Opta teorija sistema

Opta teorija sistema predstavlja naunu oblast koja se bavi izuavanjem
sistema i zakonitosti koje u njima nastaju. Jedna od najvanijih karakteristika teorije sistema jeste u pristupu, u okviru koga se svaka celina posmatra kao deo neke vee celine. Nastajanje opte teorije sistema dovelo je
do stvaranja sistemskog pristupa, kao i do novih tehnika i metoda analize
sistema. Kada se upotrebi termin sistemski pristup, tada se naglaava da
se svi predmeti i pojave posmatraju u njihovoj dinaminosti i celovitosti
u odnosu na okruenje.
Cilj opte teorije sistema je da slui kao jedinstveni metodoloki i
pojmovno-kategorijalni okvir sporazumevanja ljudi razliitih specijalnosti. Takoe, njen cilj je da obuhvati i objedini fundamentalne pojmove koji
vae u svim specinim sistemima i teorijama koje se njima bave. Imajui
u vidu optu teoriju sistema, u daljem tekstu denisae se pojam sistema
i navesti njegove karakteristike.
Sistem se najoptije denie kao skup objekata (entiteta) i njihovih
meusobnih veza usmerenih ka ostvarivanju zajednikog cilja. Objekti
u sistemu mogu da budu neki ziki objekti, koncepti, dogaaji i sl. Objekti
u sistemu se opisuju preko svojih svojstava koja se nazivaju atributima.
Skup objekata koji predstavlja posmatrani sistem denie granice sistema.
Sve izvan granica sistema se naziva okolina ili okruenje sistema. Dejstvo
okoline na sistem opisuje se preko ulaza u sistem, a dejstvo sistema na
okolinu preko njegovih izlaza, kao to je ilustrovano na slici 1.1.
Dinamiko ponaanje realnog sistema standardno se predstavlja na
sledei nain: ulazi u sistem menjaju stanja sistema. Stanje sistema se denie
kao skup informacija o prolosti i sadanjosti sistema potrebnih da bi se,
pod dejstvom buduih poznatih ulaza, mogli odrediti budui izlazi. U stanju
sistema koncentrisana je celokupna istorija realnog sistema. Izlazna transformacija denie neki nain merenja ili posmatranja dinamikog ponaanja
realnog sistema i daje, na osnovu stanja sistema, njegove izlaze.
2
POSLOVNI INFORMACIONI SITEMI
Slika 1.1. Opta definicija sistema
Svaki sistem mogue je dekomponovati na podsisteme. Istovremeno,

svaki sistem je deo nekog ireg sistema. Hijerarhinost se mora uzeti u
obzir prilikom istraivanja: ponaanja, funkcionisanja, razvoja i upravljanja
sistemima. Sistemi ne egzistiraju izolovani, ve tee da budu otvoreni
sistemi. Otvorenost predstavlja komunikaciju izmeu objekata sistema i
objekata iz njegovog okruenja.
1.2. Informacioni sistemi

Terminologija pojmova u okviru informacionih sistema varira od autora
do autora, meutim veina strunjaka se slae u sledeim denicijama:
Podatak je kodirana predstava o nekoj injenici iz realnog sveta. On je
nosilac informacija i slui za tehniko uobliavanje informacija, kako bi
se one mogle sauvati ili preneti. Pojedinani podaci sami za sebe nemaju
nikakvo znaenje ili ga imaju veoma malo.
Informacija je protumaeni podatak o pojavi koju podatak prikazuje.
Drugim reima, informacija je preien, organizovan i obraen podatak
u smislenom kontekstu. Informacija je resurs koji je kreiran od podataka,
da bi koristio menadmentu pri donoenju poslovnih odluka. Sposobnost
menadmenta da prikuplja i uopte upravlja podacima i informacijama
postao je kritian faktor uspenosti poslovanja.
Znanje se gradi na temelju novih informacija koje se nadovezuju na
postojee znanje. Razliiti ljudi mogu razliito interpretirati informacije
u zavisnosti od njihovog znanja.
Polazei od tumaenja pojma sistema, proizilazi opta denicija informacionog sistema. Informacioni sistem (IS) se moe denisati kao sistem
u kome se veze izmeu objekata i veze sistema sa okolinom ostvaruju
razmenom informacija. Detaljnije obrazloenje pojma informacionog
sistema jeste da predstavlja ureeni i integrisani skup podataka, procesa, interfejsa, mrea, tehnologija i ljudi koji su u meusobnoj korelaciji u cilju podrke i poboljanja svakodnevnih poslovnih operacija
i podrke menadmentu u reavanju poslovnih problema, planiranja,
upravljanja, predvianja, koordinisanja i donoenja odluka.
Informacioni sistem treba da bude model realnog sistema u kome deluje (Slika 1.2). Ulazi u sistem menjaju stanje sistema, a ova promena se
reektuje na izlaz. Preslikavanje realnog sistema u informacioni sistem
izvodi se postupkom modeliranja realnog sistema.
Slika 1.2. Poloaj informacionog sistema u odnosu na realni sistem
Za veinu ljudi, sistemi su preveliki i kompleksni da bi se shvatili u

celosti, na primer, inenjeri koji prave automobile kreiraju modele pre
nego to naprave nova kola, arhitekte prave modele zgrada koje projektuju
itd. Poslovni informacioni sistemi se ne mogu razumeti bez modela koji
predstavljaju sisteme u njihovoj realnosti.
1.3. Informaciona tehnologija

Informacione tehnologije su deo razvojne strategije informacionih
sistema, te se stoga ovde ukratko obrazlau.
Informacione tehnologije (IT) opisuju kombinaciju raunarske
tehnologije (hardware i software), telekomunikacione tehnologije,
netware, groupware i humanware:
Hardware podrazumeva ziku opremu kao to su mehaniki,

magnetski, elektronski ili optiki ureaji.
Software ukljuuje predenisane instrukcije koje kontroliu
rad raunarskih sistema ili elektronskih ureaja. Softver koordinira rad hardverskih komponenata u jednom informacionom
sistemu. Softver inkorporira standardne softvere kao to su operativni sistemi ili aplikacije, softverske procese, vetaku inteligenciju, inteligentne agente i korisniki interfejs.
Telekomunikacije podrazumevaju prenos signala du razliitih
distanci koji ukljuuju i prenos podataka, slika, glasova, koristei
radio, televiziju, telefoniju i druge komunikacione tehnologije.
Netware podrazumeva opremu i softver neophodne za razvoj
i podrku mree raunara, terminala i komuniokacionih kanala i
ureaja.
Groupware predstavlja komunikacione alate kao to su e-mail,
videokonferencije i dr., koji podravaju elektronsku komunikaciju i kolaboraciju izmeu grupa.
Humanware podrazumeva intelektualne kapacitete neophodne
za razvoj, programiranje, odravanje i rukovanje tehnologijom.
Humanware inkorporira znanje i ekspertizu.
Mnoge promene u projektovanju poslovnih procesa, reinenjeringu
i deljenju informacionih resursa su znatno olakane implementacijom
informacione tehnologije. Integrisane baze podataka, gde organizacione
jedinice dele zajednike podatke koje se odravaju u centralnoj bazi podataka, predstavljaju osnovu za poslovne informacione sisteme. Mnoge
su prednosti integrisanja baza podataka, kao to su poboljana konzistentnost, integritet, nezavisnost i deljenje podataka i smanjena redundantnost podataka.
1.4. Automatizovani alati i tehnologije

Celokupna dananja informaciona tehnologija je usmerena ka podrci
onima koji se bave razvojem informacionih sistema. Ta tehnologija se naziva sistemski inenjering pomou raunara (Computer-Assisted Systems
Engineering CASE). CASE alati su programi (softveri) koji automatizuju i podravaju jednu ili vie faza ivotnog ciklusa razvoja sistema.
Namera ove tehnologije jeste da ubrza procese razvoja sistema i pobolja
njihov kvalitet.
CASE nije metodologija niti bilo kakva njena alternativa. CASE je
tehnologija koja podrava metodologije naroito strategije, tehnike i standarde. CASE tehnologija automatizuje celokupnu metodologiju razvoja
sistema.
Neki ovu tehnologiju nazivaju softverski inenjering pomou raunara
(computer-aided software engineering), meutim treba imati u vidu da je
softver samo jedna komponenta informacionog sistema, pa se stoga ovde
koristi iri pojam - sistem.
U centru bilo koje arhitekture CASE alata se nalazi baza podataka
koja se naziva CASE repozitorijum (repository) (Slika 1.3). Oko CASE
repozitorijuma se nalazi kolekcija alata koji kreiraju sistemske modele i
dokumentaciju. Koncept repozitorijuma podrazumeva skladite podataka
koji obuhvata specikacije, dokumentacije i druga znanja, koja se stvaraju
tokom sistemskog razvoja projekta. Iskustvo je pokazalo da veinu ljudi,
kod CASE alata, prvo privuku njegove grake mogunosti. Meutim,
prava snaga CASE alata jeste u njenom repozitorijumu. CASE repozitorijum je baza podataka onih koji razvijaju sistem. To je mesto gde se
skladite dijagrami, opisi, specikacije i drugi elementi koji se pojavljuju u
toku razvoja sistema. Mnogi razliiti CASE alati mogu da dele informacije
putem jedinstvenog repozitorijuma. Da bi se mogao koristiti repozitorijum,
CASE alati obezbeuju kombinaciju sledeih alata (Slika 1.3):
Dijagramski alati (Diagramming tools) se koriste za crtanje
sistemskih modela.
Renik alati (Dictionary tools) se koriste za snimanje, brisanje,
izmenu i prikazivanje detaljne dokumentacije i specikacije. Opisi
su obino pridrueni elementima sistemskih modela koji su prethodno iscrtani dijagramskim alatima.
6
tampa
Sistem analitiar
CASE radna stanica i softver
Dijagramski alati
sistemski
modeli
Alati za
upravljanje
kvalitetom
Alati za
projektovanje
Renik alati
opisi i
specifikacije
sistema
prototipovi
sistema
izvetaj
o
kvalitetu
Dokumentacioni
alati
projektna i
sistemska
dokumentacija
Alati za
generisanje koda
i dizajna
programski kod i
modeli
CASE
repozitorijum
CASE repozitorijum je
obino smeten na
serverima tako da ga
mogu deliti razliiti
uesnici na projektima
Slika 1.3. Arhitektura CASE alata
Alati za projektovanje (Design tools) se koriste za projektovanje komponenata sistema ukljuujui ulaze (inputs) i izlaze
(outputs).
Alati za upravljanje kvalitetom (Quality management tools)
analiziraju i utvruju konzistentnost i kompletnost modela, opisa i
dizajna. Ukoliko doe do pojave greke, CASE alati ih identikuju
i obavetavaju korisnike.
Dokumentacioni alati (Documentation tools) se koriste za sakupljanje, organizaciju i izvetavanje neophodne dokumentacije iz
repozitorijuma.
Alati generatora koda i dizajna (Design and code generator tools)
automatski generiu dizajn baze podataka iz modela podataka,
aplikacione programe ili znaajne delove ovih programa.
1.4.1. Evolucija CASE tehnologije

CASE alati datiraju jo od sredine 1970-tih godina. Pod projektom ISDOS, voenog od strane dr Daniela Teichrowe sa Miigen Univerziteta,
je razvijen jezik za iskazivanje problema (Problem Statement Language PSL) koji je sluio za opisivanje korisnikih problema i zahteva. Drugi jezik
Problem Statement Analyzer (PSA) je kreiran da analizira ove probleme i
zahteve. PSL/PSA su se aktivirali sa velikih mainframe raunara i iziskivali
su veoma skupe raunarske resurse, tako da je malo koja kompanija tada
mogla sebi da priuti adekvatne raunarske resurse za PSL/PSA.
Preokret je nastao sa pojavom personalnih raunara (PC) kada je 1984.
godine jedna kompanija, koja se tada zvala Index Technology (danas poznata kao Intersolv), kreirala PC softverski alat koji se zvao Excelerator, iji
uspeh je postavio CASE akronim. U dananje vreme, onima koji se bave
razvojem sistema, na raspolaganju su hiljade CASE proizvoda.
CASE tehnologija je neverovatno slina drugim inenjerskim tehnologijama, kao to su projektovanje pomou raunara (Computer-Aided Design
- CAD) ili proizvodnja pomou raunara (Computer-Aided Manufacturing - CAM). Savremeni inenjeri koriste CAD alate da projektuju i analiziraju nove proizvode. CAM alati onda automatski generiu raunarske
programe koje e aktivirati neophodnu maineriju za proizvodnju datog
dizajna. Kao to CAD/CAM radi za inenjere, tako i CASE radi za one
koji se bave razvojem informacionih sistema.
1.4.2. Automatizovani alati

Postoje tri klase automatizovanih alata za developere:
modeliranje sistema pomou raunara (computer-aided systems
modeling)
okruenje za razvoj aplikacija (application development environments)
upravljanje projektima i procesima (project and process management)
Dananji CASE alati omoguavaju dva razliita pristupa za razvoj
sistemskih modela i to (Slika 1.4):
8
inenjering unapred (forward engineering) - sposobnost CASE

alata da generie inicijalni softver ili kd baze podataka direktno
iz sistemskih modela.
reverzni inenjering (reverse engineering) - sposobnost CASE
alata da automatski generie inicijalne sistemske modele iz softvera
ili kda baze podataka.
Slika 1.4. Inenjering unapred/reverzni
Reprezentativni primeri CASE alata su: BPWin, ERWin, System Architect, Rational ROSE UML, DataArchitect, Oracle Designer, SmartDraw,
Power Designer i mnogi drugi.
OKRUENJE ZA RAZVOJ APLIKACIJA
Okruenje za razvoj aplikacija (Application Development Environment ADE) je jedan integrisani alat za brzi i kvalitetan razvoj softvera.
Sinonim za ADE je Integrated Development Environment (IDE). ADE
ini programiranje jednostavnijim i ekasnijim. Uglavnom obebezbeuju
sledee alate:
programske jezike i interpretere ine srce svakog okruenja
za razvoj aplikacija. Moni alati za ukazivanje na greke u kodu
(debugging) i pomo pri njihovom otklanjanju pomau programerima da brzo identikuju i ree probleme.
alate za dizajniranje interfejsa pomau programerima da,
ko-ristei biblioteku komponenti, brzo naprave korisnike interfejse.
middleware softver koji pomae programerima da integriu
softver za drugim bazama podataka i raunarskim mreama.

alate za testiranje koriste se za pravljenje i izvravanje test
skriptova koji mogu konzistentno i potpuno da testiraju softver.
alate za kontrolu verzija pomau programerskim timovima da
upravljaju viestrukim verzijama programa, kako u toku razvoja
tako i nakon implementacije.
alate za pomo (Help) - koriste se za pisanje on-line sistema za
pomo, korisnikih prirunika i za on-line obuavanje.
repozitorijum link dozvoljava ADE da se integrie sa razliitim
CASE alatima, kao i sa drugim ADE i razvojnim alatima.
Reprezentativni primeri okruenja za razvoj aplikacija su: Microsoft
Visual Studio.net (VB.net, C#.net, J#.net), Oracle Developer, IBM Websphere (Java), Inprise1 J Builder (Java), Macromedia Cold Fusion, Sybase
Powerbuilder i mnogi drugi.
UPRAVLJANJE PROCESIMA I PROJEKTIMA
Trea klasa automatizovanih alata pomae kod upravljanja metodologijom razvoja sistema i projektima koji koriste metodologiju. Dok
CASE alati i ADE podravaju analizu, projektovanje i izgradnju novih
informacionih sistema i softvera, aplikacije upravljanja procesima i projektima podravaju ivotni ciklus aktivnosti.
Aplikacija upravljanja procesom (Process manager application)
je automatizovan alat koji pomae pri dokumentaciji i upravljanju metodologijama, njihovim isporukama i standardima upravljanja kvalitetom.
Aplikacija upravljanja projektom (Project manager application) je
automatizovan alat koji pomae u planiranju aktivnosti razvoja sistema,
ocenjuje i dodeljuje resurse (ukljuujui ljude i trokove), rasporeuje aktivnosti i resurse, prati napredovanje prema zadatom rasporedu i budetu,
kontrolie i modikuje rasporede i resurse i izvetava o napredovanju
projekta. Neki od primera automatizovanih alata za upravljanje projektima su Microsoft Project, Applied Business Tecnology - Project Manager
Workbench i dr.
10
Ex Borland.
2. Arhitektura informacionih sistema
Arhitektura informacionih sistema obezbeuje jedinstveni okvir (framework) po kome e razliiti ljudi sa razliitim pogledima organizo-vati fundamentalne blokove razvoja informacionih sistema (Slika 2.1). Pretpostavimo
da elite da razvijate jedan informacioni sistem. Razliiti ljudi e imati
razliite poglede na sistem. Menaderi, korisnici, tehnika lica, svi oni e
posmatrati sistem na razliit nain i sa razliitim nivoom detalja. Ove ljude
nazivamo nosiocima informacionog sistema, odnosno stakeholders-ima.
Oni se grubo mogu klasikovati u etiri grupe [7]:
Vlasnici sistema (System Owners) nansiraju razvoj i odravanje

informacionog sistema. Oni poseduju sistem, postavljaju viziju i
prioritete u sistemu.
Korisnici sistema (System Users) su ljudi koji za obavljanje svojih
poslova, koriste informacioni sistem. Pored internih korisnika
sistema, koji rade unutar jedne organizacije, tu spadaju i eksterni
korisnici kao to su klijenti, vendori, partneri i oni zaposleni koji
rade sa udaljenih lokacija, na primer sa terena ili od kue. Danas
korisnici sistema rade rame uz rame sa projektantima sistema.
Projektanti sistema (System Designers) projektuju sistem kako bi
izali u susret zahtevima korisnika. Oni projektuju baze podataka, ekrane, mree, programe i dr. Tu sapadaju administratori baza
podataka, mrea, Web dizajneri, eksperti za bezbednost i drugi
tehniki strunjaci. U nekim sluajevima, projektanti sistema
mogu biti i tzv. graditelji sistema.
Graditelji sistema (System Builders) su tehnika lica koja konstruiu, testiraju, isporuuju, uvode i odravaju informacioni
sistem. Neki od njih su programeri aplikacija, sistem programeri,
Webmaster-i (oni koji kodiraju i odravaju Web servere), sistem
integratori (integriu softverske pakete sa hardverom, mreama i
drugim softverskim paketima) i dr.
11
Kao to je prikazano na slici 2.1., svaka grupa stakeholders-a je jedan

red u okviru informacionog sistema i moe se videti, da generalno postoje
etiri pogleda na informacione sisteme, a to su pogledi vlasnika, korisnika,
projektanata i graditelja.
Njihovi pogledi se u mnogome razlikuju, dok su jedni fokusirani na optu
sliku, drugi su zainteresovani za detalje, neiji pogledi su ne-tehniki, dok
su drugi vrlo tehniki. Sistem analitiar premoava komunikacioni jaz
izmeu onih kojima trebaju raunari i onih koji dobro poznaju tehnologiju.
On je odgovoran za prikazivanje krajnjim korisnicima i menadmentu
kako nova tehnologija moe poveati efektivnost njihovog poslovanja i
njihovih operacija. Sinonimi, u svetu, za sistem analitiara su: arhitekta
sistema, sistem inenjer, informacioni inenjer, informacioni analitiar ili
sistem integrator.
Razliiti stakeholders-i se mogu usredsrediti na razliite aspekte sistema:
Znanje poslovno znanje treba da pomogne menaderima u
do-noenju inteligentnih odluka. Cilj je poboljanje baze znanja u
organizaciji.
Procesi aktivnosti koje izvravaju misiju poslovanja. Cilj je poboljanje poslovnih procesa i usluga.
Komunikacije interfejs sistema sa korisnicima i drugim informacionim sistemima. Cilj je poboljanje poslovne komunikacije.
Preseci pogleda (redova) i svakog fokusa (kolona) deniu fundamentalne blokove informacionog sistema (Slika 2.1). Blokovi informacionog
sistema ne egzistiraju izolovano, ve moraju biti sinhronizovani kako bi
se izbegle nedoslednosti i nekompatibilnosti unutar sistema. Na primer,
projektant baze podataka i programer imaju svoj sopstveni pogled na
arhitetkturu sistema, ali ti pogledi moraju biti koordinirani i kompatibilni,
da bi sistem bio uspean.
2.1. Blokovi znanja

Kada inenjeri projektuju jedan proizvod, oni moraju da saine sastavnicu
tog proizvoda. Sastavnica ne govori o funkciji tog proizvoda, ve o njegovim
sastavnim delovima, odnosno pokazuje koje su to sirovine, poluproizvodi
i druge komponente koje uestvuju u izgradnji nalnog proizvoda. Ista
analogija se koristi i za informacione sisteme. Podaci se mogu posmatrati
kao sirovine koje se koriste da bi se proizvele informacije.
12
Slika 2.1. Fundamentalni blokovi informacionih sistema1
Podaci se mogu smatrati kao jedan od primarnijih blokova razvoja informacionog sistema. Ovde je cilj prikupiti i uskladititi podatke korienjem
adekvatne tehnologije baze podataka, koja e znatno olakati njihovo
uvanje i upravljanje.
1
Izvor: Whitten, J.L., L.D. Bentley, K.C. Dittman (Profesori sa Purdue Univerziteta, West
Lafayette, IN), Systems analysis and design methods, esto izdanje, Irwin McGraw-Hill, New
York, 2004, adaptirano.
13
POGLED VLASNIKA SISTEMA NA SISTEM PODATAKA

Prosean vlasnik sistema, obino nije zainteresovan za sirove podatke.
Vlasnik je zainteresovan za resurse poslovanja, koje ine kupci, proizvodi, oprema, zgrade, porudbine ili plaanja. Njegov domen jeste da za
svaki objekat i relacije izmeu objekata identikuje eventualne probleme,
mogunosti, ciljeve i ogranienja. Zajedno ti podaci ine kompletan kontekst podataka za informacioni sistem.
Na primer, za jedan sistem prodaje, objekti su Kupci, Proizvodi, Prodajni regioni, Porudbine i Komercijalisti. Za date objekte treba prikupiti
i uskladititi podatke. Slino tome, relacije se mogu izraziti jednostavnim,
deklarativnim reenicama kao to su:
Kupci dostavljaju porudbine.

Porudbine prodaju proizvode.
Kupci su locirani po prodajnim regionima.
Vlasnici sistema su veoma retko zainteresovani za detaljnije podatke u
vezi objekata i relacija, sem ukoliko nisu i korisnici sistema.
POGLED KORISNIKA SISTEMA NA SISTEM PODATAKA
Korisnici informacionog sistema su eksperti za podatke koji opisuju
poslovni sistem. Oni kao informacioni radnici svakodnevno prikupljaju,
skladite, obrauju, ureuju i koriste te podatke. Za njih su podaci smeteni
po fasciklama, knjigama, organizovani po spreadsheets datotekama ili
uskladiteni unutar baza podataka. Izazov u sistemskoj analizi jeste da
se identikuju i verikuju zahtevi za podacima. Zahtevi za podacima su
neophodni korisniki podaci koji se predstavljaju u obliku objekata, atributa, relacija i pravila.
Razmotrimo sledei primer. Vlasnik sistema eli da ima sve podatke o
objektu Kupac. Korisnik sistema e nas upozoriti o tome da treba razlikovati Potencijalne kupce, Stvarne kupce i Neaktivne kupce, zbog razliitih
tipova podataka koji opisuju svaki tip kupca. Takoe, korisnik sistema e
nam rei koji su to podaci koji se moraju skladititi za svaki tip kupca. Na
primer, objekat Aktivan kupac e imati sledea svojstva: ifra kupca, naziv,
adresa, kredit i tekui bilans kupca. Za opisivanje zahteva za podacima
koristi se model podataka.
14
POGLED PROJEKTANTA SISTEMA NA SISTEM PODATAKA

Dok korisnici sistema deniu zahteve za podacima, projektanti sistema
prevode te zahteve u baze podataka, koje e potom biti dostupne putem
informacionog sistema. Pogled projektanta sistema na sistem podataka
je u obliku eme baze podataka. Pored eme baze podataka, projektant bi
trebao da odgovori i na sledea pitanja: Koje baze podataka e se koristiti
(npr. Oracle 10g, IBM DB2, Microsoft SQL Server, itd)? Na kojoj platformi
e se instalirati (npr., UNIX, Linux, Windows itd)? Koje tehnologije e se
koristiti za smetanje podataka u OLAP baze podataka i skladita podataka
(npr., ETL - Extract Transform and Load)? itd.
POGLED GRADITELJA SISTEMA NA SISTEM PODATAKA
Graditelji sistema su najblii korisnici tehnologije baze podataka.
Oni moraju da predstavljaju podatke u veoma preciznoj jezikoj formi.
Najkorieniji standardni upitni jezik koji omoguava komunikaciju sa
bazom podataka jeste SQL (Structured Query Language).
2.2. Blokovi procesa

Kada inenjeri projektuju nov proizvod, taj proizvod bi trebao da obezbedi odgovarajui nivo funkcionalnosti ili usluge. Potencijalni kupci
deniu eljenu funkcionalnost proizvoda, a inenjer kreira dizajn proizvoda kako bi obezbedio datu funkcionalnost. Neke procese obavljaju
ljudi, a neke maine, ukljuujui i raunare. Neki procesi se ponavljaju,
dok se drugi odvijaju ne tako esto ili ak retko. Cilj je da se automatizuju odgovarajui procesi pomou softver tehnologije (Slika 2.1 druga
kolona). Kao to se vidi sa slike 2.1, razliiti stakeholders-i imaju razliite
poglede na procese sistema.
POGLED VLASNIKA SISTEMA NA PROCESE SISTEMA
Kao i obino vlasnici sistema su zainteresovani za grubu sliku, odnosno
u ovom sluaju za grupe procesa visokog nivoa nazvanih poslovne funkcije. Tipine poslovne funkcije su proizvodnja, raunovodstvo i nansije,
prodaja i marketing, ljudski resursi i druge.
15
Projektni timovi esto ove funkcije izraavaju u obliku jednostavnog, hijerarhijski dekomponovanog dijagrama. Vlasnici sistema e
pruiti informacije o zapaenim problemima, mogunostima, ciljevima
i ogranienjima funkcija. Takoe e eleti da diskutuju o trokovima i
koristima oko projektovanja informacionog sistema.
POGLED KORISNIKA SISTEMA NA PROCESE SISTEMA
Korisnici vide odvojene poslovne procese. Poslovni procesi su odvojene
aktivnosti koje imaju svoje ulaze i izlaze, kao i vremena poetka i zavretka.
Zahtevi za procesima su esto dokumentovani kao aktivnosti, tokovi
podataka ili poslova (workow). Specine politike i procedure obrazuju
osnovu ovih poslovnih procesa. Politike su pravila koje se primenjuju kada
se zavri poslovni proces. Procedure su instrukcije, logika i precizni koraci
koji moraju da se prate kako bi se izvrio poslovni proces.
Mnoge kompanije bi trebalo da reprojektuju poslovne procese kako
bi eliminisale redundansu i poveale ekasnost poslovanja. Reprojektovanje poslovnih procesa (Business Process Redesign - BPR) podrazumeva
prouavanje, analizu i reprojektovanje osnovnih poslovnih procesa u cilju
smanjenja trokova i poboljanja vrednosti poslovanja.
Izazov u sistemskoj analizi jeste da se identikujuju, izraze i analiziraju
zahtevi poslovnih procesa. Jedna od metoda sistemske analize, koja to
omoguava je model procesa.
POGLED PROJEKTANTA SISTEMA NA PROCESE SISTEMA
Pogled projektanta sistema na procese je isto tehniki. Njegove aktivnosti su ograniene speciranom tehnologijom razvoja aplikacija kao to
su Java, C#.net, J#, Visaul Basic.net i dr. Na osnovu datih poslovnih procesa
od strane korisnika sistema, projektant mora prvo da odredi koje procese
treba automatizovati i kako ih automatizovati na najbolji mogui nain.
Projektant u dogovoru sa programerima treba da da odgovor na pitanja:
Koja okruenja za razvoj aplikacija ili programski jezici e se koristiti za
pisanje softvera (npr., IBM Websphere sa Javom, Microsoft Visual Studio.
NET sa Visual C#, Syebase Powerbuilder, Oracle-ov Oracle Forms i dr.)?
Projektant priprema softversku specikaciju koja e da (1) ispuni poslovne zahteve korisnika sistema i (2) obezbedi dovoljno detalja i konzistencije
za prenoenje projekta graditeljima sistema.
16
Entropija je termin koji se koristi za opisivanje prirodnog i neizbenog

raspadanja sistema. Meutim, entropijom sistema se moe upravljati.
Dananji alati i tehnike omoguavaju da se projektuje sistem tako da moe
da se razvija i menja u skladu sa rastom i promenama zahteva.
POGLED GRADITELJA SISTEMA NA PROCESE SISTEMA
Graditelji sistema prikazuju procese koristei programske jezike ili
okruenja za razvoj aplikacija koji opisuju ulaze, izlaze, logiku i kontrolu.
Neki sistemi za upravljanje bazom podataka obezbeuju sopstvene ve
ugraenje programske jezike. Na primer, Visual BASIC for Applications
(sadran je u Access-u) i PL-SQL (koga sadri Oracle). Svi ovi jezici se
koriste za pisanje aplikacionih programa. Aplikacioni programi su jezikizasnovani, mainski-itljivi prikazi o tome ta bi raunarski proces trebao
da radi ili kako bi raunarski proces trebao da ostvari svoje zadatke.
2.3. Blokovi komunikacije

Zaponimo istim primerom kao i kod blokova znanja i procesa. Kada
inenjer projektuje jedan nov proizvod, taj proizvod bi trebao da se lako
naui i koristi. Informacioni sistemi moraju da obezbede efektivan i
ekasan interfejs korisnicima sistema i drugim poslovnim informacionim
sistemima.
Zajedniki cilj kod veine organizacija jeste poboljanje poslovne komunikacije i kolaboracije izmeu zaposlenih i drugih uesnika u sistemu.
Poboljanje komunikacija u informacionim sistemima su usmerene na
dva kritina cilja:
informacioni sistemi moraju da obezbede efektivne i ekasne
komunikacione interfejse korisnicima. Takvi interfejsi treba da
podstiu timski rad i koordinaciju aktivnosti.
informacioni sistemi moraju da obezbede efektivne i ekasne interfejse ka drugim poslovnim informacionim sistemima.
17
POGLED VLASNIKA SISTEMA NA KOMUNIKACIJE

Vlasnici sistema su zainteresovani za globalnu sliku sistema i za njegove trokove i koristi. U ranoj fazi sistemskog razvoja projekta, vlasnici
sistema treba da odrede:
Sa kojim poslovnim jedinicama, zaposlenima, klijentima i spoljnim
objektima e novi sistem biti u interakciji?
Gde su locirane poslovne jedinice, zaposleni, klijenti i drugi poslovni
objekti?
Da li e sistem komunicirati sa drugim informacionim sistemima?
Odgovori na ova pitanja e pomoi u denisanju domena komunikacija
u projektu razvoja informacionog sistema. Vlasnici sistema e identikovati
i analizirati relevantne probleme, mogunosti i ogranienja.
POGLED KORISNIKA SISTEMA NA KOMUNIKACIJE
Korisnici sistema su zainteresovani za korisniki interfejs informacionog sistema. Korisniki interfejs denie kako korisnici sistema pristupaju
informacionom sistemu da bi uneli podatke, pravili upite, dobili izvetaje
i koristili help (pomo). Jedan od standarda korisnikog interfejsa jeste
grako korisniki interfejs (GUI Graphical User Interface). Tu se razlikuju Windows forme od Web formi u zavisnosti od toga da li aplikaciju
treba da podravaju i browser-i.
POGLED PROJEKTANTA SISTEMA NA KOMUNIKACIJE
Donekle su pogledi projektanta i korisnika sistema slini, jer su i jedni i
drugi ukljueni u dizajniranje ekrana, ulaznih i izlaznih podataka. Meutim,
dok su korisnici sistema zainteresovani za oblik i sadraj, projektant sistema
se bavi konzistencijom, kompletnou, korisnikim dijalogom i interfejs
tehnologijama. Projektant e se pozabaviti i sledeim pitanjima: Kako e
se razvijati korisniki interfejsi, da li sa MS Windows ili Web komponentama (npr., xHTML editor kao to je Macromedia Dreamweaver, portal
IBM Websphere i dr)? Kako e se razmenjivati podaci izmeu razliitih
informacionih sistema (npr., data broker IBM MQ Messaging ili XML)?
Korisniki dijalog u interakciji sa aplikacionim programom, opisuje kako
se korisnik pomera sa ekrana na ekran kako bi obavio zadatak. Projektant
sistema crta interfejs emu, koja denie osobine interfejsa, stanja sistema,
dogaaje koji menjaju stanje sistema i odzive na dogaaje.
18
POGLED GRADITELJA SISTEMA NA KOMUNIKACIJE

Graditelji sistema izgrauju, instaliraju, testiraju i implementiraju
korisnike i sistemske interfejse. Interfejs tehnologije su mahom ugraene
u okruenje razvoja aplikacija (Application Development Environment
ADE) kao to je na primer Visual Studio .NET.
Jedna od interfejs tehnologija je middleware. Middleware je koristan
softverski sloj koji se nalazi izmeu aplikacionog i sistemskog softvera, a
slui da transparentno integrie razliite tehnologije kako bi one mogle
da funkcioniu. Jedan primer middleware jeste povezanost otvorenih baza
podataka (Open Database Connectivity ODBC). ODBC alati dozvoljavaju
aplikacionim programima da rade sa razliitim sistemima za upravljanje
bazama podataka (Database Management Systems DBMS) bez potrebe
da budu preraeni usled nijansi i razliitosti sistema za upravljanje bazama
podataka. XAML (eXtensible Application Markup Language)1 postaje
standard za komunikaciju izmeu sistema.
XAML (izgovara: zammel) je deklarativni XML zasnovan jezik koji denie objekte, njihova
svojstva i meusobne veze u XML-u. XAML dinamiki kreira UI (user interface) za Windows Presentation Foundation (WPF). WPF je nova prezentacija API (Application Programming Interface) u .NET Frameworku 3.0 (bivi WinFX). WPF API ima irok domen funkcionalnosti, od Windows kontrola kao to su 3D graka, specijalni efekti i multimedija.
19
3. Poslovni informacioni sistemi
Imajui u vidu prethodno obrazloen pojam informacionih sistema dolazi

se do opte denicije poslovnih informacionih sistema. Poslovni informacioni sistemi su informacioni sistemi koji podravaju poslovne funkcije
i obezbeuju poslovnu inteligenciju i analitiku. Na primer, organizacija
moe koristiti odreeni informacioni sistem kako bi upravljala aktivnostima
prodaje, marketinga i ljudskim resursima. Poslovni informacioni sistemi se
oslanjaju na pet osnovih resursa:
Ljudski resursi ukljuuju korisnike IS i one koji razvijaju, odravaju i rukuju sistemom.
Hardverski resursi ukljuuju sve tipove maina, kao to su telefoni, ruteri, DVD-jevi, PDA (Personal Digital Assistant), raunari i
dr.
Softverski resursi ukljuuju raunarske programe, prirunike,
politiku kompanije i dr.
Komunikacioni resursi ukljuuju mree i neophodan hardver i
softver koji ih podrava.
Resursi podataka opisuju sve podatke kojima organizacija ima
pristup, bez obzira na njihovu formu. Ukljuuje baze podataka, fajlove, dosijee, fascikle i dr.
Tipine poslovne funkcije u nekom preduzeu su raunovodstvo,
pro-izvodnja, logistika, marketing, ljudski resursi i dr. U veini odeljenja
unutar organizacije postoje sopstveni informacioni sistemi, kao na primer
raunovodstveni informacioni sistem, marketing IS, kadrovski IS itd. Kada
sistem nije integrisan, donosioci odluka e vrlo teko izvui informacije iz
viestrukih sistema. Ukoliko odluke nisu zasnovane na integrisanoj informaciji, onda preduzee ne koristi sve prednosti koje takva informacija
moe da obezbedi.
20
3.1. ERP sistemi

Za veinu ljudi termin poslovni informacioni sistem podrazumeva ERP
softver, mada on inkorporira i CRM sisteme, SCM, PLM, SRM, alate za
optimizaciju poslovanja i dr.
ERP (Enterprise Resource Planning) sistem je poslovni softver
koji omoguava organizacijama da automatizuju i integriu glavne
poslovne procese, dele opte podatke i pristupaju informacijama u
realnom okruenju.
Preduzea moraju ekasno da kontroliu osnovne funkcije u svom
poslovanju, istovremeno, da uoavaju potrebe i planiraju strateke inicijative primenjujui nove tehnologije. ERP pomae organizacijama koje se
bave lancima nabavke, upravljanjem zalihama, upravljanjem porudbinama
klijenta, planiranjem proizvodnje, raunovodstvom, upravljanjem ljudskim
resursima i drugim poslovnim funkcijama.
ERP trite je trenutno jedno od najbre rastuih trita u softverskoj
industriji. ERP reenja predstavljaju znaajnu poslovnu investiciju koji
osiguravaju konkurentnost, osetljivost na zahteve klijenata i eksibilnost
u voenju poslovanja u globalnoj ekonomiji. ERP sistemi uvode najbolje
poslovne prakse koje se jednostavno deniu kao najbolji nain izvoenja
procesa. Implementiranje ERP reenja omoguava kompanijama da izvre
reinenjering poslovne prakse ka najboljoj praksi i integriu informacione resurse.
S obzirom na brzi porast integrisanih usluga, zahtevi projektovanja
postaju sve sloeniji i zahtevniji. Uspeh primene ERP reenja e zavisiti od
efektivnog menadmenta, organizacionih promena, primene naprednih
tehnologija i neophodnog nivoa znanja i vetina. Meutim, mnogi projekti
su propali usled toga to su ili voeni tehnolokim motivacijama umesto
poslovnim opravdanjem ili nisu iskoriavali sve potencijale implementiranog ERP reenja.
ERP softverski paketi su predstava poslovnih procesa. Ukoliko softver
ne odslikava postojee poslovne procese, onda bi trebalo promeniti ili
poslovne procese ili sam softver. Promene softvera zahtevaju dodatno
vreme i svaki put kada prodavac nadograuje (upgrade) softver, neophodno
je ponovo uraditi kastomizaciju (prilagoavanje) softvera. S druge strane,
ukoliko preduzee menja svoje poslovne procese onda i ljudi moraju da se
prilagoavaju, a ljudi ne vole promene. Ukoliko se promene ne prihvate dobro, zasigurno je da e implementacija softvera biti osuena na propast.
21
Adekvatno uvoenje poslovnog informacionog sistema omoguava

voenje poslovanja efektivnije i ekasnije, kao i bre reagovanje na promene
u okruenju ime se ostvaruje konkurentska prednost na tritu. Poslovni
IS imaju za cilj da skladite poslovne informacije samo jedanput, u
formi u kojoj se omoguava pristup od strane vie razliitih korisnika,
a u cilju donoenja razliitih tipova odluka.
Na domaem tritu, u poslednjih nekoliko godina, najzastupljeniji
ERP sistemi su: SAP R/3, Oracle Applications, Microsoft Dynamics NAV,
HansaWorld, Datalab PantheonTM i mnogi drugi.
EVOLUCIJA ERP SISTEMA

ezdesetih godina veina softverskih paketa je omoguavala samo
kontrolu zaliha, da bi se 70-tih godina uveli MRP (Material Requirements Planning) sistemi koji su se koristili za rasporeivanje proizvodnje
i ukljuivali su sastavnicu materijala sa listom materijala neophodnih
za proizvodnju svakog proizvoda. Kasnije, MRP sistemi su poboljani
uvoenjem alata za planiranje prodaje, obradu porudbina klijenata i
planiranje kapaciteta to je obezbeivalo input u redosled proizvodnje
poznatijeg kao zatvoreni (closed-loop) MRP. Osamdesetih godina, MRPII
sistemi ukljuuju sisteme za voenje nansija i raunovodstva integrisanih
sa sistemima za upravljanje materijalima i proizvodnjom. MRPII vodi ka
integrisanim poslovnim sistemima koji prevode zahteve za materijalima i
kapacitetima u proizvodnji u nansijske informacije. Devedesetih godina,
ERP sistemi obezbeuju integraciju svih informacionih tokova u kompaniji raunovodstvo, ljudski resursi, upravljanje lancem snabdevanja,
informacije o klijentima i dr.
ERP sistemi nameu pristup integrisanih sistema uspostavljanjem
opteg skupa aplikacija koje podravaju poslovne operacije. Kao to se
moe videti iz tabele 3.2., ERP sistemi prevazilaze neekasnosti izolovanih
sistema i neintegrisanih podataka, omoguavajui integrisane podatke
koje podravaju viestruke poslovne funkcije.
22
3.2. Koristi od ERP sistema

Sa sveukupnog poslovnog gledita, ERP sistemi dostiu brojne vane
ciljeve, kao to su ubrzani protok informacija, minimalno vreme odziva na
zahteve klijenata i dobavljaa, odluivanje na niim nivoima i jedinstvenu,
pouzdanu i blagovremenu informaciju donosiocima odluka. Sve ovo dovodi
do smanjivanja trokova, zaliha i boljih performansi rada.
Tabela 3.1. Evolucija ERP sistema
ERP sistemi su projektovani tako da obezbede poslovnu korist u prodaji

i distribuciji, proizvodnji, raunovodstvu, na polju usluga i trokova.
Istraivanja vedskih proizvodnih kompanija pokazuju da ERP sistemi
obezbeuju blagovremene informacije, poveane interakcije kroz preduzee,
bre projektovanje i proizvodnju proizvoda i poboljani menadment
poruivanja.
23
ERP sistemi mogu da ubrzaju poslovne procese, smanje vreme ciklusa

i trokove poslovnih procesa. Oni slue kao osnova za elektronsko poslovanje (eBusiness) jer obezbeuju funkcije front-oce-a koji omoguavaju
klijentima da postave i prate svoje porudbine putem Web-a.
Tabela 3.2. Pogled na sisteme pre i posle ERP sistema
Aplikacije kao to su Upravljanje odnosima sa klijentima (Customer

Relationship Management CRM) oslanjaju se osnove ERP sistema.
Najei razlozi zato se organizacije opredeljuju za ERP sisteme je zamena izolovanih sistema, potreba za standardizacijom, vanost sticanja
konkurentne prednosti, potreba za standardima kvaliteta i potreba za
poboljanjem interakcija sa poslovnim partnerima i klijentima.
24
3.3. ERP moduli

ERP sistemi treba da omogue odabir odgovarajue oblasti primene,
kao to su: upravljanje nansijama, proizvodnja, distribucija, upravljanje
odnosima, upravljanje servisom, e-trgovina, analitika itd.
Trenutno, vodei ERP vendori su SAP, Oracle i Microsoft koji podravaju
glavne funkcionalne oblasti poslovanja, ukljuujui obradu porudbina,
nabavke, planiranje proizvodnje, raunovodstva, ljudske resurse i dr.
Prema statistici, najee implementirani moduli su moduli za nansije
i raunovodstvo.
Tabela 3.3. ERP moduli koje podravaju glavni vendori
U proceni ERP reenja, mnoge organizacije razmatraju alternative projektovanja gde svaka od njih ima svoju cenu kao i prednosti i nedostatke.
Kompletna implementacija gotovog ERP reenja koje nudi vendor, tzv.
vanila implementacija, je skupa i zahteva dosta vremena, ali nudi prednosti totalne integracije i reinenjering poslovnih procesa. Implementacija
pojedinih ERP modula, na primer modul nansija i raunovodstva, manje
kota i zahteva manje vremena, ali postoji nedostatak totalne integracije
podataka kroz viestruke funkcionalne oblasti poslovanja. Alternativa
izgradnje ERP sistema u organizaciji (in-house), donosi brojne rizike i
najdue traje. Prednost ovog pristupa je izgradnja softvera koji odslikava
jedinstvene procese organizacije. Poslednja alternativa je odravanje
postojeih izolovanih sistema unutar organizacije. Ova alternativa znatno
umanjuje konkurentnu prednost organizacije na tritu, jer jedan ERP
sistem obezbeuje integraciju podataka i standardizaciju procesa koji
odslikavaju najbolje prakse.
25
Na osnovu brojnih faktora kao to su integrisanost podataka, trokovna

efektivnost, konkurentnost na tritu, poslovni uticaj i vreme, veina organizacija zakljuuje da je vanila ili parcijalna ERP implementacija bolja
nego razvoj u kui ili odravanje postojeih izolovanih sistema. Tabela 3.4
prikazuje mogui scenarijo ERP implementacije prema Fortune 500.
Tabela 3.4. Meni ERP Alternativa
Jedan od glavnih zahteva u opravdanju investiranja u ERP sisteme je

ocena merljivih (opipljivih) i nemerljivih koristi. Prema istraivanjima
Benchmarking Partners, Inc, za Deloitte Consulting, najvanija merljiva
korist nakon uvoenja ERP sistema je smanjenje zaliha. Rezultati istraivanja
su prikazani u Tabeli 3.5.
Tabela 3.5. Merljive koristi sa ERP sistemom
26
Najvei faktor nemerljivih koristi je raspoloivost informacija (Tabela

3.6). Informacije omoguavaju menaderima da donesu bolje odluke.
Tabela 3.6. Nemerljive koristi sa ERP-om
3.4. Analiza trokova i koristi za ERP

Trokovi implementiranja ERP reenja ukljuuju hardver, softver,
tehniku podrku, projektni menadment, tim koji radi na implementiranju reenja, spoljne konsultante, obuke i dr. Jedan od metoda za analizu
trokova i koristi (cost-benet) ERP projekta je neto sadanja vrednost (net
present value). Neto sadanja vrednost uzima u obzir vremensku vrednost
novca, na primer, ukoliko rma investira $1.000.000, pri interesnoj stopi
od 10%, oekuje da za pet godina dobije $1.610.510. Kada se vri procena
ERP projekta, tada se uzima vremenski okvir od 5 godina, jer se smatra
da e minimum tri godine proi na implementiranje reenja.
Na tabeli 3.7., se prikazuje analiza trokova i koristi metodom neto
sadanje vrednosti za jedan ERP projekat. Poetni (start-up) trokovi
ukljuuju investiranje u ERP softver. U ovom sluaju, cena softvera je
$2.420.000. Investicija u hardver iznosi $1.850.000, koja ukljuuje servere,
mrene ureaje u klijent/server okruenju. Trokovi konsultantskog vremena provedenog na instaliranju i kongurisanju softvera iznosi dodatnih
$3.000.400.
27
Tabela 3.7. Neto sadanja vrednost jednog ERP projekta [6]
Vreme projektnog menadmenta, internog tima i upravnog odbora

projekta je procenjeno da bude $400.000, a inicijalno vreme obuke je
$1.280.000. Ove cifre su preuzete sa istraivanja voenih u Americi i
vedskoj (Olhager i Selldin, 2003; Mabert et al., 2000).
Periodini trokovi ukljuuju trokove licenciranja softvera, odravanja,
vremena projektnog menadmenta, internog tima na projektu i konsultanata
koji se koriste na periodinoj osnovi. Na primer, licenciranje softvera je 10%
od trokova originalno kupljenog softvera, to iznosi $220.000 godinje.
Vremena tima koji radi na implementaciji iznosie $400.000 godinje.
Ukoliko se pretpostavi da implementacija projekta traje minimum tri
godine, onda se oekuje da se dobit nee realizovati pre etvrte godine
projekta. U naem primeru, merljive koristi ukljuuju smanjenje zaliha
koje predstavljaju utedu od $2.750.000, godinje. Zatim, redukcija kadrova
predstavlja dodatnu utedu od $1.250.000, godinje. Nemerljive koristi
mogu biti poveanje morala zaposlenih, zadovoljstvo klijenata, smanjenje
dupliciranog odravanja raznih baza podataka, meutim ove koristi ne
mogu biti prikazane ciframa.
Sa tabele 3.7., se moe videti da e predloeni ERP projekat imati pozitivni diskontni bilans u prvoj godini, dok e u etvrtoj godini investicija
28
uveliko isplatiti samu sebe gde e dostii kumulativni diskontni bilans od

$2.034.020. Na osnovu ove analize, moe se zakljuiti da je investiranje u
ERP sistem, mudra investicija.
3.5. Poslovni informacioni sistemi i

strateka prednost
Poslovni informacioni sistemi igraju krucijalnu ulogu u sticanju i
odravanju konkurentske prednosti u odnosu na druge organizacije iz
iste industrijske brane. Da bi stekle i odrale konkurentnu prednost organizacije moraju da usvoje tri osnovne strategije: vostvo u trokovima
(cost leadership), diferencijacija (dierentiation) ili inovacija (innovation).
Vostvo u trokovima podrazumeva obezbeivanje dobara i usluga po
najniim moguim trokovima. Diferencijacija podrazumeva kreiranje
takvog proizvoda koji se razlikuje bilo po kvalitetu, karakteristikama ili
drugim specinostima od proizvoda drugih konkurenata. Inovacija se
bavi pronalaenjem novih naina pristupa organizacionim aktivnostima.
Inovacija podrazumeva poboljanje postojeeg proizvoda, kreiranje potpuno novog proizvoda, poboljanje proizvodnog procesa ili ulazak na
novo trite.
Analiza lanca vrednosti organizacije moe da ukae na oblasti koje
mogu da obezbede organizaciji konkurentnu prednost. Porter-ov koncept
lanca vrednosti podrazumeva seriju povezanih aktivnosti koje dodaju
vrednosti organizacionim proizvodima ili uslugama.
Da bi shvatili analizu lanca vrednosti neophodno je razmotriti organizacioni lanac snabdevanja. Upravljanje lancem snabdevanja (Supply
chain management SCM) podrazumeva koordinaciju svih aktivnosti
snabdevanja jedne organizacije, od njenih dobavljaa preko proizvodnje
dobara i usluga do isporuke klijentima. Lanac vrednosti opisuje razliite
aktivnosti dodavanja vrednosti koje povezuju stranu nabavke sa stranom
tranje. Tradicionalna analiza lanca vrednosti (Slika 3.1) razlikuje primarne
aktivnosti koje direktno doprinose isporuci dobara i usluga klijentima (na
primer, logistika, proizvodnja, marketing, isporuka kupcima, podrka i
servisiranje nakon prodaje) i aktivnosti podrke koji obezbeuju infastrukturu koja omoguava odvijanje primarnih aktivnosti. Aktivnosti podrke
su nansije, ljudski resursi, informacioni sistemi i dr.
29
Primarne aktivnosti su vidljive potroau, dok aktivnosti podrke nisu.

Primarne aktivnosti podrazumevaju proces transformacije sirovina ili
informacija u proizvode ili usluge, a zatim njihovu isporuku klijentima i
partnerima kroz prodaju i marketing.
Slika 3.1. Porter-ov model lanca vrednosti1
Aktivnosti podrke olakavaju nesmetano funkcionisanje primarnih

aktivnosti i imaju indirektan odnos na proces dodavanja vrednosti na
proizvod. Oni ukljuuju:
administraciju i infrastrukturu neophodnu za obavljanje bilo kog

poslovanja, kao to su raunovodstvo i nansije;
upravljanje ljudskim resursima podrazumeva prijem, obuavanje,
motivisanje i raporeivanje odgovarajuih ljudskih resursa u organizaciji;
razvoj istraivanja/proizvoda/tehnologija poboljavaju postojei
proizvod i reprojektuju ga na nain kako bi se odrala njegova
privlanost i osvojila nova trita;
nabavka podrazumeva nabavku materijala po pristupanim cenama.
1
30
Porter, M.,Competitive Advantage: Creating and Sustaining Superior Performance, Free

Press, New York, 1998, adaptirano.
to je vea razlika izmeu dodatih vrednosti proizvoda i trokova

organizacije, vei je i prot. Lanac vrednosti svake organizacije je inkorporiran unutar veeg sistema vrednosti. Ovo ukljuuje lance vrednosti
njihovih dobavljaa, distributera i trgovaca na malo. Lanci vrednosti svih
uesnika bi trebalo da budu koordinirani sa sistemom, da rade ekasno i
da isporuuju krajnje proizvode. Ukoliko bilo ko od partnera ne isporui
odgovarajuu vrednost i proizvode, itav lanac moe da se slomije, a ceo
sistem ak i da propadne. Ovo je jedan od mnogih razloga zato poslovni
informacioni sistemi igraju odluujuu ulogu u sticanju konkurentne
prednosti organizacije.
Rezime
1. Sistem se najoptije denie kao skup objekata (entiteta) i njihovih
meusobnih veza usmerenih ka ostvarivanju zajednikog cilja.
2. Informacioni sistem (IS) je ureeni i integrisani skup ljudi, podataka,
procesa, interfejsa, mrea i tehnologija koja su u meusobnoj korelaciji u cilju podrke i poboljanja svakodnevnih poslovnih operacija i
podrke menadmentu u reavanju poslovnih problema, planiranja,
upravljanja, predvianja, koordinisanja i donoenja odluka.
3. Informacione tehnologije (IT) opisuju kombinaciju raunarske tehnologije (hardware i software), telekomunikacione tehnologije, netware, groupware i humanware.
4. CASE alati su programi (softveri) koji automatizuju i podravaju
jednu ili vie faza ivotnog ciklusa razvoja sistema.
5. Arhitektura informacionih sistema obezbeuje jedinstveni okvir
(framework) po kome e razliiti ljudi sa razliitim pogledima organizovati fundamentalne blokove razvoja informacionih sistema:
vlasnici i korisnici sistema se fokusiraju na tri glavna cilja, a to su:
poboljanja kod poslovnog znanja, poslovnih procesa i poslovnih
komunikacija.
projektanti i graditelji sistema se fokusiraju na tehnologije kako
bi ispunili postavljene ciljeve.
6. Poslovni informacioni sistemi su informacioni sistemi koji podravaju poslovne funkcije i obezbeuju poslovnu inteligenciju i analitiku.
31
7. ERP (Enterprise Resource Planning) predstavlja softver koji integrie

i automatizuje sve aspekte poslovanja preduzea i omoguava svim
zaposlenima dobijanje i deljenje pouzdanih informacija.
8. Poslovna dobit uvoenja ERP reenja ukljuuje poboljanu pristupanost informacijama, pristup podacima u realnom vremenu kroz
sva odelenja u organizaciji, poboljani vremenski ciklus porudbina,
smanjeni operativni trokovi, nie nivoe zaliha i dr.
9. Poslovni informacioni sistemi igraju krucijalnu ulogu u sticanju i
odravanju konkurentske prednosti u odnosu na druge organizacije
iz iste industrijske brane. Analiza lanca vrednosti organizacije moe
da ukae na oblasti koje mogu da obezbede organizaciji konkurentnu
prednost.
10. Porter-ov koncept lanca vrednosti podrazumeva seriju povezanih
aktivnosti koje dodaju vrednosti organizacionim proizvodima ili
uslugama. Tradicionalna analiza lanca vrednosti razlikuje primarne
aktivnosti koje direktno doprinose isporuci dobara i usluga klijentima
(npr., logistika, proizvodnja, marketing, isporuka kupcima, podrka
i servisiranje nakon prodaje) i aktivnosti podrke koji obezbeuju
infrastrukturu koja omoguava odvijanje primarnih aktivnosti. Aktivnosti podrke su nansije, ljudski resursi, informacioni sistemi i dr.
to je vea razlika izmeu dodatih vrednosti proizvoda i trokova
organizacije, vei je i prot.
Pitanja za razgovor i vebe

1. Posmatrajui sistem univerziteta, razmotriti sledee:
a. Koji su ciljevi tog sistema?
b. Identikovati inpute, procese i autpute.
c. Koje su povratne informacije, koje utiu na inpute ovog sistema?
2. Kakva je razlika izmeu podatka, informacije i znanja?
3. ta su informacioni sistemi i koja je razlika izmeu informacionih
sistema i informacionih tehnologija?
4. ta su okruenja za razvoj aplikacija i koje alate uglavnom obezbeuju?
32
5. Kako projektanti deniu poslovne zahteve za podacima?

6. ta su to poslovni informacioni sistemi i na koje osnovne resurse se
oslanjaju?
7. ta omoguava uvoenje ERP reenja?
8. U dananjem konkurentnom okruenju kritini faktor opstanka organizacije je primena informacionih sistema. Prodiskutujte sledee:
a. Kako Porterov model lanca vrednosti i konkurentna strategija
utiu na sticanje prednosti na tritu?
b. Na koji nain informacioni sistemi podravaju takvu strategiju?
Reference
[1] Bocij. P., D. Chaey, A. Greasley i S. Hickie, Business Information Systems Technology, Development and Management for the e-business,
drugo izdanje, Prentice Hall, Harlow. 2003.
[2] Dunn., L.C., J.O. Cherrington i A.S. Hollander, Enterprise Information
Systems a pattern-based approach, tree izdanje, McGraw-Hill, Irwin,
2005.
[3] Njegu., A. Sistemska analiza i projektovanje informacionih sistema,
skripta, Megatrend univerzitet, Beograd, 2002.
[4] Njegu., A., A. Veljovi, Internet poslovno programiranje, Megatrend
univerzitet, Beograd, 2004.
[5] Porter, M.,Competitive Advantage: Creating and Sustaining Superior
Performance, Free Press, New York, 1998.
[6] Sumner., M. Enterprise Resource Planning, Prentice Hall, New Jersey,
2005.
[7] Whitten J.L., L.D. Bentley i K.C. Dittman, Systems Analysis and Design
Methods, esto izdanje, McGraw-Hill, Irwin, 2004.
[8] XAML, http://msdn2.microsoft.com/en-us/library/ms752059.aspx,
MSDN Library, Microsoft.
33
DEO II:
RAZVOJ POSLOVNIH
CILJEVI POGLAVLJA
Tri poglavlja u okviru drugog dela ove knjige vas uvode u metodoloke
osnove razvoja informacionih sistema, prikazuju aktivnosti razvoja poslovnih reenja prema MSF okviru i implementacije gotovih poslovnih
reenja. Sistemska analiza je najkritinija faza projekta. Tokom sistemske
analize prouavaju se postojei poslovni sistemi, razumeju njihovi problemi,
deniu ciljevi za poboljanje sistema i deniu detaljni poslovni zahtevi
koje mora da ispuni svako tehniko reenje. Projektovanje sistema i
implementacija novog sistema e zavisiti upravo od kvalitetno obavljene
sistemske analize. Podpoglavlja u okviru sistemske analize vas poduavaju
odreenim vetinama sistemske analize sa naglaskom na logiko modeliranje
sistema. Projektovanje sistema podrazumeva pripremu raunarski
zasnovanih specikacija koje e ispuniti zahteve speciranih tokom sistemske analize i podrazumeva izgradnju prototipova sistema. Finalne
faze razvoja sistema se bave stabilizacijom i uvoenjem nalnog sistema
u rad.
Nakon prouavanja ovog poglavlja, znaete da:

analizirate probleme i modelujete sistemske zahteve funkcionalnim i objektno-orijentisanim tehnikama;
analizirate izvodljivost reenja i upravljate rizicima na projektu;
kreirate funkiconalnu specikaciju poslovnog reenja;
analizirate modele podataka primenom normalizacije;
dokumentujete konceptni, logiki i ziki dizajn pomou UML-a;
objasnite discipline Microsoft Solution Framework-a;
objasnite korake implementacije ERP reenja primenom ASAP
metodologije.
35
4. Metodoloke osnove razvoja informacionih

sistema
Metodologije razvoja informacionih sistema podrazumevaju ziku

implementaciju logikog ivotnog ciklusa koji ukljuuje:
aktivnosti za svaku fazu,
individualna i grupna pravila za svaku aktivnost,
standarde kvaliteta za svaku aktivnost i
alate i tehnike koje treba da budu upotrebljene za svaku
aktivnost.
ivotni ciklus razvoja sistema (Systems Development Life Cycle SDLC)
je konceptualni model koji se sastoji od sekvencionalnih procesa koji opisuju faze projekta razvoja informacionih sistema poevi od inicijalne studije
izvodljivosti do odravanja nalnih aplikacija. SDLC je jedan logiki proces
po kome analitiari, softverski inenjeri, programeri i krajnji korisnici razvijaju informacione sisteme kako bi reili poslovne probleme i ispunili zahteve.
Namena ivotnog ciklusa je da planira, izvrava i kontrolie sistemski razvoj projekta. On denie faze i zadatke koji su osnovni za sistemski razvoj,
bez obzira o kom tipu i vrsti sistema je re. Sve metodologije su izvedene
iz ovog logikog procesa reavanja problema odnosno iz ivotnog ciklusa
razvoja sistema. Razvijene su razliite SDLC metodologije koje prate procese
SDLC-a, kao to su model vodopada (izvorni SDLC metod), model brzog
razvoja aplikacija (Rapid Application Development - RAD), spiralni model
(spiral model) i mnoge druge.
Zato kompanije koriste metodologije? Metodologije, pre svega, obezbeuju jedan konzistentan i reproduktivni prilaz koji moe biti primenjen
na sve projekte. Metodologije smanjuju rizik od greaka. Metodologije
izdaju kompletnu i konzistentnu dokumentaciju za trenutne i budue
projekte.
Usled injenice da se projektni timovi i osoblja menjaju, metodologija
omoguava da oni timovi koji nastavljaju rad svojih prethodnika, brzo i
lako shvate rezultate rada svojih prethodnika.
36
4.1. Modeli i modeliranje

Modeli su apstrakcije koje odslikavaju kljune elemente kompleksnog
problema ili strukture time to eliminiu manje bitne detalje i na taj nain,
ine problem daleko lakim za razumevanje. Modeli se koriste da bi se opisali
poslovni procesi, razumelo trenutno stanje poslovanja i modelovali novi
procesi koji ne postoje, ali koji planiraju da se uvedu. Modeli su korisni za
razumevanje problema, za komunikaciju meu ljudima koji su ukljueni u
projekat, za modelovanje preduzea, pripremu dokumentacije i za dizajn
programa i baza podataka. Modelovanje omoguava bolje razumevanje
zahteva, istiji dizajn i sisteme pogodnije za odravanje.
Modeli mogu biti neformalni i formalni. Neformalni modeli se mogu
koristiti samo za dokumentaciju, dok se formalni mogu izvravati, kompajlirati ili prevesti u rezultate koji se mogu kompajlirati. Formalni
modeli sadre metapodatke i on je izraen jezikom domena problema
(Slika 4.1).
Slika 4.1. Formalni modeli
Formalni model olakava mapiranje koncepata problema i implementacije. Prednosti formalnog modela su: unapreivanje komunikacije meu
lanovima tima, smanjivanje runog rada, podizanje nivoa apstrakcije
na kojoj se radi projektovanje, unapreivanje praenja odnosa zahteva i
konanog reenja, obezbeivanje automatizacije mehanikih poslova itd.
37
Treba napraviti razliku izmeu konceptualnih, logikih i zikih modela.

Konceptualni modeli pokazuju veoma grubo ta je sistem, odnosno prikazuje objekte, veze i referencijalna ogranienja. Logiki modeli pokazuju
tabele, redove, kljueve, ogranienja primarnih i spoljnih kljueva, normalizaciju. Oni opisuju sistem nezavisno od bilo koje tehnike implementacije.
Fiziki modeli pokazuju ne samo ta je sistem i ta on radi, ve i kako je
sistem ziki i tehniki implementiran. Prikazuju se tipovi podataka, indeksi, particije podataka itd. Sinonimi za ziki model su implementacioni
model, tehniki model i sl. Da bi razjasnili navedenu razliku, razmotrimo
sledei primer. Pretpostavimo da korisnik eli da skladiti podatke o
prosenoj oceni studenata. Za svakog studenta, prosena ocena mora biti
izmeu 5 i 10. Za svakog novog studenta (brucoa) se ne moe formirati
prosek, dok ne poloi prvi ispit. Svi ovi iskazi su poslovne injenice. Nas
ne interesuje koju tehnologiju treba da koristimo da bi implementirali
ove injenice, injenice su konstantne - one su logike. Prosena ocena je
logiki atribut sa logikim domenom od 5 do 10, dok je logika difoltna
vrednost prazno polje. Kod zikog modela prvo treba da odluimo kako
emo skladititi ove podatke (atribute). Recimo da emo koristiti tabele
baze podataka Microsoft Access-a. Prvo treba da se odredi naziv kolone,
npr. ProsenaOcenaStudenta. Zatim treba da se deniu zika svojstva za
kolonu ProsenaOcenaStudenta, npr. tip podatka je Integer, da se odrede
primarni kljuevi, indeksi itd.
Za opis rada poslovnog sistema veliki problem predstavlja to to ne
mogu da se koriste prirodni jezici, zbog jezikih dvosmislenosti. S druge
strane, precizan opis preko formalnih jezika je nerazumljiv za veinu
ljudi. Stoga je potrebna tehnika koja e organizovati prirodne jezike na
taj nain da se eliminie dvosmislenost i omogui ekasna komunikacija
i razumevanje. Pokazalo se da je postupak modeliranja jedna od najefektivnijih tehnika za razumevanje i jednoznanu komunikaciju izmeu
projektanata i korisnika.
Modeliranje je projektovanje softverskih aplikacija pre njihovog kodiranja odnosno programiranja. Poslovni problemi su veoma kompleksni
to moe da ometa komunikaciju izmeu razvojnog tima i korisnika.
Modeliranje moe da pojasni sloene probleme i samim tim olaka razumevanje. Odgovorni za razvoj softverskog projekta, korienjem modela su sigurni da je funkcionalnost kompletna i korektna. Istraivanja
pokazuju da veliki softverski projekti koji nisu dobro izmodelirani imaju
veu verovatnou na neuspeh.
38
U procesu modeliranja, eliminiu se detalji, ime se umanjuje vidljiva

kompleksnost sistema koji se prouava. Grake prezentacije (uglavnom
pravougaonici i linije) koriste se da bi obezbedile da veina ljudi razmilja
o procesu modeliranja kao o slikovitoj prezentaciji. Pored grakog prikaza potrebno je dati i precizne denicije koji se pojavljuju u modelu, kao
i propratni tekst koji ima ulogu kao sredstvo komunikacije.
Ovakav pristup nametnuo je potrebu za apstrakcijom, kojom se izvodi
kontrolisano iskljuivanje detalja, tj. izvlae se zajednike karakteristike
u opisivanju nekog sistema. Tako je na viim nivoima apstrakcije sistem
opisan jasnije, a na niim detaljnije. Trenutno i budue stanje sistema se
modeluje kako bi se identikovali:
zahtevi kada se modelira sistem, sve daljne diskusije i analize se
fokusiraju na detalje modela i postizanje koncenzusa;
problemi i rizici ponekad postoji neslaganje oko toga ta su
problemi, a ta rizici kod trenutnog sistema;
informacije koje nedostaju kreiranje modela sistema pomae
razvojnom timu da lako identikuje ono to nije poznato.
Modeliranje je opti pristup u svim inenjerskim disciplinama. U svakoj
oblasti postoji vie intelektualnih alata (jezika) za modeliranje sistema. U
oblasti razvoja softvera, modeliranje se moe izvoditi klasinim pristupom
denisanjem modela podataka i modela procesa ili objektno-orijentisanim
pristupom korienjem UML-a.
Za postupak modeliranja razvijeni su odgovarajui CASE alati, kao to su
BPwin za funkcionalno modeliranje (podrava IDEF0, DFD), zatim ERwin
za modeliranje podataka koji podrava IDEF1X standard, RatonalRose koji
podrava UML i mnogi drugi. Ove tehnike omoguavaju:
izvrenje sistemske analize i projektovanja informacionih sistema
na svim nivoima;
stvaranje dokumentacije kao osnova za integraciju informacionog
sistema i ISO 9000 standarda;
bolju komunikaciju izmeu menadera, korisnika, projektanta i
programera;
upravljanje velikim i sloenim projektima.
39
4.2. Strategije sistemske analize

Sistemska analiza je najkritinija faza jednog projekta. Tokom sistemske analize treba da se shvate problemi konkretnog poslovnog sistema,
deniu ciljevi za njegovo poboljanje i deniu detaljni poslovni zahtevi,
koje mora da ispuni bilo koje tehniko reenje. Odnosno, svako naredno
projektovanje i implementacija novog sistema zavisi e od kvaliteta prethodno obavljene sistemske analize.
Sistemska analiza je metodoloki postupak dekompozicije nekog
sistema na podsisteme (komponente) sa ciljem da se proui njihov
meusobni uticaj i rad. Kada se radi sistemska analiza izvrava se i
sistemska sinteza. Sistemska sinteza je integracija komponenata sistema
u jedan celokupan sistem, za koji se pretpostavlja da je poboljani sistem.
Tokom sistemske analize i sinteze dodaju se, briu i modikuju komponente sistema prema cilju poboljanja globalnog sistema.
Sistemska analiza se bavi reavanjem problema. S obzirom da postoji
mnogo razliitih pristupa za reavanje problema, tako postoje i mnoge
strategije i tehnike sistemske analize, neke od njih su strukturna analiza,
informacioni inenjering, pravljenje prototipa, objektno-orijentisana analiza
i dr. Pogledajmo ukratko, ta neke od njih podrazumevaju.
Strukturna analiza (Structured Analysis - SA) je jedna od najstarijih
tehnika sistemske analize koja se i danas dosta koristi. Ona je orjentisana
na procese i koristi se za modeliranje poslovnih zahteva sistema. Modeli su
struktuirane slike koje prikazuju procese, ulaze, izlaze i skladita podataka.
Sistem analitiari crtaju seriju modela procesa, na primer dijagrame toka
podataka, da bi opisali osnovne procese sistema, tokove i skladita podataka.
Danas se za projektovanje softvera uglavnom koriste objektno-orijentisane
metode. Strukturna analiza se jo uvek koristi kod reinenjeringa poslovnih
procesa (Business Process Redesign). Reinenjeringom poslovnih procesa,
organizacija prouava osnovne poslovne procese kako bi eliminisala ili
smanjila nepotrebne tokove podataka i procese u postojeem sistemu u
cilju poveanja ekasnosti i smanjenja trokova.
Informacioni inenjering i modeliranje podataka je tehnika koja je
usredsreena na podatke u sistemu i strateko planiranje. Modeli podataka
kod informacionog inenjeringa (Information Engineering IE) se nazivaju
dijagrami objekti-veze (Entity Relationship Diagrams).
40
Sistem analitiari crtaju dijagrame objekti-veze kako bi modelirali podatke sistema i prikazali kako e se podaci prikupljati, skladititi, koristiti
i odravati. Strukturna analiza i informacioni inenjering pokuavaju da
sinhronizuju modele podataka i modele procesa.
Objektno-orijentisana analiza (Object-Oriented Analysis - OOA) je
tehnika koja je uspela da eliminie vetaki razdvojene podatake od procesa. Umesto podataka i procesa koji su kreirali, itali, aurirali i brisali te
podatke, oni su zajedno integrisani u objekte. Jedini nain da se kreiraju,
itaju, auriraju ili briu podaci objekta (properties) jeste putem ugraenih
procesa koji se nazivaju metode (methods). Programski jezici kao to su
C++, Visual Basic, C#, Java i mnogi drugi se baziraju na ovoj objektnoj
tehnologiji. OOA je naroito postao popularan pojavom UML-a (Unied
Modeling Language) koji obezbeuje i graku sintaksu za objektne modele.
UML denie nekoliko razliitih tipova dijagrama koji zajedno modeluju
jedan informacioni sistem ili aplikaciju u terminima objekata.
4.3. Reinenjering i modeliranje procesa

ERP sistemi doprinose reinenjeringu poslovnih procesa kombinovanih sa upotrebom novih informacionih tehnologija. Reinenjering se
moe denisati kao temeljno razmatranje i radikalno reprojektovanje
poslovnih procesa kako bi se postigla drastina poboljanja u kritinim
merama performansi, kao to su trokovi, kvalitet, usluge i brzina. Da
bi se razumeo reinenjering, veoma je vano da se shvati koncept lanca
vrednosti. U tabeli 4.1, su prikazane primarne aktivnosti preduzea koje
ukljuuju ulaznu logistiku, operacije, izlaznu logistiku, marketing i usluge.
Ove aktivnosti su osnovne za kreiranje, proizvodnju, marketing, prodaju
i podrku proizvoda ili usluga. Jedan informacioni sistem podrava svaku
od ovih primarnih aktivnosti. Taj informacioni sistem moe da smanji
trokove izvravanja aktivnosti ili se moe koristiti da obezbedi dodatnu
vrednost karakteristikama proizvoda ili usluga. Na primer, aktivnost nazvana izlazna logistika se bavi obradom porudbina klijenata. Sistem za online unos porudbina koji omoguava klijentima elektronsko poruivanje,
moe da smanji trokove i vremena ove aktivnosti. Podrka ovih usluga
moe da se vri putem udaljenih maina to dodaje vrednost poslovanju
obezbeujui, pri tom, on-line dijagnostiku podrku.
41
Tabela 4.1. Lanac vrednosti: primarne aktivnosti
U tabeli 4.2 su prikazane sekundarne aktivnosti koje podravaju primarne

aktivnosti organizacije. Ove sekundarne aktivnosti ukljuuju organizacionu
strukturu, ljudske resurse, tehnologiju i nabavku. Informacioni sistemi
mogu da podre svaku od ovih sekundarnih aktivnosti. Na primer, elektronska pota (email) moe da podri organizacionu strukturu olakavajui
vremenske komunikacije. Informacioni sistemi mogu da podre nabavku
omoguavajui nabavljaima da se poveu sa bazama podataka dobavljaa
kako bi postavili porudbine, odredili nivo zaliha i izvrili proveru cena.
Tabela 4.2. Lanac vrednosti: sekundarne aktivnosti
Menadment lanca snabdevanja, ukljuuje planiranje i kontrolu svih

zadataka poslovnog lanca vrednosti. Na ovaj nain, dobavljai se mogu
direktno povezati sa proizvoaima, a proizvoai sa prodavcima na malo,
a oni se mogu direktno povezati sa klijentima. Ove elektronske povezanosti
smanjuju trokove, poboljavaju vremensku obradu porudbina i isporuku,
poveavajui nivoe usluga.
U dananjoj ekonomiji, meu glavnim motivacijama za modernizovanjem i reinenjeringom poslovnih procesa su satisfakcija klijenata,
42
deregulacija i poveanje konkurentnosti na globalnom nivou. Generalno,

osetljivost na potrebe trita i fokus na potrebe klijenata zahteva brzo
vreme odziva i uproavanje i integraciju procesa.
Primeri reinenjeringa procesa se prikazuju na studijama sluajeva koji
objanjavaju situaciju pre i posle reinenjeringa. Prva studija sluaja se
bavi sistemom za plaanje rauna (Accounts Payable System) kompanije
Ford Motors. U situaciji pre reinenjeringa odravane su nezavisne baze
podataka za nabavku, prihvatanje i plaanje rauna. Kada se roba nabavlja
tada se podeava zapis u bazi podataka Nabavke. Kada se prihvati roba od
dobavljaa, odelenje za prijem aurira sopstvenu bazu podataka sa primljenim iznosom. Ukoliko bi isporuka bila parcijalna, onda se zapis iz baze
podataka Nabavke ne bi poklapao sa zapisom baze podataka Prihvatanja.
Ovakva nekonzistencija stvara probleme za plaanje rauna koji opet ima
sopstvenu bazu podataka. Nakon reinenjeringa (Slika 4.2), integrisana
baza podataka podrava Nabavku, Prihvatanje i Plaanje rauna. Kompanija je postavila novo poslovno pravilo da se plaanje rauna izvri tek po
isporuci robe od dobavljaa. Na ovaj nain su mnoge nekonzistentnosti
eliminisane. Sa uvoenjem procedura i zajednike baze podataka, znatno
je redukovano administrativno osoblje. U ovom sluaju, izmena procedura, uvoenje novih tehnologija i meu funkcionalna saradnja su znatno
smanjile administrativne trokove.
Slika 4.2. Primer reinenjeringa: Sistem za plaanje rauna
Drugi primer je razvoj proizvoda kompanije Xerox (Slika 4.3), gde je

integrisanje podataka dovelo do smanjenja vremena razvoja proizvoda i
poboljanja odzivnosti na potrebe trita.
43
Pre
Inenjerska procena
i razvoj
Definisanje
proizvoda
Definisanje procesa
Procena trokova
projektovanja
Konceptualni
dizajn
Zahtev za
inenjeringom
Inenjerska
isporuka
Pregled spremnosti za
isporuivanjem reenja
Posle
Konceptualni dizajn
Inenjering i
procena razvoja
Definisanje
proizvoda
Definisanje procesa
Crtei i repozitorijum
podataka
Inenjering i
procena razvoja
Procena trokova
projektovanja
Inenjerska
isporuka
Inenjerski pregled
Slika 4.3. Primer reinenjeringa: Xerox
Prethodne slikovite studije posluile su radi lakeg razumevanja procesa

reinenjeringa. Meutim, kada se radi ozbiljan reinenjering poslovnih
procesa uglavnom se koriste tehnika strukturne sistem analize - modeliranje procesa.
44
Modeliranje procesa je tehnika koja organizuje i dokumentuje procese

sistema i/ili implementira logiku, politike i procedure sistema. Neki od
modela procesa sistemske analize su dijagram toka podataka (Data Flow
Diagram - DFD), IDEF0 metodologija i dr. Najvanija korist u primeni
modeliranja aktivnosti je prototipski pristup gde se na brz i jednostavan
nain proveravaju alternativne ideje. Ovo je veoma bitna osobina jer brzi
razvoj informacionih tehnologija i primena Internet servisa uslovljava
potrebu za reinenjeringom koja zahteva radikalni redizajn aktivnosti, a
koje je potrebno opisati i pre sprovoenja prototipski proveriti.
4.3.1. Dijagram toka podataka

Dijagram toka podataka (DTP) je alat koji opisuje tokove podataka kroz sistem i
procese koji se izvravaju u sistemu. Dijagram toka podataka pre-dstavlja model
sistema koji sadri etiri osnovne komponente (Slika 4.4):
procese (processes) obrade podataka, koji predstavljaju aktivne

komponente sistema (graki simbol: krug);
spoljne objekte ili spoljne agente (external agents) sa kojima
sistem komunicira (graki simbol: pravougaonik);
skladita podataka (data stores) koje procesi koriste i/ili auriraju
(graki simbol: dve paralelne linije) i
tokove podataka (data ows) koji povezuju ostale komponente
sistema u celinu (graki simbol: usmerena linija).
SINTAKSA (PRAVILA KREIRANJA) DIJAGRAMA TOKA PODATAKA
Kod kreiranja dijagrama toka podataka vae sledea osnovna pravila:
Slika 4.4. Osnovne komponente DTP-a1

1
Koriena je DeMarco/Yourdon notacija jer poseduje veoma jednostavne, grafike,

pa samim tim i jasne koncepte.
45
1. Tok podataka predstavlja podatak u pokretu. Tok podataka predstavlja ulaz podataka u proces ili izlaz podataka ili informacija iz procesa (to mogu biti razliita dokumenta, formulari, tekstovi, knjige
i slino). Oni se takoe koriste za prikazivanje kreiranja, brisanja
ili menjanja podataka u bazi podataka ili datoteci. Tok podataka
ostvaruje vezu izmeu ostalih komponenti sistema i na DTP-u se
predstavlja imenovanom, orjentisanom linijom.
2. Svaki tok podataka mora da ima svoj izvor i ponor. Meutim, za
jedan tok, bilo izvor, bilo ponor (ili oba) mora da bude proces. Na
slici 4.5 se prikazuju nepropisne situacije tokova podataka za koje
se mogu dati sledei komentari:
Direktno povezivanje spoljnih objekata, objekata van sistema,
nekim tokom podataka nije dozvoljena, jer predstavlja opis
odnosa objekata van posmatranog sistema, pa nije od interesa.
Ako bi takva veza bila od interesa, odnosno ostvarivala se preko
posmatranog sistema, tada bi se morao denisati proces u
posmatranom sistemu koji takvu vezu uspostavlja.
U realnom sistemu spoljni objekti nemaju direktan pristup
skladitima podataka, ve to obavljaju procesi sistema.
Ukoliko je neophodno da se podaci sa jednog skladita podataka prenesu na drugo skladite podataka, ta veza se ne moe
ostvariti direktnom vezom izmeu skladita podataka, ve se
mora formirati proces preko koga e se vriti to premetanje.
Procesi se ne mogu direktno povezivati, ve ukoliko na osnovu rezultata koje daje jedan proces, a iji sadraj se smeta u
skladite podataka, poinje da radi drugi proces, onda on uzima
te rezultate iz skladita u koji su smeteni i na taj nain se veza
izmeu procesa ostvaruje putem skladita podataka.
46
Slika 4.5. Pravilan i nepravilan nain prikazivanja

DTP komponenata
3. Svaki tok podataka na DTP-u mora imati ime, koje treba da odraava
znaenje podataka koje on nosi. Ova imena treba da budu prirodna,
a ne neka specina, kodirana, preterano skraena imena, kako
bi se ostvarila itljivost i razumljivost DTP-a. Izuzetak su tokovi
koji idu ka, odnosno od skladita podataka koji ne moraju biti
imenovani. Ukoliko tok izmeu procesa i skladita nije imenovan,
podrazumeva se da tok nosi celokupan sadraj i strukturu podataka
tog skladita.
4. Tok podataka se moe granati. Istoimeni tokovi na DTP-u u sutini
predstavljaju grananje jednog toka, pa moraju imati zajedniki
izvor, a mogu imati razliite ponore.
47
5. Proces obrade podataka je aktivna komponenta sistema koja vri

transformaciju strukture i sadraja ulaznog u izlazni ili izlaznih
tokova u ulazne tokove podataka. Svaki proces ima naziv i oznaku. Naziv procesa treba precizno da oznaava funkciju koju on
obavlja.
6. Svaki proces mora da ima barem jedan ulazni i barem jedan izlazni
tok podataka. Proces koji ima ulaze, a nema izlaze je tzv. crna rupa,
jer izgleda kao da je podatak jednostavno nestao. Proces koji ima
izlaze, a nema ulaze, je takoe nemogu.
7. Svako skladite podataka bi trebalo da ima barem jedan ulazni
i barem jedan izlazni tok. Meutim, dozvoljava se da skladite
nema ulazni tok, podrazumevajui da se formira i aurira u nekom
drugom sistemu, odnosno da nema izlazni tok, podrazumevajui
da posmatrani sistem formira i aurira skladite koje se koristi u
nekom drugom sistemu.
8. Svaki spoljni objekat (spoljni agent) mora da ima barem jedan, bilo
ulazni, bilo izlazni tok podataka, inae bi bio izolovan od ostalog
dela sistema.
9. Da bi se izbeglo nepotrebno presecanje linija, dozvoljava se da se
skladite ili spoljni objekat, na jednoj slici, viestruko ponovi.
Hijerarhijska dekompozicija dijagrama toka podataka
Kompleksni sistemi, kada se posmatraju u globalu kao jedan proces, njih
je veoma teko razumeti. Stoga, se u sistemskoj analizi, sistem razlae ili
dekomponuje na svoje komponente odnosno na podsisteme. To se postie
primenom hijerarhijske dekompozicije DTP-a.
Dekompozicija je nain razlaganja sistema na njegove komponente
podsisteme, procese i podprocese. Svaki nivo apstrakcije opisuje, sa vie
ili manje detalja, celokupan sistem ili podskupove tog sistema.
Dijagram dekompozicije prikazuje top-down (sa vrha na dole) funkcionalnu dekomoziciju i strukturu sistema. Hijerarhijska dekompozicija DTP se
48
izvodi na taj nain to se jedan proces vieg nivoa apstrakcije dekomponuje

i prikazuje pomou novog celokupnog DTP-a na niem nivou apstrakcije.
Tehnika hijerarhijske dekompozicije prikazana je na slici 4.6, gde je proces
2, dekomponovan u novi dijagram toka podataka na niem nivou.
Slika 4.6. Hijerarhijska dekompozicija DTP-a
Pri dekompoziciji DTP-a moraju se potovati sledea pravila:

1. Dijagram najvieg nivoa, koji po pravilu sadri samo jedan proces
koji predstavlja ceo IS, zatim spoljne objekte sa kojima IS komunicira
i odgovarajue tokove podataka naziva se dijagram konteksta.
2. Dijagram prvog nivoa predstavlja dekompoziciju dijagrama konteksta. Procesi se oznaavaju brojevima 1,2,3.
3. Svaki proces sa dijagrama prvog nivoa se dalje dekomponuje do
nivoa primitivnih procesa (procesa koji se dalje ne dekomponuju). Procesi na dijagramima niih nivoa, povlae sa sobom brojnu
oznaku nadreenog procesa (npr. 2.1.).
49
4. Uobiajeno je da se zatim celokupan sistem predstavi dijagramom

stabla aktivnosti (Slika 4.7).
5. Procesi na najniem nivou odnosno procesi koji se dalje ne dekomponuju, se nazivaju primitivni procesi i za njih se daje specikacija
logike njihovog odvijanja.
6. Pored procesa, mogu se dekomponovati i tokovi i skladita. Njihov
opis se detaljno daje u reniku podataka. Na primer, tok Ponuda se
dekomponuje na sledeem dijagramu nieg nivoa, u tokove Podaci
o klijentu i Podaci o nekretnini.
7. Najvanije pravilo koje se mora potovati pri dekompoziciji procesa
je pravilo balansa tokova, to podrazumeva da ulazni i izlazni tokovi
nekog procesa na dijagramu nieg nivoa moraju biti ekvivalentni sa
ulaznim i izlaznim tokovima tog istog procesa na dijagramu vieg
nivoa.
8. Skladita podataka ukoliko se pojave na jednom nivou, uz jedan
proces, moraju se nadalje pojavljivati na svim niim nivoima dekompozicije toga procesa.
Slika 4.7. Opti primer dijagrama stabla aktivnosti
50
Preduzee
Nabavka
Evidentiranje
dobavljaa
Naruivanje
robe
Izrada
porudbine
Prodaja
Knjigovodstvo
Knjienje
Prijem robe
Evidentiranje
kupaca
Dodavanje
Auriranje
Fakturisanje
Brisanje
Prodaja robe
Izrada
otpremnica
Otpremanje
robe
Slika 4.8. Primer dijagrama funkcija za jedan sistem preduzea
Primer dekompozicije sistema

Na slikama, je predstavljen primer dekompozicije IS jednog manjeg
trgovinskog preduzea. Na dijagramu konteksta uoavaju se dva spoljna
objekta i to Dobavlja i Kupac i svi tokovi podataka preko kojih ovi objekti
komuniciraju sa IS preduzea.
Slika 4.9. Dijagram konteksta
Na dijagramu prvog nivoa dekompozicije razlaemo IS trgovinskog

preduzea na globalne procese, u ovom sluaju ih ima dva i to: Nabavka
i Prodaja. Odgovarajue tokove podataka pridruujemo odgovarajuem
procesu. Na ovom dijagramu iscrtavaju se i sva skladita podataka koja
se pojavljuju u sistemu, u naem primeru ima ih etiri: Katalog, Poslovni
partner, Artikal i Dokumenta nabavke.
51
Slika 4.10. Dijagram prvog nivoa
Sledei korak je dekompozicija globalnih procesa do nivoa primitivnih

procesa (zadataka). Prvi proces Nabavka se dekomponuje na etiri nova
procesa kao to se moe videti sa slike 4.11. Odgovarajui tokovi i skladita se
prikljuuju odgovarajuem pod procesu. Drugi proces Prodaja se dekomponuje na tri primitivna procesa kao to se moe videti sa slike 4.12.
Slika 4.11. Dekompozicioni dijagram procesa Nabavke
52
Slika 4.12. DTP Prodaje
4.3.2. Renik podataka

Renik podataka (Data Dictionary) predstavlja struktuirano skladite
meta podataka, tj. podataka o podacima. Prvobitno se pojavio kao proirenje
dijagrama toka podataka, za opisivanje sadraja i strukture svih tokova
i skladita podataka. Danas, za opis renika podataka upotrebljava se
BNF notacija (Backus-Naur Form), koja se inae koristi za opis sintakse
programskih jezika. Denisanje podataka BNF notacijom se prikazuje na
tabeli 4.3.
Tabela 4.3. BNF notacija
53
Na primer, raun i stavke rauna se notacijom BNF prikazuju:

Racun = @BrRac + DatRac + BrKupca
+ { SifArt, NazArt, Cena, Kol, Vrednost }
+ (IznosRac)
Takoe, prethodni primer se moe napisati i na sledei nain:
Racun = @BrRac + DatRac + BrKupca
+ { StavkaRac}
+ (IznosRac)
StavkaRac = @SifArt, NazArt, Cena, Kol, Vrednost
Sledei primer, pokazuje alternativne elemente.
Proizvod = @ProizvodID + Naziv
+ [KolicinaPorudzbine, StopaAmortizacije]
Ukoliko je proizvod osnovno sredstvo, onda e se pojaviti polje
StopaAmortizacije, a ukoliko je proizvod materijal za proizvodnju, onda
e se pojaviti polje KolicinaPorudzbine.
ELEMENTARNI PROCESI
Mini-specikacije slue za opisivanje osnovnih procesa u dijagramu toka
podataka. One mogu imati razliite oblike, ali imaju nekoliko zajednikih
elemenata:
naziv i broj procesa
listu podataka koji ulaze u sistem (ulazni tokovi podataka)
listu podataka koji izlaze iz procesa (izlazni tokovi podataka)
telo opisa procesa
Opis procesa sadri algoritam zadataka koje proces obavlja i moe
poprimiti razliite oblike. Na bazi ovog algoritma moe se u zavisnosti od
alata, generisati kd. Primer denicije procesa se prikazuje u tabeli 4.4.
Elementarni procesi se opisuju proceduralnom logikom za ije opisivanje
se koristi strukturni engleski jezik (Tabela 4.5).
54
Tabela 4.4. Primer definicije elementarnih procesa
Tabela 4.5. Proceduralne strukture struktuiranog jezika
55
4.3.3. IDEF0 funkcionalno modeliranje

Ranih devedesetih godina, IDEF (Integration DEFinition) Users Group
usvojila je standarde za funkcionalno modeliranje IDEF0 i za informaciono
modeliranje IDEF1X. Softverska realizacija IDEF0 standarda je BPwin
(Business Process Windows) rme LogicWorks. IDEF1X je semantiki
bogat modelar podataka koji je realizovan u okviru softvera ERwin (Entity
Relationships for windows) CASE alata.
Funkcionalno modeliranje pomou IDEF0 tehnike omoguava dekomponovanje poslovnih funkcija i planiranje potrebnih resursa za realizaciju
funkcija. IDEF0 funkcionalni model se sastoji od hijerarhijskog niza dijagrama koji postepeno prikazuju sve vie detalja o funkcijama i njihovoj
meuvezi sa ostalim delovima sistema. IDEF0 metode se koriste za modeliranje funkcija, kreiranje grakog modela koji pokazuje ko upravlja
funkcijama, ko ih izvrava, koji se resursi koriste, ko ih proizvodi i koje
relacije postoje sa drugim funkcijama.
IDEF0 predstavlja sistem kao mreu meusobno povezanih aktivnosti.
Model je hijerarhijski organizovan jer zapoinje sa jednom aktivnou
na najviem nivou, a zatim se ta aktivnost dalje dekomponuje do nivoa
primitivnih procesa. IDEF0 se moe koristiti za dobijanje struktuirane
dokumentacije koju podrava ISO 9000.
IDEF0 model se sastoji od 2 elementa (Slika 4.13):
Pravougaonik predstavlja aktivnosti denisane kao funkcije,
procese i transformacije. Svaki pravougaonik ima naziv i broj. Za
naziv aktivnosti se koristi aktivan glagol ili glagolska fraza koja
opisuje funkciju.
Strelice predstavljaju podatke ili objekte vezane za aktivnosti.
Slika 4.13. Opti model dijagrama konteksta

56
Ulazi se transformiu u aktivnosti koristei mehanizme ili resurse kao

to su osoblje i maine, da bi proizvele izlaze. Operacije aktivnosti e biti
usmerene kontrolama kao to su politike i procedure. Poziv je specian
sluaj mehanizma i oznaava da pozivajua aktivnost nema vlastiti detaljniji dijagram, ve daje detaljniji prikaz izveden na nekom drugom modelu.
Sledi detaljniji opis tokova podataka:
Ulazna strelica - predstavlja materijal ili informaciju koja se koristi
ili transformie sa ciljem denisanja izlaza. Dozvoljava se mogunost da odreene aktivnosti ne moraju imati ulazne strelice.
Kontrolne strelice - strelice koje ulaze u pravougaonik odozgo
deniu se kao kontrole (Control). Kontrolne strelice reguliu, odnosno odgovorne su za to kako, kada i da li e se aktivnost izvesti,
odnosno kakvi e biti izlazi. Svaka aktivnost mora imati najmanje
jednu kontrolnu strelicu. Kontrole su esto u obliku pravila, politika,
procedura ili standarda. One utiu na aktivnost bez mogunosti
da budu transformisane ili upotrebljene.
Izlazne strelice - materijali ili informacije stvorene aktivnou.
Svaka aktivnost mora imati najmanje jednu izlaznu strelicu. Aktivnost koja ne stvara izlaz, ne treba ni modelirati.
Strelice mehanizama - strelice na donjoj strani pravougaonika
predstavljaju mehanizme. Strelice okrenute prema gore identikuju
znaenje koje podravaju izvrenje aktivnosti. Strelice mehanizama
su oni izvori koji izvode aktivnosti, a sami se ne troe. Mehanizmi
mogu biti ljudi, maine i/ili oprema tj. objekti koja obezbeuju
energiju potrebnu za izvoenje aktivnosti. Mehanizami mogu biti
izostavljeni iz aktivnosti.
Strelica poziv - strelice mehanizma koje su okrenute na dole
deniu se kao strelice poziva (Call arrows). Strelica poziv je specini sluaj strelice mehanizma i ona oznaava da pozivajui
pravougaonik nema svoj vlastiti detaljniji dijagram, ali je detaljniji
prikaz izveden na nekom drugom pravougaoniku u istom ili nekom
drugom modelu. Vie pozivajuih pravougaonika mogu pozivati
isti pravougaonik na nekom drugom ili istom modelu. Imenuju se
sa brojem dekompozicionog dijagrama koji sadri pozvani pravougaonik zajedno sa brojem pozivnog pravougaonika.
57
Dakle, elemente prikazane na slici 4.13 mogu se opisati reenicom: Pod

Kontrolom, Aktivnost, od Ulaza pravi Izlaze, koristei Mehanizme.
Dijagrami opisuju sistem. Prvo se crta dijagram konteksta (A-0) koji se
koristi za opisivanje celokupne svrhe i/ili funkcije sistema. Na dijagramu
konteksta postoji samo jedna aktivnost, ulaz (ili skup ulaza), kontrole neophodne za pravilno funkcionisanje, mehanizmi koji obezbeuju sredstva
za izvravanje funkcije i izlazi koji predstavljaju rezultat funkcije. S obzirom da je kompleksne sisteme, kada se posmatraju u globalu kao jedan
proces, veoma teko razumeti, dati sistem se razlae ili dekomponuje
na svoje komponente odnosno na podsisteme. To se postie primenom
hijerarhijske dekompozicije dijagrama konteksta. Na sledeim slikama se
prikazuje primer funkcionalnog modeliranja pomou IDEF0 tehnike na
modelu poslovanja preduzea.
Slika 4.14. Dijagram konteksta
Sa dijagrama konteksta uoava se sledee:

ulazne informacije su informacije sa trita, informacija od kupca
od koga se dobija povratna informacija o upotrebi proizvoda i informacije od poslovnih parntera koji utiu na snabdevanje, a time i
na lanac vrednosti organizacije.
izlazne informacije su informacije za poslovnog partnera (informisanost o nabavci i prodaji) i informacije za kupca koje treba da
zadovolje potrebe kupca za kvalitetnim proizvodom.
58
Kontrole su zakoni i propisi (odnose se na funkciju nansija) i

standardi (vezani za proizvodnju i marketing).
Mehanizmi su postojanje odgovarajue hardverske platforme klijent/server organizacije, sistem za upravljanje bazama podataka,
zaposleni i dr.
Slika 4.15. Dekompozicioni dijagram modela poslova preduzea
Na slici 4.15 se prikazuje dekompozicioni dijagram modela poslova

preduzea i uoavaju se etiri globalna procesa: upravljanje, nansije,
marketing i proizvodnja. Za razliku od DTP-a gde se procesi nisu mogli
direktno povezivati, kod IDEF0 standarda to nije sluaj. Naime, strelice
koje izlaze iz procesa mogu direktno ulaziti u druge procese, s tim to treba
obratiti veliku panju da ukoliko te izlazne strelice predstavljaju ulaze u
drugi proces, treba da se i prikau na strani ulaza, a ne na strani kontrola
ili mehanizama.
Na osnovu detaljno iscrtanih dekompozicionih dijagrama, moe se
izvui stablo aktivnosti koje predstavlja pogled na sve procese u sistemu.
Na slici 4.16 se prikazuju samo prva tri nivoa, zbog veliine slike.
59
Slika 4.16. Stablo aktivnosti modela poslova preduzea
Model procesa se primenjuje za:

strateko planiranje sistema slui za denisanje arhitekture sistema u okviru stratekog plana, pri emu se radi model procesa
preduzea koji je najee u formi dijagrama dekompozicije funkcija
ili dijagrama konteksta;
reinenjering poslovnih procesa analiza i restruktuiranje poslovnih
procesa radi poboljanja produktivnosti pre primene informacionih
tehnologija;
analizu sistema logiki modeli procesa sistema ili aplikacije;
dizajn sistema ziki modeli procesa.
60
4.4. Modeliranje podataka i analiza

Modeliranje podataka je tehnika za organizovanje i dokumentovanje
strukture podataka sistema. Modeliranje podataka se ponekad zove modeliranje baze podataka jer se model podataka na kraju implementira kao
baza podataka. Modeliranje podataka je nae apstraktno vienje stanja
realnog sistema.
Model podataka je pojednostavljeno predstavljanje realnog sistema preko
skupa objekata (entiteta), veza izmeu objekata i njihovih atributa. Model
podataka (u literaturi denisan kao Model Objekti-Veze - MOV ili EntityRelationship - E-R model), preko skupa podataka i njihovih meusobnih
veza, predstavlja stanje sistema u jednom trenutku vremena i sadri skup
informacija o prolosti i sadanjosti sistema koja je potrebna da se pod
dejstvom buduih poznatih ulaza mogu odrediti njegovi budui izlazi.
Postoji nekoliko notacija modela objekti-veze. Mnogi su imenovani
prema njihovim tvorcima (npr., Chen, Martin, Bachman, Merise) ili prema
objavljenim standardima (npr., IDEF1X). Svi jezici modeliranja podataka
podravaju iste fundamentalne koncepte i konstrukcije.
4.4.1. Osnovni pojmovi modela podataka

Svi sistemi sadre podatke. Podaci opisuju neke stvari. Posmatrajmo
jedan kolski sistem. kolski sistem sadri podatke koji opisuju sledee
stvari Uenik, Uitelji, asovi, Uionice itd. Konkretni podaci koji opisuju
uenika su ime, adresa, telefon, datum roenja, pol, smer, uspeh itd. Koncept koji se koristi za apstraktno predstavljanje stvari sa slinim podacima
je objekat.
Objekat je klasa osoba, mesta, objekata, dogaaja ili koncepata o kojima
treba da prikupljamo i skladitimo podatke. Objekat je neto to se moe
videti, dodirnuti ili drugaije osetiti, koji ima svoja svojstva i ponaanja
i o kome korisnici mogu da skladite podatke. Posmatrajte okruenje u
kome se trenutno nalazite. Pogledajte okolo. Koji objekti su prisutni unutar
vaeg okruenja? Moda vidite vrata, prozore, knjige, stolice ili stolove.
Sve su to objekti koji se mogu videti i dodirniti, pa ak i vi predstavljate
jedan vidan objekat. Poto smo denisali objekat kao neto to je mogue
videti, dodirnuti ili drugaije osetiti, postavlja se pitanje koji su to objekti
61
koji se mogu na neki drugi nain osetiti. Na primer, ukoliko oekujete telefonski poziv, to je neto to moete da osetite. Ukoliko ste na poslovnom
sastanku i poslovni sastanak je takoe neto to se moe identikovati i
na kome se moe uestvovati. To znai da su i telefonski poziv i poslovni
sastanak takoe objekti.
Tipovi objekata se mogu klasikovati u osobe, mesta, stvari ili dogaaje.
U okviru tipa objekta osobe mogu se svrstati radnici, klijenti, prodavci,
studenti i dr. Odelenje, agencija, skladita, zgrade, kampus su primeri tipa
objekata mesta. Primeri tipa objekata stvari ukljuuju knjigu, proizvod,
vozilo, mainu, sirovine, softverski paket, opremu, DVD i dr. Na kraju
objekti dogaaja ukljuuju porudbinu, plaanje, raun, aplikaciju, registraciju ili rezervaciju i sl. Graki prikaz objekta po Chen-ovoj notaciji je
u obliku pravougaonika.
Objekti imaju svoj identitet koji je denisan svojstvima ili atributima.
Atributi su podaci koji predstavljaju karakteristike objekta. Na primer,
pretpostavimo da smo zainteresovani za sledee atribute objekta klijent:
ifra klijenta, naziv klijenta, adresa, tip klijenta, telefon, status na raunu.
Neprikazuju se svi atributi koji opisuju dati objekat, ve samo oni za koje
je korisnik zainteresovan da dri u bazi podataka. Neki atributi se mogu
logiki grupisati u sloeni atribut. Sloeni atribut se sastoji od vie primitivnih atributa. Na primer, adresa je sloeni atribut jer se sastoji od sledeih
primitivnih atributa: ulica, broj, grad, potanski broj, drava.
Za svaki atribut se uglavnom deniu: tip podatka, domen i difoltna
vrednost. Tip podatka denie koja klasa podataka moe biti skladitena
u taj atribut. Primeri tipova podataka su dati na tabeli 4.6. Domen denie
koje vrednosti moe da ima jedan atribut. Na primer, ispitna ocena studenta
uzima vrednosti iz domena 5 i 10. Difoltna vrednost je ona vrednost koja
e biti uskladitena za dati atribut ukoliko je korisnik ne promeni.
Ljudi rado klasikuju stvari, ne bi li nali slinosti meu njima i prema
tome ih grupisali. Stvari sa slinim svojstvima se grupiu zajedno. Na
primer, Petar Petrovi i Marija Marjanovi imaju svoja imena, adrese i
zanimanja i poto oboje rade u istom preduzeu, moemo ih svrstati u
objekat zaposlenih radnika. Konkretan objekat se naziva primerkom ili
instancom (instance) objekta. Na primer, Petar Petrovi je instanca objekta
Zaposleni.
62
Tabela 4.6. Logiki tipovi podataka za atribute
Jedan objekat ima vie instanci. Na primer, objekat Student e imati i

nekoliko hiljada uneenih studenata (Slika 4.17). Svaka instanca objekta
mora da ima jedinstveni klju po kome e se pretraivati u bazi podataka.
Na primer, s obzirom da atribut Broj indeksa zadovoljava osobine kljua,
jer jedinstveno identikuje svaku instancu objekta Student (svaki student
ima jedinstveni broj indeksa i ne moe ga deliti sa drugim studentom),
tada e Broj indeksa predstavljati klju objekta Student.
Slika 4.17. Prikaz atributa i instanci za objekat Student
Nekada je neophodno da vie od jednog atributa jedinstveno identikuje objekat. Ta grupa atributa koja jedinstveno identikuju objekat se
zove sloeni klju. Na primer, ukoliko bi projektovali informacioni sistem
nekog video kluba, koji ima vie kopija kaseta, sloeni klju bi bio ifra
naslova i broj kopije video kasete. Oba ova atributa jedinstveno identikuju
konkretnu video kasetu.
Da bi neki atribut mogao da bude primarni klju, on mora da zadovolji
sledee uslove:
63
jednoznanost ne smeju da postoje dve pojave za istim vrednostima svih kljunih atributa;
minimalnost da ne postoji podskup atributa kljua koji je takoe
jednoznaan (npr., sloeni primarni klju objekta Osobe ne moe
biti kombinacija atributa JMBG i Prezime, jer Prezime nema osobinu jednoznanosti);
odreenost postojanje vrednosti u trenutku stvaranja instance;
stabilnost otpornost na promene tokom vremena;
raspoloivost dostupnost svim korisnicima;
neutralnost prema znaenju vrednosti kljua (samogovoree
ifre).
Objekat moe imati vie atributa koji zadovoljavaju karakteristike primarnog kljua. Na primer, objekat Radnik se moe jedinstveno identikovati preko matinog linog broja ili preko ifre zaposlenog ili preko e-mail
adrese. Svaki od ovih atributa se nazivaju kandidati za klju. Kandidati
za klju su kandidati za primarni klju. Primarni klju (Primary key) je
kandidat za klju koji e se najee koristiti da jedinstveno identikuje
dati objekat. Primarni klju se denie kao jedan ili vie atributa ija
vrednost jedinstveno identikuje jednu instancu objekta. Primarni klju
mora da zadovolji osobine jedinstvenosti i neredundantnosti. Difoltna
vrednost primarnog kljua je Not Null, odnosno klju ne sme da bude
prazno polje, jer onda nee moi da jedinstveno identikuje datu instancu
objekta. Svi drugi kandidati za klju koji nisu izabrani za primarni klju
se zovu alternativni kljuevi.
Objekti ne ekzistiraju sami ve moraju biti u nekoj relaciji ili vezi sa
drugim objektima. Ukoliko posmatramo objekte Zaposleni i RadnoMesto,
jedna od relacija izmeu ova dva objekta e biti Angaovan, to znai da
je zaposleni angaovan na odreeno radno mesto u nekoj organizaciji. Na
slici 4.18 je prikazana relacija ova dva objekta sa svojim atributima, prema
Chen-ovoj notaciji.
64
Ime i
prezime
Datum
zaposlenja
(1,M)
ZaposleniID
ZAPOSLENI
RadnoMesto
ID
Plata
angaovan
na
NazivRadn
Mesta
(1,M)
RADNO MESTO
Slika 4.18. Relacija Angaovanje zaposlenih na radna mesta
Jedna od bitnih karakteristika veza izmeu objekata je kardinalnost

(tip veze). Kardinalnost denie minimalni i maksimalni broj dogaaja
jednog objekta koji se nalazi u konkretnoj relaciji sa drugim objektom.
Poto su sve relacije dvosmerne, kardinalnost se mora denisati za oba
smera. Kao to je prikazano na slici 4.18, u zagradama, konkretan zaposleni
(npr., Petar Petrovi) moe da bude angaovan minimum na jedno (1), a
maksimalno na vie radnih mesta (M). Na primer, Petar je angaovan na
radno mesto programera i konsultanta za prodaju softvera. Meutim,
na odreeno radno mesto moe biti minimum jedan (1), a maksimalno
vie zaposlenih (M). Na primer, na radno mesto konsultanta moe biti
angaovano vie zaposlenih, odnosno u organizaciji je zaposleno vie konsultanata. Graka notacija kardinalnosti zavisi od notacija modela objekti
veze. Na slici 4.19, je prikazana notacija kardinalnosti prema Martin-ovoj
notaciji ER modela.
Slika 4.19. Martin-ova notacija kardinalnosti

65
Agregacija istovremeno predstavlja i objekat i vezu, odnosno udrueni

ili asocijativni objekat (associative entity), izmeu dva ili vie objekta
(Slika 4.20). Ukoliko postoji potreba da se u toku relacije uvaju dodatni
atributi, tada relacija postaje udrueni objekat. Udrueni objekat je objekat
koji nasleuje primarne kljueve svojih tzv. roditelja. Na primer, atributi
udruenog objekta Porueni proizvod su Poruena koliina i Jedinina cena
(Slika 4.20), a njeni kljuevi bi bili atributi PorudbinaID i ProizvodID.
UkupanIznos
KlijentID
Naziv
ProizvodID
JedinicaMere
DatumPor
PORUENI
PROIZVOD
PORUDBINA
PorudbID
Poruena
koliina
PROIZVOD
Jedinina
cena
Slika 4.20. Agregacija Porueni proizvod
Objekti se povezuju pomou spoljnjeg kljua. Spoljni klju (Foreign

key) je atribut ili grupa atributa jednog objekta, ija se vrednost koristi za
povezivanje sa vrednou primarnog kljua drugog objekta. Odnosno,
spoljni klju objekta 1 je primarni klju objekta 2 sa kojim je objekat 1 u
vezi. Spoljni kljuevi i njima odgovarajui primarni kljuevi denisani su
nad istim domenom. Na primer, pogledajmo relaciju Klijent i Porudbina
sa slike 4.21. S obzirom da klijent moe da ima vie porudbina, tada emo
primarni klju objekta Klijent (u naem primeru to je KlijentID) preneti
u objekat Porudbina, gde e taj atribut predstavljati njegov spoljni klju.
Za konkretnu porudbinu, postojanjem spoljnog kljua KlijentID, znae
se ko je nainio konkretnu porudbinu.
Adresa
isporuke
PorudbID
PIB
DatumPor
UkupanIznos
NazivKlijenta
(1,M)
KLIJENT
(1,1)
pravi
PORUDBINA
KlijentID
Slika 4.21. Relacija Klijent - Porudbina
66
KlijentID
Da rezimiramo, objekat Porudbina e imati primarni klju PorudbinaID,

a spoljni klju je KlijentID koji ga povezuje sa objektom Klijent. Obino,
gde postoji kardinalnost tipa (1,1), onda taj objekat uzima primarni klju
objekta sa kojim je u vezi, a koji e predstavljati njegov spoljni klju. Kao
to se vidi sa slike 4.21, kardinalnost kod objekta Porudbina je (1,1), tako
da e spoljni klju stajati na njegovoj strani.
Kod onih relacija gde postoji veza vie prema vie, onda se ubacuje meu
objekat, kako bi reio problem vieznane zavisnosti. Ukoliko posmatramo
prethodni primer opisan na slici 4.18, uoava se da postoji veza vie prema
vie, odnosno zaposlen moe da bude angaovan na vie radnih mesta i
na jednom radnom mestu moe da bude angaovano vie zaposlenih. U
tom sluaju se ubacivanjem udruenog objekta pravi veza jedan prema
vie (1,M) prema ovim objektima. Jedini atributi ovog meu-objekta su
primarni kljuevi objekata koje povezuje (Slika 4.22).
Ime i
prezime
Datum
zaposlenja
ZaposleniID
ZAPOSLENI
RadnoMesto
ID
Plata
(1,M)
ZAPOSLENIRADNO MESTO
ZaposleniID
NazivRadn
Mesta
(1,M)
RADNO MESTO
RadnoMesto
ID
Slika 4.22. Reavanje problema vieznane zavisnosti
Problem odreivanja spoljnih kljueva e biti detaljnije obrazloen kroz

postupak normalizacije koji e kasnije biti objanjen.
Ukoliko postoji potreba da se ponavljaju vrednosti jednog atributa u
okviru odreenog objekta, tada se takav atribut izdvaja i formira se slab
objekat. Na primer, za objekat zaposleni koji ima atribut telefon, elimo
da pamtimo vie telefona. Tada emo napraviti slab objekat telefon koji
e naslediti primarni klju svog nad objekta (Slika 4.23).
67
Ime i
prezime
Datum
zaposlenja
Plata
ZaposleniID
ZaposleniID
Broj telefona
ZAPOSLENI
TELEFON
Slika 4.23. Primer slabog objekta
Generalizacija je tehnika gde se objekti sa zajednikim atributima,

vezama i/ili operacijama, grupiu (generalizuju) u jedan objekat koji
se zove nadtip. Inverzni postupak, gde se za neki tip objekta, deniu
njegovi podtipovi, koji imaju neke njima specine atribute, veze i/ili
operacije, je specijalizacija. Na primer, objekti Student, Zaposleni, Dete
i Penzioner imaju zajednike atribute kao to su Ime i prezime, JMBG,
Starost i Adresa, tako da se mogu predstaviti generikim tipom Osoba. S
obzirom da Student ima sebi svojstvene atribute kao to je Broj indeksa,
a Zaposleni ima npr., Platu, tada se objekat Osoba specijalizuje u objekte
Student i Zaposleni (Slika 4.24).
Ime i prezime
Starost
JMBG
Adresa
Osoba
Deji dodatak
Broj indeksa
Dete
Plata
Student
Radno mesto
Redovni
Zaposleni
Vanredni
Penzija
Penzioner
Satnica
Stalni
Privremeni
Cena
kolarine
Slika 4.24. Primer generalizacije/specijalizacije
68
4.4.2. Modeliranje podataka

Mnoge kompanije prvo obavljaju strateko planiranje gde se razvija
strateki plan informacionog sistema u kome se deniu vizija i arhitektura informacionog sistema. Arhitektura informacionih sistema ukljuuje
model podataka kompanije. Model podataka kompanije identikuje
osnovne objekte bez opisivanja njegovih atributa ili kljueva, a takoe
moe da ukljui, a ne mora, relacije izmeu objekata.
Prvi zadatak u modeliranju podataka je da se odrede osnovni objekti
sistema. Postoji nekoliko tehnika koje se mogu koristiti za identikaciju
objekata:
Tokom intervjua sa vlasnicima i korisnicima sistema, treba obratiti
panju na kljune rei njihove diskusije. Na primer, ukoliko korisnik kae Treba informisati nae stalne kupce, o novom kvalitetu
proizvoda, primetiemo da su kljune rei u ovoj reenici Kupci
i Proizvod, a oni su ujedno i objekti sistema.
U toku intervjua treba pitati vlasnike i korisnike sistema da identikuju one stvari za koje ele da prikupljaju, skladite i dobijaju
informacije. esto su to objekti koji treba da budu opisani u modelu
podataka.
Druga tehnika za identikaciju objekta je da se proue postojei
formulari i kartoteke. Neki formulari identikuju dogaaj objekata.
Na primer, porudbina, uplata, depozit itd.
Neki CASE alati takoe mogu da identikuju objekte.
Kada se identikuju objekti sistema, treba im dati jednostavna, znaajna,
poslovno-orjentisana imena.
Drugi zadatak u modeliranju podataka je identikovanje atributa
objekata. Predlae se sledei nain:
Mnoge kompanije koriste standardna imena i skraenice. Administrator podataka obino odrava takve standarde.
Paljivo birajte imena atributa. Mnogi nazivi atributa imaju istu
osnovu, npr. ime, adresa, datum, njih bi trebalo razdvojiti, kao
npr., NazivDobavljaa, NazivKlijenta i sl.
Trei korak je da se identikuju kljuevi za svaki objekat. Predlae
se sledee:
69
Vrednost kljua ne sme da se menja u toku veka trajanja svakog

objekta. Na primer, Prezime osobe se ne moe uzeti kao klju,
jer osoba moe da promeni svoje prezime ukoliko se vena ili
razvede.
Vrednost kljua ne moe da bude prazno polje.
Kontrole kljua moraju da budu instalirane, kako bi vrednost kljua
bila uvek validna.
etvrti korak je povezivanje objekata. Relacija je veza izmeu dva ili
vie objekata, tj. predstavlja odnos koji postoji meu objektima, bilo u
realnosti ili u mislima. Nazivi relacija treba da budu glagoli, npr, upisuje,
polae, predaje itd. Objekat od koga je uspostavljena veza zove se roditelj
(parent) ili domen, a objekat ka kome je uspostavljena veza zove se dete
(child) ili kodomen. U toku odreivanja relacija treba da se odrede i tipovi
veza ili kardinalnosti.
U toku odreivanja objekata sistema, njihovih atributa, kljueva i
relacija iscrtava se kontekstualni (konceptualni) model podataka, na
kome e se jasno uoiti objekti i njihove meusobne veze.
Logiki model podataka je potpuno odreen ukoliko su denisane
sledee tri komponente:
Struktura podataka - kojima se deniu statike karakteristike
sistema (opis objekata, atributi i veze).
Ogranienja - logika ogranienja na podatke (pravila integriteta) koja se ne mogu denisati preko strukture modela podataka
(strukturna i vrednosna ogranienja) i odnose se na denisanje
poslovnih pravila.
Skup operatora (operacije) - denie dinamiku interpretaciju podataka kroz njihovu obradu (odravanje baze podataka i
pretraivanje) ima uticaja na denisanje zikog nivoa modela i
verikaciju nalnog dizajna.
Peti korak je normalizacija relacionog modela podataka. Normalizacija
je tehnika analize podataka koja organizuje atribute na nain kako bi se
dobili neredundantni, stabilni, eksibilni i prilagodljivi objekti. U toku
normalizacije proverava se da li su atributi dobro postavljeni i odreuju
se odgovarajui spoljni kljuevi koji povezuju objekte.
Poslednji korak je prevoenje logikog modela podataka u ziki model
(ema baze podataka) u zavisnosti od izabranog sistema za upravljanje
bazom podataka (Database Management System DBMS).
70
4.4.3. IDEF1X standard za modeliranje podataka

Postoji mnogo razliitih verzija modela objekti veze, koji se u veini
sluajeva meusobno razlikuju samo sintaksno. U praksi najee koriena
verzija je IDEF1X standard amerike vlade za modeliranje podataka.
IDEF1X je realizovan kroz ERwin CASE alat.
Kod IDEF1X se koriste pojmovi roditelj i dete. Objekat od koga je uspostavljena veza se zove roditelj, a objekat ka kome je uspostavljena veza
zove se dete.
U IDEF1X deniu se dve vrste objekata:
nezavisni objekti objekti koji mogu postojati nezavisno od drugih
objekata u sistemu tzv. jaki objekti.
zavisni objekti objekti ija egzistencija i identikacija zavise
od drugog ili drugih objekata. Postoje etiri grupe zavisnih objekata:
slab objekat objekat koji se ponavlja vie puta za odreeni
nezavisni objekat. Na primer, objekti Faktura i StavkaFakture.
Za objekat StavkaFakture se kae da je slab objekat, jer potpuno
zavisi od objekta Faktura.
asocijativni objekti predstavljaju vezu vie objekata;
projektni objekti slini su asocijativnim, samo to nemaju
sopstvene atribute;
objekti kategorije (generalizacija/specijalizacija) predstavljaju
podkategoriju objekta. Kod objekta tipa kategorije deniu
se: nadreeni tip koji ima zajednike osobine (npr., Partner)
i podreeni objekti (npr., FizikoLice i PravnoLice), koji se
identikuju kljuem nadreenog i poseduju svoje specine
osobine.
Kod IDEF1X standarda razlikuju se sledei tipovi veza:
Identikujue veze koje objekat dete identikuje kroz njegovu
vezu sa objektom roditelj. Identikujua veza je prikazana punom
linijom i povezuje objekat roditelja sa objektom dete sa takom na
strani objekta dete. U identikujuoj vezi objekat roditelj ima svoj
nezavisni primarni klju (Klju A), a objekat dete ima sloeni klju
koji se sastoji od svog kljua (Klju B) i prenesenog roditeljskog
kljua (Klju A(FK)).
71
Dakle, instance objekta roditelj se deniu nezavisno, a instance

objekta dete se ne mogu identikovati bez identikatora objekta
roditelj.
Slika 4.25. Identifikujua veza
Neidentikujua veza ne identikuje dete preko identikatora

roditelja. Ukoliko se svaki primerak objekta dete moe jedinstveno
identikovati bez znanja veze sa primerkom objekta roditelj, onda se
takva veza denie kao neidentikujua veza. Neidentikujue veze
su prikazane isprekidanom linijom koja povezuju objekat roditelj i
objekat dete sa takom na strani objekta dete. Neidentikujua ili
slaba veza zavisi od naina denisanja kljueva od roditelja ka detetu
i to na dva naina: obavezna i neobavezna (opciona) neidentikujua
veza. Ako je veza obavezna (No Nulls ili Mandatory) iz perspektive
roditelja, onda je dete egzistencijalno zavisno od roditelja (Slika
4.26).
Slika 4.26. Neidentifikujua obavezna veza
Ako je veza neobavezna (Nulls Allowed ili Optional), tada dete niti
je egzistencijalno niti identikaciono zavisno, ali potuje tu vezu.
72
Slika 4.27. Neidentifikujua neobavezna veza
ERwin koristi romb (diamond) da naznai sluaj egzistencijalne

i identikacione zavisnosti. Romb moe postojati samo u slabim
vezama (poto je jaka veza u okviru primarnog kljua, a primarni
klju ne moe da ima Null vrednost).
Veza kategorije tj. veze prema podtipovima je denisana za hijerarhijsku vezu izmeu nadreenog generikog objekta koji sadri zajednike
osobine podreenih objekata kategorije. Ovaj tip veze se deli na kompletnu
kategoriju ili tzv. potpune strukture gde su navedene sve mogue kategorije
(podtipovi) nadreenog generikog objekta i nekompletnu kategoriju ili
tzv. nepotpunu strukturu, gde su navedene samo kategorije (podtipovi)
nadreenog generikog objekta.
Slika 4.28. Vrste objekata kategorije
Na sledeem primeru pokazuje se model podataka prema IDEF1X

standardu. Polazi se od standardizovanog obrasca za fakturu (ISO 7372)
- EDIFACT, koji se koristi u meunarodnoj trgovini (Slika 4.29), na osnovu koga je napravljen logiki model podataka prema IDEF1X standardu
(Slika 4.30).
73
Slika 4.29. Obrazac EDIFACT fakture
Slika 4.30. Logiki model podataka EDIFACT fakture [12]

74
4.4.4. Analiza modela podataka

Ukoliko model podataka efektivno izraava poslovne zahteve za podacima, to ujedno ne znai da je takav model i dobar model. Njegova
struktura moe biti takva da umanjuje eksibilnost, proirljivost ili stvara
nepotrebnu redundantnost. Kod kreiranja modela podataka treba se
pridravati sledeih kriterijuma:
Dobar model podataka je jednostavan atributi jednog objekta
treba da opisuju samo taj objekat.
Dobar model podataka je u osnovi neredundantan.
Dobar model podataka treba da bude eksibilan i adaptibilan za
budue potrebe.
Tehnika koja se koristi za poboljanje modela podataka u fazi pripreme
za ziki dizajn baze podataka se naziva analiza podataka. Analiza podataka
je proces koji priprema model podataka za implementaciju jednostavne,
neredundantne, eksibilne i adaptibilne baze podataka. Ova tehnika se
naziva normalizacija.
Normalizacija je tehnika analize podataka koja organizuje, grupie
atribute podataka tako da formiraju neredundantne, stabilne, eksibilne
i prilagodljive objekte. Ovde neemo prikazati matematiki pristup koji
obuhvata relacionu algebru i relacioni raun, ve emo se osvrnuti samo
na primenu normalnih formi. Pravilno projektovana baza podataka
mora imati strukturu koja osigurava da u radu sa njom ne moe doi do
neeljenih anomalija, kao to su na primer, unitavanje odreenih podataka
ili neusklaenost izmeu memorisanih podataka kao posledica auriranja
baze podataka.
Tvorac normalizacije je Codd koji je denisao postupak koji dovodi
projektanta relacione baze podataka do eljenog rezultata. Codd je denisao
tri nivoa normalizacije, da bi kasnije bilo dokazano da u nekim izuzetnim
primerima, relacije koje su u treoj normalnoj formi, jo uvek pokazuju
izvesne anomalije. Na treu normalnu formu nadovezuje se Boyce-Coddova normalna forma koja se bavi problemima preklapajuih kandidata
za klju. Probleme vieznane zavisnosti reava Fagin deniui etvrtu
normalnu formu (4NF). Kasnije je formulisana i peta normalna forma
koja denie zavisnost spajanja relacija. Da bi se stalo u denisanju novih
normalnih formi, Fagin je 1981. godine dao najoptiju deniciju normalne
forme kljueva i domena.
75
Da bi se mogao opisati postupak normalizacije, potrebno je prethodno opisati pojmove funkcionalne, potpune funkcionalne, tranzitivne i
vieznane zavisnosti.
FUNKCIONALNA ZAVISNOST
Funkcionalna zavisnost se moe denisati izmeu jednostavnog atributa
i sloenog kljua (vie atributa). Ako je svakoj vrednosti atributa A u relaciji R prikljuena samo jedna vrednost atributa B u istoj relaciji, onda je
atribut B funkcionalno zavisan od atributa A. Ako je mogue svakom paru
vrednost atributa A i B relacije R prikljuiti tano jednu vrednost C iste
relacije, tada je atribut C funkcionalno zavisan o sastavljenom atributu A
i B. Na osnovu denicije funkcionalne zavisnosti, potpuna funkcionalna
zavisnost se denie na sledei nain:
Atribut B je potpuno funkcionalno zavisan od atributa A iste relacije,
ako je funkcionalno zavisan od atributa A, a ne od nekog sastavnog
dela atributa A (u sluaju kada je atribut A sastavljen).
Drugim reima, potpuna funkcionalna zavisnost se posmatra kada je
klju tabele iskljuivo sastavljen od vie atributa. Kao primer pokazaemo
tabelu POSLOVI_ZAPOSLENIH.
U ovom primeru OpisPosla je funkcionalno zavisan od PosaoID (koji

je deo kljua, pa zbog toga nije potpuno funkcionalno zavisan o kljuu
ove tabele). Atribut Brojasova je potpuno funkcionalno zavisan o celom
kljuu, te je broj asova rada (40) odreenog radnika (1001) na odreenom
poslu (202).
TRANZITIVNA FUNKCIONALNA ZAVISNOST
Atribut C je tranzitivno funkcionalno zavisan od atributa A, ako je
funkcionalno zavisan od A i ako je funkcionalno zavisan od nekog atributa
B koji je i sam funkcionalno zavisan od A. Graki prikaz opte denicije
tranzitivne funkcionalne zavisnosti relacije ZAPOSLENI se prikazuje na
sledeoj slici.
76
Slika 4.31. Primer tranzitivne funkcionalne zavisnosti
U ovom primeru NazivOdelenja je funkcionalno zavisan i od primarnog kljua ZaposleniID i od jednog njegovog nekljunog atributa
OdelenjeID, to dovodi do pojave tranzitivne funkcionalne zavisnosti.
Tranzitivna funkcionalna zavisnost dovodi do redundantnosti podataka
u bazi podataka.
Nakon denisanja postojeih zavisnosti, prelazimo na objanjavanje
postupka normalizacije koji zapoinje sa prvom normalnom formom.
Proces normalizacije predstavlja transformaciju poetne tabele u jednu
ili vie korektnih tabela (relacija) u kojima su svi atributi potpuno funkcionalno zavisni od kljua, a meusobno funkcionalno nezavisni. Cilj
normalizacije je da eliminie redundansu u atributima i sa time omogui
lake odravanje integriteta podataka i jednostavniju manipulaciju.
PRVA NORMALNA FORMA

Osnovne operacije odravanja baze podataka su: dodavanje nove n-torke
u relaciju, izbacivanje neke n-torke iz relacije i izmena (auriranje) vrednosti
nekog atributa u relaciji. Problemi pri izvoenju ovih ope-racija kao to su ponavljanje ovih operacija vie puta, izbacivanje jednog logikog skupa podataka
koji dovodi do neeljenog izbacivanja drugih podataka ili logiko dodavanje
se ne moe izvriti, nazivaju se anomalije u odravanju baze podataka.
Pre nego to se krene u denisanje tabela i njihovo normalizovanje,
projektant informacionog sistema u okviru analize polazi od, na primer,
nekog formulara, kao to su fakture ili dosiji radnika i sl. Formirajui na osnovu toga jednu relaciju, projektant pristupa proveri date relacije, odnosno
pristupa normalizaciji, primenjujui prvu normalnu formu, koja glasi:
Relacija je u Prvoj normalnoj formi ukoliko su sve vrednosti njenih
atributa atomske ili drugim reima nisu dozvoljeni atributi ili grupe atributa
sa ponavljanjem, tzv. tabele u tabeli.
77
Na primer, posmatrajmo polaznu relaciju FUDBALSKI_SUDIJA koja je

sledeeg oblika:
FUDBALSKI_SUDIJA
Datu relaciju FUDBALSKI_SUDIJA moemo normalizovati, odnosno svesti

na 1NF, ako u svakoj vrsti prikazane tabele, za svaku odigranu utakmicu
ponovimo i sve ostale podatke o sudiji. Meutim, ova relacija sadri izvesne
anomalije u odravanju baze podataka, kao to su na primer:
Anomalije u dodavanju ukoliko se ele ubaciti podaci o novom
fudbalskom klubu, to se ne moe uraditi sve dok odreeni sudija
ne sudi na utakmici u kojoj igra dati fudbalski klub.
Anomalije u izbacivanju ukoliko se ele obrisati podaci o jednom
sudiji, onda se gube i sve informacije o odranim utakmicama.
Anomalije u auriranju ukoliko se promeni adresa stanovanja
sudije, to se mora uiniti na onoliko mesta koliko utakmica je sudio
dati sudija.
Postupkom normalizacije, logika struktura baze podataka se dovodi
u takav oblik u kome se izbegavaju anomalije u odravanju i problemi u
izvetavanju.
Da bi se smanjila redundansa do koje bi, oigledno, ovakva normalizacija dovela, moemo ovako dobijenu relaciju, operacijom projekcije1,
dekomponovati na sledee dve:
FUDBALSKI_SUDIJA (SudijaID, ImeSudije, AdresaSud, PttBr, Mesto)
UTAKMICA (UtakmicaID, DatumUtakmice, Domain, Gost, Stadion, Rezultat, SudijaID)
1
78
Projekcija je unarna operacija relacione algebre koja iz neke relacije selektuje skup
navedenih atrubuta, odnosno izvlai vertikalni podskup iz odgovarajue tabele. Operacijom projekcije eliminiu se duplikati n-torki.
Pri daljem postupku normalizacije postavlja se pitanje da li se pri takvoj

dekompoziciji gubi neka informacija iz polazne relacije, odnosno postavlja
se zahtev da se ovakva dekompozicija vri bez gubljenja informacija. Relacija R se dekomponuje u svoje projekcije bez gubljenja informacija ako
prirodno spajanje tako dobijenih projekcija dovodi do polazne relacije.
Heath-ova teorema daje uslove pod kojima se moe izvriti dekompozicija relacije bez gubljenja informacija: Relacija R(A,B,C) gde su A,B i C
podskupovi atributa, u kojoj vai R.A R.B moe se uvek dekomponovati
u svoje projekcije R1(A,B) i R2(A,C) bez gubljenja informacija.
Pogledajmo jo jedan primer nenormalizovane relacije DOBAVLJAI
koja je sledeeg oblika:
DOBAVLJAI
Data relacija DOBAVLJAI pokazuje izvesne anomalije u odravanju

baze podataka, kao to su na primer:
ukoliko se promeni adresa dobavljaa to se mora uiniti na onoliko
mesta koliko proizvoda se nabavlja od tog dobavljaa.
ukoliko se ele ubaciti u bazu informacije o novom proizvodu, to
se ne moe ubaciti sve dok ga neki dobavlja ne ponudi itd.
Nenormalizovanu relaciju DOBAVLJA operacijom projekcije, dekomponujemo na sledee dve:
DOBAVLJACI (DobavljacID, NazivDob, AdresaDob, Ptt_Br)
PROIZVOD (ProizvodID, NazivProizvoda, DobavljaID)
79
DRUGA NORMALNA FORMA

Relacija R je u Drugoj normalnoj formi (2NF) ako i samo ako je u 1NF
i svi njeni nekljuni atributi potpuno funkcionalno zavise od primarnog
kljua. Nekljuni atributi su atributi koji nisu kandidati za klju, niti deo
kandidata za klju.
Svoenje na 2NF vri se dekompozicijom na taj nain to se u jednoj
projekciji ostavlja primarni klju i svi atributi koji su potpuno funkcionalno
zavisni od njega, a u drugim projekcijama se realizuju one funkcionalne
zavisnosti koje su prouzrokovale nepotpune funkcionalne zavisnosti.
Ukoliko posmatramo sledeu relaciju:
PORUENI_PROIZVOD (PorudbinaID, ProizvodID, OpisProizvoda,
PoruenaKol, JedCena)
Uzrok redundansi i anomalijama u odravanju je nepotpuna funkcionalna zavisnost atributa OpisProizvoda od sloenog atributa PorudbinaID,
ProizvodID. Naime,
PorudbinaID, ProizvodID OpisProizvoda
PorudbinaID OpisProizvoda
ProizvodID OpisProizvoda
Denicija druge normalne forme zabranjuje postojanje ovakve zavisnosti. Odnosno, s obzirom da je relacija R u 2NF, ukoliko svi njeni
atributi daju jednoznane injenice samo o celom kljuu, onda relacija
PORUENI_PROIZVOD nije u 2NF, jer OpisProizvoda daje jednoznanu
informaciju o delu kljua i to ProizvodID. Iz denicije 2NF i denicije
potpune funkcionalne zavisnosti oigledno je da je svaka relacija sa prostim primarnim kljuem u 2NF, jer prosti klju nema semantiki mogu
pravi podskup.
Svoenje na 2NF vri se sledeom dekompozicijom:
PORUENI_PROIZVOD (PorudbinaID, ProizvodID, PoruenaKol,
JedCena)
PROIZVOD (ProizvodID, OpisProizvoda)
80
TREA NORMALNA FORMA

Relacija R je u Treoj normalnoj formi (3NF) ako i samo ako je u
2NF i ako svi njeni nekljuni atributi netranzitivno funkcionalno zavise
od primarnog kljua.
Ukoliko posmatramo relaciju:
FUDBALSKI_SUDIJA (SudijaID, ImeSudije, AdresaSud, PttBr, Mesto)
Evidentne su anomalije u odravanju baze podataka i redundantnost

podataka usled postojanja tranzitivne funkcionalne zavisnosti atributa
Mesto od atributa PttBr. Da bi smo datu relaciju sveli na 3 NF, vrimo
dekompoziciju (bez gubljenja informacija) relacije u njene projekcije, na
taj nain to u jednoj projekciji ostavljamo primarni klju i sve netranzitivno zavisne atribute, a u drugim projekcijama se realizuju funkcionalne
zavisnosti koje su dovele do tranzitivnih zavisnosti:
FUDBALSKI_SUDIJA (SudijaID, ImeSudije, AdresaSud, PttBr)
IFARNIK_MESTA (PttBr, Mesto)
Relacije FUDBALSKI_SUDIJA i IFARNIK_MESTA su u 2 NF, jer relacije

sadre prost primarni klju i one su i u 3 NF jer nepostoje tranzitivne
funkcionalne zavisnosti. Pogledajmo i relaciju:
UTAKMICA (UtakmicaID, DatumUtakmice, Domain, Gost, Stadion, Rezultat, SudijaID)
Atribut Stadion je zavisan i od kljua relacije i od jednog nekljunog

atributa Domain. Stoga se data relacija svodi na:
UTAKMICA (UtakmicaID, DatumUtakmice, Domain, Gost, Rezultat,
SudijaID)
KLUB (Domain, Stadion)
Kod objanjavanja pojma tranzitivne zavisnosti u prethodnom poglavlju,

pomenuli smo da relacija ZAPOSLENI sadri tranzitivnu zavisnost, usled
toga to je atribut NazivOdel funkcionalno zavistan i od kljua i od jednog
nekljunog atributa u relaciji. Njen poetni oblik je bio:
ZAPOSLENI (ZaposleniID, ImeZaposl, DatumZaposlenja, Plata, OdelenjeID,
NazivODel)
81
Datu relaciju dekomponujemo, tako to uklanjamo zavisnost koja

je dovela do tranzitivne zavisnosti, tako da se relacija dekomponuje na
sledee dve relacije:
ZAPOSLENI (ZaposleniID, ImeZaposl, DatumZaposlenja, Plata,
OdelenjeID)
ODELENJE (OdelenjeID, NazivOdel)
BOYCE-CODDOVA NORMALNA FORMA

Tvorac relacionog modela je E.F. Codd, koji je dao originalne denicije
2NF i 3NF. Meutim, pokazalo se da ove denicije nisu dovoljno precizne,
naroito u sluajevima kada relacija ima tzv. preklapajue kandidate
za klju (dva ili vie sloenih kandidata za klju koji imaju barem jedan
zajedniki atribut).
Relacija je u Boyce-Codd-ovoj normalnoj formi (BCNF) ako i samo
ako su sve determinante u relaciji i kandidati za klju. Determinanta relacije
R je bilo koji atribut, prost ili sloen, od koga neki drugi atribut u relaciji
potpuno funkcionalno zavisi.
Da bi prikazali preklapajue kandidate za klju pretpostavimo da na
nekom fakultetu jedan predmet moe da predaje vie nastavnika, ali svaki
nastavnik moe da predaje samo jedan predmet. Svaki student prijavljuje
vie predmeta, ali polae samo kod jednog profesora za zadati predmet.
Ova situacija se moe opisati sledeom relacijom:
PRIJAVA (BrIndeksa, ImeNastavnika, PredmetID)
Data relacija nije u 2NF, jer postoji nepotpuna funkcionalna zavisnost:

ImeNastavnika
PredmetID
Da bi relaciju sveli na 2 NF, onda bi mogli drugaije da izaberemo

primarni klju:
PRIJAVA (BrIndeksa, PredmetID, ImeNastavnika)
Sada je relacija u 3NF, ali nije u BCNF zbog zavisnosti:

ImeNastavnika
82
PredmetID
Pritom ImeNastavnika nije kandidat za klju. Zbog odstupanja od

BCNF nastaju sline anomalije kao kod odstupanja od 3NF. Ne moemo
evidentirati injenicu da odreeni nastavnik predaje odreeni predmet,
sve dok bar jedan student ne prijavi dati predmet. Takoe, veza nastavnika
i predmeta je zavisana sa velikom redundantnou, onoliko puta koliko
ima studenata, to oteava auriranje. Ako svi studenti odustanu, brie se
evidencija da odreeni nastavnik predaje dati predmet. Reenje problema je razbijanje relacije na dve ime se prekida nepoeljna funkcionalna
zavisnost.
PRIJAVA (BrIndeksa, ImeNastavnika)
PREDAJE (ImeNastavnika, PredmetID)
Pogledajmo jo jedan primer praenja organizacije turneje koncerata

po turistikim mestima.
PESMA (DatumNastupa, Peva, Pesma)
MESTO(DatumNastupa, Mesto)
U okviru relacije PESMA, klju bi mogao da bude i kombinacija atributa

(DatumNastupa, Pesma), ali tada bi imali nepotpunu funkcionalnu zavisnost, usled zavisnosti Pesma Peva. Da bi se izbegla navedena nepotpuna
funkcionalna zavisnost, biramo za klju atribute DatumNastupa i Peva jer
Pesma zavisi i od Pevaa i od Datuma. Dakle, sada nepostoje nepotpune
i tranzitivne funkcionalne zavisnosti, ali ipak, relacija nije u BCNF jer
determinanta Pesma nije kanditat za klju. Pogledajmo sve determinante
(D) relacije PESMA i obeleimo postojee kandidate za klju (KK):
DatumNastupa, Peva Pesma
DatumNastupa, Pesma Peva
Pesma Peva
(D)
(D)
(D)
(KK)
(KK)
Relacija PESMA se moe dovesti u BCNF razbijanjem na dve manje

relacije:
PESMA (DatumNastupa, Pesma)
PEVA (Peva, Pesma)
83
ETVRTA NORMALNA FORMA

Relacija R je u etvrtoj normalnoj formi (4NF) ukoliko u njoj nisu
date dve ili vie nezavisne vieznane injenice. Codd objanjavanja pojam
vieznane zavisnosti:
U relaciji R(A,B,C) postoji vieznana zavisnost A B, ako za datu
vrednost A, postoji skup vie vrednosti B, a taj skup vrednosti ni na koji
nain ne zavisi od vrednosti atributa C. Atributi A, B i C mogu biti sloeni.
Primer vieznane zavisnosti se prikazuje u tabeli IZVOZI.
Na tabeli IZVOZI uoavaju se dve nezavisne vieznane zavisnosti:
kompanija proizvodi vie proizvoda i kompanija izvozi u vie drava,
odnosno.
Kompanija Proizvod
Kompanija Drava
Drava gde se izvozi zavisi samo od kompanije, ali ne i od proizvoda.

Takoe, proizvod zavisi samo od kompanije, ali ne i od drave gde se
prodaje. Data relacija IZVOZI se nalazi u BCNF jer sadri samo primarne
atribute koji jedinstveno deniu n-torku. Ukoliko pretpostavimo da sve to
neka kompanija proizvede to i izvozi u sve zemlje sa kojima posluje, tada
postoji velika redundantnost. Ukoliko kompanija IBM uvede proizvodnju
novog proizvoda, tada bi morali da upiemo onoliko n-torki, posebno za
svaku dravu sa kojima IBM posluje.
Dosadanja pravila normalizacije nam nisu pomogla u eliminaciji
redundantnosti u relaciji IZVOZI, usled toga to ona nije posledica funkcionalnih zavisnosti ve vieznanih zavisnosti. Relaciju IZVOZI treba
da dekomponujemo na projekcije bez gubljenja informacija.
84
Fagin navodi pod kojim uslovima moemo dekomponovati relacju bez

gubljenja informacija: Relacija R (A,B,C) moe se dekomponovati bez
gubljenja informacija na projekcije R1(A,B) i R2 (A,C) ako i samo ako
vai A B (to ukljuuje i AC, jer ako u relaciji postoji vieznana
zavisnost A B, tada postoji i vieznana zavisnost A C).
Poto relacija IZVOZI nije u 4 NF, jer u njoj postoje dve nezavisne
vieznane injenice, oigledno je da datu relaciju treba dekomponovati
na projekcije:
RADI (Kompanija, Proizvod)
PRODAJE (Kompanija, Drava)
PETA NORMALNA FORMA

Postoji jo optija forma zavisnosti, tzv zavisnost spajanja koja u sebi
obuhvata vieznane, pa samim tim i funkcionalne zavisnosti. U relaciji
R(X,Y, ... Z) postoji zavisnost spajanja ako i samo ako relacija R rezultuje
iz prirodnog spajanja njenih projekcija po X, Y, ..., Z, gde su X,Y, .. Z podskupovi atributa relacije R.
Relacija R je u Petoj normalnoj formi (5NF) ako i samo ako se svaka
zavisnost spajanja moe pripisati kandidatu za klju.
Ukoliko posmatramo prethodno pomenutu relaciju:
FUDBALSKI_SUDIJA (SudijaID, ImeSudije, AdresaSud, PttBr, Mesto,
UtakmicaID, DatumUtakmice, Domain, Gost, Stadion, Rezultat)
Primenom normalih formi, datu relaciju smo normalizovali dekomponujui je na sledee etiri:
FUDBALSKI_SUDIJA1 (SudijaID, ImeSudije, AdresaSud, PttBr)
IFARNIK_MESTA (PttBr, Mesto)
UTAKMICA (UtakmicaID, DatumUtakmice, Domain, Gost, Rezultat,
SudijaID)
KLUB (Domain, Stadion)
85
Polazna relacija FUDBALSKI_SUDIJA se moe rekonstruisati iz njenih

projekcija prirodnim spajanjem relacija FUDBALSKI_SUDIJA1 i IFARNIK_MESTA po atributu PttBr koja predstavlja primarni klju u relaciji IFARNIK_MESTA, a zatim prirodnim spajanjem tako dobijenog rezultata sa relacijom
UTAKMICA po atributu SudijaID koji je primarni klju u relaciji FUDBALSKI_SUDIJA. Na kraju tako dobijena relacija se spaja sa relacijom KLUB po
atributu Domain koja predstavlja primarni klju u relaciji KLUB.
S obzirom da se relacija FUDBALSKI_SUDIJA moe rekonstruisati prirodnim spajanjem preko kljueva relacija, onda je ova relacija u 5NF.
NORMALNA FORMA KLJUEVA I DOMENA (DK/NF)

R. Fagin je 1981. godine dao najoptiju deniciju normalne forme
kljueva i domena i time pokazao da je relacija koja je u DK/NF ne prouzrokuje anomalije u odravanju.
Relacija je u DK/NF (Domain Key/Normal Form):
Ako su sve zavisnosti u njoj posledica denicije kljueva i domena.
Ako svaki atribut daje informaciju iskljuivo o kljuu i o celom
kljuu.
Drugim reima, relacija R je u DK/NF ako i samo ako je svako ogranienje
na R logina posledica ogranienja na domenu i kljuu relacije R. Fagin tvrdi
da nam nije potrebna funkcionalna zavisnost da bi denisali tabele. Dok
god znamo koje emo kljueve koristiti i koju vrstu ogranienja imamo nad
vrednostima koja e se nalaziti u kolonama (domeni), moemo dokazati da
je tabela najmanje u 5NF i nee patiti od anomalija ubacivanja i brisanja.
Na primer, relacija PORUENI_PROIZVOD (PorudbinaID, ProizvodID,
OpisProizvoda, PoruenaKoliina, JedCena) nije u DK/NF jer je denisano
ogranienje da jedan Proizvod ima jedan OpisProizvoda, a to nije posledica
denicije kljua ove relacije.
Ako je relacija u DK/NF, ona je sigurno u svim ostalim. Meutim, direktna primena ove denicije je slabo primenjiva, jer otkrivanje ogranienja
u relacijama zahteva otkrivanje funkcionalnih, vieznanih i zavisnosti
spajanja, a to praktino znai primenu svih navedenih denicija.
86
SINHRONIZACIJA SISTEMSKIH MODELA

Modeli podataka i procesa predstavljaju razliite poglede na isti sistem
koje treba sinhronizovati kako bi se obzebedila konzistentnost i kompletnost
celokupne specikacije sistema. Kvalitet sinhornizacije podrazumeva da
svaki objekat treba da ima najmanje jedno kreiranje (C create), jedno
iitavanje (R read), jedno menjanje (U update) i jedno brisanje (D
delete) da bi sistem bio kompletan. CRUD matrice dokumentuju ove
zahteve i sinhronizuju modele podataka i procesa i lokacija. Na 4.32 se
prikazuje primer podatak-proces CRUD matrice.
Slika 4.32. Podatak-proces CRUD matrica
Pored sinhronizacije modela procesa i podataka, neophodno je identikovati i koji podaci e se nalaziti na odreenim lokacijama. Da bi identikovali podatke i prava pristupa na svakoj od lokacija, potrebno je pronai
odgovore na sledea pitanja:
Koji podskup objekata i atributa su neophodni za obavljanje posla
na svakoj od lokacija?
Koji nivo pristupa se zahteva?
Mogu li se na odreenoj lokaciji kreirati, iitavati, menjati ili brisati
instance objekta?
87
Sistemska analiza predlae denisanje ovih logikih zahteva u formi

podatak-lokacija CRUD matrica. Podatak-lokacija CRUD matrica (Data-tolocation-CRUD matrix) je tabela u kojoj redovi pokazuju objekte i mogue
atribute, kolone pokazuju lokacije, a presena polja pokazuju nivo pristupa
gde je C-kreiranje, R-iitavanje, U-menjanje i D-brisanje ili deaktiviranje.
Na slici 4.33 je prikazan primer podatak-lokacija-CRUD matrice, gde se
uoava da e svako prodajno odelenje pristupati samo onim klijentima
koji se nalaze u njihovom regionu.
Slika 4.33. Podatak-Lokacija-CRUD matrica
4.5. Objektno-orijentisana analiza i modelovanje

Objektno-orijentisana analiza (Object-Oriented Analysis - OOA)
je tehnika koja je uspela da eliminie vetaki razdvojene podatake od
procesa. Umesto podataka i procesa koji su kreirali, itali, aurirali i brisali te podatke, oni su zajedno integrisani u objekte. Jedini nain da se
kreiraju, itaju, auriraju ili briu podaci objekta (properties) jeste putem
ugraenih procesa koji se nazivaju metode (methods). Programski jezici
kao to su C++, Visual Basic, C#, Java i mnogi drugi se baziraju na ovoj
objektnoj tehnologiji.
88
Kada se kae da je neto objektno-orijentisano, to u osnovi znai

da se na problem gleda preko objekata koji su ukljueni u taj problem.
Objektno-orijentisani koncepti se koriste u mnogim profesijama. Na
primer, kada projektuje kancelarije arhitekta razmilja o radnim prostorima, temeljima, konstrukciji i vodovodu. To su objekti iz stvarnog sveta.
Arhitekta ne razmilja o procesu nalivanja temelja betonom, zakucavanju
eksera ili spajanju vodovodnih cevi. To su procesi niih nivoa koji imaju
svoju vanost, ali se ne uzimaju u obzir kod projektovanja poslovne zgrade.
Sa konceptima objektnog modeliranja donekle ste se ve upoznali u delu
modeliranje podataka, a u narednom tekstu e se, radi celine, ponoviti
neki i objasniti novi koncepti.
Objektno-orijentisani pristup razvoja sistema je zasnovan na konceptu
objekata koji postoje unutar sistemskog okruenja. Objekti su denisani
kao stvari, ljudi, dogaaji, sistemi, strukture ili ureaji. Efektivan metod
za identikovanje objekata je da se proue scenarija upotrebe (usage
scenarios, koja e kasnije biti detaljnije objanjena) i identikuju imenice
i pridrueni glagoli koji e se prevesti u objekte i pridruena ponaanja.
Na primer, razmotrimo sledei sluaj korienja: Zaposleni kreira ugovor
sa klijentom. Mogu se identikovati sledei poslovni objekti: zaposleni,
ugovor i klijent.
Drugi isto tako vaan koncept u objektnom modelovanju jeste kategorizacija objekta u klase. Klasa je skup objekata koji dele zajednike atribute
i ponaanja. Ljudi rado klasikuju stvari, ne bi li nali slinosti meu njima
i prema tome ih grupisali. Stvari sa slinim svojstvima i ponaanjima se
grupiu zajedno. Na primer, Petar Petrovi i Marija Marjanovi imaju
svoja imena, adrese i zanimanja i poto oboje rade u istom preduzeu,
moemo ih svrstati u klasu zaposlenih radnika. Petar je programer i ima
listu programskih jezika koje koristi, pa ga moemo svrstati u klasu sa
ostalim programerima, a Marija obavlja komercijalne poslove pa emo je
svrstati u klasu sa drugim komercijalistma iz preduzea. Da bi neko bio u
klasi zaposlenih radnika mora imati ime, adresu, zanimanje i ponaanje
radi. Poto Petar i Marija ispunjavaju ove kriterijume, oni su objekti
koji pripadaju ovoj klasi. Odreeni objekat koji pripada klasi naziva se
primerak ili instanca (instance) klase. Svaki objekat koji je instanca klase
ima atribute i ponaanja denisana u klasi.
Atributi ili svojstva jednog objekta su denicije vrednosti koje objekat
poseduje. Da bi se identikovali atributi objekta, treba razmotriti prideve ili
imenice (koje nisu postali objekti) unutar scenarija upotrebe. Svaka instanca
89
objekta sadri sopstveni set vrednosti. Na primer, ukoliko posmatramo

sluaj korienja koji glasi: Klijent sadri broj rauna, naziv i adresu; tada
se uoava da objekat Klijent sadri atribute broj rauna, naziv i adresu sa
konkretnim vrednostima npr. 1007, ComTrade, Savski nasip 7.
Objekti takoe mogu i da izvravaju neke radnje. Stvari koje objekat
radi se nazivaju ponaanja (behaviors) ili servisi. Na primer, vrata se mogu
otvarati, zatvarati, zakljuavati ili otkljuavati. Porudbina se moe modikovati, obrisati, dodati itd. Servisi su specina ponaanja (metode) koje
poslovni objekat mora da izvrava.
Ponaanja implementiraju poslovna pravila, obrauju podatke i pristupaju informacijama. Odnose se na operacije, funkcije ili transformacije
koje izvrava objekat. Da bi se uoila ponaanja treba identikovati akcije
koje objekat mora da izvrava u scenarijima upotrebe. Zatim se analizira
ta objekat mora da radi i koje podatke mora da odrava. Ovakve informacije vode ka neopohodnoj funkcionalnosti ponaanja. Neki od primera
akcija koje objekat moe da izvrava su: izraunavanje ukupnih iznosa ili
odreivanje trokova transporta. Ponaanja treba dodeliti odgovarajuim
objektima.
Jedna od osnovnih prednosti korienja objekata je u tome to objekat
ne mora da otkriva sve svoje atribute i ponaanja. Objekat treba da otkrije
interfejse preko kojih se moe komunicirati sa njim. Druge detalje, koji
nisu vani za korienje objekata treba sakriti od ostalih objekata. Ovaj
objektno-orijentisani koncept se zove enkapsulacija (encapsulation). Na
primer, objekat koji izraunava kvadrat nekog broja mora obezbediti interfejs za dobijanje rezultata. Meutim, unutranji atributi i algoritmi koji se
koriste za izraunavaje kvadrata ne treba da budu dostupni pozivajuem
objektu.
Svaki atribut ili metode unutar neke klase mogu biti:
Javni (public) - oznaava da su atribut ili metoda vidljivi za sve
klase u programu (oznaava se sa +);
Privatni (private) atribut ili metoda su vidljivi samo unutar svoje
klase (oznaava se sa -);
Zatieni (protected) atribut ili metoda su vidljivi samo za klase
naslednice (oznaka #);
Objektno-orijentisani koncept nasleivanje (inheritance) je proces kojim
jedan objekat nasleuje svojstva drugog objekta. Nasleivanje je vano jer
90
podrava koncepciju hijerarhijske klasikacije (tj. odozgo nadole). Ukoliko

postoji nasleivanje, za objekat treba denisati samo one karakteristike
koje ga ine jedinstvenim u klasi, jer opta svojstva objekat nasleuje od
roditelja. Na taj nain, nasleivanje predstavlja mehanizam koji omoguuje
da jedan objekat bude poseban sluaj nekog optijeg objekta. Na primer,
ako biste eleli da ivotinje opiete apstraktno, rekli biste da one imaju
izvesne osobine, npr. veliinu, inteligenciju i vrstu skeletnog sistema.
ivotinje imaju i odreene aspekte ponaanja; one jedu, diu i spavaju.
Ovakav opis osobina i ponaanja predstavlja deniciju klase ivotinja. Ako
elite da deniete odreeniju klasu ivotinja, npr. sisare, oni bi takoe
morali imati odreenije osobine, npr. mlene lezde i tip zuba. Kaemo
da su sisari potklasa (subclass) ivotinja, a ivotinje su sisarima natklasa
(superclass). Poto su sisari samo ue denisane ivotinje, oni nasleuju
sve osobine ivotinja. Potklasa koja se nalazi duboko u hijerarhiji nasleuje
osobine svih svojih predaka u hijerarhiji klase.
Objektno-orijentisani koncept polimorzam (polymorphism) je re
grkog porekla koji znai mnogo oblika i predstavlja koncept koji se
esto objanjava frazom jedan nain pristupa, vie metoda. Polimorzam podrazumeva mogunost pravljenja opteg naina pristupa za rad sa
grupom srodnih aktivnosti. Na primer, ukoliko posmatramo klasu Oblik,
sa ponaanjem Crtaj. Kada nekom kaete da nacrta oblik, pitanje koje
sledi je: Koji oblik? Pretpostavimo da imate niz od tri oblika i to Krug,
Kvadrat i Zvezda. Iako sa svima postupate kao sa objektima nasleenim
iz klase Oblik i svima aljete poruku Crtaj, konani ishod je drugaiji, jer
Krug, Kvadrat i Zvezda obezbeuju konkretnu realizaciju. Svaka klasa je
sposobna da drugaije odgovori na isti metod Crtaj.
Polimorzam omoguava da opta klasa denie metode koje e biti
zajednike za sve klase koje su iz nje izvedene, ostavljajui potklasama
slobodu da deniu specine varijante nekih ili svih pomenutih metoda
(tzv. redenisanje metoda).
91
Slika 4.34. Generalizacija sa redefinisanim metodama
Objektno-orijentisana analiza je naroito postala popularna pojavom

UML (Unied Modeling Language) jezika koji obezbeuje i graku sintaksu za objektne modele. UML denie nekoliko razliitih tipova dijagrama
koji zajedno modeluju jedan informacioni sistem ili aplikaciju u terminima
objekata. Pomou UML-a softverski sistem se moe opisati sa razliitih
aspekata, kao to su:
specikacija zahteva preko modela sluajeva korienja,
specikacija strukture sistema preko dijagrama klasa,
specikacija dinamike sistema preko dijagrama kolaboracije i dijagrama promene stanje,
specikacija implementacije preko dijagrama komponenti,
specikacija rasporeda komponenti u zikoj strukturi preko dijagrama rasporeivanja i sl.
4.5.1. Jedinstveni jezik modelovanja - UML

Object Management Group (OMG) je u Novembru 1997. godine usvojila
kao ocijelnu notaciju objektno-orijentisanog modelovanja - jedinstveni
jezik modelovanja, krae UML (Unied Modeling Language). Cilj OMG
je bio da se kreira standardizovana objektno-orijentisana arhitektura za
distribuirane aplikacije koje podravaju distribuirane objekte, odnosno cilj
im je bio da komponente objektno-orijentisanog softvera imaju osobine
ponovne upotrebljivosti, portabilnosti i interoperativnosti u jednom heterogenom okruenju. Konsenzus oko glavnih ideja i unikacija glavnih
92
metoda objektno-orijentisanog modelovanja kao to su Booch-ova metoda particionisanja sistema u podsisteme, Rumbaugh-ov koncept klase i
asocijacije i Jacobson-ov model korisnikih funkcija za denisanje zahteva
sistema dovele su do pojave UML-a.
UML je metod tree generacije koji slui za specikaciju, vizuelizaciju,
konstrukciju i dokumentaciju razvoja sistema. Namena UML-a je poveanje
produktivnosti, skraenje vremena razvoja i poboljanje kvaliteta informacionih sistema. UML moe da se koristi u razliitim fazama razvoja,
od specikacije zahteva do testiranja zavrenih, gotovih sistema.
Slika 4.35. Aspekti modela u UML-u
UML obezbeuje brojne grake alate koji se mogu koristiti za vizuelizaciju i razumevanje sistema sa razliitih taaka gledita. Dijagrami se
mogu korisiti kako bi se predstavili razliiti pogledi na sistem. Zajedno,
viestruki pogledi na sistem predstavljaju model sistema. Modeli ili pogledi
se koriste kako bi se opisala kompleksnost softverskih sistema. Razliiti
UML pogledi opisuju nekoliko aspekata softverskog sistema. Aspekti koji
se koriste su:
Korisniki pogled opisuje se ponaanje sistema sa take gledita
korisnika. Predstavljaju se ciljevi sistema iz perspektive korisnika i
njihovih sistemskih zahteva. Ovaj pogled predstavlja deo sistema
sa kojima su korisnici u interakciji. Statiki opis ovoga aspekta
daje se preko dijagrama sluajeva korienja, a dinamiki, prvenstveno tekstualno, a zatim i preko dijagrama interakcija, dijagrama
promene stanja ili dijagrama aktivnosti. Ovaj pogled se jo naziva
aspekt sluajeva korienja (use case) i jednom reju predstavlja
funkcionalnu specikaciju sistema.
93
Aspekt projektovanja predstavlja realizaciju sistema u objektnom prostoru stanja. Statiki opis ovoga aspekta daje se preko
dijagrama klasa i dijagrama objekata. Dinamiki opis se daje preko
dijagrama interakcija, dijagrama promene stanja i dijagrama aktivnosti.
Aspekt procesa predstavlja dinamiko stanje sistema. Opisuje
nain odvijanja procesa u sistemu, niti procesa, konkurentnosti i
sinhronizaciju. Koriste se isti dijagrami kao i u aspektu projektovanja
i za statiki i za dinamiki opis, a najvie dijagrami aktivnosti.
Aspekt implementacije predstavlja strukturu logikih elemenata
u sistemu. Predstavlja komponente i fajlove preko kojih se sistem
ziki ostvaruje. Statiki opis ovoga aspekta daje se preko dijagrama
komponenti. Dinamiki opis se daje preko dijagrama interakcija,
dijiagrama promene stanja i dijagrama aktivnosti.
Aspekt razmetanja predstavlja raspodelu zikih elemenata
sistema. Okruenje sistema odreuje funkcionalnost sistema iz
perspektive korisnika. Aspekt razmetanja predstavlja topologiju
sistema, raunarsko-komunikacionu mreu. Pokazuje se kako su
u ovoj mrei razmetene komponente koje predstavjlaju ziku
realizaciju sistema. Dijagrami razmetaja se koriste za statiki
opis. Dinamiki opis se daje preko dijagrama interakcija, dijagrama
promene stanja i dijagrama aktivnosti. Aspekt razmetanja se jo
naziva i aspekt uvoenja (deployment).
Svaki pogled na sistem koristi vie vrsta dijagrama za prikazivanje svog
sadraja, a sa druge strane, jedna vrsta dijagrama moe da se koristi za
prikazivanje delova modela u raznim pogledima na sistem. Na tabeli 4.7
su grupisani UML dijagrami prema opisu strukture sistema.
Tabela 4.7. UML dijagrami prema strukturi sistema
Detaljniji prikaz gupisanja UML dijagrama:

94
I. Dijagrami modelovanja sluajeva korienja:

1. Dijagrami sluajeva korienja (use-case diagrams) - prikazuju
eljenu funkcionalnost sistema.
II. Dijagrami statike strukture:
2. Dijagrami klase (class diagrams) - opisuju razliite klase i njihove
veze (asocijacije).
3. Dijagrami objekta (object diagrams) - opisuju raziliite objekte
u sistemu i njihove meusobne veze.
III. Dijagrami interakcije:
4. Dijagrami sekvenci (sequence diagrams) - opisuju interakcije
izmeu klasa prikazivanjem redosleda poruka koje se razmenjuju izmeu klasa.
5. Dijagrami kolaboracije (collaboration diagrams) - predstavlju
skup klasa i njihovih poslatih i prijemnih poruka.
IV. Dijagrami stanja:
6. Dijagrami stanja (statechart diagrams) - predstavljaju algoritme razliitih stanja jednog objekta koji se dogaaju pri uticaju
razliitih spoljnih dogaaja.
7. Dijagrami aktivnosti (activity diagrams) - predstavljaju drugi
nain pogleda na stanje i ukljuuje i sekvence aktivnosti. Pogodan kod modelovanja konkurentnih procesa kako bi se videla
neophodna sinhronizacija izmeu klasa i zadataka.
V. Dijagrami implementacije:
8. Dijagrami komponenti (component diagrams) - prikazuju
razliite komponente sistema i njihove veze (npr. source code,
object code i execution code).
9. Dijagrami razmetaja (deployment diagrams) - predstavljaju
spajanja softverskih komponenti sa vorovima zike implementacije sistema.
Dijagrami klasa predstavljaju kimeni stub za skoro sve objektnoorijentisane metode. Oni prikazuju statiku strukturu sistemu. Klase u
objektnom modelovanju, prema UML notaciji se prikazuju u obliku pravougaonika (Slika 4.36). Pravougaonik je podeljen u tri dela. U prvom delu
se prikazuje naslov klase. Drugi, sredinji deo sadri imena zajednikih
atributa. Trei, donji deo sadri zajednika ponaanja (metode).
95
Objekti ili klase su povezani preko relacija (veza). UML denie etiri
tipa relacija:
Zavisnost relacija izmeu dva objekata u kojoj promena na jednom objektu utie na ponaanje drugog objekta. Relaciju zavisnosti
treba upotrebiti onda kada elimo da pokaemo da jedan objekat
koristi drugi.
Zavisnost izmeu dva objekta se predstavlja usmerenom isprekidanom linijom (Slika 4.36).
Proizvod
-Teina
-Visina
-irina
-Dubina
-Boja
Katalog proizvoda
-SkupProizvoda
+DodajNoviProizvod(Proizvod p)()
Slika 4.36. Primer relacije zavisnosti
Asocijacija kada su dve klase konceptualno vezane jedna za

drugu. Na UML dijagramima asocijacija se predstavlja punom
linijom izmeu dve klase, sa nazivom asocijacije na vrhu (Slika
4.37).
Proizvod
-Visina
-Teina
-irina
-Dubina
-Boja
-OrganizovaniPo
*
-Organizuje
*
Kategorija
-KategorijaID
-NazivKategorije
Slika 4.37. Primeri relacije asocijacije
Asocijacija kao tip veze moe biti kompleksnija ukljuivanjem

vie od dve klase u relaciju. Ponekad veza izmeu dve klase mora
biti ispraena nekim pravilom. To pravilo se najee stavlja dodavanjem ogranienja pored linije koja predstavlja vezu klasa
(Slika 4.38).
96
Raun
Klijent
Super market
Kupuje od
Slika 4.38. Primer sloenije asocijacije
Postoje dva tipa aoscijacije: agregacija i kompozicija. Agregacija

predstavlja vezu izmeu celine i njenih delova. Na primer, Osoba
je zaposlena u Kompaniji (Slika 4.39). Agregacija je veza izmeu
dva jaka objekta, gde e objekat B koji je dinamiki atribut objekta
A ostati vidljiv i kada objekat A prestane da postoji. Agregacija je
predstavljena punom linijom sa praznim rombom na kraju linije
koja se povezuje sa celinom.
Kompanija
1..*
- Osoba moe da postoji i da nije

lan kompanije .
- Objekat Kompanija ne upravlja
ivotnim vekom objekta Osoba.
Osoba
Slika 4.39. Relacija agregacije
Ukoliko celina upravlja ivotnim vekom delova onda se takva veza

naziva kompozicija (Slika 4.40). Kompozicija odgovara vezi izmeu
jakog i slabog objekta u modelu objekti veze. Objekat B koji je
statiki atribut objekta A je vidljiv sve dok objekat A postoji, jer je B
egzistencijalno zavistan od A. Kompozicija je predstavljena punom
linijom sa popunjenim rombom na kraju linije koja je povezana sa
celinom.
97
Porudbina
0..*
- Porueni proizvodi ne mogu da

egzistiraju bez postojee porudbine .
- Objekat Porudbina upravlja ivotnim
vekom objekta PorueniProizvodi .
PorueniProizvodi
Slika 4.40. Relacija kompozicije
Generalizacija relacija izmeu optijeg tipa (roditelja) i odreenijih tipova (dete). Generalizacija se prikazuje kao puna linija sa
praznom strelicom koja ukazuje na roditelja (Slika 4.41).
Klijent
Kupac
Prodavac
Slika 4.41. Relacija generalizacije
Realizacija relacija izmeu klasa, gde jedna apstraktna klasa

odreuje zadatke koje druga klasa mora da iznese. Generalizacija je
predstavljena isprekidanom linijom i praznom strelicom usmerene
na roditelja (Slika 4.42).
98
Organizacija
Udruenje
+KreirajRaun()
+ObriiRaun()
+AurirajRaun()
-Naziv
-Adresa
-Telefon
-Kontakt
-Status
-Komentari
+DodajKontakt()
+AurirajKontakt()
+ObriiKontakt()
Slika 4.42. Relacija realizacije
Specijalan vid asocijacije je viestrukost ili multiplikativnost (multiplicity) koja pokazuje broj objekata jedne klase koji su u relaciji sa odreenim
brojem elemenata u drugoj klasi. Primer UML notacije viestrukosti je
prikazana u tabeli 4.8.
Tabela 4.8. Primer UML notacija viestrukosti
99
Relacije se mogu identikovati iz sluajeva korienja tako to se iz

scenarija izvlae informacije koje opisuju zike lokacije, usmerene akcije,
komunikacije, posedovanje ili ukazuju na ispunjene uslove. Relacije prikazuju kako akcije objekata ili sistema utiu na druge objekte ili sisteme.
Dijagram klasa se koristi da bi se:
predstavio osnovni renik sistema koji denie pojmove koji se u
tom sistemu koriste;
opisala struktura neke kolaboracije;
predstavila logika ema baze podataka.
Opis sistema obino sadri vie dijagrama klasa. Primer dijagrama klasa
prikazan je na slici 4.43.
Slika 4.43. Primer dijagrama klasa
Dijagram objekata je varijanta dijagama klasa i koristi skoro istu notaciju, a razlika je u tome to, umesto klase, prikazuje jednu ili vie instanci
klase sa konkretnim podacima. Dijagrami objekata modeliraju stanje
sistema u jednom trenutku vremena, tj. daju zamrznutu sliku sistema u
jednom trenutku vremena. Dijagrami objekata daju statiku strukturu za
opis dinamikog ponaanja sistema preko dijagrama interakcije. Oni su
100
pojavljivanje odgovarajueg dijagrama klasa i statiki deo dijagrama interakcije. Predstavljaju skup objekata i pojavljivanja veza, a mogu da sadre
komentare i ogranienja i da budu podeljeni u pakete i podsisteme.
Dijagrami sluajeva korienja modeluju funkcionalnost sistema
prikazujui uesnike (korisnike sistema) i njihove veze sa sluajevima
korienja. Sluajevi korienja su opisi pojedinanih funkcija vien iz
perspektive korisnika. Uesnik je bilo koji spoljni entitet, ovek, drugi
sistem ili neki hardverski ureaj, koji treba da komunicira sa sistemom
koji se modelira. Sam proces kreiranja modela ini: denisanje sistema,
uoavanje uesnika i sluajeva korienja, opisivanje sluajeva korienja,
denisanje veza izmeu funkcija i na kraju validacija modela.
Slika 4.44. Primer dijagrama sluajeva korienja
Dijagram sekvenci prikazuje dinamike veze objekata, redosled poruka

koje objekti razmenjuju, dogaaje koji se deavaju u odreenom trenutku
rada. Dijagram se sastoji od vie objekata pri emu se proticanje vremena
prikazuje odozgo na dole, poruke horizontalnim usmerenim linijama, dok
se dodatni komentari piu na marginama dijagrama.
Slika 4.45. Primer dijagrama sekvenci
101
Dijagrami komunikacije ili saradnje (kolaboracije) opisuju statiku

strukturu i dinamiko ponaanje sistema, pri emu se prikazuju veze meu
objektima, odnosno konekst u kom se objekti koriste. Razlika u upotrebi
dijagrama sekvenci i ovog je u aspektu koji naglaava vreme tj. redosled
(koristi se sekvencni dijagram) ili kontekst (koristi se dijagram saradnje).
Dijagramu se mogu dodati i uslovi, iteracije, povratne vrednosti itd.
Slika 4.46. Primer dijagrama komunikacije [1]
Dijagram stanja obino predstavlja dodatak opisu klase jer pokazuje

sva mogua stanja u kojima se objekti jedne klase mogu nai i dogaaje
koji prouzrokuju promene stanja. Dogaaj moe biti poruka koju alje
drugi objekat, ispunjenje nekog uslova, proteklo vreme i slino. Promena
stanja se naziva prelaz i moe mu se pridruiti akcija koja specicira ta
treba da se uradi pri tom prelazu. Dijagram stanja predstavlja stanja u
kojima objekat moe da bude tokom tranzicije iz jednog u drugo stanje i
prikazuje poetnu taku i krajnju taku sekvence koja menja stanje. Bitno
je napomenuti da dijagram stanja prati stanje samo jednog objekta. Stanja se predstavljaju sa zaobljenim pravougaonikom, dok se simbol transakcije stanja predstavlja punom linijom sa strelicom. Punim krugom se
predstavlja poetna taka, a krajnja sa krugom sa takom u sredini. Sam
102
zaobljeni pravougaonik se stoji od tri dela. U gornjem se nalazi naziv

stanja (ovaj podatak obavezno mora biti unet), u sredini se nalazi podatak o stanju promenjive, dok je u donjem delu informacija o aktivnosti.
Aktivnosti mogu imati tri opisa: entry- ta se deava kada sistem ulazi u
stanje, exit- ta se deava kada sistem napusti stanje, do- ta se deava sa
sistemom kada je u stanju.
Slika 4.47: Primer dijagrama stanja [1]
Nekada su stanja u kojima se nalazi sistem previe komplikovana, te

se tada predstavljaju podstanjima u jednom stanju.
Dijagrami aktivnosti prikazuju redosled toka aktivnosti i obino
podseaju na slike algoritama. On se sastoji od koraka (zvanih aktivnosti), taaka odluke i grananja. Veoma je koristan za pokazivanje ta se
deava u poslovnim procesima ili operacijama. Pre svega dijagrami aktivnosti se prave da bi se lake shvatilo ta se deava tokom procesa. Oni
na neki nain predstavljaju nadogradnju dijagrama stanja. Dijagrami
stanja pokazuju stanja objekata i prezentuju aktivnosti strelicama. Dijagrami aktivnosti stavljaju akcenat na aktivnostima. U UML notaciji svaka
aktivnost se predstavlja elipsom. Tranzicija sa jedne na drugu aktivnost
se predstavlja strelicom, dok se na vrhu svakog dijagrama aktivnosti nalazi pun krug (koji oznaava poetak), a u dnu prazan krug sa takom
koji oznaava kraj. Element grananja se prikazuje u obliku dijamanta, do
koga dolazi strelica koja pokree grananje, a iz njega izlaze dve grane, u
zavisnosti da li je uslov ispunjen ili ne. Obino se na linijama koje izlaze
iz dijamanta ispisuje vrednost uslova koji treba da ispuni grananje da bi
tok podataka krenuo na tu stranu
Prilikom projektovanja aktivnosti veoma se esto deava da se neka
aktivnost podeli na dva odvojena dela koja se izvravaju u isto vreme
103
(konkurentno), da bi se na kraju izvrenja obe slile ponovo u jednu. To

deljenje aktivnosti na dva dela se obeleava sa zadebljanom linijom u koju
ulazi strelica iz poetne aktivnosti. Iz zadebljane linije izlaze dve strelice
koje predstavljaju novonastale aktivnosti i opet se zavravaju u zadebljanoj liniji iz koje izlazi jedna strelica, oznaavajui da je konkurentni
rad zavren.
Slika 4.48. Primer dijagrama aktivnosti
Dijagram komponenti prikazuje ziku strukturu kda tj. komponenti kda, pri emu komponenta moe biti izvorni ili izvrni program.
Komponente mogu da se grupiu u pakete, a prikazane zavisnosti meu
njima omoguavaju laku analizu uticaja jedne komponente na ostale
komponente.
Dijagram razmetaja prikazuje ziku arhitekturu hardvera i softvera
u sistemu. Prikazuje se povezanost raunara i ureaja, tj. vorova sa tipovima veza. U pojedinim vorovima se navode softverske komponente
koje se u njima izvravaju, kao i zavisnost meu komponentama. Primer
dijagrama razmetaja je prikazan na slici 4.49.
104
4.5.2. Proces objektnog modelovanja

Kod objektno-orijentisane analize (OOA), kao i kod drugih metoda
sistemske analize, namera je da se to bolje shvati sistem i njegovi zahtevi.
Drugim reima, OOA zahteva da se identikuju objekti, njihovi atributi,
ponaanja i relacije koji podravaju zadate poslovne zahteve sistema. Faze
obavljanja objektno-orijentisane analize su sledee:
Slika 4.49. Primer dijagrama razmetaja [1]
Modelovanje funkcija sistema sluajevima korienja.

Modelovanje aktivnosti sluajeva korienja upotrebom dijagrama
aktivnosti.
Pronalaenje i identikacija poslovnih objekata.
Organizovanje objekata i identikovanje njihovih relacija.
105
MODELOVANJE FUNKCIJA SISTEMA

U narednom poglavlju e biti detaljnije objanjen proces modelovanja
zahteva sluajevima korienja. Tokom ovog procesa, dokumentovani su
sluajevi korienja koji sadre opte informacije o poslovnim dogaajima.
Cilj koji se eleo postii jeste brzo dokumentovanje svih poslovnih dogaaja
(sluajeva korienja) kako bi se denisali i verikovali svi poslovni zahtevi.
Koraci kod analize modela sluajeva korienja su:
identikovanje, denisanje i dokumentovanje novih aktera;
identikovanje, denisanje i dokumentovanje novih sluajeva
korienja;
redenisanje dijagrama sluajeva korienja (ukoliko je neophodno);
dokumentovanje scenarija upotrebe sluajeva korienja.
Koristi od modelovanja sluajeva korienja su sledee:
Slui kao osnova za identikovanje objekata i njihovih relacija i
odgovornosti;
Prua pogled na ponaanje sistema iz ugla spoljnjeg korisnika;
Predstavlja efektivan alat za validaciju zahteva;
Predstavlja efektivan alat za komunikaciju;
Slui kao osnova za testiranje plana;
Slui kao osnova za korisniki prirunik.
MODELOVANJE AKTIVNOSTI SLUAJEVA KORIENJA UPOTREBOM
DIJAGRAMA AKTIVNOSTI
Da bi se modelovali koraci ili aktivnosti procesa sistema koristi se
dijagram aktivnosti. Dijagram aktivnosti je veoma slian algoritmu jer
opisuje sekvencionalni tok aktivnosti svakog poslovnog procesa ili sluaja
korienja. Za razliku od obinih algoritama, dijagrami aktivnosti opisuju
aktivnosti koji se paralelno odvijaju. Primer dijagrama aktivnosti je dat
na slici 4.50.
106
PRONALAENJE I IDENTIFIKOVANJE POSLOVNIH OBJEKATA

Koraci su:
pronalaenje potencijalnih objekata;
selekcija predloenih objekata;
Slika 4.50. Primer dijagrama aktivnosti
ORGANIZOVANJE OBJEKATA I IDENTIFIKOVANJE NJIHOVIH RELACIJA

Nakon identikovanja poslovnih objekata sistema, neophodno je iscrtati dijagram klasa koji opisuje objekte i njihove asocijacije. Dijagram
klasa ukljuuje i viestrukosti, relacije generalizacije/specijalizacije i
agregacije.
Koraci su:
identikovanje asocijacija i viestrukosti;
identikovanje relacija genralizacije/specijalizacije;
identikovanje relacija agregacije.
107
5. Razvoj poslovnih reenja prema MSF okviru
S obzirom da se u ovoj knjizi bavimo poslovnim informacionim sistemima, osvrnuemo se na metodologije koje obezbeuju skup modela, principa
i smernica za projektovanje i razvoj poslovnih reenja. Jedan od poznatijih
je MSF (Microsoft Solution Framework) kompanije Microsoft.
Zato se veina kako inostranih tako i domaih rmi okree primeni
MSF okvira u razvoju poslovnih informacionih sistema ili krae poslovnih
reenja? Naime, u praksi se pokazalo da je svega 16% uspenih projekata,
dok je 31% propalih, a ostatak ine oni projekti koji se na neki nain
mogu nazvati uspenim, ali su ili probijeni rokovi ili su isporueni sa
loijom funkcionalnou i slino (Slika 5.1). Ono to je i Microsoft hteo
da postigne, a to je da je primenom MSF okvira zabeleen rast na 20%
uspenih projekata sa tendencijom porasta. Microsoft je u MSF ugradio
najbolje prakse uspenih projekata.
MSF nije metodologija ve okvir (framework). Za razliku od metodologija koje daju tane smernice, korake kojih se treba striktno pridravati,
framework je kao kompas, potvruje napredovanje i daje upravljake
smernice, slui kao podrka metodologijama.
Slika 5.1. Procentualni prikaz uspenosti projekata (Izvor: Standish grupa)
MSF obezbeuje skup modela, principa i smernica za projektovanje i

razvoj poslovnih reenja na nain koji osigurava da se svim elementima
projekta (npr., ljudi, procesi, alati) uspeno upravlja. MSF takoe obezbeuje
dokazane prakse za planiranje, projektovanje, razvoj i uvoenje uspenih
poslovnih reenja.
108
MSF kombinuje dva razliita pristupa ivotnog ciklusa projekta:

model vodopada (waterfall model) kod ovog modela svi zadaci
u jednoj fazi se moraju zavriti pre nego to se pree na sledeu
fazu. Ovaj model se koristi kod onih projekata gde su zahtevi jasno
denisani i nisu skloni modikacijama u budunosti.
spiralni model (spiral model) - ovaj model se bazira na kontinualnoj potrebi za usavravanjem projekta. Spiralni model je efektivan
kada se koristi brzi razvoj aplikacija (Rapid Application Development - RAD) kod vrlo malih projekata. Ovaj pristup stvara veliku
sinergiju izmeu razvojnog tima i klijenata, jer klijent obezbeuje
povratne informacije i odobrava svaku fazu.
MSF procesni model opisuje generalne sekvence aktivnosti za izgradnju
i uvoenje poslovnih reenja. On kombinuje najbolje principe modela
vodopada i spiralnog modela. Spiralnost se denie i u okviru samog
projekta, a i u okviru kritinih taaka (milestones) (Slika 5.2).
Slika 5.2. Microsoft-ov primer verzionisanja istog proizvoda
5.1. MSF discipline

MSF obuhvata discipline za upravljanje timovima, procesima, tehnologijom i rizicima, tj. elementima sa kojima se projekti najee susreu. Tri
kljune MSF discipline su:
1. Upravljanje rizicima (Risk Management) podrava proaktivno
upravljanje rizicima, kontinualnu ocenu rizika i odluivanje tokom
ivotnog ciklusa projekta. Projektni tim kontinualno procenjuje,
nadgleda i aktivno upravlja rizicima. Upravljanje rizicima prema
MSF-u denie est koraka tokom kojih tim upravlja tekuim rizicima, planira i izvrava strategije upravljanja rizicima:
109
a. Identikovanje rizika primenom brainstorming-a mogu se

identikovati svi potencijalni rizici.
b. Analiza rizika prema proceni verovatnoe dogaaja rizika
i njegovog uticaja na sistem, rizici se sortiraju prema prioritetu.
c. Planiranje rizika koriste se informacije dobijene analizom
rizika kako bi se formulisali planovi, strategije i akcije. Za svaki
rizik se procenjuje njegov uticaj na ishod projekta, navode
se naini njegovom umanjenja i koraci koje treba sprovoditi
ukoliko do rizika doe.
d. Praenje rizika nadgleda se status odreenih rizika.
e. Kontrolisanje rizika proces izvravanja planova akcija i
njihovog izvetavanja.
f. Uenje iz rizika formuliu se nauene lekcije kako bi se to
znanje ponovo upotrebilo u slinim sluajevima kod buduih
projekata.
2. Upravljanje spremnou tima (Readiness Management) podrazumeva nain podizanja nivoa spremnosti cele ekipe (motivacija,
edukacija, interesantnost, iskustvo i dr.). Upravljanje spremnou
ukljuuje procese koji pomau da se razviju znanja, vetine i sposobnosti neophodne za kreiranje i upravljanje projektima i reenjima.
Prate se sledea etiri koraka:
a. Denisanje (Dene) Deniu se scenarija, kompetencije i
nivoi strunosti neophodnih za uspeno planiranje, kreiranje
i upravljanje reenjima.
b. Ocena (Assess) - Za svaku ulogu u organizaciji se analiziraju
kompetencije i porede sa prethodnim korakom. Prave se planovi
uenja.
c. Promene (Change) Tokom ovog koraka lanovi tima
poboljavaju vetine i podiu nivo strunosti do eljenog nivoa.
Prema planu uenja odreeni lanovi tima se obuavaju i prati
se njihov napredak.
d. Procena (Evaluate) - Tim procenjuje da li su planovi obuke
bili efektivni i da li je steeno znanje uspeno implementirano
na poslu.
110
3. Upravljanje projektima (Project Management) Kod MSF modela ne postoji uloga projekt menadera, niti rigidna hijerarhijska
struktura u procesu odluivanja. MSF se bori protiv rigdnog, diktatorskog stila koji je prisutan kod projekt menadmenta. Sve uloge u
timu ispunjavaju odreeni cilj i svi se smatraju podjednako bitnim.
Glavne odluke se donose konsenzusom kljunog tima. Ukoliko
se konsenzus ne moe postii, program menader donosi nalnu
odluku. Program menadment je taj koji donosi odluke tako da
one budu u skladu sa zahtevima klijenata. Upravljanje projektima
je proces koji kombinuje skup vetina i tehnika kako bi se ispunili
sledei zadaci:
a. Integracija planiranja i upravljanje promenama
b. Deninisanje i upravljanje ciljevima i oblau projekta
c. Pripremanje budeta i upravljanje trokovima
d. Pripremanje i praenje rasporeda odvijanja projekta
e. Osigurati da su odgovarajui resursi alocirani na projektu
f. Olakati timsku i spoljnu komunikaciju
g. Olakati proces upravljanja rizicima
h. Dokumentovanje i nadgledanje procesa upravljanja kvalitetom
tima.
Upravljanje
timom
MSF
Upravljanje
rizicima
Upravljanje
procesima
projekta
Slika 5.3. MSF discipline
111
5.1.1. MSF procesni model

MSF procesni model (MSF Process Model) opisuje aktivnosti za izgradnju i uvoenje poslovnih reenja u sistem. Ovaj model se moe primeniti
i na razvoj i uvoenje klasinih aplikacija, poslovnih reenja za elektronsku
trgovinu (e-commerce) ili na Web distribuirane aplikacije.
MSF procesni model se sastoji od pet razliitih faza:
1. Stvaranje vizije (Envisioning) identikuju se ciljevi, domen i
ogranienja projekta, razmatra izvodljivost projekta, procenjuju
neophodni resursi, formira se projektni tim i utvruju odgovornosti
lanova tima, analiziraju potencijalni rizici i dr.
2. Planiranje (Planning) pravi se konceptualni, logiki i ziki
dizajn reenja, projektuju sloj prezentacije, sloj podataka i specikacije bezbednosti.
3. Razvijanje (Developing) kodiranje reenja.
4. Stabilizovanje (Stabilizing) - pregled pilot reenja, piu se korisniki
help-ovi, prirunici za obuku i dokumentacija za rukovanje, vri se
testiranje i izvetava o bagovima.
5. Uvoenje (Deploying) priprema se okruenje za uvoenje reenja,
aurira se dokumentacija, pravi se plan testiranja, plan bezbednosti,
backup plan, plan oporavka od oka i vri obuavanje.
Svaka faza zavrava sa jednom kritinom takom (milestone). Na slici
5.4. se ilustruju faze i kritine take MSF procesnog modela. Da bi se prelo
iz prve u drugu fazu, fazu planiranja, neophodno je da je odobren Vizija/
domen (Vision/Scope) dokument, odnosno dokument koji opisuje ciljeve
projekta i ogranienja (zahtevi koji e se ispuniti, funkcionalnosti i inicijalni vremenski raspored). Da bi se iz faze planiranja prelo u fazu razvoja
reenja neophodno je da se odobri projektni plan koji sadri funkcionalnu specikaciju konkretnog reenja, plan projekta (master project plan),
raspored projekta (master project schedule) i aurirani dokument ocene
rizika (risk assessment). U toku faze razvoja prate se performanse developera
putem dnevnog rasporeda (daily bill), koji prikazuje koje funkcionalnosti
moraju dnevno da budu zavrene. Kada se postigne eljena funkcionalnost
reenja u okviru odreenih granica projekta prelazi se na sledeu fazu
fazu stabilizacije.
112
Faza stabilizacije se nalizira kada su reeni svi kritini i ozbiljni bagovi

u reenju i odobravanjem dokumenta spremnosti putanja u rad (Release
Readiness Approved). Faza uvoenja (Deploying) je zavrena kada je stabilizovano uvedeno reenje i dobijeno i nalno odobrenje od klijenata.
Slika 5.4. MSF procesni model [9]
5.1.2. MSF timski model

Pored procesnog modela MSF obezbeuje i timski model za organizaciju projektnih timova. Ovaj model istie vanost jasnih uloga (rola),
odgovornosti i ciljeva pojedinanih lanova projektnog tima. Fleksibilnost
MSF timskog modela omoguava da se bre prilagodite ciljevima projekta,
veliini tima i vetinama lanova tima.
MSF timski model specira est razliitih uloga (Slika 5.5):
1. Proizvodni menadment (Product Management). Proizvodni
menader vodi poetne razgovore sa naruiocima posla, prikuplja zahteve, dogovara ta e se raditi, uspostavlja rokove,
ogranienja.
2. Program menadment (Program Management). Program
menader sastavlja funkcionalnu specikaciju (master project
plan i master project schedule). Odgovoran je za razvoj i isporuku
reenja.
3. Razvoj (Development). Razvojni tim ili tzv. developeri su odgovorni
za razvoj tehnolokog reenja prema specikacijama dobijenih od
strane program menadera.
113
4. Testiranje (Testing). Testiranje je jedna od vanijih rola. Tim koji

vre testiranje pronalazi bug-ove, probaju sve module kako bi nalno
reenje bilo to stabilnije, uporeuju funkcionalnosti programa sa
ciljevima i vizijom projekta.
5. Menadment putanja reenja u rad (Release management).
Prave Help-ove, implementiraju i instaliraju sistem. Odgovorni su
za rukovanje i odravanje sistema.
6. Iskustveni korisnik (User experience). Poznaje obe strane procesa, proizvodnje i upotrebe. Unosi podatke, analizira performanse,
koriguje ekrane kako bi reenje bilo to upotrebljivije i dr.
Kod manjih projekata, pojedinci projektnog tima mogu da imaju vie
uloga, ali to moe dovesti do odreenih rizika na projektu. Nije dobro
na primer, da jednoj osobi budu dodeljene uloge program menadera i
developera.
Slika 5.5. MSF timski model
5.1.3. Upravljanje kompromisima

Projekti esto propadaju jer su ili kasno zavreni ili prevazilaze planirani
budet. Ovi problemi su esto posledica nedovoljno jasno postavljenih
ciljeva i granica projekta. Granice ili domen projekta tano odreuju ta
e reenje da radi, a ta ne. Da bi efektivno denisali i upravljali granicama
projekta, neophodno je:
114
identikovati ogranienja projekta

upravljati kompromisima (tradeos)
uspostaviti kontrolu promena
pratiti napredak projekta.
U projektima postoji jasan odnos izmeu resursa, vremenskog rasporeda i funkcionalnosti projekta. S obzirom da je skoro nemogue ostvariti
istovremeno sve ciljeve, neophodno je upravljati kompromisima. MSF alati
za upravljanje kompromisima su:
trougao kompromisa (tradeo triangle) svaka promena na
jednoj komponenti odraava promenu na drugoj. Projektni tim
zajedno sa klijentima treba da odredi i odrava korektan balans
izmeu resursa, datuma uvoenja reenja i funkcionalnosti. Trougao
kompromisa pomae da se objasne ogranienja i predstave opcije
kompromisa.
Slika 5.6. Trougao kompromisa
matrica kompromisa projekta (project tradeo matrix) alat

koga projektni tim i klijenti koriste kada treba da donesu odluke o
kompromisima. Veoma je vano da se ove odluke donesu u ranim
fazama projekta.
Na slici 5.7. se prikazuje matrica kompromisa za sluaj da su resursi
ksirani, vremenski raspored odreen, a funkcionalnosti su onda
prilagodljive.
115
Slika 5.7. Matrica kompromisa projekta
5.2. Tehnike prikupljanja informacija i analiziranje

poslovnih problema i zahteva
Efektivno prikupljanje podataka je krucijalno kod razvoja projekata.
Sistemska analiza zahteva jedan organizovan metod prikupljanja injenica.
Kada prikupljate odreene informacije, treba da budete svesni injenice
da postoje razliiti tipovi i karakteristike informacija. Preduzee je jedan
dinamiki poslovni sistem u okviru koga se informacije mogu svrstati u
etiri kategorije:
Poslovne opisuje kako se radi posao, odnosno opisuje funkcije
i unakrsne aktivnosti koje posao obavlja. Informacije iz ove kategorije opisuju i primarne ciljeve, proizvode i usluge, nansije,
integrisane poslovne funkcije i procese, organizacionu strukturu
i njihove meusobne veze. Ovde su ukljuene i poslovne strategije
i planovi za prelazak iz postojeeg u budue stanje sistema.
Aplikacije automatizovane i neautomatizovane usluge koje
podravaju poslovne procese. Ukljuuju gotove aplikacije, komponente, izvorne kodove koje su dostupne za analizu informacija
ili funkcionalnosti zadatka.
esto se deava da se u nekoj organizaciji, identini zadaci vie
puta izvravaju putem razliitih alata. U toku prikupljanja podataka o procesima, treba istraiti razliite aplikacije koje se koriste
za obavljanje poslovnih aktivnosti kako bi se uoile potencijalne
neekasnosti ili redundantnosti. Ova kategorija obezbeuje informacije o trenutnoj upotrebi sistema i usluga.
116
Operacije informacije koje su neophodne da bi se pokrenuo

poslovni proces. Ova kategorija ukljuuje standardne modele podataka, politike upravljanja podacima i opisuje izvore informacija i
njihovo korienje u poslovanju. esto korisnici ne znaju adekvatno
da odrede koje su im informacije neophodne i ta treba da rade sa
informacijom kada je dobiju. Identikovanje porekla informacija,
vlasnitva i njihove upotrebe, omoguava praenje i analiziranje
informacija koje mogu posluiti kao osnova za donoenje odluka
vezanih za distribuciju podataka, particionisanje, repozitorijume,
skladitenje podataka (data warehousing) i dr. Razumevanje kljunih
poslovnih procesa i informacija koje su neophodne za njihovo
obavljanje, omoguava da se postave standardi i smernice za kreiranje, prikupljanje, auriranje i brisanje informacija i podataka,
za deljenje kritinih dokumenata i podataka i za denisanje nivoa
bezbednosti i standarda za pristup. Treba biti svestan injenice da se
sve informacije ne mogu nai na jednom mestu niti su pristupane,
veina kritinih informacija se nalazi na serverima baza podataka,
radnim stanicama ili esto u glavama zaposlenih.
Tehnologije tehnike usluge neophodne za izvrenje i podrku
poslovne misije. Ukljuuju topologije, razvojna okruenja, bezbednost, usluge mree, DBMS, tehnike specikacije, operativne
sisteme, hardvere i dr. Ova kategorija takoe obezbeuje informacije o standardima i smernicama za nabavku i uvoenje radnih stanica i serverskih alata, aplikacija, infrastrukturnih usluga,
mrenih komponenata i platformi. Tehnologije obezbeuju vezu
izmeu aplikacija i informacija. Aplikacije se kreiraju i baziraju na
razliitim tehnologijama. One koriste tehnologije kako bi pristupale
informacijama. Informacije iz ove kategorije se mogu koristiti za
odreivanje interfejsa, usluga i aplikacionih modela.
Kategorije informacija se mogu pronai u razliitim oblicima. Brojnost
i raznovrsnost izvora informacija zavisie od veliine poslovanja. Neke od
informacionih izvora su:
injenice (artifacts) obezbeuju informacije o zadacima, procesima, poslovnim potrebama i ogranienjima, na primer to mogu
biti prirunici, nansijski izvetaji, dokumentacije, programske
datoteke, video snimci itd. Prvi dokument koji bi analitiar eleo
da vidi je organizaciona struktura. Organizaciona struktura slui
da identikuje kljune uloge na projektu kao i njihove odnose u
117
izvetavanju. Sledee to bi analitiar prikupio jesu dokumenta

koja opisuju probleme koje su dovele do projekta. Ta dokumenta
mogu biti interna prepiska, predlozi, albe klijenata, izvetaji koji
ukazuju na oblast problema, performanse, merenje rada, raune,
zahteve za informacionim sistemima itd. Pored dokumenata koji
opisuju probleme, prouavaju se i dokumenta koja opisuju poslovne
funkcije. Ta dokumenta ukljuuju misiju kompanije, strategijski
plan, ciljeve organizacionih jedinica, pravilnike, standardne procedure rada, instrukcije za obavljanje dnevnih operacija, forme
koje predstavljaju transakciju u razlitim takama ciklusa obrade,
baze podataka, ekrane i izvetaje. Analitiar e takoe prouavati
i dokumentaciju svojih prethodnika kao to su razliiti tipovi algoritama i dijagrama, renici projekata, repozitorijumi, dokumentacije projektovanja (inputi, autputi i baze podataka), programske
dokumentacije, prirunici za obuavanje itd.
Sistemi pokazuju kako se obavljaju svakodnevne poslovne aktivnosti. Odreeni sistem je skup diskretnih procesa koji izvravaju
jednu akciju. Sistem moe biti sastavljen od podsistema. Sistem
moe da bude opipljiv proces, kao to je na primer sistem za praenje
zaliha ili neopipljiv kao to su na primer metode koje menader
koristi da bi identikovao i reio probleme u okviru svog odeljenja.
Sistemi mogu biti sloeni jer mogu da sadre vie podsistema i
mnoge kategorije informacija.
Ljudi Ljudi mogu biti vredan izvor informacija jer omoguavaju
uvid u celokupno poslovanje preduzea. Njih ine izvrioci, developeri, menaderi, klijenti i korisnici. U sluaju gde je dokumentacija nekompletna ili ak ne postojea, jedini izvor informacija
su ljudi.
Pre nego to priete ljudima, odvojite vreme da identikujete
razliite uloge (role) koje ljudi obavljaju na poslu. Na primer, grupa
ljudi koja prua podrku i informacije korisnicima, mogu da ukau
na oblasti koje predstavljaju najvie potekoa korisnicima. Zaposleni sa iskustvom mogu da ukau na to kako razliite aktivnosti
utiu jedna na drugu. Takoe, ukoliko preduzee koristi spoljne
prodavce (vendore) onda oni mogu da ukau na ekasnost poslovanja i njihove procese.
118
5.2.1. Tehnike za prikupljanje informacija

Postoji est glavnih tehnika za prikupljanje informacija:
Praenje (Shadowing) je tehnika koja podrazumeva direktno
posmatranje kako pojedinac obavlja svoj posao u svom radnom
okruenju kako bi se uvidela praksa i eventualni problemi. Da bi ste
prikupili to vie informacija podstaknite korisnika da vam detaljno
objanjava razloge obavljanja svih zadataka. Praenje moe biti:
pasivno - podrazumeva posmatranje korisnika i pasivno sluanje
svih objanjenja vezanih za obavljanje posla;
aktivno pored posmatranja, vi postavljate i pitanja dok korisnik objanjava dogaaje i aktivnosti. Takoe vam se moe
ukazati prilika da izvravate neke od zadataka.
Tehnika praenja je korisna kod zadataka koji se esto dogaaju.
Praenje je dobar nain da se naui kako korisnik ispunjava svoje
dnevne zadatke. Meutim, moe se desiti da korisnik u toku sesije
ne izvri sve zadatke koje su mu dodeljene, ve samo odreene.
Na primer, raunovoe mogu praviti odreene izvetaje tek na
kraju meseca, developeri mogu praviti nedeljne izvetaje itd. U
toku praenja poeljno je prikuptiti i dokumenta, ekranske forme
trenutnog reenja i dr. Ovom tehnikom se mogu uvideti i elementi
trenutnog reenja kao i procesi koji izazivaju kod korisnika nezadovoljstvo i frustracije. Tokom procesa praenja prikupite to vie
informacija o poslu i zadacima koji se izvravaju u sistemu, karakteristikama sistema, prioritetima, potrebama za dokvalikacijom
korisnika, kao i dokumenta i druge injenice (artifakte).
Tokom prikupljanja informacija tehnikom aktivnog praenja,
podstiite korisnika da odgovori na sledea pitanja:
Kako je strukturian va posao?
Koje odluke treba da donesete pre nego to ponete da izvravate
odreeni zadatak?
Kako implementacija reenja denie nain obavljanja zadataka?
Koje varijacije u proceduri obavljanja zadataka postoje? Pod
kojim uslovima se koriste varijacije?
Tokom date aktivnosti sa koliko ljudi ste u interakciji?
Kako prekidi utiu na vas? Da li moete brzo da nastavite tamo
gde su vas prekinuli?
119
ta bi vam olakalo obavljanje posla?

Kako bi procesi mogli da budu ekasniji? Da li zadaci koji se
obavljaju runo mogu biti automatizovani?
Koji zadaci mogu uticati na projektovanje reenja?
Koji su kriterijumi za merenje performansi?
Kako bi funkcionalnosti reenja trebale da budu strukturirane?
Kako bi moglo da se pobolja trenutno stanje?
Koje funkcionalnosti sistema se esto koriste, a koje retko?
ta se korisnicima svia, a ta ne kod trenutnog sistema?
Koja su korisnikova radna okruenja?
Kako bi mogli da se smanje trokovi obuke i podrke?
Koje informacije o korisnicima nisu dokumentovane?
Koje su karakteristike i prednosti korisnika?
Koje koncepte i terminologiju koriste korisnici?
Kako novi korisnici ue da koriste trentni sistem? Da li novi
korsnici idu na obuku ili ue na poslu? Koliko obuavanje utie
na njihovu sposobnost da koriste sistem i izvravaju zadatke?
Praenje ima i svojih ogranienja. Na primer, s obzirom da se informacije prikupljaju u toku redovnog obavljanja posla, moda neete
imati dovoljno vremena da postavite sva pitanja kako bi razjasnili
svaku taku. Ukoliko hvatate beleke moe se desiti da ispustite
neku kvalitetnu informaciju. Snimanje sesije kamerom moe biti
korisno kod prikupljanja podataka koji su isputeni tokom sesije.
Intervju je koristan kod prikupljanja podataka o procesima u okviru
kojih se zadaci odvijaju relativno brzo, zatim o poslovnim temama
iz ugla menadera i o aspektima poslovanja ili zadataka koji se ne
mogu direktno posmatrati, zbog toga to su ili automatizovani ili
su se dogodili pre dueg vremenskog perioda. Kvalitet prikupljenih
informacija e zavisiti od vetine voenja intervjua, kao i od kompententnosti osobe sa kojom se vodi intervju. Intervjuista moe da
naui dosta o ogranienjima i potekoama trenutnog reenja. Pre
nego to ponete da vodite intervju evo nekoliko vanijih napomena:
Ponite za otvorenim pitanjima (pitanja na koje korisnik nee
davati kratke odgovore) i ohrabrujte korisnike da razmiljaju
o svim zadacima koje izvravaju i informacijama koje mogu da
daju.
120
Koristei odgovore na pitanja, pitajte korisnike da poreaju

vee zadatke i da ih razbiju na nekoliko manjih.
Posebno upitajte korisnike da ukau na informacije koje esto
nedostaju i alternative koje se mogu dogoditi.
Ponovite nekoliko puta korake obavljanja zadatka i zapitajte
korisnika ta bi tu moglo jo da bude ukljueno.
Pitajte korisnika o idejama za poboljanje situacije.
Neka od pitanja koja bi mogli da postavite tokom intervjua su:
Na koje probleme nailazite kada izvravate zadatke?
Koje poslovne politike vam pomau ili vas ometaju u obavljanju
svog posla?
Koja dokumenta ili pojedinci vam pruaju bitne informacije
neophodne za obavljanje vaeg posla?
Kako drugi korisnici ili sistemi, kao na primer spoljni vendori,
utiu na va posao?
Koja vrsta pomoi vam je neophodna dok radite na terenu?
Da li imate neke zahteve koji nisu dokumentovani?
Svrha intervjua je da se istrai, a ne da se ocenjuje i kritikuje. Koristite jasne i koncizne reenice. Nemojte davati vaa miljenja u
okviru pitanja. Izbegavajte duga i sloena pitanja. Trudite se da ne
postavljate pitanja koja iziskuju vie od jednog tipa informacija.
Voenje intervjua se sastoji od tri faze:
Otvaranje intervjua namera je da se motivie sagovornik
stvaranjem idealnog okruenja. U toku stvaranja okruenja od
obostranog poverenja i potovanja, intervjuista treba da ukae
na svrhu i duinu intervjua i da objasni kako e se prikupljeni
podaci dalje koristiti. Evo nekoliko naina kako bi mogao efektivno da se pone intervju:
1. Sumirajte oigledan problem i objasnite kako je problem
otkriven.
2. Ponudite odreenu stimulaciju za uestvovanje.
3. Pitajte za savet i pomo.
Telo intervjua ova faza oduzima najvie vremena. Intervjuista
mora paljivo da slua, posmatra i belei kako verbalne tako i
neverbalne odgovore. Poeljno je da se intervju snimi.
Zatvaranje intervjua zatvaranje je veoma vano za odravanje
121
dobrih odnosa i poverenja sa intervjuisanom osobom. Intervjuista treba na kraju da izrazi zahvalnost i odgovori na eventualna pitanja.
Primer voenja intervjua je prikazan u tabeli 5.1. Jedini nedostatak
kod intervjua je ukoliko se intervjuie osoba koja nije ekspert iz
domena koji se prouava, jer se tada dobija subjektivno vienje
posla i problema.
Tabela 5.1. Primer voenja intervjua
122
Fokus grupe koristi tehnike grupnog intervjuisanja. Intervju se

radi sa veom grupom kako bi se dobila preiena informacija,
otkrila ponaanja i deljena miljenja. Da bi se prikupile korisne
informacije, neophodno je da uesnici fokus grupe predstavljaju
korisnike posmatranog poslovanja. Fokus grupe obezbeuju najkorisnije informacije kada se uesnici oseaju ugodno da dele
svoja iskustva i diskutuju njihove razliite poglede na poslovanje.
Intervjuista treba da obrati panju da odrava fokusiranost grupe
na temu intervjua.
Istraivanje podrazumeva prikupljanje detaljnih i statistikih podataka. Informacije koje se mogu prikupiti tehnikom istraivanja
su:
organizacione strukture, politike i prakse koje olakavaju obavljanje zadataka
posebne potrebe za hardverom i softverom
frustracije sa tehnikom podrkom
efektivnost trenutnog programa obuavanja, tipove programa
koje korisnici vole i programe obuke koji daju najbolje rezultate
u korisnikom radnom okruenju.
povratne informacije od klijenata i dr.
Instrukcije korisnika ova tehnika podrazumeva da se prema
instrukcijama korisnika obavlja njegov posao. Krajnji korisnik vas
poduava kako oni rade sa sistemom. Ova tehnika vam omoguava
da tokom obavljanja aktivnosti sagledate svaki korak procesa iz
ugla korisnika. Takoe, moete nauiti ono to je korisnik nauio
vremenom, a to znanje se ne moe nai ni u kakvim dokumentima
niti u sistemu. Nedostatak ove tehnike je u tome to zahteva dodatno vreme korisnika, zatim se moe desiti da korisnik ne zna da
prenese svoje znanje ili da razliiti korisnici razliito obavljaju isti
zadatak. Informacije koje se mogu prikupiti ovom tehnikom su:
dizajn korisnikog interfejsa,
potrebe za obukom u trenutnom i buduem sistemu,
kriterijumi performansi sistema,
uticaj zikog okruenja na zadatak.
123
Prototipovanje podrazumeva prikupljanje informacija simuliranjem

predloenog sistema koji nije mogue testirati direktno. Pravi se
prototip koji se usavrava. U sluajevima kada je nemogue pratiti
osobu u normalnom radnom okruenju koristi se prikupljanje
podataka na prototipu. Na primer, korienje prototipa moe biti
veoma korisno kada se prikupljaju informacije o softveru koji je
napravljen za medicinske analize. U nekim sluajevima trokovi
pravljenja prototipa mogu biti vrlo visoki. Informacije koje se mogu
dobiti ovom tehnikom su:
zahtevi klijenta za kvalitetom
vreme odgovora na zahteve i ciljeve korisnika
lakoa korienja
integracija tehnologija i aplikacija
funkcionalnosti kod korisnikog interfejsa koje bi korisnik eleo
da doda na aplikaciju.
vrednovanje workow procesa.
Instrumenti (Instrumented versions) kod ove tehnike se koriste
metode praenja koje se ugrauju u aplikaciju kako bi se snimilo
kako korisnik izvrava zadatke. Ova tehnika vam omoguava da
odgovorite na sledea pitanja:
Koliko esto se koristi odreena funkcionalnost?
Koliko vremena je potrebno da bi se uradio zadatak?
Koje funkcionalnosti se najee koriste da bi se zadatak obavio?
Koje funkcionalnosti se ne koriste?
Koje teme Help-a se najee koriste?
Informacije koje se mogu prikupiti ovom tehnikom mogu da ukau,
na primer, na odreene funkcionalnosti koje se uopte ne koriste,
a projektovane su da bi se ubrzao proces obavljanja zadatka.
124
5.2.2. Analiza poslovnih problema

Da bi se lake razumela priroda poslovnih problema, ovde se prikazuje
scenario jedne multinacionalne proizvodne kompanije koja proizvodi i
distribuira svoje proizvode na trita Evrope, Azije i Severne Amerike.
Kompanija zapoljava oko 500 ljudi. Pre dve godine kompanija je kupila
manji proizvodni pogon koji proizvodi nekoliko kritinih podkomponenti
za proizvodnu liniju kompanije. Ove komponente se transportuju na drugu
lokaciju gde se obavlja nalna montaa. Ve naredne godine ova fabrika
postaje jedini proizvoa i distributer odreene vrste proizvoda. Nakon
uspene skalne godine, kompanija eli da proiri trini udeo tako to
e fokusirati prodaju na najbolje klijente, proiriti dostupnost proizvoda
putem Web sajta i smanjiti trokove prodaje smanjivanjem proizvodnih
trokova.
Poslovni problemi se mogu kategorizovati prema razliitim odelenjima
unutar kompanije kao to su Prodaja, Ljudski resursi, Nabavka, Informacioni sistemi, Proizvodnja, Administracija i Inenjering.
Prodaja. Kompanija poseduje regionalne prodajne kancelarije na
teritoriji Australije, Kanade, Engleske, Francuske, Nemake i Amerike. U
svakoj regionalnoj kancelariji se nalaze reprezentanti prodaje i menaderi.
Reprezentanti koriste laptop kompjutere i handheld PC-jeve na kojima je
instaliran Microsoft Windows CE. Tipian radni dan jednog reprezentanta
prodaje zapoinje tako to prvo uitava sve tekue podatke vezane za zalihe, proizvode i promocione informacije. U toku dana, sve porudbine
od klijenata unosi u laptop ili handheld PC. Na kraju svakog radnog dana,
reprezentant planira sastanke za sledei dan ili nedelju, proverava sastanke
drugih reprezentanata radi mogue saradnje i aurira listu kontakata.
Reprezentant na kraju unosi aurirane informacije i proverava elektronsku
potu ili bilo koji drugi vid interne komunikacije sa glavnom ili regionalnim
kancelarijama. Za elektronsku potu kompanija koristi Micorsoft Outlook.
Prodajni tim je identikovao sledee zahteve koji bi im omoguili da bolje
rade svoj posao:
Segmentacija klijenata i prolisanje. Prodajni tim treba da izvue
vane informacije iz sirovih podataka koji se nalaze u raznim bazama podataka, kako bi mogao da odgovori na sledea pitanja:
Koji su rani znaci problema?
Koji su najbolji kupci kroz sve proizvodne linije? Prema kojim
kupcima prodajni tim treba da fokusira svoj trud kako bi izgradio
dugoroniju saradnju?
125
Koja su pitanja klijenata, kategorizovane prema demografskim

grupama (geografska lokacija, istorija prihoda itd.)?
Koje proizvode kupuju klijenti i u kom odnosu?
Aktivnosti prodaje:
Trenutna politika odobravanja popusta omoguava reprezentantima diskreciju da ponude popust do 15%. Menader prodaje
moe da povea njihove popuste i popuste klijenata do 20%.
Da bi se podrala aktivnost prodaje irom sveta, prodajnom
odeljenju je neophodna meunarodna podrka, to podrazumeva da informacije o proizvodima, datumima i cenama
budu na vie jezika i tipova valute.
Interna komunikacija. Svaki reprezentant mora da dobija podatke
o klijentima i prodaji. Svaki menader prodaje mora da prima relevantne podatke o klijentima, sastancima i detaljne informacije za
svakog reprezentanta prodaje u timu. Menader treba da dodeli
klijente reprezentantima prema njihovim odnosima sa klijentima
(obino se klijenti dodeljuju prema regionima).
Upravljanje prilikama. Reprezentantu prodaje je potreban metod
za skladitenje i pristup podacima o prodajnim prilikama, a kada
se generie prodaja, da prenese odreene ili sve informacije na
porudbinu bez potrebe za ponovnim unoenjem informacija.
Sistem za podrku odluivanju. Sistem za podrku odluivanju
treba da obezbedi sledee funkcionalnosti:
da omogui marketing i prodajnom osoblju da postavljaju upite
i koriste podatke klijenata za generisanje standardnih izvetaja;
da izvravaju kastomizirane upite; da dobiju informacije koje
se odnose na praenje promocije, prognoziranje prodaje i segmentacije klijenata; da pristupaju izvorima podataka i alatima
za nansijsku evaluaciju.
da predstave sve aktivnosti klijenata (kontakti, konverzacije,
transakcije) na jedan ujedinjen nain.
omogue marketing osoblju da iniciraju nove promocije i programe na multinacionalnoj osnovi. Trenutno, reprezentanti
ne znaju kako na najbolji nain da poveu ove programe sa
odreenim oblastima.
identikuju, analiziraju i dele sve aspekte odnosa sa klijentima.
126
Odeljenje za ljudske resurse. Menadment ove kompanije predvia

da e morati da zaposli jo 35% radnika tokom naredne skalne godine
kako bi se izalo u susret planiranom poveanju proizvodnje. Takoe,
menadment je odredio da im je neophodno jedno aplikativno reenje
koje e pratiti biograje zaposlenih i prijave kandidata i koje e poboljati
prognoziranje neophodnog broja zaposlenih. Odeljenje za ljudske resurse
zahteva sledee funkcionalnosti od reenja:
Upravljanje prijavama i biograjama. Sve prijave i biograje se
trenutno nalaze u dokumentima razliitih formata. Sistem treba
da obezbedi:
jedinstvenu formu i skladite za sve tipove fajlova;
pristup postojeim podacima zaposlenih sa mogunou povezivanja na njihove priloene biograje i prijave;
alate za konvertovanje svih tipova datoteka u dokumenta koja
se mogu interno deliti kroz odeljenja;
bezbednost odreenih polja u dokumentima, kao to su na
primer informacije o platama;
pretraivanje prijava i biograja po kljunoj rei ili frazi.
Analiza i planiranje. Odeljenje za ljudske resurse zahteva podrku
za izvravanje sledeih tipova analize:
analiza dobiti kroz meunarodni odnos valuta;
planiranje i procena neophodne radne snage;
prognoze i simulacije trokova plata.
Nabavka. Da bi proirila svoju infrastrukturu, kako bi podrala oekivani
rast, kompanija je kupila fabriku koja proizvodi nekoliko kritinih komponenti koje oni koriste u svojoj proizvodnoj liniji. Iako je fabrika odvojena
poslovna jedinica kompanije, neophodno je da se neke aplikacije i podaci
dele izmeu ove dve institucije. Poslovni problemi u odeljenju nabavke
su sledei:
Prenos podataka. Kompanija ne moe redovno da premeta i
prenosi podatke zbog toga to:
fabrika nema ureaje za visoko brzinski prenos podataka kako
bi se preneli podaci iz njihove lokalne baze podataka u Microsoft
SQL Server bazu podataka u centrali;
kompanija ima centralizovano okruenje; neophodno je da se
povea skalabilnost baze podataka proizvodnje prelaskom na
distribuirano okruenje;
127
podaci se ne prenose ureajima za bezbednu mrenu konekciju.

Administracija i podrka. Fabrika ima limitiranu podrku za
informacioni sistem. Odeljenja odravaju svoje radne stanice, a servere koji podravaju Oracle bazu podataka, nadgledaju i odravaju
dva administratora i menader za informacione sisteme. Fabrici
nedostaju mnogi standardizovani procesi koje kompanija koristi
u svom dnevom voenju posla.
Prodaja. Kompanija trenutno koristi nekoliko dobavljaa kako bi nabavila razliite komponente i sirovine za svoju proizvodnu liniju. Odeljenje
prodaje ima glavnog dobavljaa koji je zainteresovan da uspostavi elektronsku razmenu podataka (Electronic Data Interchange EDI) sa kompanijom
kako bi prenosili kritina dokumenta i podatke kao to su porudbine,
raune, plaanja i specikacije o proizvodima. Agenti prodaje i raunovoe
utroe vie od 50% svog vremena na rad sa glavnim dobavljaima. Nakon to
se EDI reenje u potpunosti implementira, menader prodajnog odeljenja
predvia da e doi do poveanja ekasnosti zaposlenih do 30%. Aplikacija
treba da obezbedi sledee funkcionalnosti:
mogunost da kompanija i dobavljai prenose i primaju mnotvo
podataka i tipova datoteka, ukljuujui i struktuirane i polustruktuirane podatke;
mogunost za dobavljae da direktno prenose podatke u Microsoft
SQL Server tabele nabavke;
Web zasnovani sistem koji e obezbediti pouzdane informacije
dobavljaima;
mogunost da se automatski detektuje kada dobavljai imaju
dolazee fajlove ili druge podatke.
Odeljenje za informacione sisteme. Kompanija je razvila svoj Internet sajt, gde klijenti mogu da pristupaju osnovnim informacijama o proizvodima, pronau najbliu prodavnicu i tampaju informacije. Oni ne mogu
da narue proizvod on-line ili da pregledaju status postojee porudbine.
Mogunost pretraivanja Web sajta prema informacijama o proizvodu
je ograniena pretragom proizvoda po kategorijama. Kako bi omoguili
dodatne funkcionalnosti njihov Internet sajt treba da ukljui sledee:
on-line porudbinu proizvoda za klijente;
on-line proveru statusa porudbine;
bolju pretragu informacija o proizvodima;
128
mogunosti pristupa odreenim tehnikim specikacijama

proizvoda;
mogunost da pregledaju informacije o proizvodima i cenama
u meunarodnim valutama.
Proizvodnja. Proizvodna linija kompanije se sastoji od devet proizvodnih
grupa. Svaki proizvod sadri jednu ili vie podkomponenti, u zavisnosti
od porudbine klijenta. Trenutno, proizvodnja prihvata specikacije od
Inenjering odeljenja i koristi ga za sastavljanje proizvoda. Putem Web
sajta, klijentima su na raspolaganju pojedine osnovne informacije o proizvodima. Meutim, klijenti nemaju pristup svim specikacijama proizvoda.
Specikacijama proizvoda ima pristup prodajno osoblje, putem internog
sajta. Neki od problema su:
Planiranje rasporeda i proizvodnje. Da bi se izbegla kanjenja u
proizvodnji, tim treba da:
lako pristupa proizvodnim podacima, kao to su radni nalozi,
nivo zaliha i dr.
omogui analizu podataka workow-a.
Praenje zaliha. Umesto runog praenja i auriranja sistema zaliha, kompanija eli da koristi skeniranje barkodova, koristei pri
tom handheld PC sa instaliranom aplikacijom za praenje zaliha.
Administracija. Administracija nema centralnu kontrolu nad funkcijama upravljanja bazom podataka. Kao posledica toga, svaka grupa baze
podataka razvija sopstvene prakse i procedure. Ovaj decentralizovani
pristup ne koristi resurse optimalno, te stoga osoblje za informacione
sisteme zahteva bolji nain praenja resursa kroz sve operativne sisteme.
Administracija treba da obezbedi sledee funkcionalnosti:
dostupnost servisa za podrku kljunim sistemima kompanije;
backup i sisteme oporavka za sve baze podataka;
praenje svih resursa putem svih operativnih sistema.
Inenjering. Odeljenje inenjeringa je odgovorno za projektovanje
glavnih komponenti za sve proizvode kompanije. Timu treba takav sistem
koji e im omoguiti upravljanje dokumentacijom. Neki od zahteva ovog
sistema su:
kolaborativno upravljanje sadrajem dokumenata. Odeljenju
treba jedan automatizovan sistem koji e im omoguiti da kontroliu
kako se crtei i specikacije pregledaju, odobravaju i alju u proizvodnju na korienje.
129
pristupanje i skladitenje viestruktih tipova fajlova. Odeljenje

zahteva konzistentan nain za skladitenje, pronalaenje, ispitivanje
i arhiviranje razliitih fajlova kao to su CAD crtei i XML specikacije proizvoda. Ovaj sistem mora da bude povezan sa podacima
koji se koriste za praenje razliitih verzija crtea i specikacija.
5.2.3. Analiza zahteva

Aplikacija je Web zasnovana i namenjena je klijentima i drugim poslovnim
jedinicama. Aplikacija treba da omogui i kandidatima da alju i auriraju svoje
prijave za posao.
Aplikacija mora da podri sledee poslovne zadatke:
mogunost slanja porudbine od strane klijenta;
mogunost brisanja i odbijanja porudbine;
mogunost modikacije postojee porudbine koja je ve obra-ena;
pregledanje postojeih porudbina;
mogunost kreiranja novih zapisa o klijentima;
mogunost da klijenti auriraju informacije o klijentima;
prosleivanje prijava za zapoljavanje na razmatranje;
auriranje i pregledanje prethodno podneene prijave;
bezbednost pristupa informacijama.
Internet Web sajt kompanije treba da podri sledee funkcionalnosti:
svaka strana na Web sajtu mora da prikae opciju za pretraivanje sa
odgovarajuim kontrolama za pretragu i navigacionim barom;
klijentu treba omoguiti pretragu proizvoda po unosu dela opisa proizvoda ili opsega cena;
Home strana mora da prikae proizvode koji se prodaju pod specijalnim
uslovima kao i odgovarajue slike i opise;
Web strana nazvana Grupe mora da prikae hijerarhijsku listu linkova
ka grupama modela proizvoda ili delovima proizvoda u strukturi
drveta (tree structure);
stranica Detalji proizvoda treba da prikae informacije o pojedinim
modelima proizvoda (naziv proizvoda, opis, slike i opseg cena). Ukoliko
je model raspoloiv u vie veliina, boja i sl., tada se mora prikazati
drop-down lista, kako bi klijent mogao da bira veliinu ili boju;
130
stranica Tekua porudbina mora da prikae proizvode koje je klijent poruio, koliinu svakog proizvoda, jedininu i ukupnu cenu.
Klijentu se mora omoguiti da menja koliine ili ukloni artikle sa
strane. Dugme Nastavak kupovine mora da obezbedi povratak
na poslednju instancu poseene stranice o proizvodima;
strana Prijavljivanje klijenta mora da omogui, registrovanim klijentima, prijavljivanje unoenjem e-mail adrese i ifre, a novim
klijentima mogunost registrovanja;
strana Informacije o prijavi mora da omogui klijentima unos ili
izmenu e-mail adrese, ifre i drugih linih informacija;
strana Odravanje adrese treba da omogui klijentima kreiranje,
pregledanje, auriranje i brisanje adrese fakturisanja i isporuke;
strana Izbor adrese treba da omogui klijentima da biraju ili uklone
adresu isporuke i fakturisanja sa porudbine;
strana Pregled porudbine, treba da prikae porudbinu (da ukljui
i porez, trokove isporuke i detalje o popustima za preprodavce).
Kupcima treba se omogui menjanje koliine i uklanjanje artikala;
strana Priprema plaanja mora da omogui klijentima upotrebu
kreditnih kartica ili unos novih informacija o kreditnim karticama.
Preprodavcima da omogui biranje tipova plaanja;
strana Potvrda porudbine mora da omogui pregled podneene
porudbine (datum, broj potvrde, status porudbine i dr.);
strana Status porudbine prijavljenom klijentu prikazuje listu svih
uneenih porudbina. Odabirom na odgovarajuu porudbinu
klijentu se prikazuje status eljene porudbine;
strana Zaposlenje treba da omogui kandidatima podnoenje prijava.
131
5.3. Modelovanje sistemskih zahteva sluajevima

korienja
Jedan od primarnih izazova od vitalne vanosti za tim koji se bavi razvojem informacionih sistema, naroito sistem analitiare ili proizvodne
i program menadere, je sposobnost korektnog prikupljanja sistemskih
zahteva i njihovo opisivanje na nain koji e biti razumljiv korisnicima
kako bi ti zahtevi bili validni i verikovani. IT zajednica je oduvek imala
problem pokuavajui da odredi funkcionalne zahteve korisnika.
Industrija razvoja softvera je shvatila da bi uspeno planirala, analizirala,
projektovala, izgraivala i uvodila informacione sisteme, sistem analitiari
moraju prvo da razumeju potrebe korisnika i razloge zato sistem treba da
bude razvijen koncept nazvan korisniko orjentisan razvoj (user-centred
development). Fokusiranjem na korisnike sistema, analitiar se koncentrie
na to kako e se sistem koristiti, a ne na to kako e biti izgraen. Jedan od
naina da se struktuiraju analizirani zahtevi i problemi jeste da se nacrtaju
modeli. Modeli slue da se bolje razumeju sistemi i dokumentuju poslovni
zahtevi. Kao to slika vredi hiljadu rei, tako i veina modela predstavljaju
slikovite predstave stvarnosti.
5.3.1. Model sluajeva korienja

Sluajevi korienja opisuju funkcije sistema iz perspektive korisnika
na nain koji je njima razumljiv. Preko sluajeva korienja se opisuje niz
dogaaja koji se deavaju kada korisnik koristi sistem da bi dovrio proces.
Svaki sluaj korienja treba da se odnosi na jedinstveni merljivi zadatak
ili cilj. Sluajevi korienja se sastoje od elemenata koji se nalaze unutar
sistema i koji su odgovorni za funkcionalnost i ponaanje sistema.
Model sluajeva korienja pomae uesnicima na projektu da se sloe
oko granica i funkcionalnosti sistema. Veoma je vano da se prate zahtevani
zadaci od korisnika, rezultati tih zadataka i mogui izuzeci. Sluajevi
korienja opisuju uesnike (actor), objekte (objects) i akcije (actions) koji
dostiu ciljeve u sistemu.
Modelovanje sluajeva korienja ukljuuje:
narativne sluajeve korienja tekstualni opis poslovnih dogaaja
i naina kako e korisnici biti u interakciji sa sistemom kako bi
obavili zadatke. Primer iskaza sluajeva korienja se prikazuje na
slici 5.8.
132
Slika 5.8. Primer iskaza sluajeva korienja
dijagrame sluajeva korienja graki opisuju sistem preko

sluajeva korienja, uesnika (aktera) i njihovih veza. Uesnik
(akter) je korisnik koji je u interakciji sa sistemom. Akter moe
biti korisnik (ovek) ili neki drugi sistem. Treba napraviti razliku
izmeu korisnika i aktera. Korisnik je ovek koji koristi sistem,
dok je akter specina uloga koju korisnik ima u komunikaciji
sa sistemom. Relacije ili veze povezuju dva simbola na dijagramu
sluajeva korienja. Veze mogu biti:
asocijacije (associations) oznaava komunikaciju aktera sa
sluajevima korienja;
proirivanje (extends) usled kompleksne funkcionalnosti,
sluaj korienja se moe podeliti u nekoliko koraka kako bi se
pojednostavio i bio razumljiviji. Izvueni koraci se predstavljaju
kao posebni sluajevi korienja koji proiruju funkcionalnost
originalnog kompleksnog sluaja korienja. Relacija extend
se koristi da prikae opciono ponaanje, ponaanje koje se
pokree samo pod odreenim uslovima i nekoliko razliitih
tokova koji mogu biti pokrenuti na osnovu izbora aktera. Na
primer, sluaj korienja koji prati tok paketa na traci moe
se proiriti sluajem korienja Aktiviranje alarma ukoliko se
paketi zaglave.
ukljuivanje (includes, uses) kada dva ili vie sluajeva
korienja izvravaju korake od identine funkcionalnosti tada
je najbolje da se oni predstave jednim apstraktnim sluajem
korienja. Osnovni sluajevi korienja ukljuuju ponaanje
opisano sa apstraktnim sluajem korienja. Slui da bi se izbeglo viestruko opisivanje istog ponaanja. Na primer, svaki
133
sluaj korienja u sistemu univerziteta za registraciju kurseva

poinje sa proverom korisnika (user verication) koju zatim po
potrebi koriste drugi sluajevi korienja.
zavisne od (depends on) veoma je korisno znati koji su
sluajevi korienja zavisni od drugih, kako bi se odredio redosled razvoja sluajeva korienja. Na primer, sluaj korienja
Podizanje kredita nije mogue izvriti ako se prethodno nije
dogodio sluaj korienja Otvaranje rauna u banci.
nasleivanje (inheritance) kada dva ili vie aktera imaju
ista ponaanja tj. iniciraju iste sluajeve korienja, onda je
najbolje da se oni generalizuju u jednog apstraktnog aktera.
Na ovaj nain se smanjuje redundantnost komunikacije u
sistemu. Na primer, lan biblioteke moe da pretrauje bazu
knjiga, pregleda detalje knjige i izvri rezervaciju. S obzirom da
su biblioteke javne institucije, one omoguavaju i posetiocima
da koriste njihove usluge kao to je pretraga baze knjiga, ali im
se ne doputa korienje drugih usluga (npr., Pregled detalja
knjige). Kreiranjem apstraktnog aktera Klijent koga nasleuju
lanovi i posetioci, samo se jedanput modelira veza koja inicira
sluaj korienja Pretraga baze knjiga.
Dijagrami sluajeva korienja identikuju granice sistema, sekvencu
zadataka i hijerarhije. Na osnovu prethodno napisanih iskaza formira
se dijagram sluajeva korienja (Slika 5.9).
5.3.2. Modelovanje zahteva sluajevima korienja

Cilj kod modelovanja zahteva sluajevima korienja je da se izvuku
i analiziraju zahtevi tako da model komunicira sa onim to se zahteva iz
perspektive korisnika, ali da bude osloboen specinih detalja o tome
kako e sistem dalje da se razvija i implementira. Koraci kod modelovanja
zahteva sluajevima korienja su:
134
Slika 5.9. Primer dijagrama sluajeva korienja
Prvi korak je da se analiziranjem izvora informacija pronau zadaci. Na

primer, analiziranjem odlomka iz intervjua koji glasi: Da bi identikovali
nae najbolje kupce i razloge zbog ega su oni najbolji, prodajno osoblje
treba da pronae nain da pristupi i analizira naim podacima o prodaji.,
treba uoiti neophodne zadatke.
Drugi korak kod modelovanja je da se za svaki zadatak odrede uesnici,
akcije i objekti akcije (Slika 5.10).
Slika 5.10. Primer narativnih sluajeva korienja
Trei korak kod modelovanja je da se napravi dijagram sluajeva

korienja. Prethodno je potrebno identikovati sledee:
Sistem skup meusobno povezanih podsistema usmerenih
ka ostvarenju odreenog cilja. Prvo treba identikovati sistem
ili podsistem. Skup sluajeva korienja ukazuje na veze izmeu
podsistema koji ine jedan sistem.
135
Uesnike (aktere) ine integralan deo sluajeva korienja.

Sluajevi korienja predstavljaju veze izmeu uesnika i sistema.
Uesnik je entitet koji je u interakciji sa sistemom radi izvrenja
nekog dogaaja. Da bi identikovali uesnike, postavite sledea
pitanja:
Ko koristi, inicira i odrava sistem?
Koji drugi sistemi koriste sistem?
Ko dobija informacije iz sistema i ko obezbeuje informacije
sistemu?
Da li se neto deava automatski u unapred odreenom vremenu?
Ko ili ta inicira dogaaje sa sistemom?
Ko ili ta je u interakciji sa sistemom kako bi pomogao odzivu
na dogaaje?
Da li postoje odnosi izvetavanja?
Da li postoje bilo kakvi odnosi sa administrativnim sistemom?
Da li sistem mora da bude u interakciji sa nekim postojeim
sistemima?
Da li postoje neki drugi hardver ili softver koji su u interakciji
sa sistemom i koje bi trebalo modelovati tokom analize?
Interakcije izmeu uesnika i sistema nakon to ste identikovali uesnike i sistem, sledee je da se opiu interakcije izmeu
njih. Za svaku interakciju se pravi jedan sluaj korienja. Treba
opisati samo one interakcije koje su vane za poslovanje.
Granice sistema jedan od najteih aspekata modelovanja sluajeva
korienja je odreivanje tane granice sistema koji e se razvijati.
Da bi se denisale granice sistema, tim bi trebao da pokua da
odgovori na sledea pitanja:
ta se dogaa sa sluajevima korienja koji su pridrueni svim
uesnicima?
Ko ili ta je trenutno u interakciji sa tim sluajevima korienja?
Da li e novi zahtevi biti deo sistema?
Da li su ti zahtevi neophodni za ovaj sistem?
Da li su ti zahtevi neto to bi sistem logino radio?
136
Da li bi tim zahtevima moao da rukuje jedan uesnik?

Da li su ti zahtevi neto to korisnici oekuju da sistem radi?
etvrti korak je pisanje scenarija upotrebe (usage scenarios) koji
obezbeuju dodatne informacije o aktivnostima i sekvencama zadataka
koje ine jedan proces. Jedan sluaj korienja predstavlja skup sekvenci
dogaaja. Jedna sekvenca dogaaja se naziva scenario. Postoji osnovni
scenario i skup moguih izuzetaka i alternativnih funkcionisanja. Da bi se
dokumentovao jedan sluaj korienja potrebno je napisati vie scenarija
upotrebe. Formalan opis sluaja korienja je mogue dati i preko dijagrama kolaboracije i dijagrama promene stanja. Meutim, preporuuje se,
naroito u prvoj fazi, da se koristi struktuirani opis sluajeva korienja.
Scenarija upotrebe opisuju objekte i izuzetke. Objekat moe da bude
neto na ega sistem utie, neto to utie na sistem ili neto to je neophodno sistemu da bi pravilno funkcionisao. Izuzeci su netipine ili alternativne sekvence zadataka koje obezbeuju kompleten opis sluajeva
korienja. Na primer, izuzetak se moe dogoditi kada prilikom unosa
novog kupca u bazu, sistem padne, te agent prodaje mora da koristi druge
naine kako bi snimio informacije o kupcu.
Da bi se kreirao scenario upotrebe, neophodno je izvriti sledee zadatke:
utvrditi preduslove - odreivanjem informacija ili uslova koji
moraju biti ispunjeni da bi se scenario izvrio;
identikovati posledice - identikuju se posledice uspeno obavljene akcije;
razbiti aktivnosti na korake - raspored svih poslova odnosno
svakog pojedinanog posla, kako bi posao bio obavljen;
identikovati izuzetke izuzeci koji se mogu dogoditi na svakom
koraku. Moda e biti neophodno da se naprave scenarija upotrebe
za ove izuzetke;
identikovati zahteve na koje scenario ukazuje;
identikovati izvor za odreeni scenario radi dalje diskusije i
razjanjenja. Odrediti na koji se sluaj korienja odnosi.
Da bi ste uspeno upravljali izuzecima u sistemu, evo nekoliko saveta:
postavljajte ta-ako pitanja kako bi ste prikupili izuzetke za odreene
zadatke ili korake;
137
odredite, za sve izuzetke, relativnu verovatnou da se izuzetak dogodi;

diskutujte kako upravljati izuzecima i koje su alternativne metode;
ukljuite izuzetke sa visokom verovatnoom dogaaja u projekat
reenja.
Mogu se kreirati scenarija za trenutno i budue stanje poslovnog
okruenja. Scenario trenutnog stanja (current state usage scenarios)
opisuje kako se poslovne aktivnosti trenutno odvijaju odnosno kako trenutno proces izgleda. Scenario budueg stanja (future state scenario)
predstavlja eljene budue aktivnosti odnosno kako bi scenario trebao da
izgleda. Scenario trenutnog stanja vam pomae da:
idetikujete probleme u sistemu;
odredite ciljeve i
otkrijete nepodudarnosti izmeu percepcije trenutnog i stvarnog
problema.
Primer osnovnog scenarija za sluaj korienja Podizanje novca sa
bankomata bi izgledao:
Provera kartice: Komitent ubacuje karticu u automat. Automat ita
karticu i proverava da li je prihvatljiva. Ako je prihvatljiva, zahteva
se od komitenta da unese ifru.
Proveravanje ifre: Komitent unosi tajnu ifru i ukoliko je ispravna
zahteva se biranje eljene transakcije.
Unos tipa transakcije: Komitent bira transakciju Podizanje novca
i automat alje raunaru banke tajnu ifru da bi se dobili brojevi
komitentovih rauna.
Podizanje novca: Komitent bira raun i unosi iznos koji podie.
Automat alje raunaru banke zahtev za podizanje datog iznosa
sa datog rauna. Priprema se tampanje izvetaja za komintenta.
Kraj: Automat vraa karticu komitentu, traeni novac i izvetaj o
podizanju.
Alternativna scenarija kod sluaja korienja Podizanje novca bi bila:
Kartica nije prihvatljiva: Kartica se vraa korisniku sa zvunim
signalom.
138
Neispravna ifra: Na ekranu se prikazuje odgovarajua poruka i

korisniku se daje mogunost ponovnog unosa ifre. Dozvoljena
su tri pokuaja, a potom se kartica vraa korisniku.
Prekid: Korisnik moe u svakom trenutku da prekine transakciju.
Sve prethodne akcije e biti ponitene, a kartica e biti vraena
komitentu.
Pad sistema: Komitentu se prikazuje odgovarajua poruka.
Finalni izgled scenarija upotrebe na primeru sluaja korienja Upravljanje porudbinama bi izgledao kao na slici 5.11.
Peti korak je identikovanje zahteva korisnika. Zahtevi se mogu prikupiti analiziranjem intervjua, rezultata fokus grupa i drugih tehnika za
prikupljanje informacija. Treba uoiti da sluajevi korienja i scenarija
dokumentuju zahteve iz perspektive krajnjih korisnika ili objekata, a ne i
zahteve samog sistema. Tako prikupljeni zahtevi se moraju dalje modikovati kako bi reektovali zahteve sistema. U ovoj fazi se uglavnom opisuju,
organizuju i prema prioritetu sortiraju zahtevi i elje. Kasnije, u procesu
razvoja proizvoda, razvojni tim e odrediti jasne karakteristike proizvoda.
Koraci kod identikovanja zahteva su:
Kreirati listu zahteva tokom procesa prikupljanja informacija i
identikovati izvor odakle je zahtev doao.
Zahtevi moraju da budu kratke (ostvarljive) reenice.
Proiriti listu zahteva preispitivanjem svih prikupljenih informacija
i pronalaenjem novih zahteva.
139
Slika 5.11. Primer scenarija upotrebe
Zahteve podeliti od elja. Zahtevi ukazuju na karakteristike procesa

koji su osnovni za dostizanje ciljeva poslovanja. elje se zasnivaju
na iskustvu korisnika i predstavljaju idealno stanje posla. elje su
zahtevi koji mogu biti ukljueni ukoliko to dozvoljavaju vreme i
resursi. elje su vane, ali ne i neophodne za dostizanje poslovnih
ciljeva ili reavanja poslovnih problema. U toku diskusije sa korisnicima, neke elje mogu postati zahtevi, a neki zahtevi mogu
postati elje.
140
Prepoznati ogranienja i pretpostavke. Ogranienje je ksni limit.

Ukoliko se ogranienja neadekvatno identikuju, projektni tim
moe projektovati reenje koje ne moe biti uvedeno u poslovanje.
Primeri moguih ogranienja koje treba dokumentovati su:
limiti budeta;
karakteristike postojeih sistema;
arhitektura mree;
zahtevi bezbednosti;
operativni sistemi;
planirana poboljanja (upgrade) u tehnologijama;
odravanje i podrka;
irina prohodnosti mree;
nivo znanja razvojnog tima i tima podrke;
ogranienja uenja kod korisnika.
Treba razjasniti pretpostavke kako bi se zatitili od nesporazumevanja. Na primer: Novo reenje emo razvijati na Microsoft .NET
tehnologiji. Tim pretpostavlja da e razvijati reenje koristei
.NET.
identikovati skrivene zahteve - neki zahtevi nisu odmah vidljivi
(npr., zakonske regulative koje se menjaju).
esti korak je analiziranje informacija. Kada se prikupi dovoljno informacija, sledei korak je ltriranje i odreivanje onih informacija koje su
relevantne za poslovanje.
Pre nego to se krene u analizu prikupljenih informacija treba utvrditi
da postoji dovoljno informacija koje ukazuju na poslovne zahteve i zahteve
za reenjem, a koje ukljuuju:
potrebe sigurnosti;
podrku za reenjem i karakteristike;
planirane promene u poslovanju koje mogu da utiu na projektovano reenje;
performanse koje korisnici oekuju ili koje su neophodne da bi se
odrala konkurentnost;
integraciju aplikacija postojee aplikacije koje treba da se poveu
sa novim reenjem;
kako postojei poslovni procesi utiu na reenje.
141
Sedmi korak je dokumentovanje zahteva. Ve tokom prikupljanja informacija od korisnika, zapoeete beleenje liste potencijalnih zahteva. U
tom grubom, draft dokumentu e se nalaziti i zahtevi i elje koji e se u
toku narednih faza analizirati i iistiti. Mnoge elje e biti odloene do
naredne verzije.
Na primeru multinacionalne proizvodne kompanije koju smo ranije spomenuli, analiziraemo intervju koji je voen sa menaderom prodaje.
PREGLED INTERVJUA:
Imali smo dobru proteklu godinu. Poslovi su nam dosta olakani od
kada nam je kompanija nabavila laptop raunare i PDA. Ove godine smo
radili prognoze i uvideli smo blagi pad u prodaji, naroito ukoliko bi nastavili da radimo na nain koji smo radili do sada. Odeljenje prodaje je
postavilo brojne ciljeve za novu skalnu godinu. Najvaniji ciljevi su (a)
fokus na najbolje klijente (b) efektivnije korienje vremena prodajnog
osoblja i (c) bolje upravljanje prodajnim prilikama. Analiza podataka o
naim klijentima, nam je dosta oteana, jer se podaci trenutno nalaze
na razliitim sistemima i ne postoji laki nain prikupljanja podataka i
mogunost njihove analize i pregledanja iz razliitih uglova.
Drugi problem koji smo iskusili tokom proteklih meseci je predstavljanje
naih proizvoda i njihova prodaja na stranim tritima. Trenutno su sve
informacije, u naim raunarima, memorisane na engleskom jeziku. Neophodno je da se memoriu i viejezine i multiregionalne informacije o
proizvodima kako ne bismo zavisili od sposobnosti prevoenja prodajnog
osoblja. Na tim treba svakodnevno da dobija aurirane informacije o
cenama proizvoda. Trenutno se to radi tako to se agent prodaje, svakog
jutra, konektuje na mreu kompanije i download-uje novu listu cena.
Meutim, na toj listi nije naznaeno koje cene su modikovane i za kog
agenta prodaje one vai.
Druga oblast, koju treba poboljati, je upravljanje prodajnim prilikama.
Zaposleni bi trebalo da koriste na sistem za upravljanje klijentima kako bi
planirali, izvravali i pratili prodajne i marketing strategije. Agent prodaje
bi trebao da instalira veliku aplikaciju na svoj laptop i da se konektuje na
mreu kompanije da bi mogao da je koristi. eleli bismo da budemo mobilniji i da pristupamo tim informacijama preko Web sajta. Informacije
moraju biti validne, znaajne i pristupane kako agentima prodaje tako i
kompaniji, uopte.
142
Sa novim sistemom bi eleli da postignemo sledee ciljeve: da minimiziramo tehnika znanja potrebna za pristup podacima, dobijanje standardnih
izvetaja, generisanje upita, praenje promocija i pregledanje informacija
o segmentaciji klijenata. Sistem treba da bude eksibilan kako bi mogli da
dodajemo podatke sa spoljnih izvora i alate za nansijsku procenu. Bez
obzira ko gleda podatke o klijentima, taj pojedinac mora da ima jasan i
jedinstven pogled na kijenta i njihove odnose sa nama.
Sledea lista prikazuje preliminarni skup sluajeva korienja koji su
uoeni tokom intervjua. Na ovoj listi jo uvek nije izvrena analiza i validacija informacija.
Sluajevi korienja dobijeni sa intervjua:
Prodajno osoblje se bavi prognoziranjem prodaje.
Prodajno osoblje postavlja ciljeve prodaje.
Prodajno osoblje izvlai podatke o klijentima iz baze.
Prodajno osoblje pristupa, pregleda i analizira podatke.
Prodajno osoblje identikuje najbolje klijente.
Prodajno osoblje predstavlja proizvode na strana trita.
Prodajno osoblje skladiti viejezine i multiregionalne informacije.
Prodajno osoblje dobija dnevno informacije o cenama.
Agent prodaje se konektuje na mreu kompanije.
Agent prodaje download-uje novu listu cena.
Sistem identikuje modikovane cene.
Klijent pregovara sa agentima prodaje.
Zaposleni koriste sistem za upravljanje klijentima.
Zaposleni planiraju prodajne strategije.
Zaposleni planiraju, izvravaju i prate marketing strategiju.
Agenti prodaje pristupaju informacijama sa Web sajta.
Prodajno osoblje dobija standardne izvetaje.
Prodajno osoblje generie upite.
Prodajno osoblje prati promocije.
Prodajno osoblje gleda izvetaj o segmentaciji klijenta.
Prodajno osoblje dodaje podatke iz eksternih izvora.
Prodajno osoblje dodaje alate za nansijsku evaluaciju.
Prodajno osoblje procenjuje nansije klijenta.
143
Odgovarajui dijagram sluajeva korienja je prikazan na slici 5.12.

Sistem
uses
Prodajne prognoze
Postavljanje prodajnih ciljeva
Menader prodaje
extends
Upravljanje kontaktima
Upravljanje prilikama
Analiziranje klijenata
Direktor prodaje i marketinga
uses
uses
Upravljanje porudbinama
uses
Agent prodaje
Pregled kataloga proizvoda

extends
Sva odelenja
extends
Meunardoni katalog
Upravljanje proizvodima
Accounts Recievable
Klijent
Nabavka
Grupa inenjera
Radnik u proizvodnji
Plaanje rauna
Inenjering proizvoda extends
Redizajn proizvoda
extends
Spoljni uticaj
Dobavlja
Pregled dizajna proizvoda

Finansijski sistemi
Uvoznici
Slika 5.12. Dijagram sluajeva korienja izvuen iz intervjua [9]
Ovaj inicijalni dijagram sluajeva korienja predstavlja poetno

stanje odnosno prikazuje tekue stanje sistema. Revidirani dijagram
sluajeva korienja koji predstavlja procese onako kako bi trebalo da budu
reinenjeringom procesa u sistemu se prikazuje na slici 5.13.
144
Sistem
uses
Prodajne prognoze
Uspostavljanje prodajnih ciljeva
Menader prodaje
extends
Upravljanje kontaktima
Analiza klijenata
Upravljanje prilikama
Direktor prodaje i marketinga
uses
Upravljanje porudbinama
uses
Agent prodaje
Upravljanje proizvodima
extends
Klijent
Meunarodni katalog
Grupa inenjera
Sva odelenja
Radnik u proizvodnji
extends Redizajn proizvoda

Inenjering proizvoda
extends
Glavni zahtev koji

nova aplikacija
mora da ispuni je
da omogui
klijentima da
naprave
porudbinu na
Web sajtu.
Revidirani sluaj
korienja
ukljuuje interfejs
izmeu klijenta i
sluaja korienja
Upravljanje
porudbinama.
Primljeni rauni
Nabavka
Pregled dizajna proizvoda
Spoljni uticaj
Finansijski sistemi
Plaanje rauna
Uvoznici
Dobavlja
Slika 5.13. Revidiran dijagram sluajeva korienja dobijen reinenjeringom

procesa [9]
Deo draft dokumenta zahteva izvuenih iz intervjua i sluajeva korienja

je prikazan na slici 5.14.
145
Slika 5.14. Grubi (draft) dokument
U toku analize informacija, tim kreira i nekoliko internih dokumenata

i to:
katalog uesnika (aktera) sadri informacije o svim uesnicima
koji e se nalaziti na dijagramu sluajeva korienja. Katalog uesnika
sadri naziv uesnika, njegove odgovornosti i izvor ovih informacija.
Na primeru nae kompanije, agent prodaje je jedan uesnik ije su
odgovornosti da uspostavlja kontakte sa klijentima unutar regiona
i posedovanje znanja o proizvodima i njihovim specikacijama
kao i informacija o svim klijentima. Na slici 5.15 je prikazan jedan
primer kataloga uesnika.
Slika 5.15. Primer kataloga uesnika
katalog poslovnih pravila dokument koji lista sva poslovna

pravila reenja. Ovaj dokument prethodi dokumentu zahteva i
kreira se tokom faze prikupljanja informacija. Polja poslovnog
kataloga su: identikacioni broj poslovnog pravila, kratak naziv
poslovnog pravila, opis poslovnog pravila, ovlaeno lice, SK/PP
(sluaj korienja ili poslovno pravilo na koje se odnosi) i trenutnu
funkcionalnost.
146
Na primer poslovno pravilo koje se uoilo tokom voenja intervjua

i konverzacije sa menaderom prodaje je to da agent prodaje moe
da ponudi popust od 10% svojim klijentima. Dok, menader prodaje
moe da odobri popust od 20% svojim klijentima. Na slici 5.16 je
prikazan izgled kataloga poslovnih pravila.
Slika 5.16. Primer kataloga poslovnih pravila
renik tim e u toku projektovanja poslovnog reenja, uoiti

termine koje korisnici najee koriste. Renik sadri listu ovih
termina i njihova znaenja. Svrha renika je da svako koristi iste
termine i da razume njihovo znaenje.
5.4. Analiza izvodljivosti reenja i upravljanje rizicima

Informacija je glavna kapitalna investicija koja mora biti opravdana,
ba kao to marketing mora da opravda novi proizvod ili proizvodnja novi
proizvodni prostor ili opremu. Proizvodni menader treba da pomogne u
odgovorima na pitanja: Da li e investicija isplatiti samu sebe? Da li e se
pojaviti druge investicije koje e poveati trokove? Analiza izvodljivosti
treba da odgovori na ova i mnoga druga pitanja koja se javljaju u toku
razvoja reenja.
Izvodljivost (feasibility) je mera korisnosti i primenjivosti razvoja informacionog sistema u organizaciji. Analiza izvodljivosti (feasibility analysis)
je proces kojim se meri izvodljivost. Izvodljivost mora da se meri tokom
svih faza ivotnog ciklusa razvoja reenja. Prva analiza izvodljivosti se
sprovodi u toku faze denisanja vizije reenja.
5.4.1. Faza definisanja vizije

Uspeh projekta zavisi od sposobnosti lanova projektnog tima i korisnika
da dele jasnu viziju ciljeva projekta. U ovom delu e se razmatrati uloge i
odgovornosti lanova tima tokom denisanja vizije projekta prema MSF
procesnom modelu.
147
Faza denisanja vizije (Envisioning) je period tokom koga tim, korisnici i sponzori deniu prioritetne poslovne zahteve i sveukupne ciljeve
projekta. Glavna svrha ove faze jeste da se osigura zajednika vizija i da
se dostigne konsenzus izmeu lanova tima oko toga da je projekat vaan
za organizaciju i da se uspeno moe realizovati. Tokom ove faze, fokus je
na jasnoj deniciji problema. Tim sagledava kako poslovni problemi utiu
na poslovanje, korisnike i okruenje.
Razmotrimo sledei primer. Organizacija eli da se razvije Web sajt
kompanije. Treba nam Web sajt nije dobra vizija. Da bi se kreiralo efektivno reenje, tim treba da identikuje ciljeve koje organizacija eli da
postigne razvojem i uvoenjem Web sajta. Da li organizacija eli sloen
sajt ili sajt koji e da podri rastui broj korisnika? Tim treba da razmotri
ciljno trite, oekivani obim posete i brend organizacije na tritu.
U toku faze denisanja vizije tim:
identikuje ciljeve projekta i ogranienja (inicijalni rizici, zahtevi,
uska grla, budetska sredstva i dr.);
odgovara na pitanja o izvodljivosti projekta;
denie domen projekta (granice projekta, ta nije ukljueno u
projekat);
procenjuje neophodne resurse (broj ljudi, hardverske resurse i
dr.);
identikuje i utvruje vremenski raspored projekta i odreuje
nalnu taku zavretka projekta.
Iako, projektni tim zajedniki radi na uspostavljanju vizije i domena
projekta, svaka pojedinana uloga ima odreeni fokus u toku faza ivotnog
ciklusa projekta:
Proizvodni menadment - osigurava da se tim usredsredi na
zahteve klijenata. Analizira poslovne probleme, poslovne zahteve,
viziju projekta, poslovne ciljeve i uloge korisnika. Razmilja globalno, ne fokusira se samo na trenutne potrebe korisnika. Kreira
dokument Vizija/Domen (Vision/Scope).
Program menadment - uspostavlja ciljeve projektovanja, infrastrukturu projekta, denie faktore uspeha, jasno postavlja koncept
reenja i uloge korisnika.
Developeri - razmatraju i procenjuju tehniku izvodljivost reenja.
148
Testiranje oni koji vre testiranje izvetavaju tim o kvalitetu

ciljeva reenja i predlau akcije kako bi se osigurao kvalitet.
Menadment putanja reenja u rad - uloga sistem administratora koji identikuje zahteve za uvoenjem reenja, potrebnu
infrastrukturu i odreuje kako i kada e reenje biti uvedeno.
Iskustveni korisnik - analizira performanse reenja, neophodnu
podrku korisnicima i razmatra da li je reenje izalo u susret potrebama korisnika.
Tokom faze denisanja vizije reenja, vaan segment je i formiranje
tima. Veoma je vano da su lanovi tima kompetentni za obavljanje
neophodnih zadataka. Formiranje tima je vetina od koje jednim delom
zavisi uspenost projekta. Da bi identikovali lanove tima, neophodno
je razmotriti sledee:
Znanje informacije koje pojedinac mora da zna kako bi kompetentno obavio posao.
Vetine ponaanje ili sposobnosti koje ine kompetentnost, na
primer matematika logika.
Nivo performansi sposobnost ispunjavanja rokova i dostizanje
kvaliteta u zadatim rokovima.
Dokumenti koji se formiraju u toku faze denisanja vizije su:
Vizija/domen dokument (Vision/scope document) opisuje ciljeve
projekta i ogranienja (zahtevi koji e se ispuniti, funkcionalnosti
i inicijalni vremenski raspored).
Dokument strukture projekta (Project structure document)
prikazuje organizacionu strukturu projekta, proces upravljanja
projektom, odgovornost lanova tima i identikuje vou tima za
svaku rolu.
Dokument procene rizika (Risk assessment document) obezbeuje inicijalnu identikaciju, analizu rizika i upravljanje rizicima.
Projektni tim formira i interna dokumenta (prethodno objanjena):
katalog uesnika;
katalog poslovnih pravila;
149
renik termina;
kandidatne tehnologije (npr., SQL Server, Oracle, DB2 i dr.).
U zavisnosti od veliine projekta, moe se priloiti i sledee:
inicijalna lista testiranih funkcionalnosti;
preliminarni zahtevi i sluajevi korienja;
preliminarna arhitektura;
graki korisniki interfejsi.
Projektni tim se uglavnom oslanja na dokument vizija/domen kako bi
odluio da li dalje da nastavi sa projektom. Ukoliko se projekat odobri, tim
koristi dokument vizija/domen kako bi isplanirao dalji tok projekta.
Dokument vizija/domen (Vision/Scope V/S) sadri ciljeve i ogranienja poslovnog reenja. On predstavlja prvi zvanian dogovor izmeu
svih uesnika u projektu i vodi i usmerava tim ka dostizanju postavljenih
poslovnih ciljeva. Da bi se kreirao V/S dokument, tim prethodno mora da
vodi niz intervjua sa korisnicima, da analizira globalne sluajeve korienja
i na kraju identikuje pretpostavke i ogranienja. Treba napomenuti da se
proces prikupljanja i analize informacija odvija tokom svih faza razvoja
projekta. V/S dokument mora da se fokusira na denisanje i razumevanje
problema. Sadraj V/S dokumenta ukljuuje sledee:
Denisanje problema (Problem statement) - krai narativni
prikaz poslovnih oekivanja. Podvlai poslovne probleme koje tim
mora da rei. Razumevanje navedenih problema odreuje dizajn
reenja. to su problemi preciznije postavljeni, vea je mogunost
da se izmeri njihov uticaj na poslovne potrebe organizacije. Primeri
iskaza problema su: Treba da poveamo broj on-line registracija,
tako to emo napraviti Web sajt koji e biti lak za navigaciju ili
Korisnicima su potrebne jasne smernice iz sistema kako bi reavali
greke kada se pojave.
Viziju (Vision statement) - Kreirati koncizan, jasan i motivirajui
iskaz koji uspostavlja zajedniku viziju i omoguava timu da dostigne
konsenzus. Vizija mora biti kratke sadrine da bi se lake upamtila, mora biti jasna da bi se razumela i dovoljno jaka da bi bila
motivirajua za tim. Dobra vizija sadri sledeih pet SMART
karakteristika:
150
Specina (Specic) usredsreena na poslovni problem.

Vizija mora da bude specina i da ukljui idealno stanje poslovnog problema tako da krajnji rezultat bude znaajan.
Merljiva (Measurable) kreiranjem vizije koja je merljiva,
projektni tim moe da odredi uspenost projekta sagledavanjem
ispunjenosti poslovnih ciljeva.
Dostina (Achievable) sa datim resursima, vremenskim
okvirima i vetinama tima, vizija mora da bude dostina. Takva
vizija e motivisati lanove tima da zavre projekat.
Relevantna (Relevant) mora da bude usredsreena na
odreeni poslovni problem, ukoliko nije tako, onda projektni
tim moe da uvidi da pokuava da rei poslovni problem koji
uopte ne postoji.
Vremenski-zasnovana (Time-based) treba jasno da ukae
na oekivano vreme isporuke reenja.
Na primer: Do kraja godine, postaemo najproduktivnija proizvodna kompanija u industriji poveanjem naih on-line prodaja.
Korisniki proli (User proles) Veoma je vano shvatiti ko su
korisnici za koje se razvija reenje. Da bi se dobio jasan opis svakog
korisnika, tim kreira korisnike prole (user proles). Korisniki
proli identikuju korisnike tako da tim moe proceniti njihova
oekivanja, rizike, ciljeve i ogranienja na projektu. Kada se identikuju korisnici treba razmotriti sledee:
Ciljeve ukljuuje se lista stvari koje korisnik oekuje u toku
interakcije sa proizvodom.
Ogranienja koja utiu na sposobnost korisnika da koristi
reenje.
Podrka korisniki proli sadre informacije o problemima
koje korisnici mogu da imaju sa slinim proizvodima. Ove
informacije e pomoi u planiranju podrke koja e koristiti
korisniku tokom upotrebe novog proizvoda.
Globalni korisnici i geografske granice Odrediti da li e
reenje podrati i razliite kulture i potrebe lokalizacije.
Tok informacija izmeu korisnika Opisati komunikaciju
koja se dogaa izmeu korisnika, ukljuujui i tipove komunikacija, njihovu vanost i obim podataka.
151
Funkcije korisnika Opisati zadatke koje korisnik izvrava,

npr. unosi porudbinu klijenta i detalje o porudbini.
Organizaciona komunikacija neke organizacije imaju rigidnu hijerarhijsku podelu koja ograniava naine, razloge i kada
pojedinci komuniciraju kroz hijerarhijske nivoe. Dokumentovati
sastav i granice organizacione hijerarhije.
Politike donoenja odluka koje direktno utiu na efektivnu
implementaciju predloenog reenja.
Dodatni faktori Neophodno je dokumentovati i raspoloivost
i upotrebu resursa na korisnikim lokacijama i identikovati
bilo koje dodatne faktore kao to su nekompatibilni protokoli,
mreni operativni sistemi i dr.
Domen projekta (Scope of the project) Domen ili granice
sistema opisuju ta e biti, a ta nee biti ukljueno u projekat.
Granice sistema se odreuju na osnovu vizije projekta i obaveznih
funkcionalnosti koje reenje mora da ima. Vana aktivnost kod
odreivanja granice sistema je denisanje i preiavanje zahteva
koje budui projekta mora da ispuni. Primer preliminarnog zahteva
izvuenog iz intervjua sa korisnikom: Sistem mora da podri lokalizaciju kako bi odgovarala kulturama krajnjih korisnika.. Nakon
preiavanja ovog preliminarnog zahteva, u toku faze sagledavanja
vizije projekta, zahtev glasi: Sistem mora da ima procedure za
globalizaciju, lokalizaciju i dostupnost.. Usled ogranienih resursa,
vremena i drugih limitirajuih faktora mora se navesti koje funkcionalnosti e zadovoljiti trenutno reenje, a koje e se razvijati u
sledeoj verziji. Na odreivanje granica sistema takoe utiu i pretpostavke i ogranienja projekta. Na primer, korisnik iznosi sledee
pretpostavke: Koristiemo Microsoft .NET Framework za razvoj
reenja. Koristiemo dva razvojna tima. Imaemo i OLAP i OLTP
sisteme. Ove pretpostavke znatno utiu na ciljeve projektovanja
budueg reenja. Ogranienja su: budet, karakteristike ranijeg
sistema, mrena arhitektura, operativni sistemi, nivoi znanja korisnika. Granice sistema se obino oznaavaju na dijagramu sluajeva
korienja, kao to je prikazano na slici 5.12.
Koncept reenja (Solution concept) Nakon identikovanja
poslovnih problema i denisanja vizije i granice sistema, tim kreira
konceptno reenje koje opisuje kako tim namerava da realizuje
zahteve projekta. Fokus je na koncepte, a ne na detalje reenja.
152
Konceptno reenje ukljuuje konceptualni model arhitekture hardvera i softvera sistema. Na primer: u sluaju jednog Web sajta
koji treba da podri elektronsku trgovinu (e-commerce), treba
doneti odluku da li da se e-commerce sajt radi od samog poetka
ili da se angauje spoljna kua koja e razvijati reenje ili pak da se
nabavi gotovo komercijalno reenje. Slino, kod odluivanja gde
e se hostovati taj isti sajt, postavljaju se sledea pitanja: Da li da
se sajt hostuje na lokalnim serverima ili kompanija treba da koristi
usluge provajdera? Nakon to je tim procenio opcije, on se odluuje
za konceptno reenje koje najbolje odgovara njihovim potrebama,
resursima i vremenskim okvirima. Konceptno reenje ukljuuje
sledee elemente:
Faktore uspenosti projekta i kriterijume prihvatljivosti
ukljuuju zahteve koji moraju biti zadovoljeni pre nego to se
krene u realizaciju reenja.
Inicijalni pristup razvoju i isporuke reenja - ukljuuju
scenarije naina implementacije reenja, broj korisnika koji e
koristiti novo reenje i kompletnu listu faktora koji e omoguiti
da novo reenje bude funkiconalno.
Inicijalni opis funkcionalnosti reenja koje ukazuju na poslovni problem.
Na primeru proizvodne kompanije, na slici 5.17 se prikazuje proces
razvoja od koncept reenja do konceptualnog modela.
Browser
Analize
Klijent raunar
Proizvodi
Analize
OLTP pristup
OLAP pristup
Data Warehouse
Podaci
a) Primer koncept reenja

153
Porudbine klijenata i proizvodi

Microsoft Internet
Explorer
Pocket
Internet
Explorer
Analize
Klijent
Netscape
Navigator
UI komponente
Analiza UI
komponenata
UI komponente procesa
Analize UI
komponenata procesa
Katalog
Lista kontakata
Bezbednost
Operacioni menadment
Komunikacija
Microsoft Visual
Basic Scripting
Edition
Proizvodi
Klijenti
Agenti
prodaje
Porudbine
Prodajne
prognoze
Pristup podacima
OLTP pristup
Podaci
OLAP pristup
Data Warehouse
b) Primer konceptualnog modela

Slika 5.17. Primer razvoja od koncept reenja do konceptualnog modela
Ciljevi projekta - Da bi projekat bio uspean, neophodno je precizirati ciljeve projekta. Ciljevi projekta se mogu kategorizovati u:
poslovne ciljeve (business goals) ono to klijent eli da
postigne sa reenjem, analiza matrice kompromisa i postavljanje prioriteta. Na primer, za projekat e-commerce Web sajta,
poslovni ciljevi bi bili:
proiriti trite kompanije i tamo gde nema prodavnica.
skratiti vremena prodaje proizvoda ekasnijim korienjem on-line sajta.

integrisati sve dobavljae, skratiti vreme porudbine i isporuke.
ciljeve projektovanja (design goals) fokusiraju se na atribute
reenja i postavljaju se prioriteti meu ciljevima. Na primer, u
sluaju e-commerce sajta, ciljevi projektovanja bi bili:
smanjiti vreme uitavanja (download) strane;

154
smanjiti zavisnost od konekcije sa serverom;

smanjiti vreme i nivo napora koji je nophodan da bi korisnik popunio on-line registraciju.
Kritine faktore uspeha (Critical success factors)
Inicijalni raspored projekta (Initial schedule).
Nakon kreiranja preliminarnog ili draft V/S dokumenta, tim nanovo
pregleda i modikuje dokument. Zatim organizuje sastanak sa klijentima
kako bi se sporazumeli o sledeim pitanjima:
poslovne potrebe koje bi trebalo nalno reenje da ispuni;
vizija i domen reenja;
kompromisi koji su dogovoreni kako bi se denisale granice sistema;
ciljevi projektovanja reenja;
rizici kojima se mogu izloiti preduzimanjem projekta;
inicijalni koncept upravljanja projektom poslovnog reenja;
lanovi projektnog tima;
mehanizmi za upravljanje projektom.
Nakon usaglaavanja stavova po svim pitanjima, projektni tim zahteva
od korisnika da verikuju, a time i formalno odobre V/S dokument. Kraj
faze denisanja vizije je odobren dokument vizija/domen koji predstavlja
nalni dogovor izmeu projektnog tima i klijenta o sveukupnim smernicama projekta.
Drugi dokument koji treba da se dostavi program menaderu je dokument strukture projekta (project structure). Dokument strukture
projekta denie nain na koji e tim organizovati i upravljati projektom,
ukljuuje:
Uloge i odgovornosti tima i klijenata lista imena ljudi koji su
ukljueni u projekat i njihove kontakt informacije. Opisuje odluke prema odgovornostima razliitih uloga tokom narednih faza
projekta. Tokom faze planiranja, tim treba da odlui o sledeim
pitanjima:
Koji alati e se koristiti za razvoj i praenje planova projekta?
Kako e se funkcionalnosti rasporediti po razliitim verzijama
reenja?
155
Ko e identikovati rizike i denisati njihove izdatke?

Da li e tim organizovati sastanke tokom faze planiranja i ko
e im prisustvovati? i druga pitanja.
U toku faze razvoja reenja, tim treba da donese odluke o sledeim
pitanjima:
U toku rada na projektu sa kojim grupama, organizacijama ili
vendorima e tim biti u interakciji? Ko je odgovoran za ugovaranje sa spoljnim vendorima?
Koje su uloge i odgovornosti voe tima u toku razvoja reenja?
Ukoliko razliiti timovi razvijaju razliite komponente reenja,
koje su njihove pojedinane uloge i odgovornosti?
Da li e svaka komponenta biti dodeljena timu za podrku,
iskustvenim korisnicima i timu za testiranje?
Koja je uloga podugovaraa (subcontractor) na projektu? Ko e
birati podugovarae i pratiti njihov rad? i druga pitanja.
Komunikacione odluke prikazuje procese komunikacije unutar
tima i sa klijentima koji e se pratiti tokom projekta. Ukljuuju se
sledei odgovori na pitanja:
Koga treba izvetavati o odlukama planiranja?
Kako e se klijenti, korisnici i tim informisati o odlukama u
toku planiranja?
Koji tipovi sastanaka e se odravati, gde e se odravati i ko
e im prisustvovati?
Ko e praviti agendu sastanaka i distribuirati je?
Ko mora da bude informisan o napretku projekta i kako e se
informisati? i dr.
U toku projekta odravaju se fajlovi koji sadre informacije o ugovorima, rasporedima i planovima. Takoe, u okviru dokumenta
strukture projekta tim treba da odlui koje informacije e se uvati
u fajlovima projekta. Neke od odluka koje treba doneti, vezanih za
fajlove su:
Koje informacije e biti ukljuene u fajlove projekta, npr. specikacije projekta, rasporedi, planovi, ugovori i dr.?
156
Ko e kreirati i odravati fajlove projekta?

Ko e im pristupati?
Ko e odravati fajlove projekta, nakon zavretka projekta i
koliko dugo e se uvati? i dr.
Logistike odluke dokumentuju odluke vezane za razvoj reenja:
Koje metode razvoja e se koristiti, npr. metode testiranja, provera
nula defekata, specikacija proizvoda, marketing metode i dr?
Ko e denisati sadraj specikacije proizvoda i ko e je i kako
koristiti?
Koji alati e se koristiti za denisanje funkcionalnosti re-enja?
Ko e izvetavati tim o izmenama na specikaciji proizvoda?
Kako e se odrediti kriterijumi za zavretak specikacije proizvoda?
Koje specikacije e se dostavljati spoljnim vendorima koji rade
na projektu i ko e ih kreirati?
Kako e se denisati i implementirati metoda nula defekata na
projektu?
Kome je neophodna dodatna obuka, npr. kurs upravljanja projektima? i dr.
Odluke upravljanja promenama dokumentuju se procesi koje
tim treba da prati kako bi upravljao promenama na projektu. Odluke
koje treba da se dokumentuju su:
Kako e se denisati promene na projektu (na primer, promene
u rasporedu ili u poveanju trokova)?
Ko e i na koji nain odrediti datum putanja reenja u rad?
Ko e i kako identikovati i pratiti promene na projektu?
Kako e se meriti uticaj promena na projektu? Kolika je dozvoljena devijacija pre nego to doe do promene rasporeda? i
dr.
Odluke procene napretka dokumentuju se odgovori na sledea
pitanja, vezanih za praenje i procenu napretka projekta:
Kako e se oceniti napredak projekta? Koje informacije e se
koristiti za merenje napretka?
157
Kako i koliko esto e se prikupljati te informacije od lanova

tima?
Koliko esto e se aurirati grupni raspored projekta?
Ko e identikovati i oceniti uticaj svake promene?
Kako e se reavati problemi izmeu razliitih timova?
Da rezimiramo, komponente dokumenta strukture projekta su ukratko:
Tim i struktura;
Ocene projekta (Project estimates) - model trokova po fazama
(Slika 5.18);
Slika 5.18. Novana procena projekta
Dokument strukture projekta iji sadraj bi izgledao:

Svrha dokumenta (Purpose of document);
Raspored projekta (Schedule) prikaz odgovarajueg gantograma;
Model trokova (Cost model) prikazan na slici 5.18;
158
Tabelarni prikaz datuma kada se zavravaju dokumenta vizije/

domen, strukture projekta, glavni plan projekta, funkcionalna specikacija, raspored glavnog projekta, procena rizika,
aplikacija, obuka korisnika i prirunici za korisnike i tehnika
dokumentacija;
Struktura tima (Team structure) sadri tabelarni prikaz pregleda uloga u timu (uloga, opis, ime i prezime lana), tabelarni
prikaz odgovornosti svake pojedinane uloge (uloga, cilj, funkcionalne oblasti, odgovornosti) i tabelarni prikaz liste kontakata
(ime i prezime lana, uloga u timu, telefon i email);
Pristup upravljanju promenama (Change Management Approach) prikazuje odgovorne za proces kontrole promena
i dokumentacije, funkcionalnosti prema verzijama softvera i
njihove procene, matricu kompromisa i dr.
Ogranienja (Constraints) opisuje poslovna ogranienja,
ogranienja na projektu i tehnika ogranienja.
5.4.2. Analiza rizika

Jedan od bitnijih aspekata za razvoj uspenog reenja je upravljanje
rizicima koji ine sastavni deo svakog projekta. Dokument procene rizika
(Risk assessment document) je poslednji dokument u nizu koji treba da
se kreira tokom faze denisanja vizije projekta pre nego to se pree na
narednu fazu fazu planiranja.
Rizik je mogunost gubitka. Rizik moe biti i sve ono to umanjuje
kvalitet reenja, poveava trokove, premauje rokove ili ukazuje na pad
projekta. Osnovni aspekt razvoja uspenog reenja je da se kontroliu i
umanjuju rizici prisutni u projektu.
Upravljanje rizicima (Risk management) je proaktivan pristup kontrolisanja i umanjivanja rizika koji denie est koraka kroz koje tim upravlja tekuim rizicima, planira i izvrava strategije upravljanja rizicima
i dokumentuje iskustva i znanja za budue projekte. Veina pojedinaca
koncept rizka poistoveuje sa gubitkom vrednosti, kontrole, funkcionalnosti, kvaliteta ili neispunjenja vremenskog roka zavretka projekta,
meutim rizici podrazumevaju i neuspeh u dostizanju maksimalnih
mogunosti ili nesigunosti pri donoenju odluka to moe dovesti do
159
proputanja poslovnih prilika. Upravljanje rizicima je kontinualni proces

koji se odvija tokom svih faza projekta. Tim kontinualno procenjuje ta to
moe poi naopako i kako spreiti ili minimizirali svaki mogui gubitak.
Proces upravljanja rizicima prolazi kroz est logikih koraka, koji se ne
moraju hronoloki pratiti:
Identikovanje rizika Identikovati rizike i predoiti potencijalne probleme svim lanovima tima.
Analiza rizika i sortiranje prema prioritetu Pretvoriti informacije i podatke o potencijalnim rizicima u korisne informacije
za tim koje e oni dalje sortirati prema prioritetu reavanja problema.
Planiranje rizika i pravljenje rasporeda Informacije kreirane u
fazi analize rizika upotrebiti za formulisanje strategije umanjenja
rizika, planova i akcija. Rasporediti vremena za planiranje rizika
u projektnom planu.
Praenje rizika i izvetavanje Nadgledati status odreenog rizika
i progres njegovog plana za umanjenje. Izvestiti tim i korisnike o
tom napretku;
Kontrola rizika Izvriti plan umanjenja rizika i izvestiti tim i
korisnike o statusu rizika;
Uenje iz rizika Dokumentovati nauene lekcije iz projekta tako
da ih tim i korisnici mogu opet upotrebiti.
U toku faze denisanja vizije, tim upravlja rizicima tako to kreira
dokument procene rizika, identikuje i dokumentuje sve mogue rizike i
ocenjuje rizike prema verovatnoi pojave i uticaja na projekat. Dokument
procene rizika moe da sadri sledee delove (Tabela 5.19):
Iskazi o rizicima (Risk statements) opisuje prirodu svakog
rizika;
Verovatnoa rizika (Risk probability) opisuje verovatnou da
se rizik desi (na primer, u skali od 1 do 10);
Mera rizika (Risk severity) opisuje uticaj rizika na sistem;
Izloenost riziku (Risk exposure) odreuje sveukupnu pretnju rizika. Izraunava se mnoenjem verovatnoe i mere rizika:
Verovatnoa (p) * Uticaj (i) = Izloenost riziku (R);
160
Planovi umanjenja (Mitigation plans) opisuje planove

spreavanja ili umanjenja rizika;
Planovi kontigencije i trigeri (Contingency plans and triggers)
specira korake koji se preduzimaju kada se rizik dogodi i kada
treba preduzeti date korake;
Odgovorni za rizik (Risk ownership) naznaava imena lanova
tima koji su zadueni i odgovorni za praenje i uopte upravljanje
odreenim rizicima.
Program menader kreira dokument procene rizika. Pre nego to dokumentuje koncept reenja u okviru dokumenta vizija/domen, tim moe da
proceni rizike za svako konceptno reenje. Na primer, ukoliko je projekat
kreiranje ERP poslovnog reenja organizacije, onda se mogu razmotriti
razliite opcije. Jedna opcija bi bila da se reenje kreira od samog poetka,
to dovodi do angaovanja dodatnih resursa, poveanja vremena razvoja i
dr. Druga opcija bi bila nabavka gotovog reenja, odnosno njegovog izvornog koda i da se postepenom kastomizacijom, reenje prilagodi zahtevima
korisnika. Oigledno je da e druga opcija umanjiti rizike koji bi se pojavili
ukoliko bi se reenje razvijalo od samog poetka.
Nakon identikovanja svih moguih rizika koji se mogu pojaviti na
projektu, tim dalje procenjuje svaki rizik pojedinano, koristei sledeu
formulu:
R=p i
gde je:
R izloenost riziku
p verovatnoa da e se gubitak dogoditi;
i uticaj rizika na sistem.
Ovaj proces vam omoguava da poredite rizike i odredite njihove uticaje
i prioritete. Na primer, ukoliko koristite brojeve od 1 do 5 za oznaavanje
verovatnoe i uticaja za svaki rizik, gde 5 oznaava najveu, a 1 najniu
verovatnou i uticaj, tada se dobija faktor izloenosti rizika u rasponu od
1 do 25. Na ovaj nain se mogu uoiti najkritiniji rizici na koje bi tim
prvo trebao da se usredsredi. Na osnovu prethodnog prorauna, program
menader e napraviti listu od, na primer, 10 najkritinijih rizika, koju e
s vremena na vreme aurirati prema vanosti rizika (Slika 5.19).
161
Slika 5.19. Primer rangiranja rizika prema prioritetu
5.4.3. Kategorije izvodljivosti projekta

Generalno, postoje etiri kategorije izvodljivosti:
Operativna izvodljivost (Operational feasibility) meri se
prihvatljivost reenja u organizaciji. Posmatraju se dva aspekta:
Vredi li reavati problem? razmatra se efektivnost reenja
analizom PIECES okvira:
Performanse (Performance) npr. da li sistem obezbeuje adekvatno vreme odziva;

Informacije (Information) da li sistem prua korisnicima i menaderima pravovremene, vane, tane i korisne
informacije;
Ekonomija (Economy) da li sistem smanjuje trokove
poslovanja ili poveava prot;
Kontrola (Control) da li sistem obezbeuje adekvatnu
kontrolu protiv kraa i pronevere i da li garantuje tanost
162
i bezbednost podataka i informacija;

Ekasnost (Eciency) da li sistem maksimalno koristi
raspoloive resurse ukljuujui i ljude, vremena, minimalna zakanjenja i sl.;
Usluge (Services) da li sistem prua eljene i pouzdane
usluge onima kojima su potrebne i da li je sistem eksibilan i proirljiv.
Kakav je stav korisnika prema reenju? veoma je vano
meriti ne samo kako sistem radi ve i da li e biti prihvaen
u okruenju. Deava se da reenje ne uspe usled otpora koji
pruaju korisnici ili menadment. Treba razmotriti sledea
pitanja:
Da li menadment podrava sistem?
Kako se korisnici oseaju prema novoj ulozi u sistemu?
Prema emu korisnici pruaju otpor i da li se moe prevazii
i kako?
Kako e se promeniti radno okruenje korisnika? Da li se
korisnici mogu prilagoditi promenama?
Analiza izvodljivosti se uglavnom izvodi u ranim fazama ivotnog
ciklusa projekta. Najee se analizira na prototipu predloenog
sistema i to uglavnom testiranjem korisnikog interfejsa. Meri se
koliko korisnici lako mogu da naue, korste ili kako se podravaju
eljeni nivoi produktivnosti korisnika.
Tehnika izvodljivost (Technical feasibility) meri se primenjivost tehnikog reenja i raspoloivost tehnikih resursa i ekspertize. Danas je malo toga to je tehniki nemogue uraditi. Tehnika
izvodljivost razmatra sledee teme:
Procena moguih reenja i alternativa procena stanja na
tritu opreme, postojeih reenja u drugim organizacijama,
primenjivosti razliitih tehnologija i sl.;
Primenjivost reenja, tehnologije moe li se tehnologija
jednostavno primeniti. Pojedina okruenja zagovaraju upotrebu
najsavremenije tehnologije, dok je veina sklona zreloj i dokazanoj tehnologiji zbog sigurnosti i bolje podrke;
Raspoloivost tehnologije moe li se nabaviti i u kojoj meri
je treba prilagoditi ili doraditi;
163
Strunost postoji li neophodna strunost za primenu

odgovarajue tehnologije u organizaciji.
Izvodljivost rasporeda ili vremenska izvodljivost (Schedule
feasibility) procenjuje se da li e projekat biti zavren u dogovoreno vreme. Procenu vre svi uesnici u razvoju reenja, a naroito
developeri koji direktno rade na funkcionalnosti reenja. Proizvodni
menader e, nakon razgovora sa svim uesnicima i analize moguih
rizika, briljivo odrediti krajnji rok zavretka projekta. Bolje je
isporuiti ispravan sistem dva meseca kasnije, nego neispravan ili
beskoristan na vreme!
Ekonomska izvodljivost (Economic feasibility) je trokovnoefektivna analiza projekta koja odgovara na pitanje da li se isplati razvijati reenje. Trokovi podpadaju u dve kategorije. Postoje trokovi
koji se javljaju tokom razvoja reenja (trokovi razvoja sistema) i oni
koji se odnose na upotrebu reenja (operativni trokovi). Trokovi
razvoja informacionog sistema se mogu klasikovati prema fazama
u kojima se javljaju. Mnoge organizacije imaju standardne kategorije
trokova, kao na primer:
Trokovi osoblja ukljuuje plate sistem analitiara, programera, konsultanata, sekretarica i svih onih koji rade na projektu.
Njihove plate se mogu odrediti prema vremenu provedenog na
projektu;
Upotreba raunara trokovi vezanih za odravanje raunara,
testiranje, hostovanje i sl. Ukoliko raunski centar ili provajder
naplauju posebno svoje usluge;
Obuavanje ukoliko korisnici moraju da se obue, onda i
trokovi oko odravanju kurseva moraju da se uraunaju;
Trokovi opreme i nabavke;
Trokovi softvera (licence).
Operativni trokovi u toku ivotnog veka reenja se mogu klasikovati u ksne i varijabilne trokove. Fiksni trokovi su trokovi koji ostaju
nepromenjeni bez obzira na obim poslovanja. Na primer, plate i honorari
osoblja, licence softvera, trokovi nabavke i zakupljivanja hardvera, ureaja,
poslovnog prostora, obuavanje korisnika i sl. Varijabilni trokovi su trokovi
koji se menjaju srazmerno obimu poslovanja. Na primer, trokovi nabavke
DVD kaseta, papira za tampu, trokovi struje, telefona, odravanja i sl.
164
Popularne tehnike za ocenu ekonomske izvodljivosti su: analiza isplativosti, povratak investicija i neto sadanja vrednost.
Analiza isplativosti (Payback analysis) je jednostavan metod za
odreivanje da li e i kada investicija isplatiti samu sebe. S obzirom da se
trokovi razvoja deavaju mnogo pre nego to dobit pone da se ostvaruje,
treba saekati izvesno vreme da dobit pone da prevazilazi trokove.
Analiza isplativosti odreuje koliko vremena treba da proe da bi dobit
sustigla trokove. Taj period se naziva period isplativosti.
Na slici 5.20 je prikazana analiza izplativosti za projekat razvoja informacionog sistema iji trokovi razvoja iznose 418.040. Za narednih est
godina procenjeni su neto operativni trokovi i neto dobit. Da bi sagledali
period isplativosti, prvo treba prilagoditi trokove i dobit prema trenutnoj
vrednosti novca (u ovom primeru evra). Sadanja vrednost evra u godini
n e zavisiti od diskontne stope. Diskontna stopa je procentna vrednost
slina kamati koja se dobija na raun uteevine. U naem primeru, recimo
da je diskontna stopa 12%. Sadanja vrednost evra, za bilo koji naredni
period, izraunava se prema sledeoj formuli:
gde je:
PVn sadanja vrednost (present value) od 1 godinje
i diskontna stopa (discount rate)
Sadanja vrednost evra za dve godine e biti:
Da bi se izraunala sadanja vrednost trokova ili dobiti u drugoj godini,

treba samo pomnoiti sa 0.797. Na primer, procenjeni operativni trokovi
u drugoj godini su 16.000 * 0,797 odnosno 12.752. Nakon izraunavanja
svih diskontovanih trokova i koristi, analiza isplativosti je zavrena.
Ukoliko se pogledaju ukupne vrednosti, moe se uoiti da se trokovi,
tokom est godina, postepeno uveavaju, dok se dobit uveava mnogo
bre. S obzirom da e dobit prevazii trokove izmeu tree i etvrte godine, postavlja se pitanje da li je ulaganje u informacioni sistem dobra ili
loa investicija. Mnoge kompanije imaju odreeni period isplativosti za
165
sve investicije. Ukoliko pretpostavimo da sve investicije moraju da imaju

period isplativosti manje ili jednako etiri godine, onda je investicija u
naem primeru dobra.
Slika 5.20. Analiza isplativosti projekta
Povratak investicija (Return on investment ROI) je tehnika koja

poredi ivotni vek protabilnosti alternativnih reenja ili projekta. ROI za
reenje ili projekat je procentualna stopa koja meri odnos izmeu iznosa
koji posao dobija od investicije i investiranog iznosa. Krae, ROI je procenat relativnog iznosa koristi projekta. ivotni vek ROI za potencijalno
reenje ili projekat se izraunava prema sledeoj formuli:
ROI =
(Procenjena
ukupna dobit Procenjeni ukupni trokovi )

Procenjeni ukupni trokovi
Svi trokovi i dobit treba da budu diskontovani za period od est godina.

Kumulativni trokovi i dobit su prikazani u redovima 6 i 12 na slici 5.20.
Procenjena ukupna dobit manje procenjeni ukupni trokovi su jednaki:
795.440 - 488.692 = 306.748
Stoga, ROI iznosi:

ROI = 306.748/488.692=0,628 = 63%
Treba napomenuti da ovo nije godinji ROI ve ROI tokom ivotnog

veka reenja ili projekta. Ukoliko podelimo 63% sa 6 godina dobiemo da
166
prosean ROI iznosi 10,5% godinje. Ono reenje koje ima najvei ROI
je najbolja alternativa. Kao i kod analize isplativosti, kompanija moe da
postavi minimalni prihvatljivi ROI za sve investicije. Nizak ROI (manji od
10% godinje) moe pokazivati da je dobit preniska da bi bila isplativa.
Neto sadanja vrednost (Net present value) jedne investicije se smatra jednom od prioritetnijih tehnika analize trokova i dobiti. Kao i kod
prethodnih analiza i ovde se odreuju trokovi i dobit za svaku godinu
ivotnog veka sistema, koji su prethodno usklaeni prema trenutnoj
vrednosti evra. Na slici 5.21 se prikazuje tehnika neto sadanje vrednosti.
Trokovi su predstavljeni kao negativni tok novca (cash ow), dok je dobit
prikazana pozitivnim tokom novca. Diskontna stopa za nultu godinu je 1
jer je sadanja vrednost evra u nultoj godini tano 1. Nakon diskontovanja
svih trokova i dobiti, treba odbiti sumu diskontovanih trokova od sume
diskontovane dobiti da bi se odredila neto sadanja vrednost. Ukoliko je
pozitivna, investicija je dobra, a ukoliko je negativna, onda je loa. Kada se
poredi vie reenja ili projekata, onda onaj sa najveom pozitivnom neto
sadanjom vrednou predstavlja najbolju investiciju. Na naem primeru,
neto sadanja vrednost iznosi 306.748, to znai da ukoliko investiramo
306.748 sa 12% na est godina, imaemo isti prot kao i kad bi implementirali konkretno reenje IS.
Slika 5.21. Analiza neto sadanje vrednosti za jedan projekat
167
5.5. Kreiranje funkcionalne specifikacije poslovnog reenja

Funkcionalna specikacija je virtuelni repozitorijum projekta koji sadri
rezultate aktivnosti projektovanja dobijenih iz konceptnog, logikog i
zikog dizajna. Ti rezultati su uglavnom predstavljeni UML modelima
kao to su dijagrami sluajeva korienja, scenarija upotrebe i drugi razliiti
informacioni modeli. Funkcionalna specikacija je po prirodi virtuelna jer
je uglavnom u elektronskoj formi, skladitena u bazama podataka razliitih
alata. Meutim, ona moe biti i u papirnoj formi, u vidu tekstualnog dokumenta ili grake ili predstavljena kao prezentacija. Funkcionalna specikacija nije rezultat rada jedne osobe, ve nastaje zajednikim naporom
razliitih uloga u timu.
Funkcionalna specikacija opisuje domen trenutne verzije reenja
listajui funkcionalnosti koje e biti deo reenja. Iskljueni delovi e ostati u dokumentu vizija/domen kao potencijalne karakteristike budue
verzije reenja ili kao elje ili kao delovi koji e biti van granica sistema.
Funkcionalna specikacija se koristi radi evidentiranja doneenih odluka
i dogovora vezanih za funkcionalnosti reenja, njegovih interfejsa, ciljeva
i prioriteta. Komunikacija sa razvojnim timom se upravo odvija preko
funkcionalne specikacije. Tim za testiranje takoe koristi funkcionalnu
specikaciju kako bi kreirao planove testiranja.
Ne postoje konane take poetka i zavretka kreiranja funkcionalne
specikacije. Tokom faze planiranja, svaki od procesa projektovanja
konceptni, logiki i ziki doprinosi razliitim elementima funkcionalne
specikacije. Sa zavretkom svakog zadatka tokom faze planiranja, funkcionalna specikacija postaje sve kompletnija.
Neki od ciljeva funkcionalne specikacije su:
Konsolidovanje zajednikog shvatanja poslovnih i korisnikih
zahteva. Funkcionalnost reenja e zavisiti od poslovnih i korisnikih
zahteva. Kod veih i sloenijih projekata, broj i sloenost zahteva se
poveava. Funkcionalna specikacija pomae da se klijenti i projektni tim sloe oko zahteva koje budue reenje mora da ispuni;
Razlaganje problema i logiko modelovanje reenja. Za sloenije
probleme je veoma vano da tim jasno identikuje sve delove
problema. Takoe tim treba da razbije reenje na posebne, nedvosmislene delove. Funkcionalna specikacija pomae timu da
168
pojednostavi reenje na logike delove i da ih dokumentuje. Takoe,

pomae da tim izmeni dizajn reenja u ranim fazama razvoja, ime
se izbegavaju rizici i dodatni trokovi koji bi se pojavili u kasnijim
fazama projekta.
Obezbeuje strukturu za planiranje, pravljenje vremenskog
rasporeda i razvijanje reenja. Funkcionalna specikacija pomae
program menaderu u identikovanju timskih zadataka i kreiranju
procena trokova i budeta za itav projekat. Program menader
moe da oceni resurse i vremena projekta i da kreira projektne
planove i rasporede. Tim za testiranje koristi funkcionalnu specikaciju da bi kreirao test scenarije u ranim fazama ivotnog ciklusa
projekta. Menadment putanja reenja u rad koristi funkcionalnu
specikaciju za uvoenje i implementiranje reenja i za podrku
okruenja za razvoj i testiranje.
Slui kao ugovor izmeu tima i klijenta za ono to e biti
isporueno. U veini organizacija i na veini projekata, funkcionalna specikacija slui kao ugovor izmeu tima i klijenta, to je
pisani dokaz o tome ta e biti razvijeno i isporueno. Funkcionalna
specikacija moe posluiti i kao zakonski dokument.
Ponekad ogranienja kao to su budet i vreme mogu da odvrate tim
od pisanja ili korienja funkcionalne specikacije. Tim moe direktno da
ide na fazu razvoja bez pisanja funkcionalne specikacije, ali tada se rizici
projekta znatno poveavaju. Neki od rizika ukoliko se ne pie funkcionalna
specikacija su:
tim moe da razvije reenje koje upotpunosti ne ispunjava korisnike
zahteve;
tim ne moe biti potpuno siguran da je razvio eljeno reenje, jer
je u nemogunosti da jasno denie oekivanja klijenata;
tim nee imati dovoljno informacija o tome da li reenje zadovoljava
eljeni kvalitet;
projektni menader nee biti u mogunosti da tano proceni budet
i raspored projekta. Informacije unutar funkcionalne specikacije
pomau timu da proceni neophodne vetine za razvoj reenja.
Mogui elementi funkcionalne specikacije su prikazani na tabeli 5.2.
Svaki element moe da predstavlja poseban dokument (Tabela 5.2):
169
Pregled konceptnog dizajna ukljuuje informacije kao to

su pregled reenja i arhitektura reenja. Prikazuju se sluajevi
korienja, scenarija upotrebe i kontekstualni modeli.
Pregled logikog dizajna ukljuuje informacije kao to su korisnici, objekti i atributi. Prikazuju se modeli sekvence zadataka,
logiki modeli objekata i usluga, konceptni modeli predloenog
reenja, korisniki interfejsi, logiki model baze podataka i arhitektura sistema.
Pregled zikog dizajna ukljuuje informacije o aplikaciji i
infrastrukturi. Prikazuju se topologija distribuiranih komponenti,
pakovanje komponenti, smernice za korienje tehnologije, arhitektura infrastrukture i dizajn, opis korisnikih ekrana i ziki model
baze podataka.
Standardi i procesi ukljuuje informacije o standardima i procesima koje tim koristi za obavljanje razliitih zadataka na projektu. Ukljuuje i detaljne informacije o kvalitetu i performansama
reenja.
Tabela 5.2. Elementi funkcionalne specifikacije
5.5.1. Faza planiranja prema MSF-u

Tokom faze denisanja vizije, projektni tim je prikupio dovoljno informacija za poetak projekta. Verikovanjem dokumenta vizija/domen, tim
prelazi na fazu planiranja. Tokom ove faze se planira kako e reenje dalje
da se razvija i odreuju se neophodni resursi za njihov razvoj. U okviru
faze planiranja razvija se konceptni, logiki i ziki dizajn reenja. Ova
170
tri procesa nisu paralelna, ve e logiki dizajn zavisiti od konceptnog,

a ziki od logikog dizajna. Bilo koja promena na konceptnom reenju
uticae na logiki, a potom i na ziki dizajn.
U toku faze planiranja pravi se niz modela i dokumenata koji zajedno
ine funkcionalnu specikaciju reenja. Postoje brojne tehnike modelovanja
poslovnih procesa i kljunih aktivnosti u poslovanju. Svaka uloga (rola)
projektnog tima ima razliite odgovornosti tokom faze planiranja:
Proizvodni menadment vodi rauna da plan ispuni korisnike
zahteve. Ova uloga je zaduena za analizu zahteva i tekueg stanja
poslovanja, optimizovanje koncept reenja i kreiranje konceptnog
(idejnog) reenja.
Program menadment osigurava da tim ima sve neophodne
resurse za izvoenje projektnog plana. Ova rola je odgovorna za
sveukupni dizajn sa naglaskom na logiki dizajn i funkcionalnu
specikaciju. Program menader kreira projektne planove i vremenske rasporede i odgovoran je za zavretak faze planiranja.
Razvojni tim obezbeuje da plan bude tehniki izvodljiv. Developeri su odogovorni za kreiranje logikog i zikog dizajna reenja i
odreivanje vremena i resursa neophodnih za razvoj i stabilizaciju
reenja.
Testiranje odgovorni su za procenu da li se funkcionalnosti
reenja mogu tesitrati i ujedno obezbeuju plan i raspred za njihovo
testiranje.
Menadment putanja reenja u rad procenjuju da li se reenje
moe lako implementirati, upravljati i podravati. Ova rola planira
i pravi raspored uvoenja reenja.
Iskustveni korisnik osigurava da e korisnici moi da koriste
reenje. Ova rola je odgovorna za analiziranje korisnikih zahteva,
kreiranje strategije podrke performansi, lokalizaciju i ocenjivanje
upotrebljivosti reenja. Takoe, ocenjuju neophodno vreme i resurse
potrebnih za razvoj sistema za podrku korisnicima (prirunici,
obuka i dr.).
Faza planiranja se zavrava kada se odobri projektni plan. Kritine take
faze planiranja su:
Funkcionalna specikacija (Functional specication) denie
ta e se razvijati i kako i kada e reenje biti razvijeno.
171
Glavni projektni plan (Master project plan) kolekcija planova

koji ukazuju na zadatke koje tim treba da obavi kako bi dostigao
funkcionalnost opisanu u funkcionalnoj specikaciji.
Glavni raspored projekta (Master project schedule) odreuju se
vremenski okviri za glavni projektni plan. Ovaj dokument predstavlja prvi korak u odreivanju tanog datuma isporuke reenja.
Aurirani glavni dokument ocene rizika (Updated master risk
assessment document) dokument ocene rizika koji je razvijen u
toku faze denisanja vizije se ponovo pregleda i aurira po kritinim
takama.
5.5.2. Konceptni dizajn

Konceptni dizajn (idejni projekat) je proces prikupljanja, analiziranja
i postavljanja prioriteta na poslovne i korisnike poglede na probleme i
reenje. Kod konceptnog dizajna, projektni tim pokuava da shvati kontekst
problema, zabelei poslovne aktivnosti i odredi granice i meusobne veze
na projektu. U okviru konceptnog dizajna se modeliraju zahtevi i kreira
prezentacija reenja visokog nivoa. Konceptni dizajn poinje da se kreira
jo u toku pisanja dokumenta vizija/domen. Bez konceptnog dizajna, moe
se desiti da se kreira veliko reenje, ali na pogrenom problemu.
Konceptni dizajn je jedan iterativan proces koji sledi sledee korake:
Istraivanje identikuju se kljuni poslovni procesi i aktivnosti,
vrednuju, prerauju i proiruju zahtevi, sluajevi korienja i scenarija upotrebe, kreiranih tokom faze denisanja vizije.
Analiza dokumentuju se i modeliraju tokovi posla (workow),
sekvence zadataka i veze u okruenju.
Optimizacija optimizuje se konceptno reenje i vrednuje i testiraju poboljani poslovni procesi.
U toku istraivanja, veoma je vano da projektni tim razume razliku
izmeu razliitih kategorija zahteva: korisniki, sistemski, operacioni i
poslovni. U toku faze denisanja vizije, projektni tim je na bazi intervjua
identikovao grube zahteve (Tabela 5.3). U toku analize vri se preiavanje
tih zahteva (Tabela 5.4). Zahtevi moraju biti dobro denisani, koncizni,
organizovani u hijerarhiju povezanih zahteva, pisani poslovnim jezikom
da bi mogli biti testirani.
172
Tabela 5.3. Zahtevi izvueni iz faze definisanja vizije
Tabela 5.4. Redefinisani zahtevi
Tokom analize razmilja se i o mogunosti projektovanja elja korisnika.

Zadaci koji se izvravaju u toku analize su:
sintetizovanje informacija proces transformacije prikupljenih
podataka u znaajne informacije. Tim identikuje informacije o
tome ta su korisnici rekli i uradili, belee detaljne tokove zadataka
koje izvravaju korisnici, identikuju alate koji se koriste, izuzetke
i alternativne sekvence zadataka, modeluju veze izmeu poslovnih
procesa, poslovnih sistema i korisnika, modeluju trenutno okruenje
u kojem korisnici rade i eventualne promene koje se mogu desiti
u postojeem okruenju;
poboljavanje dijagrama sluajeva korienja sluajevi korienja koji su identikovani u toku faze denisanja vizije prikazuju
173
kljune sluajeve korienja u sistemu, deniu domen reenja

i obezbeuju osnovu za konceptno reenje. Poboljanje tih dijagrama podrazumeva kreiranje detaljnih sluajeva korienja i
odgovarajuih scenarija upotrebe za svaki pojedinaan dijagram.
Zatim, svaki dijagram sluajeva korienja i scenarija se uporeuju
sa intervjuom i ostalom dokumentacijom i na kraju verikuju sa
korisnicima.
selektovanje odgovarajue arhitekture aplikacije - cilj konceptnog dizajna je konceptni model reenja. Da bi mogli da kreiramo
konceptni model, neophodno je razumeti servise koje reenje mora
da obezbedi. Servisi se deniu kao jedinice aplikacione logike koje
ukljuuju metode za implementaciju operacija, funkcionisanje ili
transformisanje. Servisi su pridrueni akcijama i koriste se za implementaciju poslovnih pravila, rukovanje podacima i omoguavaju
akcije kao to su dodavanje, pregledanje, modikovanje podataka
i dr. Klijente ne zanima kako su servisi implementirani, ve da li
mogu da izvre eljenu akciju. Tipini servisi koje reenje obezbeuje
su:
korisniki servisi (user services) obezbeuju korisniki
interfejs u jednoj aplikaciji. Korisniki servisi jedne aplikacije
omoguavaju interakciju izmeu aplikacije i njegovih korisnika.
poslovni servisi (business services) obezbeuju da se poslovna pravila izvravaju prema tanoj odreenoj sekvenci.
Poslovni servisi kriju logiku implementacije poslovnih pravila i
transformiu podatke iz korisnikih servisa, poslovnih i servisa
podataka.
servisi podataka (data services) obezbeuju najmanje vidljiv
nivo detalja za rukovanje sa podacima. Servisi podataka se koriste da bi se implementirala poslovna ema nad uskladitenim
podacima koje koristi aplikacija.
sistemski servisi (system services) obezbeuju funkcionalnost
van poslovne logike. Opti sistemski servisi su backup servisi,
servisi za rukovanje sa grekama, bezbednosni servisi, servisi
za rad sa porukama.
174
Na tabeli 5.5. se prikazuju razliiti servisi na primeru jedne aplikacije

za obradu porudbine. Treba istai da se servisi klasikuju prema
funkcijama, a ne prema lokacijama.
Tabela 5.5. Servisi na primeru aplikacije za obradu porudbine
Servisi
Korisniki servisi
Poslovni servisi
Servisi podataka
Primeri
prikazivanje porudbine
prikazivanje rauna klijenta
prikazivanje informacija o proizvodu
popunjavanje porudbine
auriranje informacija na raunu klijenta
izvlaenje informacija o proizvodu
provera zaliha proizvoda
informacije porudbine
raun klijenta
informacije o proizvodu
Servisi su organizovani prema arhitekturi aplikacije. Arhitektura aplikacije se sastoji od denicija, pravila i relacija koje formira
struktura jedne aplikacije. Ona pokazuje kako je aplikacija struktuirana, ali ne i kako je implementirana. Fokusira se na reenje, a
ne na tehnologije koje e se koristiti za implementaciju reenja. Da
bi mogao da se razvije konceptualni model reenja, treba izabrati
aplikacioni model i kandidate aplikacione arhitekture koje e reenje
koristiti. Projektni tim bira arhitekturu zasnovanu na servisima
koje reenje mora da obezbedi i na korisnikim oekivanjima o
performansama tog reenja. Pretpostavke i ogranienja utiu na
izbor arhitekture reenja. Pretpostavke podrazumevaju, na primer,
operativni sistem koji se koristi u sistemu. Ogranienja mogu biti
raspoloivi budet, vreme, vetine i resursi neophodni da bi se
zavrio projekat. Arhitekture aplikacija koje se koriste su:
klijent/server arhitektura (client/server) - klijent zapoinje
sesiju sa serverom i kontrolie sesiju. Kada primi zahtev, server
izvrava zahtevanu operaciju i vraa rezultat klijentu. Ogranienje
ove arhitekture je velika zavisnost klijenta od servera.
slojevita arhitektura (layered) je proirena verzija klijent/
server arhitekture i sastavljena je od hijerarhijskih slojeva.
Razliiti servisi u aplikaciji su jasno pozicionirani na odreene
175
slojeve tako da servisi mogu meusobno da komuniciraju jedino

ukoliko se nalaze na susednim slojevima. Slojevi enkapsuliraju
servise i tite servise jedan od drugih obezbeujui jednostavni
set interfejsa za deljene resurse. Servisi prezentacije, poslovni i
servis podataka su razliiti slojevi u slojevitoj arhitekturi. Prednosti su poboljani sistem skalabilnosti i visoka bezbednost.
stateless arhitektura - je verzija klijent/server ili slojevite
arhitekture gde svaki klijentski zahtev sadri sve informacije
koje zahteva server kako bi razumeo i obradio zahtev. Nijedna
informacija se ne skladiti kod klijenta.
cache arhitektura - keing je drugi pristup u kojem aplikacija
obezbeuje nain za obradu klijentskog zahteva bez prosleivanja
(forward) tog zahteva drugim mainama. Da bi se implementirala ova arhitektura, treba identikovati ta se moe, a ta ne
keirati, takoe treba denisati i naine upravljanja vremenom
artikala u keu.
hibridna arhitektura (layered-client-cache-stateless-cacheserver) omoguava kreiranje eksibilne i skalabilne aplikacije.
kreiranje konceptnog modela reenja primer konceptnog
modela je prikazan na slici 5.22.
Slika 5.22. Primer konceptnog modela reenja [9]

176
Finalni korak konceptnog dizajna je optimizacija. Tokom optimizacije

poinje da se projektuje reenje. Projektovanje budueg stanja sistema
zapoinje tako to se ispituju scenarija koja odslikavaju trenutna stanja
sistema i eliminiu neekasnosti, uska grla i redundantnosti. Treba napomenuti da se reinenjering poslovnih procesa radi samo za one aktivnosti
koje se nalaze u okviru domena projekta. Koraci kod opisivanja budueg
stanja sistema su:
Denisanje vizije budueg stanja podrazumeva poboljanje
produktivnosti trenutnog stanja, razmatranje potreba u odnosu na
elje, uravnoteenje poslovnih i korisnikih zahteva i razmotranje
tehnike izvodljivosti reenja.
Redizajniranje trenutnih procesa - kako bi se optimalno podrale
kljune poslovne aktivnosti i procesi.
Optimizovati itav proces.
Integrisati procese gde je to mogue.
Eliminisati neekasnosti, uska grla i redundatnosti.
Razviti scenarija upotrebe budueg stanja koji odslikavaju redizajnirane procese.
Vrednovati scenarija budueg stanja sa korisnicima.
Ponoviti reinenjering procesa ukoliko je neophodno.
Redizajniranje reenja je mogue uraditi i iz perspektive korisnika.
Naime, mogu se uoiti mogunosti poboljanja kod workow aktivnosti,
neproduktivne poslovne politike, birokratije, proputenih komunikacija i
uloga koje ne dodaju vrednost poslovanju i ometaju sveukupnu ekasnost
poslovnih procesa. Treba imati na umu sledee:
identikovati neeljene aktivnosti, uska grla i nepotrebne korake
u procesu;
otkloniti redundantnost u trenutnom okruenju;
integrisati individualne funkcionalne informacione sisteme;
identikovati i otkloniti sav nepotreban paprini posao;
odrediti minimalni nivo performansi koji se mora dostii u procesu;
177
otkloniti vremena ekanja u sistemu identikovanjem koraka koji

se mogu simultano izvravati umesto sekvencionalno;
poboljati sistem tako to e se obezbediti ekasan feedback korisnicima, npr. o performansama kako bi se osigurali da su problemi
trenutno reeni.
Cilj kod reinenjeringa poslovnih aktivnosti je da se reenje projektuje
sa najmanje napora. Ne postoji jedinstven metod za ekasno redizajniranje
procesa. Tim moe da obavlja brainstorming sesije. esto problem ima
nekoliko alternativa njegovog reavanja. Tokom reinenjeringa treba
razmotriti sve elemente procesa inpute, autpute, nivoe performansi,
resurse, procedure kontrole, produktivnost i vreme. U toku optimizacije
procesa treba obratiti panju na sledee:
Uskladiti procese prema ciljevima performansi.
Dizajnirati procese oko proizvoda i usluga.
Zameniti hijerarhiju sa samo-organizovanim timovima koji paralelno
rade.
Poboljati produktivnost integracijom zadataka.
Odrediti gde se moe upotrebiti tehnologija koja e podrati redizajnirane procese.
Analizirati komponente procesa i dr.
Razmotrimo sledei primer. Ukoliko je u sistemu uoeno da magacioner popunjava optremnicu i prijemnicu koji su u trenutnom sistemu
predstavljeni kao dva posebna objekta, tada se uoava problem auriranja
kod dupliranih objekata. S obzirom da otpremnica i prijemnica imaju iste
atribute, primenom optimizacije, pravi se jedan objekat Dokument sa
dodatnim atributom na primer Tip=Ulazna/Izlazna.
U toku procesa optimizacije mogu se uoiti i novi sluajevi korienja
koje treba inkorporirati u konceptualni model. Takoe, u ovom koraku se
vri i procena trokova i koristi redizajniranog reenja. Mnogi projekti se
u ovoj fazi otkazuju usled toga to evaluacija ukazuje da ROI (Return On
Investment) novog reenja ne ispunjava poslovne kriterijume. Validacija
je neophodna jer umanjuje rizike, pomae u pronalaenju proputenih
informacija, usaglaava obostrane interese i predstavlja osnovu za dalje
logiko projektovanje reenja.
178
5.5.3. Logiki dizajn

Za razliku od konceptnog projekta koji opisuje reenje sa aspekta
poslovanja i korisnika, logiki projekat opisuje reenje sa aspekta projektnog tima. Dobar logiki dizajn e zavisiti od dobrog konceptnog
dizajna. Logiki dizajn se moe denisati kao proces opisivanja reenja u
terminima njegove organizacije, strukture i interakcije njegovih delova sa
aspekta projektnog tima. Kada se kreira logiki dizajn, tim uzima u obzir
sve poslovne, korisnike, sistemske i operacione zahteve koji identikuju
potrebe za bezbednou, praenjem, skalabilnou, rukovanjem grekama,
licenciranjem, globalizacijom, arhitekturom aplikacije i integracijom sa
drugim sistemima.
Da bi se razumela razlika izmeu konceptnog i logikog dizajna,
razmotriemo primer projektovanja kue. Tokom konceptnog dizajna,
klijent i arhitekta listaju zahteve klijenata, kao to su okruenje, spavanje,
neophodne ureaje i sl. Tokom logikog dizajna, arhitekta kreira podnu
podlogu, kompletno okruenje kue, vrata, prozore, sobe, krov itd.
Logiki dizajn nije tehniko reenje, ve samo odreuje poslovne
potrebe koje tehnologija mora da podri. Logiki dizajn je nezavisan od
zike implementacije. Primarni fokus je na identikovanju onoga to
reenje treba da radi. Projektni tim mora u potpunosti da razume reenje
pre nego to odabere tehnologiju za implementaciju reenja. Svakako da
tim moe da identikuje pretpostavke i ogranienja koji mogu da utiu na
izbor odreene tehnologije. Logiki dizajn ne sme da bude optimizovan
prema zikom modelu.
Prednosti projektovanja glavnog (logikog) projekta su:
Pomae timu da razume i upravlja kompleksnou projekta. Mnogi
projekti propadaju usled toga to su veoma sloeni i to nisu prethodno dobro isprojektovani.
Verikuje da dizajn reektuje poslovne probleme. Pomae timu
u otkrivanju greaka, nekonzistentnosti kod konceptnog dizajna,
eliminisanju redundantnosi u zahtevima i dr.
Olakava koordinaciju izmeu viestrukih sistema u organizaciji
i obezbeuje dosledan pogled na itav projekat.
Koristi se kao osnova zikog dizajna.
179
U toku logikog dizajna, svaki lan tima ima razliite odgovornosti:

Proizvodni menadment osigurava da dizajn bude u skladu sa
potrebama klijenata i poslovanja.
Program menadment denie projektni plan, to ukljuuje
resurse, rasporede i procenu rizika i odgovoran je za izlaznu dokumentaciju logikog dizajna.
Razvoj identikuje servise i pridruene objekte.
Testiranje vrednuje modele logikog dizajna u odnosu na konceptni i denie preliminarni plan testiranja.
Menadment putanja reenja u rad procenjuje izvodljivost
implementacije reenja, denie infrastrukturu i uvoenje reenja
u sistem.
Iskustveni korisnik denie korisnike ciljeve za performansama, preporuena reenja i derinie preliminarni plan za edukaciju
korisnika.
Faza logikog dizajna se moe podeliti u sledee zadatke:
Analiza logikog dizajna u okviru koga tim izvrava sledee zadatke:
Preureivanje liste kandidatnih tehnologija i alata;
Identikovanje poslovnih objekata i servisa;
Identikovanje vanih atributa i kljunih relacija.
Optimizacija logikog dizajna, u okviru koga tim izvrava sledee:
Poboljanje logikog dizajna;
Validaciju logikog dizajna.
ANALIZA KANDIDATNIH TEHNOLOGIJA

U toku analize, tim razbija problem na manje jedinice tzv. module. Za
svaki modul, tim identikuje objekte, servise, atribute, relacije i kandidatne
tehnologije. Tokom logikog dizajna, tim poboljava listu kandidatnih
tehnologija koje su prethodno identikovane u fazi konceptnog dizajna.
Kod ocene kandidatnih tehnologija tim uzima u obzir poslovna razmatranja, arhitekturu preduzea i tehnologiju. Neka od poslovnih razmatranja
su:
180
Izvodljivost da li e tehnologija da ispuni poslovne zahteve;

Proizvodni trokovi razumevanje kompletnih proizvodnih trokova,
koji ukljuuju trokove servera, licenciranja, upgrade-ovanja, developera, inicijalne trokove hardvera i softvera, podrke, infrastrukture,
obuavanja i dr.;
Iskustvo veliki uticaj mogu imati i korisnika iskustva u korienju
razliitih tehnologija;
Povratak investicija (return on investment - ROI) svaka investicija
mora da bude u skladu sa ROI. Ne treba birati tehnologiju samo
zbog toga to je nova. Svako investiranje u nove tehnologije treba
da obezbedi odgovarajuu vrednost poslovanju, kao na primer
poveanje prihoda ili smanjivanje trokova i dr.;
Zrelost Zreli proizvodi su prihvaeni na tritu zbog toga to su
dobro shvaeni, stabilni i to se raspolae sa resursima i znanjima;
Podrka u odabiru tehnologije, veoma je vano da postoji podrka
u toku razvoja reenja;
Legacy (naslee, ostavtina) problem - denie da IT reenja koja se
koriste u sistemu trae vie ulaganja od uvoenja novog IT reenja.
Odravanje vie kota nego sam razvoj novog reenja;
Lakoa uvoenja reenja u sistem;
Konkurentna prednost;
Sposobnost integracije sa postojeim sistemima i dr.
Projekat mora da bude u skladu sa ciljevima i principima opisanih arhitekturom preduzea. Arhitektura preduzea opisuje planove trenutnog i
budueg stanja. Na primer, ukoliko se planira upotreba Microsoft Windows Server 2003, onda i izbor tehnologija treba da bude u skladu sa ovim
planom. Reenje mora da se uklapa u ogranienja arhitekture preduzea.
Na primer, nova tehnologija kao to je streaming video moe da zahteva
poveanje prohodnosti mree. Takve promene ne zahtevaju samo novac
za kupovinu novih tehnologija, ve i vreme da se naui i implementira
ta tehnologija. Tehnologija mora da funkcionie i sa drugim sistemima
unutar organizacije.
Neke od tehnolokih razmatranja koje treba uzeti u obzir su:
Bezbednost proceniti bezbednost novog reenja razmatrajui autentikaciju, kontrolu pristupa, enkripciju i praenje. Autentikacija
181
odreuje da li je pojedinac onaj za koga se smatra, dok autorizacija

dozvoljava identikovanim pojedincima da izvravaju dozvoljene
akcije unutar sistema. Servisi bezbednosti takoe obezbeuju
enkripciju kako bi zatitili informacije u toku njihovog prenosa ili
skladitenja. Praenje kreira zapise akcija koje pojedinci izvravaju
ili nameravaju da izvre unutar sistema;
Standardi interakcije servisa razmatraju se standardi interakcije
i platformi. Na primer, Microsoft .NET Fremework pojednostavljuje razvoj aplikacija u distribuiranom okruenju. Pored toga to
obezbeuje viejezine integrisane funkcionalnosti, smanjuje probleme performansi i obezbeuje jednostavan model za interakciju
komponenti.
Pristup podacima kod odabira usluga pristupa podacima, treba razmotriti performanse, standardizaciju, budua usmerenja,
upravljanje pristupom podacima i razliita skladita podataka.
Skladitenje podataka sistemi za skladitenje podataka se koriste
za skladitenje svih poslovnih informacija tako da prvo treba razmotriti lokaciju skladitenja. Podaci se mogu skladititi na jednom
raunaru, serverima ili distribuiranim klijent raunarima. Lokacija
direktno utie na performanse aplikacije i nain njenog razvoja.
Sistemski servisi projektni tim procenjuje zahtevane sistemske
servise i identikuje tehnologije koje obezbeuju traene servise.
Primeri sistemskih servisa su:
transakcioni servisi - obezbeuju mehanizme i okvir (framework)
za transakcione aplikacije.
servisi asinhrone komunikacije aplikacija prijema garantuje
da je poruka stigla na udaljeni sistem.
servisi poruka rutiraju i isporuuju informacije.
Alati razvoja obezbeuju integrisana razvojna okruenja, kontrolu izvornog koda, wizard-e i biblioteke koda. Ovi alati znatno
smanjuju vreme potrebno za razvoj jedne aplikacije. Projektni tim
razmatra sledee faktore:
vetine developera - novi alati zahtevaju dodatnu obuku i vremena uenja i direktno utiu na raspored i resurse projekta.
angaovanje sa strane tzv. autsorsing (outsourcing) spoljnih
razvojnih timova.
182
izbor razliitih jezika za razliite zadatke na projektu na primer, .NET Framework programski model podrava razliite
programske jezike kako bi developer mogao da odabere one
koje zna ime se ubrzava produktivnost developera.
izbor razvojnih alata utie na odluke vezane za druge tehnologije
na primer, Microsoft ASP.NET obezbeuje platformu koja je
nezavisna od jezika za kreiranje Web aplikacija, ali sam ASP.
NET nije nezavisna platforma. Web aplikacije koje su izgraene
u ASP.NET-u moraju da se pokreu sa Windows operativnog
sistema.
Operativni sistemi servisi koji obezbeuju operativni sistemi
utiu na potrebe skalabilnosti, bezbednosti, kodiranja i sl. Izbor
operativnog sistema moe da zavisi i od odreenih tipova ureaja
kao to su na primer: Handheld PC, desktop raunari, serveri ili
specijalizovani ureaji namenjeni odreenoj industriji.
DOKUMENTOVANJE LOGIKOG DIZAJNA

Postoji nekoliko metoda za modelovanje relacija, a samim tim i dokumentovanje izlaznih dijagrama. Jedan od njih je dijagram sekvenci.
Dijagram sekvenci (Sequence diagram) prikazuje:
hronoloki ureene uesnike i objekte koji uestvuju u jednoj interakciji;
dogaaje koje uesnici i objekti generiu;
tok kontrole i sekvence ponaanja.
Vertikalna linija kod dijagrama sekvenci prikazuje ivotni vek objekta.
Strelice izmeu dva objekta predstavljaju poruke koje se prikazuju prema
redosledu njihovog deavanja. Dijagram sekvenci pomae da se jasno
sagledaju sekvence aktivnosti.
Dijagram na slici 5.23 opisuje scenario gde radnik dodaje nove specikacije postojeem proizvodu u katalogu. Prvi korak je da radnik pronae
postojei proizvod. Kada locira proizvod, onda dodaje nove specikacije
proizvodu. Pre nego to radnik doda nove informacije na Web sajt, inenjeri
moraju da provere informacije. Ukoliko tim inenjera odobri informaciju,
radnik se obavetava da je informacija o proizvodu dodata na Web sajt.
183
Radnik
Pretraga (Search)
Katalog
Proizvod
Inenjering
Otvaranje kataloga
Unosi proizvodID
Trai proizvod
Locira proizvod
Izvlai proizvod iz kataloga
Dobija informacije o proizvodu
Dodaje nove specifikacije zapisu proizvoda
Oznaava proizvod za "spreman za proveru"
Automatska notifikacija za proveru
Provera proizvoda
Oznaava proizvod kao "odobren"
Automatska notifikacija za odobrenje
Snimanje izmena
Slika 5.23. Dijagram sekvenci
Dijagram sekvenci prikazuje redosled poslova (sekvence zadataka),

reference na sluajeve korienja, uesnike (aktere), rezultate izvoenja,
izuzetke (alternative dogaanja) i dr. Na osnovu dijagrama se moe izvriti
optimizacija ukoliko se uoe sekvence zadataka koje se ponavljaju. Takoe
se na osnovu dijagrama mogu iscrtati i ekranske mape. Problem kod dijagrama sekvenci je taj to mora da se ide dovoljno duboko da bi se uvidela
sekvenca dogaaja.
U toku logikog dizajna, tim kreira izlaznu dokumentaciju:
logiki objektni model;
preliminarni dizajn korisnikog interfejsa;
logiki model podataka.
Logiki objektni model (Logical Object Model) se kreira na osnovu
prethodno denisanih objekata, servisa, atributa i relacija tokom procesa
logikog dizajna. U toku kreiranja modela, veoma je vano da se razmotre
svi poslovni i korisniki zahtevi za bezbednou, globalizacijom, lokalizacijom, praenjem i logovanjem, rukovanjem grekama, integracijom
sa postojeim sistemima i menadmentom stanja17 (state management).
1
184
Menadment stanja ukazuje na stanje kontrola korisnikog interfejsa (User Interface

Primer logikog objektnog modela je dat na slici 5.24.
Slika 5.24. Primer logikog objektnog modela
Logiki objektni model i logiki model podataka dokumentuju sline

informacije za razliite naine. Za veinu projekata, sasvim je dovoljno
dokumentovati jedan model.
Potrebe za podacima identikovane tokom konceptnog dizajna se u
okviru logikog dizajna pretvaraju u objekte i relacije. Prvi zadatak kod
kreiranja logikog modela podataka je da se identikuju entiteti (objekti),
atributi, relacije izmeu objekata i kardinalnosti. Logiki model podataka
na primeru porudbine je prikazan na slici 5.25.
UI) kao to su tekstualna polja, radio dugmii i dr. Stanje UI kontrola e zavisiti od
stanja drugih UI kontrola. Na primer, stanje UI kontrole dugme (button) e biti aktivno
ukoliko su validno uneene vrednosti polja ili e biti neaktivno ukoliko su uneene
pogrene vrednosti ili su polja prazna.
185
Slika 5.25. Primer logikog modela podataka
Lista objekata i servisa prua timu poetnu zamisao o funkcionalnosti koju korisnici oekuju. Na osnovu scenarija upotrebe tim projektuje
elemente korisnikog interfejsa kao to su dugmii (buttons), tekstualna
polja (text elds), meni (menu items) i sl.
Razmotrimo sledei primer scenarija upotrebe: Klijent selektuje katalog proizvoda. Na osnovu izabranog kataloga prikazuju se informacije o
kategoriji proizvoda i sami proizvodi. Klijent moe da bira proizvod kako
bi video detalje ili da bira kategoriju kako bi pregledao podkategorije i
njihove pridruene proizvode.
Na osnovu ovog scenarija, tim kreira sledei preliminarni UI dizajn:
Stranica Info o proizvodima prikazuje detaljan opis proizvoda,
cene, raspoloivost i dr.
Stranica Info o klijentima prikazuje informacije o registraciji
klijenta i neke line podatke.
Takoe, mogu biti ukljuene i stranice koje prikazuju informacije o
porudbini, o statusu porudbine, istoriju prethodnih transakcija itd.
186
OPTIMIZACIJA LOGIKOG DIZAJNA

Pravi izazov predstavlja optimizacija logikog dizajna prema postavljenim zahtevima i scenarijima upotrebe. Koraci optimizacije logikog
objektnog modela su:
Validacija modela prema zahtevima
Logiki model podataka je nekompletan ukoliko i jedan jedini
zahtev nije pokriven.
Verikacija objekata
Identikovati ulaze i izlaze jednog objekta i funkcionalnost koju
objekat mora da obezbedi.
Pravovremeno predvideti izlaze i ponaanja svakog ulaza.
Prolaenjem kroz scenarijo:
verikovati nezavisnost i sekvencu objekata i servisa voenjem
komplentnog scenarija;
oceniti frekventnost jedne aktivnosti. Koliko esto se ona dogaa
i da li se odvija periodino ili uniformno?
odrediti da li servisi koji kontroliu transakciju zavise i od servisa koji su deo drugih poslovnih objekata;
sagledati ona poslovna pravila koja podravaju vie poslovnih
objekata;
odrediti da li se zahteva sekvencionalni redosled operacija u
okviru cele ili dela transakcije;
identikovati kritina vremena. Da li se aktivnost moe obustaviti ili se mora odmah odgovoriti?
odrediti nezavisnost operacija kod poslovnih objekata.
5.5.4. Fiziki dizajn

Fiziki dizajn je poslednji korak kod faze planiranja prema MSF procesnom modelu. Nakon to se usaglase stavovi oko logikog dizajna tim
prelazi na fazu zikog dizajna. Tokom zikog dizajna se:
prikazuje kako e reenje biti implementirano;
identikuju odgovarajue tehnologije za razvoj reenja tim procenjuje tehnologije i odreuje koje tehnologije e se koristiti za
razvoj reenja;
187
transformie logiki u ziki dizajn;

obezbeuje osnova za fazu razvoja (developing phase) tim denie
uloge, odgovornosti i procese razvoja;
razvija specikacija komponenti i topologija uvoenja reenja;
denie da li su ispunjene i odobrene kritine take tim procenjuje
rizike, aurira prioritete i nalizira procenu resursa i rasporeda
projekta.
Da bi uoili razliku izmeu logikog i zikog dizajna, razmotrimo
analogiju za projektovanjem i izgradnjom kue. Kod logikog dizajna,
odreuju se zahtevi na primer za elektrinim kapacitetima, nivoima
svetlosti, ureajima za vodovod i sl. Kod zikog dizajna biraju se ureaji
koji e se koristiti i podrati prethodno denisane zahteve za strujom,
odgovarajuim kablovima i sl.
Fiziki dizajn opisuje komponente, servise i tehnologije reenja sa
aspekta developera (Slika 5.26). Fiziki dizajn ne podrazumeva kodiranje
reenja, ve omoguava da se kreiraju detaljne specikacije komponenti
za razvoj reenja kao i da se identikuju tehnologije koje se mogu koristiti
za razvoj reenja.
Slika 5.26. Od konceptnog do fizikog dizajna
Tokom zikog dizajna, svaka rola u timu ima razliite odgovornosti:

Proizvodni menader upravlja oekivanjima klijenta, kreira
komunikacioni plan i priprema reenje za uvoenje u okruenje;
Program menader upravlja procesom zikog dizajna, kreira
funkcionalnu specikaciju, denie projektni plan ukljuujui
resurse, rasporede i procenu rizika;
Razvoj pomae pri formiranju izlazne dokumentacije zikog
dizajna i to zikih modela, planova razvoja i rasporeda, procenjuje razvoj reenja, tehnologije, izgrauje prototipove i priprema
okruenje za razvoj;
188
Testiranje procenjuju i vrednuju funkcionalnosti i konzistentnost

zikog dizajna u odnosu na scenarije upotrebe, deniu detaljne
planove tesitranja i priprema okruenje za testiranje i kontrolu
kvaliteta;
Menadment putanja reenja procenjuje uticaj zikog dizajna
na infrastrukturu, denie reenja za uvoenje, dodatnu infrastrukturu i zahteve za operacijama;
Iskustveni korisnik ocenjuje ziki dizajn prema zahtevima
korisnika, dizajnira Help, denie plan obuavanja korisnika.
Na kraju zikog dizajna, projektni tim dostavlja timu za razvoj neophodnu dokumentaciju koja ukljuuje:
preliminarne korisnike interfejse sa pseudokodom;
dijagrame klasa;
modele komponenti, dijagrame sekvenci ili dijagrame aktivnosti
reenja;
emu baze podataka;
model uvoenja (deployment) koji prikazuje:
topologiju mree - ukazuje na lokacije hardvera i njihove
meusobne konekcije;
topologiju uvoenja - oznaava lokacije komponenata reenja,
servisa i skladita podataka u relaciji sa topologijom mree;
specikacije komponenti - ukljuuju internu strukturu komponenti
i interfejse komponenti;
strategije pakovanja i distribucije - identikuju servise koji se
pakuju u komponente i odreuje kako e komponente biti distribuirane preko topologije mree. Mogu da ukljue i preliminarni
plan uvoenja;
model programiranja - identikuje izbor implementacije, objekte
stanja, naine povezivanja, smernice za vienitno programiranje,
rukovanje grekama, izbor bezbednosti i dokumentovanje koda.
Fiziki dizajn se zavrava kada se odobri projektni plan. Fiziki dizajn
prolazi kroz etiri koraka:
1. Istraivanje na osnovu logikog dizajna projektni tim kreira
tehnika reenja tako to razmatra ogranienja kod poslovnih
189
procesa, infrastrukture i arhitekture preduzea, kao i zahteve za

bezbednou, skalabilnou, upravljivosti i raspoloivosti reenja.
Na primer, reenje treba da podri odreeni broj transakcija po
sekundi. U toku istraivanja identikuju se sva zika ogranienja
i zahtevi koji utiu na razvoj reenja. Izlazna dokumentacija faze
istraivanja su:
trenutna topologija mree;
trenutna topologija podataka;
trenutna topologija komponenti;
ziki zahtevi aplikacije;
aurirani planovi procene i umanjenja rizika.
Fiziki zahtevi se prikupljaju iz poslovnog okruenja i arhitekture
preduzea. Neki tipini ziki zahtevi su: performanse, trokovi i
koristi, lakoa korienja, podrivost, pouzdanost, ponovna upotrebljivost i dr. Neka tipina zika ogranienja su budet, raspored,
topologija mree, podataka, komonenti, bezbednost i sl.
U toku faze istraivanja razreavaju se i mogui konikti izmeu
zahteva i ogranienja. Na primer, aplikacija moe da zahteva 100
megabita po sekundi (Mbps) prohodnosti mree, dok postojea
infrastruktura mree moe da podri samo 10 Mbps.
Razreavanje konikta se odvija na sledei nain:
identikovati zahteve koji su apsolutno neophodni za projekat.
Analizirati uticaj na ogranienja i mogue kompromise.
identikovati oblasti infrastrutkure gde moe da doe do konikta;
analizirati razlike izmeu zahteva i ogranienja i odrediti da li
je potrebno doneti odluku.
sa svim uesnicima na projektu uraditi brainstorming reenja.
2. Analiza tim kreira i poboljava sledee modele zikog dizajna:
Dijagram klasa (Class diagrams) predstavljaju statiku
strukturu aplikacije.
Dijagram sekvenci (Sequence diagrams) predstavljaju interakcije izmeu objekata i dinamiki aspekt modela objekata.
190
Obino se koristi kako bi se razjasnile sloene relacije izmeu

klasa. Tim aurira klase, poboljava dijagram sekvenci tako
to ukljuuje relacije izmeu klasa ili servisa zasnovanih na
zikim ogranienjima ili tehnolokim zahtevima.
Dijagram aktivnosti (Activity diagrams) ukljuuje zahteve
za platformom i tehnologijom i identikuje potencijalne workow procese. Moe se koristiti dijagram aktivnosti umesto
dijagrama sekvenci i obrnuto.
Dijagram komponenti (Component diagrams) prikazuje
zavisnosti izmeu komponenti ili paketa komponenti. Projektni
tim kreira dijagram komponenti da bi jasno sagledao zavisnosti
izmeu komponenata i denisao dalje odluke vezane za pakovanje komponenti. Primer dijagrama komponenti za proces
poruivanja je prikazan na slici 5.27.
Slika 5.27. Primer dijagrama komponenti [9]
Preliminarni model uvoenja (Deployment model) Na osnovu arhitekture aplikacije, strukture tima, rasporeda projekta,
zahteva, dokumenta ocene rizika i kandidatnih tehnologija,
tim kreira preliminarni model uvoenja. Preliminarni model
ukljuuje topologije mree, podataka i komponenti koje predlae
projektni tim. Topologija mree je mapa infrastrukture koja
191
prikazuje radne stanice i servere, opisuje njihove funkcije i prikazuje infrastrukturu mree koja povezuje raunare. Topologija
komponenti i podataka je mapa koja ukazuje na lokacije
paketa, komponenti i njihovih servisa u relaciji sa topologijom mree i lokacijama baze podataka. Topologija uvoenja
prikazuje ziku distribuciju komponenti i njihovih lokacija
preko razliitih slojeva servisa. Primer topologije uvoenja je
prikazan na slici 5.28.
Slika 5.28. Primer topologije uvoenja [9]
3. Racionalizacija prikazuju se tano denisana reenja, odnosno

opisuju se tehnologije, strategije i topologije dizajnirane za konkretno reenje. Racionalizacija je jedan iterativni proces tokom koga
projektni tim pokuava da dizajnira jedno optimalno reenje.
Jedan od ciljeva racionalizacije je distribucija servisa i pakovanje
ovih servisa u komponente. Da bi se odredila odgovarajua strategija distribucije i pakovanja, neophodno je prethodno razmotriti
menadment stanja i performanse reenja.
Menadment stanja (state management) je proces u okviru koga
reenje odrava informacije o stanju i stranicama tokom viestrukih
zahteva za istom ili razliitim stranicama. Microsoft ASP.NET
podrava razliite opcije za upravljanje stanjem na klijent i server
192
strani. Poznato je da su Web Forms stranice stateless, odnosno ne

mogu automatski da ukazuju na to da li su svi sekvencni zahtevi od
istog klijenta ili da li pretraiva (browser) klijenta jo uvek aktivno
prikazuje stranicu ili sajt. Opcije menadmenta stanja na klijent
strani u jednom Web zasnovanom reenju su:
Svojstva stanja (ViewState property) Web Forms (obrasci)
stranice obezbeuju osobine stanja koje automatski pamte
vrednosti izmeu viestrukih zahteva za istom stranicom. Stanje
je sadrano u strukturi unutar koda stranice. Meutim, to se
vie vrednosti uva, poveava se korienje resursa servera,
bezbednost i implementacija, to dovodi do usporavanja odziva
i prikazivanja stranice.
Skrivena polja (Hidden elds) ukoliko se odluite da pamtite
odreene informacije o stranici u skrivenim poljima, tada morate
da aljete stranice serveru putem HTTP Post metoda. Najbolje
je da se skladite manje koliine frekventnih i promenljivih
podataka, na klijent strani.
Kolaii (Cookies) predstavljaju manje koliine esto menjanih informacija koji su uskladiteni na klijent fajl sistemu. Oni
umanjuju potranju za resursima servera. Kolaii se koriste za
autentikaciju, praenje i odravanje odreenih informacija o
korisnicima kao to su omiljeni sajtovi, sadraji njihovih elektronskih korpi za kupovinu i sl.
Stringovi upita (Query strings) predstavlja manju koliinu
informacija prikljuenih na kraj URL stranice. Obezbeuju
jednostavan metod za odravanje stanja. Mogu se koristiti samo
onda kada se zahteva stranica, nisu bezbedni i imaju limitirane
kapacitete.
Opcije za upravljanje stanjem na serverskoj strani u jednom Web
zasnovanom reenju su:
Stanje aplikacije (Application state) globalni mehanizam
za skladitenje kome mogu pristupati sve stranice jedne Web
aplikacije. ASP.NET obezbeuje klasu HttpApplicationState
za skladitenje vrednosti aplikacije koje e deliti sesije i koje
se nee esto menjati. Omoguava laku implementaciju i utie
na performanse.
193
Stanje sesije (Session state) slino je stanju aplikacija samo

to je limitirano trenutnom sesijom pretraivaa (browser).
ASP.NET klasa HttpSessionState uva vrednosti i objekte koji
e biti vidljivi samo toj sesiji. Ukoliko razliiti korisnici koriste
reenje, svaki korisnik e imati razliito stanje sesije. Ukoliko
korisnik napusti reenje i vrati se kasnije, imae razliito stanje
sesije.
Baza podataka (Database) uvanje stanja u bazama podataka.
Ova tehnika se koristi kod veine Web sajtova za elektronsku
trgovinu kojima su bitni bezbednost, personalizacija, konzistentnost i data mining.
Kod projektovanja, projektni tim razmatra:
Skalabilnost sposobnost brzog i lakog proirivanja reenja
kako bi podrao veliki broj korisnika i transakcija;
Performanse vreme odziva sistema i brzina izvravanja
zadataka aplikacije;
Upravljivost lakoa upravljanja sistemom na svim nivoima;
Upotrebljivost lakoa ponovne upotrebljivosti komponenti
od strane drugih aplikacija;
Granularnost odnosi se na broj servisa grupisanih u jedan
objekat i na veliinu i broj objekata grupisanih u jednu komponentu.
Jedna od karakteristika dobrog plana komponenti je visoka kohezija i slabo sprezanje. Kohezija (Cohesion) je veza izmeu razliitih
internih elemenata komponente. Komponenta ima visoku koheziju
kada su joj servisi usko povezani. Sprezanje (Coupling) je odnos
komponente prema drugim komponentama. Kada komponenta
ima slabu spregu sa ostalim komponentama, to znai da moe da
obavlja svoje funkcije nezavisno od drugih komponenti.
Prvi korak kod racionalizacije zikog dizajna je pakovanje servisa
u slojeve: korisnike, poslovne i slojeve podataka. Da bi zapoeli
proces distribucije, treba prvo identikovati glavne kategorije
servisa kod zikog modela objekta, a zatim ih razbiti na njihove
individualne slojeve servisa. Za svaki poslovni objekat, treba grupi194
sati servise u tri sloja: sloj servisa korisnika, sloj servisa poslovanja
i sloj servisa podataka. Nakon pakovanja servisa u komponente
treba distribuirati komponente preko mree i kreirati topologiju
komponenti.
Za svaki vor u topologiji mree, tim treba da identikuje kategorije servisa korisnik, poslovanje i podaci. Treba odluiti koje
korisnike servise treba distribuirati na Web servere, a koje na
klijent raunare. Poslovne servise treba distribuirati na servere
aplikacije ili Web servere. Servise podataka treba distribuirati
na servere baze podataka, odnosno prema lokacijama podataka
naznaenih na topologiji podataka.
Slika 5.29. Primer dijagrama komponenti [9]
Model uvoenja (deployment model) je dijagram koji pridruuje

aplikacije i njihove servise na topologiji servera (Slika 5.30). Svrha
modela je da omogui razvojnom timu i timu putanja reenja u
rad da projektuju i planiraju topologiju servera i njihovu konguraciju. Model koristi topologiju mree kako bi se prikazalo na kom
serveru e se nalaziti servisi aplikacija.
195
Slika 5.30. Model uvoenja [9]
4. Implementacija tim odreuje model programiranja koji e

razvojni tim koristiti, interfejse za svaku komponentu i internu
strukturu svake komponente. Model programiranja opisuje kako
e komponente biti struktuirane i kako e razvojni tim koristiti
odabrane tehnologije. Model programiranja razmatra tehnologije
implementacije, koheziju i sprezanje, konekcije, vienitni model,
rukovanje grekama, bezbednost, distribuciju i dr. Nakon opisivanja
modela programiranja, projektni tim opisuje kako e komponente
biti u vezi. Ova interakcija je dokumentovana interfejsima komponenti, koji opisuju naine pristupa servisima i atributima. Sloj
prezentacije obezbeuje mehanizme komunikacije izmeu korisnika
i slojeva servisa. Postoje dva tipa korisnika i to raunarski sistemi
i korisnici. Raunarski sistemi ne zahtevaju korisnike interfejse,
ve posrednika preko koga e biti u interakciji. Obino su to XML
Web servisi koji olakavaju komunikaciju izmeu dva sloja. Tokom
ovog koraka, razvojni tim mora da razmotri i sledee:
zika ogranienja baze podataka, kao to su memorija ili
veliina diska;
performanse, detekcija deadlock-a, indeksiranje i sl.;
primarne i spoljne kljueve;
dizajn trigera;
migraciju podataka iz prethodnih sistema baza podataka i dr.
Kada se informacioni sistem razvija od samog poetka tzv. razvoj u kui
(in-house) tada su zadaci projektovanja sistema sledei:
196
Projektovanje arhitekture aplikacija deniu se tehnologije

koje e informacioni sistem koristiti. Projektovanje arhitekture
aplikacija razmatra mrenu tehnologiju i naine kako e se podaci,
procesi i interfejsi distribuirati prema poslovnim lokacijama. Ovom
zadatku prethodi analiziranje logikih modela podataka i procesa
koji su inicijalno bili kreirani tokom analize zahteva.
Projektovanje baze podataka ema zike baze podataka.
Projektovanje interfejsa sistema grako korisniki interfejs.
Auriranje plana projekta u odnosu na postavljene zahteve
sistema.
Koraci projektovanja sistema kod integrisanja komercijalnog softvera
tj. kupljenog reenja su:
Identikovanje i sagledavanje proizvoda koji bi mogli da podre
predloeno reenje;
Prikupljanje, procena i rangiranje ponuda vendora;
Selekcija najboljih predloga;
Sklapanje ugovora sa izabranim vendorom.
PROJEKTOVANJE SLOJA PREZENTACIJE

Sloj prezentacije (presentation layer) je deo poslovne aplikacije koji
obezbeuje mehanizme komunikacije izmeu korisnika i slojeva poslovnih
servisa sistema. Jednostavan sloj prezentacije sadri komponente korisnikog
interfejsa koji se nalaze na grako korisnikim interfejsima kao to su
Microsoft Windows forme ili Microsoft ASP.NET Web forme
Informacije koje su analizirane i optimizovane tokom faze denisanja
vizije i faze planiranja predstavljaju ulaze u fazu projektovanja sloja prezentacije. Informacije ukljuuju: zahteve i ogranienja reenja, scenarija
upotrebe, workow modele, korisnike prole, opise zadataka i dr.
Za veinu korisnika najvaniji deo je upravo korisniki interfejs koji
za njih predstavlja samu aplikaciju. Dobro dizajniran korisniki interfejs
u najveem broju sluajeva, obezbeuje uspeh i prihvatljivost poslovne
aplikacije. Komponente korisnikog interfejsa upravljaju interakcijom sa
korisnicima, prikazuju i prihvataju podatke od korisnika, interpretiraju
dogaaje koji su posledica akcija korisnika, menjaju stanje korisnikog
197
interfejsa i prate tok zadataka. Interfejs aplikacije se moe podeliti na tri

dela: model (objekat aplikacije), pogled (prezentacija korisnicima) i kontroler (korisnika kontrola).
Dizajn korisnikog interfejsa bi trebao da implementira zadatke korisnika na nain koji je intuitivan korisnicima. Ovaj cilj se moe postii
jedino ukljuivanjem korisnika u svim fazama projektovanja korisnikog
interfejsa i to za vreme prototipovanja, beta testiranja i ranog usvajanja
programa. Neka od pitanja koja bi trebalo razmotriti u toku projektovanja
korisnikog interfejsa su:
Kako e korisnici biti interakciji sa sistemom?
Da li korisniki interfejs koristi odgovarajuu terminologiju, koncepte i metafore?
Da li korisnici mogu lako da pronau neophodne naredbe?
Da li je workow korektan i kompletan?
Da li interfejs optimizuje workow?
Da li korisnici mogu brzo i lako da pristupe Help-u?
Da li korisnici mogu da prilagode korisniki interfejs svojim potrebama?
Da li postoje alternativni naini za izvravanje odreenih zadataka
u sluaju da se pojavi problem?
Da bi interfejs bio efektivan treba razmotriti sledee karakteristike:
Intuitivan dizajn dizajnirati interfejs tako da korisnici intuitivno
mogu da razumeju kako da ga koriste.
Optimalno korienje prostora ekrana planirati koliinu informacija koja e biti prikazana na jednom ekranu.
Odgovarajui izgled - obratiti panju na boje, na primer za poruke
greke koristiti crvenu i sl.
Lakoa navigacije na primer, za prelazak na polja koristiti Tab,
strelice i druge preice sa tastature.
Kontrolisana navigacija odrati redosled pristupanja komponentama.
Difoltne vrednosti neki put je bolje obezbediti difoltne vrednosti.
198
Provera ulaznih podataka dobro je proveriti unete podatke pre

nego to ih aplikacija obradi.
Meni, toolbars i Help dizajnirati interfejs tako da obezbedi pristup
svim funkcionalnostima aplikacije.
Ekasno rukovanje dogaajima bitno je da korisnik ne mora da
eka dugo na odziv aplikacije.
Kod projektovanja korisnikog interfejsa veoma je bitno odabrati
najbolji interfejs model. Neki opti modeli i tehnologije implementacije
korisnikog interfejsa su:
Windows zasnovan korisniki interfejs obezbeuje bogatu korisniku interakciju, interakciju sa drugim aplikacijama,
omoguava diskonektovan rad.
Web zasnovani korisniki interfejs kada je potrebno da reenje
radi u Web okruenju. Omoguava prenosivost na mnoge druge
ureaje i platforme.
Korisniki interfejs mobilnih ureaja u dananje vreme sve je
popularnije koristiti WAP telefone ili pocket PC-jeve. Korisniki
interfejs za mobilne ureaje treba da prikae informacije na manjim
ekranima i da ponudi prihvatljivu funkcionalnost.
Dokument zasnovani korisniki interfejs neke aplikacije
omoguavaju korisnicima unoenje i pregledanje podataka u dokument formatu. Na primer, korisnik moe da pregleda i unosi
podatke u Word dokumente ili Excel radne listove.
Izbor okruenja klijenta (client environment) za korisniki interfejs
poslovnog reenja je odreena nainom korienja aplikacije i povezanosti
sa drugim sistemima. Kada su korisnici na lokalnoj mrei ili veoma brzoj
WAN mrei, najverovatnije e izbor klijenta biti okruenje bogato funkcionalnostima, poznatije kao bogati klijent (rich client). Brzina komunikacije
izmeu raunara i sistema koji im pristupaju, ovde nije primarna tema.
Ovakav tip klijenta ima veliki broj opcija za razvoj i implementaciju.
Drugi izbor klijenta je tanak klijent (thin client). Tanki klijenti, kao to
su Web pretraivai (browsers) i udaljene desktop komunikacije se najee
koriste za udaljene ili distribuirane korisnike ili za korisnike sa slabim
konekcijama kao to su dial-up modem. Ovakvi korisnici su zainteresovani
za brzinu komunikacije i zahtevaju korisniki interfejs koji alje minimum
informacija putem mree.
199
Pre nego to se odluite za klijent okruenje, prethodno je potrebno

razmotriti nekoliko faktora:
Klijent ureaji aplikacija koja mora da se koristi na razliitim
klijent ureajima, PDA (Personal Digital Assistants), telefonima,
interaktivnim televizijama i sl., bi trebala da bude aplikacija tankog
klijenta.
Graki crtei ukoliko aplikacija treba da podri visoko dinamike
grake crtee, kao to su CAD ili video animacije, onda bi se
trebalo odluiti za bogatog klijenta.
Interakcija ukoliko aplikacija treba da podri visok nivo interakcije, odnosno ukoliko sadri dinamike korisnike interfejse koji se
esto menjaju, obezbeuju brze odzive, provere i druge dinamike
operacije, onda bi takva aplikacija trebala da bude bogat klijent.
irina mree aplikacija tankog klijenta zahteva veu prohodnost
mree za razliku od bogatog klijenta.
Diskonektovani klijent ukoliko klijent mora da radi u diskonektnovanoj korporativnoj mrei, onda treba koristiti bogatog klijenta.
CPU operacije ukoliko korisnik izvrava operacije koje zahtevaju
intenzivan rad CPU-a, onda bi takve operacije trebalo da se odvijaju
na raunarima krajnjih korisnika. Aplikacije koje zahtevaju intenzivno korienje CPU-a je najbolje da rade u okruenju bogatog
klijenta.
Zakljuavanje baze podataka ukoliko aplikacija zahteva visok stepen konkurentnosti kontrola onda je bogat klijent neminovan.
Lokalni resursi ukoliko aplikacija treba da pristupi lokalnim
resursima, kao to su baze podatka, tampai, skladita, registri ili
bilo koji drugi lokalni ureaji, onda je pogodan bogat klijent.
Bezbednost u okruenju visoke bezbednosti, prednosti aplikacije
bogatog klijenta su: autorizacija, autentikacija, bezbedna komunikacija, menadment stanja i praenje.
Nakon to se odluite za dizajn korisnikog interfejsa, poinjete da
kreirate prototipe korisnikog interfejsa. Poslednji korak je njihova validacija u odnosu na zahteve, sluajeve korienja, scenarija upotrebe i
logiki dizajn.
200
PROJEKTOVANJE SLOJA APLIKACIJE

Arhitektura aplikacije ukazuje na tehnologije koje e se koristiti kod
implementacije informacionog sistema. Teme koje treba razmotriti su:
stepen distribuiranosti informacionog sistema;
distribuiranje baze podataka;
informacione tehnologije za sve softvere koje se razvijaju u kui;
integracija i kastomizacija kupljenog softvera;
tehnologija koja e se koristiti za interfejs sa drugim sistemima.
Dananji informacioni sistemi su uglavnom distribuirani. Distribuirani
sistemi su sistemi gde se komponente informacionog sistema distribuiraju
na vie lokacija preko raunarske mree. Suprotno distribuiranim sistemima
su centralizovani sistemi. Distribuirane sisteme je daleko komplikovanije
implementirati nego centralizovana reenja.
Klijent/server sistem je distribuirano reenje gde su prezentacija, logika
prezentacije, aplikaciona logika, manipulacija podacima i slojevi podataka,
distribuirani izmeu klijent PC-ja i jednog ili vie servera. Logika aplikacije
je podeljena izmeu klijenta i servera tako da obezbedi optimalno
korienje resursa. Na primer, prezentacija podataka i provera ulaznih
podataka su sastavni deo klijent-aplikacije, dok se rukovanje podacima, u
smislu njihovog fizikog smetaja i kontrole pristupa, vri na serveru.
Tanak klijent (thin client) je PC raunar koji predstavlja samo interfejse
korisniku, dok se aplikaciona logika izvrava na udaljenom aplikacionom
serveru. Serveri kod klijent/server modela moraju da budu veoma jake
maine, koji uglavnom imaju instalirane klijent/server operativne sisteme,
kao to su Unix, Windows 2000 Server ili Enterprise Edition ili Linux.
Mogu biti:
sever baze podataka hostuje jednu ili vie deljenih baza podataka, izvrava sve naredbe i servise baze podataka. Na njima mogu
biti instalirani Oracle, Microsoft SQL Server, IBM DB2 ili drugi.
transakcioni serveri osiguravaju da su sve promene na bazi
podataka za jednu poslovnu transakciju uspeno obavljene ili su
otkazane. Primeri su Microsoft Transaction Server, BEA Tuxedo
ili IBM CICS i dr.
201
aplikacioni serveri izvravaju aplikacionu logiku i servise. Komunicira kao front end sa klijentima zbog prezentacije i back end
sa serverima baze podataka radi pristupa i auranja podacima. Aplikacioni server je uglavnom integrisan sa transakcionim serverom.
Veina aplikacionih servera su bazirani na CORBA standardu za
deljenje objekata ili Microsoft COM+ ili DNA standardu.
Groupware server hostuje servise za email i druge funkcionalnosti radnih grupa. Na primer, Microsoft Exchange Server.
Web server hostuje Internet ili intranet Web sajtove. Komunicira i sa debelim i tankim klijentima kako bi im prosledio dokumenta (HTML formata) ili podatke (XML formata). Pojedini Web
serveri su posebno projektovani da hostuju e-commerce aplikacije
koje podravaju elektronsku trgovinu (npr., Netscape Commerce
Server).
Klijent/server sistemi sa troslojnom arhitekturom (three-tier architecture)
predstavljaju sisteme sa tri, u velikoj meri, nezavisna podsistema:
podsistem za interakciju sa korisnikom (implementira funkcije
korisnikog interfejsa);
podsistem za implementaciju osnovnih funkcija sistema (implementira tzv. "poslovnu logiku");
podsistem za rukovanje podacima, gde se pre svega misli na sistem
za upravljanje bazama podataka.
Na slici 5.31 je prikazan odnos ova tri podsistema gde se vidi da ne
postoji direktna veza izmeu podsistema za interakciju sa korisnikom i
podsistema za rukovanje podacima. Zbog ovakvog meusobnog odnosa,
ovi podsistemi se nazivaju i slojevi.
Slika 5.31. Elementi troslojne arhitekture sistema

202
Za razliku od dvoslojnog modela obrade podataka, u okviru koga je

logika aplikacije bila podeljena izmeu klijenta i servera, u modelu troslojne
arhitekture sistema ona se nalazi koncentrisana u tzv. aplikacionom serveru
ija je namena da izvrava programski kd koji implementira logiku aplikacije. Klijent aplikacija je namenjena samo za implementaciju korisnikog
interfejsa, a funkcija sistema za upravljanje bazom podataka je iskljuivo
ziko rukovanje podacima. Tako organizovan sistem je jednostavniji za
odravanje, jer je mogue nezavisno razvijati korisniki interfejs i logiku
aplikacije.
Jedna od vanijih karakteristika troslojnih sistema je skalabilnost.
Naime, poveavanje broja klijenata u tom sluaju je veoma jednostavno.
Poveavanje propusne moi servera srednjeg sloja postie se dodavanjem
novih serverskih maina. Analogno tome mogue je poveati i propusnu
mo zadnjeg sloja. Ovde se moe uoiti da se poveanje brzine odziva
serverskog sloja moe postii dodavanjem novih serverskih maina uz
korienje postojeih, te se na taj nain moe iskoristiti i oprema koja ne
mora imati vrhunske performanse. Sistem sa vie servera karakterie i
poveana pouzdanost i eksibilnost. Pored toga, mogue je ekasno vriti
balansiranje optereenja serverskog podsistema.
iroka prihvaenost World Wide Web-a uticala je na pojavu Web itaa,
iji je izgled i nain korienja postao poznat veini korisnika. Informacioni sistemi kod kojih se komunikacija sa korisnikom odvija kroz Web
ita u velikoj meri eliminie potrebu za dugotrajnom i skupom obukom
korisnika. Sa druge strane, npr., Java programi se, u formi apleta, mogu
ugraivati u Web stranice i na taj nain distribuirati korisnicima. Nezavisno od konkretne zike platforme klijenta (dovoljan je Web ita sa
podrkom za Javu), takve klijent aplikacije se mogu na mrei automatski
distribuirati i instalirati.
Troslojne arhitekture informacionih sistema podrazumevaju oslanjanje
na standarde gde su najee u pitanju sistemi zasnovani na Internet tehnologijama. Oslanjanje na standarde omoguava integraciju informacionih
sistema heterogenih u pogledu koriene hardverske i softverske opreme.
Na primer, raunarska mrea ovakvog sistema moe biti zasnovana na TCP/
IP familiji protokola. Serveri u mrei mogu biti od razliitih proizvoaa,
sve dok obezbeuju standardne servise predviene protokolom.
Proirivanjem koncepta troslojnih sistema dolazi se do pojma vieslojnih
sistema (multitier architecture), gde se vri dalja podela na komponente
203
u okviru srednjeg sloja sa ciljem jo veeg poveanja skalabilnosti, odnosno performansi sistema. Jedna mogua arhitektura vieslojnih sistema
je prikazana na slici 5.32. Srednji sloj je podeljen na dva sloja: jedan je
namenjen za opsluivanje Web klijenata, a drugi sadri komponente koje
implementiraju poslovnu logiku sistema.
Slika 5.32. Primer arhitekture vieslojnog sistema
PROJEKTOVANJE SLOJA PODATAKA

Baza podataka (BP) se najoptije moe denisati kao dobro struktuirana
kolekcija podataka, uskladitenih sa minimumom redundanse, koju,
zajedniki, koriste i odrava vie korisnika i aplikacija. Baza podataka se
projektuje tako da to ekasnije zadovolji zahteve za informacijama. Baza
podataka mora da omogui pravovremno dobijanje kvalitetnih informacija na svim nivoima odluivanja kako bi na taj nain poveala ekasnost
organizacije. Da bi se ovaj zadatak izvrio, potrebno je detaljno poznavati
poslovanje cele organizacije, a ne samo njenih izolovanih delova.
Podaci u bazi podataka su organizovani sledeim redom: bit, bajt,

polje, zapis, tabela, baza podataka (Slika 5.33).
204
Slika 5.33. Hijerarhija organizacije podataka
Bit je najmanji element prikaza podataka u raunaru i uzima vrednosti

0 ili 1. Bajt je najmanja adresibilna jedinica koja sadri 8 bita i predstavlja
jedan karakter. Polje ili atribut predstavlja se sa jednim ili vie bajtova.
Zapis sadri skup atributa o jednom primerku (instanci), na primer atributi
jednog studenta su: broj indeksa: 50/90, ime i prezime: Petar Petrovi,
semestar: 2. Tabela je kolekcija razliitih zapisa, a koje pripadaju jednom
objektu. Baza podataka je kolekcija povezanih tabela.
Proces projektovanja baza podataka je deo procesa projektovanja
informacionih sistema i sastoji se od sledeih faza:
Analiza sistema i zahteva korisnika cilj je izrada poslovnog
modela sistema (Business Model) koji predstavlja model procesa.
Postoji vie razliitih metoda za analizu sistema i specikaciju
zahteva korisnika koje se mogu podeliti na konvencionalne i objektne. Kod objektno-orijentisanog pristupa izrauju se poslovni
sluajevi korienja (Business Use Cases).
Specikacija aplikacija u ovoj fazi se izrauju detaljne specikacije aplikacija. Aplikacija se obino predstavlja kao skup ulaza
i izlaza koji su najee opisani preko ekranskih formi. Kod objektno-orijentisanog razvoja koriste se sluajevi korienja, sistemski
dijagrami sekvenci i dijagrami aktivnosti.
205
Izrada konceptualnog modela konceptualni model je model

realnog sistema koji predstavlja celokupan informacioni sadraj
baze podataka. Izgradnja konceptualnog modela i specikacija
aplikacija su meusobno uslovljeni. U nekim pristupima se konceptualni model izgrauje direktno, na bazi poslovnog modela
sistema, a objekti konceptualnog modela slue za specikaciju
aplikacija. U drugim pristupima se konceptualni model razvija na
osnovu specikacije aplikacija, odnosno strukture ulaza i izlaza
aplikacije. Kao alat za konceptualno modelovanje u konvencionalnim pristupima se najee koristi model objekti-veze. Kod
objektno-orijentisanog pristupa, za prikaz konceptualnog modela
koristi se dijagram klasa.
Logiko projektovanje baze podataka predstavlja transformaciju konceptualnog modela u opis baze podataka u jeziku za
opis (DDL) konkretnog DBMS-a. Pojedini CASE alati sadre ovu
mogunost transformacije modela objekti veze ili dijagrama klasa
u relacioni model.
Fiziko projektovanje baze podataka podrazumeva projektovanje interne, zike strukture baze podataka, na osnovu
logikog modela i specikacija svih aplikacija. Fizika struktura
baze podataka treba da omogui ostvarivanje zadovoljavajuih
performansi sistema.
Implementacija i podeavanje Baza podataka se imlementira
u konkretnom DBMS-u, a zatim se prate performanse sistema,
izmene u aplikacijama i logikoj strukturi baze i vri odgovarajue
podeavanje zike strukuture.
Projektovanje aplikacija na osnovu specikacije aplikacija i
logikog modela baze podataka u konkretnom DBMS-u obavlja
se projektovanje aplikacija. U konvencionalnim pristupima za
ovu fazu se koristi metoda Strukturnog projektovanja, dok se za
objektne sisteme standardno primenjuje jedinstveni proces razvoja
softvera (The Unied Software Development Process).
Implementacija i odravanje podrazumeva se kodiranje, testiranje i uvoenje aplikacija. Odravanje aplikacija podrazumeva
promene u aplikacijama, a ponekad i u logikom modelu baze
podataka do kojih se dolazi usled otkrivenih greaka, promena u
implementacionom okruenju ili promena zahteva korisnika.
206
Izuavanju baze podataka moe se pristupiti sa dva aspekta:

modeli podataka teorije pomou kojih se specikuje i projektuje neka konkretna baza podataka ili informacioni sistem. U
prethodnom delu knjige smo se upoznali sa nekim modelima
podataka.
sistemi za upravljanje bazom podataka (Database Management Systems DBMS) softverski sistem koji kreira, pristupa,
upravlja, kontrolie, uva i pretrauje podatke. Osnovne komponente DBMS-a su (Slika 5.34):
1. Fizika baza podataka baza podataka je smetena na diskovima. Sistem za upravljanje skladitenjem podataka mora da
obezbedi jednoobrazan pristup svim formatima podataka na
svim vrstama memorije. Pored podataka, baza sadri i metapodatke, tzv. renik podataka (Data Dictionary, Catalog ili Data
Directory). Renik baze podataka opisuje strukturu posmatrane
baze podataka, pravila ouvanja integriteta podataka, prava
korienja, indekse posmatrane baze i sl. DBMS odrava i bazu
indeksa koji omoguavaju brz pristup indeksiranim podacima
baze. Najea struktura indeksa je B-stablo.
2. Sistem za upravljanje skladitenjem podataka sadri dve osnovne komponente:
Upravljanje datotekama (File Manager) upravlja lokacijama
datoteka preko kojih se realizuje baza podataka i pristupima
blokova podataka na zahtev upravljanja baferima. Diskovi su
obino podeljeni u blokove koji predstavljaju kontinualne segmente memorije veliine od 4000 do 16000 bajta.
Upravljanje baferima (Buer Manager) prihvata blok
podataka sa diska, dodeljuje mu izabranu stranicu centralne
memorije, zadrava ga u skladu sa ugraenim algoritmom upravljanja baferima, a zatim vraa na disk oslobaajui dodeljenu
mu stranicu.
3. Upravljanje transakcijama i oporavkom obezbeuje konzistentnost baze podataka u konkurentnoj obradi podataka i pri veoma
ozbiljnim otkazima sistema.
4. Odravanje eme baze podataka dizajn baze podataka se
opisuje modelom eme baze podataka. ema baze podataka je
207
ziki model baze podataka i predstavlja tehniku implementaciju

logikog modela podataka. ema baze podataka opisuje strukturu
baze, pravila integriteta i prava korienja. Odravanje eme baze
podataka podrazumeva kreiranje i modikovanje ovog opisa koji
se uva u reniku podataka.
5. Podema ulazi u DBMS su upiti i aplikacije i ema baze podatka.
Sva tri navedena ulaza se realizuju preko jezika baze podatka:
Jezik za opis podataka (Data Denition Language - DDL)
se koristi za izradu renika podataka, inicijalizaciju ili kreiranje baze podataka, opisivanje logikog pogleda za svakog
individualnog korisnika ili programera i speciranje bilo kog
ogranienja nad poljima ili tabelama baze podataka.
Jezik za manipulaciju podataka (Data Manipulation Language - DML) se koristi za odravanje podataka, koja ukljuuje
takve operacije koje auriraju, ubacuju i briu delove baza
podataka i realizuju upite.
Jezici baze podataka su ili potpuno neproceduralni (relacione baze) ili
u sebi sadre proceduralne delove (objektne baze). Neproceduralni jezici
sadre konstrukcije preko kojih se samo specikuju uslovi koje treba da
zadovolji eljeni rezultat, a ne i procedura pomou koje se dobija taj rezultat. Neproceduralni jezici se esto nazivaju i upitni jezici jer im je osnovna
namena specikacija upita. Osnovni zadatak procesora upita (Query
Processor) je da transformie neproceduralni iskaz u sekvencu akcija koje
treba da obavi sistem za upravljanje skladitenjem podataka. Najsloeniji
deo je optimizacija upita, tj. nalaenje najpogodnije procedure (sekvence
akcija) za realizaciju neproceduralnog iskaza. Najpoznatiji upitni jezik je
SQL (Structured Query Language), meutim sve vea primena objektnih
baza dovela je do OQL (Object Query Language) standardnog upitnog
jezika za ovaj tip baze.
208
Slika 5.34. Osnovne komponente DBMS-a [8]
DBMS je tronivovske arhitekture koja ima sledee nivoe (Slika 5.35):

Eksterni dizajn (podema) je takvo predstavljanje podataka,
koje odgovara zahtevima nekog korisnika ili programima. To je
apstraktan prikaz odreenog dela baze podataka, koji je relevantan
za odreenog korisnika.
Konceptualni nivo ili ema baze podataka je apstraktni globalni
logiki pogled na bazu podataka. U njemu su obuhvaene sve vrste
objekata, njihovi atributi i meusobne veze. ema baze podataka je
vanija od programskog jezika za korisnika, jer predstavlja temelj
celokupne obrade podataka u organizaciji. Taj temelj raste i postaje
s vremenom sve opseniji i kompleksniji.
Fiziki ili interni pogled na podatke je opis zike organizacije
podataka, koja je, naravno, zavisna od medijuma za memorisanje.
Ovaj pogled pokazuje u kakvom su obliku podaci stvarno memorisani, kakvi su pojedini zapisi, kako su rasporeeni, kakvi se mehanizmi za adresiranje koriste i dr.
209
Slika 5.35. Tipina DBMS arhitektura
Objektna orjentacija postepeno preuzima primat i u sistemima za

upravljanje bazama podataka (Database Management Systems DBMS).
Cilj razvoja objektnih DBMS-a je da se preuzmu i druge bitne karakteristike objektno-orijentisanog razvoja i objektno-orijentisanih programskih
jezika, kao to su: uaurenje (enkapsuliranje), odvajanje implementacije
softvera od njegove specikacije tj. naina korienja; modularizacija,
grupisanje pojedinih delova softvera u koherentne i relativno izolovane
celine; ponovno korienje ranije razvijenog softvera i sl. Kod konvencionalnih DBMS sistema, tronivovska arhitektura je tretirala bazu podataka
kao samostalnu komponentu informacionog sistema koja je u najveoj
meri bila nezavisna od aplikacija koje je koriste. To je razlog i to su jezici
DBMS-a (DDL i DML) potpuno nezavisni od programskih jezika u kojima
se razvijaju aplikacije. Nasuprot ovome, objektni DBMS tee da integriu
funkcije DBMS-a u programski jezik kako bi se poboljale performanse
sistema. Osnovna karakteristika objektnih DBMS-a je integracija objektnoorijentisanih jezika i funkcija DBMS-a. Oni omoguavaju da se objekti
baze podataka pojavljuju kao objekti programa.
210
Osnovni elementi arhitekture objektnih DBMS-a su:

objektni model treba da bude denisan kao zajednika osnova za
objektne programske jezike, komunikaciju objekata u nekoj klijent/
server arhitekturi i objektne baze podataka. U objektnom modelu
objekat se denie kao entitet koji je sposoban da uva svoja stanja
i koji okolini stavlja na raspolaganje skup operacija preko kojih se
tim stanjima pristupa. Stanje objekata se predstavlja vrednostima
njegovih atributa i veza sa drugim objektima u sistemu. Ponaanje
sistema se opisuje preko skupa operacija koje objekat izvrava ili
se nad njim izvravaju. Primer objektnog modela je prikazan na
slici 5.36.
objektni specikacioni jezici pod specikacijom se podrazumevaju eksterne karakteristike, vidljive korisniku kao to su: operacije
koje mogu biti pozvane, osobine kojima se moe pristupiti i izuzeci
koji se mogu dogoditi pri izvoenju operacija. Specikacija tipa se
daje preko koncepta interfejsa ili preko koncepta klase. Interfejs
se ne moe direktno instancirati i slui da se preko njega deniu
operacije koje e naslediti neki korisniki denisani objekti.
Slika 5.36. Primer objektnog modela [8]
objektni upitni jezik OQL (Object Query Language) je namenjen

objektnom modelu. Upiti napisani u OQL-u mogu da vrate objekte
iji tipovi odgovaraju skupu tipova u objektnim programskim
jezicima.
povezivanje jezika (language binding) povezivanje jezika baze
podataka i objektnih programskih jezika. Radei sa objektnim
211
jezikom nad objektnom bazom podataka, programer treba da

stekne utisak da radi sa jednim, a ne sa dva posebna jezika i nekim
vidljivim nainom njihovog povezivanja. Da bi se ostvario ovaj cilj
deniu se tzv. language binding.
Aktivni sistemi baza podataka automatski izvravaju odreene operacije kao odgovor na pojavu odreenih dogaaja i/ili za zadovoljenje
odreenih uslova. Aktivni sistemi imaju mehanizme za prepoznavanje
situacija i za automatsko pokretanje odgovarajuih procedura kao reakcija
na nastale situacije. Pasivni sistemi, za razliku od aktivnih, imaju manje
mogunosti za predstavljanje dinamike realnog sistema. Oni pamte logiku
emu i podatke, dok sloeniji uslovi integriteta i pravila poslovanja se
realizuju aplikativnim programima.
Za ilustraciju naina rada pasivnih sistema prikazae se primer magacinskog poslovanja. Na skladitu jedne parmerije nalazi se odreeni broj
proizvoda. Na osnovu informacija o broju prodatih proizvoda smanjuje
se broj na zalihama. Kada broj proizvoda na skladitu postane manji od
50, tada se vri naruivanje novih 150 komada.
Kod pasivnih baza podataka uvaju se samo podaci o trenutnom broju
proizvoda kojima se raspolae. Sva ostala semantika se nalazi u programima.
Neki programi slue za auriranje stanja na skladitu, dok poseban program periodino ispituje stanje i generie porudbinu kada broj proizvoda
padne na 50. Takvi programi se pokreu na korisniki zahtev.
Kod aktivnih sistema prestaje potreba za programom za periodino
ispitivanje stanja na skladitu, jer ga menja pravilo u jedinstvenoj bazi
pravila i podataka. To pravilo se automatski pokree i omoguuje generisanje porudbenice svaki put kada broj proizvoda na skladitu postane
manji od 50. Svako pravilo denie situaciju i akcije koje se preduzimaju sa
nastankom situacije. Pravila u aktivnim bazama podataka su poznata kao
ECA (Event-Condition-Action) produkciona pravila. Situacija se odreuje
u terminima dogaaja i uslova: Kada se dogaaj pojavi, ukoliko je uslov
zadovoljen (dogaaj i uslov odreuju situaciju), izvrti akciju. Dogaaji i
akcije prethodno moraju biti denisani. Sva specirana pravila ine model
znanja.
Trigeri su specina vrsta ECA pravila. Dogaaj je operacija auriranja
baze podataka, uslov je proizvoljni SQL predikat, a akcija je sekvenca
SQL naredbi. Sekvenca SQL naredbi se izvrava samo ako je detektovan
212
dogaaj (pokrenuta odgovarajua operacija auriranja baze) i ako je uslov

zadovoljen (true). SQL:1999 standard denie trigere kao objekte eme
baze podataka, koji su vezani za tano jednu baznu tabelu i koji se pozivaju
svaki put:
kada se ubaci jedan ili vie redova u tabelu za koju je denisan
triger (INSERT naredba);
kada se promeni jedan ili vie redova u tabeli za koju je denisan
triger (UPDATE naredba) ili
kada se obrie jedan ili vie redova iz tabele za koju je denisan
triger (DELETE naredba).
Trigeri mogu biti kategorizovani na vie naina:
trigeri mogu da se pozivaju neposredno pre (BEFORE) ili neposredno posle (AFTER) izvravanja SQL naredbe za koju je denisan
triger;
u zavisnosti od toga koji od tri tipa operacija auriranja baze predstavlja dogaaj koji izaziva pokretanje trigera, mogu biti INSERT,
UPDATE ili DELETE trigeri;
triger se moe izvriti jednom za operaciju auriranja koja ga
pokree ili jednom za svaki red koji je auriran operacijom koja
pokree triger. U skladu sa time razlikuju se trigeri koji se pokreu
na nivou naredbe i oni koji se pokreu na nivou reda.
Trigeri mogu da podre sledea poslovna pravila:
validacija ulaznih podataka;
automatsko generisanje vrednosti za ubaeni red;
itanje iz drugih tabela;
pisanje u druge tabele;
odravanje poslovnih pravila itd.
213
Slika 5.37. Kreiranje trigera kod DB2 baze [6]
Slika 5.38. Kreiranje akcije trigera [6]
214
Sloj podataka (data layer) jednog reenja se sastoji od skladita i servisa

podataka. Skladite podataka je obina baza podataka u kojoj su podaci
organizovani i skladiteni. Servisi podataka izvravaju osnovne zadatke
kao to su kreiranje, izvlaenje, auriranje i brisanje podataka. Tokom
logikog dizajna, projektni tim je odredio objekte i atribute koji e biti
uskladiteni u bazu podataka, naine pristupa, obrade i pretraivanja. U
toku zikog dizajna, tim kreira emu baze podataka koja prikazuje tabele,
relacije, tipove polja podataka, indekse, procedure i planove za migraciju
podataka, backup, oporavak baze podataka i odgovarajue podrke. Pitanje
performansi bi trebalo razmatrati kroz itav ciklus razvoja.
Tehnike koje se najee koriste za optimizovanje pristupa podacima
su:
Indeksiranje podataka indeks (index) je ureena lista redova
u tabeli koju DBMS moe da koristi kako bi ubrzao operacije
pretraivanja. Indeks je struktuiran kao stablo i odrava sortiranu
listu odreenog skupa podataka. Upiti (query) koji se izvravaju nad
indeskiranim podacima su mnogo bri i ekasniji. DBMS koristi
indekse kako bi brzo vodio upit do direktne lokacije zahtevanih
podataka. Mogu se koristiti dva tipa indeksa i to klasterovani i
neklasterovani indeksi.
Klasterovani indeks ziki pamti redove podataka u tabeli kako bi
sloio redosled indeksa. Klasterovani indeks je obino denisan kao
primarni klju tabele. Jedino ogranienje klasterovanih indeksa je
to to usporavaju operacije upisivanja jer redovi moraju biti ee
preureivani. Neklasterovani indeks odrava malu tabelu informacija o indeksima o koloni ili grupi kolona. Jedina razlika izmeu
klasterovanog indeksa (primary key) i neklasterovanog (unique
constraint) je ta to primarni klju ne dozvoljava null vrednost
(prazno polje), dok unique constraint dozvoljava jednu null vrednost, dok su sve vrednosti razliite.
Particionisanje podataka kada je broj zapisa u tabeli toliko
velik da usporava pristup podacima, onda je neophodno izvriti
particionisanje tabele. Mogu se implementirati horizontalno ili
vertikalno particionisanje velikih tabela kako bi se ubrzala brzina
obrade podataka. Kod horizontalnog particionisanja (horizontal
partitioning) tabela koja sadri mnogo redova se deli u vie tabela
koje sadre isti broj kolona. Meutim, svaka tabela sadri odreeni
215
podskup podataka. Na primer, jedna tabela moe da sadri sve

nazive klijenata koji poinju od slova A do M, dok druga tabela
moe da sadri nazive klijenta iji nazivi poinju od N do . Vertikalno particionisanje deli tabelu koja sadri mnogo kolona u vie
tabela.
Normalizacija podataka podrazumeva poboljanje logikog
modela baze podataka kako bi se eliminisali duplicirani podaci u
bazi. Normalizacija obino podrazumeva deljenje baze podataka
u dve ili vie tabele i denisanje relacija izmeu njih. Normalizacija baze podataka minimizira dupliciranje informacija, smanjuje
nekonzistentnost podataka i ubrzava menjanje podataka preko
operacija ubacivanja, auriranja i brisanja.
Vaan korak u planiranju baze podataka je integritet podataka koji
obezbeuje tanost i konzistentnost podataka. Mogu se implementirati
tri tipova integriteta podataka u bazama podataka:
integritet domena (domain integrity) odreuje skup validnih
vrednosti podataka za kolonu i odreuje da li su dozvoljene null
vrednosti.
integritet objekta (entity integrity) zahteva da svaki red u tabeli
ima jedinstveni identikator, tj. vrednost primarnog kljua.
referencijalni integritet (referential integrity) osigurava da se
veze izmeu primarnog i spoljnjeg kljua uvek odravaju. Razmatra se ta treba da se uradi ukoliko primarni klju mora da bude
izmenjen ili obrisan.
validacija podataka (data validation) osiguravaju korektnost
i validnost podataka. Mogu se koristiti sledee metode za proveru
podataka:
provera opsega (range checking) proverava da li su vrednosti podataka unutar granica koji su odreeni funkcionalnom
specikacijom reenja.
provera formata podataka (data format checking) proverava
da li su podaci postavljeni na odgovarajui format, na primer
format telefonskog broja, format valute (currency) i sl.
provera tipa podataka (data type checking) proverava da su
podaci odgovarajueg tipa (string, date, decimal, integer i sl.).
216
Validacija podataka se moe vriti na klijent ili server strani. Provera

podataka na klijent strani (skriptovima, kontrolama korisnikog
interfejsa, programima i sl.) spreavaju upisivanje nevalidnih podataka u bazu.
Integritet podataka se moe postii sledeim funkcionalnostima baze
podataka:
tipovi podataka (data types) postavljanje odgovarajuih tipova
podataka na polja u bazi podataka obezbeuje da se nekorektni
tipovi podataka ne mogu dodati u tabelu.
difoltne vrednosti (default values) odreuju vrednosti polja pre
nego to je korisnik izmeni.
pravila validacije podataka (data validation rules) odreuju se
prihvatljive vrednosti podataka, kao to su duina polja, ulazne
maske ili opseg vrednosti.
kljuevi (keys) mnoge baze podataka automatski nadgledaju
referencijalni integritet izmeu tabela.
okidai (triggers) triger je skup programskih iskaza koji se deniu
za odreenu tabelu. Kada se odreena akcija (na primer, ubaci (insert), promeni (update) ili brii (delete)) dogodi u toj tabeli, trigeri
automatski aktiviraju te iskaze. Trigeri mogu i verikovati podatke
u drugim tabelama ili izvravati automatsko auriranje razliitih
tabela.
uskladitene procedure (stored procedures) predstavlja imenovanu
kolekciju SQL iskaza koje su uskladitene u DBMS-u. Mogue je
napisati jedan deo koda koji izvrava jednu akciju, zatim je skladititi
i pozivati je onoliko puta koliko je potrebno.
skriptovi (scripts) skript je manji programski kod u tekstualnom
formatu koji moe biti interpretiran u raznim programima. Svaki
skript se aktivira van memorijskog prostora DBMS-a.
Servisi podataka se takoe mogu koristiti za implementaciju integriteta
podataka. Komponente implementiraju servise podataka unutar jedne aplikacije. Komponente su izvrne kolekcije koda koje se nalaze na serveru ili
unutar nekog drugog programa. Komponente su sline skriptovima samo
to omoguavaju uu integraciju okruenja razvoja sa bazom podataka i
programskim kodom.
217
Tokom identikovanja zahteva, projektni tim je denisao i mnoga

poslovna pravila koji predstavljaju logiku reenja. Nakon postavljanja
pravila integriteta podataka, tim mora da preispita zahteve u odnosu na
date kriterijume.
PROJEKTOVANJE BEZBEDNOSTI
Sistem mora biti projektovan za bezbednost, a ne doraivan za bezbednost! Tokom svih faza razvoja sistema treba preduzimati odgovarajue
mere bezbednosti (Tabela 5.6).
Veoma je vano da organizacija bude svesna svih bezbednosnih slabosti
kako bi se bolje zatitila. Tipine slabe take sistema su:
slabe ifre (weak passwords) korisnici obino biraju ifre koje se
lako pamte, kao to su nazivi njihovih voljenih ili bilo ta vezano za
njihove line podatke. Zlonamerni napadai lako mogu da pogode
tanu ifru i pristupe ne samo raunaru, ve i itavoj mrei na koju
je raunar povezan.
Tabela 5.6. Mere bezbednosti po fazama MSF procesnog modela
nepravilno kongurisan softver (miscongured software)

ukoliko su servisi softvera kongurisani tako da koriste lokalni
nalog ili doputaju vie nego to se zahteva, napadai mogu lako
da iskoriste servise kako bi pristupili sistemu ili izvrili zlonamerne
akcije. Nepravilno kongurisan softver se moe podeliti u tri kategorije:
218
mrea Internet veze, rewalls;

aplikacija kongurisani fajlovi;
host servisi, portovi, protokoli.
prenos nekriptovanih podataka (unencrypted data transfer)
veina Web aplikacija prihvataju korisniki input, obrauju
korisnike zahteve i vraaju odgovor korisniku. Ukoliko se podaci
alju na Web server i vraaju korisniku u istom tekstualnom formatu, onda postoji mogunost da podaci, tokom prenosa, budu
uhvaeni, proitani i izmenjeni od strane napadaa. Ukoliko su
podaci koji sadre poverljive informacije, na primer poverljivi
brojevi prodaje, informacije o autentikacji, poslati bez enkripcije, napada lako moe da im pristupi i da iskoristi za obavljanje
zlonamerne akcije na Web aplikaciji ili organizaciji.
buer overow tip greke koji se deava kada se vie podataka
upisuje u bafer koji nije programiran da sadri toliki broj. Na primer,
ukoliko korisnik pozove funkciju sa stringom od 260 karaktera, koja
treba da se kopira u bafer u koga moe da stane 256 karaktera tada
se alje tip greke buer overow. Zlonamerni korisnici ispituju
aplikacije ne bi li pronali nain da prouzrokuju buer overow
jer to mogu iskoristiti za:
obaranje aplikacije ili operativnog sistema;
pronalaenje jo bezbednosnih slabosti itajui poruke o
grekama (developeri obino piu poruke o grekama u procesu debagovanja aplikacije koje ukazuju na trag o greci, na
primer moe da oda lokaciju fajla o iframa i sl.);
dobijanje pristupa memoriji sistema koji se zahteva da bi se
pokrenuo kod programa.
Ubacivanje koda (code injection) podrazumeva ubacivanje
zlonamernog koda koji u zavisnosti od prirode napada mogu da
se pokrenu na Web serveru, serveru baze podataka ili na klijentu.
Tipini tipovi napada ubacivanjem koda su ubacivanjem SQL iskaza,
unakrsno skriptovanje i ubacivanjem koda preko buer overows.
Ukoliko developeri dinamiki prave SQL iskaze preko korisnikog
inputa, tada napadai mogu da modikuju SQL iskaze. Kod unakrsnog skriptovanja, napadai ne napadaju Web server ve druge
219
korisnike na Web serveru tako to izvravaju skript na drugim

korisnikim raunarima koji mogu dalje pristupati kolaiima
(cookies) ili aktivirati druge skriptove.
Kreiranje modela pretnje ukljuuje sledee zadatke:
Organizovati brainstorming sastanke kako bi se identikovale
potencijalne pretnje;
Izlistati sve mogue pretnje;
Primeniti STRIDE kategorije bezbednosti (nakon to se kreira
inicijalna lista moguih pretnji bezbednosti, pomou STRIDE
modela treba kategorizovati pretnje). STRIDE model je tehnika
za identikovanje i kategorisanje pretnji aplikacije:
Prevara identiteta (Spoong identity) napada krade ili pogaa
ifru korisnika; alje e-mail poruku u tue ime ili IP prevara
gde napada koristi IP adresu poverljivog izvora.
Podmiivanje (Tampering) kada korisnik neautorizovano
pristupa raunaru i zatim menja operacije, konguraciju ili
podatke.
Poricanje (Repudiation) kada sistem administrator ne moe da
dokae da je korisnik zlonameran ili da je izvrio neku akciju.
Obelodanjena informacija (Information disclosure) kada
neautorizovani korisnik moe da pregleda privatne podatke,
kao to su fajlovi koji sadre brojeve kreditnih kartica i njihove
datume isteka.
Napad uskraivanjem usluga (Denial-of-service - DoS) moe
da prouzrokuje da aplikacija ili operativni sistem prestane da
radi, da je CPU angaovan predugo, sistemska memorija se
troi to dovodi do usporavanja funkcionalnosti aplikacija i
operativnog sistema, smanjen je opseg mree ili je potpuno
uguen saobraaj na mrei.
Visina privilegije (Elevation of privilege) kada korisnik dobija
prava pristupa koja su vea i od privilegija koje administrator
ima.
Pisati komentare za svaku pretnju (tip pretnje, uticaj napada na
organizaciju u odnosu na trokove i uloen napor, mogue tehnike
220
koje e napada koristiti, mesto deavanja napada i mogue tehnike

za umanjenje napada)
Voditi istraivanje;
Rangirati rizike pretnji.
Nakon to se identikuju pretnje, sledei korak je da se pronae nain
kako da se te pretnje umanje. Na pretnje se moe odgovoriti na nekoliko
naina:
informisati korisnike o potencijalnim pretnjama;
ukloniti funkcionalnosti reenja koje dovode do veih rizika;
identikovati tehnike umanjenja:
autentikacija i autorizacija autentikacija je proces verikovanja korisnika, dok je autorizacija proces odreivanja pristupa
resursima;
bezbedna komunikacija koristiti Secure Sockets Layer SSL
(koji uspostavlja kriptovani komunikacioni kanal izmeu klijenta i servera); Internet Protocol Security IPSec (obezbeuje
podatke koji se alju izmeu dva raunara, kao na primer servera
aplikacija i servera baze podataka); Virtual private networks
VPNs (omoguava da se uspostavi point-to-point IP prenos
preko Interneta);
kvalitet usluga (Quality of Service - QoS) mehanizam koji
omoguava sistem administratorima da dodele vee prioritete
odreenim tipovima mrenog saobraaja;
guenje (throttling) ograniava broj poruka koji se alje ka
vaem sistemu;
praenje (auditing) proces prikuplja informacije o korisnikim
aktivnostima i vanim dogaajima i skladiti te informacije radi
dalje analize. Praenje je poznatije kao logging. Windows event
logs omoguava vaoj aplikaciji da snima informacije o vanim
dogaajima.
ltriranje (ltering) proces hvatanja i ispitivanja podataka se
alje do vaeg sistema gde vi moete da odluite dali da prihvatite ili odbijete podatak.
najnie privilegije (least privilege) korisnicima se daje minimalni nivo privilegije koji im omoguava samo da zavre svoje
poslove.
221
Politika bezbednosti (Security policy) denie organizacione zahteve

za bezbednim korienjem raunara i mree. Ukljuuje procedure za detektovanje, prevenciju i odzive na napade i obezbeuje okvir (framework)
za implementaciju plana i procedura bezbednosti aplikacije. Politika bezbednosti odreuje ta vaa aplikacija i njeni korisnici smeju da urade.
Prvi korak kod projektovanja bezbedne aplikacije je pisanje sigurnog
koda. Kd koji pristupa samo memoriji za koju je autorizovan da pristupa
se zove bezbedan kd (type-safe code). Na primer, bezbedan kd ne
pristupa vrednostima privatnih polja drugih objekata.
Drugi nain da se zatitimo je potpisivanje koda (code signing) ime
se osigurava autentinost i integritet koda. .NET Framework podrava
autentine digitalne sertikate (authenticode digital certicates) i potpise
sa jakim imenom (strong name signatures).
Potpisivanje podataka (data signing) i enkripcija (encryption) su
procesi koji se koriste u zatiti sadraja podataka. Enkripcija je proces
prikrivanja podataka pre nego to se poalju ili uskladite. Pre nego to se
podaci ifruju, njihov sadraj je u punom tekstu (plaintext), a nakon enkripcije tekst se naziva ifrirani tekst (ciphertext). ifrirani tekst je totalno
neitljiv. Dekripcija je proces prevoenja ifriranog teksta u itljiv (plaintext). Procesi enkripcije i dekripcije podataka se oslanjaju na tehnike heinga
i potpisivanja podataka. Heing (hashing) je proces uparivanja podataka
bilo koje duine na ksnu duinu sekvence bajtova tzv. he (hash). He je
dobijen primenom matematike funkcije koje se zove heing algoritam na
odreenu koliinu podataka. Potpisani podatak (signed data) je standardni
tip podataka koji se sastoji od bilo kog tipa sadraja kombinovanog sa
enkriptovanim heevima za nula ili vie potpisnika. Heevi se koriste za
potvrivanje identiteta potpisivaoca podatka i da poruka nije bila menjana
tokom njenog potpisivanja.
Bezbednost uloga (role-based security) pomae kod reavanja prevare identiteta tako to omoguava verikovanje identiteta i uloge (role)
korisnika.
KOMPLETIRANJE FAZE PLANIRANJA

Faza planiranja obuhvata vei deo arhitekture i dizajna reenja. Tokom
faze planiranja nekoliko elemenata utiu na projektovanje reenja:
Skalabilnost sposobnost proirivanja resursa kako bi se poveao
kapacitet reenja. Na primer, poveanje memorije, premetanje
222
aplikacije na moniji raunar ili distribuiranje aplikacije na vie

raunara tako da se odri transparetnost lokacije.
Raspoloivost mera koliko esto je aplikacija raspoloiva da
rukuje zahtevima. Ukoliko reenje treba da radi 24 asa dnevno, 7 dana u nedelji, onda treba da bude projektovano za visoku
raspoloivost.
Pouzdanost sposobnost aplikacije da obezbedi tane rezultate.
Performanse moe se denisati i kao mera odziva sistema ili
kao odnos broja transakcija i upotrebe resursa.
Interoperativnost sposobnost sistema da uspeno radi u heterogenim raunarskim okruenjima.
Globalizacija i lokalizacija koriste se za razvoj aplikacija koje
e se koristiti irom sveta. Globalizacija podrazumeva proces
projektovanja i razvoja aplikacija koje mogu da rade u razliitim
kulturama i lokacijama. Globalizacija ukljuuje:
identikovanje kultura i jezika koje reenje mora da podri;
dizajniranje dodatnih funkcionalnosti koji e podrati te kulture;
pisanje koda koji e adekvatno da se aktivira u svim kulturama
i na svim jezicima.
Lokalizacija je proces prilagoavanja globalizovanih aplikacija
odreenoj kulturi.
Vaan deo reenja su i administrativne funkcionalnosti:
praenje (monitoring) obezbeuje da aplikacija funkcionie korektno i da se izvrava na optimalnom nivou. Elementi plana praenja
su resursi, detekcija greke, praenje performansi, alata i dr.
migriranje podataka (data migration) kako e podaci migrirati sa
postojeeg na novo reenje. Elementi plana migracije su strategije
migracije, smernice migracije, testiranje okruenja, alati, proces
migracije i plan povratka na prethodnu konguraciju (rollback
plan).
specikacije licenciranja (licensing specications) neophodno
je obezbediti licence za sve korisnike koji e instalirati i aktivirati
aplikacije.
223
U toku faze planiranja, neophodno je napisati planove aktivnosti koji

e se izvriti u narednim fazama projekta:
plan za fazu razvoja pre nego to razvojni tim pone da razvija
reenje, veoma je vano da se verikuje da je infrastruktura spremna
za razvoj, a okruenje za testiranje reenja. Elementi plana razvoja
ukljuuju: ciljeve razvoja, matrice kompromisa, proces izgradnje,
kontrolu verzija i izvornog koda, strategiju isporuke, ciljeve projektovanja, obuavanje razvojnog tima i standarde i najbolje prakse;
plan za fazu stabilizacije plan testiranja opisuje strategiju
planiranja, organizovanja i upravljanja aktivnostima testiranja
projekta. Elementi plana testiranja ukljuuju: testiranje koda, baze
podataka, infrastrukture, bezbednosti, integracije, prihvatljivosti i
upotrebljivosti reenja, performanse i testiranje kapaciteta.
plan faze uvoenja u okviru plana uvoenja diskutuju se faktori
koji mogu da utiu na uspeno uvoenje reenja. Elementi plana
uvoenja ukljuuju: cilj uvoenja, arhitektura, resursi uvoenja,
koordinacija obuavanja, raspored uvoenja, podrka reenja,
proces instalacije sajta i dr.
Da bi zapoeo kreiranje reenja, razvojni tim koristi dokument tehnike
specikacije. Tehnika specikacija je skup dokumenata koji ukljuuju
ziki dizajn, kao to su specikacije klasa, modela komponenti, topologije
mree i komponenti i sl. Elementi dokumenta tehnike specikacije su:
pregled arhitekture opisuje se arhitektura koja e biti implementirana reenjem;
objektni model opisuje model objekata reenja. Ukljuuje opise
svih objekata i njihovih funkcionalnosti;
interfejsi sadri kd i detalje svakog interfejsa u reenju;
kd opisuje operacije svakog metoda u reenju;
kodovi greke opisuje kodove greki koji se koriste za rukovanje
grekama u reenju;
praenje greaka opisuje kako e se razliite greke pratiti i upravljati;
konguracija opisuje kako e reenje biti registrovano na destinacionim raunarima.
dokumentacija podrke npr., funkcionalna specikacija i dr.
224
5.6. Stabilizacija i uvoenje reenja

Nakon to je zavrena faza razvoja reenja, projekat ulazi u faze stabilizacije i uvoenja (deploying). Cilj faze stabilizacije je da se pobolja kvalitet
reenja i da ga stabilizuje pre nego to se pusti u proizvodno okruenje.
Faza uvoenja uvodi reenje u proizvodno okruenje.
Dva glavna zadatka u fazi stabilizacije su:
Testiranje reenja tim implementira planove testiranja koji su
kreirani tokom faze planiranja i koji su testirani tokom faze razvoja;
Voenje pilot reenja tim testira pilot reenje sa aktuelnim korisnicima i na realnim scenarijima.
Izlazna dokumenta iz faze stabilizacije su:
Pregled pilot reenja
Gotove verzije:
izvornog koda
skriptova i instalacione dokumentacije
korisnikog help-a i prirunika za obuku
dokumentacije za rukovanje
Testiranje i izvetaj o bagovima
Dokumenti projekta
U toku faze stabilizacije, svaka rola u projektnom timu ima odreene
odgovornosti:
proizvodni menader prati plan izvrenja i lansiranja proizvoda;
program menader prati projekat i uspostavlja prioritete meu
bagovima;
razvojni tim razreava bagove i optimizuje kd;
tim za testiranje testira i izvetava o statusu bagova;
menadment putanja u rad postavlja pilot reenje, planira
uvoenje reenja i vodi obuavanje;
iskustveni korisnici stabilizuju materijale obuavanja, asistencije
i performanse korisnika.
225
Koraci faze stabilizacije su:

konvergencija bagova (bug convergence) je taka u kojoj broj
bagova koji se pronalazi je isti broju bagova koji se razreava. To je
taka u kojoj je vidljiv napredak reenja u odnosu na broj bagova.
Nakon konvergencije bagova, broj bagova treba da nastavi da se
smanjuje sve do nula bagova.
Slika 5.39. Konvergencija bagova [9]
nula bagova (zero-bug) je taka u projektu kada razvojni tim

razrei sve bagove koji su se pojavili u toku testiranja.
Slika 5.40. Nula bagova [9]
faza pred putanja u rad na osnovu povratne informacije od

korisnika, projektni tim nastavlja da poboljava proizvod i razreava
bagove koji su se pojavili u toku pilot projekta.
zlatno putanje je putanje reenja u rad. Zlatno putanje je
odreeno kombinacijom nula defekata i kriterijuma uspenosti.
Bag (bug) ne podrazumeva obavezno greku, ve se moe denisati kao
bilo koja pojava nastala korienjem proizvoda (Slika 5.41). Bagovi treba
226
da se sagledaju i obrade saglasno prioritetima isporuke proizvoda. Upravljanje bagovima (bug management) je proces tretiranja bagova kako bi se
uspostavio eljeni odnos izmeu denisanog nivoa kvaliteta proizvoda u
projektu i kvaliteta proizvoda u realizaciji. Proces praenja bagova (bug
tracking process) izvetava, klasikuje bagove, odreuje prioritete i reava
bagove (Slika 5.42).
Slika 5.41. Pojam baga [2]
Bagovi se mogu klasifkovati na dva standardna naina:

klasikacija prema uticaju (by severity) - meri uticaj baga na proizvod:
Uticaj 1: Pad sistema (system crash) ova vrsta bagova prouzrokuje pad sistema ili gubitak podataka;
Uticaj 2: Glavni problem (major problem) ova vrsta bagova
dovodi do ozbiljnih oteenja u programu, ali ne naruava
sistem;
Uticaj 3: Manji problem (minor problem) ova vrsta bagova
dovodi do naruavanja funkcionalnosti programa;
Uticaj 4: Trivijalni (trivial) beznaajne greke, trivijalne.
klasikacija prema prioritetu (by priority) sortira bagove prema
prioritetu reavanja:
Prioritet 1: Najvei prioritet (highest priority) bagovi klasikovani pod najveim prioritetom podrazumeva da reenje
nije isporuivo;
Prioritet 2: Visoki prioritet (high priority) bagovi klasikovani
pod visokim prioritetom takoe podrazumevaju da reenje nije
spremno za isporuku;
227
Prioritet 3: Srednji prioritet (medium priority) srednji prioritet

bagova ukazuje da je reenje isporuivo;
Prioritet 4: Nizak prioritet (low priority) proizvod je isporuiv
jer su bagovi najnieg prioriteta.
Nivo kvaliteta svake verzije reenja se opisuje kroz klasikaciju
bagova.
Proces testiranja je projektovan na nain da identikuje i ukae na
potencijalne teme koje su od prioriteta za razvoj reenja. Testiranjem se
potvruje da su komponente reenja ispunile planirane ciljeve projekta u
predvienom roku i sa odgovarajuim kvalitetom. Merenje da li je projekat uspean je gotovo nemogue bez neega sa ime bi se merili rezultati
projekta. Kreiranje kriterijuma uspenosti ukljuuje denisanje uslova pod
kojim e predloeno reenje dostii ciljeve. Na primer, Sveukupno zadovoljstvo klijenta sa novim modulom za obradu porudbina na Web sajtu,
bie najmanje 82%. Ponekad se kriterijumi uspenosti nazivaju indikatori
kljunih performansi (Key Performance Indicators - KPI).
Slika 5.42. Proces praenja bagova
Bez sistema za praenje bagova, nemogue je proceniti da li su kriterujmi

nula bagova ispunjeni. Promenljive koje se prate su:
Ponovljivost, repetivnost (repeatability) meri koliko se esto
ponavlja jedan bag. Predstavlja procenat vremena u kome se bag
pojavljuje.
Vidljivost (visibility) meri situaciju koja mora da se dogodi kako bi
se bag pojavio. Na primer, ukoliko se bag dogaa jedino onda kada
korisnik dri Shift taster dok pritiska desnik klik mia i pregleda
File meni, onda je procenat nevidljivosti visok.
228
Uticaj (severity) meri koliki je uticaj baga na reenje, kd ili

korisnike. Na primer, kada se bag dogodi, da li to utie da se operativni sistem ili aplikacija blokiraju ili utie na to da se promeni
piksel boje na meni baru? Da bi mogla da se odredi uticaj bagova,
projektni tim treba da denie listu problematinih situacija. Na
primer, ukoliko sistem prestane da se odaziva i postoji gubitak
podataka onda je promenljiva uticaja 10.
Ove tri promenljive, prethodno spomenute, se procenjuju i pridruuju
svakom pojedinanom bagu kako bi se utvrdila prioritetnost. Prioritet
baga se moe izraunati prema sledeoj formuli:
(PONOVLJIVOST + VIDLJIVOST) * UTICAJ = PRIORITET
Tipini naini reavanja bagova su:

ispravljen (xed) podrazumeva da je developer popravio bag,
testirao prepravku, proverio kd, dodelio prepravci verziju koda
gde je prepravka izvrena i vratio bag testeru koji ga je prijavio;
dupliciran (duplicated) znai da je prijavljeni bag duplikat nekog
drugog baga koji je ve prijavljen u bazi. Novi bag je reen, zatvoren
i pokazuje na originalni bag;
odloen (postponed) znai da se bag odlae za narednu verziju
programa. Ova odluka se donosi ukoliko je tim ogranien vremenom, a bag nije visokog prioriteta;
prema projektu (by design) podrazumeva da je prijavljeno ponaanje
namerno postavljeno jer je traeno u funkcionalnoj specikaciji;
ne reprodukovanje (cant reproduce) developeri ne mogu da nau
postojanje baga ni na jednom nivou;
ne ispravljanje (wont x) znai da developeri nee popraviti bag
u trenutnoj verziji, jer smatraju da nije vredan truda.
Danas, jedan od popularnijih softvera za praenje defekata je BUGZILLA defect tracking software.
229
5.6.1. Voenje pilot reenja

Pilot podrazumeva testiranje reenja u proizvodnom okruenju i njegovo
isprobavanje od strane krajnjih korisnika, osoblja za podrku i instalaciju
reenja. Primarna svrha pilot reenja je da pokae da projekat radi u
proizvodnom okruenju kao to se i oekivalo i da ispunjava organizacione zahteve. Sekundarna svrha je da se prui ansa razvojnom timu da
poboljaju proces razvoja. Pilot nije zavren sve dok tim nije siguran da
je svaka komponenta spremna za uvoenje u sistem.
Pilot je prilika korisnicima da prue povratnu informaciju o tome kako
rade funkcionalnosti reenja to ujedno pomae timu u odreivanju nivoa
podrke koji je neophodan nakon potpunog uvoenja reenja u sistem.
Pilot proces je iterativan. Zapoinje sa zadacima planiranja, kao to su
kreiranje plana pilot reenja i pripremanje korisnika i sajtova, a zatim nastavlja sa implementacijom pilot reenja, procenom rezultata, reavanjem
problema i uvoenjem druge verzije, sve dok se ne postigne cilj i kvalitet
koji ukazuje na spremnost potpunog uvoenja reenja u sistem. Na slici
5.43 se prikazuju koraci planiranja i voenja pilot reenja. Faza stabilizacije
se zavrava onda kada menadment odobri dokument gotove verzije (release readiness) koji sadri rezultate prethodnih zadataka raenih u toku
ove faze.
Slika 5.43. Koraci voenja pilot reenja

230
5.6.2. Faza uvoenja reenja

Tokom faze uvoenja, tim uvodi tehnologiju reenja, komponente, stabilizuje uvoenje, usmerava projekat na operacije i podrku i dobija nalno
odobrenje projekta od klijenta. Glavni zadatak ove faze je pripremanje i
uvoenje reenja. Izlazna dokumentacija u ovoj fazi su:
informacioni sistemi operacija i podrke;
procedure i procesi;
baza znanja i izvetaji;
repozitorijum svih verzija dokumenata, konguracija, skriptova i
koda;
zavrni izvetaj projekta
dokumenta projekta;
nadzor klijenta;
naredni koraci.
Nakon faze stabilizacije, projektni tim moe da migrira na fazu uvoenja
na razne naine. Jedna od opcija je da iskoristi organizacioni operativni tim
na uvoenju reenja. Ukoliko operativni tim uspe da upravlja celokupnim
procesom uvoenja, onda obino predstavnici iz razvojnog tima ostaju na
projektu kako bi umanjili potencijalne probleme tokom transfera. Druga opcija je da se kombinuju lanovi iz svake grupe i da se kreira odvojeni razvojni
tim. Tokom faze uvoenja, odgovornosti pojedinanih rola su sledee:
proizvodni menadment povratne informacije od klijenta; procena;
odobravanje;
program menadment poreenje reenja i cilja; upravljanje stabilizacijom;
razvoj reavanje problema; podrka;
testiranje performanse testiranja; identikovanje, denisanje,
reavanje i izvetavanje o problemima;
menadment putanja reenja upravljanje uvoenjem;
iskustveni korisnik obuavanje; upravljanje rasporedom obuke.
Kompleksnost i duina faze uvoenja e zavisiti od samog projekta. U
toku faze uvoenja neophodno je razmotriti zahteve za hardverom i operativnim sistemom koji ukljuuju servere preduzea, centre podataka, XML
Web servise, klijente (desktop, mobilni).
231
Uvoenje reenja u proizvodno okruenje prolazi kroz nekoliko koraka:

planiranje uvoenja testiraju se, instaliraju i konguriu zika infrastruktura, sistemski i aplikacioni softveri. Projektni tim poboljava
i aurira sledeu dokumentaciju:
dijagrami uvoenja (deployment diagrams);
plan testiranja (test plan);
plan bezbednosti (security plan) - tim osigurava da je svo osoblje
upoznato sa pravilima i standardima bezbednosti;
backup plan;
plan za analiziranje performansi i upotrebe sistema;
plan za rukovanje logovima i drugi administrativni zadaci;
plan oporavka od tete (disaster recovery plan) ta se oekuje
da e se desiti reenju, opremi, osoblju i podacima ukoliko se
teta dogodi;
plan poslovne kontigencije (business contingency plan) tim
utvruje ta e se desiti ukoliko doe do zastoja poslovnih aktivnosti;
informacije o obuavanju tim mora da osigura da je osoblje
adekvatno obueno za odravanje i auriranje reenja;
uvoenje komponenti primeri komponenti su: ruteri, serveri
baza podataka, mail ruteri, serveri za udaljeni pristup (remote access
servers), lokalni ruteri, fajl serveri, klijentske aplikacije i dr. Uvoenje
komponenti podrazumeva izbor odgovarajue strategije uvoenja
(serijsko ili paralelno uvoenje), a zatim i izvravanje uvoenja.
Uvoenje podrazumeva i korienje sistema od strane korisnika.
period zatija zapoinje kada se zavri faza uvoenja. Period
zatija od 15 do 30 dana je neophodan da bi se generisali statistiki
podaci.
transfer projekta podrazumeva prenoenje operacija i funkcija
podrke na osoblje.
zavrne aktivnosti podrazumeva praenje zadovoljstva klijenta,
pripremanje zavrnog izvetaja, zavrni pregled projekta i dobijanje
odobrenja od klijenta.
232
6. Metodologija implementacije ERP reenja
6.1. Proces razvoja ERP sistema

Proces projektovanja gotovog ERP reenja se razlikuje od tradicionalnog
procesa razvoja sistema. Proces razvoja ERP sistema obuhvata planiranje,
analizu zahteva, projektovanje, detaljan dizajn, implementaciju i odravanje.
Planiranje zapoinje sa procenom potreba koje predstavljaju poslovnu
opravdanost kupovine softvera. Procena potreba je veoma bitna usled
investicije u ERP sistem i njegovog uticaja na celokupno poslovanje. Faza
analize zahteva jednog ERP projekta obuhvata odreivanje poslovnih
procesa koji e biti podrani ERP paketom. U fazi projektovanja se uvode
najbolje prakse koje podrava ERP sistem, to povlai reinenjering poslovnih procesa. Ovde se uoava osnovna razlika u odnosu na tradicionalni
pristup razvoja sistema, gde projektanti deniu nove poslovne zahteve i
implementiraju softver prema tim zahtevima. Jedna od osnovnih odluka
u implementaciji ERP paketa je da li da se redizajniraju organizacioni poslovni procesi kako bi odgovarali softveru ili kastomizirati softver prema
organizacionom poslovnim praksama.
PLANIRANJE
Poslovna opravdanost uvoenja ERP reenja obuhvata merljive i nemerljive koristi, kao to su smanjenje zaliha, smanjenje operativnih trokova,
poboljanje procesa, smanjeno vreme ciklusa i dr. Neka tehnoloka i poslovna obrazloenja uvoenja ERP reenja su prikazana u tabeli 6.1.
ANALIZA ZAHTEVA
Aktivnosti analize zahteva ukljuuju analiziranje poslovnih procesa

i odreivanje procesa koji e biti podrani ERP paketom. S obzirom da
kompanija kupuje vendorov pogled najbolje prakse, veoma je vano da
se izabere sistem koji najbolje odgovara organizacionim ciljevima i konkurentnoj strategiji.
233
Tabela 6.1. Obrazloenja za ERP
Veina vendora nudi najbolje prakse za odreene industrije, kao to su

na primer, farmaceutska industrija ili naftna industrija i sl. Proces odabira
najboljeg ERP sistema se vri ekiranjem (selektovanjem) aktivnosti.
Tabela 6.2. Selekcija jednog ERP sistema
234
PROJEKTOVANJE
Kljuno pitanje kod projektovanja ERP sistema je da li izvriti reinenjering ili kastomizaciju. Kod reinenjering pristupa, tim odabira gotovo
komercijalno ERP reenje i redizajnira poslovne procese kako bi bili u
saglasnosti sa paketom. Kod pristupa kastomizacije ili prilagoavanja, tim
odabira komercijalni ERP kako bi ga kastomizirala prema jedinstvenim
potrebama.
Tabela 6.3. Reinenjering vs. kastomizacija
Najlake je instalirati kompletno ERP reenje, jer organizacije mogu

da slede metodologiju koju propisuju vendori i koriste konsultante vendora, koji poseduju specijalizovanu ekspertizu. Ukoliko se ERP reenje
prilagoava organizaciji, tada se vreme i trokovi investirani u projekat,
poveavaju srazmerno rizicima uspene implementacije. Razlog tome je
da se kastomiziran softver ne moe lako integrisati sa novijim verzijama
ERP paketa, koje s vremena na vreme isporuuje vendor.
Pojedine organizacije se opredeljuju za odravanje postojeih sistema
i pridodavanje ERP modula koje podravaju odreene funkcije kao to
su nansijsko raunovodstvo ili CRM i sl. Ovakav vid implementacije u
poreenju sa kompletnom implementacijom ERP reenja je isplativ, ali je
lien funkcionalnosti koje nudi kompletna ERP implementacija. Jedina
prednost ovakvog pristupa je da ne izaziva velike potrese u organizaciji,
jer korisnici sistema ne moraju da usvajaju nove poslovne procese.
Drugi pristup u realizaciji ERP sistema je autsorsing, odnosno da sistem
odrava spoljni vendor. Odluke koje se donose zavise od pouzdanosti i
stabilnosti vendora to ini organizaciju ranjivom.
235
DETALJNI DIZAJN
U fazi detaljnog dizajna projekta, tim odabira modele, procese i informacije koje e biti podrane sistemom. Metodologija najbolje prakse
obuhvata sledee korake:
Izbor primenjivih poslovnih procesa.
Odbacivanje neprimenjivih poslovnih procesa.
Ukoliko se poslovni procesi ne poklapaju sa sistemom, oni slue
kao osnova za reinenjering.
Identikovati one oblasti koje nisu pokrivene od strane najbolje
prakse i koje e zahtevati razvoj kastomizovanih modela.
Detaljni dizajn ukljuuje interaktivno prototipovanje i ukljuenost

korisnika u odreivanju elemenata sistemskog dizajna.
IMPLEMENTACIJA
ERP implementacija obuhvata pitanja konguracije, migracije podataka sa starog sistema na novi sistem, izgradnju interfejsa, implementaciju
izvetaja i pilot testiranje. Kongursanje ERP sistema zahteva da projektni
tim razmotri odreeni broj faktora (tabela 6.4).
Tabela 6.4. Faktore za razmatranje tokom konfigurisanja ERP sistema
Faktori
Podaci
Raspodela
procedura
Transakcije
Stvari koje treba razmotriti

Ko je zaduen za integitet podataka? (centralizovana
odgovornost nasuprot lokalne odgovornosti)
Koji poslovni procesi treba da budu centralizovani?
Koji procesi treba da ostanu pod lokalnom kontrolom?
Da li ERP obezbeuje praenje transakcija?
Da li ERP obezbeuje praenje agregiranih transakcija?
Upravljanje Da li e ERP podrati centralizovano ili lokalno

podacima
upravljanje podacima?
236
6.2. ASAP metodologija implementacije SAP sistema

SAP (Systems, Applications, Products) AG je jedna od najpoznatijih
softverskih kua za proizvodnju ERP sistema, osnovana 1972. u Waldorfu
u Nemakoj, 1992. SAP je predstavio svoj sistem nazvan R/3 koji se bazira
na klijent/server tehnologiji. Poslednjih 10-tak godina, SAP R/3 dominira ERP tritem. R/3 softver omoguava integraciju svih poslovnih operacija kompanije u jedan sveobuhvatan sistem za planiranje, kontrolisanje
i praenje. Na raspolaganju je preko 1000 standardizovanih procesa koji
predstavljaju reenja najbolje poslovne prakse koja odraavaju iskustva,
sugestije i zahteve vodeih kompanija. SAP R/3 sistem obezbeuje integrisani skup poslovnih aplikacija koje pokrivaju kompletan opseg procesa
koji se koriste gotovo u svim poslovanjima. R/3 aplikacije su moduli koji
se mogu samostalno koristiti ili kombinovati sa drugim reenjima.
R/3 sistem nije sektorski orjentisan, ve podrava praktino sve tipove industrije, od diskretne proizvodnje preko procesne industrije,
inenjeringa prema porudbini do serijske proizvodnje. Primeri proizvodnje i prodaje razliitih proizvoda, tj. grupa proizvoda i njihova klasikacija na tipove proizvodnje, prikazani su u tabeli 6.5.
Tabela 6.5. R/3 proizvodi i odgovarajui tip proizvodnje
Postoje dva pristupa uvoenja R/3 sistema:

1. Analiza stanja i detaljno projektovanje R/3 softvera. R/3 je izuzetno veliki, ima puno parametara koje treba postaviti na osnovu
analize stanja. Da bi se na taj nain radilo, zahteva se izuzetno
poznavanje R/3 softvera od strane SAP konsultanata i dobra sistem analiza kod korisnika.
237
SAP obezbeuje ASAP (AcceleratedSAP) metodologiju i alate za

brzo implementiranje R/3 reenja. Ovaj nain prua vie mogunosti za kastomizaciju i prilagoavanje poslovnim procesima korisnika.
2. Korienje predenisanog SAP-ovog reenja za odreeni model proizvodnje. Primeri kako je to uraeno za odreene modele mogu se nai na IDES-u, sistemu za Internet demonstraciju i
evaluaciju (Internet Demonstration and Evaluation System). IDES
predstavlja jednu meunarodnu kompaniju koja se sastoji od
nekoliko odelenja lociranih u razliitim zemljama. Svrha IDES-a
je da pokae sveobuhvatne funkcije R/3 sistema. Meutim, fokus nije na samoj funkcionalnosti, ve na poslovnim procesima i
njihovoj integraciji. Takoe, IDES sadri brojne poslovne scenarije
koji se bave problemima upravljanja visokom inacijom ili razumevanjem integracije elektronskog KANBAN sistema u MRPII
okruenju, just in time proizvodnje i sl. IDES-om upravlja SAP
koji redovno aurira njegove podatke.
SAP R/3 sistem je razvijen tako da podri distribuiranu vieslojnu klijent/server arhitekturu. Postoji jasna razlika izmeu prezentacionog, aplikacionog, sloja baze podataka i Internet sloja. Prezentacioni sloj moe da
koristi brojne razliite grako korisnike interfejse. SAP je razvio sopstveni softver korisnikog interfejsa SAPGUI koji pokriva 20 razliitih jezika, ali takoe se mogu koristiti i Microsoft Windows ili Internet browser
interfejsi. Aplikacioni serveri sadre kompletnu logiku poslovnih procesa R/3 aplikacija. Ovi aplikacioni serveri se mogu aktivirati na Windows
NT sistemima, UNIX operativnim sistemima i AS/400 sistemima. Sloj
baze podataka upravlja komponentama aplikacije R/3 sistema i podacima
preduzea. Podravaju IBM DB2, Informix On-line, Microsoft SQL Server
i Oracle relacione sisteme za upravljanje bazama podataka. Internet sloj
omoguava pristup R/3 sistemu putem Interneta ili intraneta.
R/3 sistemi nude i standardne interfejse koje omoguavaju integraciju
R/3 sa aplikacijama razvijenih od strane drugih vendora. Ovi objektnoorijentisani interfejsi se nazivaju BAPI (Business Application Programming Interfaces) koji su kompatibilni sa Microsoft-ovim DCOM-om (Distributed Component Object Model) i OMG-ovom CORBA-om (Common
Object Request Broker Architecture).
SAP je razvio sopstveni programski jezik nazvan ABAP (Advanced
Business Application Programming) koji predstavlja jezik etvrte genera238
cije. R/3 takoe nudi kompletno razvojno okruenje pomou koga developeri mogu da modikuju postojei SAP kd ili da razvijaju sopstvene
funkcije, prave izvetaje ili ak da razvijaju kompletne transakcione sisteme u okviru SAP framework-a.
Vizija SAP-a je da nastavi da obezbeuje kompletna, integrisana
reenja. Svoju Internet strategiju, SAP je realizovao razvijanjem reenja
mySAP.com. Portali mySAP.com omoguavaju korisnicima svih softverskih reenja da pristupaju svojim aplikacijama i R/3 bazama podataka putem Interneta i Web pretraivaa sa svog desktop ili portabilnog ureaja.
Reenje mySAP.com je integrisan sa R/3 i predstavlja interfejs za sve SAP
proizvode: kolaborativne, front oce i back oce. Na primer, prodavac na
terenu moe da popuni elektronsku formu porudbine na svom laptop
raunaru, koja e zatim biti prevedena kao ulaz za R/3 sistem. Uvoenjem
SAP reenja u organizacije, osigurava se dobijanje meunarodnih sertikata za kvalitet to otvara put na meunarodno trite.
Projekat uvoenja SAP-a je izrazito veliki projekat, koji ne traje kratko,
zahteva velika nansijska ulaganja i ima veliki uticaj na poslovanje organizacije koja ga uvodi. Tekoe pri implementaciji SAP-a proizilaze
upravo iz injenice da uspeh implementacije zavisi od tanog mapiranja
svih poslovnih procesa organizacije u SAP sistem. Ovo povlai za sobom
tanu konguraciju svih traenih procesa od samog poetka projekta. SAP
je vrlo eksibilan, ali da bi se izvrila precizna konguracija nije dovoljno
poznavati samo procese organizacije, ve je potrebno dobro poznavati i
SAP funkcionalnosti.
Accelerated ASAP (Ubrzani SAP) je metodologija brze implementacije
koju je 1996. godine razvio SAP. ASAP nudi brojne alate i pomo pri
implementaciji procesa. Prednosti ove metodologije su brza implementacija, optimalna iskorienost resursa i budeta i poboljanje kvaliteta.
Meutim, metodologija nee reiti sve probleme, jer svaka organizacija
ima posebne zahteve i na svaku SAP implementaciju e uticati organizaciona struktura.
Koraci ASAP metodologije su (Slika 6.1): priprema projekta, analiza
zahteva, realizacija i priprema za produkciju, konana priprema, putanje
u rad.
239
Slika 6.1. ASAP metodologija implementacije SAP reenja
PRIPREMA PROJEKTA
Nakon pozitivne poslovne opravdanosti ulaganja u ERP sistem, pristupa se denisanju cilja, domena i organizacije projekta, zatim denie
se strategija implementacije i dunosti kljunih korisnika. Na slici 6.2 se
prikazuje plan prve faze projekta na primeru jedne organizacije koja se
odluila za uvoenje SAP reenja, u okviru koje je faza pripreme trajala
170 dana.
Slika 6.2. Faze projekta
240
Primer projektne organizacije je prikazan na slici 6.3.
Slika 6.3. Primer projektne organizacije za implementaciju SAP modula [3]
Analiza zahteva
Svrha ove faze je kreiranje dokumenata specikacije zahteva (tzv. Business Blueprint) ime se dokumentuju svi zahtevi poslovnih procesa organizacije. Tim dokumentom postie se zajedniko razumevanje izvoenja
poslova unutar SAP sistema. Primer terminskog plana faze specikacije
zahteva je prikazan na slici 6.4.
241
Slika 6.4. Terminski plan faze Specikacije zahteva

U ovoj fazi zadatak menadmenta projekta je identikovanje nastalih
promena izmeu poslovnih procesa i organizacione strukture i analiza
potencijalnih rizika koji su utveni u prvoj fazi. Zadatak menadmenta
promene procesa je upravljanje problemima promena kako bi se optimizovali procesi u organizaciji. Kreira se mapa poslovnih uticaja koja se koristi
kao polazna taka u upravljanju promenama procesa.
Sledei korak je da se denie i dokumentuje tehniki dizajn celokupnog
sistema, a pomo za ovaj posao trai se od partnera za hardver. Primer
arhitekture SAP sistema u jednoj organizaciji je troslojna (Slika 6.5).
Slika 6.5. SAP R/3 arhitektura
242
U ovoj fazi se vri i obuka korisnika kako bi korisnici razumeli SAP

funkcionalnosti i postigli potrebno tehniko znanje ime je omoguen
poetak usklaivanja zahteva i SAP funkcionalnosti.
Dokument specikacije poslovnih zahteva za poslove na primer nansijskog raunovodstva bi obuhvatao sledee denicije:
Svrha i ocena dokumenta
Povezanost sa drugim dokumentima (Proces, Dodela konta, Cena)
Zakljuak menadmenta
Konceptualni dizajn
Organizaciona struktura
Stavke
Standardni procesi
Izvetavanje
Korisnike uloge i autorizacije
Prilagoavanje
Razvoj programa
Test prihvatanja (Business Acceptance Test)
Putanje u rad (Going live)
Otvorene teme (Open issue)
Problemi, pretpostavke i rizici
Potpisi
Dokument specikacije zahteva potpisuju svi lanovi tima i njime se
potvruje dizajn procesa, organizaciona struktura, osnovni cilj, tehniki
dizajn i sistemsko okruenje.
Na kraju druge faze sprovodi se provera kvaliteta i SAP preporuuje
sledeu listu provere aktivnosti:
Provera statusa projektnog tima i odravanje sastanaka upravljakog
odbora;
Provera da li se uspeno odrala obuka projektnog tima;
Overa da su se odravale aktivnosti izgradnje tima (team building);
Osiguranje uloga i odgovornosti korisnika;
Potvrda razvoja tehnikog dizajna;
243
Provera postavki okruenja razvojnog sistema;

Overa da su tano postavljene funkcije administriranja sistema;
Provera inicijalne konguracije;
Provera da je dokument specikacije zahteva potpun i postpisan.
REALIZACIJA I PRIPREMA ZA PRODUKCIJU
U fazi realizacije sprovodi se implementacija poslovnih i procesnih
zahteva baziranih na dokumentu specikacije zahteva i putanja sistema
u stvarni rad. U ovoj fazi radi se konguracija sistema koja se sastoji iz
dva dela i to osnovne i konane konguracije. Osnovna konguracija se
odvija sekvencionalno kroz cikluse, sve dok se problemi ne ree i sve dok
kongurisani sistem nije spreman za konani test integracije.
Sistem se kongurie i testira na osnovu liste glavnih poslovnih procesa
(Business Process Master List). Nakon konguracije sistema sprovodi se
test integracije koji predstavlja skup najvanijih poslovnih scenarija koji
osiguravaju da se celokupni sistem ukljuujui i eksterne komponente,
potpuno integrie kako bi se zadovoljila specikacija poslovnih zahteva.
Glavni fokus je usmeren na testiranje SAP-a sa svim programima prenosa podataka iz drugih sistema na izvetaje, sve izlazne obrasce i prenose
matinih slogova od drugih klijenata.
U fazi realizacije postoje mnogi tehniki zadaci koji moraju da se
obavljaju paralelno sa konguracijom, kao to su razvijanje poslovnog
toka (workow), izrada programa prenosa iz drugih sistema ili modula,
kodiranje, poboljanje, prilagoavanje izvetaja i obrazaca, kreiranje uloga
ili autorizacije korisnika i arhiviranje.
Izlazni dokumenti iz ove faze su 4 glavne liste koje deniu poslovni
scenario i SAP transakcije:
Procedure poslovnih procesa koje opisuju SAP transakcije i koriste
se za testiranje i dokumentaciju;
Konguracija i plan testiranja koji odreuju kako e se sprovoditi
konguracija i kako e biti testirana;
Razvijanje programa tako da se omogue dodatni detalji eksternih
zahteva za programiranjem;
Kreiranje materijala za obuku krajnjih korisnika.
244
Konana priprema
U fazi konane pripreme usklauju se sve aktivnosti iz prethodnih
faza, sprovodi se testiranje, obuka korisnika, upravljanje sistemom i
reavaju se bitna otvorena pitanja. U ovoj fazi SAP eksperti proveravaju
konguraciju pojedinanih komponenti sistema i daju korisne savete kako
optimizovati sistem. Glavni cilj je proveriti da li je sistem spreman za rad
u produkciji.
PUTANJE U RAD
Putanje sistema u rad i podrka sistemu podrazumeva prenos rada na
produkciju. Program podrke je vrlo kritian, a naroito u prvih nekoliko
nedelja stvarnog rada. Pruanje usluga korisnicima (tzv. service desk),
njegovo praenje i podeavanje zavisi od povratnih informacija krajnjih
korisnika. Odgovornost IT odelenja se svodi na implementaciju funkcionalnih zahteva poslovanja, pruanje neophodne podrke pri testiranju i
funkcionisanje svih SAP sistema. Poboljanje poslovnih procesa, merenjem
kljunih indikatora performansi sistema (KPIs Key Performance Indicators), nije zavreno nakon to je sistem puten u rad, ve se ta aktivnost
nastavlja.
Svi zahtevi nakon zatvaranja projekta se sprovode kroz menadment
promena koji se odvija u razvojnom sistemu, zatim se testira i nakon prihvatanja rezultata testiranja, prenosi na sistem produkcije.
Cena projekta implementacije SAP reenja se sastoji iz 4 dela: licence,
konsalting, hardver i odravanje softvera u iznosu od 17% na ukupnu
vrednost licence. Prema do sada uraenim analizama 77% projekta implementacije SAP-a je zavreno za manje od godinu dana., a ulaganje se
u proseku vraa u periodu izmeu 18 i 24 meseca.
245
Rezime
1. Metodologije obezbeuju jedan konzistentan i reproduktivni prilaz koji
moe biti primenjen na sve projekte, one smanjuju rizik od greaka i
izdaju kompletnu i konzistentnu dokumentaciju za trenutne i budue
projekte.
2. Modeliranje je opti pristup u svim inenjerskim disciplinama i predstavlja projektovanje softverskih aplikacija pre njihovog kodiranja
odnosno programiranja. U oblasti razvoja softvera, modeliranje se
moe izvoditi klasinim (funkcionalnim) pristupom denisanjem
modela podataka i modela procesa ili objektno-orijentisanim pristupom
korienjem UML-a.
3. Modeliranje procesa je tehnika koja organizuje i dokumentuje procese
sistema i/ili implementira logiku, politike i procedure sistema. Neki od
modela procesa sistemske analize su dijagram toka podataka (Data
Flow Diagram, krae DFD), IDEF0 metodologija i dr.
4. Model podataka (denisan i kao Model Objekti-Veze - MOV ili E-R
Entity-Relationship model), preko skupa podataka i njihovih meusobnih
veza, predstavlja stanje sistema u jednom trenutku vremena. Postoji
nekoliko notacija modela objekti-veze. Mnogi su imenovani prema
njihovim tvorcima (npr., Chen, Martin, Bachman, Merise) ili prema
objavljenim standardima (npr., IDEF1X).
5. Objektno-orijentisana analiza zahteva da se identikuju objekti, njihovi
atributi, ponaanja i relacije koji podravaju zadate poslovne zahteve
sistema. Faze obavljanja objektno-orijentisane analize su: modelovanje funkcija sistema sluajevima korienja, modelovanje aktivnosti
sluajeva korienja upotrebom dijagrama aktivnosti i pronalaenje i
identikacija poslovnih objekata i njihovih relacija.
6. Jedna od reprezentativnijih metodologija razvoja poslovnih reenja je
Microsoft Solution Framework (MSF) procesni model koji opisuje generalne sekvence aktivnosti za izgradnju i uvoenje poslovnih reenja,
kombinovanjem najboljih principa modela vodopada i spiralnog modela. MSF obuhvata discipline za upravljanje timovima, procesima,
tehnologijom i rizicima, tj. elementima sa kojima se projekti najee
susreu.
246
7. Proces implementacije gotovih ERP reenja se razlikuje od tradicionalnog procesa razvoja sistema. Proces razvoja ERP sistema obuhvata
planiranje, analizu zahteva, projektovanje, detaljan dizajn, implementaciju i odravanje. Planiranje zapoinje sa procenom potreba koje
predstavljaju poslovnu opravdanost kupovine softvera. Procena potreba je veoma bitna usled investicije u ERP sistem i njegovog uticaja
na celokupno poslovanje. Faza analize zahteva jednog ERP projekta
obuhvata odreivanje poslovnih procesa koji e biti podrani ERP
paketom. U fazi projektovanja se uvode najbolje prakse koje podrava
ERP sistem, to povlai reinenjering poslovnih procesa. Ovde se uoava
osnovna razlika u odnosu na tradicionalni pristup razvoja sistema, gde
projektanti deniu nove poslovne zahteve i implementiraju softver
prema tim zahtevima. Jedna od osnovnih odluka u implementaciji ERP
paketa je da li da se redizajniraju organizacioni poslovni procesi kako
bi odgovarali softveru ili kastomizirati softver prema organizacionom
poslovnim praksama.
8. Accelerated ASAP (Ubrzani SAP) je metodologija brze implementacije
koju je razvila kompanija SAP AG. ASAP nudi brojne alate i pomo pri
implementaciji procesa. Prednosti ove metodologije su brza implementacija, optimalna iskorienost resursa i budeta i poboljanje kvaliteta.
Koraci implementacije su priprema projekta, analiza zahteva, realizacija
i priprema za produkciju, konana priprema i putanje u rad.

1.
2.
3.
4.
Zato su vane metodologije kod razvoja informacionih sistema?

Koja je bitna razlika izmeu strukturne i objektno-orijentisane analize?
Deniite termin polimorzam i navedite primer.
Kako implementacija ERP reenja doprinosi reinenjeringu poslovnih
procesa?
5. emu slui matrica kompromisa projekta (project tradeo matrix)
koju predlae MSF okvir?
6. U okviru dokumenta procene rizika kako se izraunava mera izloenosti riziku?
7. Koje tehnike za ocenu ekonomske izvodljivosti poznajete i ukratko ih
obrazloite?
247
8. Koja rola prema MSF okviru kreira funkcionalnu specikaciju poslovnog reenja?
9. Koji dijagrami se iscrtavaju kod zikog dizajna poslovnog reenja?
10. ta je to arhitektura aplikacije i kakvu ulogu imaju kod razvoja informacionih sistema?
11. Koji su glavni zadaci faze stabilizacije reenja?
12. Kako se tradicionalni sistemi ivotnog ciklusa razvoja sistema razlikuju od projektovanja i implementacije ERP sistema?
Reference
[1] Ambler, S.W., Introduction to the Diagrams of UML 2.0, http://www.
agilemodeling.com/essays/umlDiagrams.htm
[2] Atanasijevi, V., Bug Management best practice, Sinergija, 2003.
[3] upi, A., Strategija uspjenog uvoenja sustava za planiranje resursa
poduzea, magistarski rad, Ekonomski fakultet Zagreb, Sveuilite u
Zagrebu, 2005.
[4] Eckel, B., Misliti na Javi, CET, Beograd, 2002.
[5] Hoer, J.S., M.B. Prescott, F.R. McFadden, Modern Database Management, sedmo izdanje, Prentice Hall, New Jersey, 2005.
[6] IBM, DB2 Family Fundamentals, Student Notebook, International Business Machines Corporation, 2005.
[7] IEEE, IEEE Standard Conceptual Modelling Language Syntax and Semantics for IDEF1X, eeexplore.ieee.org/iel5/6170/16492/00761916.pdf.
[8] Lazarevi, B., Z. Marjanovi, N. Anii, S. Babarogi. Baze podataka,
Fakultet organizacionih nauka, Beogradski univerzitet, Beograd, 2003.
[9] Microsoft, Analyzing Requirements and Dening Microsoft. NET Solution Architectures, Workbook, Microsoft Corporation, 2003.
[10] Njegu, A., A. Veljovi, Internet poslovno programiranje, Megatrend
univerzitet, Beograd, 2004.
[11] Schildt, H., Java 2: Kompletan prirunik, etvrto izdanje, Mikro knjiga,
Beograd, 2001.
[12] UML standardi (www.rational.com i www.omg.com).
[13] Veljovi., A. i A. Njegu, Osnove relacionih i analitikih baza podataka,
Megatrend univerzitet, Beograd, 2004.
248
DEO III:
ANALITIKI POSLOVNI
INFORMACIONI SISTEMI
CILJEVI POGLAVLJA
Dananji poslovni informacioni sistemi ne mogu da se zamisle bez
ugraene poslovne inteligencije. Vodei IT analitiari predviaju da e se
u narednih pet godina softverska industrija fokusirati na poslovnu inteligenciju (Business Intelligence BI) i analitiku, usled potrebe organizacija
za donoenjem odluka na svim nivoima menadmenta. Operaciona BI
reenja uvode inteligenciju u sve poslovne procese organizacije pruajui
pravu informaciju, pravim ljudima u pravo vreme. Dananji izazov za
organizacije nije samo pruanje informacija ljudima koji vode posao, ve
omoguavanje svim entitetima u preduzeu da pristupaju i sarauju nad
istim informacijama, kako i kada se za to javi potreba.
U ovom delu se prouavaju delovi poslovne inteligencije i to Data
warehouse, OLAP sistemi i data mining i na kraju se navode koraci razvoja
jednog BI reenja.
Nakon prouavanja ovog poglavlja znaete da:
objasnite razliku izmeu OLTP i OLAP alata;
objasnite pojmove: data mart, data warehouse, OLAP i data mining;
napravite dimenzioni model putem eme zvezda;
sagledate funkcionalnosti OLAP sistema i kreirate kocku nad
eljenim podacima;
objasnite tipove arhitekture OLAP sistema;
objasnite tehnike data mining-a;
objasnite korake razvoja jednog BI reenja.
249
7. Skladite podataka
Kompanija svakodnevno prikuplja velike koliine podataka. Ti podaci su

esto sirove injenice koje odraavaju tekue stanje poslovanja. Prevoenje
tih sirovih podataka u dragocene informacije je kljuni analitiki proces,
na osnovu kojih kompanija donosi poslovne i operativne odluke. Naredni
scenario prikazuje razliku izmeu sirovih i izvedenih podataka.
SCENARIO:
Sirovi podaci: Finansijska institucija prikuplja podatke o svim raunima
i uteevinama klijenata. Sirov podatak na primer, moe pokazati da je
Sefan M. podigao 50 evra jutros, sa svog rauna u Amsterdamu.
Izvedene informacije: Stefan ivi u Beogradu, ali u proteklih pet meseci,
Stefan je podizao novac u Londonu, Oslo-u, Stockolm-u, to dovodi do
zakljuka da on esto putuje po Evropi. S toga bi on moda bio zainteresovan za specijalnu kreditnu karticu koji mu omoguava neogranien pristup
svom raunu u 16 razliitih zemalja uz odgovarajuu godinju lanarinu.
Pitanja koja se postavljaju nakon ove analize su: Koji je prosean dnevni
bilans njegovog rauna?, Za koje usluge bi bio zainteresovan?
Nakon to su se uvidele vrednosti poslovne analize, zahtevi za podacima i informacijama postaju sve brojnije i uestalije. Izlaenje u susret
ovim zahtevima moe biti veoma kompleksan zadatak, jer je neophodno
pretraivati ogromne koliine prikupljenih izvora podataka, konsolidovati
ih, analizirati i distribuirati informacije drugim lanovima organizacije.
Da bi izala u susret ovim zahtevima, kompanija obino implementira
sisteme za podrku odluivanju kako bi obezbedila podatke i informacije koji
se mogu koristiti za obavljanje poslovne analize. Investicija u ove sisteme je
obino veoma velika, naroito ako se uzme u obzir vreme implementacije,
trokovi i napor. Povratak investicija (ROI) odslikava koliko dobro sistemi
za podrku odluivanju mogu da zadovolje potrebe poslovanja.
Kompanija moe imati jedan ili vie operacionih sistema koji obavljaju
osnovne poslovne procese. Ovi sistemi se mogu nalaziti na odvojenim
250
serverima i ak razliitim mreama. Te operacione sisteme nazivamo OLTP

(On-line transaction processing) koji prikupljaju transakcije poslovanja i
snabdevaju skladite podataka (data warehouse) sa podacima.
Karakteristike OLTP sistema su:
obrauju poslovne transakcije u realnom vremenu;
sadre strukture podataka optimizovane za unoenje i izmenu
podataka;
obezbeuju ograniene sposobnosti za podrku odluivanju (izvetaji
se sastoje od tekuih podataka).
Primeri OLTP sistema su: aplikacije praenja porudbina, aplikacije
pruanja usluga klijentima (npr., otvaranje rauna), bankarske funkcije
(npr, krediti) i dr.
Sistem skladita podataka (Data warehouse DW) sadri komponente
koje pomeraju podatke sa izvornih sistema ka korisnicima koji ele da vre
analize podataka. Primarna funkcija sistema skladita podataka je da prui
podrku organizaciji u obavljanju poslovne analize. Koncept skladitenja
(warehousing) podrazumeva skladitenje agregiranih, ekstrahovanih i
ltriranih podataka u meta baze, koje omoguavaju slojevit, multidimenzionalni pristup podacima, kakav je potreban za donoenje odluka najvieg
stratekog nivoa.
Skladitenje podataka (Data Warehousing) je proces integracije
podataka u jedan repozitorijum iz kojeg krajnji korisnici mogu sprovoditi ad-hock analize podataka i praviti izvetaje. Skladite podataka
je analitika baza podataka namenjena samo za itanje i koristi se kao
osnova sistema za podrku odluivanju.
Skladite podataka obezbeuje podatke za procese poslovne analize,
integrie podatke sa heterogenih sistema i skladiti podatke u zikim
strukturama koje su optimizovane za analizu podataka. Skladite podataka je informaciona baza podataka dizajnirana za podrku jedne ili vie
klasa analitikih zadataka, kao to su nadgledanje i izvetavanje, analiza i
dijagnoza, simulacija i planiranje.
Karakteristike skladita podataka su:
Organizacija - podaci su organizovani po predmetu i sadre relevantne informacije za podrku odluivanju.
251
Konzistentnost - podaci u razliitim operacionim bazama podataka se drugaije ifriraju. U skladitu e ti podaci biti ifrovani na
konzistentan nain.
Vremenski podaci - podaci se uvaju mnogo godina kako bi se iskoristili za praenje trendova, prognoza i vremensko poreenje.
Multidimenzionalnost - obino skladite podataka koristi multidimenzionalnu strukturu.
Web-zasnovanost u dananje vreme skladite podataka je dizajnirano tako da obezbedi jedno ekasno okruenje za Web aplikacije.
Sistem skladita podataka sadri mnoge komponente koje prenose
podatke sa izvornih sistema do korisnika koji izvravaju analizu podataka.
Komponente sistema skladita podataka su (Slika 7.1):
Izvori podataka Izvorni sistemi su operacioni sistemi, npr. OLTP
sistemi koji mogu biti relacioni.
Oblast za pripremu podataka podrazumeva skup procesa
koji isti, transformie, povezuje i priprema izvorne podatke za
korienje u DW. Podaci se transformiu u konzistente formate.
Oblast za pripremu podataka se nalazi na jednom ili nekoliko
raunara, ne mora da bude zasnovana na relacionoj tehnologiji i
ne podrava korisnike izvetaje.
Data Mart je podskup DW koji sadri podatke specine za
odreenu poslovnu oblast kao to su nansije ili analiza klijenata.
Data mart-ovi mogu biti ukljueni u DW, mogu se izgraditi u
relacionim ili OLAP bazama podataka i mogu da sadre detaljne ili
sumarne podatke koje se mogu ili ne, deliti kroz data mart-ove.
Data Warehouse moe se denisati i kao virtuelna unija data
mart-ova sa integrisanim informacijama koje su deljive kroz data
mart-ove ili kao centralizovano, integrisano skladite podataka
koje obezbeuje podatke data mart-ovima.
252
Slika 7.1. Komponente DW sistema
7.1. Razvoj skladita podataka

Za razliku od transakcionih sistema (OLTP), koji su orjentisani poslovnim
procesima, skladita podataka su subjektno orjentisana, to znai da su
fokusirana na subjekte u poslovnim procesima, kao to su kupci, zaposleni
i dobavljai. Integrisanost podataka u skladitima podataka obezbeuje da
se podaci predstavljaju u konzistentnim formatima korienjem konvencija
pri zadavanju imena i ogranienja nad domenima, atributima i merama.
Podaci u skladitima podataka su vremenski zavisni, to znai da je svaki
podatak koji se nalazi u skladitu podataka u vezi sa nekim vremenskim
trenutkom. Na kraju, podaci u skladitima podataka su nepromenljivi,
tj. im se neki podatak upie u skladite podataka, mogue mu je samo
pristupati. Na slici 7.2 su prikazani svi elementi potrebni za razvoj skladita
podataka.
Pri izgradnji skladita podataka najbitniji su sami podaci, a ne poslovni
procesi i funkcije, kao to je to sluaj sa transakcionim sistemima. Baze
podataka namenjene sistemima za podrku odluivanju mogu biti veoma
velike (terabajtne), pri emu neke tabele mogu sadrati i gigabajt podataka.
Zato se veliina baze podataka mora uzeti u obzir pri planiranju skladita
podataka.
253
Za razvoj skladita podataka potrebno je:

1. izvriti analizu izvora podataka
a. prikupljanje zahteva;
b. planiranje skladita podataka;
c. izbor tehnike analize podataka.
2. pripremiti podatake
a. ekstrakcija i ienje podataka,
b. transformacija podataka.
3. izgraditi skladite podataka.
a. denormalizacija podataka,
b. denisanje hijerarhija,
c. kreiranje agregacija,
d. kreiranje zikog modela,
e. generisanje baze podataka,
f. uitavanje podataka.
Slika 7.2. DW i OLAP
254
Dimenziono modeliranje
Dimenziono modeliranje je tehnika logikog dizajna iji je cilj prezentacija podataka u obliku koji obezbeuje visoke performanse sistema radi
vrenja analize podataka. U dimenzionom modeliranju, strukture podataka
su tako organizovane da opisuju mere i dimenzije. Mere su numeriki
podaci smeteni u centralnoj, takozvanoj tabeli injenica (fakt tabela).
Mere predstavljaju analizirane vrednosti, kao to su jedinica prodaje ili
broj zaposlenih. Dimenzije su standardni poslovni parametri koji deniu
svaku transakciju.
Osnovu za izradu dimenzionog modela predstavljaju meta podaci,
na osnovu kojih se vri denisanje hijerarhija, elemenata i atributa, normalizacija i denormalizacija i denisanje agregacija. Dimenzione tabele
sadre opisne tekstualne informacije. Svaka dimenziona tabela ima svoj
primarni klju koji predstavlja kolonu ili grupu kolona u tabeli iji sadraj
jedinstveno identikuje zapise, a svi oni uestvuju u stvaranju primarnog
kljua tabele injenica. Tabele injenica sadre podatke koji su, najee,
numerikog tipa i mogu sadrati veliki broj zapisa. Fizika arhitektura dimenzionog modela je ema zvezde. Na slici 7.3 se prikazuje ema zvezde
kroz primer.
Slika 7.3. ema zvezde

255
Pri dizajniranju kladita podataka najee se koristi ema zvezde. Ona

se sastoji od relativno malog broja tabela sa dobro denisanim vezama.
ema zvezde polako postaje standard za izradu skladita podataka zbog
svojih prednosti u odnosu na ostale relacione strukture:
obezbeuje krae vreme odziva na upit, jer se smanjuje broj zikih
veza izmeu tabela;
model je jednostavan i lako se mogu vriti modikacije;
pojednostavljuje razumevanje i navigaciju meta podataka;
odravanje je relativno jednostavno;
proiruje skup alata koji se mogu koristiti za rad sa podacima.
Osnovna karakteristika eme zvezde jeste da su dimenzione tabele denormalizovane. Denormalizacija je pristup gde se podaci u bazi podataka
ponavljaju zbog pojednostavljenja dizajna i karakteristika. Ovim postupkom
se smanjuje broj potrebnih veza koje se moraju obraditi zadavanjem upita.
Time se direktno utie na poboljanje performansi sistema, jer to je manji
broj veza, to sistem bre nalazi traene podatke. Primer normalizovane i
denormalizovane prezentacije podataka dat je na sledeoj slici.
Slika 7.4. Razliiti naini prezentacije podataka
Dimenzije veoma esto mogu biti organizovane u hijerarhiji. Svaki

hijerarhijski nivo se nastavlja sa nekim drugim hijerarhijskim nivoom. Na
256
primer, unutar vremenske dimenzije, dani se nastavljaju na nedelje, koji se

nastavljaju na kvartale itd. Za dimenziju proizvoda vezuje se proizvodna
grupa, koja se nastavlja na proizvodne vrste.
Slika 7.5. Primer hijerarhije proizvoda
Dimenzioni elementi su specijalna kategorija podataka, koja predstavlja

odreeni nivo u dimenzionoj hijerarhiji. Za svaki hijerarhijski nivo postoji
po jedan dimenzioni element. Na primer, kod dimenzije proizvod, mogu
postojati tri dimenziona elementa: prozvod, grupa i vrsta proizvoda. U
ovom modelu moemo rei da dimenzioni element proizvod predstavlja
najnii hijerarhijski nivo u dimenziji proizvod, dok Kategorija proizvoda
predstavlja najvii nivo (Slika 7.5).
Posmatranje podataka iz razliitih, ali blisko povezanih perspektiva
omoguava da korisnik analizira podatke na razliitim nivoima detalja.
Postupak prelaska sa nivoa sa manjim brojem detalja na nivo sa veim
brojem detalja naziva se sputanje u dubinu (drill down) i predstavlja zahtev
korisnika da mu se prikae vie detalja. Postupak prelaska sa nivoa sa veim
brojem detalja na nivo sa manjim brojem detalja, na tzv. sumarne podatke,
naziva se dizanje navie (drill up). Na primer, upit bi mogao prezentovati
prodaju u odnosu na neke regione. Poto pronaemo vrh prodaje u nekom
regionu, sputamo se nanie da bi smo saznali kako se prodaja odvija po
optinama. Na primer, geografski podaci vezani za prodaju mogli bi se
organizovati u sledeu hijerarhiju:
SVET
KONTINENT
DRAVA
OBLAST
GRAD
OPTINA
Pored operacija drill down i drill up, postoji i operacija drill across,
koja se koristi za povezivanje dve ili vie injeninih tabela na istom nivou
hijerarhije.
257
Dobro dizajnirana ema zvezde mora obezbediti postojanje razliitih

nivoa detalja, tj. hijerarhija.
Bitan element kod dimenzionog modeliranja je i kreiranje agregiranih
atributa. Agregacija je proces skupljanja injeninih podataka po unapred
denisanim atributima. Na primer, tipini korisnik e esto postaviti
zahtev da mu se prikae ukupna prodaja za ceo mesec. Ovaj zahtev bi
se u bazi podataka interpretirao kao potreba da se saberu svi podaci o
dnevnoj prodaji u toku odreenog meseca. Ako bi, na primer, tokom jednog dana postojalo 1000 transakcija u svakoj od 1000 prodavnica, onda
bi ovaj upit morao da obradi 30 miliona redova da bi se dobio odgovor.
Ovakav upit bi znatno troio sve raspoloive resurse. Za podatke kojima
se ee pristupa poeljno je izvriti sumiranje. Time se omoguava da
se ve postojei sumarni podaci mogu odmah koristiti, ime se znatno
smanjuje vreme odziva na upit koji treba da obradi te sumarne podatke.
Na primer, ako bi postojala tabela u kojoj bi se uvali sumarni podaci o
prodaji za svaku od 1000 prodavnica, onda bi upit o ukupnoj prodaji za
ceo mesec morao da obradi 1000 redova. Prema tome, postojanje tabele
sa sumarnim podacima, u ovom primeru, smanjuje potrebu obrade 30
miliona redova podataka.
Glavni razlozi kreiranja agregacija su da se poboljaju performanse
upita, tj. da se smanji vreme odziva na upit, kao i da se smanji broj resursa
potrebnih za izvrenje upita. Jedini problem je to se upotrebom agregacija
poveava sama baza podataka.
7.2. Primena skladita podataka

Primena skladita podataka je irokog dijapazona, poev od dravnih
organa, zdravstva i obrazovanja, pa do nansija, prodaje, marketinga,
nabavke i proizvodnje. Primena skladita podataka u nansijama vezana
je za, npr.:
izvetaj o protoku novca po grupama proizvoda i organizacionim
jedinicama koji omoguava analizu prihoda i trokova po velikom
broju parametara;
detaljnu analizu prota, multidimenzione izvetaje po kategorijama
protnih i trokovnih centara;
izradu bilansnih rauna;
izradu sumarnih izvetaja o kljunim nansijskim parametrima.
258
Primena skladita podataka u marketingu vezana je za izradu stratekih

marketinkih analiza koje se implementiraju putem multidimenzionih
izvetaja, sa detaljima o prodaji viskoprotnih proizvoda i praenjem po
vremenu, regionima, distributerima, sektorima potronje i dr. Mogunost
slobodnog izvlaenja sumarnih izvetaja i zalaenja u detalje u podrujima
koja ne ispunjavaju oekivanja, daje sektoru marketinga uvid u promene
na tritu. Kako su marketinke kampanje skupe, arhiviranje podataka o
tritu daje odgovor na pitanje koji je segment trita reagovao, preko kojih
kanala, na kom geografskom podruju i preko kojih medija. Ovi podaci su
od neprocenjivog znaaja za organizovanje narednih kampanja.
Primena skladita podataka u prodaji vezana je za analizu prodaje i
davanje odgovora na pitanja kao to su:
Koji proizvod donosi najvei prot?
Koji kupci kupuju najprotabilnije proizvode? i sl.
Primena multidimenzionih izvetaja dovodi do uoavanja Pareto principa1, pokazujui odnos izmeu proizvoda, profatibilnosti i geografske
distribucije (npr. 20% proizvoda donose 80% prota). Precizna analiza
moe biti osnova za stimulaciju prodavaca (stimulacija po ostvarenom
protu, a ne po prihodu) i za planiranje prodaje.
Primena skladita podataka u nabavci veoma je vana jer nabavka
odreuje protabilnost preduzea na vie naina. Pre svega, to su trokovi
materijala, praenje odnosa sa dobavljaima kroz vreme. Jo su vee
mogunosti upravljanja zalihama, u smislu oslobaanja obrtnog kapitala
zarobljenog u zalihama. Uz dobro planiranje omoguava se dobro analitiko
praenje performansi dobavljaa, tano ispunjenje dogovorenih rokova,
kvaliteta i drugih parametara.
Primena skladita podataka u proizvodnji vezana je za davanje odgovora
na pitanja kao to su:
Koliko vremena treba da se napravi proizvod A?
Gde je usko grlo proizvodne linije?
Gde se javlja najvie problema vezanih za kvalitet?
Paretov princip, poznatiji kao pravilo 80/20, je tvrdnja da u svakom drutvu posledice
proizilaze iz malobrojnih uzroka. 80% posledica je izazvalo 20% uzroka. 20% klijenata donosi 80% profita. 80% procesorskog vremena se troi na 20% aplikacijskog koda
i druga tumaenja.
259
Analiza upravljanja kapacitetima reava probleme u operativnom

planiranju i otvara mogunost za provlaenje proizvodnje kroz ograniene
kapacitete bez veih investicija. I ovde se moe ukljuiti Pareto analiza,
tj. 80% problema potie od 20% uzroka, to je posebno vano za praenje
kvaliteta proizvoda. Da bi se problem kvaliteta mogao dobro analizirati i
u transakcionim sistemima i u skladitu podataka, potrebno je obezbediti
potpuno praenje proizvodnog procesa, od ulaznih sirovina do gotovog
proizvoda.
Primena skladita podataka u upravljanju kadrovima vezana je za analizu
i planiranje razvoja kadrova i predstavlja prvi korak u uvoenju upravljanja
znanjem kao novog kvaliteta i prednosti organizacije na trinoj utakmici.
Skladita podataka se mogu primeniti i za praenje i analizu zarada i
trokova (po grupama, organizacionim jedinicama, regionima), ekasno
ulaganje u obrazovanje kadrova i dr.
260
8. OLAP sistemi
OLAP (On-line Analytical Processing) reenja omoguavaju korisnicima

brz i eksibilan pristup podacima i predstavljaju nadgradnju skladita podataka. Interaktivno analitiko procesiranje (OLAP) namenjeno je on-line
analizama i izvetavanjima, za razliku od produkcionih sistema namenjenih auriranju baza podataka i obradi transakcija (On-line Transaction
Processing OLTP).
Jedna od karakteristika koja razdvaja transakcione sisteme (OLTP) od
analitikih (OLAP) jeste dizajn baze podataka:
Transakcioni sistemi su dizajnirani tako da preuzimaju podatke,
vre izmene nad postojeim podacima, daju izvetaje, odravaju integritet podataka i upravljaju transakcijama to je bre mogue.
Analitiki sistemi nisu predvieni da obavljaju ove poslove. Oni
se dizajniraju za veliki broj podataka namenjenih samo za itanje,
obezbeujui informacije koje se koriste za donoenje odluka.
Postavlja se pitanje, ta je to to je krajnjem korisniku potrebno. Krajnji
korisnik zahteva sledee:
da moe da postavi bilo koje poslovno pitanje;
da bilo koji podatak iz preduzea koristi za analizu;
da dobijeni podaci budu integrisani i pouzdani;
mogunost neogranienog izvetavanja i dr.
U poetku su upiti korisnika bili relativno jednostavni. Meutim, vremenom su korisniki upiti postali toliko sloeni da relacioni alati (OLTP
alati) nisu bili u mogunosti da daju odgovore u prihvatljivom vremenskom
periodu. Upravo u tu svrhu se koriste OLAP sistemi. Oni omoguavaju jednostavnu sintezu, analizu i konsolidaciju podataka. Koriste se za intuitivnu,
brzu i eksibilnu manipulaciju transakcionim podacima. OLAP sistemi
podravaju kompleksne analize koje sprovode analitiari i omoguavaju
analizu podataka iz razliitih perspektiva (poslovnih dimenzija). OLAP
je nain obrade podataka koji karakteriu ad-hoc upiti, slabo struktuirani
izvetaji i analiza koja obuhvata relativno mali broj transakcija, ali koja
ukljuuje veliki broj tabela i zapisa u njima.
261
Osnovni elementi OLAP sistema su:

baza podataka, koja slui kao osnova za analizu,
OLAP server, za upravljanje i manipulaciju podacima,
interfejs sistem, prema korisniku i prema drugim aplikacijama,
alati za administriranje.
OLAP baza podataka je denisana sledeim komponentama:
Numerike mere mere su vrednosti podataka ili injenice koje
korisnici analiziraju. Primeri mera su iznos prodaje, trokovi prodate robe itd.
Dimenzije dimenzije predstavljaju poslovne kategorije koje
obezbeuju kontekst numerikim merama. Dimenzijama OLAP-a
je lake navigirati nego dimenzijama eme zvezde.
Kocke Kocke kombinuju sve dimenzije i sve mere u jedan konceptualni model.
OLAP dimenzije sadre sledee hijerarhijske elemente (Slika 8.1):
Dimenzije organizovani nivoi i lanovi u strukturi drveta.
Nivoi grupa lanova dimenzije koji imaju isto znaenje.
lanovi Svaka diskretna vrednost u dimenziji.
Slika 8.1. Elementi dimenzije
262
Kocka je logika struktura skladitenja OLAP baze podataka. Kocka

kombinuje dimenzije i mere kako bi korisnici mogli da prave upite. Kocka
denie skup povezanih dimenzija koje formiraju jednu n-dimenzionalnu
mreu:
Svaka elija kocke sadri jednu vrednost;
Vrednost svake elije je presek dimenzije.
Mere su numerike vrednosti koje korisnici analiziraju. Svaka kocka
mora da sadri barem jednu meru, ali ne moe da ima vie od 1024 mera.
Iako su podaci sauvani samo jednom i to na jednom mestu, svaki korisnik
moe dobiti razliite poglede na jedne iste podatke. Jedan od primera dat
je na sledeoj slici.
Slika 8.2. Razliiti pogledi na iste podatke
Kao to smo ranije rekli, dimenzija predstavlja kategoriju podataka, kao

to su tip proizvoda, region, vreme itd. Svaka elija kocke sadri agregirane podatke koji su u vezi sa dimenzijama. Na primer, jedna elija moe
sadrati podatke o ukupnoj prodaji za dati proizvod i region u toku jednog
meseca. Na slici 8.3 se moe videti da kocka skladiti vrednosti prodaje
za svaki proizvod, svako trite i za svaki period vremena. Da bi dobili
ukupnu godinju vrednost, korisnici biraju proizvod i trite i sumiraju
elije iz sva etiri kvartala.
263
Slika 8.3. OLAP kocka Prodaja
Kocka Prodaja (Slika 8.3) sadri tri dimenzije: Vreme, Proizvodi i

Trita. injenice o prodaji su skladitene u presecima svih dimenzija
u kocki. Korisnik koji nadgleda prodaju malina u Milanu eli upit za Q4
prodajne vrednosti.
Glavna svrha OLAP baza podataka je da obezbede eksibilne modele
za pronalaenje podataka. Dimenzije i hijerarhije omoguavaju tu eksibilnost. Dimenzije omoguavaju slice i dice:
Slice (krika ili podskup kocke) - izbor jednog lana iz dimenzije.
Na primer: ukoliko elite da se fokusirate na samo jedan proizvod,
slice vam omoguava da ignoriete sve osim eljenog proizvoda.
Dice (domine ili slino pivot tabeli) kada primenjujete dice na
kocki, onda postavljate vie lanova iz jedne dimenzije na jednu
osu i vie lanova druge dimenzije na drugu osu. Ovakav nain
vam omoguava da sagledate meuodnose lanova razliitih dimenzija.
Slika 8.4. Zbirni prikaz (dice)
264
Hijerarhija vam omoguava drill down i drill up:

Drill Down - Sve dimenzije sadre hijerarhiju i za veinu dimenzija
hijerarhija se sastoji od vie nivoa. Vie nivoa hijerarhije omoguava
drill down po jednom lanu hijerarhije. Drill down omoguava da
se fokusirate samo na odreene podatke ili oblast problema.
Slika 8.5. Fokus na konkretne podatke (drill down)
Drill Up Vide se samo zbirne informacije lanova. Omoguava

da se sagleda opta slika.
OLAP pristup mora od hardvera da poseduje poseban raunar, tzv.
OLAP server, na koji se povezuju relacione BP, eksterni izvori podataka i
ostali interni podaci. OLAP serveri koriste viedimenzione strukture za
uvanje podataka i veza izmeu njih. Viedimenzione strukture se najbolje
vizuelizuju kao kocke podataka i kao kocke u kockama podataka. Svaka
strana kocke se naziva dimenzijom. OLAP serveri podravaju tipine
analitike operacije:
konsolidacija ovom operacijom se vri agregacija podataka po
zadatom kriterijumu;
drill down/up
isecanje (slice & dice)
Interfejs OLAP sistema treba da omogui korisniku komforan rad,
samostalno izvoenje analitikih operacija i dobijanje pregleda i poslovne
grake, bez znanja programiranja i strukture baze podataka. OLAP alati
veoma ekasno omoguuju prelaenje sa tabela na viedimenzione grakone
korienjem ekrana koji su dinamiki promenljivi (dashboards). Ovako
denisana OLAP ili hiper kocka sadri desetine hiljada moguih izvetaja
koji se lako menjaju, brzo deniu i jo bre izvravaju.
265
Princip rada OLAP analize je sledei (Slika 8.6):

Denisanje izvora podataka;
Denisanje strukture kocke;
Podeavanje dimenzija i mera;
Izvravanje upita nad kockom.
Slika 8.6. OLAP analiza [5]
266
8.1. Arhitekture OLAP sistema

Prenoenje samo izmenjenih podataka zahteva kompleksno programiranje i odravanje, dok kompletno zanavljanje podataka u skladitu postaje
ozbiljan zadatak kada osnovna baza naraste. Neki od OLAP alata ziki
prenose sve povezane transakcione podatke iz relacione baze podataka i
iz drugih izvora u viedimenzionalnu bazu podataka, koristei meta nivo
i pune skladite podataka preko noi (batch pristup), odnosno izvode
kompletno zanavljanje podataka u odreenim vremenskim intervalima.
Drugi pristup, tzv. on-line, prenosi svaku pojedinanu izmenu relacione
u viedimenzionu bazu podataka. Ovo su dva krajnja pristupa, meutim,
obino se koristi srednje reenje, gde je batch osnovna metoda, dok se
samo neke izmene na starim podacima prenose pojedinano.
Oba gore denisana pristupa uslovila su pojavu dve osnovne arhitekture, tzv. multidimenzioni OLAP (MOLAP) i relacioni OLAP (ROLAP).
MOLAP je reenje kada se koriste multidmenzione baze podataka, a
ROLAP nastaje kao nadgradnja relacionih baza podataka. Tendencija je
ka kombinovanju ova dva pristupa za izgradnju skladita podataka. Dakle,
trenutno postoje sledee arhitekture OLAP sistema:
viedimenzioni OLAP (MOLAP),
relacioni OLAP (ROLAP),
hibridni OLAP (HOLAP).
MOLAP i ROLAP se razlikuju po nainu zikog uvanja podataka. Kod
MOLAP sistema podaci se uvaju u viedimenzionoj strukturi, a u sluaju
ROLAP sistema podaci se uvaju u relacionim bazama podataka.
8.1.1. Viedimenzioni OLAP (MOLAP)

MOLAP (Multidimensional On-line Analytical Processing) baze podataka imaju ogranienje zike veliine skupa podataka sa kojima mogu
da rade i ogranienje na broj dimenzija. Da bi se vrila bilo kakva analiza,
potrebno je prvo uitati podatke u viedimenzione strukture, pri emu se
vre razni prorauni kako bi se kreirale agregacije i popunili podaci. Po
zavrenom procesu, korisnik moe zapoeti analizu.
Prednost MOLAP sistema je to obezbeuje odline performanse
sistema, naroito kada se radi sa ve izraunatim podacima (agregacijama).
267
Nedostatak MOLAP sistema je tekoa dodavanja novih dimenzija. Na

sledeoj slici je prikazana arhitektura MOLAP sistema.
Transakcioni
sistemi
Viedimenziona
baza podataka
- upiti
- heiranje
- indeksiranje
Sloj baze
podataka
- predvianja
- traenje
izuzetaka
Sloj aplikacije
OLAP interfejs
- tabele
- grafikoni
- drill down
- isecanje
- tampanje
Sloj prezentacije
Slika 8.7. Arhitektura MOLAP sistema
Sa slike 8.7 se vidi da se podaci iz razliitih transakcionih sistema

uitavaju u viedimenzionu bazu podataka pomou batch rutina. Kada se
zavri sa uitavanjem podataka, prelazi se na kreiranje agregacija, nakon
ega je baza podataka spremna za rad. Korisnici zadaju svoje zahteve za
OLAP izvetajima putem interfejsa.
8.1.2. Relacioni OLAP (ROLAP)

ROLAP sistemi pristupaju podacima direktno iz skladita podataka i
rade sa relacionim bazama podataka. Ovi sistemi mogu da rade sa velikim skupovima podataka. im se odredi izvor podataka, korisnik moe
zapoeti analizu. S obzirom da se radi direktno nad bazom podataka,
korisniku su uvek na raspolaganju tekui podaci. Takoe, kod ROLAP
sistema ne postoje ogranienja po pitanju broja dimenzija koja postoje u
sluaju MOLAP sistema.
268
Na sledeoj slici je prikazana arhitektura ROLAP sistema.
Slika 8.8. Arhitektura ROLAP sistema
Nakon to se denie model podataka za skladite podataka, podaci iz

transakcionih sistema se uitavaju u skladite podataka. Viedimenziona
analiza, koju korisnik zahteva, dinamiki se transformie u niz SQL naredbi
koje se dalje prenose na relacionu bazu podataka.
ROLAP sistemi su optimizovani za pristupanje podacima, dok su MOLAP sistemi optimizovani za prikupljanje podataka. Neke od karakteristika
MOLAP i ROLAP sistema su:
viedimenziona analiza mogua je korienjem ROLAP i MOLAP
sistema,
za manje koliine podataka ROLAP sistemi imaju skoro iste performanse kao i MOLAP sistemi,
MOLAP sistemi nisu pogodni za rad sa velikim skupom podataka,
MOLAP sistemi su manji od ROLAP sistema, te je potrebno manje
ulazno/izlaznih (U/I) operacija pri pribavljanju podataka, to uslovljava da su MOLAP sistemi bri.
269
8.1.3. Hibridni OLAP (HOLAP)

Najbolje reenje predstavlja HOLAP, iji alati mogu pristupati i relacionim i viedimenzionim bazama podataka. Cilj korienja HOLAP alata
jeste da se iskoriste prednosti MOLAP alata (kratko vreme odziva sistema
i analitike mogunosti) i ROLAP alata (dinamiki pristup podacima).
Pri tome se ne moe rei da je HOLAP prost zbir MOLAP-a i ROLAP-a,
ve je zapravo ROLAP koji ima mogunost izvravanja vrlo sloenih SQL
naredbi. Dakle, cilj je bio da se zadre sve prednosti ROLAP-a, ali da se pri
tome dodaju i neke nove mogunosti za rad sa viedimenzionim bazama
podataka. Jedan od HOLAP alata je i Oracle Express.
Potrebe korisnika su:
viedimenzioni pogled na podatke ovu mogunost poseduju i
MOLAP i ROLAP alati,
odline performanse sistema ovu mogunost poseduju MOLAP
alati,
analitika eksibilnost (za potrebe simulacija) ovu mogunost
poseduju MOLAP alati,
pristup podacima u realnom vremenu ovu mogunost poseduju
ROLAP alati,
veliki kapacitet podataka ovu mogunost poseduju ROLAP
alati.
HOLAP alati moraju imati sledee karakteristike:
dimenzije se mogu dinamiki aurirati ne samo da treba obezbediti brz pristup samim podacima, ve se mora omoguiti i
jednostavna izmena struktura podataka;
mogunost viedimenzionih pogleda zasnovanih na meta podacima
relacionih sistema za upravljanje bazama podataka HOLAP
alati moraju koristiti meta podatke relacionih DBMS pri kreiranju
viedimenzionog modela;
brz pristup svim nivoima agregacionih podataka;
jednostavno odravanje agregacija.
Sledei akronimi se takoe ponekad koriste, ali nisu toliko rasprostranjeni kao prethodni:
desktop OLAP (DOLAP) - obezbeuju lokalnu multidimenzionalnu analizu na klijent maini nad podacima koji su prikupljeni i
270
sa relacionih i multidimenzionalnih servera baze podataka. Korisnik download-uje manje kocke sa data mart-ova ili data warehouse-a radi obavljanja multidimenzionalne analize i to u oline reimu. Ova funkcionalnost je posebno korisna za mobilne
korisnike.
Web zasnovan OLAP (WOLAP) reenje koje spaja dve vrlo
dinamine tehnologije: World Wide Web i OLAP alate. WOLAP
alati obezbeuju OLAP funkcionalnosti kao to su drill-up i drilldown kroz hijerarhije dimenzija i odline performanse kombinovane sa svim prednostima Web aplikacija.
271
9. Otkrivanje znanja i data mining
Korisnici informacionih sistema s pravom zakljuuju da su im uvoenjem

poslovnog reenja obeavali sve i svata, a dobili su samo gomilu podataka.
To je tano, tim pre to se baze podataka uveavaju zbog realnih potreba
poslovnog procesa. Ono to se namee jeste potreba za automatizacijom
analize podataka. Upravo je to ono to omoguavaju tehnike i alati otkrivanja
znanja u bazama podataka (Knowledge Discovery in Databases KDD).
Otkrivanje znanja u bazama podataka, krae KDD, je proces pronalaenja
znanja u podacima i obezbeivanje automatizovanih analitikih reenja.
Proces otkivanja znanja uzima sirove rezultate iz data mining-a (proces
izvlaenja trendova ili obrazaca iz podataka) i precizno ih transformie u
korisne i razumljive informacije. Proces ekstrakcije znanja iz velikih baza
podataka, KDD vri koristei metode data mining-a (algoritme). Sveukupni
koraci otkrivanja znanja su prikazani na slici.
Slika 9.1. Pregled koraka KDD procesa
Celokupan proces pronalaenja i tumaenja obrazaca dobijenih iz podataka prolazi kroz sledee korake:
1. Razumevanje domena aplikacije, relevantnog prethodnog znanja
i ciljeva krajnjih korisnika;
2. Selekcija - odabiraju se (segmentiraju) podaci po nekom kriterijumu
(na primer, svi ljudi koji poseduju automobile) da bi se odredili
272
3.
4.
5.
6.
7.
podskupovi podataka; kreira se ciljni skup podataka i to izborom

skupa podataka ili fokusiranjem na podskup promenljivih ili na
uzorke podataka nad kojim e se vriti otkrivanje znanja;
ienje podataka i preprocesiranje - faza ienja podataka, u
kojoj se odreene informacije odbacuju jer se smatraju nepotrebnim, a koje bi usporile obradu upita;
Transformacija u ovoj fazi se vri redukcija podataka i njihova prekonguracija kako bi postali korisni i jednostavniji za
pretraivanje;
Izbor data mining zadatka (klastering, regresija, klasikacija i
dr.) i algoritma (izbor metoda koji e se koristiti za pronalaenje
obrazaca u podacima); odluivanje o tome koji su odgovarajui
modeli i parametri; pripajanje odreenog metoda data mining-a
celokupnomm kriterijumu KDD procesa;
Tumaenje/Evaluacija - obrasci koji su otkriveni u prethodnim
fazama interpretiraju se kao znanje koje se dalje moe koristiti za
procese podrke odluivanju.
Konsolidovanje otkrivenog znanja.
Ne treba meati termine KDD i data mining-a. KDD se odnosi na interaktivni i iterativni proces otkrivanja korisnog znanja iz podataka koji
ukljuuje pripremu podataka, izbor obrazaca i evaluaciju znanja. Data
mining (tzv. iskopavanje podataka) se odnosi na aplikacije algoritama za
izvlaenje obrazaca iz podataka. Data mining otkriva obrasce i trendove
u sadraju informacije. Primer otkrivanja odreenih podataka je i matini
broj graana, gde su u strukturi broja smeteni podaci koji se mogu koristiti
kao elementi za pretraivanje.
Data mining otkriva relacije naeg svakodnevnog komuniciranja sa
podacima. Omoguava sagledavanje informacija na nain koji ranije nije
bio sagledavan. Osnovna namena data mininga jeste da se iz ogromne
koliine operativnih podataka i veza koje se ne mogu odmah sagledati
deniu odgovarajue relacije, obrasci ponaanja, to u krajnjem sluaju
treba da od podataka da potrebne informacije.
Dakle, data mining se moe denisati kao proces podrke odluivanju
u kojem se trae abloni (obrasci) infomacija u podacima. Osnovni cilj
data mining-a jeste otkrivanje skrivenih veza, predvidivih sekvenci i tanih
klasikacija.
273
Viestruke su oblasti primene data mining-a. Na primer data mining

se moe koristiti za klasikovanje grupa klijenata sa slinim informacijama, kako bi se ciljno reklamiralo. Kada se korisnik na primer registruje
na e-commerce Web sajt koji prodaje sportsku opremu tada DBMS prikuplja informacije o klijentu, kao to su pol, godine, omiljeni sport i dr.
Korienjem tehnika data mining-a, Web sajt e prikazivati, na primer,
baner sa motivima golfa za mukarce i sl.
Kada kupujete putem Interneta, ponekad vam se ponude i dodatni
proizvodi za koje je Web sajt predvideo da ete moda biti zainteresovani.
Takva preporuka se zasniva na tehnikama data mining-a koji pretrauje
obrasce klijenata koji su na primer kupili istu knjigu koju vi sada kupujete.
Sistem preporuuje: Ukoliko vam se dopada knjiga x, proverite i sledee
ponuene knjige.
Kada uzimate kredit, banka prikuplja irok opseg informacija o vama,
kao na primer prihodi, godine staa, brani status, kreditna sposobnost
itd. Korienjem data mining tehnika, banka moe da predvidi da li ste
dobar ili rizian klijent za davanje kredita i takva informacija e odluivati
o odobravanju kredita.
9.1. Tehnike data mining-a

Tehnike data mining-a su specine implementacije algoritama data
mining-a koje omoguavaju identikovanje obrazaca u ogromnim broju
podataka. Modeli data mining-a u okviru Analysis Services SQL Server-a
2005 su (Slika 9.2):
Stablo odluivanja (Decision Trees) popularan metod za klasikaciju i predvianje. Korienjem serije pitanja i pravila za
kategorizaciju podataka, mogu se predvideti da e izvesni tipovi
imati specine ishode. Na primer, osoba u starosnom dobu izmeu
25-35 godina koja zarauje 60.000 godinje, najverovatnije e biti
zainteresovana da podigne kredit za stan nego neko u starosnoj
grupi od 15-24 godina. Na osnovu godina, dohotka i dr. istorijskih
injenica, algoritam drveta odluivanja e izraunati izglede da
nekoj osobi trebaju neke odreene usluge.
Pravila asocijacije (Association Rules) ovaj algoritam pomae
u identikovanju relacija izmeu razliitih elemenata. On grupie
po slinosti, odnosno koristi se za pronalaenje grupe artikala koji
274
se najee zajedno dogaaju u jednoj transakciji. Na primer, koristi se kod unakrsne prodaje gde se belee veze izmeu artikala i
predvia za koji proizvod e jo biti zainteresovan da kupi. Ovaj
algoritam moe da radi sa enormno velikim katalozima. Bio je
testiran na pola miliona artikala.
Naive Bayes ovaj algoritam se zasniva na Bayes-ovoj teoremi sa
pretpostavkama o nezavisnosti promenljivih kod razliitih elemenata podataka. Algoritam izraunava verovatnou izmeu ulaza
i predvidljivih kolona i pretpostavlja da su kolone nezavisne. Na
primer, promenljiva: dohodak jednog domainstva se razlikuje za
svakog klijenta u bazi podataka i moe da poslui kao predskazatelj
za budue kupovine.
Sekvencionalno otkrivanje obrazaca (Sequential Pattern Discovery) ova tehnika data mining-a je slina tehnici asocijacije, s
tim to senkvencionalno otkrivanje povezuje dogaaje vremenski i
odreuje u kakvoj su vezi elementi tokom odreenog vremenskog
perioda. Na primer, koristei ovu tehniku moe se predvideti da
osoba koja kupi mainu za pranje vea bi u narednom periodu od
6 meseci sa verovatnoom 0.7, kupila i mainu za suenje vea.
Prodavnica ovaj podatak moe da iskoristi i da ponudi kupcu koji
je kupio mainu za pranje vea popust od 10% za nabavku maine
za suenje u roku od 4 meseca.
Klasikacija (Classication) posmatra ponaanja i atribute
predeterminisanih grupa. Grupe mogu biti npr., lojalni klijenti,
visoki potroai, ljudi koji se odazivaju direktnim mail kampanjama
i sl. Primer klasikacije bi bio otkrivanje karakteristika klijenata
koji kupuju (ili ne kupuju) odreenu vrstu proizvoda. Ovo znanje
e rezultirati u smanjenju trokova promocije i slanja direktnih
mail-ova.
Klastering (Clustering) tehnika klasteringa omoguava grupisanje zapisa podataka koji su slini na osnovu sekvenci prethodnih
dogaaja. Na primer, sa klasteringom moete segmentirati klijente
sa slinim karakteristikama u grupe. Korisnici Web aplikacije esto
prate razliite putanje kroz sajt. Ovaj algoritam moe da grupie
klijente prema njihovom redosledu otvaranja stranica na sajtu
kako bi pomogli u analizi korisnika i u odreivanju koje su putanje
protabilnije od drugih. Ovaj algoritam se takoe moe koristiti u
predvianju koju e sledeu stranicu korisnik posetiti.
275
Predvianje (Forecasting) tehnika predvianja se posmatra

kroz dva aspekta:
regresiona analiza (regression analysis) koristi poznate vrednosti podataka za predvianje buduih vrednosti ili buduih
dogaaja koji se zasnivaju na istorijskim trendovima i statistici.
Na primer, obim prodaje opreme za sportska kola se moe
predvideti na osnovu broja prodatih sportskih kola u prolom
mesecu.
otkrivanje vremenske sekvence (time sequence discovery)
se razlikuje od regresione analize u tome to predvia samo
vremenski zavisne vrednosti podataka. Na primer, odreuje
procente saobraajnih nesrea tokom praznika na osnovu broja
nesrea koje su se dogodile tokom istog perioda u protekloj
godini.
Neuronske mree (Neural Nets) kao to ovek ui na osnovu
iskustva tako moe i raunar. Neuronske mree modeluju neuronske
veze u ljudskom mozgu i na taj nain simuliraju uenje. Ukoliko
sastavljate podatke gde su ulazne i izlazne injenice poznate, raunar
moe da naui iz tih obrazaca i postavi pravila i matematike faktore
kako bi npr., pomogao izraunavanje ili predvideo izlaznu vrednost.
Pretpostavimo da elite da prodate kola, nekoliko faktora utie na
prodajnu cenu kao to su godine, stanje, proizvoa, model itd.
Analizirajui cene kola, neuronske mree mogu da kreiraju seriju
ulaznih i izlaznih faktora kako bi predvideli cenu prodaje.
Text Mining ovaj algoritam analizira nestruktuirane tekstualne
podatke. Na primer, kompanije mogu da analiziraju nestruktuirani
podatak kao to je deo za komentare gde klijenti unose svoje utiske,
zadovoljstvo o proizvodu i druge komentare.
276
Slika 9.2. Algoritmi data mining-a
Razmotrimo sledei primer koji tehnikom drveta odluivanja pokuava

da odgovori na pitanje: Koji je kljuni atribut za predvianje da li e svreni
srednjokolci upisati fakultet ili ne?
Prikupljeni su odgovori na sledea pitanja:
Kog su pola?
Koliki je prihod njihovih roditelja?
Koliki im je koecijent inteligencije - IQ?
Da li ih roditelji ohrabruju da nastave studiranje ili ne?
Da li planiraju da upiu fakultet?
Da bi na osnovu prikupljenih podataka utvrdili koliko studenata e
nastaviti kolovanje, neophodno je da se postavi upit koji broji zapise
studenata koji ele i onih koji ne ele da nastave kolovanje. Pretpostavimo
da ste zainteresovani da odredite koji atribut ili kombinacija atributa imaju
najvei uticaj da predvidi verovatnou studenata koji e upisati fakultet.
S obzirom da je ovo sloeniji upit, zahteva se korienje tehnika data
mining-a.
277
Primenjujui algoritam drveta odluivanja (Slika 9.3) otkrivene su

sledee relacije: Najuticajniji atribut je ohrabrivanje njihovih roditelja
da upiu fakultet. Oni studenti koje roditelji ohrabruju da upiu fakultet,
60% planira da upie fakultet i to uglavnom oni sa visokim koecijentom
inteligencije.
Slika 9.3. Stablo odluivanja
Koraci kod izgradnje data mining modela su:

1. Izbor tehnike data mining-a npr. stablo odluivanja;
2. Identikovanje sluaja (case) - sluaj (case) je element koji se koristi
za klasikaciju i grupisanje podataka (npr. klijenti ili proizvodi);
3. Izbor entiteta koji treba da se predvidi npr. prot ili kreditna
kartica i sl.;
4. Identikovanje podataka za analizu npr. analizirae se odreeni
atributi klijenta kao to su pol, brani status, obrazovanje, meseni
prihodi i sl.;
5. Opciono kreiranje dimenzije i virtuelne kocke iz rezultujueg
modela;
6. Obrada modela i prikupljanje rezultata.
278
OLAP i data mining su integralni delovi svakog procesa podrke

odluivanju. Korienjem OLAP pristupa, korisnik postavlja pitanja tipa
Koje su prodaje po gradovima i po mesecima? i sistem daje odgovor.
Meutim, sam pristup nije dovoljan, s obzirom da se na taj nain dobija
samo prikaz podacima koji se nalaze u skladitu podataka. Korisniku je
potrebno da pretrauje podatke po vie dimenzija ne bi li naao razliite
ablone podataka koji postoje u OLAP prostoru (na primer, kako na prot utiu dimenzije Grad i Vreme). Prema tome, OLAP sistemi se moraju
fokusirati ne samo na pristup podacima, ve i na proces otkrivanja znanja.
Komponente OLAP data mining-a su:
relaciona baza podataka koja sadri granularne podatke (ne mora
biti skladite podataka),
OLAP koji obezbeuje brz pristup sumarnim podacima izmeu
vie dimenzija,
viedimenzioni proces otkrivanja koji e vriti otkrivanje izmeu
dimenzija i spajati rezultate.
Osnovni koncept je da se sa objektima manipulie u viedimenzionom
prostoru. Osnovna jedinica viedimenzionog prostora je kocka, kao to je
osnovna jedinica u relacionom svetu tabela. Kocke imaju atribute, kao to
relacije imaju kolone. Svaka kocka predstavlja agregaciju izraunavanja
nad skupom dimenzija (npr., suma svih prodaja za sve proizvode u jednoj
prodavnici). Taka kocke se naziva koordinata ili primerak (npr., prodaja
za jakne u jednoj prodavnici). Za vreme procesa OLAP otkrivanja, fokus
neprestano rotira izmeu razliitih dimenzionih tabela, dok se prelazi
hibridni prostor da bi se izvrila analiza uticaja.
Razmotrimo sledei primer izgradnje data mining modela sa OLAP
podacima. Direktor marketinga eli da oceni trenutni program kreditnih
kartica. Da bi zadrao postojee klijente i ispunio njihova oekivanja, eli
da identikuje mogunosti kako bi poveao nivo usluga kod svih vrsta
kartica: zlatna, srebrna, bronzana i obina. Raspoloive informacije od
klijenata su pol, brani status, godinji prihodi i nivo obrazovanja.
279
Da bi predvideli faktore koji utiu na izbor odgovarajue kartice

koristiemo data mining:
1. Odabraemo tehniku drveta odluivanja da bi pronali obrazac za
izbor kreditne kartice.
Slika 9.4. Ekran Mining Model Wizard-a za izbor tehnike data mining-a
2. Odabraemo Klijente kao dimenziju sluaja (case dimension).
Slika 9.5. Ekran za izbor sluaja (case) i nivoa

280
3. Odabrati Kreditnu karticu kao informaciju koju e koristiti algoritam data mining-a da bi identikovao obrasce.
Slika 9.6. Ekran izbora objekta predvianja
4. Iskoristie se raspoloive informacije o klijentima kako bi se pronaao

obrazac.
Slika 9.7. Ekran za izbor atributa posmatrane dimenzije
5. Ukoliko elite na interaktivan ad-hoc nain da isptujete stablo

281
odluivanja onda moete da ukljuite opciju kreiranja nove dimenzije i ukljuivanje iste u virtuelnu kocku.
Slika 9.8. Kreiranje nove dimenzije i virtuelne kocke
6. Ispitati stablo odluivanja uoavanje zavisnosti meu atributima.

Na ovom primeru se moe uoiti da je obrazovanje glavni faktor
uticaja na izbor kreditne kartice. Iz ovoga bi se moglo zakljuiti da
bi direktor marketinga trebao da posveti panju edukaciji i uopte
informisanju korisnika o prednostima koje se dobijaju korienjem
kreditnih kartica kao i nainu njihove upotrebe. Atribut brani
status najmanje uticaja ima na izbor kreditne kartice.
282
Slika 9.9. Ispitivanje data mining modela
Slika 9.10. Ispitivanje zavisnosti atributa
283
9.2. Web mining

Danas postoji nekoliko biliona HTML dokumenata, slika i drugih
multimedijalnih fajlova dostupnih preko Interneta, a iji broj se i dalje
uveava. Prikupljanje specinih sadraja postaje teak zadatak. Web
mining koristi ideje i principe data mining-a i KDD-a kako bi izvukao
specine podatke. Web mining (WM) predstavlja korienje data mining
(DM) tehnika za automatsko otkrivanje i ekstrakciju korisnih informacija
iz Web dokumenata.
Web mining se moe denisati kao otkrivanje i analiza korisnih informacija na WWW-u. Web mining se deli na tri istraivake oblasti, u
zavisnosti od toga koji deo Web-a ispituju, a to su: otkrivanje sadraja na
Web-u (Web Content Mining), otkrivanje strukture veza na Web-u (Web
Structure Mining) i otkrivanje obrazaca u korienju Web-a (Web Usage
Mining).
Otkrivanje sadraja na Web-u (Web Content Mining) predstavlja
otkrivanje korisnih informacija iz Web sadraja, podataka i dokumenata.
Sadraj Web-a se sastoji od nekoliko vrsta podataka, kao to su tekstualni
podaci, slike, audio i video zapisi i metapodaci, poznatiji kao hiperlinkovi.
Poslednja istraivanja u otkrivanju viestrukih vrsta podataka se nazivaju
multimedijalni DM, tako da moemo smatrati multimedijalni DM kao
jedan deo sadraja Web Mining-a. Ipak, najvei deo podataka na Web-u
ine nestruktuirani tekstualni podaci. Istraivanja u oblasti primene DM
tehnika na nestruktuirane tekstove se nazivaju otkrivanje znanja u tekstovima (Knowledge Discovery in Texts - KDT) ili tekst mining.
Istraivanja uraena u oblasti Web Content Mining-a mogu se podeliti
na dva razliita pristupa: pristup zasnovan na agentima i pristup zasnovan
na bazama podataka. Cilj Web Content Mining-a u pristupu zasnovanom
na agentima je da pomae korisnicima u pronalaenju relevantnih informacija ili u njihovom ltriranju, na osnovu odgovarajuih prola korisnika.
U pristupu zasnovanom na bazama podataka cilj je da se formira model
podataka na Web-u i da ga integrie sa mnogo sosticiranijim upitima
nego to su kljune rei, na osnovu kojih pretraivai vre pretraivanja.
Otkrivanje strukture veza na Web-u (Web Structure Mining) nastoji da otkrije fundamentalni model strukture linkova na Web-u. Model
mora biti zasnovan na topologiji hiperlinkova sa opisom linkova, ili bez
284
opisa. Ovaj model moe biti korien za kategorizaciju Web strana i npr.
u odreivanju slinosti i veza izmeu razliitih Web sajtova.
Otkrivanje obrazaca u korienju Web-a (Web Usage Mining)
pokuava da da smisao podacima generisanim u Web korisnikim sesijama ili podacima o ponaanju korisnika. Dok Web Content Mining i Web
Structure Mining koriste realne i primarne podatke na Web-u, Web Usage
Mining otkriva sekundarne podatke izvedene iz interakcija korisnika u toku
njihovog rada na Web-u. Ova oblast koristi podatke iz pristupnih logova
Web servera, logova proksi servera, logova pretraivaa, korisnikih prola, registracionih podataka, korisnikih sesija ili transakcija, korisnikih
upita, pokretanja ili pritiskanja tastera mia i bilo koje druge podatke koji
nastaju kao rezultat interakcije korisnika.
Organizacije prilikom obavljanja svakodnevnih operacija prikupljaju
ogromne koliine podataka koje Web serveri automatski generiu i prikupljaju u logovima za pristup serveru. Druge izvore korisnikih informacija
predstavljaju referencirani logovi (referrer logs) koji sadre informacije o
referenciranim stranama za svaku referencu na strani, zatim informacije o
registraciji korisnika ili pregledu prikupljenih podataka preko CGI skripta.
Analiza ovakvih podataka moe pomoi organizacijama u odreivanju
ivotnog ciklusa potroaa, ivotnog ciklusa proizvoda, u formulisanju
marketing strategije, u efektivnijoj promotivnoj kampanji i dr. Takoe
moe obezbediti informacije o tome kako treba prestrukturirati Web sajt
organizacije u cilju kreiranja ekasnijeg prisustva organizacije na Web-u,
ali i ekasnijeg upravljanja komunikacijama izmeu radnih grupa.
Za potrebe reklamiranja prodaje na WWW-u, analiza obrasca u
korisnikim pristupima serveru moe pomoi u kreiranju reklama za
specine grupe korisnika. Mnotvo postojeih alata za Web analize
obezbeuje mehanizme za izvetavanje o korisnikim aktivnostima
na serverima, kao i mehanizme za razliite oblike ltriranja podataka.
Korienje takvih alata omoguava odreivanje broja pristupa serverima
i pojedinanim fajlovima, odreivanje vremena pristupa, kao i naziv domena i URL-a korisnika. Ipak, ovi alati su dizajnirani u cilju smanjivanja
manipulacija u poslovanju na Web-u, pa obino omoguavaju male ili
skoro nikakve, analize povezanosti podataka preko pristupnih fajlova i
direktorijuma unutar Web prostora.
285
10. Poslovna inteligencija
Poslovna inteligencija ili inteligencija o poslovanju (Business Intelligence BI) je arhitektura koja predstavlja zbirni naziv za kolekciju
integrisanih alata, aplikacija i baza podataka koje obezbeuju organizaciji
ekasan i lak pristup poslovnim podacima, analizu i meusobno deljenje
informacija u cilju donoenja kvalitetnijih, brzih i relevantnijih odluka i
poboljanja sveukupne poslovne efektivnosti. BI softver je opti pojam
koji opisuje sisteme za podrku odluivanju (Decision Support Systems DSS), ranije izvrne informacione sisteme (Executive Information Systems
EIS), data warehouse softvere, ekspertne sisteme i data mining tehnike
za interpretiranje podataka (Slika 10.1).
Slika 10.1. Poslovna inteligencija
BI aplikacije ukljuuju sledee aktivnosti: viedimenzionalnu analizu,

npr. OLAP; data mining; upravljanje znanjem; poslovne analize; implementaciju portala preduzea; predvianja i dr.
BI arhitektura predstavlja ivotni ciklus projekta razvoja BI aplikacija
286
korienjem struktuiranih i nestruktuiranih (text, content i voice mining)

podataka, ukljuuje i izgradnju portala preduzea sa inkorporiranim XML
servisima i rasporeuje odgovarajue poslovne role (uloge).
Razlozi uvoenja BI u organizaciju su brojni (Slika 10.2). BI daje pogled
na celokupnu organizaciju, pri emu svi zaposleni mogu dobiti informaciju
koja im je u tom trenutku neophodna radi donoenja boljih, brih i relevantnijih odluka. BI omoguava proaktivan nain voenja preduzea, to
znai da se moe predvideti budunost, izraditi nekoliko scenarija i biti
pripremljen za svaku situaciju. Problem je kako pretvoriti informaciju u
znanje. Danas se preduzea vode na osnovu znanja o konkurenciji, kupcima, dobavljaima, procesima i dr. BI proizvodi znanje koje je osnova za
donoenje poslovnih odluka.
Slika 10.2. Razlozi uvoenja BI
287
10.1. Koraci razvoja BI projekta

Kao i svi inenjerski projekti i ovaj projekat prolazi kroz est faza, kao
to je ilustrovano na slici 10.3 [3]:
Opravdanost (Justication) procenjuju se poslovne potrebe;
Planiranje (Planning) razvoj stratekih i taktikih planova koji
ukazuju na to kako e se projekat razvijati i uvoditi u sistem;
Analiza poslovanja (Business analysis) obavlja se detaljna analiza
poslovnih problema ili poslovnih mogunosti kako bi se razumeli
poslovni zahtevi za potencijalnim reenjem (proizvodom);
Projektovanje (Design) projektovanje proizvoda koji reava
poslovne probleme;
Izgradnja (Construction) izgradnja proizvoda koji treba da
obezbedi povraaj investicija u okviru predenisanog vremenskog
okvira;
Uvoenje (Deployment) implementacija i prodaja zavrnog
proizvoda, zatim merenje njegove efektivnosti da bi se odredilo da
li reenje dostie oekivani povraaj investicija (return on investment ROI).
Slika 10.3. Faze razvoja BI projekta
288
Detaljniji koraci razvoja BI projekta su (Slika 10.4) [3]:

1. Faza Opravdanosti projekta:
1.1. Ocena poslovnih sluaja (Business Case Assessment) na osnovu
denisanih poslovnih problema i mogunosti predlae se BI reenje.
Opravdanost BI reenja treba da bude poslovno voena, a nikako
tehnoloki.
1.1.1. Potrebe za informacijama - U ovom koraku neophodno je
odrediti krajnje rezultate koji se ele postii analiziranjem poslovanja,
kao npr.: Zato gubimo 50% trinog udela ABC kompanije u Engleskoj?. Zatim treba denisati koje informacije se zahtevaju (oblasti
poslovanja, vreme, nivoi detalja, granularnost podataka, spoljni podaci
i dr.), kako bi se dobio odgovor na gore postavljeno pitanje. Sledei
korak je identikovanje poslovnih rola (menaderi, biznis analitiari
itd.) koji e biti aktivni u razliitim funkcijama podrke odluivanju.
1.1.2. Tipovi izvora podataka - U ovom koraku, najvei izazov predstavlja spajanje podataka iz razliitih tipova izvora podataka. Postoje
tri glavna tipa izvora podataka i to:
operativni OLTP sistemi obezbeuju operativne podatke o
odreenoj oblasti, kao to su nansije, logistika, prodaja, kadrovi,
istraivanje, inenjering i sl.
privatni podaci podaci koji se nalaze u spreadsheets datotekama,
bazama podataka i dr. fajlovima analitiara, statistiara, menadera
i drugog osoblja koje obavlja svoje aktivnosti u okviru posmatrane
oblasti;
eksterni izvori podataka podaci koji se nalaze na Internetu, u
bazama podataka poslovnih partnera, a koji mogu biti razvrstani
po kategorijama, npr. industrijski podaci (tehnoloki trendovi, marketing trendovi, menadment nauke, informacije o trgovini i sl.),
podaci o konkurenciji (proizvodi, usluge, cene, promocije prodaja i
sl.), podaci o prodaji i marketingu (npr., lista potencijalnih klijenata),
kreditni podaci (podaci o kreditnoj sposobnosti klijenata, bilansi
poslovanja i sl.), ekonomski podaci (politiki indikatori, cene na
berzi, kretanja kamatnih stopa i sl.), demografski podaci (gustina
populacije, starosno doba i sl.), podaci o robi (npr., cene sirovina),
psihometrijski podaci (npr., proli klijentata), meteoroloki podaci
(vremenski uslovi, temperature naroito za agrikulturne i putnike
industrije i sl.), ekonometrijski podaci i dr.
289
Spajanje i standardizovanje podataka je zahtev skoro svake BI aplikacije.

Najvei problem je taj to su podaci na razliitim izvorima memorisani
u razliitim strukturama i na razliitim platformama.
Slika 10.4. Detaljni koraci razvoja BI aplikacije
Problem nekonzistentnosti podataka jo je vei ukoliko se doda informacija da razliiti ljudi u organizacijama imaju razliite autoritete u
odreivanju poslovnih pravila i politika.
1.1.3. Analiza trokova i koristi - Drugi aspekt koji se u ovom koraku
razmatra je analiza trokova i koristi (cost-benet analysis). Koristi BI
projekta je obino tee kvantikovati nego trokove. Jedan od efektivnijih metoda za opravdanje trokova jeste da se ukae direktno na
poslovni problem, npr., pretpostavimo da organizacija gubi 5 miliona
evra svake godine jer ne moe da zauzda prevare osiguranja usled nepouzdanih i nedovoljnog broja podataka. Ukoliko BI aplikacija moe da
rei konkretan problem, onda bi bilo veoma lako opravdati investiciju.
Stoga, treba biti koliko je mogue detaljan u identikovanju koristi,
ak i onda kada je veoma teko kvantikovati precizno ROI. Na ovaj
nain moe se stei poverenje kod poslovnih menadera i izvrioca i
dobiti odobrenje za poetak rada na BI projektu.
Kod identikovanja koristi, neophodno je imati u vidu sledee kategorije koristi:
290
Poveanje sveukupne dobiti npr., identikovanjem novog trita

ili efektivnija prodaja, bre prepoznavanje poslovnih mogunosti
i sl.
Poveanje prota npr., poboljana mail promocija, upozorenja
pada na tritu, identikovanje neekasnih proizvodnih linija,
ekasnije upravljanje prodajom i sl.
Poboljanje satisfakcije klijenta npr., bolje razumevanje prioriteta klijenata, poboljano spajanje klijent-proizvod, poboljana
prodaja klijentima, bre reavanje albi klijenata i sl.
Poveanje utede npr. smanjenje otpadaka ili smanjenje zahteva
za kastomiziranim izvetajima.
Poboljanje trine pozicije npr., povean broj klijenata pridolih
od konkurencije, vii nivo odravanja klijenata u poreenju na
prethodne godine i prema konkurenciji.
1.1.4. Procene rizika (Risk assessment) - rizici su faktori ili stanja
koji mogu da ugroze projekat. Rizike bi trebalo oceniti prema sledeim
kriterijumima:
Tehnoloki rizik odnosi se na tehnologiju koja se koristi za
implementaciju BI projekta. Treba razmotriti sledea pitanja:
Da li je izabrana tehnologija zastarela u odnosu na trite i
organizaciju?
Koliko razliitih tehnologija koegzistira?
Da li imamo nekompatibilne operativne sisteme?
Da li imamo nekompatibilne sisteme za upravljanje bazama
podataka (DBMS)?
Rizik sloenosti razmatra se kompleksnost sposobnosti i procesa
koji treba da se implementiraju. Razmatraju se sledea pitanja:
Koliko je kompleksno celokupno IT okruenje?
Koliko je sloena sama BI aplikacija?
Koliko e se menjati workow? Da li e biti kompletno redizajniran?
Koliko sajtova e biti podrano?
Koji je stepen distribuiranosti podataka, procesa i kontrola?
Rizik integracije razmatra se integracija razliitih komponenata
i podataka:
291
Koliko e interfejsa imati BI aplikacija?

Da li postoje ukljueni i spoljni interfejsi?
Koliko ima redundantnosti kod izvora podataka?
Da li se mogu primarni kljuevi iz razliitih izvora podataka
spojiti?
Zato nemamo standarde ili imamo nekompatibilne?
Da li imamo zapise bez roditelja kao rezultat problema referencijalnog integriteta?
Organizacioni rizik razmatraju se sledea pitanja:
Koliko rizika e menadment da tolerie?
Koliko rizika e tolerisati IT menaderi?
Koliku nansijsku i moralnu podrku moemo oekivati kada
projekat naie na prepreke?
Rizik projektnog tima razmatraju se vetine, ponaanja, nivoi
obavezanosti kadrova za organizaciju:
Da li osoblje ima dovoljno iskustva u uspenom implementiranju
BI aplikacija?
Koliko je tim uravnoteen?
Kakav je moral tima?
Koja je verovatnoa gubitka jednog ili vie lanova tima?
Da li vetine lanova tima pokrivaju sve osnovne discipline?
Koliko je jak i sposoban projektni menader?
Rizik nansijske investicije iskazuje se u ROI:
Za koliko se moe oekivati ROI?
Koja je verovatnoa da trokovi prevaziu koristi?
Da li se nansijski rizik moe umanjiti jedino upotrebom dokazanih tehnologija?
Za ocenu rizika moe se koristiti matrica ocene rizika (Tabela 10.1),
gde su sa razliitim bojama istaknuta jaina rizika:
zelena nizak rizik to ukazuje na to da se moe nastaviti sa projektom;
uta srednji rizik koji ukazuje da treba obazrivo nastaviti;
crvena visok rizik, podrazumeva da treba stati i izvriti ponovnu
evaluaciju pre nego to se nastavi dalje.
292
Tabela 10.1. Osnovna matrica ocene rizika
2. Faza planiranja
2.1. Ocena infrastrukture preduzea pojedine komponente infrastrukture preduzea postoje, a druge bi trebalo razvijati u toku razvoja
BI projekta. Kada se razmatra infrastruktura preduzea posmatraju se
dve komponente:
2.1.1. Tehnika infrastruktura ukljuuje hardver, softver, middleware, DBMS sisteme, operativne sisteme, komponente mree,
skladita meta podataka, ureaje i dr.
hardver:
Novi hardver treba da se uklopi u postojeu konguraciju
hardvera.
DBMS na izabranoj hardver platformi mora da se izvrava
podjednako dobro sa rastom pristupa bazi podataka i upotrebe. Skalabilnost je glavno pitanje koje treba zadovoljiti.
Izbor platforme je ogranieno potrebom za interoperabilnou izmeu razliitih hardverskih platformi.
293
Trokovi i ROI su faktori koji moraju da se kontroliu.

Middleware odnosi se na softverski sistem koji se nalazi u
sloju izmeu aplikacionih programa i operativnog sistema.
Ponaa se kao most integracije aplikacionih programa i
drugih softverskih komponenti u okruenju gde postoji
nekoliko operativnih sistema, mnogo softverskih proizvoda,
viestrukih vorova mree. Data management middleware
povezuje aplikacije ili DBMS na jednoj platformi sa DBMSom koji se aktivira na drugoj platformi.
DBMS infrastruktura baze podataka se menja sa veliinom BI
okruenja, to utie na izbor DBMS-a, kao to je prikazano na
slici 10.5.
Slika 10.5. Infrastruktura baze podataka
2.1.2. Netehnika infrastruktura ukljuuje standarde meta podataka, standarde imenovanja podataka, logiki model podataka
preduzea, metodologije, vodie, procedure za testiranje, procedure
za razreavanje sporova i sl. Netehnika infrastruktura preduzea se
opisuje kroz poslovne funkcije, poslovne procese i poslovne podatke.
Svaki model sadri denicije standarda, poslovna pravila i politike.
Svrha ovih modela je da se dokumentuje skup poslovnih akcija.
2.2. Planiranje projekta BI projekti su ekstremno dinamini. Svaka
promena osoblja, budeta, tehnologije, sponzora, oblasti projekta moe
da utie na sam uspeh projekta. Stoga je neophodno detaljno izvriti
planiranje projekta, a svaki napredak nadgledati i izvetavati. Najea
pitanja koja se ovde postavljaju su:
ta e biti isporueno?
Kada e reenje biti isporueno?
294
Koliko e to kotati?
Ko e to uraditi?
Ovakva pitanja potpadaju u etiri glavna ogranienja projekta, a to su
oblast (domen projekta), vreme, budet i resursi. Koraci kod planiranja
projekta su sledei:
Denisati BI projekat navesti ciljeve, oblast, rizike, ogranienja,
pretpostavke, procedure kontrole promena, procedure o pitanjima
menadmenta.
Napisati projektni plan izlistati aktivnosti, zadatke i podzadatke,
oceniti neophodna vremena za ove aktivnosti i zadatke, dodeliti im
resurse, odrediti zavisnosti izmeu zadataka, odrediti zavisnosti
resursa, odrediti kritinu putanju i na kraju kreirati detaljan projektni
plan.
3. Faza analize poslovanja
3.1. Denisanje zahteva projekta Upravljanje oblau projekta je
jedan od najteih zadataka na BI projektima. elja da se isprojektuje
sve i to odmah je teko limitirati, tako da uskraivanje odreenih elja
predstavlja jedan od vanijih aspekata pregovaranja o zahtevima. Projektni tim treba da oekuje da e se zahtevi, tokom razvojnog ciklusa,
menjati, jer poslovni ljudi postaju svesniji mogunosti i ogranienja BI
tehnologija, tokom projekta. Zahtevi se posmatraju sa dva aspekta:
poslovni zahtevi visokog nivoa zahtevi za BI okruenje koji su
identikovani jo u koraku BI inicijative i koji se periodino revidiraju;
specini zahtevi projekta detaljni zahtevi koji se oekuju od
svake verzije BI aplikacije.
Aktivnosti denisanja zahteva projekta su:
Denisanje zahteva za tehnikom infrastrukturom prethodno je
trebalo ve utvrditi da li komponente tehnike infrastrukture mogu
da podre BI aplikaciju ili se zahtevaju izmene u infrastrukturi. U ovoj
aktivnosti se razmatraju zahtevi za: novim ili dodatnim hardverom;
novim DBMS-om ili nadogradnjom (upgrade) postojeeg, novim
razvojnim alatima, novim alatima za pristup i izvetavanje; novim
alatima data mining-a; novim skladitima meta podataka i novim
zahtevima za mreom.
295
Denisanje zahteva za netehnikom infrastrukturom ukljuuje

role i odgovornosti, standarde, metodologije, procese bezbednosti,
procese testiranja, funkcije podrke, komunikacije i dr.
Denisanje zahteva za izvetavanjem tokom intervjua, treba
sakupiti ili skicirati izvetaje i upite, denisati poslovna pravila za
kreiranje agregacija, sumarnih podataka i uopte izvoenje podataka.
Denisanje zahteva za izvorima podataka denisati detaljne
zahteve za podacima i izabrati najadekvatnije izvore podataka (fajlove, baze podataka i sl.). Odrediti zahteve za ienjem podataka i
denisati kritina poslovna pravila za podacima.
Pregled oblasti projekta uporediti detaljne zahteve sa domenom
projekta. Utrvrditi da li je cilj projekta i dalje ostvarljiv u okviru
odreenog domena projekta.
Proiriti logiki model podataka koristei informacije iz intervjua,
proiriti logiki model podataka sa novim entitetima, relacijama i
atributima.
Denisati preliminarne dogovore na nivou usluga razmatra
se raspoloivost, bezbednost, vreme odziva, istoa i pouzdanost
podataka, podrka i sl.
Napisati dokument zahteva aplikacije navesti zahteve za funkcijama, podacima, performansama, bezbednosti i pouzdanosti.
3.2. Analiza podataka najvei izazov kod BI projekata je kvalitet
izvora podataka. Analiza podataka se razlikuje od faze analize sistema
u okviru koje se koristi tradicionalna metodologija. Aktivnosti koje se
odvijaju tokom analize podataka su usmerene ka razumevanju i korigovanju postojeih neslaganja u poslovnim podacima, nezavisno od bilo
kog metoda sistemskog projektovanja ili implementacije. Stoga, analiza
podataka je poslovno, a ne sistemski orjentisana aktivnost. Zahtevaju se
dve komplementarne metode za analizu podataka:
top-down (sa vrha na dole) logiko modeliraje podataka radi integracije i konzistencije podataka koristi se model objekti-veze
(entity-relationship E-R);
bottom-up (odozgo na gore) analiza izvora podataka radi standardizacije i kvaliteta podataka ukoliko se ne obavi bottom-up analiza
296
tada se problemi podataka i naruavanja poslovnih pravila i politika

ne bi ni otkrili sve dok se ne implementira ETL proces. Mapiranje
izvora podataka se ne odnosi samo na pravila konverzije podataka (u
okviru koje se mapiraju tipovi podataka, duina i logika programa)
ve i na pravila domena podataka i integriteta.
Jedan od najfrekfentnijih ciljeva kod BI aplikacija je isporuka istih,
integrisanih i usklaenih (izmirenih) podataka. Arheologija podataka
(proces pronalaenja podataka), ienje podataka (proces korigovanja loih podataka) i kvalitet podataka (proces prevencije od greaka
u podacima) su poslovne odgovornosti, a ne IT odgovornosti. Ovo
podrazumeva da poslovni ljudi moraju biti ukljueni u aktivnosti analize
podataka i upoznati sa pravilima mapiranja izvornih podataka. Kljune
take selekcije podataka su:
integritet podataka to je nii integritet podataka, vei su zahtevi
za ienjem podataka;
preciznost podataka Da li su podaci precizni, jasni? Kako su podaci predstavljeni? Za numerike podatke, koja je skala i preciznost
podataka? Za podatke datuma, kako su formatirani?
ispravnost, tanost podataka Da li su podaci tani?
pouzdanost podataka Koliko su podaci stari? Da li je podatak
dobijen direktno sa izvora ili iz download-a? Da li je poznat izvor podataka? Da li je podatak dupliciran na drugom skladitu podataka?
format podataka to je format podataka blii destinacionom
formatu podataka, manji e biti zahtevi za konverzijom podataka.
Da li su podaci iz relacione baze podataka ili iz fajlova i sl.?
3.3. Prototipovanje aplikacije Prototipovanje pomae poslovnim
ljudima da sagledaju mogunosti i ogranienja tehnologije, kako bi
mogli da prilagode svoje projektne zahteve i oekivanja. Prototipovanje
predstavlja jedan efektivan metod za validaciju zahteva i pronalaenje
delova koji nedostaju. Poslovni ljudi obino ne misle na sve detalje kada
postavljaju svoje zahteve. esto zaborave da ukljue zavisne procese
ili povezane podatke. Prototip im moe pomoi da se fokusiraju na
konkretne zahteve i da sagledaju mogunosti BI tehnologije. Ukoliko to
vreme i budet dozvoljavaju, izgradnja prototipa omoguava testiranje,
proirivanje ili izmene zahteva u ranim fazama kada jo uvek nije visok
uticaj na raspored projekta. Takoe, svrha prototipovanja je i da potvrdi
da li bi dizajn, izabrani alati, DBMS i druge komponente tehnologije bili
297
odgovarajui za BI okruenje. Ukoliko sve komponente funkcioniu onako

kako se i oekivalo tokom prototipovanja, onda postoje velike anse da BI
implementacija uspe. Aktivnosti prototipovanja su prikazane na slici.
Slika 10.6. Aktivnosti prototipovanja aplikacije
3.4. Analiza skladita meta podataka Skladite meta podataka je baza

podataka. Meutim, za razliku od obine baze podataka, skladite meta
podataka nije projektovano da skladiti poslovne podatke za aplikacije,
ve da skladiti kontekstualne informacije o poslovnim podacima. Primeri
kontekstualnih informacija o poslovnim podacima su:
znaenje i sadraj poslovnih podataka;
politike koje se odnose na poslovne podatke;
tehniki atributi poslovnih podataka;
specikacije koje transformiu poslovne podatke;
programi koji rade sa poslovnim podacima.
Kontekstualne informacije o poslovnim podacima postoje u svakoj
organizaciji, bez obzira na to da li su dokumentovane ili ne. Ukoliko
su dokumentovane onda su poznate kao meta podaci. Ukoliko nisu
dokumentovane, onda nisu poznate svima u organizaciji. Kao rezultat
toga, poslovni ljudi esto postavljaju sopstvena poslovna pravila, ime
se kreiraju redundantni podaci i procesi, esto ne razmiljajui o tome
da takvi podaci moda ve postoje.
298
Meta podaci opisuju jednu organizaciju u terminima poslovnih aktivnosti

i objekata nad kojima se one izvravaju. Na primer, zaposleni prodaje
proizvod klijentu. Prodaja je poslovna aktivnost, a proizvod, klijent i
zaposleni su poslovni objekti nad kojima se aktivnost prodaje izvrava.
Poslovne aktivnosti i objekti, bilo da se izvravaju runo ili automatski,
se ponaaju u skladu sa relacijama i poslovnim pravilima. Meta podaci
se nalaze u CASE, ETL, OLAP i data mining alatima. Meta podaci dokumentuju transformacije i ienje izvornih podataka, obezbeujui time
praenje i periodino punjenje podataka. Takoe, meta podaci pomau u
praenju zahteva za bezbednou i merama kvaliteta BI. Njima se moe
upravljati centralno ili distribuirano. U oba sluaja, svaka instanca meta
podatka bi trebala da bude jedinstvena, bez obzira na ziku lokaciju.
Kategorije meta podataka su:
poslovni meta podaci opisuju naine pristupanja podacima u
BI okruenju u reniku koji je razumljiv i netehnikim poslovnim
ljudima;
tehniki meta podaci obezbeuju informacije o aplikacijama i
bazama podataka, koje su neophodne tehnikim licima u odravanju
BI aplikacija.
Tehnike meta podatke treba prevesti u poslovne meta podatke, a zatim
ih treba uskladititi u repozitorijume (skladita) meta podataka. Zahteve
za podacima treba dokumentovati u logikom modelu meta podataka.
Aktivnosti analize skladita meta podataka su:
Analiza zahteva za skladitem meta podataka identikovati
koji meta podaci su obavezni, bitni i opcioni. Ukoliko skladite ve
postoji trebalo bi ga aurirati.
Analiza interfejsa bez obzira da li je skladite izgraeno ili kupljeno,
ono mora da prihvata meta podatke iz razliitih izvora, kao to su
CASE alati, Word dokumenti, spreadsheet datoteke i sl. Tehniki
meta podaci e biti izvueni iz DBMS renika, ETL alata, alata za
ienje podataka, OLAP alata, data mining alata, od onih koji piu
izvetaje itd.
Analiza zahteva za pristupanjem i izvetavanjem identikovati
zahteve za pristupanjem meta podacima, zahteve za bezbednou i
help funkcija. Proceniti i druge naine prikazivanja kao to su PDF
(Portable Document Format) dokumenta, HTML, SQL i sl.
Kreirati logiki model meta podataka nacrtati logiki model
299
kao E-R model i u sluaju da se implementira kao objektna (objectoriented OO) baza podataka.
4. Faza projektovanja
4.1. Projektovanje baze podataka u zavisnosti od zahteva za izvetavanjem, zavisie i nain skladitenja poslovnih podataka (detaljni ili
agregirani podaci). Nisu svi zahtevi strategijski, niti su multidimenzionalni. ema baze podataka mora da odslikava zahteve za pristupanjem
informacijama. Aktivnosti projektovanja baze podataka su:
Pregled zahteva za pristupom podacima administrator baze
podataka sagledava zahteve za pristupanjem i analiziranjem podataka.
Odreivanje zahteva za sumiranjem i agregacijama treba obratiti panju na one zahteve na koje su korisnici ukazali da e moda
jednog dana zatrebati.
Projektovanje ciljne BI baze podataka veina BI baza podataka
e se zasnivati na multidimenzionalnoj emi, usled potrebe za slice
i dice analizama.
Izgradnja ciljne BI baze podataka zika baza podataka je
izgraena onda kada je pokrenut DDL (Data Denition Language)
sa odgovarajueg DBMS-a. Bezbednost podataka je uspostavljena
onda kada je pokrenut DCL (Data Control Language).
Razviti procedure za odravanje baze podataka kada je baza
podataka putena u rad, veoma je vano razmotriti backup-ovanje
baze ili reorganizaciju fragmentiranih tabela.
Priprema za nadgledanje baze podataka i najbolje isprojektovana
baza podataka ne garantuje dobre performanse tokom upotrebe.
Jedan od razloga je to se upotreba BI baze podataka tokom vremena
menja. Poeljno je praenje performansi upita i drugih dijagnostikih
mogunosti.
Priprema nadgledanja dizajniranih upita s obzirom da su performanse pravi izazov kod BI aplikacija, neophodno je isprobati sve
varijacije upita. Paralelno izvravanje upita bi mogao da pobolja
performanse upita.
4.2. Projektovanje ETL (Ekstrakcija/Transformacija/Punjenje) procesa ETL je najkoplikovaniji proces u itavom BI projektu. Izvori
podataka za BI aplikacije se nalaze na razliitim platformama, koje su
300
upravljane razliitim operativnim sistemima i aplikacijama. Svrha ETL

procesa je da spoji podatke iz heterogenih platformi u standardni format
(Slika 10.7).
ETL proces poinje sa reformatiranjem podataka koji treba da unicira
formate podatka sa razliitih izvora. U drugom koraku se reava problem
konzistentnosti koji se javlja usled redundantnosti podataka. Na kraju se
pristupa ienju onih podataka koji naruavaju poslovna pravila.
Generalno, prvi zadatak je proces konverzije sistema gde se mapiraju
najpogodniji elementi podataka u ciljne fajlove ili baze podataka. Kada
se kae najpogodniji elementi podataka misli se na one podatke koji
su najsliniji po imenu, deniciji, veliini, duini i funkcionalnosti.
Slika 10.7. Heterogeni izvori podataka
Drugi zadatak je pisanje programa konverzije (transformacije) kako bi

se transformisali izvorni podaci. Ovi programi moraju da ree probleme
dupliciranih zapisa, prilagoavanja primarnih kljueva i odsecanja ili
poveavanja veliine elemenata podataka. Ono to uglavnom nedostaje
ETL programima su ienje i usklaivanje podataka, na koje treba
obratiti panju kod projektovanja procesa punjenja.
301
Kod procesa punjenja istorijskih podataka koji su obino statini, treba

obratiti panju na one podatke koji nisu vie u upotrebi i novih podataka
koji se dodaju tokom godina.
Programi ekstrakcije podataka treba da vre sortiranje, ltriranje,
ienje i da agregiraju sve zahtevane podatke. Programi ekstrakcije
moraju da prepoznaju koji od redundantnih izvornih fajlova ili baza
podataka su zapisi sistema. Na primer, isti izvorni element podatka
kao to je Naziv klijenta moe da postoji u nekoliko izvornih fajlova
i baza podataka. Ova redundantnost treba da se sortira i konsoliduje,
to ukljuuje korake sortiranja i spajanja, preko odreenih kljueva i
vrednosti podataka.
Koristei pravilo 80/20, 80% ETL procesa je transformacija podataka, dok je
ostalih 20% ekstrakcija i punjenje. Projektovanje programa transformacije
je veoma komplikovano, naroito kada su podaci ekstrakovani iz heterogenih operativnih okruenja. Tipini problemi izvora podataka su:
nekonzistentnost primarnih kljueva esto se primarni kljuevi
izvornih zapisa podataka ne poklapaju. Na primer, moe postojati
pet fajlova o klijentima, gde svaki od njih ima razliiti atribut kao
primarni klju klijenta. Ovi razliiti kljuevi klijenata se moraju konsolidovati ili transformisati u jedan standardizovani BI klju klijenta
(Slika 10.8).
Slika 10.8. Reavanje problema nekonzistentnosti primarnih kljueva
nekonzistentnost vrednosti podataka mnoge organizacije du302
pliciraju svoje podatke. Termin dupliciranje se odnosi na elemente

podataka koji su kopija originalnog podatka. Tokom vremena, usled
anomalija auriranja, ovi duplicirani podaci imaju totalno razliite
vrednosti.
razliiti formati podataka elementi podataka kao to su datumi i
novani podaci (currencies) mogu biti uskladiteni u totalno razliitim
formatima.
netane vrednosti podataka da bi se korigovale netane vrednosti
podataka, mora se denisati logiko ienje. ETL algoritmi ienja
podataka treba da se aktiviraju svaki put kada se podatak puni. Stoga,
programi transformacije ne smeju biti pisani na brzinu, ve se moraju
razviti na jedan struktuiran nain.
sinonimi i homonimi redundantne podatke nije uvek lako prepoznati usled toga to isti elementi podataka imaju razliite nazive. S
obzirom da sinonimi i homonimi1 ne smeju postojati u BI okruenju,
neophodno je preimenovati date elemente podataka.
ugraena logika procesa neki operacioni sistemi su ekstremno
stari. Oni esto sadre nedokumentovane i arhaine relacije izmeu
pojedinih elemenata podataka. Takoe, obino koriste i neke kodove,
kao na primer, vrednost 00 podrazumeva da je poiljka vraena, dok
FF znai da je prosleena na kraju meseca. Specikacije procesa
transformacije moraju da reektuju ovu logiku.
Pored transformisanja izvornih podataka zbog nekompatibilnosti tipa
podataka, duine ili netanosti, najvei deo transformacione logike
e ukljuivati i preraunavanje podataka za multidimenzionalno skladitenje.
Finalni korak kod ETL procesa je punjenje ciljne BI baze podataka, koja
se postie na dva naina, i to: unoejem novih redova u tabele ili koristei
DBMS-ov alat za punjenje. Kod projektovanja programa za punjenje
treba obratiti panju na referencijalni integritet i indeksiranje.
Na kraju je neophodno dokumentovati ETL specikacije transformacije
pomou dokumenta mapiranja izvora-ka-cilju (source-to-target mapping
document) koji treba da lista sve BI tabele i kolone sa njihovim tipovima i
duinama podataka (Tabela 10.2). Takoe, treba prikazati ETL dijagram
1
Homonimi (homonym) su rei koje se isto piu i izgovaraju, ali imaju razliita znaenja
(est sluaj u engleskom jeziku).
303
toka procesa (ETL process ow diagram) koji prikazuje zavisnosti procesa

izmeu ekstrakovanja, sortiranja i spajanja, transformacije, privremeno
kreiranih fajlova i tabela, procesa rukovanja sa grekama, aktivnosti
usklaivanja nekonzistentnosti i redosleda punjenja podataka.
Tabela 10.2. Primer dokumenta mapiranja izvora-ka-cilju
Oblast prikazivanja (staging area) je mesto gde se izvrava ETL proces,

a koji ukazuje na dodeljeni prostor na disku, biblioteke ETL programa,
privremene i trajne fajlove i tabele, kao i na dodeljeni server. Ova oblast
moe biti centralizovana ili decentralizovana.
4.3. Projektovanje skladita meta podataka izvori meta podataka
mogu biti CASE alati, DBMS renici, ETL alati, alati za ienje podataka,
OLAP i data mining alati. Skladita meta podataka mogu biti:
centralizovana postoji jedna baza podataka (relaciona ili objektnoorijentisana) i jedna aplikacija za odravanje.
Skladite
meta podataka
Slika 10.9. Centralizovano skladite meta podataka

304
decentralizovana skladite meta podatke u bazama podataka koje

se nalaze na razliitim lokacijama.
DBMS Gateway
Skladite
meta podataka
Skladite
meta podataka
Skladite
meta podataka
Skladite
meta podataka
Slika 10.10. Decentralizovano skladite meta podataka
distribuirana preko XML reenja, meta podaci ostaju na svojim

originalnim pozicijama, odnosno na razliitim alatima.
Slika 10.11. Distribuirano XML reenje meta podataka
Ukoliko organizacija odlui da razvija skladite meta podataka u kui,

onda treba da bira izmeu E-R i OO dizajna. Meutim, ukoliko eli da
kupi gotovo reenje onda nikada ne treba da postavi pitanje tipa Koji je
najbolji proizvod ovog tipa na tritu?, ve treba da postavi pitanja:
Koji su nai zahtevi?
Koji zahtevi su obavezni, korisni, a koji opcioni?
Koji proizvodi odgovaraju obaveznim zahtevima, a koji korisnim?
305
Treba uporediti logike modele meta podataka vendora ili njihove

zike modele sa vaim logikim meta modelom kako bi se uvidelo da
li model vendora pokriva sve zahteve meta podataka. U svakom sluaju,
model vendora mora da podri obavezne zahteve za podacima. Takoe,
treba sagledati mogunosti proirenja skladita meta podataka koje
ukljuuju:
dodavanje objekata meta podataka;
dodavanje relacija;
menjanje neodgovarajuih relacija;
dodavanje atributa;
menjanje veliina i duina komponenata meta podataka;
kastomiziranje izvetaja;
imortovanje meta podataka iz drugih alata;
eksportovanje meta podataka u druge alate.
Aktivnosti projektovanja skladita podataka su prikazane na sledeoj
slici.
Slika 10.12. Aktivnosti projektovanja skladita meta podataka
306
5. Faza izgradnje
5.1. Razvoj ETL-a u zavisnosti od zahteva za ienjem i transformacijom podataka, zavisie i izbor ETL alata. BI projekti predstavljaju
najbolju mogunost eliminisanja zastarelih i beskorisnih podataka,
jer omoguavaju poslovnim ljudima da sagledaju svoje zahteve za informacijama iz razliitog ugla. Kada se ETL adekvatno implementira,
tada aktivnosti transformacije podataka (ienje, sumiranje, izvoenje,
agregiranje i integracija) e proizvesti podatke koji su isti, saeti, novi,
kompletni i standardizovani, respektivno (Slika 10.13).
Slika 10.13. Aktivnosti transformacije podataka
Jedna od najeih albi na BI aplikacije je ta da se podatak u BI bazi ne

poklapa sa podatkom iz izvornog sistema. Kao rezultat toga, poslovni
ljudi esto ne veruju BI podacima. Da bude ironija vea, u veini sluajeva
podaci u BI bazi podataka su esto taniji nego podaci iz operacionih
izvornih fajlova ili izvornih baza podataka, jer su oni preformatirani,
standardizovani i oieni. Stoga se skladite meta podaci o kvalitetu
podataka, statistici punjenja i sl. esto se testiranje ETL programa na
BI projektima vri veoma oskudno. Ta injenica nije prihvatljiva, kao ni
opravdanje da e to biti popravljeno u sledeoj verziji programa. Sledea
verzija e biti vea i komplikovanija, te e stoga zahtevati mnogo vie
vremena za testiranje.
Tipovi testiranja koji se primenjuju kod operacionih sistema, mogu se
primeniti i na BI aplikacije:
Testiranje jedinica (unit testing) podrazumeva:
kompajliranje (compilation) testiraju se moduli i skriptovi
kompajliranjem programa, gde svako kompajliranje programa
mora uspeno da se zavri.
funkcionalnost (functionality) svaki modul programa mora da
izvrava funkcije zbog kojih je i projektovan, kao i da obezbedi
oekivane rezultate.
editovanje (edits) svaki programski modul mora da hvata greke
i da upozori na njih.
307
Testiranje integracije (integration testing) je poznat i kao sistemsko

testiranje:
interakcije moraju se testirati interakcije izmeu modula.
tok ETL dijagram toka procesa treba da prikae kojim redosledom se programi izvravaju, koji se mogu paralelno odvijati i
kada se mogu ubaciti operacije sortiranja i spajanja. Ovaj tok se
mora testirati u odnosu na funkcionalnost i ekasnost. Testiranjem funkcionalnosti osigurava se da se pravi procesi izvravaju
nad pravim podacima u pravo vreme, odnosno da se programi
izvravaju prema pravilnom rasporedu.
Testiranje regresije (regression testing) cilj je da se uvidi da modikacije nad postojeim ETL programom nisu nenamerno proizvele
neke greke koje ranije nisu postojale.
Testiranje performansi proverava se ponaanje i performanse
sistema. Moe se izvoditi samo nad kritikim programskim modulima.
Testiranje kvaliteta veina organizacija ima jasne procedure kod
uvoenja aplikacije. Te procedure obino ukljuuju testiranje kvaliteta
koje se odvijaju u posebnim QA (quality assurance) okruenjima.
Testiranje prihvatljivosti proveravaju se sve funkcije ETL procesa
koje moraju biti tane i kompletne.
5.2. Razvoj aplikacija Kada prototipovanje potrvrdi sve funkcionalne
zahteve, onda se moe pristupiti razvoju aplikacije. Razvoj aplikacija
moe biti jednostavno naliziranje prototipa ili moe ukljuiti sloenije
razliite alate pristupa i analize. Glavni cilj koji BI aplikacija treba da
ispuni jeste da obezbedi brz i lak pristup podacima radi vrenja poslovnih
analiza. Vei procenat ovog pristupa e biti zadovoljeno primenom predenisanih obrazaca (ablona). Predenisani obrasci podrazumevaju da
su podaci izvedeni, agregirani, sumirani i uskladiteni na nain da im
se bre pristupa. Ovo je razlog velike popularnosti multidimenzionalnih OLAP alata koji ine glavnu komponentu BI aplikacija. OLAP alati
omoguavaju inovativne naine analiziranja podataka:
multdimenzioni pogled na podatke koji je intuitivan i prepoznatljiv
poslovnim ljudima. Na primer, organizacije uglavnom postavljaju
svoje strategije kako bi poveali prihode i to bilo uvoenjem novog
proizvoda, osvajanjem novih trita ili poveavanjem cena. Ove tri
308
karakteristike se mogu lako pratiti kroz multidimenzionalni pogled

na podatke prodaje (po proizvodu, po regionu, po klijentu);
sumiranje i agregacije podataka;
interaktivno postavljanje upita i vrenja analiza tipa: ta-ako smanjimo cenu proizvoda za 5 evra? Koliko bi nam se poveao obim
prodaje u odreenom regionu?
podrka analitiarima da mogu da kreraju lanove unutar dimenzija, dodaju nove ili menjaju parametre upita ili kreiraju mere ili
injenice.
podravanje drill-down, roll-up i drill-across funkcija. Na primer,
analitiar koji eli da pronae nain da smanji trokove proizvodnje robe, moe drill down funkcijom da sagleda detaljne trokove
kupljenih sirovina. Takoe, moe da sumira trokove sirovina u
predenisane kategorije, roll-up funkcijom. Primenjujui drill-across
moe da ode do druge tabele kako bi ukljuio i trokove proizvodnje
proizvedene robe.
primena analitikog modeliranja. Uzimajui u obzir prethodni primer,
smanjivanje trokova proizvodene robe moe se postii i smanjivanjem radnog kapitala. Primenom analitikog modeliranja mogu se
pronai optimalni iznosi radnog kapitala.
analize trendova i prognoziranje. OLAP analizira podatke iz prolosti
kako bi dao prognoze u budunosti.
prikazivanje podataka u grakonima, dijagramima i tabelama
omoguava vizuelni pregled, jer kao to se kae da slika vredi hiljadu
rei, tako i ove komponente ine sastavni deo OLAP alata.
OLAP arhitektura se sastoji od tri funkcionalne komponente: servisi
prezentacije, OLAP servisi i servisi baze podataka (Slika 10.14).
Servisi prezentacije moraju biti laki za korienje, eksibilni i
prilagodljivi. esto su to tabelarni izvetaji, ali se koriste i graki i
dijagramski prikazi. Meni, ikone i funkcije treba da se konguriu u
zavisnosti od prola analitiara, njihovih raunarskih sposobnosti i
vetina.
309
Prikazivanje informacija
Postavljanje upita,
izvetavanje, analiziranje
Relaciona, multidimenzionalna
Servisi prezentacije
OLAP servisi
Servisi baza podataka
Slika 10.14. Funkcionalne komponente OLAP arhitekture
OLAP alati treba da omogue interaktivno, meupovezano i iterativno postavljanje upita, izvetavanje i analiziranje.
Servisi baze podataka u zavisnosti da li je ROLAP, MOLAP ili
HOLAP.
Razvoj vitalnih poslovnih aplikacija se ne odvija ad hoc na neijem PCju. Veina organizacija zahteva formalan i struktuiran pristup razvoju,
testiranju i isporuci aplikacija. Organizacije obino postavljaju razliita
razvojna okruenja za razliite namene. Vee organizacije imaju okruenje
prototipovanja, razvojno okruenje, QA okruenje, proizvodno okruenje
i Web okruenje.
5.3. Data mining cilj je razvoj data mining baze podataka koja je projektovana i izgraena prema specinom analitikom modelu podataka
i setu data mining operacija (algoritmi u okviru data mining alata)
5.4. Razvoj skladita meta podataka Bilo da je skladite meta podataka kupljeno ili razvijano u kui, pre nego to se pusti u proizvodnju
trebalo bi izvriti pripreme.
Server platforma Produkcionu server platformu, gde e biti
smeteno skladite meta podataka, treba instalirati i testirati, to
ukljuuje hardverske komponente, operativni sistem, ureaje za
nadgledanje i mrenu konekciju.
Produkcioni DBMS ukoliko se skladite meta podataka instalira
na novom produkcionom serveru, tada bi trebalo kreirati instancu
DBMS-a, podesiti parametre i testirati nad operativnim sistemom.
310
Bezbednost
Prirunici i
instrukcije
Biblioteke programa i
upiti
Skladite meta podataka
Server platforma
Obuavanje
Postavljanje DBMS-a
Slika 10.15. Pripremni koraci uvoenja skladita meta podataka
Programske biblioteke i upiti svi meta podaci o migraciji programa

(programi interfejs alata) i svi meta podaci aplikacionih programa
(programe pristupa interfejsu, on-line help funkcije, izvetaje i upite)
e se nalaziti u biblioteci. Programi za upravljanje bibliotekom se
moraju instalirati i testirati pre nego to se puste u proizvodnju
programi skladita meta podataka.
Bezbednost produkcioni server, DBMS, skladite meta podataka
i svi programi moraju da imaju implementirane odgovarajue nivoe
bezbednosti.
Prirunici i instrukcije kada se jednom pusti u proizvodnju
skladite meta podataka, sa svakim ETL procesom prikupljae se
statistika punjenja i kvalitet podataka koji e se puniti u skladite
meta podataka.
Obuka poslovni ljudi i tehniko osoblje treba da se obue kako da
koriste skladite podataka, bilo preko interfejsa, direktno ili interaktivno. Analitiari treba da znaju kako da pristupaju skladitu meta
podataka kako bi selektovali BI podatke za izvravanje ad hoc upita.
Tehniko osoblje mora da zna kako da koristi meta podatke kako bi
znali da odravaju BI aplikacije i da isporuuju meta podatke kao
integralni deo izvetaja i upita BI aplikacija.
311
6. Faza uvoenja
6.1. Implementacija Kada je BI aplikacija razvijena i testirana, tada je
ona spremna da bude implementirana u proizvodno okruenje. Upravljanje bezbednou treba da se proima kroz sve korake razvoja BI
aplikacije, ali se ovde posebno posmatra bezbednost za Internet pristup.
Druga vana problematika o kojoj mora da se vodi rauna je backup i
oporavak baze podataka. Naredni korak je praenje upotrebe resursa.
Ovde se misli o angaovanosti raunara, mree i ljudi. Ono to, na kraju,
treba imati u vidu jeste vremenski rast podataka, korisnika i hardvera.
Aktivnosti implementacije su prikazane na slici 10.16.
Slika 10.16. Aktivnosti implementacije
6.2. Evaluacija uvoenja Sa izgradnjom BI okruenja ne zavrava se

proces razvoja BI projekta. BI projekti uvode mnoge nove prakse:
nove tehnologije za analitiare, nove tehnike prototipovanja, nove
tehnike projektovanja, nove arhitekture i nove tehnologije.
Navedene korake razvoja BI reenja ne morate izvravati sekvencionalno, mnogi projektni timovi e ih izvravati paralelno.
312
Rezime
1. Skladitenje podataka (Data Warehousing DW) je predmetno orjentisana, integrisana, vremenski zavisna kolekcija podataka koja
podrava proces donoenja menaderskih odluka. DW je relaciona/
multidimenzionalna baza podataka koja je projektovana za analizu
i postavljanje upita, a ne za obradu transakcija. DW obino sadri
bive podatke izvuenih iz transakcionih sistema. Okruenje DW se
sastoji od ETL reenja, OLAP engine, alata za klijent analizu i drugih
aplikacija koji upravljaju procesom prikupljanja podataka i prikazivanje poslovnim korisnicima.
2. Data mart je podstkup DW koji podrava odreeni region, poslovnu
jedinicu ili funkciju. Data mart je projektovan za odreenu liniju
poslovanja kao to je prodaja, marketing ili nansije.
3. Dimenziono modeliranje podataka ukljuuje jednu ili vie dimenzionih tabela i tabelu injenica. Primeri dimenzija su lokacija, proizvod, vreme, organizacija itd. Dimenzione tabele skladite zapise koji
se odnose na odreene dimenzije (npr. dimenzija proizvod e sadrati
kategoriju proizvoda, podkategoriju, naziv proizvoda i karakteristike
proizvoda), a one nee sadrati injenice, tzv. mere (npr. vrednost
prodaje, ukupna koliina prodatih proizvoda i sl.). Tabela injenica
sadri mere i spoljne kljueve dimenzionih tabela. Dimenziono modeliranje podataka se koristi za raunanje izvedenih (zbirnih, prosenih
i sl.) podataka.
4. ema zvezde je relaciona ema baze podataka za predstavljanje multidimenzionalnih podataka.
5. ETL alati ekstrakuju, transformiu i pune podatke u DW. ETL pristupaju i rukuju izvorima podataka i pune ih u ciljne baze podataka. Prvi
korak kod ETL procesa je mapiranje podataka iz izvornih sistema u
ciljne baze podataka (DW ili data mart). Drugi korak je ienje izvornih podataka u oblasti za pripremu podataka (staging area). Trei
korak je transformacija oienih izvornih podataka i njihovo punjenje u ciljne sisteme.
6. OLAP (On-line Analytical Processing) je pristup koji pomae organizaciji da koristi sve prednosti podataka. OLAP kocke omoguavaju
analizu podataka kroz viestruke dimenzije obezbeujui multidimenzionalni pogled agregiranih i grupisanih podataka. OLAP apANALITIKI POSLOVNI INFORMACIONI SISTEMI
313
likacije ukljuuju analize prodaje i klijenata, marketing analize, analize protabilnosti, proizvodnje, predvianje. Popularni OLAP alati
su Cognos, Business Objects, Micro Strategy itd.
7. ROLAP (Relational On-line Analytical Process) obezbeuje multidimenzionalnu analizu podataka koji su uskladiteni u relacioni sistem
baze podataka (RDBMS).
8. MOLAP (Multidimensional OLAP) obezbeuje analize podataka
uskladitenih u multidimenzionalne kocke podataka.
9. HOLAP (Hybrid OLAP) je kombinacija ROLAP-a i MOLAP-a i
moe da obezbedi simultanu multidimenzionalnu analizu podataka
uskladitenih i u multidimenzionalnoj bazi podataka i u relacionoj
bazi podataka.
10. DOLAP (Desktop OLAP ili Database OLAP) obezbeuju lokalnu
multidimenzionalnu analizu na klijent maini nad podacima koji su
prikupljeni i sa relacionih i multidimenzionalnih servera baze podataka.
11. Data mining je otkrivanje skrivenih veza, predvidivih sekvenci i tanih
klasikacija meu podacima. Web mining se deli na tri istraivake
oblasti, u zavisnosti od toga koji deo Web-a ispituju, a to su: otkrivanje
sadraja na Web-u (Web Content Mining), otkrivanje strukture veza
na Web-u (Web Structure Mining) i otkrivanje obrazaca u korienju
Web-a (Web Usage Mining).
12. Poslovna inteligencija (Business Intelligence) je tehnologija koja se
zasniva na modelima orjentisanih na klijente i prot u cilju smanjenja operativnih trokova, poveanja protabilnosti poboljanjem
produktivnosti, prodaje, usluga i donoenja boljih poslovnih odluka.
Modeli poslovne inteligencije se zasnivaju na multidimenzionalnoj
analizi i kljunim indikatorima performansi (Key performance indicators KPI) preduzea. Aplikacije poslovne inteligencije zasnovanih
na modelima poslovne inteligencije se kreiraju softverima poslovne
inteligencije koji obezbeuju agregirane detalje o dobavljaima, klijentima, internim aktivnostima, poslovnim transakcijama menaderima
i svima onima koji treba da donesu bolje odluke. Alati poslovne inteligencije pomau u prikupljanju, skladitenju, pristupanju i analizi
korporativnih podataka u cilju podrke odluivanju.
13. KPI su faktori koji utiu na uspeno poslovanje organizacije. KPI
moe da se odnosi na regionalne prodaje prodavaca, statistiku lanca
snabdevanja dobavljaa, produktivnost jedinica, zadovoljstvo klijenata, rast klijenata itd. Faktori koji utiu na izbor KPI su:
314
a. Merljivost KPI mora da bude merljiv odnosno da bude u

terminu brojki.
b. Reektovanje organizacionih ciljeva KPI mora da vodi
poslovanje ka uspehu.
c. Mogunost iniciranja poslovnih akcija treba da pomognu
menaderima u iniciranju poslovne akcije kao rezultat analiza
i mera KPI-a.
14. Dashboard poslovne inteligencije vizuelno predstavlja kljune organizacione podatke u realnom vremenu i na razumljiv nain. Dashboard prikazuje KPI-jeve i omoguava menaderu drill-down i druge
opcije analize. Tipine karakteristike su Web interfejs, izvetaji, graci i dijagrami i dr.

1.
2.
3.
4.
5.
6.
7.
Objasnite razliku izmeu skladita podataka (DW) i OLAP sistema.

Da li je mogue aurirati podatke koji su uskladiteni u DW?
Objasnite OLAP arhitekture.
Navedite i objasnite tehnike data mining-a.
Koje su prednosti alata poslovne inteligencije (Business Intelligence - BI)?
Navedite opte korake razvoja posovne inteligencije.
Navedite aktivnosti transformacije podataka u okviru ETL alata.
Reference
[1] Adelman, S., L.T. Moss, Data Warehouse Project Management, AddisonWesley, Boston, MA, 2000.
[2] Berson, A., S.J. Smith, Data Warehousing, Data Mining and OLAP,
McGraw-Hill, New York, 1997.
[3] Moss, L.T., S. Atre, Business Intelligence Roadmap the Complete Project
Lifecycle for Decision-Support Applications, Addison-Wesley, 2003.
[4] Veljovi, A., A. Njegu, Osnove relacionih i analitikih baza podataka,
Megatrend univerzitet, Beograd, 2004.
[5] Visual Studio 2005 Net arhitektura, prezentacija, Sinergija 2006,
Microsoft.
315
DEO IV:
MODULI POSLOVNIH
Ciljevi poglavlja
Svako poslovno reenje pokriva glavne poslovne procese organizacije.
U ovom delu se analiziraju najprimenjiviji moduli dananjih ERP reenja i
to: prodaja i marketing, raunovodstvo i nansije, proizvodnja i upravljanje
materijalima, ljudski resursi, menadment lanca snabdevanja i elektronsko
trite. Svi moduli su integrisani, to znai da razliita odelenja u okviru
organizacije koriste iste podatke u isto vreme. Takoe, omoguavaju
povezivanje poslovnih procesa izmeu organizacija irom sveta. Baza podataka je integrisana, tako da svi procesi koriste iste podatke. Na primer,
modul prodaje i marketinga koji podrava proces prodaje i distribucije sa
funkcijama za cene, obraivanje porudbina i isporuku, je direktno povezan sa modulom proizvodnje i upravljanje materijalima. Ovo omoguava
integrisani proces na primer, provere kredite kupca, osiguranja materijala,
proizvodnih kapaciteta koji zadovoljavaju pravovremenost narudbine,
izvravanje narudbine i automatski proces naplate. Ovaj modul omoguava
i analilzu prodaje i isporuke.
Nakon prouavanja ovog dela, studenti e:
razumeti glavne poslovne procese u organizaciji;
prepoznati tokove i veze izmeu poslovnih procesa koji podravaju
prodaju i marketing, proizvodnju, raunovodstvo i nansije i ljudske
resurse;
razumeti veze u lancu snabdevanja.
317
11. ERP sistemi: Prodaja i marketing
Prodaja i marketing ukljuuju procese na operativnom nivou i procese

kontrole upravljanja. Operativni procesi ukljuuju dnevne aktivnosti, kao
to su predvianje (prospecting), upravljanje kontaktima (contact management), telemarketing i direktni mail. Reprezentanti prodaje treba da kreiraju
i odravaju liste predvianja po lokacijama, po kategoriji proizvoda i prema
potencijalnoj prodaji i da odravaju sistem za upravljanje kontaktima.
Sistem za upravljanje kontaktima prati karakteristike klijenta, podatke
o prethodnoj prodaji i kontaktima. Obino operativne funkcije prodaje
i marketinga podravaju sistemi za obradu porudbina, koji prikupljaju
podatke o porudbini i POS (point-of-sale) sistemi, koji prikupljaju podatke
sa mesta prodaje. Ovi sistemi su povezani sa sistemima za upravljanje
zalihama koji auriraju nivoe zaliha prema podacima o prodaji.
Procesi upravljanja prodajom predstavljaju jednu od najvanijih oblasti.
Menaderi prodaje su odgovorni za kreiranje teritorija i za rasporeivanje
vremena prodajnog osoblja kako bi se generisala maksimalna dobit i usluga.
Odluke koje menaderi prodaje treba da donesu su sledee:
Kako bi trebalo urediti teritorije?
Kako rasporediti vremena prodajnog osoblja?
Koji klijenti su najprotabilniji?
Koji proizvodi su najprotabilniji?
Informacije koje menaderi prodaje koriste za donoenje odluka, su
uglavnom zasnovani na analizama prethodnih prodaja. Sumarni izvetaji,
izvetaji komparativne analize i drugi izvetaji su korisni alati u analiziranju trendova prodaje i odreivanju kako najbolje rasporediti resurse.
Na primer:
poreenje prodaja, prihoda po proizvodima, klijentima i regionima
u odnosu na benmarking uspenosti;
poreenje produktivnosti svakog prodavca prema proseku za
odeljenje;
izvetavanje o najprotabilnijim proizvodima po regionima;
318
izvetavanje o proizvodima koji predstavljaju najvei procenat

prodaje za svakog prodavca;
izvetavanje o klijentima koji predstavljaju najvei procenat prodaje
za svakog prodavca.
Jedan softver za upravljanje prodajom bi trebao da identikuje slabe
proizvode po regionima; da poredi performanse prodavaca po tipu proizvoda i tipu klijenta; da poredi performanse prodavaca u odnosu na ciljeve
prodaje; analizira performanse prodavaca unutar regiona; identikuje
trendove kupovine klijenata; identikuje mogue manjkove i vikove roba
na zalihama itd. Analize prodaje bi trebale da pomognu u rasporeivanju
prodajnog osoblja, u organizovanju regiona, u tome kako opsluiti potrebe
klijenata i kako trenirati prodajno osoblje da ekasnije koristi svoje vreme
kako bi se dostigla maksimalna dobit.
Proces predvianja prodaje je veoma vaan kako bi se odredile potencijalne potrebe klijenata u razliitim trinim segmentima. Aktivnosti
predvianja prodaje ukljuuju segmentiranje trita u ciljne grupe potencijalnih klijenata i planiranje proizvoda/usluga prema potrebama klijenata. Prognoze bi se mogle praviti za celokupnu prodaju ili za prodaje
po regionima, prema svakom proizvodu ili uslugama, za prodaju novih
proizvoda/usluga i za prodaju prema prodavcima. Predvianje prodaje
koristi informacije iz prolih prodaja, kao i informacije o konkurenciji,
potrebama klijenata i demografskim trendovima.
Drugi vaan marketing proces je reklama i promocija. Uglavnom se
postavljaju sledea pitanja:
Koje medije reklamiranja i kanale promocije bi trebalo koristiti?
Koji kanali i mediji reklamiranja su najekasniji kada se upuuje
ciljnom tritu?
Kljuno pitanje koje se postavlja kod upravljanja marketingom je koju
cenu dodeliti prozvodima. Da bi doneo odluku o ceni, marketing menader
bi trebao da zna oekivanu tranju za proizvodom, eljenu protnu marginu,
proizvodne trokove proizvoda i proizvode konkurencije. Odreivanje
cena zavisi od strategije, modela odreivanja cena koji se prave na osnovu
podataka iz razliitih izvora koji utiu na odreivanje cena, a koje ukljuuju
popis cena klijenta, oekivani raspoloiv prihod klijenta, koliinu proizvedenih proizvoda, trokova rada i trokova sirovina.
319
11.1. Moduli prodaje i marketinga u ERP sistemima

Softver za prodaju i marketing obino podravaju operativne i
menadment procese koji ukljuuju upravljanje kontaktima, upravljanje
prodajama i analize/predvianja prodaje. Razlika izmeu modula Prodaja
i marketing (Sales and Marketing) unutar jednog ERP sistema i tradicionalnih softvera za prodaju i marketing je u tome to ERP sistemi obezbeuju
integrisane sisteme za podrku marketingu, koji ukljuuju kontakt fajlove,
fajlove za unos porudbine, fajlove o bivim prodajama i dr. ERP sistemi,
takoe, obezbeuju CRM (Customer Relationship Management) softver
koji opsluuje prodavce sa informacijama o prethodnim iskustvima odnosa
sa klijentima, podrazumevajui klijentove nabavke, njegove prioritetne
proizvode i istoriju plaanja.
Unutar jednog ERP modula, klijent postavlja porudbinu, na osnovu koje
sistem pravi raspored isporuke, nabavlja delove i sirovine od dobavljaa
i pravi plan proizvodnje. Zatim, modul proverava kreditni limit klijenta,
aurira prognoze prodaje i kreira sastavnicu materijala. Takoe se auriraju
i dunosti prodavca. Izraunavaju se trokovi proizvoda i protabilnost. Na
kraju se auriraju raunovodstveni podaci, kao to su bilans stanja i uspeha,
rauni, glavna knjiga i druge nansijske informacije (Slika 11.1.).
Slika 11.1. Proces prodaje i distribucije

320
Svrha modula Prodaje i marketinga unutar ERP sistema je da identikuje oekivane prodaje, obrauje porudbine, upravlja zalihama, rukuje
isporukama, obezbeuje naplaivanje i prihvata i obrauje uplate i isplate
(tabela 11.1). Na narednim slikama mogu se uporediti ekrani Microsoft
Navision ERP reenja i SAP R/3 za deo prodaje i marketinga
Tabela 11.1. Funkcije podsistema prodaje i marketinga
Slika 11.2. Microsoft Navision ekran
321
Slika 11.3. SAP R/3 ekran (Kreiranje naloga)
11.2. ERP i upravljanje odnosima sa klijentima (CRM)

ERP sistemi podravaju tzv. back-oce funkcije kao to su prodaja,
raunovodstvo, ljudski resursi i proizvodnja, ime obezbeuju osnovu za
napredne aplikacije kao to su CRM i SCM (Supply Chain Management).
CRM predstavljaju sisteme koji su u interakciji sa klijentima i dobavljaima.
Koristei sledee scenarije, mogu se uvideti kako CRM sistemi doprinose
poslovanju.
Scenario 1: Na putu ste da posetite jednog od najboljih klijenta vae
kompanije, koji ine 5% od ukupne prodaje. Kada ste stigli uvideli ste da
je klijent veoma ljut, jer je njegova itava rma u 48-asovnom prekidu
zbog toga to nije dobio isporuku jednog dela za visoko-brzinski laserski tampa u boji kako bi mogao hitno da odtampa neke marketinke
materijale. Na neki nain, niste prethodno uopte bili obaveteni o ovom
problemu i desilo se to da ste izgubili posao sa svojim klijentom.
322
SCENARIO:
Na putu ste da posetite jednog od najboljih klijenta vae kompanije, koji
ine 5% od ukupne prodaje. Na putu, ukljuili ste svoj laptop i primili ste
hitnu poruku od klijenta da je dolo do kvara u opremi tampau u boji.
Kada ste stigli, vaa servisna ekipa je ve tamo i zamenjuje polomljeni deo.
Klijent je bio u mogunosti da putem eBusiness-a narui odgovarajui deo
tampaa koga je dostavila kurirska sluba. Klijent priznaje da bi verovatno
trebalo nadograditi (upgrade), odnosno nabaviti tampa veeg kapaciteta
jer ga koristi prekomereno. Na ovaj nain, ste poveali svoje prihode od
svog klijenta.
Ova dva scenarija prikazuju kako znanje o potrebama klijenata moe
da utie na kvalitet usluga, a samim tim i na zadravanje klijenta. CRM
softver ima svoje korene u softveru za prodaju koji je projektovan da
omogui prodajnom osoblju:
upravljanje aktivnostima prodaje - vodi prodajno osoblje kroz
svaki korak procesa prodaje, koji ukljuuje generisanje prioriteta,
kontaktiranje, rukovanje porudbinama i osiguranje realizacije
porudbine.
upravljanje prodajom i teritorijom pomae menaderima
prodaje u nadgledanju aktivnosti prodavaca, optimizovanju tima
i praenju celokupnog procesa prodaje.
upravljanje kontaktima pomae prodajnom osoblju u organizaciji
podataka o kontaktima, na nain da mogu postavljati upite nad
bazom podataka i razna pitanja, na primer: Ko je klijentov agent
prodaje? ili Koji klijenti su dobili najnoviju promociju proizvoda
X?.
upravljanje prioritetima omoguava praenje atributa proizvoda,
kao to su interesovanje za proizvodom, budet i konkurencija.
upravljanje konguracijom obezbeuje podrku za odreene
proizvode.
upravljanje znanjem omoguava pristup resursima informacija
koje ukljuuju: korporativne prirunike, slajdove prodajnog osoblja,
telefone kompanija, ablone za pisanje ponude, podatke o industriji
i konkurenciji, iseke iz tampe i zapisnike sa sastanaka prodaje.
Ove informacije mogu biti dostupne putem intraneta kompanije.
323
CRM sistem moe biti integrisan sa ERP sistemom. Glavne funkcionalnosti CRM sistema su prikazane na sledeoj tabeli.
Tabela 11.2. Funkcionalnosti CRM sistema
12. ERP sistemi: Raunovodstvo i finansije
Donoenje poslovnih odluka o protabilnosti proizvoda je znatno

oteano ukoliko se nansijske informacije odravaju u posebnoj bazi
podataka, odvojene od baze podataka nabavke, proizvodnje, marketinga
i dr. U osnovi, raunovodstveni sistemi podravaju operativne i kontrolne
funkcije. Na operativnom nivou, jedan raunovodstveni sistem proizvodi
transakcije (fakture, porudbine i sl.). Proces zapoinje kada se unese
porudbina koja generie auriranje zaliha kod sistema zaliha koji odrava
informacije o svakoj stavci na zalihama i povlai nabavku dodatnih zaliha
ukoliko nivo zaliha padne do kritine take. Sistem porudbine kreira
porudbine, proverava popunjena polja i odreuje vreme kada se oekuje
zavretak ove transakcije. Porudbina generie pravljenje fakture u okviru
sistema za obradu rauna klijenata. Plaanje se odvija kod sistema za
plaanje rauna.
324
Procesi kontrole unutar raunovodstva podrazumevaju budetiranje,

upravljanje gotovinom i investicijama. Budetiranje podrazumeva poreenje
trenutne alokacije budeta u odnosu na prethodne godine, kao i poreenje
trenutnih prihoda i rashoda u odnosu na prethodne godine. Na primer,
ukoliko se uporede trokovi putovanja koji su u odnosu na prolu godinu
poveani za 25%, uvia se znantno poveanje putnih trokova. Druga
analiza bi mogla da sagleda da se prihod jednog regiona znatno poveao
u odnosu na prethodne godine. Akcije koje bi se na osnovu ovih analiza
mogle preuzeti, jesu, na primer, da se u regionu, gde je dolo do poveanja
prihoda, ponudi nov proizvod.
Razlika izmeu tradicionalnih raunovodstvenih sistema i ERP modula
koji podravaju Raunovodstvo i nansije je ta da se nansijske informacije
dele u jednoj integrisanoj bazi podataka (Tabela 12.1).
Tabela 12.1. Raunovodstvo i finansije u ERP sistemu
Svaka transakcija u sistemu je predstavljena dokumentom koji belei

svaku poslovnu transakciju. Dokumenti su dostupni u realnom vremenu
i mogu se pregledati sa bilo kog nivoa detalja. Transakcije koje se odvijaju
u sistemu automatski auriraju glavnu knjigu (General Ledger). Glavna
knjiga prikuplja podatke iz itavog sistema (Slika 12.1).
325
Slika 12.1. Integracija drugih modula sa glavnom knjigom
Sa ERP reenjem, menaderi imaju pristup informacijama o trokovima

aktivnosti (Activity-based cost ABC). ABC informacije prate trokove
(na primer, ljudi, maina i drugih resursa) i primenjuje ove trokove na
odreene proizvode, usluge i klijente. Koristei ABC sisteme, menaderi
mogu da odgovore na vana pitanja, kao to su na primer: Koliko kota
pravljenje odreenog proizvoda i koliko je protabilan? ABC informacije
su strateke jer utiu na odluivanje o marketing i poslovnoj strategiji.
13. ERP sistemi: Proizvodnja i upravljanje

materijalima
U tabeli 3.1, u treem poglavlju ove knjige, prikazan je zapadni razvoj modela upravljanja proizvodnjom i kasnije kompletnim poslovanjem
jedne rme. Paralelno sa razvojem ovog modela, u Japanu se razvijao sasvim drugaiji model upravljanja proizvodnjom/ poslovanjem, zasnovan,
pre svega, na najboljoj poslovnoj praksi. Kompletna japanska lozoja je
razvijana i usavravana u tojotinoj (Toyota) laboratoriji, iji su strunjaci
znali da procene ta je to to u praksi daje najbolje rezultate, na primer
KANBAN, a takoe i da prihvate svaku novu ideju, bez obzira odakle ona
dolazi - TQC (Total Quality Control Deming), koja je u Tojoti doivela
svoju prvu primenu.
326
Svu ovu meavinu okupio je i uobliio Taii Ono (glavni inenjer u

Tojoti) i nazvao je JIT (Just in Time)1. Iako su MRPII i JIT u poetku bile
totalno razliite lozoje upravljanja poslovanjem, oni su na kraju u ERP
reenjima integrisane. Trenutno je nezamislivo da bilo koji ERP softver
nema u sebi KANBAN2. Jedan od takvih ERP reenja je i SAP R/3, koji za
upravljanje proizvodnjom ima dva razliita modula: SAP PP koji u osnovi
slui za diskretnu proizvodnju i koji u sebi sadri KANBAN (pull system)
i SAP PP-PI koji je klasino MRP II reenje (push system).
ERP sistemi uvode najbolje poslovne prakse koje se jednostavno
deniu kao najbolji nain izvoenja procesa. Da bi stekle konkurentnu
prednost, organizacije moraju da poboljavaju njihove poslovne prakse i dele
informacije sa svojim poslovnim partnerima i klijentima. Implementiranje
ERP reenja omoguava kompanijama da izvre reinenjering poslovne
prakse ka najboljoj praksi i integriu informacione resurse. Uspeh primene ERP reenja e zavisiti od efektivnog menadmenta, organizacionih
promena, primene naprednih tehnologija i neophodnog nivoa znanja i
vetina. Meutim, mnoge kompanije ne iskoriavaju sve potencijale implementiranog ERP reenja. Mnogi projekti su propali i usled toga to su
voeni tehnolokim motivacijama umesto poslovnim opravdanjem.
Sa sveukupnog poslovnog gledita, ERP sistemi dostiu brojne vane
ciljeve, kao to su ubrzani protok informacija izmeu svih poslovnih procesa, minimalno vreme odziva na zahteve klijenata i poslovnih partnera,
odluivanje na niim nivoima, jedinstvene, pouzdane i blagovremene
informacije donosiocima odluka, poveane interakcije kroz organizaciju,
bre projektovanje i proizvodnju proizvoda, poboljani menadment
poruivanja, smanjeno vreme ciklusa i trokova poslovnih procesa, bolje
performanse rada i dr.
Pravovremena proizvodnja (Just-in-time - JIT) proces proizvodnje je snabdeven

odgovarajuim materijalima, u pravo vreme, na pravom mestu i u tanom iznosu. Karakteristike JIT-a su: proizvodnja po narudbini, u malim serijama, sa nula
greaka, sa najkraim ciklusom izrade i bez zaliha.
2 Kanban (ident karta ili karta materijala) je sredstvo da se u proizvodnji postigne
JIT. Cilj uvoenja Kanban sistema je da se materijal dobro planira, da se prati,
kontrolie koliina i da se, u pravo vreme, izvri porudbina novog materijala za
potrebe proizvodnje. Na primer, kada stanje zaliha na skladitu dostigne nivo momenta porudbine (signalna zaliha), odmah se oslobaa sledei nalog za dopunu
odreene koliine zaliha na skladitu.
1
327
Proizvodni sistemi ostvaruju sledee ciljeve:

kreiraju planove proizvodnje;
nabavljaju sirovine;
rasporeuju opremu, ureaje i radnu snagu;
projektuju proizvode i usluge;
proizvode eljenu koliinu, uz odgovarajui nivo kvaliteta u zahtevano
vreme.
Procesi upravljanja proizvodnjom na operativnom nivou (Tabela 13.1) su:
Nabavka ija je funkcija da nabavi odgovarajuu koliinu sirovina
i/ili poluproizvoda.
Prihvatanje robe roba se pregleda i prihvata, a informacije o njenom
statusu se prosleuju do raunovodstva, magacina i proizvodnje.
Kontrola kvaliteta (Quality Control QC) identikuje vendore
koji su isporuili neispravnu robu ili nepouzdane materijale. QC
nadgleda kvalitet proizvodnih delova od sirovina, preko proizvoda
u proizvodnji do zaliha gotovih proizvoda. Kod TQM okruenja,
naglasak je na predvianje i prevenciju od defekata.
Sistemi upravljanja materijalima (Materials Management) obezbeuju informacije o nivoima zaliha, o upotrebi tih materijala
u proizvodnji i njihovoj lokaciji. Sistemi sastavnice (Bill of Materials
BOM) obezbeuju listu neophodnih sirovina, poluproizvoda i
komponenata kako bi se napravio nalni proizvod.
Upravljanje zalihama - odravaju zalihe na odgovarajuem nivou.
Sistemi trokova prikupljaju i izvetavaju o resursima koji su se
koristili u procesu proizvodnje kako bi se utvrdili tani proizvodni trokovi, koji ukljuuju trokove osoblja, materijala, opreme i
ureaja.
Tabela 13.1. Procesi planiranja i proizvodnje
328
Procesi menadment kontrole (Management Control) u proizvodnji su:

MRP (Material Requirement Planning) - podrava procese:
identikovanja zaliha, odreivanja glavnih vremena, izraunavanja
bezbenosnog nivoa zaliha, odreivanja najefektivnijih koliina
porudbina i kreiranja porudbina nabavke za odgovarajui nivo
zaliha. MRP koristi ulazne informacije sa Glavnog plana proizvodnje
(Master Production Schedule MPS). MPS koristi prognoze prodaje
kako bi identikovao kada su potrebni odreeni proizvodi.
Just-in-time (pravovremena proizvodnja) idealno proizvodno
okruenje je JIT sistem gde postoji ba onoliko zaliha koliko je i
potrebno za proizvodnju. Jedan nain za ostvarivanje ovog cilja je
uspostavljanje ekstraneta sa dobavljaima kako bi mogli da nadgledaju nivoe zaliha.
Planiranje kapaciteta - odreuje da li ima dovoljno proizvodnih
kapaciteta (osoblje, prostor, maine i drugi proizvodni ureaji) kako
bi se ostvarili ciljevi proizvodnje. Planiranje kapaciteta zahteva
detaljne informacije o ljudskim resursima, BOM, zalihama roba u
procesu proizvodnje, zalihama gotovih proizvoda, veliinama serija,
statusu sirovina, porudbina i glavnog vremena1 za odgovarajue
porudbine.
Rezultat je vremenski plan za svaki proizvod i svaku proizvodnu
oblast. Planiranje kapaciteta osoblja ocenjuje broj i tip radnika,
supervizora i menadera koji su neophodni da bi se ostvario glavni
plan proizvodnje.
Rasporeivanje proizvodnje - rasporeuje odreene proizvodne
ureaje za proizvodnju gotovih proizvoda prema glavnom rasporedu proizvodnje. Ovo omoguava menaderima da kontroliu
projekte i vremena zavretka projekta i odreuju uticaj problema
na projektovane datume zavretka.
Projektovanje i razvoj proizvoda - integrie informacije o
trokovima komponenti u dizajn/inenjering proizvoda kako bi
smanjili trokove. Na primer, projektant proizvoda moe da poredi
trokove komponenata sa dva ili tri alternativna izvora i izgradi
komponente koje su trokovno efektivne u dizajn proizvoda pre
nego to proizvod krene u proizvodnju.
1
Glavno vreme (Lead time) je vreme za koje dobavlja prihvata i obrauje porudbinu i
isporuuje je proizvoau.
329
Idealni sistem za raunarsku integrisanu proizvodnju (Computer Integrated Manufacturing CIM) integrie sav softver i hardver neophodan za proizvodnju sa integrisanom bazom podataka proizvodnje. Neke
komponente CIM-a su: projektovanje proizvoda (Computer-aided Design
CAD), projektovanje tehnologije (Computer-aided Manufacturing
CAM), upravljanje kvalitetom (Computer-aided Quality Assurance
CAQ), planiranje proizvodnje (Computer-aided process planning CAPP),
upravljanje materijalima (Materials Management), logistika podrka i dr.
Ovaj koncept eliminie uska grla u proizvodnji, smanjuje glavna vremena, trokove projektovanja, zalihe u proizvodnji i trokove radne snage i
poveava produktivnost projektovanja i inenjeringa.
Sa ERP sistemima, podaci iz prognoze o prodaji ulaze u sistem planiranja
prodaje i operacija (Sales and Operation Planning SOP) koji odreuje
zahtevane resurse proizvodnje, nivo proizvodnje i razvija proizvodne
planove (Slika 13.1). Glavni plan proizvodnje (MPS) odreuje vremena
zavretka i neophodne koliine gotovih proizvoda. MRP, dalje, razvija
detaljan plan materijala i odreuje ta treba da se porui i u koje vreme.
Planirane porudbine se alju proizvodnji u vidu radnih naloga. Svaki
radni nalog ukljuuje listu zahtevanih materijala sa sastavnice (BOM) i
proizvodne operacije koje treba izvriti. Proces proizvodnje utie na kapacitet, trokove zaliha, izvetavanje i analize.
Slika 13.1. Planiranje i izvravanje proizvodnje

330
Web tehnologije omoguavaju dobavljaima da vide zahteve za ponudama (Requests for Proposals), tehnike specikacije i zahteve za nabavkom,
to omoguava bri odziv na zahteve klijenata.
13.1. SAP R/3 ERP reenje

Prikazae se jedan scenario koji opisuje optimalno reenje za proizvodnju lekova u jednoj farmaceutskoj kompaniji.
SCENARIO 1:
Optimalno reenje za farmaceutsku industriju je implementacija sledeih
modula:
Planiranje proizvodnje i kontrola (Production Planning and Control PP-PI)
Upravljanje kvalitetom (Quality Management QM)
Menadment materijala (Materials Management MM)
Menadment skladita (Warehouse management WH)
Prodaja i distribucija (Sales and Distribution SD)
Finansijsko raunovodstvo (Financial Accounting FA)
Kontrola (Controlling CO)
Odravanje pogona (Plant Maintenance PM)
Tip proizvodnje u farmaceutskoj industriji je proizvodnja za zalihe
(make-to-stock). Za farmaceutsku industriju u proizvodnji je korien
modul PP-PI, modul upravljanja proizvodnjom za procesnu industriju.
Osnovni procesi mogu se ukratko opisati na sledei nain:
Obradom planova prodaje nastaju planovi proizvodnje.
Operativnim planiranjem (MRP) nastaju planovi nabavke i planski
nalozi za proizvodnju.
Posle provere svih raspoloivih resursa kreiraju se radni nalozi.
Nakon izjednaavanja kapaciteta CRP (Capacity Requirement
Planning) i provere radnih naloga prema prioritetima proizvodnje
lansiraju se radni nalozi.
Lansiranjem radnih naloga kreira se i potrebna dokumentacija
za izdavanje sirovina i ambalae sa logistikih skladita, odnosno
poluproizvoda sa pogonskih skladita.
Potvrivanje radnih naloga inicira praenje prijema poluproizvoda
na pogonska, odnosno gotovih proizvoda na logistika skladita.
331
Tehniko zavravanje radnih naloga je zavretak ovog uproenog

modela.
Osnovni procesi u upravljanju proizvodnjom, njihova struktura meuzavisnosti i veze sa drugim modulima (prodaja, kontrola, upravljanje
materijalima, kontrola kvaliteta) dati su na slici 13.2.
Ekranski prikazi SAP R/3 ERP reenja za upravljanje proizvodnjom su
dati na slikama 13.3, 13.4, 13.5, 13.6 i 13.7.
Projekt LESAP: modul PP - cjeloviti prikaz
SD-13
PP-21
Obrada plana
prodaje
PP-24
Simulacijsko
planiranje - LTP
Potrebe za
materijalima
Potrebe za
radnim satima
PP-23
Operativno planir.
MRP / MPS
PP-11, PP-12 PP
matini podaci
Planski nalozi
za prizvodnju
Planski nalozi za
nabavku
MM-02
PP-51
Eksterno
podugovaranje
MM-26
PP-52
Interno
podugovaranje
MM-12
PP-25
Procena kapaciteta
PP-31 Kreiranje
radnih naloga
PP-61, 62, 63
Specijalna i
korektivna proizv.
Radni nalozi
PP-26
Izjednaavanje
kapaciteta - CRP
PP-32 Provera
radnih naloga
PP-47 Kreiranje
zahteva za dopunu
podruja izdavanja
Lista
rezervacija
MM-19
PP-33 Lansiranje
radnih naloga
PP-44 Evidencija
potronje materijala
na RN
Trebovanje (Izdatnica)
MM-16
PP-34 Potvrivanje
radnih naloga
PP-45,46 Prijem
proizvoda sa RN na
skladite
Prijemnica
MM-14
QM-06
PP-35 Tehniko
zavravanje RN
CO-41
CO-42
CO-43
CO-44
Slika 13.2. Osnovni procesi upravljanja proizvodnjom za farmaceutsku industriju
332
Slika 13.3. Ekranski prikaz MRP1
333
334
Slika 13.7. Ekranski prikaz rasporeivanja rada
SAP nudi puno reenja za farmacetsku industriju koja druga ERP reenja
nemaju, to ga i izdvaja u odnosu na druge. Na primer, proraun aktivnih
supstanci u farmaceutskoj industriji. S obzirom da aktivne sirovine veoma
retko stiu u istim procentualnim odnosima (to im i samo ime kae),
dolazi do potrebe da se u proizvodnji stalno mora raunati receptura za
odreenu seriju proizvoda iz poetka. SAP R/3 i za ovo ima reenje zato
to je mogue denisati varijabilnu sastavnicu koja zavisi od kvaliteta i
sadraja aktivnih supstanci. Za svaku posebnu seriju takve sirovine, sistem automatski proraunava potrebe za svim ostalim komponentama
u sastavnici.
Izvetajni sistem R/3 je takoe originalno reenje. Pored velikog broja
predenisanih izvetaja, R/3 nudi mogunost da se veoma jednostavno
kreiraju izvetaji prema elji i potrebama korisnika bez dodatnog programiranja (Slika 13.8). Meutim, ukoliko ni to ne zadovoljava sve potrebe,
R/3 ima snano razvijene alate u okviru svog framework-a.
335
Slika 13.8: Ekranski prikaz izvetaja naloga [2]
14. ERP sistemi: Ljudski resursi
Poslovni procesi koji podravaju upravljanje ljudskim resursima (Human Resources HR) mogu se kategorizovati u operativne i procese
odluivanja. Procesi na operativnom nivou ukljuuju kreiranje i odravanje
informacija o zaposlenima, njihovim pozicijama i aplikacijama za posao.
Druge vane aktivnosti na operativnom nivou ukljuuju administriranje
plata, menadment performansi, razne potvrde i izvetaje. Na osnovu ovih
informacija menaderi odluuju kako efektivno rasporediti ljudske resurse.
Obuavanje zaposlenih i profesionalni razvoj zaposlenih su kritini za
odravanje odgovarajuih vetina kako bi se i dalje poboljavala produktivnost i odala lojalnost i moral kod radnika.
336
HR modul unutar jednog ERP sistema povezuje HR aplikacije sa nansijskim sistemima. Neke od komponenti HR modula su HR Menadment,
Plate, Menadment rada i vremena, Web izvetavanje o linim i poslovnim
podacima i sl. (Tabela 14.1).
Tabela 14.1. HR procesi podranih ERP sistemima
15. Menadment lanca snabdevanja i

elektronsko trite
Trina konkurencija, promena potreba klijenata, promene trita, krai
ivotni ciklusi proizvoda i globalna konkurencija karakteriu trenutno
poslovno okruenje. Svrha upravljanja lancima snabdevanja (Supply Chain
Management SCM) je da se dostigne integrisano planiranje kroz aktivnosti
lanca snabdevanja (Slika 15.2). SCM podrazumeva planiranje i upravljanje
tokom dobara i usluga, informacija i novca kroz lanac snabdevanja, poevi
od nabavljanja sirovina do nalnih proizvoda u rukama klijenata.
337
Slika 15.1. SAP ekran (Prikazivanje optih podataka)
Slika 15.2. Upravljanje lancima snabdevanja
338
Tranzicija od ranijeg lanca snabdevanja ka novom lancu tranje je

prikazana na slici 15.3.
Slika 15.3. Prelaz sa starog lanca snabdevanja na novi lanac tranje
Sistemi upravljanja lancima snabdevanja kontinualno povezuju aktivnosti nabavke, proizvodnje i distribucije proizvoda od dobavljaa ka
kupcima. Sa jednim SCM sistemom i kontinualnim popunjavanjem dobara
na skladitu, eliminiu se zalihe, a proizvodnja zapoinje tek onda kada se
dobije porudbina (Slika 15.4).
Slika 15.4. Sistemi upravljanja lancima snabdevanja
339
Da bi se kompanije brzo odazvale zahtevima klijenata, menaderi

moraju da imaju informacije o aktivnostima POS terminala, prognozama
potreba, projekcijama rasta, planovima proizvodnje, bilansu zaliha i kretanju proizvoda kroz lanac snabdevanja. Namena takve informacije je da
se raspored proizvodnje prilagodi potrebama klijenata.
Kompanija Hewlett Packard je razvila Web zasnovani sistem upravljanja
lancom snabdevanja sa sistemom porudbine koji zapoinje tako to klijent
kreira porudbinu on-line. Porudbina se iz sistema unosa porudbine
prosleuje proizvodnji i sistemu isporuke. Odatle se porudbina prenosi
do jednog od nekoliko rmi dobavljaa koji verikuje porudbinu sa HPom kako bi osigurala da se proizvod, u ovom sluaju PC moe proizvesti.
Porudbina se dalje prosleuje sistemu kontrole proizvodnje koja izdaje bar
kodovane etikete fabrici gde se montira proizvod. Istovremeno, porueni
delovi se prosleuju do magacina dobavljaa i sistemu za upravljanje
zalihama. Radnici montiraju i pakuju raunar i prevoze ga do klijenta.
Isporuka se nagdleda i prati preko HP-ovog sistema za upravljanje lancima
snabdevanja, koji se direktno povezuje sa distributerima. Proteklo vreme
od unosa porudbine do isporuke je 48 sati. Sa ovim sistemom, dobavlja
i HP su eliminisali zalihe, smanjili vreme ciklusa sa jedne nedelje na 48
sati i umanjili greke. HP je proirio ovaj sistem na globalni B2B sistem
za praenje porudbina, izvetavanje i podrku. Trenutno njihov sajt radi
na 15 jezika u 180 zemalja (Hewlett Packard, 2002).
Slika 15.5. Elektronski lanac snabdevanja
340
ERP sistemi su osnova za elektronsko trite (eMarketplace). Prednosti

elektronskog lanca vrednosti (eSupply chain) su smanjena vremena ciklusa,
prisnija veza sa partnerima, rast prihoda, smanjenje trokova i vremena
proizvodnje, optimizovano upravljanje zalihama, ekasnija distribucija i
kolaborativniji proces poslovanja.
Rezime
1. Moduli prodaje i marketinga u ERP sistemu su projektovani da podre
unoenje porudbina, generisanje zaliha, obraivanje isporuka, fakturisanje i obradu plaanja. Ovaj modul je osnova CRM sistema.
CRM moduli podravaju menadment prodaje, kontakt menadment,
menadment voenja i konguracije.
2. Namena modula raunovodstvo i nansije je da podre funkcije nansijskog raunovodstva i upravljakog raunovodstva. Informacije
o nansijama se kreiraju, odravaju i auriraju u svrhe izvetavanja.
Informacije upravljakog raunovodstva su interne i projektovane su
da podre donoenje upravljakih odluka.
3. Moduli upravljanja proizvodnjom i materijalima pokazuju kako je
proizvodni plan zasnovan na predvianju prodaje. Jednom kada je
razvijen plan prodaje, menadmenta tranje odreuje koliine i datume
koji su neophodni za proizvodnju gotovih proizvoda.
4. Namena SCM (Supply Chain Management) je da povee sve aktivnosti
kroz lanac nabavke i to od nabavke sirovina do prodaje proizvoda klijentima. Kod novijih lanaca snabdevanja postoji prisnije partnerstvo
izmeu proizvoaa i trgovaca na malo koji dele informacije o prodaji
i nivoima zaliha. Uvoenje elektronskog poslovanja stvara virtuelne
vrednosne lance koji olakavaju interaktivne odnose i deljenje informacija izmeu dobavljaa, proizvoaa, prodavaca i klijenata. ERP je
osnova za elektronsko poslovanje (eBusiness) jer obezbeuje osnovne
podatke za Web transakcije. ERP je takoe osnova za sisteme poslovne
inteligencije koji menaderima pruaju informacije neophodne za
donoenje stratekih odluka.
341

1. Objasnite razliku izmeu back oce i front oce-a.
2. ta omoguava CRM softver?
3. Da li se vie isplati razvijati u kui ili nabaviti gotovo ERP reenje?
4. ta se podrazumeva pod terminom just-in-time proizvodnja?
5. Kako funkcionie CIM (raunarska integrisana proizvodnja)?
6. Kako ERP sistemi poboljavaju SCM? Navedite primere za sledee:
a. Povezivanje dobavljaa i proizvoaa
b. Povezivanje klijenata i proizvoaa
c. Povezivanje proizvoaa i prodavaca
Reference
[1] Bocij. P., D. Chaey, A. Greasley i S. Hickie, Business Information Systems

Technology, Development and Management for the e-business, drugo
izdanje, Prentice Hall, Harlow 2003.
[2] Njegu, A., Z. urevi, Upravljanje proizvodnjom u farmaceutskoj
industriji uz pomo SAP R/3 reenja, 13. festival informatikih dostignua
INFOFEST, Budva, 2006.
[3] SAP Library,
http://help.sap.com/saphelp_46c/helpdata/en/73/69f5c755bb11d1896800
00e829fbbd/frameset.htm.
[4] Sumner, M. Enterprise Resource Planning, Prentice-Hall, New Jersey, 2005.
[5] Uitgeverij, B., ERP with Navision a product of Microsoft Business
Solutions, Microsoft, Amsterdam, 2004.
342
Odlukom Senata Univerziteta Singidunum, Beogrd, broj 636/08 od 12.06.2008,

ovaj udbenik je odobren kao osnovno nastavno sredstvo na studijskim programima koji
se realizuju na integrisanim studijama Univerziteta Singidunum.
CIP -
,
007:004(075.8)
004(075.8)
, , 1971Poslovni informacioni sistemi / Angelina,
Njegu. - 3. izd. - Beograd : Univerzitet
Singidunum, 2009 (Loznica : Mladost grup). IX, 342 str. : ilustr. ; 24 cm
Tira 250. - Napomene i bibliografske
reference uz tekst. - Bibliograja uz svako
poglavlje.
ISBN 978-86-7912-231-5
) b)
COBISS.SR-ID 172026636
2009.
Sva prava zadrana. Ni jedan deo ove publikacije ne moe biti reprodukovan u bilo kom
vidu i putem bilo kog medija, u delovima ili celini bez prethodne pismene saglasnosti
izdavaa.

US - Poslovni Informacioni Sistemi

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

US - Poslovni Informacioni Sistemi

Uploaded by

Copyright:

Available Formats

UNIVERZITET SINGIDUNUM

Prof. dr Angelina Njegu

POSLOVNI INFORMACIONI SISTEMI

Mojim roditeljima, Gospavi i Vuksanu Njegu

1. OSNOVNI KONCEPTI POSLOVNIH

1.2. INFORMACIONI SISTEMI

1.3. INFORMACIONA TEHNOLOGIJA

2. ARHITEKTURA INFORMACIONIH SISTEMA

3. POSLOVNI INFORMACIONI SISTEMI

4. METODOLOKE OSNOVE RAZVOJA

4.1. MODELI I MODELIRANJE

5.3.1. Model sluajeva korienja

7.2. PRIMENA SKLADITA PODATAKA

9. OTKRIVANJE ZNANJA I DATA MINING

10. POSLOVNA INTELIGENCIJA

MODULI POSLOVNIH INFORMACIONIH SISTEMA

12. ERP SISTEMI: RAUNOVODSTVO I FINANSIJE

13. ERP SISTEMI: PROIZVODNJA I UPRAVLJANJE

14 .ERP SISTEMI: LJUDSKI RESURSI

15. MENADMENT LANCA SNABDEVANJA I

Nakon savladavanja ove knjige, studenti e se osposobiti da:

1. Osnovni koncepti poslovnih informacionih

1.1. Opta teorija sistema

POSLOVNI INFORMACIONI SITEMI

Slika 1.1. Opta definicija sistema

Svaki sistem mogue je dekomponovati na podsisteme. Istovremeno,

1.2. Informacioni sistemi

Slika 1.2. Poloaj informacionog sistema u odnosu na realni sistem

Za veinu ljudi, sistemi su preveliki i kompleksni da bi se shvatili u

POSLOVNI INFORMACIONI SITEMI

1.3. Informaciona tehnologija

Hardware podrazumeva ziku opremu kao to su mehaniki,

1.4. Automatizovani alati i tehnologije

POSLOVNI INFORMACIONI SITEMI

Slika 1.3. Arhitektura CASE alata

1.4.1. Evolucija CASE tehnologije

1.4.2. Automatizovani alati

POSLOVNI INFORMACIONI SITEMI

inenjering unapred (forward engineering) - sposobnost CASE

Slika 1.4. Inenjering unapred/reverzni

softver za drugim bazama podataka i raunarskim mreama.

2. Arhitektura informacionih sistema

Vlasnici sistema (System Owners) nansiraju razvoj i odravanje

UVOD U POSLOVNE INFORMACIONE SISTEME

Kao to je prikazano na slici 2.1., svaka grupa stakeholders-a je jedan

2.1. Blokovi znanja

POSLOVNI INFORMACIONI SITEMI

Slika 2.1. Fundamentalni blokovi informacionih sistema1

POGLED VLASNIKA SISTEMA NA SISTEM PODATAKA

Kupci dostavljaju porudbine.

POSLOVNI INFORMACIONI SITEMI

POGLED PROJEKTANTA SISTEMA NA SISTEM PODATAKA

2.2. Blokovi procesa

POSLOVNI INFORMACIONI SITEMI

Entropija je termin koji se koristi za opisivanje prirodnog i neizbenog

2.3. Blokovi komunikacije

UVOD U POSLOVNE INFORMACIONE SISTEME

POGLED VLASNIKA SISTEMA NA KOMUNIKACIJE

POSLOVNI INFORMACIONI SITEMI

POGLED GRADITELJA SISTEMA NA KOMUNIKACIJE

3. Poslovni informacioni sistemi

Imajui u vidu prethodno obrazloen pojam informacionih sistema dolazi

POSLOVNI INFORMACIONI SITEMI

3.1. ERP sistemi