prof. dr ing poliščuk e.

jaroslav

projektovanje informacionih sistema

2

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Prof. dr ing Poliščuk E. Jaroslav PROJEKTOVANJE INFORMACIONIH SISTEMA

Kompjuterska obrada knjige: autor E-mail: jaroslav@cg.ac.yu

Sva prava zadržava autor.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

3

PREDGOVOR
"Klasična predstava o svemiru, koji se sastoji od materije i energije, mora da ustupi mjesto predstavi o svijetu sastavljenom od tri komponente: energije, materije i informacija, jer bez informacija organizovani sistemi nisu mogući. Jedino moguće materijalističko tumačenje održavanja organizovanosti je neprekidno izvlačenje iz spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju" [A. Lerner, 2003]. Predviđanje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA, vodeća u svijetu u analizi kretanja u oblasti globalne industrije informatičke tehnologije, glasi: „Trend automatizacije informatičkih tehnologija će imati veliki uticaj na razvoj softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehničku podršku i umrežavanje. Neka informatička zaduženja će biti veća, neka će biti umanjena, neka prebačena u druge dijelove kompanije, a neka će biti ukinuta". Specijalizovani informatički radnici, koji se ističu samo svojim poznavanjem informatičkih tehnologija i vještinama vezanim za računare, bez posjedovanja drugih funkcionalnih znanja, biće manje potrebni, predviđaju „Gartner“-ovi analitičari. Prosječno informatičko odijeljenje u srednjim i velikim kompanijama će do 2010. godine biti za trideset procenata manje, tvrde analitičari tržišta kompanije „Gartner“, i zaključuju: „Informatički radnici budućnosti će biti zaposleni u jednom od četiri glavna područja: tehnološkoj infrastrukturi, projektovanju i upravljanju informatičkim sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima“. Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, rađena na osnovu dostupne literature i obrađuje savremeni pristup projektovanju IS. Izvori, na osnovu kojih je nastala ova knjiga, jednim dijelom su navedeni u samom tekstu knjige, dok je cjelovit pregled dan u okviru pregleda korištene literature. Zahvaljujem se autorima čiji su manji dijelovi radova, u djelimično izmijenjenom obliku, ušli u sastav ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglašeno, taj propust će rado biti naknadno otklonjen. U pojedinim slučajevima bilo je nemoguće razgraničiti autorstvo pojedinih tekstova, jer se isti ili sličan tekst mogao naći u različitim izvorima. Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalističkog studija Elektrotehničkog fakulteta u Podgorici i može poslužiti kao potrebna literatura.

4

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Knjiga može korisno poslužiti projektantima IS, kao i svima koji se bave razvojem savremenih IS ili žele da se detaljnije upoznaju sa ovom oblasti.

U Podgorici, septembar 2007. god.

Autor

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

5

SADRŽAJ
1. Opšte o informacionim sistemima ........................................................... 1.1. Uvod ...................................................................................................... 1.2. Pojam informacionog sistema................................................................ 1.3. Elementi i osobine sistema i informacionih sistema .............................. 1.4. Vrste informacionih sistema .................................................................. 1.5. Životni ciklus razvoja sistema ................................................................ 1.6. Kompleksnost razvoja informacionog sistema ...................................... 2. Planiranje razvoja informacionog sistema .............................................. 2.1. Modaliteti razvoja informacionog sistema ............................................. 2.2. Analiza izvodljivosti, troškova i koristi projekta ...................................... 2.3. Strategija i planiranje razvoja informacionog sistema ............................ 2.4. Modeli razvoja informacionih sistema .................................................... 2.5. Metodologija razvoja informacionih sistema .......................................... 2.6. Savremeni postupci razvoja informacionog sistema .............................. 3. Uvod u projektovanje i definisanje zahtjeva za informacionim sistemom ........................................................................... 3.1. Uvod u projektovanje i izgradnju informacionog sistema ....................... 3.2. Definisanje zahtjeva za informacionim sistemom ................................... 4. Analiza sistema ........................................................................................... 4.1. Uvod u analizu sistema .......................................................................... 4.2. Aktivnosti analize ................................................................................... 4.3. Definisanje zahtjeva koje sistem mora posjedovati ............................... 9 9 11 13 15 16 18 21 21 27 30 38 48 51 57 57 60 67 67 67 69

5. Modeliranje funkcija i procesa .................................................................. 77 5.1. Uvod u modeliranje funkcija i procesa ................................................... 77 5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnoloških procesa ................................................... 83 5.3. Modeliranje toka podataka ..................................................................... 89 5.4. Elementarni procesi ............................................................................... 98

........... Modeliranje događaja ..........6............................ 11.......................................................................1..................... Normalizacija .............5....................... 134 8..................................................... Osnovni pojmovi modela podataka . 132 8........... 136 8........................... Specifikacija i dizajn programske podrške ..... 123 7.. Informaciono inženjerstvo ........... 11.. Uvod u dizajn baza podataka ......... 151 9...................1.......... Matrica entiteti/događaji ..........................8..................... 148 9......................... 11............ 11.............................................................................................................2................................................... 11.. 166 10.......................... 129 7............................................................. 133 8. Sistemsko inženjerstvo .......................................... 181 11.............6........ 111 6......................................................... Logičko modeliranje podataka ..... Standardizacija i modularnost programske podrške ................................................. Organizacija modula i aplikacija ........... 168 10................................ Oblikovanje i arhitektura informacionog sistema .........5..........4.................................................3... Dizajn interfejsa ...5............ 163 10.................................2..........2........ 128 7....... Ugradnja pravila za očuvanje integriteta .... 180 10........................................................................... 162 10. CASE proizvodi ......2.....2.....3........... Podešavanje baze podataka ....3.………………………………… 130 8.................. Šifarski sistem ..1.......................................3....................................................................... 132 8......................... 176 10................................. 123 7.. Strukturirani dizajn ................................. 135 8......................................... Modeliranje procesa vođeno događajima .............................................................................................................................. Implementaciono projektovanje.....................6. Programsko inženjerstvo ................. Pristup oblikovanju programa ...... Model istorije života entiteta ................................................................... Uvod .. 101 6................ 11.......................................................4............................4....................................5....................... Razvoj modela podataka . 186 186 186 187 191 194 195 196 .... Dizajn baza podataka ............6 Poliščuk E........................... 151 9....... Mape dijaloga …………………………….......................................7...... 124 7....1............................. Jaroslav: Projektovanje informacionih sistema 6.................. Reverzno inženjerstvo .... Rječnik podataka – katalog .........…………………….............3.........................................................................................................................1......... 116 7........1.... Trigeri u relacionim bazama podataka .....................4............................. Denormalizacija .................. Inženjerski pristup izgradnji IS ............................................. Modeliranje podataka .... 101 6.................. generisanje i programiranje BP pomoću CASE alata ............. 162 10............7...........................2.............. Arhitektura informacionog sistema ....... Oblikovanje (dizajn) sistema .........9....... Ulančavanje procedura .............................. 153 10................................. 165 10...................... 11................. 164 10... Dizajn programske podrške ........................... Dijagram prelaza stanja .....

............................... Raspodjela zadataka ......... 14.................................. Izrada plana ......... 14........................ 14......................... 15........... Praćenje napretka (izvršenja) projekta ...4.......6.................4..... 251 .......... 12... 15.................11......1................. Izrada dokumentacije ............................................................................................. Tabele odlučivanja ...................... 13........ 13................................................Poliščuk E......... Organizacija i upravljanje projektom ............10........ Programiranje (kodiranje) .......................... Provjera ispravnosti informacionog sistema ...............8........................................................13.............5........................... Preporuke za planiranje poslova ..............5.................12............... 14..... 12.. Generički modeli organizacije . 12........................................ Dijagram toka (blok dijagram.................... Planiranje projekata .......... algoritam) ........................................................... 14..............2......................................................................3.............. Evidencija projekta .... 14. 15................ Pristup programiranju .... Programski jezici .......... Modeli timova ..................................................................... 13.................................... Obuka korisnika IS ..............3................... Uvođenje sistema u primjenu .................... Poboljšanje sistema i reinženjerstvo ....... Strukturirani prirodni jezik (pseudokod) ....... Tehnike za vremensko planiranje ...................... Organizacija i timski rad ..............................4...........................7................................ 14...... Elementi konfiguracije ..................................... 13........................................................................................... 14............................... Izrada sistema .. 14.............. 14................................................... 13..................9.................................... Organizacija velikih projekata ............................... Jaroslav: Projektovanje informacionih sistema 7 201 201 201 202 204 209 211 213 213 216 221 222 224 225 226 233 233 233 234 235 236 236 237 238 239 240 241 242 243 245 245 246 246 247 248 12..2.................................. Stablo odlučivanja ......................4.....................................................................1. Implementacija informacionog sistema .. 12.................................. 15...............................................................................6......................... Prikaz plana ..................................................................................... Primjena i održavanje informacionog sistema ....3.......................... 14................. Upravljanje projektom ............................................7. Održavanje informacionog sistema ..... 13................ 12...............................................5....... Literatura ........ 13....................5..... 13........... 14...2............................................. Struktogram ...2................1..........................................................1........................................ Logičko projektovanje programa i programski jezici ......... 15.........................6..... 14.... 14............................ Programski standardi i preporuke ...................................................................... Akcioni dijagram ..... 15............................................................3.......... 12...........

8 Poliščuk E. Jaroslav: Projektovanje informacionih sistema .

odnosno povećanje kvaliteta i brzine realizacije programskih proizvoda. generacije je bilo povećanje produktivnosti programiranja. U drugoj fazi se koriste asembleri (jezici 2. čija je čitljivost bila veoma mala i koji su zavisili od hardvera. U prošlosti je razvoj programskih proizvoda bio oslonjen na različite tipove alata za programiranje. takođe. generacije. Za organizaciju koja modernizuje IS. stepen razvoja IS. Bitna karakteristika 3GL je njihova nezavisnost od hardvera. metodologiju primjerenu tehnološkim mogućnostima. Neophodno je imati strategijsku sliku razvoja IS. zajednički model podataka i njihov standardni oblik. generacije (3rd generation languages (3GL)). i 2. Sa jezicima 3GL. bili zavisni od hardvera i teško čitljivi. Jaroslav: Projektovanje informacionih sistema 9 1. koji su. Opšte o informacionim sistemima 1. nije svrsishodno težiti za standardom koji bi čvrsto definisao pristup. generacije). koja će obezbjediti kompatibilnost sistema i biti fleksibilna u prihvatanju nove tehnologije. Jezici 3. generacije). metodu. Sa druge strane. proceduralno orijentisani. ne uzimajući u obzir vrstu primjene. kao i mašinski jezici i asembleri. Ono što je potrebno je dovoljno slobode kako bi korisnici mogli da razvijaju svoju inicijativu u kreiranju sistema koji im je potreban. Osnovna prednost uvođenja u upotrebu jezika 3. generacije su.Poliščuk E. u upotrebu je ušla i tehnika strukturiranog programiranja. Brzi tehnološki razvoj zahtjeva da se dugoročno zna šta se hoće. u upotrebu su ušli jezici 3. u trećoj fazi. karakteristike korisnika i osobine realnog sistema u kome IS djeluje. U prvoj fazi razvoja u upotrebi su bili mašinski jezici (jezici 1. Problem smanjenja performansi je rješavan uvođenjem u upotrebu sve „moćnijeg“ hardvera. Poslije jezika 1. povećanje produktivnosti je uzrokovalo smanjenje performansi (brzine rada) tadašnjih programskih proizvoda i funkcionalnosti (širine primjene) 3GL. sredstva i dokumentaciju. i prati dostignuća u tehnologiji i metodologiji projektovanja. Uvod Projektovanje informacionih sistema (IS) je kompleksna kreativna djelatnost koja zahtijeva sistemski pristup. šta podrazumjeva zajedničku mrežu za prenos. Totalno integrisani IS je nedostižan i nepotreban.1. a problem smanjene funkcionalnosti je rješavan . Pri tome je potrebno poštovanje pravila koja će omogućiti da razmjenjuju podatke.

Jaroslav: Projektovanje informacionih sistema tehnikom povezivanja programa. Od pomenutih 64% „ranih“ grešaka.1.1. očekivanja da će programski proizvodi. dok se preostalih 36% grešaka pojavljivalo tokom realizacije IS. koji su razvijeni upotrebom 3GL. Programiranje upotrebom 3GL je bilo neefikasno i dugotrajno. Međutim. svega 30% je otklonjeno prije isporuke softvera. 2000]. Tako. Identifikovani su slijedeći problemi kroz koje se softverska kriza prelamala. Osnovni pojavni oblik softverske krize je bio u tome da očekivani efekti od razvoja programskih proizvoda brzo izostaju. Ovo je dovelo do jedne „neprirodne“ raspodjele finansijskih sredstava. bez obzira na znatno povećanje ulaganja u ovu djelatnost. Povećanje cijene održavanja i neefikasno programiranje su doveli do velikih zakašnjenja u realizaciji projekata IS. Očekivani efekti ulaganja Ulaganje u softver. na primjer. što je ilustrovano dijagramom na slici 1. veliki projekti u SAD su . pratiti potrebe krajnjih korisnika i mogućnosti hardvera se već 70-ih godina nisu ostvarila. Pri tome. sa asemblerskim programima. kasno otkrivanje i otklanjanje grešaka iz početnih faza razvoja programskih proizvoda dovodi do eksponencijalnog rasta troškova uvođenja u upotrebu i održavanje proizvoda. otklanjanje strateške greške u fazi održavanja košta 100 puta više nego kad se greška otkrije na početku rada na projektu. uloženih u razvoj IS.10 Poliščuk E. ljudske resurse i razvoj programskog proizvoda Slika 1. ili daljim povećanjem mogućnosti samih 3GL. Prema tim podacima 64% grešaka pri razvoju IS se pravilo u toku analize korisničkih zahtjeva i projektovanja IS. Najveći dio programerskog vremena je odlazio na održavanje postojećih programskih proizvoda. prema kojoj preko 70% ukupnih sredstava uloženih u razvoj IS odlazi na njegovo održavanje [Mogin et al. što je dovelo do fenomena nazvanog softverska kriza. hardver. Grafički prikaz fenomena „softverska kriza“. Prema nekim podacima. Tvrdnja da je najveći dio programerskog vremena odlazio na održavanje postojećih programskih proizvoda se može potkrijepiti slijedećim statističkim podacima. pisanih pomoću 3GL. što je blokiralo dalji razvoj IS.

prema tome. 2. Granice sistema definišu skup objekata koji će se u tom sistemu posmatrati. Jaroslav: Projektovanje informacionih sistema 11 1985. koji bi podržali projektovanje IS ili automatizovali postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Zato je neophodno odrediti granice sistema koje izoluju objekte od interesa od "okoline" sistema. generacije (4th generation languages (4GL)).2 može predstavljati poslovni sistem. Pojam informacionog sistema Metodologija razvoja informacionih sistema (IS) treba da bude opšta. 3. a dejstvo sistema na okolinu "izlaz" sistema. To je vodilo ka formalizaciji metodologija i tehnika projektovanja IS i pojavi CASE proizvoda i jezika 4. Svi ovi uzroci su doveli do prethodno opisanih posljedica. cirkulaciju . Sistem je skup objekata i njihovih veza (medjusobno povezanih objekata). Objekti u sistemu se opisuju preko svojih svojstava koja se nazivaju atributima. Iz tih razloga je potrebno poći od slijedećih opštih pojmova i definicija. 1. Ovo. Nedostatak odgovarajućih softverskih alata za razvoj aplikacija IS. Nedostatak softverskih alata. primjenljiva na sisteme bilo koje vrste. odnosno na neki "opšti sistem".Poliščuk E. Projektovanje IS bez primjene odgovarajuće metodologije dovodi do lošeg projekta. takođe. što vodi ka neefikasnoj realizaciji i održavanju IS. U skladu sa navedenim činjenicama. mrežu puteva ili ulica. fragmentiranog i nekonzistentnog dokumentovanja i neusaglašenosti dijelova projekta IS. vodi ka nekvalitetnom projektu uslijed otežanog rukovođenja projektom. Objekti nekog sistema su povezani sa objektima van njegovih granica. koje su njegove funkcije i kakav je njegov položaj u sistemu u kome djeluje. Dejstvo okoline na sistem naziva se "ulaz". kao podrške odgovarajućim tehnikama i metodologijama. Rješenje softverske krize je.2. vremenom su identifikovani slijedeći uzroci softverske krize: 1. sistem za prenos električne energije. Sistem na slici 1. trebalo tražiti u otklanjanju navedena tri uzroka. Zahtjeva da se precizno definiše šta se pod pojmom IS podrazumjeva. pojave velikog broja grešaka i prekoračenja zadanih vremenskih rokova završetka projekta. godine „kasnili“ od 30 do 45 mjeseci. a ovi sa nekim drugim "daljim" i tako dalje.

kretanje materijala koji se obrađuje. objašnjenja. ima smisao obavještavanja. informacioni sistemi su sastavni deo upravljanja ("održanja željene organizovanosti") nekog sistema. "Informacija je nešto što ukida ili smanjuje neodređenost" [N. Objekti u sistemu mogu biti veoma različiti. a veze izmedju objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri načina: razmjenom materije. Jaroslav: Projektovanje informacionih sistema dokumenata unutar nekog poslovnog sistema. 1975]. prenošenja znanja. Winer. Pojmovi podatak i informacija se. Riječ informacija. Iz ugla upravljanja i donošenja odluka. itd. Medjutim.2. 1979]. Information System) je sistem u kome se veze izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija. Iz tog ugla posmatranja može im se pridodati atribut "upravljački" i definisati upravljački IS kao sistem koji prenosi. energije ili informacija. Ako se povežu definicije pojmova sistema i informacije. može se izvesti slijedeća opšta definicija informacionog sistema: Informacioni sistem (eng. Takođe. neophodno je i ova dva pojma precizno definisati i razgraničiti. Wilson. u svakodnevnom govoru. . informacija se može razmatrati kao svaka vrsta znanja ili poruka koja može da se upotrijebi za poboljšanje upravljanja u nekom sistemu. Opšti prikaz sistema. za precizno razgraničenje koncepata o kojima se govori. koriste kao sinonimi. u svakodnevnom govoru. OKOLINA O1 O2 (interfejs) IZLAZ ULAZ O3 On Slika 1.12 Poliščuk E. Za pojam informacije uobičajene su slijedeće definicije: "Informacija je kapacitet povećanja znanja" [I. čuva i obrađuje podatke pretvarajući ih u informacije potrebne za upravljanje.

5.3. Isti podaci mogu biti različito interpretirani od strane različitih ljudi u zavisnosti o njihovom znanju. Elementi i osobine sistema i informacionih sistema Mogu se izdvojiti slijedeći elementi sistema i definisati njihove glavne osobine: 1. odnosno komponente koje pripadaju sistemu. Karakteristike. kako bi se one mogle sačuvati ili prenijeti. Informacija je protumačeni podatak o pojavi koju podatak prikazuje. Međuzavisnost pokazuje . 1. koja sačinjavaju unutrašnji i vanjski činioci koji određuju i ograničavaju funkcionisanje sistema. 8. odnosno hijerarhijske veze koje određuju formalnu komunikaciju i upravljački lanac (npr. međuzavisnost i Organizacija je struktura i poredak. Granice.Poliščuk E. Krajnje tumačenje nekom podatku daje sam primalac (čovjek). Izlazi su elementi koji napuštaju sistem. Ulazi su elementi koji ulaze u sistem iz okoline. interakciju. koje opisuju organizaciju. Okolina je sve što je izvan granica sistema. Podsistemi. ustanova. 2. Ograničenja. uz pomoć različitih postupaka obrade podataka. definišu opseg i domašaj sistema. Jaroslav: Projektovanje informacionih sistema 13 Podatak je kodirana predstava o nekoj činjenici iz realnog svijeta. Proizvodnja sa Prodajom). Osnovna funkcija IS je čuvanje i prenos podataka o činjenicama iz sistema i njegove okoline i njihova obrada u informacije koje zahtjeva korisnik. preduzeće). 4. 7. 3. Interfejs je veze između sistema i njegove okoline. Nabavka sa Proizvodnjom. Znanje se gradi na osnovu novih informacija koje se nadovezuju na postojeće znanje. Interakcija predstavlja način na koji pojedine komponente sarađuju sa drugim komponentama (npr. 6. ali se još uvijek tiče sistema. on je nosilac informacije i služi za tehničko uobličavanje informacija. integrisanost.

“kompjuterski”) i sisteme koji se ne oslanjaju na računare. . skladištenje i pronalaženje informacija. Jaroslav: Projektovanje informacionih sistema da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati. odnosno informacioni sistemi. Informacioni sistem sadrži/predstavlja znanje organizacije koju podržava. osoblje). te se mogu nazvati organizacioni IS. proizvodnja). . (2) sistemi za upravljanje informacijama važnim za organizaciju i društvo. Korisnici informacionih sistema su poslovodstvo. ali obrađuju informacije. koju je teško u potpunosti definisati. računarski (“kompjuterizovani”. radnici (zaposleni. složeni interfejs prema okolini.14 Poliščuk E. programi.. Poslovni sistemi sadrže procese (npr. poređenje plana i realizacije). sirovine). ljudski resursi ili kapital. . alati. Informacija je postala upravljački resurs jednake važnosti kao što su vlasništvo (osnovna sredstva). Sačinjavaju ga ulazni podaci i izlazne informacije. mašine. izvršioce (osobe. Za informacione sisteme se mogu izdvojiti bitni elementi i definisati njihovne glavne osobine: (1) sistemi za obavještavanje. povratne veze (npr. energija. zapisivanje i pamćenje podataka. dokumenti). prerada. Poslovne sisteme sačinjavaju materijalni ulazi i izlazi (sirovine. obrada. izrade i održavanja IS se prevazilaze zbog važnosti IS za jedan poslovni sistem. skladišta podataka (informacija). dok je integrisanost mjera povezanosti komponenti. Informacioni sistem određuju slijedeće karakteristike: složena okolina. IS i aplikacije pokazuju se prijeko potrebnim za održavanje konkurentnosti ili postizanje kompetitivnog prestiža poslovnog sistema. tj. a sačinjavaju ga: prikupljanje podataka. Poslovni sistemi u kojima se IS primjenjuju visoko su zavisni o stalnoj raspoloživosti IS kroz duže vrijeme. kao i veliki obim i složenost podataka. obrada podataka. Pojam informacionog sistema podrazumijeva sisteme koji su podržani računarom. Upravljanje informacijama se obavlja bez obzira na vrstu sistema. Informacioni sistem je podsistem poslovnog sistema. Problemi projektovanja. skladišta materijala. procesi (obrada podataka o stanjima stvarnog sistema) i izvršioci (osobe. 1980].. kao i prikaz informacija u odgovarajućem obliku. složene veze između ulaza i izlaza (strukturno i algoritmički). (3) sistemi za upravljanje sadržajem ljudskih aktivnosti [Checkland. proizvodi) i informacioni tokovi (poruke. Ulaz u neki poslovni sistem predstavlja izlaz iz nekog drugog poslovnog sistema. klijenti i drugi. računari). koji uključuje različite ulaze i izlaze. Namjena IS je prikupljanje i pružanje informacija korisnicima u jednom ili više poslovnih sistema.

…) . periodično Sintetizovane. koji imaju zadatak da podržavaju upravljačku funkciju na osnovu dokazanih matematičkih/statističkih metoda. Sistemi za grupnu podršku [Group Support System. 7.4. odnosno sistemi sa ugrađenim znanjem i simulacijom zaključivanja. sinonim Data Processing System]. 4. Tabela 1. Ekspertni sistemi (ES) [Expert Systems (ES)]. Transakcioni informacioni sistemi (TIS) [Transaction Processing System (TPS). Upravljanje i nivoi IS su prikazani tabelom 1. Jaroslav: Projektovanje informacionih sistema 15 1. Izvršni informacioni sistemi [Executive Information System (EIS)]. 3. ko Niže poslovodstvo Srednje poslovodstvo Više poslovodstvo. koji služe za odlučivanje na osnovu nestrukturiranih podataka iz različitih izvora. 2. Sistemi za podršku odlučivanju (SPO) [Decision Support System (DSS)]. koji predstavljaju podvarijantu IS za izvršne rukovodioce.1. Informacioni sistem Transakcioni Upravljački Za podršku odlučivanju Informacije. Groupware (GSS)]. čija je namjena da evidentiraju i obrađuju podatke o poslovnim transakcijama. 5.Poliščuk E. Vrste informacionih sistema Mogu se izdvojiti slijedeće vrste informacionih sistema: 1.1. kada Obrada podataka. 6. Sistemi za automatizaciju kancelarijskog poslovanja [Office Automation Systems (OAS)]. Upravljački informacioni sistemi (UIS) [Management Information System (MIS)]. dnevno Zbirne. uprava Upravljanje Operativno Taktičko (trendovi) Strategijsko (“šta ako”. “ad hoc” Korisnici.

1. Detaljni/programski dizajn (Detailed/Program Design). Praćenje životnog ciklusa obezbjeđuje konzistentan i standardizovan način razvoja IS. te definisanju zahtjeva koji se postavljaju pred sistem. Mogu se izdvojiti slijedeći nazivi životnog ciklusa: životni ciklus razvoja IS.5. Jaroslav: Projektovanje informacionih sistema 1. Projekat prolazi kroz faze životnog ciklusa. Konceptualni/sistemski dizajn (Conceptual/System Design). Ciklus osigurava “kontrolne točke” za praćenje napretka. Sistemsko testiranje (System Testing). identifikovanju problema i ideja.3) potrebno je definisati mnogo kompleksnije faze. Primjer: Za životni ciklus razvoja softvera mogu se definisati slijedeće faze i zadaci: • • • • • • • Potreba analize i dizajna (Requirements Analysis & Specification).16 Poliščuk E. koje nužno treba obaviti tokom razvoja. Životni ciklus razvoja sistema (Systems Development Life-Cycle (SDLC)) 1. odnosno preglednu analizu problemskog područja i . Životni ciklus definiše faze i zadatke (aktivnosti). Doprinosi određivanju poslovnih ciljeva.5. određivanju načina njihovog rješavanja. 1.5. Implementacija/kodiranje (Implementation/Coding). Strategijsko planiranje razvoja IS počinje snimanjem stanja (inicijalna strategija). Predaja sistema (System Delivery). bez obzira na veličinu sistema koji se gradi. procjenu postignutih rezultata i donošenje odluka o daljnjim koracima. životni ciklus razvoja softvera i životni ciklus razvoja aplikacija. izvršavanje i nadzor razvojnog projekta.2. Pojedinačno i integralno testiranje (Unit & Integration Testing). Sadrži studiju izvodljivosti. Životni ciklus i faze razvoja informacionog sistema Za životni ciklus razvoja IS (slika 1. Svrha praćenja životnog ciklusa razvoja omogućava pravilno planiranje. Svaka pojedina aktivnost proizvodi skup rezultata. Pojam životnog ciklusa razvoja Naziv životnog ciklusa razvoja zavisi od konteksta u kome je upotrebljen.

Testiranje je provjera ugrađenih komponenti. 2005]. Vrši se detaljna analiza postojećeg sistema. oblikovan tako da ga razumiju dizajneri. da bi se dokazalo da sistem radi (da je ispravno napravljen). Jaroslav: Projektovanje informacionih sistema 17 određivanje (granica) projekata. Specifikacija zahtjeva je detaljni opis zahtjeva za IS. Detaljni dizajn predstavlja razradu rješenja. Služi za donošenje odluke o tome kako graditi sistem. a vrši se nakon odabira računarske platforme. Planiranje projekta se sastoji od izrade plana rada. te da radi ono što je zahtijevano (da je napravljen pravi sistem koji ispunjava zahtjeve korisnika). pohranjivanja podataka i programa. drugim riječima izvršiti tehničku specifikaciju sistema. Predstavlja model budućeg sistema. Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP). Integracija i provjera sistema je udruživanje dijelova i provjera cjeline.Poliščuk E. Poslovni cilj je izrada glavnog projekta informatizacije. Sadrži dizajn potrebnih rješenja. problema i poslovnih zahtjeva. Postoje rješenja koja ne treba dizajnirati. Dijagram životnog ciklusa i faza razvoja IS [Fertalj & Kalpić. odnosno izradu tehnološkog modela IS (pogled izvođača). predstavlja pogled projektanta na budući IS. Slika 1. Oblikovanje sistema. . određivanja kadrova za projekat. kodiranje procesa (funkcija) novog IS. Potrebno je izvršiti dizajn arhitekture. interfejsa. upravljanje i nadzor projekta. Analiza zahtjeva je detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi.3. odnosno dizajn (modeliranje) IS.

1.4. predstavlja novi projekat. u prihvatljivom vremenu i po opravdanoj . kao i izradu plana održavanja. Novi razvojni ciklus se provodi nakon preispitivanja čitavog sistema i konstatacije da su potrebne veće izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. Jaroslav: Projektovanje informacionih sistema Uvođenje u primjenu sistema predstavlja prenošenje radnih aktivnosti i konverzija podataka sa starog na novi sistem.4 su navedene tipične faze životnog ciklusa razvoja softvera. Održavanje se sastoji od izmjena sistema radi poboljšanja njegovih radnih karakteristika (performansi). Ciljevi i problemi razvoja informacionih sistema Osnovni cilj razvoja informacionog sistema je izgraditi sistem koji radi i koji je pouzdan. Na slici 1. Kompleksnost razvoja informacionog sistema 1.18 Poliščuk E. pomoć tehničkog osoblja korisnicima informacionog sistema u toku njegove upotrebe. najčešće. Održavanje podrazumjeva i podršku dobavljača opreme. 1. Slika 1. Prikaz faza životnog ciklusa razvoja softvera. poboljšanja ili prilagođavanja načina upotrebe. Novi razvojni ciklus. unutar zadanih granica.6. bez naglašavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima. prema zahtjevima korisnika. To podrazumjeva izgraditi sistem koji zadovoljava poslovne ciljeve.6.

uz troškove od 1.Poliščuk E. http://www. Ukupni gubici smatra se da su neizračunljivi. Denver Airport (1994): Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odlaganje otvaranja vazdušne luke u trajanju od 16 mjeseci.6. Oko 70% informacionih sistema u svijetu se smatra neuspješnim.2. Procenat uspješnih i neuspješnih projekata IS prema Standish Group. Prosječno prekoračenje troškova je 189%. srednje kompanije 1. Uzroci neuspjeha projekata informacionih sistema Razlozi neuspješnih projekata IS su različiti. Neki primjeri neuspješnih projekata i sistema London Ambulance System (1992): Nakon uvođenja u eksploataciju IS se dva puta "raspao" zbog niza grešaka. nedostatak usmjerenosti korisniku. 1994. 1. jer se do njih nije stiglo na vrijeme. sačinjavaju 16. a projekti završeni i u funkciji. nepouzdanost. duže trajanje i/ili reduciranu funkcionalnost 52. naročito zbog grešaka u upravljanju razvojem IS. zanemarivanje okruženja .3. Neki od problema koji se mogu pojaviti prilikom razvoja IS su: prekoračenje planiranog vremena i finansijskih sredstava.7%. a prosječno prekoračenje rokova 222%.2%. Neposredni trošak je bio relativno nizak (9 miliona £). kao i teškoće u održavanju IS. 1.standishgroup. Prosječno koštanje projekta prema The CHAOS Report [Standish Group. Projekti završeni na vrijeme. te posljedični gubitak klijenata od 450 miliona £.6. nesigurnost.1%. neelastičnost IS u primjeni.com] iznosi: velike kompanije 2. ali se vjeruje da su neki ljudi umrli. 2002. ali uz veće troškove. Mogu se izdvojiti slijedeći razlozi: složenost aplikacija.33 miliona $ i male kompanije 434 hiljade $.1 miliona $/dan. neispunjavanje zahtjeva. Jaroslav: Projektovanje informacionih sistema 19 cijeni. Taurus (1993): Projekat sistema automatizovanih transakcija Londonske berze prekinut je nakon 5 godina razvoja i troška od 75 miliona £. odnosno neodgovarajući sistem. iznosi 34% uspješnih projekata i 17% potpunih neuspjeha. Ariane 5 (1996): Raketa eksplodirala u lanseru radi niza softverskih grešaka. u okviru predviđenih sredstava i sa predviđenim funkcijama. Prekinutih projekata je 31.32 miliona $.

. formalno izvještavanje o napretku. neodgovarajuća analiza sistema. pretjerani optimizam. Jaroslav: Projektovanje informacionih sistema organizacije.6. oslonac na vanjske projektante i savjetnike. formalni nadzor nad projektom. Mnogi sistemi su propali. pa čak i svojevrsna zloporaba CASE alata. nerealno planiranje. Važno je da u procesu izgradnje sudjeluje i poslovodstvo. delegirano upravljanje projektima. da bi se upoznalo sa stvarnim mogućnostima i koristima uvođenja IS.20 Poliščuk E. ili su bili odbačeni. Ne treba isključiti i slijedeće uzroke neuspjeha: loša izvedba projekata. U našem okruženju uzroci neuspjeha se. • uključivanje korisnika. izostanak praćenja napretka i nedostatak komunikacije između korisnika i izvođača. upravljanje izvedbom. greške u dizajnu i kontroli kvaliteta. kao i podcijenjena uloga vlastitih stručnjaka. Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe. • planiranje. a informacije o neuspješnim projektima nerado se objavljuju. uglavnom. ne istražuju. a nisu razumjeli suštinu poslovnog sistema i poslovanja. a informatičar upoznaje(?) poslovanje i zna(?) kako izraditi IS. 1. Među najčešćim uzrocima može se pretpostaviti da su: loša organizacija i vođenje projekata. jer su se izvođači trudili napraviti lijepa programska rješenja. praćenje napretka.4. naročito jer donosi konačne (za poslovni sistem sudbonosne) odluke. Poboljšanje uspješnosti informacionih sistema Da bi se poboljšala uspješnost IS potrebno je: • projektovanje IS. neodgovarajući CASE alati i krivo korištenje.

uz izdvajanje vlastitog informatičkog odjela u glavnog izvođača. pomoć pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja. . kao i konsultativna pomoć prilikom ugradnje složenih poslovnih funkcija. 2.1. takva da ne postoje gotova rješenja na tržištu ili takva da organizacija pomoću nje postiže komparativnu prednost u odnosu na konkurenciju. Prednosti su višestruke. ili njegovih dijelova. Vanjski razvoj informacionog sistema Angažovanje vanjskih saradnika za razvoj informacijskog sistema. IS ili njegovi dijelovi izrađuju se po mjeri naručioca. Varijante su slijedeće: ugovoreni razvoj. odnosno ugovara se isporuka gotovog proizvoda ili dugoročna saradnja sa isporučiocem. U ovoj knjizi će biti razmatrani modaliteti razvoja koji se najčešće koriste. podrazumjeva pružanje pomoći u obrazovanju radnika informatičke struke. Postoje dodatni ili posebni razlozi kao što su povećana tajnost podataka i poslovnih procesa ili povećana zaštita IS. softverske kuće.2. Modaliteti razvoja informacionog sistema 2.1. Moguća varijanta je i nalaženje strateškog partnera na duži vremenski period. kao i povremeno ili dugoročno angažovanje spoljnih saradnika. Planiranje razvoja informacionog sistema 2. Prednosti ovakvog pristupa su fleksibilnost. sistem je prilagođen organizaciji/poslovanju. Razvoj vlastitim informatičkim snagama podrazumjeva osposobljavanje i angažiranje netehničkog osoblja. Jaroslav: Projektovanje informacionih sistema 21 2. upravljanje izvođenjem i/ili nadzor izvođenja. razvoj je skuplji i dugotrajniji i može povećati gomilanje zaostalog posla. Nedostaci su da ovaj pristup zahtijeva značajno vrijeme i napor. kreativnost i povećanje stručnosti vlastitog osoblja.Poliščuk E. Ovakav razvoj podrazumijeva dugotrajan postupak i odgovarajuću visoku cijenu. a po mogućnosti treba istovremeno poboljšati organizaciju/poslovanje poslovnog sistema. Vlastiti razvoj informacionog sistema Postoje različiti modaliteti razvoja informacionog sistema. Razvoj vlastitim snagama ima smisla kada se radi o programskoj podršci koja je posebnost organizacije.1. npr.1. Takođe se podrazumjeva kodiranje (generisanje) cjelovitog programskog sistema.

Nabavka poslovnih aplikacija Slijedeći modalitet razvoja IS je nabavka i prilagođavanje postojećih domaćih poslovnih aplikacija. SAP. uglavnom. Nužno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogućnost odlučivanja. gubitka nadzora nad sadašnjim i/ili budućim razvojem (zavisnost o dobavljaču). su: programski paketi za kancelarijsko poslovanje (npr. šta može uzrokovati da rješenja gube moguću komparativnu prednost (brzinu i lakoću primjene). šta zahtijeva istovremeno prilagođavanje programske opreme i promjenu organizacije/poslovanja. Primjeri aplikativnih paketa. payroll). propisima. podržavaju slijedeće aplikacije: finansijsko poslovanje (accounting). Microsoft Office). Cjeloviti sistemi za podršku poslovanju. Prednosti su raskošna funkcionalnost i kompatibilnost sa svjetskim poslovnim standardima.1. 2. programi za upravljanje dokumentima (npr. Poželjno je da se mogu prilagoditi potrebama. mjestimična tehnološka zastarjelost. dok se nedostatci ogledaju u neprilagođenosti domaćim uslovima i konkretnoj organizaciji/poslovanju. BAAN. Nabavka “gotovih” stranih poslovnih aplikacija. Mogu se nabaviti slijedeći sistemi za upravljanje poslovanjem.3. Dolazi do gubitka povjerljivih informacija. ima svoje prednosti i nedostatke. kao i gubitak vlastite stručnosti. prekapacitiranost dobavljača. J. Peoplesoft. Glomazni paketi mogu zahtijevati angažovanje velikog broja . Edvards. šta olakšava prilagođavanje aplikacija organizaciji/poslovanju. takođe.22 Poliščuk E. npr. Modaliteti ovakvog pristupa su slijedeći: otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz samostalno održavanje. upravljanje ljudskim resursima i plate (CG management. Jaroslav: Projektovanje informacionih sistema Nedostaci i rizici su takođe prisutni. Nedostatci su nepostojanje ili manjkavost pojedinih komponenti. Lotus Domino) ili specijalističke aplikacije za određene namjene.4. koji se mogu nabaviti kao gotovi proizvodi. proizvodnju (manufacturing). Prilagođavanje se obavlja slično razvoju. robno-materijalno poslovanje (material management/distribution). Nabavka gotovih aplikacija Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe.D.1. koji nose komercijalne nazive: Enterprise Resource Planning (ERP) systems. 2. Prednost ovog pristupa je usklađenost važećim uslovima.

2. pruža mogućnost prilagđavanja vlastitim . kapacitet. osim putem posebnog dogovora sa isporučiocem. Mane izvedbenog koda. kao i pomoć u razvoju vlastitih aplikacija. što se dokazuje referensama.7. što se može pokazati kao prednost u odnosu na konkurenciju.1. su: izvedbeni kôd podrazumijeva potpunu zavisnost od isporučioca. broj korisnika. uz izuzetak nekih opšte primjenjivih komercijalnih programa. tehničke mogućnosti (Client-Server. Osim toga. blagovremeno otklanjanje problema. brzina. referense dobavljača (prisutnost dobavljača na lokalnom tržištu) i podrška korisnicima. Prednost izvedbenog koda je i ta da se ne mora kupiti (skupi) razvojni programski alat u kojem je programski proizvod razvijan. ponuda gotovih aplikacija.5. obzirom na korisnika. OLTP. elastičnost.6. funkcionalnost. održavanje (dinamika razvoja i mogućnosti nabavke novih verzija). U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost. raspoloživost dokumentacije. OLAP). Dodatna prilagođavanja lako mogu postati predmetom ucjene. Pod podrškom korisnicima se podrazumjeva: školovanje. mogućnost prilagođavanja i prepravki.Poliščuk E. Takođe.1.1. Izvorni kôd omogućava stalni razvoj i praćenje vlastitih posebnosti. ne postoji mogućnost prilagođavanja specifičnim vlastitim potrebama. Kriterijumi za donošenje odluke o nabavci Opšti kriterijumi za donošenje odluke o razvoju IS su: • • • • • • cijena. 2. Jaroslav: Projektovanje informacionih sistema 23 konsultanata. interoperabilnost). Nabavka izvedbenog programskog koda Prednosti nabavke izvedbenog koda su: izvedbeni kôd je jeftiniji. Mogući modalitet nabavke je da se prilagođavanje vrši vlastitim snagama uz savjetovanje i pomoć dobavljača. Nabavka izvornog programskog koda Prednosti nabavke izvornog programskog koda su znatne. mogućnost obuke i trajne podrške. kredibilitet i održivost dobavljača na tržištu. tehničke konsultacije. brigu i odgovornost o njegovom održavanju preuzima isporučilac. tj. 2. ne postoji mogućnost razvoja programske opreme vlastitim snagama.

dok su izlazi moguća rješenja novog sistema i njihove karakteristike. Izbor modaliteta razvoja Određivanje mogućih rješenja podrazumjeva identifikaciju rješenja na osnovu poslovnih zahtjeva postavljenih tokom analize. Izvedbeni kôd treba preporučiti u slijedećim slučajevima: • kada se radi o standardnim. Naručilac se izlaže iskušenju da nekompetentno mijenja nabavljeni izvorni kôd. takođe. šta daje elastičnost pri promjenama organizacije poslovanja. a korisnik nema namjeru da se baviti detaljima te struke. Izvorni kôd je višestruko skuplji od izvedbenog.8. upotrebom generatora izvornog koda. Uvidom u kvalitetna gotova rješenja pomaže se razvoju vlastitih informatičkih radnika. ne može se povoljno kupiti sličan. Analiza izvodljivosti alternativnih rješenja se sastoji od procjena alternativa obzirom na tehničku. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. masovno prodavanim aplikacijama. a korisnik raspolaže vlastitim informatičkim snagama dovoljnim za projektovanje novog. • kada korisnik nema vlastite informatičke stručnjake. Održavanje je skuplje ukoliko se radi o programskoj opremi podložnoj promjenama. postavlja nerazumne uslove ili je u međuvremenu nestao sa tržišta. • kada isporučilac ne može preuzeti obavezu održavanja ili ne može garantovati da će ostati na tržištu. ekonomsku i vremensku izvodljivost. Preporuke za izbor programskog koda su slijedeće. • kada na tržištu ne postoji IS koji odgovara potrebama. prisutne. operativnu. Nema bojazni da će nakon prve potrebne izmjene prestati upotreba IS zbog toga što isporučilac nije trenutno dostupan. Ulazi su specifikacija računarske opreme i programske podrške. • kada se radi o visokostručnim aplikacijama koje se neće mnogo mijenjati. onesposobi aplikaciju za rad i izgubi pravo na održavanje. 2. Mane narudžbe izvornog koda su.1. Sniženje cijene izvornog koda može se postići automatizacijom kodiranja. Izvorni kôd treba preporučiti onda: • kada programska oprema predstavlja stratešku investiciju.24 Poliščuk E. Jaroslav: Projektovanje informacionih sistema potrebama. te odabrana tehnološka arhitektura. • kada korisnik nema novaca ili želje za vlastiti informatički razvoj. Ulazi su . • kada korisnik raspolaže kompetentnim informatičarima ili ima motiva razvijati vlastitu informatičku djelatnost.

Ocjenjivanje kriterijuma za izbor sistema Na osnovu opisa karakteristika ne može se sa sigurnošću procijeniti koji je sistem najbolji. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr.Poliščuk E. plan projekta. od 0 do 5). Procedura bodovanja kriterijuma je slijedeća. procjena veličine projekta. Dodjeljena ocjena se pomnoži težinskim faktorom kriterijuma za koji je donesena. a izlazi analiza izvodljivosti za svako moguće rješenje. Karakteristike: Operativni sistem Baza podataka Brzina pretraživanja i dohvat podataka Programski jezik Raspoloživ izvorni kod Korisnički interfejs Integrisani sistem pomoći (on-line help) Dokumentacija (na papiru) Mogućnosti aplikacije Integracija sa drugim aplikacijama Brzina ispisa računa Rad sa različitim štampačima Rad u mreži Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instalisanih paketa Datum prve instalacije Cijena paketa Cijena računara i sistemskog softvera Težinski Super Video Video Boss Video ZZ Video faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9 Ukupno bodova: 171 124 97 124 . Prijedlog rješenja sistema koji će se oblikovati i ugraditi se donosi na osnovu izbora onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivosti. referense i uslovi dobavljača. te se dobije broj bodova [Fertalj & Kalpić. Tabela 2.1. Oni kriterijumi koji su značajniji u uporedbi sistema dobivaju veće težinske faktore. od 1 do 4). 2. Odredi se težinski faktor za svaki kriterijum (npr. karakteristike i cijene hardvera i softvera.1. Da bi se pravilno uporedio značaj različitih kriterijuma koristi se sistem bodovanja. 2005]. Ulazi su napravljena analiza izvodljivosti. a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloženog sistema.9. Jaroslav: Projektovanje informacionih sistema 25 karakteristike mogućih rješenja. Primjer: Analiza izvodljivosti za moguća rješenja.

a želi se odabrati najbolje rješenje. Izbor ponuda se obavlja slijedećim redoslijedom: (1) provjera sadržaja ponuda. sij = vrijednost j . .to rješenje. Jaroslav: Projektovanje informacionih sistema Na kraju se saberu dodjeljeni bodovi po svim kriterijumima za svaki sistem: Si = 3sij wj j =1 n gdje su: Si = ukupna vrijednost i . funkcionalnosti sistema. Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zamišljeno. dodatna svojstva. . Ugovaranje posla se završava sklapanjem ugovora koji definiše uslove saradnje. Ulazi sadrže specifikacije zahtjeva za programsku podršku i računarsku opremu: funkcionalnost. prikupljaju se ponude koje su skup “referensi"). Izvršilac projekta treba biti stimulisan proporcionalno ostvarenoj. Super Video. ključne parametre performansi. Kod prikupljanja ponuda treba potencijalnom dobavljaču uputiti zahtjev za dostavljanje referensi (kada postoje različiti dobavljači i/ili proizvodi. Izlazi su lista potencijalnih dobavljača proizvoda ili usluga. wj = važnost ili težina j . nažalost. . vrši se na osnovu slijedećih ulaza i izlaza. (3) izbor objektivno najboljeg ponuđača (to se. integracije sa postojećim sistemom. Najbolji je onaj sistem sa najvećim brojem bodova (npr. tabela 2. kao i zahtjev za dostavljanje ponude sa informacijama o konfiguracijama.1). te kriterijumi za izbor.10.tog kriterijuma. održavanja i slično.tog rješenja. poželjno odvojenim ocjenjivanjem pojedinačnih ponuda. cijenama. isporuke i naplate.1. a mora se kupiti najjeftinije). Često se mogu javiti slijedeće nedoumice: • Šta učiniti kada su sistemi (pod)jednako bodovani? • Šta učiniti ako pojedino svojstvo ima više podsvojstava? 2.26 Poliščuk E.tog kriterijuma za i . Izbor dobavljača proizvoda ili usluga Definisanje kriterijuma i opcija. u praksi dokazanoj i od korisnika prihvaćenoj. vrlo teško uklapa u zakonske odredbe po kojima treba tačno specificirati što se želi. (2) izrada rang liste.. održavanju (kada se određeni proizvod može nabaviti od različitih dobavljača).. kod izbora dobavljača proizvoda ili usluga.

2. elastičnost i mogućnost prilagođavanja. npr. troškova i koristi projekta 2.2. (2) procjenu da li je projekat izvodljiv obzirom na raspoloživa sredstva. (4) radi se izvještaj o izvodljivosti i prezentira se relevantnim učesnicima radi komentara i mišljenja (može biti dio idejnog rješenja). (3) procjenjuje se da li projekat omogućava poboljšanja. opreme.operativna izvodljivost. itd. koju provode sistem analitičari.Poliščuk E. Treba na vrijeme uočiti otpore ulozi ili tehničkim . ekonomska izvodljivost. praktičnosti i isplativosti projekta IS. zadovoljstvo). odnosno mjerenje korisnosti. informacije (da li su dovoljne. ekonomiske aspekte (gdje spadaju problemi troškova i mogućnosti ušteda). prikladne. te početno izvodljiv projekat može postati neizvodljiv. (5) eventualni povratak u studiju izvodljivosti. korisne).tehnološka izvodljivost. kontrolu (u prvom redu sigurnost i zaštitu podataka). Ove analize treba da se vrše tokom planiranja.2.). Ništa manje bitni nisu ni odgovori na slijedeća pitanja: Koji je stav korisnika prema rješenju? i Da li će se sistem koristiti? Neophodni su podrška uprave i prihvatanje sistema od krajnjih korisnika. ažurne. 2. Nakon odluke o pokretanju projekta složenost i opseg projekta se mogu promijeniti. Izvještaj o izvodljivosti projekta Izvještaj o izvodljivosti projekta sačinjavaju slijedeće analize: • • • • organizaciono . odnosno revidirani izvještaj. Analiza organizaciono . Analiza izvodljivosti projekta Za pojedine projekte se vrši analiza njihove izvodljivosti.2. kao i usluge (poželjni i pouzdani servisi. tačne. Studija izvodljivosti (feasibility study) sadrži: (1) detaljnu provjeru projekta. Tu se neminovno nameću i slijedeća pitanja: Vrijedi li rješavati problem? i Da li predloženo rješenje rješava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno protočnost i odziv sistema u odnosu na ulaze). kao i procjenu prihvatljivosti rješenja (kasnije faze). točnost procjene izvodljivosti raste sa dubinom analize.1. vremenska izvodljivost. pravovremene. Analiza izvodljivosti.operativne izvodljivosti projekta sadrži procjenu hitnosti rješavanja problema (planiranje). efikasnost (odnosno poboljšavanje upotrebe raspoloživih resursa: ljudi. Praktično gledano. Jaroslav: Projektovanje informacionih sistema 27 2. tehničko . novca. nakon faze sistemske analize. ali i kasnije.

Očekivano vrijeme završetka može biti poželjno ili obavezno. . Procjena upotrebljivosti sistema se najlakše može izvršiti korištenjem prototipa. U prvom redu potrebno je izvršiti procjenu stanja na tržištu opreme.tehnološke izvodljivosti projekta sadrži procjenu mogućih rješenja i alternativa. CBA računa troškove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Analiza tehničko . Krajnjeg korisnika treba na vrijeme pripremiti za promjenu radnog okruženja i procedura. obzirom na raspoloživu stručnost. Namjeniti jednostavni interfejs za početnike i povremene korisnike. procjenu postojećih rješenja u drugim organizacijama (tamo gdje je moguće). Veoma bitna osobina je da se zastupljena tehnološka rješenja mogu jednostavno primijeniti. Jaroslav: Projektovanje informacionih sistema rješenjima sistema i predložiti načine njihovog otklanjanja. složenije operacije za iskusne korisnike. Raspoloživost tehnologije podrazumijeva da se primjenljiva tehnologija može nabaviti. ili ga u nekoj mjeri treba prilagoditi ili doraditi. iznos plata. Analiza vremenske izvodljivosti projekta treba da dâ odgovor da li su predviđeni rokovi ostvarivi. ima li to rješenje potrebne karakteristike. prihod.00 nakon ‘n’ godina u budućnosti. Potrebno je pravilno ocjeniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema. (2) povrat investicije (korist – trošak)/trošak (Internal Rate of Return). Ako je riječ o gotovom rješenju. Današnja vrijednost onoga što će postati $1. dobra referensa). (3) trenutak u kojem korist nadvlada trošak (Payback Point). . Troškovi i korist mogu biti mjerljivi (npr.koristi (cost-benefit analysis (CBA)).) i nemjerljivi (npr. kao i procjenu primjenjivosti različitih tehnologija.. Bolje je isporučiti ispravan sistem dva mjeseca kasnije. Obezbjediti da korisnik daje prednost ponuđenom rješenju u odnosu na postojeći način rada.000. Ništa manje bitno nije ni činjenica da li postoje potrebni stručnjaci za primjenu nove tehnologije.. Finansijski trošak i korist se mogu izraziti formulama: (1) razlika korist – trošak u nekom razdoblju (Net Present Value). brzina odlučivanja. prodaja.28 Poliščuk E.000 imaju trenutnu vrijednost od $100. cijena opreme. nego neispravan ili beskoristan na vrijeme! Ekonomska izvodljivost projekta će biti objašnjena preko analiza i uporedbe ukupnih troškova . . zadovoljstvo korisnika. ako se uzmu u obzir kamate ‘I’ iznosi: PV = 1/(1 + I)n = (1 + I) – n Razlika predstavlja kamatu koja se može zaraditi tim novcem ($ označava novčanu jedinicu u bilo kojoj valuti). Primjeri: • Troškovi razvoja od $100. Pri tome treba imati na umu da se i najnovija tehnologija može savladati.

08)5 = $20.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo: $30.2 i grafičkim prikazom tabele. Odnos trošak/korist je prikazan tabelom 2.417 Povrat investicije (Return On Investment (ROI)) se obično dijeli sa dužinom trajanja projekta kako bi se dobio godišnji ROI.000 / (1 + 0. .2. Jaroslav: Projektovanje informacionih sistema 29 • Korist projekta u iznosu od $30. 2005]. Primjer: Analiza trošak – korist [Fertalj & Kalpić.Poliščuk E. Nizak ROI (~ manji od 10% godišnje) može pokazivati da je korist preniska da bi bila isplativa. Tabela 2.

1. razmjene podataka i održavanja. Proizvodnja i Informatika često postoji više različitih tehničkih sistema ili aplikacija. problem povezivanja informacija pri pokušaju cjelovite interpretacije. 2. Jaroslav: Projektovanje informacionih sistema 2. odnosno planiranje akcija za postizanje ciljeva.2. uticaj). Uprava definiše viziju i misiju poslovnog sistema. Činioci koji utječu na postavljanje ciljeva su slijedeći: ograničenja (organizaciona. 1985].30 Poliščuk E. Na primjer. čemu i kako služe. Planiranje razvoja informacionog sistema Planiranje razvoja informacionog sistema treba da dâ odgovor na slijedeća pitanja: • • • • • Čime se poslovni sistem bavi (grana. zaposlenih (ugled. kojima će poslovni sistem u nekom razdoblju ispuniti svoju misiju. tržište. To ima za posljedicu umnožavanje informacija uz različito tumačenje u različitim dijelovima. proizvodi. zadaci i ciljevi poslovnog sistema? Koja je željena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje. finansijska. kako ostvariti povećanje proizvodnje ulaganjem u nove proizvodne tehnologije.3. zakonska). gdje je kratkoročno razdoblje obično manje od 2 godine. kvalitet. naročito kada svaka cjelina prikuplja samo njoj važne informacije. poboljšanjem sistema administracije). kako željeno postići (promjenom organizacije. nepotpunost informacija. tehnička sredstva. Strategija i planiranje razvoja informacionog sistema 2. tj. srednjoročno 2 do 5 godina i dugoročno više od 5 godina [Awad. potrebe i želje uprave.3. koje i kakve podatke sadrže? Postoje li aplikacije čiji je razvoj u toku? U kojem su stadijumu razvojni projekti? • Koje su potrebne aplikacije? • Koji su raspoloživi resursi (osoblje. . kao i problem različitog posluživanja. uz istovremeno održavanje kvaliteta proizvoda.3. prihodi). Na osnovu strategijskih ciljeva se definišu poslovni ciljevi i određuju zadaci. Finansije. takozvanih informatičkih ostrva. kao što su Uprava. i kako osigurati zadovoljstva i radne sposobnosti zaposlenih doškolovavanjem i mogućnostima napredovanja. konkurencija)? Koji su problemi. strategijske ciljeve. Pri tome se dobijaju odgovori: šta se želi postići (prepoznatljivost. u Poslovnom sistemu koji se sastoji od više cjelina. vremenski okviri. tehnologija)? Razlozi zbog kojih treba planirati IS su višestruki. poslovodstva. Definisanje poslovne strategije Poslovni ciljevi zahtjevaju definisanje poslovne strategije.

oformljenje projektantske ekipe (uključivanje . koga sastavlja sponzor projekta (organizator.3.3. Umjesto prema strategijskom planu. Prijedlog projekta sadrži sažetak projekta (naziv. Strategojsko planiranje IS je prikladno za stabilne poslovne sisteme. očekivanu korist. manjkavosti. U praksi situacija je slijedeća. odnosno prethodno istraživanje. budući da se dizajnom sistema predlažu ili nameću poboljšanja. planiranja IS u skladu sa strategijom razvoja poslovnog sistema. Prije pokretanja projekta potrebno je izvršiti snimak stanja. prijedlozi rješenja. prepoznavanje problema i potreba. što naglašava potrebu uvođenja novih funkcija. Nestabilnost aplikacija uzrokuje nedostatak podataka. odnosno organizacija i upravljanje projektom. neplanirano i nejasno povećanje troškova). Slijedi faza proučavanja problema. Sastoji se od uspostave smjera i prioriteta usklađivanja informacionih servisa u skladu sa misijom. Nezadovoljstvo podacima nastaje uslijed njihove nepouzdanosti. kao i traženje odgovora na pitanje "Da li je projekt vrijedan pažnje?". poslovni sistem se "dovodi u red" tokom informatizacije i pomoću informatizacije. tako da informatizacija bude podrška promjeni poslovnog sistema i poslovnih procesa. svrha). traženje odgovora na pitanja "Da li su problemi vrijedni rješavanja?“ i "Da li je gradnja isplativa?". sastoji se od slijedećih aktivnosti: izrada plana rada. cilj. zastario razvojni alat i prisutan problem njihovog održavanja. U praksi je teško izvodljivo u uslovima “preživljavanja”. Odabir i pokretanje projekta Prvenstveno pokretači promjena su korisnici. promjene poslovnih procesa (npr. očekivanu funkcionalnost. procjena izvodljivosti. kao i posebnosti i ograničenja. poslovne potrebe. Pokretači promjena mogu biti i pokazatelji poslovanja (npr. Odabir projekta se vrši na osnovu prijedloga projekta. tj. vizijom i ciljevima poslovnog sistema.Poliščuk E. kao i zastarila tehnologija (npr. Jaroslav: Projektovanje informacionih sistema 31 Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici. istraživanje koje prethodi projektu. odnosno njihovo nezadovoljstvo aplikacijama i/ili podacima i/ili reorganizacijom. promjene na Univerzitetu uzrokovane novim zakonom). predlagač). uska grla proizvodnje. postavljanje ciljeva. zastario interfejs Internet-a. Još se mogu navesti primjene metoda analize i dizajna za proučavanje poslovnog sistema. produbljivanje snimka. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa. pad prodaje. nedostupnosti. Radna grupa za odabir projekta odobrava projekat. sa ciljem definisanja opšteg (sveobuhvatnog) plana i arhitekture IS čiji razvoj slijedi. Planiranje projekta. 2. zastarile BP). a nezadovoljstvo reorganizacijom nastaje uslijed promjene organizacione strukture.

video i video igre. pružiti korisnicima lako savladive alate za pisanje izvještaja. Moguća prilika je mogućnost pozitivne promjene. Moguće je opciono provođenje procjena mogućih tehničkih rješenja. uspostava upravljanja i nadzora projekta. obavljanje zadataka. Snimanje stanja Snimanje stanja omogućava brzo istraživanje i evaluaciju problema. procjenu potreba za nadogradnjom (poboljšanjima). 5. pa treba objediniti skladišnu evidenciju. pri čemu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazama. Trenutno 3 različita sistema za unos narudžbi servisiraju odjele za audio. Svaki sistem ima vlastiti interfejs prema različitom skladišnom sistemu.3. uočavanje problema i nedostataka postojećeg IS. prikupljanja informacija. Brza ispravka. postizanje ciljeva. 2005].32 Poliščuk E. 4. mogućnosti ili direktive 1. na kraju. Snimanje stanja obuhvata identifikaciju korisnika i opsega postojećeg (postojećih) IS. vlasnika i viših rukovodilaca. uprava. Nedavno preuzimanje kompanija: Privatna predstava i Filmsko platno nametnulo je povećanje zahtjeva za protokom informacija i dokumenata. Hitnost HITNO 6 mjeseci 6 mjeseci Vidljivost Visoka Srednja Korist 175000 75000 Prioritet 2 2 Predloženo rješenje Novi razvoj Novi razvoj Srednja 515000 2 Novi razvoj 12 mjeseci Niska 15000 3 3 mjeseca Visoka 35000 1 Nakon razvoja novog sistema. . Izražena je nedoslijednost (nekonzistentnost) između podataka u evidencijama članova i narudžbi. npr. i. Postoji nedostatak pristupa informacijama nužnim za upravljanje i donošenje odluka. pocjenu potreba za izmjenama (prilagođavanjem i popravkama) i procjenu potreba za izradom novih IS ili podsistema IS (Tabela 2. mogućih prilika i direktiva. radnici različitih poslovnih područja ili organizacijskih jedinica. kao i evidentiranja problema i prijedloga. pri čemu je važno osigurati predanost učesnika zajedničkom cilju. dok je direktiva zahtjev ili ograničenje koji su nametnuti poslovnom politikom (npr.3.3). Vrijeme odgovora na narudžbu mjereno od vremena zaprimanja narudžbe do isporuke klijentu se povećalo na prosječno 15 dana. zakon). Pod problemom se podrazumjeva neželjena situacija koja sprječava potpuno ispunjenje svrhe. čak i kada ne postoji problem. a zatim novi razvoj. Ovo će se još pogoršati preuzimanjem dva dodatna sistema za obradu narudžbi (iz Privatna predstava i Filmsko platno). 2.4. Jaroslav: Projektovanje informacionih sistema učesnika iz različitih djelatnosti. Primjer: Postojeći problemi i prijedlozi rješenja [Fertalj & Kalpić. 2. 3. Kratko obrazloženje problema. Tabela 2. vanjski konsultanti). Snimanje poslovnog sistema se sastoji od pregleda poslovnih planova. najčešće intervjuisanjem korisnika. pravilnik) ili vanjskim uticajem (npr. kao i određivanje dosega projekta i početnog plana projekta. ako takvi postoje ili nisu “tajna”.

4). Planiranje projekta Planiranje projekta podrazumjeva određivanje namjene projekta i izdvajanje zadataka koji su saglasni poslovnim ciljevima. 12 mjeseci 3 mjeseca Niska Visoka nepoznata 65000 4 1 Vidljivost: U kojoj mjeri će rješenje ili novi sistem biti vidljivi korisnicima. kao i određivanje prioriteta. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama. Permissions. . obavlja razrada i raspodjela poslova. Constraints. Konsolidovani prijedlog projekta može poslužiti kao interni ugovor projekta (tabela 2. Postojeći sistem unosa narudžbi nije kompatibilan sa planiranim sistemom za automatsku identifikaciju (štapićasti kod) koji se razvija za skladište.3. ali su sigurnost i kontrola pristupa problematični. Nastoji se pronaći takva podjela posla na cjeline da cjelinu može obaviti jedna osoba ili ekipa. dodatna ocjena koristi može povećati ažurnost. aplikacijom ili podsistemom). Može se koristiti za prezentaciju projekta radi traženja saglasnosti o njegovom nastavku. Sistemi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni sa onim u Zvučna pozornica. Problemi sa podacima obuhvataju nedoslijednosti u podacima i nedostatak upravljanja ulazom i izmjenama. 6 mjeseci Srednja nepoznata 2 33 Novi razvoj. Korist: Paušalna procjena koliko bi rješenje povećalo dobit ili smanjilo trošak u jednoj godini.Poliščuk E. a zatim novi razvoj. Početni plan razvoja IS sadrži nazive podprojekata i omogućava doradu i ažuriranje u skladu sa napretkom projekta. Brza ispravka. Domet i razgraničenje projekata ili podprojekata (System boundary. a mogu biti informatizovani. 7. 2. Izrada početnog (preliminarnog) plana razvoja IS započinje podjelom projekta u manje cjeline i određivanje redoslijeda realizacije pojedinih podprojekata. Objectives. Postoji mogućnost uvođenja sistema naručivanja putem Interneta.5. End products (SCOPE)) daje odgovore na slijedeća pitanja: • • • • • • • Koje su granice sistema? Koji će zahtjevi biti ispunjeni? Šta ne može biti napravljeno? Šta neće biti napravljeno? Ko će. 8. kako i pod kojim uslovima moći koristiti rješenje? Kako se mjeri ili određuje uspjeh (neuspjeh)? Kako će se znati da je projekat gotov? Vremensko planiranje obuhvata određivanje prioritetnih zadataka i vremenskih okvira prioriteta. Jaroslav: Projektovanje informacionih sistema 6. Buduće verzije tek razvijenog sistema. da se cjelina može obaviti jednom metodom i posao završi jednim “proizvodom” (dokumentom.

uz preuzimanje podataka. tabela 2. 16. 1. 2. Izrada prototipa programske podrške za i-tu fazu realizacije.6.Kratko objašnjenje provedenih aktivnosti Činjenice i zaključci (može se potkrijepiti matricom problema i mogućih rješenja) • • • - Problemi i analiza problema Mogućnosti i analiza mogućnosti Direktive i implikacije • Detaljan prijedlog . Izvještaj o projektu Izvještaj o projektu obrađuje probleme i dostignuća projekta.Matrica obrazloženja problema . 15. • Sažetak . 12. Tabela 2. Nabavka sistema za upravljanje bazama podataka. Obuka za odabrane korisnike na β . Jaroslav: Projektovanje informacionih sistema Primjer: Početni (preliminarni) plan informacionog sistema.verziji.34 Poliščuk E.Kratko objašnjenje sadržaja izvještaja Prikupljene informacije . Testiranje kod korisnika u paralelnom radu sa dosadašnjim programom. 13. Uklanjanje uočenih nedostataka i izrada β . 7. Obuka za programere u jeziku za upravljanje bazama podataka.4. 9. Prikupljanje primjedbi korisnika i novih zahtjeva.Obrazloženje prijedloga * Hitne prepravke * Brze prepravke * Unapređenja * Novi razvoj Plan projekta * Početni ciljevi projekta * Početni glavni plan projekta (na nivou faza) * Detaljni plan za slijedeću fazu Prilozi . 8.(ostala dokumentacija) . 17. Uklanjanje nedostataka i izrada stabilne verzije. Obuka za upoznavanje sa mogućnostima programa za odabrano poslovodstvo. 14. Obuka za administratore baze podataka. Tabela 2. 3.verzije u informacionim sistemima. Obuka opšte informatičke pismenosti za rukovodioce odjeljenja. Uvođenje korištenja programa kod ostalih korisnika. 10.5. 4.Kratak opis projektnog zadatka . 5.verzije aplikacije.5. Zamjena dotadašnjeg programa novim programom. a može imati oblik prikazan tabelom 2.4. Izrada slijedeće faze/verzije programa. Povratak na tačku 5).Sažetak prijedloga .verzije programa. Testiranje α .Zahtjev za uslugama sistema . 11. 6. Obuka za ostale korisnike.Kratko obrazloženje očekivanih koristi . Izrada α .3. 2.

ciljevi i ograničenja Istraživanje uzroka problema.. brzi odgovor na zahtjeve klijenata. Jaroslav: Projektovanje informacionih sistema 35 2. odnos cijene i kvaliteta proizvoda. .koristi.3. Mogu se koristiti različite formalne metode. Uzroci i posljedice problema. odnosno analiza poslovnih procesa analizom od vrha prema dolje i uočavanje podataka povezanih sa procesima. se mogu ilustrovati na slijedećem jednostavnom primjeru: Problem: Vidljivi znak: Razlog: Uzrok: pad prodaje povećani opoziv (storno) narudžbi nezadovoljstvo kupaca spor sistem za naručivanje Zadatak analitičara je da razdvoji uzroke i posljedice problema. . Planiranje poslovnog sistema (Business Systems Planning (BSP)) firme IBM. kojima poslovodstvo posvećuje posebnu pažnju.. a može biti posljedica pomanjkanja osoblja. Vrši se detaljnija analiza problema. odnosno činilaca. koji mogu biti raznovrsni.7. Drugi primjer: Dug red u videoteci nije poseban problem. 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica ručnog unosa podataka i izdavanja računa.3.8.Poliščuk E. Ti činioci treba srazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr. imajući na umu misao: "Ne pokušavaj popraviti prije nego shvatiš kako radi!" Takođe je potrebno izvršiti analizu poslovnih procesa odgovarajući na pitanja: • Koji su najveći problemi? • Koja su moguća rješenja problema? • Kako informatizacija može pomoći? kao i grubo modeliranje postojećeg sistema. od kojih su najznačajnije: 1. njihovih uzroka i posljedica. 2. ). Analiza izvodljivosti i procjena troškova . Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rješavanja i da li je gradnja IS isplativa. 3. Određivanje poslovnih ciljeva Za projekte koji prođu početnu selekciju vrši se produbljivanje analize problema. Analiza kritičnih faktora uspjeha (Critical Success Factors (CSF)). 2.

2. Središnji računar radi na maksimumu svoga kapaciteta. Tabela 2. računarska oprema (npr. ANALIZA UZROKA I POSLJEDICA Problem ili mogućnost 1. odjel informatike smije zaposliti najviše tri stalno zaposlena radnika). Primjeri poslovnih ciljeva mogu biti raznovrsni. povećao se broj grešaka pri unosu. Jaroslav: Projektovanje informacionih sistema U razmatranom primjeru analitičar treba razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan. Novi sistem mora biti kompatibilan sa postojećim Windows XX standardom. kao primjeri. 2. CILJEVI I OGRANIČENJA SISTEMA Ciljevi sistema 1. Vrijeme odgovora na narudžbu je neprihvatljivo dugo. tako da se eliminiše upotreba Ograničenja sistema 1. Novi sistem mora biti kompatibilan sa već odabranim sistemom za automatsku identifikaciju štapićastim kodom. 5. 2005]. . projekat se mora obaviti bez nabavke novog hardvera ili poželjno je da trošak opreme predstavlja najmanje 33% budžeta). 3. Smanjiti vrijeme unosa pojedine narudžbe za 30%. 4. Ručni unos narudžbi svesti na 50% ukupnog broja. Vrijeme obrade narudžbe je isto. Ovdje će biti navedeni. njihovi ciljevi i ograničenja su prikazani u tabeli 2.6. šta se ogleda u sporijem radu aplikacije za unos narudžbi.6 [Fertalj & Kalpić. Ograničenja mogu biti slijedeća: osoblje (npr. Sistem previše zavisi o ručnom unosu. a broj službenika smanjen.. materijalni trošak (npr. Posljedica je da se narudžbe obrađuju duže nego je potrebno. neki od mogućih ciljeva: pomoći reorganizaciju u tržišno orijentisanom poslovnom sistemu prema EU normama. 3. uskladiti hijerarhiju odlučivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utrošak novca za . Prenijeti unos podataka sa središnjeg računara na PC. finansijska sredstva (npr. Pojedine vrijednosti se unose više puta. 3. osigurati informacije o izvorima.36 Poliščuk E.. razlozima i mjestu nastanka svakog troška u sistemu. Broj zaposlenih u obradi narudžbi se ne može povećati. Promet je povećan. Analiza uzroka i posljedice problema. Zamjeniti postojeće obrasce za prikupljanje narudžbi mrežnim sistemom između skladišta i prodaje. 2. Na ekranskoj formi računara za ručni unos smanjiti broj potrebnih pritisaka na tastaturu. Uzroci i posljedice 1. ukupni budžet projekta je XXXXX €) ili naknade izvođačima ne smiju prekoračiti XX% ukupnog iznosa). . Budući da službenici pokušavaju brže raditi. nabavka kancelarijskog i potrošnog materijala ne smije premašiti XXX €).

Tu spada ponovna procjena i preciziranje opsega projekta. grubi model sistema i to: model organizacije i resursa (kontekst. Modeliranje postojećeg sistema Svrha modeliranja postojećeg sistema je preciziranje dometa projekta. Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspješnosti. Obrasci za prikupljanje narudžbi iz skladišta nisu oblikovani za racionalno popunjavanje. 2. povećanje obima uslijed pogrešne procjene ili različitog tumačenja ciljeva između korisnika i izvođača. Poželjno je realizovati takav prototip koji će omogućiti procjenu mogućih tehničkih rješenja IS . Jaroslav: Projektovanje informacionih sistema 37 4. Planiranje informacionog sistema Planiranje informacionog sistema se sastoji od analize problema. informatičari). globalni model procesa (funkcionalna dekompozicija. tzv. Time se kasnije povećanje projekta. a po potrebi i revizija glavnog plana. kao i procjena ograničenja.3. ali će se barem moći kontrolisati. povoljnih prilika i mogućih rješenja problema.3. neće ukloniti. papirne dokumentacije. u zavisnosti o veličini čitavog projekta). kruženje dokumenata i protok informacija) i globalni model entiteti-veze (kategorije podataka.10. prostorni raspored sredstava). klase podataka (ne klase objekata!)). Planira se prototip koji se može uspješno i “brzo” realizirati (npr. izbjegavanje proučavanja tehničkih detalja u ranim fazama). definisanja ciljeva i zadataka informacionog sistema. ali značajno. kao i verifikacija razumijevanja problema i usaglašavanje percepcije sistema i stavova između učesnika (korisnici. 3 do 9 mjeseci. Tokom izvođenja projekta često se događa polagano. organizaciona struktura. Pri tome primjeniti taktiku skrivanja zanemarivanja detalja i usredotočenje na ono što je zaista važno (npr. tok ključnih poslovnih procesa. Granice projekta moraju biti definisane što je moguće preciznije.9. Kreirati globalni. puzeći domet projekta. 2. možda.Poliščuk E. okvirni. što dodatno usporava unos narudžbi.

Strategijske odrednice .Ekonomija . mogućnosti i analiza uzroka i posljedica za pojedine elemente • • • • . odbacivanje. Kada je riječ o informacionom sistemu.Preporuke unapređenja sistema .Performanse . Jaroslav: Projektovanje informacionih sistema (alternativa) i prijedlog najboljeg rješenja.Modeli sistema (ako nisu dio studije) . Modeli razvoja informacionih sistema 2.Djelotvornost . Greške iz prethodnih faza. Na kraju se (opet!) može očekivati pokretanje.1. Tabela 2.(ostala dokumentacija prema potrebi) 2. otkrivene u tekućoj. a pored toga vratiti uloženu investiciju.Modeli postojećeg sistema * Model interfejsa (kontekst) * Model resursa (prostor) * Model procesa (funkcija) * Model podataka (kategorije) • Analiza postojećeg sistema * problemi. Sekvencijalni (vodopadni) model razvoja informacionog sistema Polazna pretpostavka metodologije životnog ciklusa je da se faze razvoja realizuju strogo sekvencijalno.Kratki navod ciljeva unapređenja sistema .Plan projekta * Precizirati domet projekta * Revidirati glavni plan * Detaljni plan za slijedeći korak Dodaci . zahtjevaju da se one otklone i dokumentuju vraćanjem u prethodne i prolaskom kroz sve faze koje slijede iza faze . takođe.Ciljevi i prioriteti unapređenja sistema .Popis ostalih izvora informacija .4. istovremeno za cijeli programski proizvod. • Sažetak .Informacije .4. Istovremeno se. Tabela 2. Realizacija naredne faze ne započinje dok se tekuća faza ne završi. odgađanje ili prilagđavanje (ostalih. tada se svaka faza istovremeno primjenjuje na svaki od podsistema. mogućnosti i direktiva .Kratki navod sadržaja izvještaja Poznate informacije . pojedinih) projekata.Usluge (servisi) Detaljni prijedlozi .7 prikazuje idejno rješenje plana razvoja IS.Sažetak problema.Popis održanih razgovora i kordinisanih grupnih sastanaka .Opis tehnika korištenih u analizi Pregled postojećeg sistema .Kontrola .38 Poliščuk E. u okviru identifikovane arhitekture IS.7.Sažetak prijedloga . projektuje i shema baze podataka IS.

kao i u potrebi uvođenja prema gore (bottom up) modula.1(a)) redoslijedno (sekvencijalno) napreduje iz faze u fazu. Sekvencijalni pristup. Klasični vodopadni model (slika 2.Poliščuk E. 2. gdje postoje razrađene procedure ručne obrade ili računarski sistem koji treba unaprijediti. Jaroslav: Projektovanje informacionih sistema 39 gdje je greška napravljena. Takođe. U sekvencijalnom modelu primjene metodologije životnog ciklusa krajnji korisnik nije dovoljno uključen u proces razvoja programskog proizvoda. Mogu se izdvojiti slijedeće varijante sekvencijalnog (vodopadnog) modela: klasični vodopadni model. 4. postoji potreba da se u razvoj IS odjednom ulože značajna finansijska sredstva. čime se smanjuje rizik od neuspjeha razvoja. 2000]: 1. što je jako kasno jer se korekcija grešaka i održavanje komplikuju. Umjesto da to bude postupno. „V“ model i drugi manje značajni modeli. kao i evolutivni. Između početka projekta i prvih operativno primjenljivih rezultata kod korisnika vremenski interval je dosta dug. pored dobrih osobina. a produžava se vrijeme potrebno za dobijanje konačnog rješenja aplikacije. dobra dokumentovanost i praktično istovremeni završetak svih podsistema IS. . pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj. a neki od njih su slijedeći [Mogin et al. Sistem nije upotrebljiv dok nije u potpunosti gotov. 3. U cilju izbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup. Uzroci su višestruki. inkrementalni. metodološki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva. Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisnički zahtjevi često otkrivaju tek u fazi uvođenja aplikacije u upotrebu. u konačnom vremenu. za dobro definisano okruženje. Prikladan je velikim projektima (investicijama). Često se javlja potreba da se precizni. podsistema i sistema. doći do zadovoljavajućeg rješenja programskog proizvoda. Problem predstavlja i predodžba o proizvodu na osnovu pisane specifikacije. Nedostaci ovog modela su izraženi u slučaju grešaka ili novih/promijenjenih zahtjeva. Ovakav način primjene metodologije životnog ciklusa i strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primjene metodologije životnog ciklusa. zvjezdasti. spiralni. Nisu dozvoljene naknadne promjene rezultata prethodnih faza. Dobre strane ovog pristupa su: integrisanost IS. ovaj pristup daje dobre garancije da će. ne daje uvijek prave efekte kada je u pitanju ostvarenje prethodno definisanih ciljeva. Zahvaljujući dobroj dokumentovanosti pojednostavljeno je održavanje aplikacija IS.

1(b)) sadrži povratnu vezu i mogućnost promjene rezultata prethodnih faza. programskih jezika četvrte generacije (4GL) i generatora aplikacija. Tim rezultatima se testiraju elementi IS na različitim stepenima razvoja. Analiza Analiza Oblikovanje Izrada Evaluacija Primjena Primjena (a) (b) Oblikovanje Izrada Evaluacija Slika 2. pseudostrukturiranog i radikalnog razvoja (b). Radikalni (strukturirani) razvoj (slika 2. Uporedni prikaz klasičnog razvoja (a).2. Dozvoljava korištenje rječnika podataka. 2. “V” model razvoja informacionog sistema “V” model razvoja IS (slika 2.4. 1. Jaroslav: Projektovanje informacionih sistema Pseudostrukturirani vodopadni model (slika 2. Ovaj model razvoja IS omogućava primjenu tehnika strukturiranog programiranja.40 Poliščuk E.2) omoguća definisanje rezultata (“proizvoda”) pojedinih faza koji se proslijeđuju u slijedeće faze.1(b)) omogućava da se aktivnosti različitih faza mogu obavljati istovremeno. Prikladan je kada se unaprijed ne zna konačni izgled sistema. .

3. Prototipski pristup postaje u punoj mjeri praktično primjenljiv (iako je ideja o prototipskom pristupu u softverskom inženjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda. U zavisnosti od njegove namjene. odnosno jednoekranski ili . 2. Jaroslav: Projektovanje informacionih sistema 41 Test prihvatljivosti Testirani sistem Analiza Scenariji aplikacije Specifikacija zahtjeva Strukturirano oblikovanje Ogledni slučajevi Integracija sistema Model sistema Detaljno oblikovanje Dizajn modula Kodiranje i testiranje Testirani softver Integracija modula Testirani moduli Ogledni slučajevi Slika 2. Primjer “V” modela.2.4. prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa. Model oponašanja (model u prirodnoj veličini).Poliščuk E. Prototipski model razvoja informacionog sistema Uz strukturirani pristup. koji su integrisani sa okruženjem četvrte generacije. mogu se uočiti slijedeće tri vrste prototipskog modela.

ugradbeni model. računari). čiji se razvoj u određenom trenutku prekida i slijedi faza oblikovanja sistema (slika 2.4). Jaroslav: Projektovanje informacionih sistema višeekranski model kojim se prikazuje kako će izgledati dio sistema (npr.3. interfejs). na kraju. Dobija se nefunkcionalni prototip (koji se ne može koristiti u obavljanju radnih zadataka korisnika.42 Poliščuk E. Savremeni softverski alati omogućavaju brzu izradu prototipa.3). Ovakav pristup razvoju IS je prikladan za male projekte. obično korištenjem 4GL. traženje različitih načina na koje se sistem može izgraditi (npr. Dijagram brzog razvoja prototipa. Određivanje zahtjeva Dizajn prototipa Izrada prototipa Razvoj prototipa Radni sistem Slika 2. Radni model daje se na uvid korisniku i omogućava korisniku stvaranje slike o izgledu sistema. Prototipski razvoj podrazumijeva iteraktivni pristup. Funkcionalni prototip dogradnjom može da postane radni sistem (slika 2. inkrementalnom doradom. kao i nemogućnost ispravne procjene i planiranja resursa. da postane dio završnog IS. mogući neuspjeh zamjene prototipa radnim sistemom. koji sistem za upravljanje BP. istraživački model. Prototip može postupno. a sadrži izgled ekranskih formi. programski jezik. . za istraživanje dijelova sistema kako bi se provjerile neke ključne postavke (npr. čime se stiče bolja slika o zahtjevima korisnika. tj. Nedostaci su u tome što se “zaboravlja” da prototip nije pravi sistem. povećanju kreativnosti i brzini razvoja. menia i izvještaja). dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad neće biti napravljene. Ujedno se uklanjaju moguća iznenađenja na kraju razvoja. provjera performansi određenog modula) i. Prednosti su u iteracijama promjena (korisnici se smiju predomisliti). Ograničeni/strukturirani razvoj prototipa služi kao sredstvo za određivanje zahtjeva. Korisnik daje primjedbe za popravak i poboljšanja.

a generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi za programiranje i izgled korisničkog interfejsa. a zatim definisanje nižeg stepena međusobne integracije informacionih podsistema. 3. Preporučuje se dekomponovanje cjeline IS na manje projekte. prije početka primjene prototipskog pristupa.Poliščuk E. Potrebno je. Praktični aspekti primjene prototipskog pristupa su višestruki. u odnosu na klasičnu primjenu metodologije životnog ciklusa. 2000]: 1. nego formalno strogog karaktera. Dijagram ograničenog/strukturiranog razvoja prototipa. uglavnom. obavezno ga upoznati sa činjenicom da je u pitanju prototip a ne konačno rješenje. Riječ je. . a sve u cilju postizanja bolje podrške standarda. Jaroslav: Projektovanje informacionih sistema 43 Određivanje zahtjeva Dizajn prototipa Izrada prototipa Razvoj prototipa Radni sistem Prototip Dokumentovanje zahtjeva Oblikovanje Specifikacije zahtjeva Slika 2.4. projektovanje i programiranje. o činjenicama proisteklim iz iskustva u praktičnoj primjeni prototipskog pristupa. može se reći da su te činjenice prije savjetodavnog. prilikom predaje korisniku prototipa aplikacije. Zbog toga. Pri tome treba precizirati način upotrebe prototipa od strane korisnika. 2. Standarde treba usaglasiti sa mogućnostima odabranog CASE proizvoda. Kako korisnik ne bi bio doveden u zabludu. Opšte preporuke za primjenu prototipskog pristupa su slijedeće [Mogin et al. precizno definisati standarde za izgled korisničkog interfejsa.

istih ili sličnih poslovnih sistema. u prototip aplikacije treba uključiti i odgovarajuće izvještaje. posebno treba obratiti pažnju na preporuke 3 i 4. Radeći sa prototipom aplikacije. odnosno olakšavanja postupka dorade izgenerisanih aplikacija. 8. 9. kako se ne bi produžilo ukupno vrijeme izrade aplikacije i došlo do zamora krajnjih korisnika i projektantskog tima. Do gubitka test podataka može doći u situaciji kada je za njihovo prestrukturiranje potrebno uložiti veliki napor. Ne treba praviti više od tri prototipa jedne aplikacije. ili kada je takvo prestrukturiranje nemoguće izvršiti zbog izmjena u shemi BP. dorada izgenerisanih aplikacija može biti zamoran i vremenski zahtjevan posao. Rješenja IS. a sa druge strane treba koristiti prototip aplikacije upravo da bi se pribavile sve relevantne informacije za strukturiranje sheme BP. a koje se mogu javiti prilikom primjene prototipskog razvoja. Iterativni pristup može dovesti do zamora krajnjih korisnika i projektanata. On mora biti prethodno „pripremljen“ na činjenicu da. Poteškoće koje se mogu izbjeći primjenom prethodno opisanih preporuka. 5. ukoliko se želi postići što kraće vrijeme dolaska do prototipa. a nisu podržani odgovarajućim generatorom. korisnik treba da upotrebljava isključivo test podatke. ne realizuju u okviru prototipa aplikacije kako slijedeća generisanja ne bi uništila tako isprogramirane cjeline. ukoliko je to moguće.44 Poliščuk E. Primjena preporuka 5. Jaroslav: Projektovanje informacionih sistema 4. jer tada korisnik lakše sagledava upotrebljivost aplikacije. Ako je moguće. koji se definišu tek u implementacionom projektu. što znači da su ova dva zahtjeva među sobom u suprotnosti. To znači da se detalji. 7. Ako se radi o neodbacivim prototipovima (neodbacivi prototipovi se evolutivnim podešavanjem pretvaraju u konačna rješenja aplikacija). 7 i 9 vodi ublažavanju ovog konflikta. ali ne i njegova potpuna funkcionalnost. prvenstveno na osnovu specifikacija konceptualnog nivoa. 6. Na taj način se postiže kratko vrijeme izrade prototipskog rješenja. Treba se orijentisati pretežno ka odbacivim prototipovima aplikacija. pa se od predstrukturiranja svjesno odustaje. a koristi BP čija shema ne mora biti blizu konačnog rješenja). U cilju izbjegavanja problema. ukoliko u međuvremenu dođe do prestrukturiranja sheme BP. uneseni test podaci mogu biti izgubljeni. važno je preduzeti mjere predviđene . U cilju „približavanja“ korisničkog interfejsa i funkcionalnosti generisane aplikacije konačnom rješenju. Upotreba generatora koda je moguća tek kada je formiran odgovarajući dio sheme BP. Prototip aplikacije može da predstavlja rješenje koje je dobijeno pomoću generatora koda nekog CASE proizvoda. jer se time izrada samog prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatora koda. su slijedeće. mogu biti dobra osnova u primjeni prototipskog razvoja.

posebno treba obratiti pažnju na preporuke 5 i 6.Poliščuk E. Aplikacije koje se razvijaju samo primjenom prototipskog pristupa mogu postati „izolovana ostrva“. Intervencije na prototipu kod korisnika mogu stvoriti lažni utisak da je projektovanje IS trivijalan posao. ako za nju postoje uslovi. Evolutivni model razvoja informacionog sistema Primjena IS mijenja pogled korisnika. Te iste pojave su prisutne i u razvoju IS.4. na kome se zasniva primjena sekvencijalnog modela metodologije životnog ciklusa. Primjena preporuka 8 i 9 može pozitivno uticati na ublažavanje ili izbjegavanje ovog problema. nasuprot sekvencijalnom. kod nekih projekata. posebno treba obratiti pažnju na preporuku 3. 2. a njegove potrebe se mijenjaju (rastu) tokom primjene. Sa druge strane. Zbog toga je važno obratiti pažnju na preporuku 2. predviđa da je za određene faze životnog ciklusa programskog proizvoda moguće da naredna faza započne prije nego što se prethodna završi. Može se zaključiti da IS raste sa poslovnim sistemom koga podržava. Evolutivni model primjene metodologije životnog ciklusa. Ako je riječ o manje iskusnim korisnicima ili projektantima. direktna primjena isključivo prototipskog pristupa je moguća u slučaju da treba razvijati skoro izolovane podsisteme sa niskim stepenom međusobne integracije. unesenih putem neodbacivog prototipa sa bitno prestrukturiranom shemom BP.4. u situaciji kada se projektantske aktivnosti izvode na osnovu . Jedan od osnovnih principa. faze životnog ciklusa počinju da se sprovode iterativno. je često vremenski zahtjevan i neizvjestan posao. Primjena prototipskog pristupa IS je pokazala da on nije primjeren razvoju integrisanih IS. može biti u funkciji ublažavanja ovog problema. a da pri tome projektant ne uoči takav „propust“ na vrijeme. Da bi se problem izbjegao. Primjena preporuke 9. očekuje se da prototipski pristup doživi svoju punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primjene metodologije životnog ciklusa. posebno značajnu ulogu ima evolutivni pristup razvoju IS. Do ove ideje se došlo na osnovu pretpostavke da ne treba odjednom realizovati kompletnu fazu i utrošiti za to veliku količinu vremena i novca. odnosno pravovremeno identifikovanje informacionih zahtjeva. Jaroslav: Projektovanje informacionih sistema 45 preporukom 1. Imajući u vidu tu činjenicu. Uočava se da upravo primjena ovog principa. Usaglašavanje podataka. Prema tome. je da realizacija naredne faze ne započinje dok se tekuća faza ne završi. može intenzivirati negativne efekte primjene metodologije životnog ciklusa. može se dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva. jer insistiranje na brzom uvođenju aplikacija u funkciju dovodi do parcijalizacije IS. U tom smislu. što dovodi do određenog stepena paralelizma u realizaciji tih faza. U cilju izbjegavanja problema.

kao metodom za tačno utvrđivanje informacionih zahtjeva. Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Slika 2. a ne postupno. nakon utvrđivanja preciznih informacionih zahtjeva. Prema prvoj.5. koraci konceptualnog i implementacionog projektovanja. kao pri primjeni sekvencijalnog modela metodologije životnog ciklusa. Primjenjuju se dvije varijante evolutivnog pristupa. operativno primjenljivih rezultata kod korisnika. i potrebe ulaganja finansijskih sredstava odjednom. Mogući evolutivni model primjene metodologije životnog ciklusa. Brzi prelazak u narednu fazu treba da obezbjedi bolju osnovu za kasniji uspješni završetak prethodne faze. smatra se da njegova praktična primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom. potprojekti se ponovo posmatraju kao cjelina i na njih se primjenjuju. nešto izmjenjeni. a projekti podsistema se usaglašavaju sa shemom integrisane BP. Drugim riječima.46 Poliščuk E. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva. ali ne rješava probleme dugog vremenskog intervala od početka projekta do pojave prvih. potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. Za utvrđivanje informacionih zahtjeva se pretežno primjenjuju odbacivi prototipovi. rezultati konceptualnog i implementacionog projektovanja BP se integrišu. Ovakav nezavisan rad. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije životnog ciklusa i prototipskog pristupa. Na taj način se rješavaju problemi dugog vremenskog intervala od početka projekta do pojave prvih rezultata i potrebe ulaganja odjednom finansijskih sredstava. međutim. može dovesti do nižeg stepena integrisanosti IS. Jaroslav: Projektovanje informacionih sistema nedovoljno precizno identifikovanih informacionih zahtjeva. Prema drugoj varijanti. .

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

Na slici 2.5 je prikazan mogući evolutivni model primjene metodologije životnog ciklusa. Razvoj se vrši u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporučuje i koji generiše naredne zahtjeve.

2.4.5. Inkrementalni model razvoja informacionog sistema
Kao i u slučaju evolutivnog modela, na početku primjene inkrementalnog modela, kompletno se sprovodi faza strategije metodologije životnog ciklusa. Nakon toga, formiraju se relativno manji potprojekti sa nižim stepenom međusobne integracije i utvrde se slijedeći parametri potprojekata: ciljevi, resursi i rok predaje u upotrebu. Ciljevi i resursi su varijabilni parametri, koji se po potrebi mogu mijenjati u toku samog projekta, dok je rok predaje u upotrebu programskog proizvoda obavezno fiksni parametar. Potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. Inkrementalni model se može posmatrati kao posebna varijanta evolutivnog modela životnog ciklusa.

2.4.6. Spiralni i zvjezdasti model razvoja informacionog sistema
Kod spiralnog modela primjene metodologije životnog ciklusa, na početku svake faze provodi se procjena rizika. Nastoje se utvditi mogući rizici i razriješiti ih prije nastavka (uklanjanjem ili svođenjem na najmanju moguću mjeru). U slučaju da je rizik prevelik, projekat se prekida (slika 2.6).
Analiza rizika ANALIZA Verifikacija Analiza rizika OBLIKOVANJE Verifikacija Analiza rizika IZRADA Testiranje Analiza rizika INTEGRACIJA Verifikacija

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Spiralni model metodologije životnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni trošak, a na x osi svaka petlja spirale predstavlja jednu fazu razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza može biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.
kumulativni trošak integracija izrada oblikovanje analiza

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

Analiza rizika, procjena alternativa; Razvoj i verifikacija slijedećeg „proizvoda”; Planiranje slijedeće faze; Pregled – određivanje ciljeva, alternativa i ograničenja.

(a)

(b)

Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije životnog ciklusa. Zvjezdasti model, slika 2.7(b), ne uvodi stroga ograničenja u redoslijedu primjene faza i koraka metodologije životnog ciklusa. To ne znači da prirodnog redoslijeda izvršavanja određenih koraka metodologije u ovom modelu nema, već da on zavisi od više faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno inženjerstvo, ili potreba za reinženjeringom postojećeg IS, mogu zahtjevati potpuno obrnuti redoslijed primjene faza životnog ciklusa (primjena "odozdo na gore").

2.5. Metodologija razvoja informacionih sistema
2.5.1. Uvod u metodologiju razvoja informacionog sistema
Metodologija se može definisati kao metoda + idejni pristup. Sadrži u sebi kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih filozofijom, koji potpomažu izgradnju informacionih sistema [Avison & Fitzgerald, 1995]. Metodologija predstavlja skup načela izrade IS, koji se u određenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland, 1994].

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

Komponente metodologije se mogu razvrstati u slijedećih pet tačaka: 1. 2. 3. 4. 5. Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodič) upotrebe odabranih tehnika i pomagala; Način upravljanja projektom i nadzorom projekta.

Cilj metodologije je da omogući sistemski postupak razvoja kojim će se moći pratiti napredak, uspostavi komunikaciju između učesnika uključenih u izgradnju IS (poslovodstvo, korisnici, analitičari, programeri), osigura skup tehnika koje će omogućiti da se zadaci izvršavaju na standardne i provjerene načine, osigura efikasan nadzor sa ciljem uočavanja grešaka u ranim fazama. Osim navedenog, cilj metodologije je da omogući elastične promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom će se ukloniti ad hoc rješavanje problema, odredi ili ukaže kada i u kojoj mjeri je potrebno uključivanje korisnika, te potiče i omogućava uključivanje korisnika kada se za to ukaže potreba. Metodologija omogućava da se dovoljno pažnje posveti analizi poslovanja, čime će se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti grešku u ranim fazama, jer je lakše popraviti dokumentaciju nego mijenjati programski kôd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lakše je pronaći grešku tokom faze u kojoj je nastala, nego tražiti je i popravljati na osnovu posljedičnih učinaka primijećenih u kasnijim fazama.

C i j e n a Plan Analiza Oblikovanje Izrada Održavanje

Slika 2.8. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama razvoja IS prikazani su na slici 2.8.

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

2.5.2. Pristup razvoju informacionog sistema
Tokom projektovanja IS primjenjuju se, uglavnom, sve vrste modela metodologija životnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijedeći pristupi razvoju. Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup jer omogućava opisivanje specifičnih funkcija. Prisutan je problem određivanja nivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna pažnja je posvećena modelu podataka, šta za posljedicu može imati neodgovarajući model baze podataka i otežanu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjerenost podacima (npr. IEM) obezbjeđuje složeniji opis strukture podataka, ali jednostavnije tokove podataka. Procesi se definišu analizom podataka (grupišu oko podataka) i brže konvergira kraju, jer je skup objekata (entiteta) modela konačan. Početak razvoja definisanjem događaja (npr. JSD) je primjereniji sistemima za rad u stvarnom vremenu.

2.5.3. Komercijalne metodologije za razvoj informacionog sistema
Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su navedeni u originalu: • AD/Cycle (Application Development Cycle), • BSP (Business System Planning), • CASE*Method, • IEM (Information Engineering Methodology, Martin), • JSD/JSP (Jackson System Development/ Jackson System Programming), • SA/SD (Structured Analysis / Structured Design), • SASS (Structured Analysis and System Specification), • SSM/M (Soft Systems Method / Multiview), • SSA (Structured System Analysis), • SSADM (Structured System Analysis and Design Method), • Yourdon (Yourdon Structured Method). Objektno usmjerene metodologije: • • • • • Yourdon/OO (Yourdon / Object Oriented), OMT (Object Modelling Technique), BOOCH (Booch’93), Schlaer-Mellor, Unified Modelling Process (Rational).

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

Primjena neke od ovih metodologija ne znači da će IS biti dobar! Zahtjevi korisnika se mogu mijenjati u vremenu. Preporučene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Insistiranje na provođenju propisanih procedura vodi u zanemarivanje stvarnih problema, što za posljedicu može imati formalno dobro napravljen, ali neuspješan sistem. Većina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije podržavaju sve faze životnog ciklusa (npr. IEM). Metodologije treba da su podržane odgovarajućim alatima za upravljanje i projektovanje (CASE), što nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano u praksi, prečice do rješenja problema zasnovane na sličnim iskustvima, kao i prilagođavanje razvojnog procesa.

2.6. Savremeni postupci razvoja informacionog sistema
2.6.1. Brzi razvoj aplikacija
Brzi razvoj aplikacija (Rapid Application Development (RAD)) je efikasna izrada programskog proizvoda u relativno kratkom vremenu. Ovo se postiže sistemskom i vremenski sažetom primjenom slijedećih tehnika i alata: aktivno i efikasno uključivanje korisnika, odgovarajuće upravljanje projektom, ispravna upotreba metoda i tehnika razvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao i upravljana izrada prototipa. RAD se obavlja malim ekipama u trajanju od 60 do 120 dana (približno 20 sedmica) za podsistem veličine od 25 do 30 relacija (tabela). Cijena postignutog ubrzanja može biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu priručnih rješenja) i “prljavi” razvoj. Faze brzog razvoja su: 1. JEM (Joint Enterprise Modeling ) – združeno modeliranje organizacije, odnosno sjednice na kojima poslovodstvo i analitičari traže načine usmjerenja organizacije i načine kako je učiniti kompetentnom. Istražuju se ciljevi organizacije, problemi, kritični činioci uspjeha te strategijske mogućnosti; 2. JRP (Joint Requirements Planning) – združeno planiranje zahtjeva, odnosno analiza zahtjeva za razmatrani poslovni sistem. Proučavaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istražuju i definišu informacione potrebe;

projektanta i menadžera. Primjer: RAD projekat. prototipovi za test uporabljivosti. koje obuhvata posmatranje poslovanja kao cjeline sa ciljem definisanja opšteg.2. Konstrukcija . Sedmice 15-20 • izrada dokumentacije. Sedmice 1-4 • pokretanje projekta. informaciono inženjerstvo je procesno osjetljiva tehnika usmjerena na podatke i primjenjuje se na organizaciju kao cjelinu ili na neki njen značajni dio. Informaciono inženjerstvo (Information Engineering (IE)) Informaciono inženjerstvo (IE) se zasniva na analizi poslovnih zahtjeva iz koje se izdvajaju aplikacije IS i prioriteti tih aplikacija. Jaroslav: Projektovanje informacionih sistema 3.52 Poliščuk E. Završetak projekta . priprema JAD sjednice. završetak dizajna. konsolidacija JAD dizajna i prototipa. Aplikacije postaju projekti u kojima se provode postupci analize i dizajna da bi se razvili produkcioni sistemi. priprema konverzije. priprema JRP sjednice. planiranje završetka. završetak projekta. Planiranje strategije IS . Sedmice 5-9 • prva JAD sjednica.6. obuka korisnika. obavljanje JRP sjednice.iterativna izrada prototipa. druga JAD sjednica. Osnovno načelo je da se IS moraju graditi kao što se grade drugi “unikatni” proizvodi. Za razliku od klasične strukturirane analize. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. koja se odvija projekat-po-projekat. obuka. 4.Information Strategy Planning (ISP). npr. početak dizajna. Zahtijeva tijesnu saradnju korisnika. . 2. Sedmice 10-14 • razvoj i testiranje. 5. izrada dokumentacije.provjera rada. u građevinarstvu ili brodogradnji. istraživanje. JAD (Joint Application Design) – združeno oblikovanje aplikacija. Faze informacionog inženjerstva su slijedeće: 1. priprema obuke. završno testiranje.

Analiza poslovnih područja . U XP hrabrost podrazumijeva sposobnost provođenja teških odluka (npr. Jednostavnost se ostvaruje kontinuiranim prilagođavanjem programskog kôda i svođenjem projektne dokumentacije na minimalno prihvatljivi nivo. XP nalaže kontinuirane povratne informacija od svih učesnika projekta. 2. 4. zatim na međusobnu komunikaciju članova tima sa rukovodiocem projekta. .6. kao i njegova cjelokupna arhitektura. odbacivanja dijelova koda kada je to neophodno ili nametanja velikih promjena u kasnoj fazi projekta) ili odluka koje u danom trenutku nisu pretjerano popularne. Ovdje se prvenstveno misli na komunikaciju među članovima razvojnog tima. Dijelovi softvera.Business Area Analysis (BAA). odnosno izdvajanje aplikacija i definisanje njihovih prioriteta na osnovu analize poslovnih područja. a moraju biti visoko integrisani da bi se ostvarila strategija ili misija.Poliščuk E. podaci moraju biti prvi planirani. Aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna. Modeliranje započinje modelima podataka. Proučavanje poslovnih područja i definisanje poslovnih zahtjeva za visoko organizirani i integrisani skup informacionih (pod)sistema i aplikacija podrške poslovnog područja. te drže projekt na "pravom putu". Budući da je informacija proizašla iz podataka. hrabrost podrazumijeva međusobnu iskrenost svih članova projektantskog tima.3. 2. Definisanje aplikacija. Takođe. Jaroslav: Projektovanje informacionih sistema 53 sveobuhvatnog plana i arhitekture za redoslijedni razvoj informacionih (pod)sistema. slično onima u strukturiranoj analizi. 1996]. što značajno podiže kvalitet rada i ispunjenje rokova. Dobre povratne informacije onemogućavaju nerazumijevanje među učesnicima projekta. moraju u svakoj fazi projekta biti jednostavni. Pod poslovnim područjem se podrazumjeva skup poslovnih procesa koji se protežu organizacijom. Nakon toga se rade modeli procesa. među svim njegovim učesnicima. Ekstremno programiranje (eXtreme Programming (XP)) Načela ekstremnog programiranja nastala su prije desetak godina [Kent Beck. te komunikaciju naručioca sa izvođačima (članovima razvojnog tima i njihovim rukovodiocima). Vrši se izdvajanje poslovnih područja i određivanje prioriteta. 3. XP zahtijeva komunikaciju u svim fazama projekta. Napomena: O informacionom inženjerstvu biće još govora u poglavlju 8.

Zajedničko vlasništvo se sastoji u tome da svi inženjeri koji učestvuju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku. XP nalaže izgradnju novih verzija nekoliko puta dnevno. XP preporučuje relativno često izdavanje novih verzija sistema. na način da jedan piše kôd.4. Programeri rade u parovima. Metafora sistema je analogna onome što većina drugih metodologija naziva arhitekturom sistema. Naručilac ili predstavnik naručioca mora biti prisutan prilikom razvoja sistema kako bi bio dostupan u slučaju potrebe za pojašnjenima. pa se zabranjuje prekovremeni rad dvije sedmice zaredom. 2. Igra planiranja definiše funkcionalnosti slijedeće verzije. Korisnici se izražavaju "pričama". Zastupljeno je poštovanje 40-satne radne sedmice. tako da svaka priča definiše jedan dio funkcionalnosti sistema.54 Poliščuk E. izvorno nazvan Objectory. Jaroslav: Projektovanje informacionih sistema XP uvažava mogućnost promjene specifikacija koje definišu funkcionalnost sistema. a drugi prati pisanje i revidira kôd. U stvati. Prilagođavanje programskog kôda (refactoring) je tehnika kojom se pojednostavljuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) složenog koda. Metafora mora biti jasno izražena te nedvosmisleno shvatljiva svim članovima projektantskog tima. kada sistem zadovoljava funkcionalnost traženu od strane naručioca. te kako bi pomogao u definisanju sistema i pisanju testova. tj. U početku se kreira grubi plan koji se redefiniše kroz razgovore sa naručiocima i korisnicima. a time i dotok povratnih informacija i igru planiranja. kasnije je dobio ime Rational Unified Process (RUP). prije nego što njen razvoj stvarno i počne. Pričama se dodjeljuju prioriteti i ciljano vrijeme implementacije (1 do 3 sedmice po zahtjevu). koji se obavlja na slijedeći način: . Smatra se da umorni projektanti ne mogu postići maksimalnu efikasnost u radu. Ujedinjeni razvojni proces (Unified software development process (UDP)) Ujedinjeni razvojni proces. pazeći da kôd bude jasan i razumljiv. nakon svake implementirane funkcionalnosti. Testiranje se sastoji od testova komponenti i testova prihvatljivosti. Najčešći argument osporavaoca XP-a je u tvrdnji da XP zanemaruje dizajn sistema. Zastupljen je iterativni i inkrementalni razvoj. obično u prvom trenutku u kojem to ima poslovnog smisla.6. Programeri moraju pisati kôd u skladu sa dogovorenim standardima. Prihvati promjenu! je jedan od osnovnih XP postulata. dizajn arhitekture sistema je kontinuirani proces koji se u malim koracima odvija tokom čitavog razvoja. tj. Često izdavanje novih verzija pojačava komunikaciju. XP ne definiše format ili tehniku u kojoj metafora mora biti izražena.

koji zadovoljava podskup ukupnih zahtjeva. se sastoji od prikupljanja ostalih zahtjeva plus promjene zahtjeva. . oblikovanje. #1 iter. Dijagram glavnih faza razvoja. odnosno prikupljanje detaljnih zahtjeva (80%). 2. gradnja. Početak Zahtjevi Analiza Elaboracija Gradnja Prelaz Oblikovanje Ugradnja Provjera iter. prikupljanje najvažnijih zahtjeva (10% detaljno) i određivanje dosega projekta. Svaka iteracija se obavlja standardnim životnim ciklusom koji uključuje analizu. Mogu se izdvojiti slijedeće glavne faze razvoja (slika 2.Poliščuk E.9. podešavanje performansi. Faza konstrukcije (izrade) slijedi nakon provođenja prethodnih faza. #n Slika 2. Početak (Inception). ugradnju i provjeru. razrade arhitekture i izrade sistema. obuka korisnika.9). 3. globalna analiza i dizajn. #n-1 iter. Softver se razvija i objavljuje po dijelovima. Elaboracija (Elaboration). provjeren i integrisan. Konstrukcija (Construction). #2 Inkrementi iter. Prelaz (Transition) sačinjavaju beta testiranje. Jaroslav: Projektovanje informacionih sistema 55 1. ustanovljavanje osnovne arhitekture i planiranje konstrukcije. Isporuke mogu biti interne ili prema korisnicima. Glavne faze razvoja se obavljaju kroz niz iteracija. Rezultat iteracije je proizvod završnog kvaliteta. provjera prihvatljivosti i zadovoljstva korisnika. kao i kontinuirane integracije. koga sačinjavaju opravdanje razloga za pokretanje projekta.

2. Smanjenje broja iteracija za posljedicu ima slabije rezultate razvoja. ekipe i posla. U fazi konstrukcije to vrijeme je duže. da li je opšta ekonomska i politička situacija u okruženju poslovnog sistema stabilna ili ne. je nastavak evolutivnog razvoja. sa kolikim finansijskim sredstvima za realizaciju projekta se raspolaže i kakva je dinamika obezbjeđenja tih sredstava. Zahtijeva pripremu okruženja. već se može govoriti samo o preporukama. tada najkasnije do završetka faze strategije. Uobičajeno. . kakav je stepen uređenosti poslovanja u samom poslovnom sistemu. da li su. da li je većina korisnika budućeg programskog proizvoda iskusna u upotrebi rješenja vezanih za informacione tehnologije ili ne.6. zainteresovani i stimulisani za uvođenje novog programskog proizvoda. Opasna je zbog mogućeg pretjeranog optimizma. Trajanje iteracije može varirati u zavisnosti od faze. a dijelom i budući korisnici. Dosta preporuka za izbor odgovarajućeg modela primjene metodologije životnog ciklusa proizilazi iz razmatranja danih u okviru tačaka 2. su slijedeći: koliko je poslovni sistem složen sa stanovišta funkcija koje se u njemu obavljaju.56 Poliščuk E. za projekte do 18 mjeseci. koji se ciljevi projekta smatraju prioritetnim i u kojoj mjeri su ciljevi ambiciozno postavljeni. otežane ili ne mogućnosti za obezbjeđivanje komunikacija. je okvirno 3 do 6 iteracija.5. Ukoliko je izabrana metodologija životnog ciklusa. iteracije imaju podjednako trajanje. Jaroslav: Projektovanje informacionih sistema Post-implementacija (Post-deployment) očuvanje integriteta aplikacije.4 i 2. da li su rukovodeće strukture iz poslovnog sistema. Broj i trajanje iteracija za ujedinjeni razvojni proces. koji se mogu navesti i koji utiču na izbor modela primjene metodologije. Prva iteracija je najčešće i najteža. Ne postoje formalna pravila na osnovu kojih ovaj izbor treba napraviti. Izbor pristupa razvoju informacionog sistema Izbor opšte metodologije po kojoj će programski proizvod biti razvijen vrši se tokom ustanovljavanja projekta razvoja programskog proizvoda. rukovodeći tim projekta mora da se opredjeli za odgovarajući model primjene metodologije životnog ciklusa i izvrši dodatna prilagođavanja izabranog modela potrebama projekta. Ovom navođenju parametara može se dodati: kakve informacione tehnologije stoje na raspolaganju za realizaciju projekta. u cjelini. Neki od parametara. Ako se krivo procjeni može izazvati pomake i neželjene učinke.5. da li je rukovodeći i izvođački tim projekta iskusan u primjeni odgovarajućih informacionih tehnologija.

Prikaz redoslijeda izrade fizičkog i logičkog modela IS. tehnički) opisuje kako je sistem fizički i tehnički izgrađen. Redoslijed izrade fizičkog i logičkog modela Fizički i logički model postojećeg IS. Ukoliko od ranije ne postoji IS. poslovni) opisuje šta je sistem. Uvod u projektovanje i izgradnju informacionog sistema 3. te ko.1. implementacioni. Postojeći fizički IS Postojeći logički IS Budući logički IS Budući fizički IS Korisnički/poslovni zahtjev Budući organizacijski IS Slika 3. Operativni (budući fizički) sistem prikazuje šta. Logički model (esencijalni. izrađuje se na osnovu poslovnih zahtjeva i zahtjeva krajnjih korisnika.1. odnosno različito značenje podataka zavisno od područja unutar poslovnog sistema i okruženja. a zatim logički i fizički model budućeg IS.1).Poliščuk E. 3.1. ko i kada. ali ne i gdje radi. Model je apstrakcija ili reprezentacija dijela stvarnog svijeta. Uvod u projektovanje i definisanje zahtjeva za informacionim sistemom 3. šta su podaci (slika 3.1. Fizički model (ugradni. šta radi.2. Modeliranje informacionog sistema Potrebna je izrada modela koji odgovaraju dijelovima poslovnog sistema. a prema potrebi može se razmatrati organizacijski nivo. potrebno je odrediti "surogat" postojećeg sistema po ugledu na istovjetne sisteme u .1. konceptualni. Jaroslav: Projektovanje informacionih sistema 57 3. gdje i kada nešto radi.

Vrste modela informacionog sistema Model podataka opisuje ŠTA su podaci. Dijagram modeliranja IS [Fertalj & Kalpić. Tehnika oblikovanja dijagramima odvija se na slijedeći način. Model resursa/sredstava opisuje izvršioce. Kao primjer se može navesti dijagram promjene stanja. Proces ima određeni učinak na podatke u nekom stanju. 2005]. . Najčešći model procesa je dijagram toka podataka. a najčešći logički model je relacioni model podataka. Konceptualni model opisuje podatke i veze između podataka. Jaroslav: Projektovanje informacionih sistema drugim poslovnim sistemima ili razvoj započeti sa izradom logičkog modela.3. obrađuju i distribuiraju podaci. te vrši opis stanja. npr. odnosno ŠTA opisuju podaci. Model funkcija se oblikuje razlaganjem (dekompozicijom) funkcija. Model događaja opisuje KADA se podaci obrađuju.2. Događaj Staro stanje podataka Sinhronizacija (koncept okidača) Proces (naredbe i pravila) učinak Struktura podataka Novo stanje podataka Slika 3.1. Model procesa opisuje obradu podataka posmatranog sistema. odnosno KO obrađuje podatke. iterativno od vrha prema dolje (od globalnih funkcija do osnovnih procesa). Obavljanjem procesa podaci prelaze u novo stanje (slika 3. Model funkcija i procesa opisuje KAKO se prikupljaju. Izradom modela nastoji se opisati situacija u kojoj događaj iz vanjskog svijeta pokreće (okida) process.2).58 Poliščuk E. GDJE se podaci nalaze i GDJE se podaci obrađuju. Modeliranje programa podrazumjeva predstavljanje struktura (programskih) modula IS. odnosno razmatra učinke koje događaji imaju na procese i podatke. 3. strukturnim kartama. Logički model opisuje strukturu podataka i logičkih datoteka. Najčešći konceptualni model je model entiteti-veze.

u nekim metodama. koja se naziva životni ciklus razvoja sistema. Njihov zadatak je da provode sistemsku analizu i dizajn. Sistemski dizajn (dizajn sistema) omogućava specifikaciju ili konstrukciju računarom podržanog rješenja identifikovanih poslovnih zahtjeva. postavlja prioritete i određuje politiku njegovog korištenja. političar. stručnjak koji izgrađuje sistem) provjerava njegovu ispravnost te ga isporučuje u primjenu. klijent. rješavalac poslovnih problema. osoba ili grupa za koju se gradi IS). baze podataka. poboljšani informacioni sistemi te nove ili poboljšane aplikacije. 2000] sistem analitičara glasi: Sistem analitičar pomaže proučavanju problema i potreba poslovanja radi određivanja kako poslovni sistem i informaciona tehnologija mogu najbolje riješiti problem i postići unaprijeđenje poslovanja. psiholog. mrežu i programe. a može biti i graditelj sistema. projektant. ulaze. arhitekta i kontrolor. Vlasnik sistema (naručilac. al. zajedno se zovu informaciono inženjerstvo.Poliščuk E. konstruiše komponente sistema na osnovu specifikacija koje rade dizajneri sistema. Sistemska analiza (analiza sistema) proučava poslovanje sa ciljem da dâ preporuke za poboljšanja sistema i specifikacije zahtjeva za rješavanje. stvarni vlasnik ili predstavnik uprave) naručuje i plaća razvoj i održavanje sistema. Projektant (dizajner sistema) je tehnički stručnjak koji oblikuje sistem tako da zadovolji zahtjeve korisnika. Jaroslav: Projektovanje informacionih sistema 59 3. oblikuje datoteke. Sistem analitičar je istraživač. integriše rješenje. Formalna definicija [Whitten et. trgovac. Ključne aktivnosti i učesnici Ključne aktivnosti.4. odnosno sistematičan i metodičan pristup rješavanju problema sistema. Povezuju one koji trebaju računar i one koji poznaju informacione tehnologije (IT). Plodovi ove aktivnosti su poboljšani poslovni procesi. a često sve zajedno. zagovornik promjena. prevodi poslovne zahtjeve i ograničenja u tehničko rješenje. Učesnici (nosioci uloga) u navedenim aktivnostima su: Korisnik (korisnik usluga. Korisnik sistema (krajnji korisnik) neposredno koristi IS pri obavljanju svakodnevnih poslova ili koristi informaciju dobijenu iz IS. Sistem analitičari razumiju i poslovanje i računarsku obradu podataka. Većina sistem analitičara koristi specifičnost pristupa. izlaze. ekranske forme. šta podrazumjeva korisnika sistema i vlasnika sistema. Kao ključne aktivnosti mogu se uočiti sistemska analiza i sistemski dizajn. Graditelj sistema (programer.1. .

Standardno uključuje dva sagovornika. su prikupljanje informacija. Kao zamjena za intervjue koriste se upitnici i ankete. poslovne politike. Nužna je ocjena postojećih aplikacija i/ili računarom podržanih podataka. što će u narednom tekstu biti detaljnije opisano. i to korisnika i ispitivača. koji su pogodni i za prikupljanje informacija o resursima.2. Postupak analize mora biti prilagođen korisniku.3.60 Poliščuk E. ciljeva poslovanja i strukture informacija. Posmatranje.2. Nakon završetka analize i sinteze dobijenih informacija. neke razgovore (ponekad i čitavu seriju) treba ponoviti da bi se . ili učesnici koji rade isti posao. Jaroslav: Projektovanje informacionih sistema 3.2. Postupak intervjua je spor i neefikasan. (Prve) razgovore treba voditi prema unaprijed dogovorenom planu i rasporedu. Evidentiranje rezultata analize poželjno je obaviti CASE alatima. Sagovornici su rukovodioci.2. Informacije se prikupljaju nizom pojedinačnih razgovora. procesi osnovne djelatnosti). jer se organizacija razgovora mora obaviti za svaki pojedini razgovor. odnosno neposredni uvid u poslovne procese posmatranjem radnih sredina (način izrade i razmjene dokumenata.1. 3. Ispitanik se pojavljuje u ulozi pasivnog sagovornika (!?). Individualni intervju je kada učestvuje jedan korisnik. Prikupljanje informacija Jedna od aktivnosti kod definisanja zahtjeva za IS su intervjui sa ključnim korisnicima i radne sjednice. radi analize podataka. radi boljeg utvrđivanja pravila. ali može i više. Analiza dokumentacije podrazumjeva prikupljanje cjelokupne dokumentacije značajne za poslovanje. Postupak intervjuisanja Intervju mora biti neusiljen i elastičan razgovor sa ispitanikom u obliku niza pitanja i odgovora. dok je intervjuisanje grupe kada se razgovara sa više korisnika iz različitih područja.2. Sučeljavanje korisnika i informatičara ubrzava rješavanje proturječnih iskaza. Definisanje zahtjeva za informacionim sistemom 3. šta treba da obezbjedi koordinator intervjua. koje se mogu izdvojiti u definisanju zahtjeva za informacionim sistemom. prikupljanje podataka i ustanovljavanje činjenica. krajnji korisnici i ostali učesnici iz poslovnog sistema. Ako naručilac zapošljava informatičare svakako ih treba uključiti u analizu. Ključne aktivnosti Ključne aktivnosti. 3. ali i zbog njihove konverzije u novi sistem. je značajan vid definisanja zahtjeva za IS.

Vođenje razgovora. i izradu sveobuhvatnog potsjetnika i izdvajanje prikladnih pitanja. Mogući plan i obavljanje razgovora može da se odvija na slijedeći način: 1. Tehnika intervjuisanja Priprema za razgovor treba da sadrži utvrđivanje informacija koje treba saznati. vrijeme i mjesto održavanja razgovora.4. 3.5 sata). popis prikupljene dokumentacije i ime zapisničara. 5. određuje se voditelj razgovora koji je ujedno i zapisničar. provjerava se da li postoji nešto što je sagovornik htjeo reći a nije bilo pitano.. ne može zapisivati.2. • Zapisnik treba da sadrži: naziv projekta.”). Zahvala na razgovoru. određivanje dokumentacije koju treba prikupiti i priprema pitanja koja će biti postavljena tokom razgovora. spisak učesnika. • Zapisnik ne smije nametati zaključke. . • Zapisnik mora sadržavati ono što je rečeno i slijediti tok razgovora. Kada u razgovoru sudjeluje više analitičara. dogovara se nastavak razgovora (dopunski razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra da je razgovor nametnuo nova pitanja. to jest standardnih pitanja. Dokumentovanje razgovora sačinjavaju: • Samostalno pisanje zapisnika (“Ko ne razumije. Priprema pitanja podrazumjeva izradu jezgra tema. jer su oni rezultat analize. a ostali ulažu primjedbe. Završetak razgovora je približno 5 do10 minuta prije isteka planiranog vremena. prikupljanje dokumentacije. 4. 2. provjerava se da li treba proširiti krug sagovornika. 3. Ukupan broj razgovora ne može se unaprijed tačno odrediti i treba ga prilagoditi stvarnoj situaciji.5 do 2. koji sadrži predstavljanje učesnika i upoznavanje sa svrhom razgovora (prikupljanje informacija o … ). odnosno postavljanje pitanja i zapisivanje odgovora. Prekida se redoslijed postavljanja pitanja.. Početak razgovora. Jaroslav: Projektovanje informacionih sistema 61 upotpunile dobijene informacije ili uskladili proturječni iskazi. Trajanje prvog razgovora je 2 sata (okvirno 1. elektronskom poštom ili novim sastankom. sadržaj razgovora (tekst zapisnika). Preispitivanje i pojašnjenje sadržaja se sastoji od provjera zapisanih navoda radi upotpunjavanja bilješki: telefonom. .Poliščuk E. . proučavanje postojeće dokumentacije i prethodnih nalaza.

Po potrebi sagovornik može nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su pogrešno protumačeni..2. Može se dostaviti korisniku prije ili nakon intervjua. Molim detaljnije objašnjenje za . Koji su najveći problemi . Pogodna je za popis resursa. 3. Pitanja su zatvorenog tipa.. koji potvrđuje vjerodostojnost zapisnika. analiziraju činjenice koje se ne poklapaju i vrši provjera odgovora različitih sagovornika na isto pitanje.62 Poliščuk E. Možete li navesti primjer za takvu situaciju?. Upitnici i ankete Upitnik je. pažnja i jezgrovitost tj. Na koji način obrađujete . 3.... . “brzo misli. nenametanje zaključaka i ležernost (plus praćenje reakcija sagovornika). ?. Pitanja otvorenog tipa: Što mislite o . Ovu vrstu intervjuisanja iznimno provesti kada se želi utvrditi zajednički interes ili protivrječnost. . Sadrži pitanja koja se postavljaju tokom razgovora (okvirno 20 pitanja).. u suštini. Repertoar i vrste pitanja može biti slijedeći: 1.5. 2.2. Ne pretpostavljati da se unaprijed zna o čemu se radi. ?... teško je procijeniti iskrenost (spontanost) odgovora.6. Nedostaci upitnika su slijedeći: ispitanik može prilagoditi (kontrolisati) svoje odgovore. Analizom odgovora se razdvajaju činjenice od mišljenja. utvrđuje se da li pojedine činjenice odgovaraju drugima. a može i obeshrabriti ispitanika. Preporuke za vođenje intervjua Tokom provođenja intervjua treba pitati o svemu što se smatra važnim. izbjegavanje sugestivnih pitanja. Preporučuje se slijedeće ponašanje: iskrenost i nepristranost (cilj je naći za korisnika najprikladnije rješenje. pismeni intervju. Grupno intervjuiranje je potrebno izbjegavati i po potrebi nadoknaditi radnim sjednicama. “Probna” pitanja: Zašto?. Anketa može da obuhvatiti više ispitanika.. ?. a odgovori i obrada odgovora mogu se standardizovati. a ne naturati određeno programsko rješenje ili računarsku platformu). jasno govori”. 3. Jaroslav: Projektovanje informacionih sistema Autorizacija (ovjera) zapisnika se vrši tako da se zapisnik dostavlja na uvid sagovorniku. Pitanja zatvorenog tipa: Koliko .. Ništa nije samo po sebi razumljivo i svima jasno. obrađujete (u nekom razdoblju)?.

SUBP). Praksa može odudarati od pravilnika i administrativnih obrazaca. Excel). Tokom intervjua analitičar i ispitanik se nalaze jedan može posmatrati način na koji ispitanik odgovara i pitanja. . koliko su potrebni. postojeće platforme (računari. izvještaji) i dokumente nastale analizom podataka.8. integritet. nemogućnost rada u višekorisničkom okruženju. kao i sastav i stepen informatičke obučenosti korisnika. Takođe se analizira nepostojanje programske dokumentacije. tehnološka zastarjelost (programski jezici i alati. zaštita i sigurnost podataka. Treba shvatiti zašto i kada dokumenti nastaju. međusobna povezanost različitih aplikacija i podataka. provjeriti kod korisnika. tipične dokumente (pravilnici. Proučavanje dokumenata Prikupljaju se svi dokumenti do kojih se može doći. podrške i podataka najčešći razlozi za izgradnju novog IS. Stalno bilježenje nekih podataka ne mora značiti da su ti podaci stvarno potrebni. te šta treba promijeniti da bi se popravili (sadržaj. operativni sistem. Vrši se procjena aplikacija i (baza) podataka u primjeni. Analiziraju se nedostaci sistemske opreme i programske podrške. informatička ostrva). potrebno ih je evidentirati i analizirati. U prvom redu se analizira nepovezanost aplikacija (tzv. je intervjuisanje najelastičnije! osjećajima i motivaciji osoblja.2. loša programska rješenja (funkcionalnost.Poliščuk E. tj. Jaroslav: Projektovanje informacionih sistema 63 Na osnovu navedenog. popunjeni na tipičan način (tako se može ustanoviti koje informacije se unose i na koji način).2. lakoća popunjavanja i čitanja). Reprezentativni dokumenti najčešće ne ukazuju na izuzetke. obrasci. razmatrane analizom. može se zaključiti da Pomoću intervjua se može više naučiti o stavovima. U prvom redu treba prikupiti dokumente koji su nastali kao rezultat analize procesa. kako se popunjavaju. nasuprot drugom. Poželjno je da dokumenti budu reprezentativni. Evidencija i analiza postojećih aplikacija Budući da su nedostaci opreme. Nužno je modele (podataka). Treba prikupiti više uzoraka iste vrste dokumenta! Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska. podržane funkcije i način posluživanja programa. grafički interfejs). zakoni. mreža. i to: korišteni programski jezici i alati. pa analitičar po potrebi proširiti ili usmjeriti 3. ergonomija). uključujući programe za kancelarijsko poslovanje (npr. to jest podatke koji se rjeđe bilježe. ali ipak trebaju. 3. nepouzdanost.7.

moderator. Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani i netačni. naglašenog ponavljanje uvedenog prilikom izrade zahtjevnih ili složenih programskih rješenja. 3. Jaroslav: Projektovanje informacionih sistema Nedostaci modela podataka mogu biti različiti. pri čemu se korisnici potiču na aktivno i kreativno sudjelovanje. Posmatranje na licu mjesta je najteža metoda za utvrđivanje činjenica. dnevni red i zapisnici (slika 3. Svaki učesnik iznosi sve što mu pada na pamet u vezi sa problemom koji se rješava. Najčešći nedostaci su različitost modela podataka postojećih aplikacija i nedostaci unutar pojedinih modela. prikrivanjem uobičajenog kršenja radnih procedura. ako se dobro ne provede. znatan utrošak vremena.9. Za to je potreban poseban prostor i izolacija. i obezbjeđuje pouzdanost prikupljenih informacija. Posmatranje poslovnog sistema Definisanje zahtjeva za IS se može dopuniti uvidom u poslovne procese.3). nedefinisanost identifikatora (primarnih ključeva).64 Poliščuk E. mogućnost manipulacije posmatrača. kao i ukupne nenormalizovanosti modela. Nedostaci unutar pojedinih modela su. npr. Radni sastanci Radni sastanci (sjednice) se organizuju da analitičari i korisnici zajednički provode analizu i oblikovanje.10. Posmatra se lokacija i kretanje ljudi. Genijalnost grupe se koristi za prikupljanje ideja i definisanje informacionih potreba. zaprimanje. Cilj sjednice je (zajedničko) pronalaženje najboljeg rješenja. tok izvršavanja poslova. Izvodi se tako da se od svakog ispitanika iz grupe traži da definiše svoj pogled na idealno rješenje. ometanje i nelagodnost posmatranih osoba. Od predloženih rješenja odabira se najbolje prema realnoj izvodljivosti. najčešće kao posljedica nepostojanja primarnih ključeva. nedefinisanost veza i pored postojanja primarnih i drugih (stranih) ključeva. fizički ulazi i izlazi sistema. 3. dva ili više entiteta iz stvarnog svijeta su prikazani različitim brojem entiteta u modelu podataka.2. nedefinisanost veza među podacima. izrada i razmjena dokumenata. Navedene pojave su posljedica razvoja tokom upotrebe i nedoslijednosti tog razvoja. Postupak je . npr. ako se dobro provede. Ovaj pristup je efikasan. procesi osnovne djelatnosti. isti entitet iz stvarnog svijeta opisan je različitim atributima. Različitost modela podataka postojećih aplikacija se očituje u tome da entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojećim modelima. proizvodnje. isti entitet iz stvarnog svijeta pojavljuje se pod različitim nazivima. Prednost ovakvog pristupa je u tome što je analitičar u stanju da realno sagleda poslovni proces. najčešće.2. Nedostaci posmatranja poslovnog sistema su neefikasnost. odnosno posmatranjem radnih sredina.

Systems Analysis and Design.Poliščuk E. Prednosti radnih sjednica su njihova pogodnost za projekte kojima se rješavaju problemi važni za cijeli poslovni sistem ili veći dio poslovanja. Haley Wixom. Slika 3. Sjednice treba da traju više dana (5 do 10) u nekoliko sedmica. Jaroslav: Projektovanje informacionih sistema 65 koristan tamo gdje postoje korisnici koji dobro poznaju sistem. Nedostaci radnih sjednica su pasivnost učesnika. ali teško prihvataju nove ideje. Otpor sjednici je srazmjeran nivou položaja konkretnog učesnika. Ovom zahtjevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika. Razvoj prototipa Razvoj prototipa se koristi kada korisnik ne može tačno da definiše svoje informacione potrebe prije nego što se izgradi informacioni sistem.2. John Wiley & Sons.3.Dennis & B. Otpor je naročito naglašen kada poslovni sistem zapošljava informatičare. preciznije se ustanovljava doseg projekta i bolje uočava protivrječnost zahtjeva. “usitnjavanje” razgovora i često udaljavanje od tema. Njihovim organizovanjem se izbjegavaju specifični (egzotični) i nejasni zahtjevi. jer se podrazumijeva da je informatizacija isključivo njihov posao. Prostor za radne sjednice [A. 3. 2000]. Razlog tome može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak .11.

a ponekad oboje. Postupak korištenje sistema i modifikovanje istog iterativno se ponavlja. Ne izjednačavati “tako se uvijek radi” sa “tako treba raditi”! . inicijalne potrebe. koji su bitni (nužni!) za uspješnu realizaciju. Taktika “kuhinjskog sudopera”: korisnik navodi (preko)brojne potrebe. 3. gomilu nepotrebnih izvještaja.3). Ovakav pristup obično je uzrokovan pomanjkanjem iskustva korisnika. a obično izuzeci zahtijevaju i najviše napora tokom ugradnje: "To je naša jedina procedura … (osim kada … )".2. jer samo korisnik može izraziti svoje potrebe i probleme. Jaroslav: Projektovanje informacionih sistema teška vizuelizacija budućeg sistema. te u okruženjima gdje se informacione potrebe korisnika mjenjaju ili razvijaju (prototipski model razvoja IS je obrađen u podtački 2. U radu sa takvim sistemom korisnik otkriva svoje informacione potrebe. te se sistem modifikuje kako bi se zadovoljile te potrebe.12. a zahtjeve treba reducirati na one realne i izvodljive. 3. Izrada prototipa pogodna je u onim okruženjima gdje je teško definisati konkretni model sistema. sortiranja. a zapravo mu je potrebna samo jedna ili dvije. izračunavanja i sl. Korisnik je sklon prešutjeti izuzetke. Taktika "Treba mi isto.66 Poliščuk E. ekranskih formi. 2. Da bi se olakšala vizuelizacija budućeg sistema izgrađuje se sistem koji zadovoljava neke osnovne. Ova taktika obično oslikava korisnika sa dobrim poznavanjem onoga šta želi. Dodatni zahtjevi služe za postizanje bolje nagodbe sa analitičarom. koji ne zna šta bi mu stvarno moglo zatrebati ili nije u stanju izdvojiti ono šta je bitno. 1. Informatičkim žargonom su opisana ponašanja koja se mogu očekivati od korisnika. ali u boljem obliku": korisniku koji koristi ovu taktiku nedostaje volja ili znanje. Najčešći problemi pri prikupljanju informacija Ponašanja korisnika često može da uzrokuje niz problema pri definisanju zahtjeva za IS.4. a informacione potrebe korisnika otkrivaju korištenjem sistema. Taktika “dimne zavjese”: korisnik traži više mogućnosti. Šanse za uspješno definisanje problema su male.

Uvod u analizu sistema Analiza sistema (sistemska analiza) je raščlanjivanje sistema na njegove komponente da bi se proučilo kako te komponente rade i međusobno komuniciraju. analizom trajanja i koštanja poslovnih procesa. šta predstavlja radikalni redizajn poslovnih procesa analizom mogućih posljedica. te predlaganjem poboljšanja (udruživanje procesa. poželjno poboljšani.1. 4. Analiza sistema se provodi sa namjerom slijedeće sinteze sistema i razvoja aplikacija. Aktivnosti analize 4. • Reinženjeringom poslovnih procesa (Business Process Reengineering (BPR)) ili preoblikovanjem poslovnih procesa (Business Process Redesign (BPR)).2. odnosno povećanjem efikasnosti korisnika analizom problema i uklanjanjem uzroka. tj. ukidanjem ili zamjenom pojedinih aktivnosti. te (3) definisanje poslovnih zahtjeva i prioriteta novog ili poboljšanog postojećeg sistema [Whitten et. . Svrha. Biće navedene moguće definicije analize sistema. 2000]. cilj i dubina analize sistema mogu se predstaviti slijedećim aktivnostima: • Automatizacijom poslovnih procesa (Business Process Automation (BPA)). sistem. paralelizam izvedbe).1. procjenom alternativnih tehnologija.2. Analiza sistema 4.Poliščuk E. Analiza sistema je: (1) razmatranje i planiranje sistema i projekta. analizom troškova . povećanjem efikasnosti i djelotvornosti.koristi i analizom rizika. • Poboljšanjem poslovnih procesa (Business Process Improvement (BPI)). Sinteza sistema je ponovno objedinjavanje komponenti u cjeloviti. al. (2) proučavanje i analiza postojećeg poslovnog i informacionog sistema. Uvod u aktivnosti analize Aktivnosti analize se mogu sistematizovati u tri nivoa. gdje svaki nivo traži odgovor na odgovarajuća pitanja. Jaroslav: Projektovanje informacionih sistema 67 4.

Objektno usmjerena analiza omogućava: modeliranje učaurivanjem podataka i procesa u objekte. se rade odgovarajući modeli (modeliranje procesa. ko je kome potčinjen. RazmjenaPodataka. Ko ih treba?. usmjerena podacima i proučavanju poslovnog sistema ili njegovih većih dijelova kao cjeline. kako sarađuju različiti odjeli. Ko ih stvara?. Jaroslav: Projektovanje informacionih sistema 1. Detaljna specifikacija zahtjeva za IS: Koji su podaci potrebni?. 4.2. Brzi razvoj aplikacija (Rapid Application Development (RAD)) je razvoj djelomičnih verzija aplikacija. te utvrđivanje potreba i zahtjeva: Kako radi postojeći sistem?. Primjeri: ProtokDokumenata. Združeni razvoj aplikacija (Joint Application Development (JAD)) je analiza zasnovana na intenzivnim radnim sjednicama na kojima vlasnici. Postupci i tehnike analize Moderna strukturirana analiza je procesno usmjerena tehnika modeliranja poslovnih zahtjeva za sistem. Informaciono inženjerstvo je procesno osjetljiva tehnika. Navedeni postupci se mogu komplementarno primjenjivati i pored uvriježenog mišljenja da je riječ o međusobno isključivim metodama! .2. takođe. korisnici. Za ostale elemente. Kada?. itd. koje mogu evoluirati do konačnog rješenja.68 Poliščuk E. Za potrebe pozadinske analize može se izraditi shema organizacione strukture iz koje će biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Kakav im je oblik?. Daljnja razrada granica projekta. Pozadinska analiza treba da pomogne razumjevanju strukture organizacije. Od koga?. Koji su izlazni podaci?. Detaljna analiza postojećeg sistema. analitičari. a ne projekat po projekat. dizajneri i projektanti zajednički definišu i oblikuju sistem. kao i definisanje novih ili modifikovanih objekata koji će skupa sa postojećim objektima graditi novu aplikaciju. Na koji način se podaci prikupljaju i objedinjuju? 3. modeliranje podataka). Koji su izvori izlaznih podataka?. Koji su problemi pri korištenju aplikacija? 2. ko u njoj radi. Na koji način korisnici koriste sistem da bi obavili svoj posao?. proučavanje postojećih objekata da bi se vidjelo mogu li se ponovno iskoristiti ili prilagoditi za nove primjene.

standard.Poliščuk E.3.2. šta predstavlja logički dizajn. Ti modeli izražavaju suštinu sistema (sinonimi: esencijalni. omogućava uočavanje mogućih poboljšanja (ako nije učinjeno ranije). nezavisno od tehničkih rješenja. detalje implementacije ili informacije vezane uz planiranje projekta. Razvoj koncepata budućeg sistema obuhvata prikupljanje dodatnih informacija.12-1990]. Pažnja se usmjerava na ono ŠTA se želi izgraditi. ulaza. ustanovljavanje željenih poboljšanja.3. reviziju i doradu modela. • Logički modeli kojima se prikazuje ŠTA je sistem i ŠTA mora raditi (a ne KAKO radi). kao i oblikovanje procesa i podataka. konceptualni ili poslovni modeli). Strukturirana analiza omogućava provođenje strukturiranog procesa i dobijanje rezultatata analize. (3) dokumentovanu reprezentaciju uslova ili mogućnosti definisanih pod (1) ili (2). a ne ulazi se u detalje kako i kada to napraviti. izlaza i skladišta podataka potrebnih da bi se odgovorilo na poslovne događaje. Analiza sa ciljem automatizacije poslovnih procesa omogućava razumijevanje postojećeg sistema. 4. • Uključivanje određivanja prioriteta zahtjeva. Jaroslav: Projektovanje informacionih sistema 69 4. Sačinjavaju je: • Tehnika modeliranja poslovnih zahtjeva za sistem. IEEE Std 610. Definisanje zahtjeva koje sistem mora posjedovati 4. . koja je usmjerena procesima. Koriste se dijagrami toka podataka za logički prikaz poslovnih zahtjeva. specifikacije ili neki drugi ugovoreni document. Osim toga. [IEEE Std 830-1998. (2) uslov ili sposobnost koju mora posjedovati sistem ili komponenta sistema da bi zadovoljila ugovor. ali se razvila tako da obuhvata i podatke. odnosno identifikovanje problema. Strukturirana analiza Moderna strukturirana analiza i Logički dizajn su česti sinonimi koji su u upotrebi. Uvod u definisanje zahtjeva IEEE (Institute of Electrical and Electronics Engineers) standard definiše zahtjeve koje mora posjedovati sistem kao: (1) uslov ili sposobnost koje korisnik treba da ima da bi riješio problem ili ostvario cilj. Omogućava strukturiranje procesa.1. kao i analizu i traženje uzroka problema i prioritete njihovog rješavanja. Zahtjevi ne sadrže detalje dizajna. analizu problema.3. ekstenzivno prikupljanje informacija i zahtjeva.

Poslovni zahtjevi definišu ciljeve organizacije (korisnički zahtjevi na višem nivou). korištenje subvencije za druge svrhe osim prehrane. poslovni zahtjev "Omogućiti Internet prodaju"). naplatu usluga koje nisu pružene. Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi. 4. zahtjevi za performansama. opisima scenarija rada.3. koju treba ugraditi u proizvod da bi omogućio korisnicima obavljanje njihovih zadataka. tj. Tipična posljedica su "prazna očekivanja". Vrste zahtjeva Zahtjevi mogu biti: poslovni zahtjevi (zašto). korisnički zahtjevi (zahtjevi krajnjih korisnika). Potrebno je još naglasiti da je potrebno odrediti prioritetete pojedinih zahtjeva. Nepotpuno definisani zahtjevi čine nemogućim planiranje projekta i praćenje promjena [Leffingwell. opisi vanjskih interfejsa. Primjer 1: Zahtjevi vlasnika sistema za studentsku subvencioniranu prehranu [Fertalj & Kalpić. pravila i ugovori koje proizvod mora zadovoljiti. Korisnički zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik mora moći obaviti služeći se aplikacijama ili koji su sadržani u opisima slučajeva korištenja. Naknadne prepravke mogu predstavljati do 40% troškova razvoja. ograničenja za dizajn i implementaciju. funkcionalni zahtjevi (šta) ili nefunkcionalni zahtjevi (kako ili kako dobro).2. 2005]. poslovna potreba "Poboljšanje usluge postojećim klijentima i pridobijanje novih") ili sadržani u dokumentima u kojima se opisuje vizija i opseg projekta (npr. razlika između onog što očekuje naručilac i onoga šta je izvršilac mislio da treba napraviti. odnosno daju opis problema koje treba riješiti (npr.70 Poliščuk E. odnosno skup logički povezanih funkcionalnih zahtjeva koje korisniku omogućavaju ispunjavanje poslovnih zahtjeva. Sistem mora onemogućiti: korištenje subvencije od strane osoba koje nemaju na to pravo. od čega je 70 do 85% pripisivo pogrešnim zahtjevima. 1997]. . Funkcionalni zahtjevi (šta) definišu softversku funkcionalnost (očekivano ponašanje i operacije koje sistem može izvoditi). Očekivana novčana ušteda: Sistem mora biti tako koncipiran da prava na subvencioniranu prehranu može koristiti samo student koji ih je stekao i da ih može koristiti samo u svrhu prehrane. Jaroslav: Projektovanje informacionih sistema Za 40 do 60% grešaka u projektu uzrok leži u greškama napravljenim u fazi postavljanja zahtjeva. te osobine kvaliteta koje preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim dimenzijama. U ovu grupu zahtjeva spadaju posebno zanimljive mogućnosti programa. a bitne su ili korisniku ili projektantu. zaradu ilegalnih posrednika.

Koji dio proizvoda će ispisati poruku?. Prehrana kod bilo kojeg izvršioca usluga: Novi sistem mora omogućiti da student ostvaruje svoje pravo kod bilo kojeg izvršioca usluge subvencionirane prehrane. student . Problem je rastavljen u više zahtjeva budući da će svaki zahtijevati posebno testiranje. Lakše ostvarivanje ostalih prava iz studentskog standarda. npr. Ukloniti nepotrebne postupke za ostvarivanje prava: Sistem mora biti tako koncipiran da kad se studentu jednom zavedu prava na matičnoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod izvršioca usluga. kina. Koliko doslijedni intervali moraju biti? Zahtjev definisan preciznije i detaljnije: Modul za nadzor će ispisivati statusnu poruku u za to određeni dio interfejsa. Primjer 4: Neostvariv zahtjev. Ukoliko je više zahtjeva grupisano u jedan lakše je previdjeti neki od njih tokom izrade ili testiranja.Poliščuk E. Modul će ispisati poruku o grešci ukoliko dođe do zastoja u izvođenju. Zahtjev "Softverski proizvod će ispisati statusnu poruku u redovnim intervalima. Zahtjev "Softverski proizvod će se trenutno prebaciti između ispisivanja i skrivanja oznaka koji se ne mogu štampati" je neostvariv zahtjev iz slijedećih razloga: Računari ništa ne mogu napraviti trenutno! Da li programska podrška sama odlučuje kad će se prebaciti iz jednog stanja u drugo ili je to inicirano akcijom korisnika? Na koji dio teksta će se primijeniti promjena prikaza: da li samo označeni tekst. Ukinuti plaćanje unaprijed: Treba izbjeći bilo kakvo plaćanje od strane studenata za potrebe ostvarivanja prava. a naročito unaprijed. modul za nadzor će ispisivati postotak obavljenog posla. Koliko dugo ostaje vidljiva?. Primjer 3: Nepotpuni zahtjev. Dosadašnja praksa je bila da svaki izvršilac usluga izdaje svoje bonove koji se mogu koristiti samo u određenim restoranima. cijeli dokument ili nešto . smještaj u studentskim domovima. javni prijevoz po povlaštenoj cijeni.servis. Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemogućiti zloupotrebu stečenih prava. Primjećuje se da u zahtjevu nije detaljno opisano kako i gdje će se poruka ispisivati. Modul za nadzor će ispisati "Zadatak obavljen" nakon što se zadatak obavi. To će biti odlučeno tokom dizajna. itd. pozorišta. Jaroslav: Projektovanje informacionih sistema 71 U idealnom slučaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima! Primjer 2: Zahtjevi krajnjih korisnika. Poruka će se ažurirati svakih 60 s (±10 s) nakon što započne izvođenje pozadinskog zadatka i biće vidljiva cijelo vrijeme. Ukoliko se pozadinski zadatak izvodi normalno. ne manjim od 60 sekundi" nameće slijedeća pitanja: Šta je statusna poruka i pod kojim uslovima će biti ispisana?.

3. koje korisnici moraju obavljati. Ona nisu funkcionalni zahtjevi. uz pomoć izvještaja. Primjer 5: Neodređeni zahtjev. koji omogućava brzu ispravku grešaka kada program koriste početnici u HTML-u" uočavaju se slijedeće neodređenosti: riječ "brzo" je neodređena. najvjerojatnije su slučajevi korištenja. Treba svima biti jasno zašto sistem „mora” biti u stanju da obavlja . ali nije točno navedeno kakvu (npr. Slučajevi korištenja ili scenariji: Opšte izjave o korisničkim ciljevima ili poslovnim zadacima. ispraviti greške?. Funkcionalni zahtjevi: Izjava koja počinje sa „Korisnik mora moći da obavi neku funkciju”. poslovni zahtjev. te opis svake greške. Uočava se i nejednoznačnost: da li su "oznake koje se ne mogu štampati" skrivene oznake. nije definisano šta predstavlja izvještaj i to čini zahtjev nekompletnim. posebne oznake ili kontrolne oznake? Bolji zahtjev glasi: "Korisnik će posebno dogovorenom akcijom. Poslovna pravila su operativni principi poslovnih procesa. Određivanje zahtjeva Poslovni zahtjevi: Sve što opisuje finansijski. šta se prepušta dizajnerima.72 Poliščuk E. Kada se generiše izvještaj? Bolje rješenje glasi: Nakon što je HTML analizator obradio datoteku. on možda opisuje poslovno pravilo. Sad je jasno da je riječ o HTML oznakama. Ukoliko nema grešaka prilikom analize. Specifične zadatke treba generalisati u opšte slučajeve korištenja. ili „Sistem treba moći da demonstrira određeno ponašanje” je najvjerovatnije funkcionalni zahtjev. Kako pronaći nekoga ko se smatra početnikom u HTML-u i zatim vidjeti kako brzo će. trgovački ili drugi poslovni prodor koji korisnici. Funkcionalni zahtjevi opisuju vidljivo ponašanje sistema i definišu šta će sistem raditi. najvjerovatnije. ili organizacija koja razvija sistem. dok specifični opisi zadataka predstavljaju korisničke scenarije. odabrati da li će se HTML (Hyper Text Markup Language) oznake u trenutno otvorenom dokumentu prikazivati ili ne". mogu dobiti je. U zahtjevu "Parser će brzo generisati izvještaj o greškama HTML oznaka. neće se generisati izvještaj. Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge.3. te da korisnik mora moći da obavi nekakvu akciju. pod određenim uslovima. Postavljaju se i slijedeća pitanja: Kako se ovjerava zahtjev?. generisaće izvještaj koji sadrži broj linije i tekst pronađenih HTML grešaka. 4. Jaroslav: Projektovanje informacionih sistema treće?. kombinacija tipki).

. pouzdanost.Poliščuk E. Potpuno obavezni zahtjevi se ne mogu rangirati. Neka ograničenja mogu pomoći u zadovoljavaju atributa kvaliteta. a ne zahtjev.4. Primjer je poboljšanje prenosivosti programa korištenjem samo standardnih naredbi nekog programskog jezika. uključujući i interfejse. intuitivnost. Kod postavljanja zahtjeva treba se usmjeriti na ono što je potrebno obaviti. kao glavni orjentir za učesnike na projektu. a ne na način realizacije. Neopravdana ograničenja treba pokušati odbaciti jer onemogućavaju postizanje najboljeg rješenja. Postavljanje prioriteta zahtjeva Nužno svojstvo sistema nameće pitanje: Da li vlasnik sistema nešto stvarno mora imati? Postoji tendencija da se previše zahtjeva proglasi nužnim! Po definiciji. „Korisnik odabira podatak koji želi iz padajuće liste”. Definicija podataka je bilo koji opis formata. taj sistem ne može ispuniti svoju svrhu. Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta. npr. Treba testirati svaki zahtjev koji se smatra nužnim i probati ga rangirati. Takođe. Predloženi funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neefikasne poslovne procese koji ne trebaju biti uključeni u novi sistem. Zahtjevi vanjskih interfejsa: Ova klasa zahtjeva opisuje veze između sistema i vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da uključuje odlomke za ove zahtjeve. Ideje o rješenju: Ako korisnik opisuje specifičan način interakcije sa sistemom. jer su nužni za prvu verziju sistema. jer to može pomoći u razumijevanju stvarne potrebe i korisnikovih očekivanja o načinu kako sistem treba da raditi. mogu umanjiti primjenu komercijalnog softvera i komponenti u rješenju. Zahtjeve koji opisuju poželjne karakteristike sistema: brzinu. ako sistem ne uključuje nužne zahtjeve. jednostavnost. kojom bi mogao obaviti neku akciju. Ograničenja su uslovi koji ograničavanju izbor rješenja raspoloživih dizajneru ili programeru. Treba istražiti zašto korisnik predlaže određenu ugradnju. jedna vrsta nefunkcionalnih zahtjeva. 4. hardver i druge softverske sisteme. Jaroslav: Projektovanje informacionih sistema 73 određene funkcije. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani. on predlaže rješenje. Ako se zahtjev može rangirati onda nije obavezan. da bi se precizno utvrdilo šta oni misle pod tim dvosmislenim i subjektivnim terminima. tj. te mehanizme komunikacije za korisnike. Predloženo rješenje može odvući pažnju od pravih zahtjeva. pretpostavljenih vrijednosti ili kompozicija složenih struktura podataka. dozvoljenih vrijednosti.3. Sve definicije treba pohraniti u Rječnik podataka. robustnost. sigurnost i efikasnost treba razmotriti sa korisnicima.

(2) narativni dokument namijenjen korisniku.2 Pregled dokumenata 1. a sačinjavaju ga poslovni i korisnički zahtjevi. Uvod 1. ili ga piše korisnik.3 Zahtjevi za sigurnošću podataka 5.5 Ograničenja dizajna i ugradnje 2.3 Kategorije korisnika i svojstva 2.4 Komunikacioni interfejs 4. ključne pretpostavke i preporuke za njihovo rješavanje. Jaroslav: Projektovanje informacionih sistema Poželjno svojstvo sistema su funkcije koje korisnik želi na kraju da ima.1 Namjena 1. Sveobuhvatni pregled 2.5 Referense 2.1 Opis i prioriteti 4.3 Ko treba čitati dokumente i savjeti za čitanje dokumenata 1. Specifikacija zahtjeva.2 Zahtjevi za sigurnošću korisnika 5. Ostali nefunkcionalni zahtjevi 5.x Svojstvo X 4. 4.2 Funkcije proizvoda 2. Predstavlja cjeloviti i nezavisan pogled na sistem. je strukturirani dokument sa detaljnim opisom očekivanog ponašanja sistema (tabela 4. Dokumentovanje analize zahtjeva Kratke definicije zahtjeva glase: (1) izjava o stanju.3. kao i njihovi prioriteti. iako bi lijepo bilo ih imati.1 Korisnički interfejs 3. takođe. mogu biti rangirani.5.1). To nisu pravi zahtjevi. Ovi zahtjevi. uočeni problemi.x.4 Opseg proizvoda 1.1 Zahtjevi za performansama sistema 5.74 Poliščuk E.4 Okruženje u kojem se izvodi proizvod 2. Svojstva sistema 4.4 Kvalitet programske podrške 5. Sačinjavaju ga funkcionalni i nefunkcionalni zahtjevi te njihovi Tabela 4.5 Poslovna pravila 5. 1. Ranije verzije sistema mogu pružiti (ne potpunu) funkcionalnost bez tih zahtjeva.3 Funkcionalni zahtjevi 5. često nazvana i funkcionalnom specifikacijom. Namijenjen je ugovaračima i izvršiocima razvoja. Zahtjevi za interfejsom 3.6 Pretpostavke i zavisnosti 3. Ostali zahtjevi Dodatak A: Rječnik Dodatak B: Modeli i dijagrami Dodatak C: Lista nedovršenih/neodređenih zahtjeva . ograničenjima i potrebama sistema. svojstva i mogućnosti bez kojih se može.2 Hardverski interfejs 3. Neobvezna svojstva sistema su proizvoljni zahtjevi.x.6 Korisnička dokumentacija 6.1.3 Softverski interfejs 3.2 Nizovi pobuda/odziv 4.x.1 Kontekst proizvoda 2. Poželjni zahtjevi mogu i trebaju biti rangirani.

4. Izrada takvih dodataka je nepotrebna i predstavlja gubljenje vremena. konzistentnost.3. Dobra specifikacija zahtjeva korisnika mora da sadrži slijedeća svojstva: potpunost. Zanemarivanje potreba: Zanemarivanje potreba određenih (grupa) korisnika izaziva stvaranje „opozicije“ projektu. nužnost. poredak po prioritetima. 4.3.Poliščuk E. nedvosmislenost i mogućnost provjere. Ta svojstva su: potpunost (cjelovitost). . na osnovu kojih se može pristupiti dizajnu i ugradnji pojedinih komponenata sistema. kao i degradaciju kvaliteta proizvoda. Čudni korisnički zahtjevi: Neopravdana promjena mišljenja tokom izvedbe uzrokuje prekoračenje predviđenog roka za realizaciju.6. Cilj je napisati dovoljno dobre zahtjeve. Nejasni (dvosmisleni) zahtjevi: Situacija u kojoj čitalac(i) zahtjeva taj zahtjev tumači(e) na više načina. ostvarivost (izvodljivost). Minimalističke specifikacije: Tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepata. Pretjerano ukrašavanje: Želja izvođača da dodaju novu funkcionalnost "koja treba da se svidi korisnicima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti. Uzroci lošeg planiranja zahtjeva Nedovoljna uključenost korisnika: Bez korisnika se ne može točno znati šta korisnici žele. opis toka dokumenata (dijagrami toka). uz želju da ih izvođači nadopune tokom izvedbe. To uzrokuje prepravljanje i gubljenje vremena.veze). Jaroslav: Projektovanje informacionih sistema 75 prioriteti. kao i konceptualni model podataka (dijagrami entiteti . Svojstva dobro postavljenih zahtjeva Svojstva dobro postavljenih korisničkih zahtjeva su definisana IEEE standardom [1998]. model procesa (dijagrami toka podataka). uz prihvatljiv stepen rizika. tačnost.7. mogućnost izmjene i mogućnost praćenja. izaziva frustracije izvođača i neispunjena očekivanja korisnika. model organizacione strukture (strukturirani dijagrami). Takvi proizvodi su neprihvatljivi.

76

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Primjer dobro postavljenih korisničkih zahtjeva:
“Hemičar ili član osoblja hemijske laboratorije može podnijeti zahtjev za jednom ili više hemikalija. Zahtjev može biti udovoljen ili dostavom pakovanja hemikalije koja se već nalazila na zalihi hemijske laboratorije ili upućivanjem narudžbe za novim pakovanjem hemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kada je ispunjen do trenutka kada je udovoljen ili otkazan. Takođe, mora pratiti istoriju svakog pakovanja hemikalija od trenutka kada stigne u kompaniju do trenutka kad je potpuno upotrebljen ili odbačen.”

Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sistema (procesi, podaci, događaji). Mogu se definisati preslikavanja uočenih imenica i glagola u konkretne komponente analitičkog modela. Moguća preslikavanja su opisana u tabeli 4.2. Tabela 4.2.
Tip riječi Imenica Primjer - Ljudi, organizacije, softverski sistemi, jedinice podataka ili postojeći objekti Komponente analitičkog modela - Skladišta podataka (DFD – modeliranje toka podataka) - Entiteti ili njihovi atributi (ERD – dijagram entiteti - veze) - Klase ili njihovi atributi (dijagram klasa) - Procesi (DFD) - Odnosi (ERD) - Prelazi (iz stanja u stanje) (STD – dijagram prelaza stanja) - Metode klasa (dijagram klasa)

Glagol

- Akcije, ono što korisnik može poduzeti ili događaji koji se mogu dogoditi

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

77

5. Modeliranje fukcija i procesa
5.1. Uvod u modeliranje funkcija i procesa
Logički procesi (koje sačinjavaju funkcije, događaji i elementarni procesi) su akcije koji se obavljaju bez obzira na način ugradnje i raspoložive resurse sistema. Neke metode poistovjećuju funkcije i procese. Stvarni problemi su preveliki i presloženi da bi se riješili odjednom („u komadu”), te je potrebno njihovo strukturno raščlanjivanje (razlaganje). Načelo je poznato i glasi „podijeli pa s/vladaj” (lat. divide et impera, eng. divide and conquer). Sistem se razlaže i opisuje hijerarhijskim modelima. Modeli sistema se oblikuju iterativnim razlaganjem sa vrha prema dolje. Razlagati se mogu: funkcije i procesi, organizaciona struktura, struktura podataka i struktura programske opreme.

5.1.1. Logički procesi
Funkcije su skup logički povezanih trajnih poslovnih aktivnosti i zadataka (npr. djelatnost, posao). Funkcije se obavljaju stalno (nemaju određeni početak i kraj). Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline. Primjeri funkcija: Prodaja, proizvodnja, otprema, računovodstvo. Funkcija se može sastojati od desetina pa i stotina diskretnih procesa. Funkcije se mogu hijerarhijski razložiti do nivoa diskretnih procesa, koji obavljaju određeni zadatak kojim odgovaraju na poslovne događaje. Događaj je logički dio posla koji se obavlja kao nedjeljiva cjelina. Često je u upotrebi i naziv transakcija. Pokreće se diskretnim ulazom i završava nakon što proces odgovori odgovarajućim izlazom. Poslovni događaj može se predstaviti jednim procesom kojim sistem reaguje na taj događaj. Logički događaj dalje se razlaže do elementarnih procesa kojima se prikazuje reakcija sistema na taj događaj. Proces (elementarni, primitivni proces) je postupak, način rada, doslijedna izmjena stanja. Takođe, proces je diskretna odluka, aktivnost ili zadatak kojim se obavlja neki posao.

78

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Proces se obavlja uvijek na isti način (za određeni ulaz se dobija isti izlaz). Trajanje procesa je konačno i odredivo (poznati: početak, završetak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska). Poslovna pravila su instrukcije i logika koji određuju proceduru obavljanja procesa. Ugrađuju se u računarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa). Poslovna politika je skup poslovnih pravila. U većini poslovnih sistema predstavlja osnovu za donošenje odluka.

5.1.2. Modeliranje funkcija
Funkcionalna dekompozicija (dekompozicija funkcija) se koristi za izradu opšteg modela funkcija (modela poslovnih funkcija) posmatranog sistema u fazi planiranja, što predstavlja strukturirano planiranje. Hijerarhija funkcija iterativno se razlaže do nivoa procesa, tj. do trenutka kada se počne opisivati šta se nekom funkcijom obavlja (slika 5.1).

Slika 5.1. Iterativno razlaganje hijerarhija funkcija do nivoa procesa. Dijagram funkcionalne dekompozicije (Functional Decomposition Diagram (FDD)) koristi istu notaciju za razlaganje bilo koje hijerarhijske strukture, pa se često zove samo Dijagram dekompozicije ili Mapa hijerarhije.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

79

Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi. Funkcije se označavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osušiti dio), spojnice su spojevi između funkcija i procesa, a vanjski spojevi su spojevi sa dijelovima dijagrama na drugim stranicama (slika 5.2). Primjer dijagrama dekompozicije za jedan sistem /podsistem prikazan je na slici 5.3.
Funkcija

Proces

Slika 5.2. Elementi dijagrama dekompozicije.
MARKET

Nabava

Knjigovodstvo

Prodaja

Evidentiranje dobavljača

Naručivanje robe

Knjiženje

robe

Evidentiranje kupca

Fakturisanje robe

Prodaja robe

Izrada narudžbi

Zaprimanje robe

Izrada otpremnice

Otprema robe

Dodavanje

Ažuriranje

Brisanje

Slika 5.3. Primjer dijagrama dekompozicije za jedan sistem/podsistem.

80

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Izrada globalnog modela funkcija može započeti izradom hijerarhijske liste funkcija po pojedinim organizacionim cjelinama. Primjer: • NABAVA • Evidentiranje dobavljača • Nabavka robe - Izrada narudžbi - Zaprimanje robe UPRAVLJANJE OSOBLJEM • Evidentiranje službe - Prijem u službu - Praćenje službe » redovni rad » prekovremeni rad » bolovanje » godišnji odmori - Otpuštanje iz službe • Obračun plata

Izrada dijagrama dekompozicije odvija se po slijedećem postupku. Polazi se od korijena dijagrama, kome se dodjeljuje ime sistema. Slijedi razrada u podsisteme i poslovne funkcije. Daljnja razrada je do nivoa operacionalizacije. Pri izradi dijagrama dekompozicije potrebno je pridržavati se slijedećih pravila: svaki proces je roditelj ili dijete, roditelj mora imati barem dvoje djece, dok po većini standarda, dijete smije imati samo jednog roditelja. Preporuke: Izostaviti procese koji samo premještaju ili preusmjeravaju podatke, a pri tome ih ostavljaju nedirnute. Pažnju usmjeriti na procese koji: nešto računaju (npr. prosjek ocjena), donose ili potpomažu odluke (npr. određivanje raspoloživosti robe pri naručivanju), filtriraju ili sumiraju podatke (npr. računi kojima je istekao rok plaćanja), organizuju podatke u korisne informacije (npr. generisanje izvještaja), pokreću druge procese (npr. mijenjaju modalitet rada uređaja) ili rukuju podacima (npr. stvaranje, čitanje, ažuriranje, brisanje i slično). Pomoću hijerarhijskih dijagrama se može prikazati funkcionalna dekompozicija realnog sistema. Takav jedan dijagram, dobijen pomoću alata Function Hierarchy Diagramer (Designer 2000, ORACLE), je prikazan na slici 5.4. Svaka funkcija, koja se kreira putem navedenog alata istovremeno predstavlja i proces u budućim dijagramima toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju sinonime u terminologiji mnogih CASE alata.

postoji mogućnost da se elementarna funkcija dalje dekomponuje na atomične funkcije. Primjer dijagrama dekompozicije funkcija (procesa).1. mapa. ORACLE). karta organizacije) daje prikaz strukture organizacije hijerarhijom pravougaonika („kućica"). za definisanje organizacione strukture sistema. U cilju preciznijeg specificiranja. ne moraju dalje dekomponovati i tada one predstavljaju listove u hijerarhijskoj strukturi funkcija. ili će efekti njenog izvršavanja u cjelosti biti poništeni. Svaki pravougaonik predstavlja određenu ulogu ili odgovornost u organizaciji (slika 5. Jaroslav: Projektovanje informacionih sistema 81 Slika 5. Dijagram organizacije Dijagram organizacije (shema. u principu. čija je ekranska forma prikazana na slici 5. . 5.5.6.4. Elementarne funkcije se. Za funkciju se kaže da je elementarna ukoliko njeno započinjanje podrazumjeva da će se ona u cjelosti izvršiti. može se upotrijebiti alat za neposredni pristup rječniku podataka. Osim dijagramsko orijentisanog alata. U ovu grupu alata spada Repository Object Navigator (Designer 2000. koje u tom slučaju predstavljaju listove u hijerarhijskoj strukturi funkcija.3. Pored osnovnih podataka za funkcije. pomoću hijerarhijskog navigatora objekata. za svaku funkciju se određuje da li je riječ o elementarnoj funkciji ili ne.).Poliščuk E.

6. Slika 5.82 Poliščuk E. Dijagram organizacije. Jaroslav: Projektovanje informacionih sistema Dekan XXX Sekretarica XXX Prodekan za nastavu XXX Stud. . ORACLE). služba XXX Prodekan za naučni rad XXX Finansijska služba Prodekan za finansije XXX Sekretar XXX Institut XXX Biblioteka Računarska tehnika Informacioni sistemi Slika 5.5.Ekranska forma CASE alata Repository Object Navigator (Designer 2000.

Metode strukturiranog modeliranja. odnosno poslovne (organizacione) cjeline. Jaroslav: Projektovanje informacionih sistema 83 Prozor na lijevoj strani ekranske forme prikazuje hijerarhijski navigator objekata rječnika. analize i dokumentovanja tehnoloških procesa 5. IDEF1. Elementi organizacione strukture se definišu kreiranjem pojava tipa objekta pod nazivom Business Units. prilikom unošenja nove organizacione cjeline. IDEF5 i IDEF9). Navođenjem oznake neposredno nadređene organizacione cjeline. desna – „izlaza“. 5. Prikaz bloka „poslovna funkcija“. IDEF1x.1. koja je definisana nizom standarda (IDEF0.Poliščuk E. Ova familija metoda se uspješno primjenjuje u najrazličitijim oblastima i pokazala kao efikasno sredstvo za analizu. koji odražava nekoliko poslovnih funkcija. IDEF3. Osnovni pojmovi IDEF0. . Metodologija funkcionalnog modeliranja IDEF0 je zamišljena kao inženjerska disciplina za razvoj složenih sistema. Upravljanje Ulaz Poslovna funkcija Izlaz Mehanizam Slika 5.2.7. gornja – „upravljanja“ i donja – mehanizma“. Četiri strane bloka imaju slijedeće uloge: lijeva strana ima ulogu „ulaza“. koja uključuje uređaje i ljude. Metodologija funkcionalnog modeliranja IDEF0 Za realizaciju programa integrisane kompjuterizacije proizvodnje razrađena je familija metoda IDEF (Integrated Definition Function Modeling). IDEF4. uspostavlja se hijerarhijska struktura organizacionih cjelina (desna strana ekranske forme).SADT® i SofTech. U osnovi IDEF0 metodologije se nalazi pojam bloka. nastale 1960-ih godina.2. Predstavlja metodu za modeliranje tehnoloških procesa i funkcija. Ranije tehnike za ovu namjenu su Structured Analysis and Design Technique . projektovanje i predstavljanje (modeliranje) tehnoloških procesa.

U IDEF0 su realizovana tri osnovna principa modeliranja procesa: princip funkcionalne dekompozicije.84 Poliščuk E. Na kontekstnom dijagramu se prikazuje samo jedan blok.7).8. Grafički prikaz funkcionalne dekompozicije. koji se sastoji od: • • • • ulaz (I = Input): nešto što se troši u procesu (nije obavezan). Princip ograničenja složenosti se sastoji u tome da broj blokova na dijagramu mora biti od 2 do 6. upravljanje (C = Control): ograničenje na izvršavanje procesa (obavezno). koji sa izlaza jedne funkcije dolaze na ulaz druge.8. Pri određivanju glavne poslovne funkcije. Slika 5. princip ograničenja složenosti i princip konteksta. slika 5. neophodno je imati u vidu cilj modeliranja. Jedan poslovni sistem se može opisati na razne načine. poslovne funkcije se mogu prikazati ICOM konceptom (slika 5. Jaroslav: Projektovanje informacionih sistema Uzajamno dejstvo između funkcija u IDEF0 se predstavlja u obliku duge. izlaz (O = Output): rezultat procesa (obavezan). „izlazni“ ili „upravljački“. Drugim rječima. ali se ne troši (nije obavezan). Princip funkcionalne dekompozicije se sastoji u predstavljanju složene poslovne funkcije skupom elementarnih funkcija. Principi modeliranja u IDEF0. mehanizam (M = Mechanism): koristi se u procesu. Princip konteksta se sastoji u tome da modeliranje poslovnog procesa počinje sa crtanjem kontekstnog dijagrama. u zavisnosti od toga sa kog stanovišta se posmatra. . U zavisnosti od toga sa koje strane bloka se nalazi. koja odražava tok podataka ili materijala. tok dobija naziv „ulazni“. odnosno samo glavna poslovna funkcija sistema koji se modelira.

neminovno se postavlja pitanje kako ovo modeliranje pomaže povećanju efikasnosti i kvaliteta djelatnosti poslovnog sistema. Izgrađeni funkcionalni modeli KAKO JE omogućavaju jasno utvrđivanje koji poslovni procesi se ostvaruju u poslovnom sistemu. Na slici 5. koja se koriste u radu poslovnog sistema. koji se informacioni objekti koriste pri izvršavanju poslovnih procesa i zasebnih operacija. документооборот – kretanje dokumenata u organizaciji od trenutka nastajanja ili dobijanja do završetka korištenja ili odašiljanja). Postojeći modeli KAKO JE.9 je predstavljen dio funkcionalnog modela toka dokumenata (eng.Poliščuk E. DocFlow. Nakon upoznavanja s osnovnim pojmovima funkcionalnog modeliranja poslovnih procesa. Instrukcija Dokument za rukovodstvo Sortirati dokumente Neregistrovani dokumenti Dokumenti za direktora podliježu registraciji Registrovati dokumente Registrovani dokumenti Prijemno Slika 5. pojave problema i „uskih grla“ u razradi projekta usavršavanja poslovnih procesa. Funkcionalni model KAKO JE je polazna tačka za analizu zahtjeva poslovnog sistema. odnosno određuje uzajamnu vezu između sistema koji se modelira i njegovog okruženja. Razmatrani poslovni sistem je obavezno dio nekog projekta izgradnje ili razvoja korporativnog IS. rus. Poslovna pravila. Pri izvršavanju operacije „sortirati dokumente“ koristi se poslovno pravilo: „ne podležu registraciji kopirani . Grafički prikaz dijela funkcionalnog modela toka dokumenata. Model parcijalnih procesa omogućava uočavanje i tačno određivanje poslovnih pravila. Jaroslav: Projektovanje informacionih sistema 85 Kontekstni dijagram ima još jednu ulogu u funkcionalnom modeliranju. On „određuje“ granice modeliranja poslovnog sistema.9.

i to: tehnike za dokumentovanje tehnoloških procesa (IDEF3) i tehnike za oblikovanje tokova podataka (DFD). Funkcionalni model KAKO ĆE BITI omogućava već u fazi projektovanja budućeg IS predviđanje tih promjena. on podliježe sortiranju. Izgrađeni modeli KAKO ĆE BITI. IDEF1x). koji se odvijaju u poslovnim sistemima. kao i strukture poslovnih procesa. Za razliku od nekih informacionih modela (Data Flow Diagrams (DFD). telegrami i pisma“. koja prikazuje tok informacija. na osnovu instrukcije. i predstavlja alat za vizuelno praćenje i modeliranje njihovih scenarija. Funkcionalni model omogućava jasnu raspodjelu resursa između operacija poslovnog procesa. Informacioni objekti. Pod scenarijom se podrazumjeva opis redoslijeda promjena svojstava objekata. U okviru funkcionalnog modela poslovno pravilo ima slijedeći oblik: „ukoliko je u prijemno došao dokument namjenjen rukovodstvu. ekspertiza). Taj zadatak je naročito aktuelan pri uvođenju novih poslovnih procesa u poslovnom sistemu. 5. nego i na kom radnom mjestu poslovno pravilo se mora primjeniti. Jaroslav: Projektovanje informacionih sistema dokumenti. ne samo skraćenje roka implementacije IS. modifikaciju važećih instrukcija zaposlenih.86 Poliščuk E. Raspodjela resursa. opis standarda) i tok dokumenata koji odražavaju hod njegovog izvršenja (npr. Funkcionalni model omogućava identifikaciju svih informacionih objekata. nego i smanjenje mogućeg rizika uslijed neprilagođenosti korisnika informacionim tehnologijama. Izvršavanje svakog scenarija prati odgovarajući tok dokumenata. Daljnja razrada metodologije funkcionalnog modeliranja IDEF0 je razvoj slijedeće dvije tehnike. u okvirima razmatranog procesa (npr.2. Funkcionalni model omogućava ne samo identifikaciju postojanja pravila. Ovo pravilo je definisano u instrukciji o toku podataka. koji je dvojak: tok dokumenata koji određuju strukturu i redoslijed procesa (npr. funkcionalni model IDEF0 određuje kako se koriste informacioni objekti u okvirima poslovnih procesa. rezultati testova. se određuje da li dokument podliježe registraciji ili ne“. promjena u poslovnom sistemu. a kao rezultat. šta doprinosi efikasnosti korištenja resursa. Dokumentovanje tehnoloških procesa IDEF3 Metoda IDEF3 predstavlja standard za dokumentovanje tehnoloških procesa. koje koristi poslovni sistem u svojoj djelatnosti. Primjena funkcionalnog modela KAKO ĆE BITI omogućava. tehnološke napomene. . To zahtjeva promjenu poslovnih pravila. Razvoj i implementacija korporativnog IS dovodi do promjena uslova izvršavanja pojedinih operacija. opis redoslijeda etapa obrade dijelova u radionici i promjena njihovih svojstava nakon završetka svake etape).2.

. Svaki UOB se imenuje glagolskim izrazima oblika infinitiv + objekat i jedinstvenim brojem. koje se javljaju u svakoj fazi obrade.obavlja se samo jedna od povezanih aktivnosti. izlaz prethodne je ulaz u slijedeću aktivnost.obavlja se jedna ili više povezanih aktivnosti. Dijagrami prvog tipa su Dijagrami opisa redoslijeda faza procesa (Process Flow Description Diagrams (PFDD)). Pomoću dijagrama PFDD dokumentuje se redoslijed i opis faza obrade dijela u okviru razmatranog tehnološkog procesa.10. Dijagrami OSTN se koriste za ilustraciju transformacija dijela.junction) su slijedeće: • & (logičko I) .prethođenje (Precedence). • O (ILI) . Prelazi. prethodna aktivnost se mora završiti da bi slijedeća započela (crta se slijeva nadesno ili odozgo prema dole). povezivanje uz korisnički definisani uslov. OFARBATI PONOVO OFARBATI DIO OSUŠITI DIO TESTIRATI DIO POSLATI U SLIJEDEĆU RADIONICU Slika 5. Na dijagramima za veze između funkcija se koriste slijedeći grafički simboli: . Razmatrani proces se sastoji od farbanja i faze kontrole kvaliteta.tok objekata (Object Flow). koji predstavljaju opise jednog te istog scenarija tehnološkog procesa iz različitih uglova posmatranja. Pravougaonici na dijagramu PFDD se zovu funkcionalni elementi ili elementi ponašanja (Unit of Behavior (UOB)) i označavaju aktivnosti. Dijagrami PFDD služe za vizuelni prikaz scenarija odvijanja procesa u realnom sistemu. koji predstavlja grafičku predstavu scenarija obrade dijela. a drugi tip su Dijagrami stanja objekta i njegovi transformacioni procesi (Object State Transition Network (OSTN)). . Jaroslav: Projektovanje informacionih sistema 87 Postoje dva tipa dijagrama u standardu IDEF3. Primjer PFDD dijagrama. Primjer: Potrebno je opisati proces farbanja dijelova u proizvodnoj radionici.svaka povezana aktivnost uvijek se obavlja/završava.10 je prikazan dijagram PFDD. fazu procesa ili primljena rješenja. koja određuje da li je potrebno dio ponovo ofarbati (u slučaju odstupanja od standarda) ili ga poslati na dalju obradu. Na slici 5.Poliščuk E. .relacioni (Relational Link). veze (J . • X (ekskluzivno ILI) .

tok. depozit. ali to može biti i bilo koji drugi proces iz funkcionalne dekompozicije. Svaka linija je povezana sa odgovarajućim funkcionalnim blokom UOB.11. pri čemu se cjelokupna hijerarhija organizacionih jedinica. nazivaju koracima ili aktivnostima. a kao rezultat je prikazana promjena stanja objekta. ima svoju oblast nadležnosti u . Stanje objekta je prikazano krugovima. okidač (triger) i ciljni rezultat. prikazana na dijagramu. Stanje objekta.11. Primjer OSTN dijagrama. UOB/ Testirati sloj boje UOB/ Ofarbati dio Novi sloj boje Rijetka boja Tvrda boja na dijelu UOB/ Osušiti dio UOB/ Testirati sloj boje Ispolirati sloj boje Slika 5. sa izvodom iz jednog dijagrama. Za svaki proces u hijerarhiji dekompozicije se formira jedan dijagram. Procesi na dijagramu se. onda dijagram OSTN omogućava posmatranje istog procesa „sa stanovišta objekta“. su prevashodno neposredno podređeni procesi kontekstnom procesu. koji se na samom dijagramu prikazuju. Svaka organizaciona jedinica. proces (funkcija). Procesi.12 je prikazana ekranska forma. prikazuje na krajnjem lijevom dijelu dijagrama. Organizacija dijagrama procesa prati funkcionalnu dekompoziciju IS. dijela u razmatranom primjeru. Na slici 5. ili neki njen dio. CASE alat Process Modeller omogućava oblikovanje i prikaz organizacione strukture poslovnog sistema. CASE alata Process Modeller (Designer 2000. koji je namjenjen za izradu dijagrama procesa. i promjena tog stanja su ključni pojmovi OSTN dijagrama. Prilikom otvaranja novog dijagrama bira se proces za koji se dijagram crta i taj proces se zove kontekstni proces. slika 5.88 Poliščuk E. Jaroslav: Projektovanje informacionih sistema Ako je dijagram PFDD tehnološki proces „sa stanovišta posmatrača“. Process Modeller je zasnovan na slijedećim konceptima: organizaciona jedinica. ORACLE). a promjene stanja usmjerenim linijama. u terminologiji ovog alata.

omogućava prikaz protoka. Modeliranje toka podataka (Data Flow Diagram (DFD)) Dijagram toka podataka (DTP) je skup sredstava za dokumentovanje fizičkog i logičkog modela sistema. 5. Slika 5.3. koja se proteže u visini odgovarajuće organizacione jedinice. Matrica „organizacione jedinice/procesi” se definiše pomoću dijagrama procesa. Oblast nadležnosti je na dijagramu prikazana u obliku horizontalne trake. To znači da je za sve procese u danoj oblasti zadužena nadležna organizaciona jedinica. Dijagram procesa na ekranskoj formi CASE alata Process Modeller (Designer 2000. .13).Poliščuk E.12. strukture i obrade podataka. ORACLE). te dokumentovanje logike poslovnih pravila i procedura (slika 5. Jaroslav: Projektovanje informacionih sistema 89 pogledu izvođenja pojedinih aktivnosti.

Nazivom treba izraziti šta proces obavlja. pražnjenje) i korištenje (čitanje) obavlja se procesima. mjehurasti dijagram (Bubble Chart). se primjenjuje pri razvoju aplikacija. . npr. koriste se i mijenjaju u toku obavljanja procesa (ulazno/izlazni) ili nastaju kao rezultat procesa (izlazni).13. Označava mjesto pohrane podataka. mjehurasti grafikon. Tokovi ulaze u procese (ulazni). Spremište podataka (data store) predstavlja organizovani i trajni skup podataka. Tehnika. Tokovima se dodjeljuju jedinstveni nazivi oblika imenica ili pridjev+imenica. Izlazni račun. Proces predstavlja aktivnost pretvaranja podataka (ulaznog u izlazni tok podataka). Obavljanje poslova nabavke). relacija (tabela) u bazi podataka. Jaroslav: Projektovanje informacionih sistema Sinonimi za dijagram toka podataka su: transformacioni grafikon. Elementi dijagrama toka podataka Tok podataka (data flow) predstavlja skupove podataka koji se kreću kroz sistem. 5. Opis procesa sadrži opis aktivnosti (algoritam) njegovog djelovanja.90 Poliščuk E. Procesi se imenuju glagolskim izrazima oblika infinitiv+objekat (npr. odakle je i potekla. Uprošteni dijagram toka podataka. Spremište se označava imenicom (imenicom u množini). datoteka. D1 Spremište podataka Tok podataka a P1 Vanjski entitet Tok materijala Proces 5. Prodaja. izradu upravljačkih specifikacija ili dizajn korisničkog interfejsa. Prijava ispita). ažuriranje. Ne može se koristiti za opis programske logike. koja se koristi za modeliranje toka podataka. Potvrđena prijavnica. to jest treba izbjegavati opšte nazive (npr. registrator. npr.3. Prijavnica (Prijavnice). opis promjene stanja. npr.1. Promjena sadržaja spremišta (punjenje. dokument. Prijaviti ispit) ili glagolskom imenicom (npr.

3. Izrada dijagrama toka podataka Dekompozicija procesa se odvija na slijedeći način. Dobavljač. to jest izvore i ponore podataka.14. Proces na nekom nivou razrađuje se dijagramom na nižem nivou. Slika 5. ustanove. Jaroslav: Projektovanje informacionih sistema 91 Vanjski entitet (external entity. 5. npr. . Primjer dijagrama toka podataka oblikovan pomoću alata Dataflow Diagramer (Designer 2000.Poliščuk E.2. external agent) je objekat vanjskog svijeta povezan sa posmatranim sistemom. Određuje granice posmatranog sistema. Polazni dijagram ili dijagram konteksta hijerarhijski se razlaže na poddijagrame do nivoa osnovnih procesa. Vanjski entiteti predstavljaju izvorišta i odredišta podataka. a poželjno je slijediti “pravilo 7±2” (slika 5. Vanjski entiteti mogu biti osobe. Preporučuje se izrada dijagrama koji sadrže između 2 i 9 procesa. Student.14). drugi sistemi. Za označavanje entiteta se koriste imenice. orgazicione jedinice. Kupac. ORACLE) ..

ili slovo+broj. Nivo konteksta se označava „0”. a nakon toga određuju vanjski entiteti i njihova povezanost sa sistemom (slika 5. Primjer dijagrama konteksta: Videoteka. Procesi i tokovi podataka se označavaju malim slovima. Prikazuje jedan proces i vanjske entitete. Nazivi spremišta. Zahtjev za identifikaciju P0 Narudžba 0 Osoba Identifikacija Članska karta 0 Videoteka Novi video Dobavljač Rezultat upita Zahtjev za rezervaciju Video Članska karta i plaćanje Upit 0 Član Slika 5. Definiše okruženje sistema i područje analize. kao i utvrđivanje procesa i spremišta podataka (slika 5.92 Poliščuk E. određivanje glavnih aktivnosti sistema i njihovo prikazivanje odgovarajućim procesima. Započinje se procesom koji prikazuje sistem u cjelini.15. izvora i odredišta se označavaju velikim slovima. potrebni podaci).16). korišteni dokumenti.15). . Hijerarhijski nivoi nose brojčane oznake. utvrđivanje sa korisnikom granica sistema. Dijagram konteksta prikazuje sistem na najvišem nivou hijerarhije prikaza. slovne oznake. pregledni dijagram omogućava uključivanje vanjskih entiteta i tokova podataka sa dijagrama konteksta. Osim navedenog. Jaroslav: Projektovanje informacionih sistema Postupak se zaustavlja kada postane očigledna ugradnja (implementacija) procesa na najnižem nivou. Pregledni dijagram (initial diagram) omogućava uočavanje glavnih tokova informacija (npr. Preporuke za označavanje elemenata kojih se treba pridržavati prilikom crtanja dijagrama su slijedeće.

određivanje granica sistema. a zatim ga po potrebi ažurirati. Model obrazložiti korisniku. Određivanje dometa dijagrama toka podataka: Videoteka [Fertalj & Kalpić. čak i kada dijagrame rade iskusni analitičari. U toku razrade procesa na poddijagramu. za proces Upisati novog člana. Ponavljati postupak za svaki od procesa na poddijagramu. Rezervisati video Slika 5. U praksi to može značiti doradu dijagrama u većem broju ponavljanja. evidentirati novog člana i izraditi člansku kartu (slika 5.16. Na kraju je potrebno provjeriti potpunost i ispravnost modela. Uspostaviti nivo detalja slijedeći “pravilo 7±2”.Poliščuk E. 2005]. podaktivnosti su: zatražiti lične podatke. Na primjer. Jaroslav: Projektovanje informacionih sistema 93 Primjer: Pregledni dijagram.17). Dubinu i uravnoteženost modela teško je odrediti. . potrebno je za svaki proces sa preglednog dijagrama identifikovati podaktivnosti.

4. 5.3. Jaroslav: Projektovanje informacionih sistema Zahtjev za identifikaciju P1. Ograničenja i posebni slučajevi su slijedeći. crne rupe).4 Evidentirati novog člana D1 Član P1.94 Poliščuk E. npr.: postojanje procesa bez ulaza i/ili izlaza (tzv. tok T na nižim nivoima prikazivati kao T1. Nije dozvoljeno variranje tokova nekog nivoa na nižim nivoima (npr. T2). spremišta i vanjskog entiteta. Preporuke za izradu DTP Prilikom izrade DTP treba voditi računa o trivijalnim tokovima podataka. spremišta.3. Ne dozvoljava se neposredna povezanost vanjskih entiteta. Svi objekti modela moraju biti povezani. spajanje različitih tokova. 5. Nepovezanost pojedinih objekata ukazuje na nepotpunost modela. Pravila i ograničenja kod izrade DTP Pravilo balansa (očuvanja) tokova glasi: Količina tokova koji ulaze u proces i izlaze iz procesa mora odgovarati količini tokova podprocesa na nižem nivou hijerarhije. kao i postojanje “rekurzivnih” procesa.3. izlaza za koje ne postoji dovoljno ulaza (tzv. neposredno povezanim procesima i procesima koji ne obavljaju pretvaranje podataka. sive rupe) i postojanje nepovezanih spremišta ili vanjskih entiteta. Određivanje dubine i uravnoteženosti modela podataka. Nije dozvoljeno grananje toka u različite tokove.3 Član Član Izraditi člansku kartu Članska karta Slika 5. .1 Identifikacija Zatražiti lične podatke Lični podaci P1.17.

14). Najčešće primjenjivane notacije su: 1. dojava greške).18.Primjer prespajanja toka podataka. Neposredno povezani procesi su kada jedan od procesa čeka na završetak prethodnog. SSADM (korištena na slici 5.5. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. 3.18. Obično imaju posebno značenje. Notacije koje koriste DTP Postoje različite notacije koje se koriste kod izrade DTP. koje su navedenim redoslijedom prikazane na slici 5. Yourdon/DeMarco. slika 5. 2.Poliščuk E. Slika 5. a mogu se koristiti za prikaz posebnih stanja kao što je dojava poruke sistema (npr. 5. Procesi se mogu odvijati istovremeno. šta je učinjeno sa tokom podataka b.3. Gane/Sarson (korištena u primjerima). U tom slučaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova.19. Jaroslav: Projektovanje informacionih sistema 95 Trivijalni tokovi su izlazi iz procesa koji ne ulaze u spremišta ili odredišta. .

ni jednom do konačni broj puta Alternativa (selekcija) elemenata u zagradi Odvajanje alternativnih elemenata u [ ] izrazu . Standardno se upotrebljava BNF notacija (Backus-Naur Form). podataka o podacima. za pohranu opisa spremišta podataka i tokova podataka. Jaroslav: Projektovanje informacionih sistema P1 Vanjski entitet Ulazni tok Proces D1 Izlazni tok Spremište podataka Vanjski entitet Ulazni tok 1 Proces Izlazni tok Spremište podataka Vanjski entitet a 1 Ulazni tok Proces D1 Izlazni tok Spremište podataka Slika 5. razdvajanje i spajanje tokova (alternativni tokovi). koja se inače koristi za opis sintakse programskih jezika. tabela 5.6.1. Opisivanje podataka Rječnik podataka (Data Dictionary) je mjesto pohrane definicija elemenata podataka i struktura podataka. kao i posebnih simbola za tok resursa.1. Prvobitno se pojavio kao proširenje dijagrama toka podataka. tri puta dnevno). Može se koristiti kao alternativna tehnika za prikaz modela podataka. Tabela 5.19. različite linije ili ikone). zatim posebnih simbola za prikaz ponavljanja procesa. 5. Predstavlja strukturirano spremište meta-podataka. Proširenja modela je izvršeno uvođenjem okidača (trigera).96 a Poliščuk E. Notacije koje se koriste kod izrade DTP. tj.3. = + () {} [] | Struktura s lijeva se sastoji od dijelova s desna („sastavljeno od“) Agregacija elemenata (logičko I) Opcionalnost elemenata u zagradi (0 ili 1) Ponavljanje (iteracija) elemenata u zagradi. koji prikazuju učestalost procesa (npr. tok dokumenata ili tok upravljanja (npr.

Vrijednost } + (IznosRac) Može se napisati i kao: Racun = @BrRac + DatRac + BrKupca + { StavkaRac } + ( IznosRac ) StavkaRac = @SifArt. Primjer opisivanja podataka. . šta definiše strukturu podataka. kao i tokove podataka (slika 5. Kol. Nakon toga se opisuju grupe sačinjene od elementarnih podataka. Kol.20. NazArt. Racun = @BrRac + DatRac + BrKupca + { SifArt. Jaroslav: Projektovanje informacionih sistema 97 ** @ Početna i završna vrijednost raspona definisanog [ ] izrazom Komentar Oznaka ključa Primjer: Opis računa i stavki računa korištenjem BNF notacije. Struktura podataka određuje sadržaj spremišta podataka.20). NazArt. Najmanja logička cjelina podataka Grupe sačinjene od elementarnih podataka Elementarni podatak Struktura podataka Grupe sačinjene od struktura podataka Tok podataka Spremište podataka Slika 5. odnosno elementarnih podataka. Cijena.Poliščuk E. Cijena. Vrijednost Primjer: Opis podataka može započeti opisom najmanje logičke cjeline podataka.

Proces 1: Opis: Ulazni tokovi: Provjera raspoloživosti filma Provjera da li u videoteci postoji kopija filma koja se može iznajmiti Upit (Film) Rezervacije Posuđivanje Rezultat upita (Raspoloživ | Nije raspoloživ | Ne postoji) izračunaj broj kopija traženog filma u videoteci ako je broj kopija veći od nule tada ako je broj kopija veći od (broj posuđivanja + broj rezervacija) rezultat = „Raspoloživ” inače rezultat = „Nije raspoloživ” inače poruka „Ne postoji” Izlazni tokovi: Logika procesa: . ali imaju nekoliko zajedničkih elemenata: naziv i broj procesa.98 Poliščuk E. generisati programski kôd (tabele 5. listu podataka koji izlaze iz procesa (izlazni tokovi podataka). Opis procesa sadrži algoritam zadatka koji se procesom obavlja.2 i 5.3). Mogu poprimiti različite oblike. listu podataka koji ulaze u proces (ulazni tokovi podataka). Elementarni procesi Mini-specifikacije (funkcionalne primitive) se koriste za opisivanje osnovnih procesa u dijagramu toka podataka. koji može poprimiti različite oblike (dizajn programa. 2005]. Mini-specifikacije kreira korisnik CASE alata. kao i tijelo opisa procesa. u zavisnosti od alata. Na osnovu ovog algoritma može se. neosjetljive su na izmjene dijagrama [Fertalj & Kalpić.4. odnosno opis programske logike). Jaroslav: Projektovanje informacionih sistema 5.2. Tabela 5. Budući da se ne kreiraju automatski na osnovu prethodno unesenih opisa (modela procesa i modela podataka). Primjer 1: Definisanje procesa (1).

Reinženjerstvo poslovnih procesa je analiza i restrukturiranje poslovnih procesa radi poboljšanja efikasnosti i uklanjanja birokratije. Proces 1: Opis: Ulazni tokovi: Izlazni tokovi: Logika procesa: Provjera raspoloživosti filma Provjera da li u videoteci postoji kopija filma koja se može iznajmiti Upit (Film) Rezervacije Posuđivanje Film nije raspoloživ. ali i umjesto. Film je raspoloživ. .3.4). tj. Primjer 2: Definisanje procesa (2).1. Ne postoji izračunaj broj kopija traženog filma u videoteci ako je broj kopija veći od nule tada ako je broj kopija veći od (broj posuđivanja + broj rezervacija) rezultat = Film je raspoloživ inače ako član želi rezervisati film tada upiši rezervaciju (izlazni tok Film nije raspoloživ) inače poruka „Ne postoji” 5. Jaroslav: Projektovanje informacionih sistema 99 Tabela 5. ali će takav dijagram biti preopterećen fizikalnim primjesama. Dizajn sistema se bavi fizičkim modelima procesa. Analiza sistema razmatra aplikacione modele procesa.4. Teorijski. Primjena modela procesa Strateško planiranje sistema predstavlja definisanje arhitekture sistema u okviru strateškog plana.Poliščuk E. Izrađuju se dijagrami toka podataka sa fizikalnim primjesama. koje uključuju vremensku dimenziju. dijagramom konteksta određuju se domašaj i interfejs sistema). Identifikuju se poslovna područja i poslovne funkcije. moguće je proizvesti DTP povratnim inženjerstvom postojećih aplikacija. odnosno logičke modele procesa sistema ili aplikacije. Postojeći procesi se analiziraju i dokumentuju prikladnim modelima procesa. prije primjene informacijskih tehnologija. dodavanjem upravljačkih komponenti i resursa. pri čemu se radi model procesa poslovnog sistema (globalni model procesa). protočnost podataka i troškove. izrade dijagrama (tabela 5. najčešće u obliku dijagrama dekompozicije funkcija ili nerazrađenog DTP (npr. Prikupljanje i sređivanje informacija o funkcijama i procesima se može obaviti pomoću tabela prije.

.21. Artikl .. .. ) Dobavljač . Stavka. pa napiši rješenje Dijagram toka podataka (DTP) iz stvarnog projekta prikazan je na slici 5. Zahtjev za prijem (osoba) Ispisana narudžba (dobavljač) . Jaroslav: Projektovanje informacionih sistema Tabela 5. Dobavljač. .100 Proces Ulaz (od) Poliščuk E... Prijem u službu Podaci o dobavljaču. 2005]...21. Izlaz (prema) Vanjski entitet Spremište Komentar/Algoritam Izraditi narudžbu .. Osoba Narudžba. DTP iz stvarnog projekta [Fertalj & Kalpić. Artikli za naručivanje . Osoba.. Slika 5.. Tok službe Struktura tokova ne mora u potpunosti odgovarati strukturi spremišta Provjeri zahtjev prema Pravilniku o zapošljavanju... Rješenje zahtjeva (osoba.4.

Ilustracija dijagrama entiteti-veze. Modeliranje podataka 6. Slika 6. skraćeno DOV. npr.1. Osnovni pojmovi modela podataka 6. Prema mnogim autorima modeliranje podataka je najvažnija tehnika oblikovanja informacionog sistema. (slika 6. Chen. budući da se podaci najčešće pohranjuju u BP. Jaroslav: Projektovanje informacionih sistema 101 6.2.1. Modeli podataka postojećeg i budućeg sistema međusobno su sličniji nego modeli procesa postojećeg i budućeg sistema. modeli podataka su bitno manji od modela procesa. Sinonim je modeliranje baze podataka. koji su i obrađeni u ovoj knjizi. Strukture podataka i njihova svojstva su trajniji i stabilniji od procesa. 6. Pored toga.1). Osim osnovnih modela. Podaci su resurs koji se dijeli između većeg broja procesa i zbog toga moraju biti organizirani na način koji je prilagodljiv poslovnim zahtjevima. koriste se i prošireni modeli. . a i lakše ih je preoblikovati. Modeliranje podataka se završava brže nego modeliranje procesa i modeli podataka se brže približavaju rezultatu nego modeli procesa. Postoje različite notacije ovih dijagrama.1. Dijagram entiteti-veze Dijagram entiteti-veze (Entity-Relationship Diagram (ERD)) se naziva još i dijagram objekti-veze. Martin.1. Ne postoje jednoznačni standardi postupka njihove izrade. Omogućavaju dobru komunikaciju sa korisnicima i lakše utvrđivanje naziva.1. Uvod u modeliranje Modeliranje podataka je tehnika organizovanja i dokumentovanja podataka IS. pa se manje posla “baca”.Poliščuk E.

Student ili Nastavnik. 1989]. Entiteti Entitet (entity) je nešto što postoji u stvarnom svijetu i posjeduje osobine koje ga opisuju i po kojima se razlikuje od svoje okoline. zaposlenje. atributi mogu biti: jednostavni atributi. odnosno atributi koji predstavljaju ponavljajuće grupe podataka. U praksi se može poistovjetiti pojam entitet sa skupom entiteta. poslovni sistem (Hotel Proljeće ili Elektroprivreda). višeznačni atributi. sadašnji ili budući. Jaroslav: Projektovanje informacionih sistema 6. • povezanost različitih objekata stvarnog svijeta. rođenje. . 1989].1. npr. objekat. Osoba.Telefon = (TelefonNaPoslu. roman Zločin i kazna.102 Poliščuk E. engleski jezik ili iskustvo (poznavanje jezika). 1976]. gdje je vrijednost uređena torka ili logička grupa jednostavnih atributa: npr. npr.prošli. Ime. atributi sa više istovrsnih vrijednosti: npr. npr. 1986]. ako se ne razmatraju konkretni podaci. školovanje. se grupišu u: skup entiteta (entity set). Osoba je Kupac i/ili Dobavljač. stanje) . Prezime. Fakultet. npr. (2) bilo koji objekat koji se može razlikovati i predstaviti u bazi podataka [Date. Pojedinačne vrijednosti atributa se pohranjuju u bazu podataka kao elementarni podaci. odnosno značenje entiteta. godina). npr. Pojedinačne pojave (instance). kod kojih je vrijednost pojedinačni podatak: npr. MobilniTelefon). npr. TelefonKodKuce.1.3. Entitet može biti: • • • • • • osoba. Atributi i domeni Atribut predstavlja neko obilježje.4. složeni (sastavljeni) atributi. srodstvo. tj. 6. polje (field). mjesec. penzionisanje. ustanova (ETF). apstraktni pojam. tip entiteta (entity type) i klasu entiteta (entity class). Po vrijednostima koje predstavljaju. (3) logička reprezentacija podatka [Finkelstein. Entiteti mogu poprimiti različite uloge u zavisnosti od konteksta. (4) bilo šta o čemu pohranjujemo informaciju [Martin. npr. Označava se imenicom (u jednini). Ivo Ban. u zavisnosti o metodi. događaj (situacija. Definicije entiteta istaknutih autora su: (1) stvar koja se može zasebno identifikovati [Chen. datum = (dan. Osoba. Sinonimi za atribut su: svojstvo (property).

interval [10-99]) ili skupom konstanti (npr.. character ili konkretni tipovi char. Jaroslav: Projektovanje informacionih sistema 103 Obzirom na uskladištenu vrijednosti. Pol = {M. integer. broj. Netehnički tipovi podataka su opšti tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva (npr.. isto kao i atributi. Domeni su skup mogućih vrijednosti koje. int. Ilustracija atributa i domena dana je na slici 6. Ž}). nad njima definisani atributi. . Uopšteno rečeno. . .. 8746 37528 1164 . Vrijednosti atributa definišu tip podatka (domen) i pretpostavljena ili standardna vrijednost (default). Nad svakim domenom se može definisati po volji mnogo atributa. tekst.Poliščuk E. integer). atributi mogu biti atributi za uskladištenje i izvedeni atributi... Skup vrijednosti (domen) se može definisati: tipom podatka (npr.. Ford Karson Rock . mogu poprimiti... formula CC66.2. datum-vrijeme. dok su tehnički tipovi podataka generički tipovi podataka koji se mogu preslikati u konkretne tipove (npr. Standardna vrijednost atributa je vrijednost koja se zapisuje kada je korisnik ne specificira. gdje im se vrijednost može odrediti na osnovu vrijednosti drugih atributa: starost = (DanašnjiDatum−DatumRođenja). Tipovi podataka mogu biti netehnički (logički) ili tehnički. BLOB (Binary Large OBject)). znakovni niz..... većina atributa treba da ima standardnu vrijednost. . byte (iz sastava SUBP „SQLserver”)). Ilustracija atributa i domena. 038 001 282 Slika 6. Domeni mogu biti jednostavni i složeni. Alan Bob Kit ··· Melrose place xx Sunset boulevard 2958 Vancouver avenue 63 … Identifikator Osobe (IdOsobe) Prezime (Prezime) Ime (Ime) Adresa (Adresa) Šifra mjesta (SifMjesta) 8746 37528 1164 765 Karson Ford Rock Ford Kit Alan Bob Kit Melrose place 666 Vancouver avenue 63 Sunset boulevard 2958 .2. podskupom vrijednosti tipa podatka (npr.

@) je atribut ili skup atributa koji (svojim vrijednostima) jednoznačno identifikuju svaki od entiteta u nekom skupu entiteta. raspoloživost (dostupnost svim korisnicima). Ključevi Ključ (key) ili identifikator (Id. Entitet može imati jedan ili više ključeva. MJESTO = @ŠifraDržave +@ŠifraMjesta.. Povezivanje entiteta ili skupova entiteta stranim ključem. 038 001 282 Šifra mjesta (SifMjesta) 038 Poštanski broj (PostBr) Naziv mjesta (NazMjesta) 001 282 10000 20000 30000 Roma New York Los Angeles Slika 6.5. loš primjer: OSOBA = @JMBG + @Prezime + . sastavljeni.. takođe... dobar primjer: KURS = @OznakaValute + @DatumKursa + . a može se sastojati od više atributa (složeni.3. Mora se sastojati od bar jednog atributa (jednostavni ključ): npr. Ključ mora zadovoljavati uslove jednoznačnosti i minimalnosti. jednoznačan (npr. kandidata za primarni ključ. Jaroslav: Projektovanje informacionih sistema 6.. ulančani ključ): npr. ). MJESTO = @ŠifraMjesta + NazivMjesta.. tj.... OSOBA = @JMBG + Prezime + Ime.104 Poliščuk E. Entitet mora imati barem jedan ključ. . neutralnost (obzirom na značenje vrijednosti ključa). Osim navedenih uslova. . ključ mora zadovoljiti i slijedeće uslove: određenost (postojanje vrijednosti u trenutku stvaranja instance). Entitet može imati više mogućih ključeva. . stabilnost (otpornost na promjene tokom vremena). Identifikator Osobe (IdOsobe) Prezime (Prezime) Ime (Ime) Adresa (Adresa) Šifra mjesta (SifMjesta) 8746 37528 1164 765 Karson Ford Rock Ford Kit Alan Bob Kit Melrose place 666 Vancouver avenue 63 Sunset boulevard 2958 . dok minimalnost znači da ne postoji podskup atributa ključa koji je. ne smiju postojati 2 osobe sa JMBG=2209964100028).. Jednoznačnost se definiše na slijedeći način: u skupu entiteta ne smiju postojati dvije pojave sa istim vrijednostima svih ključnih atributa (npr. koji ne moraju . ...1.

pojam veza podrazumijeva skup veza. Vozilo (tipa putnički automobil) nepoznatog registarskog broja. odnosno skupova entiteta (slika 6.). tj. Nakon odabira primarnog ključa. Nula-vrijednost označava nepoznatu vrijednost atributa ili neodređenu vrijednost atributa.JMBG.Poliščuk E.SifMjesta. Strani ključ ukazuje na povezanost između entiteta.PostBr. tj. referensira entitet Mjesto sa IdMjesta=038. Jedan od ključeva se odabira za primarni ključ (primary key): npr. Analogno entitetima. tj. Veze Veza (relationship) pokazuje odnos između entiteta. pa joj je SifMjesta neodređena (nepoznata) vrijednost. Može poprimiti vrijednost primarnog ključa drugog entiteta ili nula-vrijednost (null value).SifMjesta). a imenuje se glagolom ili glagolskom imenicom. Primjer: • Osoba. Mjesto. Osoba. Mjesto. Veza može izražavati ulogu entiteta koje povezuje. Primjer: Veza i uloge: • Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta). Primjer: Moguće nula-vrijednosti: • • Osoba (IdOsobe=37528) boravi u nepoznatom mjestu.IdOsobe. skup atributa čije se vrijednosti odnose na vrijednosti ključa drugog entiteta (Osoba. • u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA Osobe).1. nadomješta vrijednost atributa koji se ne koristi.3. ostali mogući ključevi postaju alternativni ključevi (alternate key (AK)): npr. . Kada se ne razmatraju instance.SifMjesta odnosi se na Mjesto. a veze se grupišu u skupove veza (relationship sets). Strani ključ (foreign key (FK)) je skup atributa koji se odnosi na ključ drugog skupa entiteta.SifMjesta. Osoba. nasuptot vozila (tipa buldožer) koje se ne registruje na isti način (neprimjenljiva vrijednost). Jaroslav: Projektovanje informacionih sistema 105 biti međusobno disjunktivni.SifMjesta odnosi se na Mjesto.6. pojedinačna veza uspostavlja se na nivou instanci entiteta. Nula-vrijednost nije 0 (nula) niti “” (prazan znakovni niz). mogu imati atribute presjeka. odnosno • Entitet Osoba (IdOsobe=8746) ima SifMjesta=038. 6. tj.

Ne mora postojati nijedna instanca sa druge strane veze. obavezno pridruživanje. Kada je donja granica jednaka nuli postoji djelomično. stepena. To je veza prvog stepena: unarna veza (refleksivna. Mora postojati barem neki broj ili općenito M instanci sa druge strane veze. Jaroslav: Projektovanje informacionih sistema Mjesto MjestoStan Stanuje Stanovnik Osoba Slika 6. uopšte. klasifikacija veze (type of relationship) označava način pridruživanja pojava entiteta u vezi: • jedan-prema-jedan (1:1).1 Mjesto Stanuje 0. neobavezno pridruživanje. tj. dok je. Primjer: Binarna veza 1:N. Uopšteno. pozitivni cijeli broj ili znak (npr. Veze su dvosmjerne pa se kardinalnost definiša za oba smjera veze. Posebni slučaj je veza nekog entiteta sa tim istim entitetom. 1. involucijska). Gornja granica može biti 1.N Osoba . Tip. rekurzivna. može se povezati bilo koji broj entiteta (pri čemu treba biti oprezan!). Tako veza drugog stepena je binarna veza. veza n-tog stepena: n-arna veza. Može imati konkretan broj ili općenito N instanci sa druge strane veze.106 Poliščuk E. • jedan-prema-više (1:N) . Kada je donja granica različita od nule postoji potpuno. pozitivni cijeli broj ili znak (npr. • više-prema-više (M:N).može postojati više (paralelnih) veza između dva entiteta. Primjer veze i uloga. M). Kardinalnost veze (donja i gornja granica kardinalnosti) je minimalni i maksimalni broj pojava jednog entiteta za pojedinačnu pojavu sa njim povezanog entiteta. U nekim metodama se smatra posebnim slučajem binarne veze. Donja granica može biti 0. Stepen veze je broj entiteta koji sudjeluju u vezi. 1. posebnom vezom 2. N).4. veza trećeg stepena je ternarna veza.

Zanimanje 1.N 0.N OrgJed Primjer: Unarna veza 1:N i unarna veza M:N. Ova veza opisuje posebne slučajeve u nekom skupu entiteta.1.N Proizvod Proizvodi Slika 6.1 Pripada PodJed 0. 0. Jaroslav: Projektovanje informacionih sistema 107 Primjer: Binarna veza M:N. Primjer: Ternarna veza.5.M 0.N Osoba 1.7. Primjer ternarne veze i unarnih veza 1:N i M:N. Primjeri binarnih veza 1:N i M:N. to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip).6. Podređeni entiteti stvaraju se na osnovu njima nadređenog entiteta sa kojim dijele zajedničke atribute: .N Proizvod Dio 0. OrgJed 0. 6.M Sastav NadJed OrgJed Cjelina Slika 6. Specijalizacija/generalizacija Specijalizacija/generalizacija se zove i "je" veza (“is a” relationship).Poliščuk E.N Zaposlen 1.

StavkaRacuna. Neekskluzivna i ekskluzivna specijalizacija. Osoba je ponekad Radnik (Saradnik). entitet sa stranim ključem (npr. Primjeri: 1. npr. Osoba). vlastitog atributa (deskriptora). Egzistencijalno zavisan entitet nije ujedno i identifikaciono zavisan. Radnik. Proizvod je ponekad Igla (Avion). ali ne može istovremeno biti Igla i Avion). Osoba Proizvod 11 0. . npr. nezavisan/dominantan entitet.1 Igla ES 0.1.7. Jaki i slabi entiteti Jaki entitet je entitet koji postoji (egzistira) samostalno. Specijalizacija može biti neekskluzivna (npr. Saradnik. • podtip (subtype) . Igla je uvijek Proizvod.1 Radnik NS 0. Mjesto. Egzistencijalno slabi entitet je entitet koji ne postoji samostalno.sadrži samo njemu svojstvene atribute i predstavlja specijalizaciju nadređenog entiteta. Slabi entitet postoji samo ako postoji jaki entitet u vezi. Identifikaciono slabi entitet je entitet koji se ne identifikuje samostalno.N Saradnik 0.1 Avion Slika 6. Identifikaciono zavisan entitet je ujedno i egzistencijalno zavisan. A je ponekad B. ali u isto vrijeme može biti i Radnik i Saradnik) ili ekskluzivna (Proizvod je Igla ili Avion.108 Poliščuk E. prema potrebi.sadrži zajedničke atribute i predstavlja generalizaciju podređenih entiteta. B je podtip od A ako: B je uvijek A. Jaroslav: Projektovanje informacionih sistema • nadtip (supertype) . 2. Osoba je Radnik ili Saradnik. entitet koji nema vlastiti ključ nego se njegov ključ sastoji od ključa jakog entiteta i. predstavlja zavisan/podređen entitet.8. 6. Radnik je uvijek Osoba. 3.

N Proizvodi 0.9.1 Zanimanje 1.N 1.N StavkaRacuna Slika 6. Racun 1.1 Osoba Primjer: Identifikaciona veza i identifikacioni slab entitet.N 0. Mjesto 1.N StavkaRačuna ES Radnik Saradnik 0.1 0. 1.N 0.1 RacStRac 1. Primjeri slabih entiteta.N 0.N Zaposlen OrgJed 0.1 NadJed Pripada 0.Poliščuk E. Primjer dijagrama entitet–veze jednog preduzeća (prema Chen-u).1 NS 0. ERD notacije Najviše je u upotrebi Chen-ova i Martin-ova notacija dijagrama entitet–veze (ERD).1 PodJed 1.1 RačStRač OdnosiSeNa 0.9 i 6.N Cjelina 1. Chen-ova notacija: Mjesto 1.1 Proizvod 1. . slike 6.1 0. 6. Jaroslav: Projektovanje informacionih sistema 109 Primjer: Egzistencijalno slab entitet Osoba.M Sastav Dio 0.N Stanuj Osoba 1.1 Račun 1.1 0.9.1.10.M 1.N Igla Avion Slika 6.N 1.1 Stanuje 0.8.

Jaroslav: Projektovanje informacionih sistema Zanimanje Pripada Stanuje Osoba Zaposlen OrgJed Sastav Proizvod Račun Radnik Saradnik Stavka računa Igla Avion Slika 6. .10. Tekst izjave korisnika za izradu dijagrama entiteti–veze za hemijsku laboratoriju može da glasi: "Hemičar ili član osoblja hemijske laboratorije može podnijeti zahtjev za jednom ili više hemikalija. mora pratiti istorijat svakog pakovanja hemikalija od trenutka kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen". Zahtjev može biti udovoljen ili dostavom pakovanja hemikalije koja se već nalazila na zalihi hemijske laboratorije ili upućivanjem narudžbe za novim pakovanjem hemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Izrada ERD analizom izjava korisnika Dijagrama entitet–veze (ERD) može biti izrađen na osnovu izjava korisnika. Mjesto Poliščuk E. 6.10. Takođe.110 2. Primjer dijagrama entitet–veze jednog preduzeća (prema Martin-u).1. Martin-ova notacija.

1. model podataka sa definisanim ključevima (key-based data model). model konteksta podataka (context data model). model podataka sa .2. Primjer dijagrama entiteti–veze za hemijsku laboratoriju [Fertalj & Kalpić.11. 2005]. Jaroslav: Projektovanje informacionih sistema 111 M zahtjeva Inventar hemijske laboratorije 1 pohranjuje M M ispunjava 1 Zahtjev za hemikalijom M 1 popisuje Zahtjevač M M 1 M Pakovanje hemikalija 1 prati 1 sadrži Hemikalija opisuje M Istorija pakovanja hemikalija Dobavljačev katalog Slika 6.Poliščuk E. Uvod u razvoj modela podataka Može da se razvija jedan od slijedećih modela podataka: globalni model podataka (enterprise data model). 6. Razvoj modela podataka 6.2.

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

potpuno određenim atributima (fully attributed data model) i potpuno opisani model podataka (fully described data model). Kategorije entiteta, koji ulaze u sastav modela podataka, su slijedeće: osnovni (fundamentalni, jaki entiteti), koji ne spadaju u ostale kategorije (npr. Mjesto), asocijativni (spojni, vezni), koji proizlaze iz asocijativnih veza (npr. Zaposlenje), atributivni, koji opisuju ili kategoriziraju druge entitete (npr. Zanimanje, Stanje) i podtipovi – specijalizacije (npr. Radnik, Saradnik, Igla, Avion).

6.2.2. Konceptualni model podataka
Globalni model podataka (npr. model podataka poslovnog sistema) se izrađuje u fazi planiranja. Dobijeni konceptualni model entiteti-veze, koji najčešće sadrži neodređene veze i nerazrađene kategorije podataka, može da ne sadrži pojedine veze. Definiše se mogući domet sistema, kao i ukupne informacione potrebe. Model konteksta podataka se izrađuje na početku analize. Konceptualni model, koji sadrži samo one entitete koji će biti obuhvaćeni tehničkim rješenjem, predstavlja aplikativni model podataka. Takav model usklađuje doseg bez detalja o entitetima ili detalja o poslovnim pravilima. ERD sa entitetima i vezama (često nespecifičnim), bez atributa ili samo sa osnovnim atributima, sadrži: obične veze, tj. veze tipa 1:N, npr. "račun ima više stavki" ili veze višeg stepena, npr. “zaposlenje osobe u organizacionoj jedinici na radnom mjestu”, odnosno Zaposlen. Preporuka je da se izbjegavaju entiteti koji se odnose na specifični kontekst ili ulogu. Za konceptualno modeliranje podataka se koristi tehnika dijagrama entiteti-veze (ERD). Na slici 6.12 je prikazana ekranska forma, sa izvodom iz jednog dijagrama ERD, CASE alata Entity Relationship Diagramer (Designer 2000, ORACLE), koji ovu tehniku podržava. Koncepti tehnike ERD, koji su neposredno ili posredno povezani ovim alatom, su: tip entiteta, slabi tip entiteta, tip veze, kardinalnost tipa veze, atribut tipa entiteta, domen, ključ tipa entiteta, veza „is a” i kategorizacija (koja se ovdje predstavlja ekskluzivnim tipom veze). ERD se oblikuju tako što se novi tipovi entiteta i tipovi veza neposredno kreiraju u okviru izabranog aplikativnog sistema, dok se prethodno kreirani tipovi entiteta i tipovi veza, po potrebi, preuzimaju iz rječnika podataka, bilo da pripadaju izabranom ili nekom drugom aplikativnom sistemu. Na ovaj način se obezbjeđuje mehanizam za oblikovanje jedinstvene konceptualne sheme BP informacionog sistema.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

Slika 6.12. Ekranska forma, sa izvodom iz jednog dijagrama ERD, CASE alata Entity Relationship Diagramer (Designer 2000, ORACLE). Notacija za prikaz ERD-a u Entity Relationship Diagramer-u se razlikuje od prethodno navedene notacije. Najbitnija razlika je u tome da se tipovi veze ovdje ne prikazuju simbolima za romb i linijama, već samo pomoću jedne linije koja povezuje dva tipa entiteta. Ta linija može biti puna, isprekidana ili djelimično isprekidana i na sebi imati dodatne oznake u zavisnosti od parametara tipa veze. Pored opštih pravila za tumačenje prikazanog ERD-a, koja se mogu naći u literaturi o BP, potrebno je naglasiti da simbol: • • • "#" uz atribut (obilježje) označava da je riječ o atributu koje je u sastavu primarnog ključa tipa entiteta, "*" uz atribut označava da je riječ o atributu koji je obavezan za unos, odnosno korespondira ograničenju Null(N, A) = ⊥, "o" uz atribut označava da je riječ o atributu koji nije obavezan za unos, odnosno korespondira ograničenju Null(N, A) = T,

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

"|" na tipu veze označava da je tip entiteta na strani gdje se nalazi simbol "|" identifikaciono zavisan od tipa entiteta na drugoj strani, što znači da će u sastav primarnog ključa takvog tipa entiteta ući i svi atributi primarnog ključa tipa entiteta na drugoj strani posmatranog tipa veze, a " " na tipu veze označava da se pojave tipa entiteta na strani gdje se nalazi simbol " " ne mogu "prevezivati" za druge pojave tipa entiteta na drugoj strani.

6.2.3. Logički modeli podataka
Model sa definisanim ključevima entiteta ne sadrži neodređene veze. One su nadomještene asocijativnim entitetima. Vrši se određivanje ključeva (primarnih, alternativnih, stranih). Ako se primarni ključ (PK) ne može odrediti, možda se ne radi o skupu entiteta. Određivanje kardinalnosti veza se vrši odgovaranjem na pitanja oblika: “mora/ može”: “ni jedan” (0), “barem jedan” (1), “više” (N), odnosno donja/gornja granica kardinalnosti. Primjeri: 1. Koliko stavki računa mora/može imati račun? – odgovor je: 1 (donja granica kardinalnosti), N (gornja granica kardinalnosti); 2. Koliko se osoba mora/može nalaziti u mjestu? – odgovor je: 0 (donja granica kardinalnosti), N (gornja granica kardinalnosti). Definisanje generalizacionih hijerarhija (određivanje specijalizacija, tj. podtipova entiteta), npr. Igla i Avion, vrši se definisanjem klasifikacionog atributa nadtipa (diskriminator podtipa), npr. Proizvod.TipProizvoda ∈ {“Igla”, “Avion”}. Model sa definisanim atributima entiteta se dobija dodavanjem preostalih opisnih atributa, određivanjem podskupova podataka, definisanjem domena, logičkih tipova podataka i standardnih vrijednosti atributa (slika 6.13).

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

Slika 6.13. Primjer modela podataka sa definisanim atributima entiteta i ključevima entiteta (konceptualna shema).

6.2.4. Dokumentovanje i konverzija modela entiteti-veze
Potpuno opisani model podataka je ostvaren kada raspolaže sa putpunim opisom atributa, logičkih tipova podataka i standardnih vrijednosti. Dodatni opisi su prava pristupa podacima i trajnost podataka (arhiviranje). Dobijanje potpuno opisanog modela vremenski je najzahtjevniji zadatak. Uobičajeno se provodi na kraju, ali može započeti uporedno sa izradom modela zasnovanog na ključevima ili definisanjem opisnih atributa. Dalja konverzija modela se sastoji u prevođenju modela entiteti-veze u relacioni model podataka. Faza dizajna, odnosno fizičko oblikovanje podataka, se sastoji od konverzije logičkog u fizički model (izrada sheme baze podataka), kao i od normalizacije i prilagođavanja uslijed tehničkih ograničenja i performansi.

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

6.2.5. Definisanje koncepata modela podataka
Definisanje entiteta podrazumjeva dodjeljivanje jedinstvenih naziva i izradu opisa entiteta, odnosno definisanje značenja i namjene entiteta, poslovnih zahtjeva i ograničenja. Treba koristiti kratki naziv (kôd), koji je često potreban zbog ograničenja alata ili programskog jezika. Izbjegavati skraćenice zbog moguće pojave akronima. Atributi ključeva i opisni atributi su važni za razumijevanje suštine modela. Voditi računa o tragu zahtjeva, odnosno porijeklu i primjeni entiteta. Potrebno je definisati ovlaštenja nad meta-podacima i odgovornost za podatke. Definisanje veza se sastoji u određivanju jedinstvenog naziva, koji se sastoji od glagola, odnosno glagolske imenice (npr.Roditelj-Dijete). Takođe je potrebno definisati: značenje veze (sastavni dio dokumentacije), tip veze (identifikaciona ili neidentifikaciona veza), modalitet i kardinalnost, ključeve, diskriminator generalizacije /specijalizacije, kao i pravila za očuvanje integriteta pri unosu i brisanju instanci. Određivanje ključeva se sastoji u određivanju ključa jakog entiteta (identifikacioni atribut) i ključa identifikaciono slabog entiteta (ključ jakog entiteta i vlastiti atribut). Potrebno je obratiti pažnju na ključeve sastavljene od više atributa, kao i na atribute ključa koji su ujedno ključevi drugih entiteta. Odrediti moguće zamjenitelje ključeva. Kod stranih ključeva obratiti pažnju na moguću migraciju primarnog u strani ključ. Treba ukloniti neodređenosti stranih atributa. Definisanje atributa podrazumjeva da naziv atributa mora biti jedinstven, sa izuzetkom stranih ključeva. Treba povesti računa o značenju atributa, domenu atributa i kardinalnosti atributa. Atributi mogu biti izvedeni atributi (iz različitih instanci) i izračunati atributi (jedne instance).

6.3. Logičko modeliranje podataka
6.3.1. Prevođenje modela E-V u relacioni model
Osnovni koncepti koji se javljaju u modelu entiteti – veze (E–V) su: entiteti, atributi, ključevi i veze. U narednom tekstu je predstavljeno parcijalno prevođenje modela E-V u relacioni model. Entiteti (skup entiteta) se predstavljaju relacijama (tabelama). Stanovnici Mjesta XX su Osobe XXX (relacije: Mjesto, Osoba).

slika 6.1 0. npr. kardinalnost 1 .zahtijevana vrijednost (not null) i kardinalnost N višeznačni atribut (npr. Osoba. mjesec. Osoba.Prezime.Telefon: Telefon (IdOsobe.14.15.N Telefon Telefon VrstaTelefona BrojTelefona Slika 6.Poliščuk E. VrstaTelefona. godina) dobija se atribut Datum (slika 6. Jaroslav: Projektovanje informacionih sistema 117 Atributi mogu imati slijedeće kardinalnosti preslikavanja: kardinalnost 0 .Telefon). grupisanjem (dan. Atributi skupa entiteta Osoba. npr.opciona vrijednost (null).Staz.TelefonNaPoslu. Osoba.Telefon: Osoba.MobilniTelefon ili prikazano kao slabi entitet. . BrojTelefona). dok je složeni atribut dobijen grupisanjem. npr. npr. Osoba.TelefonKodKuce.15. Osoba IdOsobe Prezime Ime TelefonNaPoslu TelefonKodKuce MobilniTelefon Adresa DatRodj Staz Osoba 1. Atribut Prezime entiteta Osoba se predstavlja sa Osoba. Osoba. Osoba IdOsobe Prezime Ime Adresa DatRodj Staz Slika 6. Osoba.14). Višeznačni atribut je skup odgovarajućih atributa. Primjeri višeznačnih atributa. Izvedeni atribut je atribut koji se pamti ili se izostavlja.

IdOsobe.SifMjesta ili alternativni (AK). Jaroslav: Projektovanje informacionih sistema Ključevi mogu biti primarni.16.17. npr.SifNadJed) <FK2> i RacunOsoba (Racun. OsobaSKljucem IdOsobe Prezime Ime Adresa DatRodj Staz Mjesto SifMjesta PostBr <AK> NazMjesta Slika 6. Mjesto. npr.IdOsobe) <FK3>. Primjeri stranog ključa <FK>.16).PostBr (slika 6.118 Poliščuk E. Na slici 6. Primjeri primarnog i alternativnog ključa <AK>. koga sačinjava indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null). . Mjesto SifMjesta PostBr <AK> NazMjesta Osoba IdOsobe Prezime Ime SifMjesta <FK1> Adresa DatRodj Staz OrgJed SifOrgJed NazOrgJed SifNadJed <FK2> Osoba IdOsobe Prezime Ime SifMjesta <FK1> Adresa DatRodj Staz Racun BrRac DatRac IdOsobe <FK3> IznosRac Slika 6. Veza može biti binarna veza 1:N sa stranim ključem. Pripada (OrgJed.SifMjesta) <FK1>. Mjesto. Osoba.17 su prikazane binarne veze egzistencijalno slabog entiteta sa običnim stranim ključem i to: Stanuje (Osoba.

SlikaOsobe (IdOsobe. StavkaRacuna (BrRacuna. Osoba (IdOsobe. slika 6. Staz.1 sa stranim ključem transformiše se u identifikaciono slabi entitet bez deskriptora: npr.N OrgJed Proizvodi Proizvod Zanimanje SifZan NazZan Zanimanje 1. TekstKom).19. .1:0.18. TekstKom). Slika). Jaroslav: Projektovanje informacionih sistema 119 Identifikaciono slabi entitet naslijeđuje ključ jakog entiteta. 0.M 0. Taj ključ može biti spojni ključ. … . StavkaRacuna (BrRacuna.N Zaposlen 1. Prezime. Racun BrRac DatRac IdOsobe <FK> IznosRac StavkaRacuna BrRacuna <FK1> SifProizvoda <FK2> JedCijena Kolicina Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda StavkaRacuna BrRacuna <FK1> RbrStRac SifProizvoda <FK2> JedCijena Kolicina Slika 6.N Osoba 1. Primjeri složenog ključa.1) u jednu relaciju: Osoba (IdOsobe. JedCijena. Komentar (IdOsobe. SifProizvoda.1 (1.Poliščuk E. Kolicina) ili kompozitni ključ.18.1:1. npr. Prezime.M Cjelina Sastav SifProizvod<FK1> SifDjela <FK2> BrDjelova BrDjelova Proizvodi SifOrgJed <FK1> SifProizvod<FK2> Proizvod Dio Sastav Slika 6. Binarna veza 1. Staz). Po potrebi se može razmotriti udruživanje entiteta u binarnoj vezi 1. JedCijena. Staz). Prezime. Primjer ključeva asocijativnog entiteta. SifProizvoda. … .N OrgJed Osoba IdOsobe Prezime SifMjesta <FK> Adresa DatRodj Staz Zaposlen IdOsobe <FK1> SifOrgJed <FK2> SifZanim <FK3> DatPoc DatZav KoefPlate Proizvod SifProizvoda NazProizvoda JedCjena TipProizvoda OrgJed SifOrgJed NazOrgJed SifNadJed <FK1> DatPoc DatZav 0. Osoba (IdOsobe. … . RbrStRac.1:0. npr. Kolicina).

13. generiše prvu verziju relacione sheme BP. Nakon postupka prevođenja konceptualne sheme BP. nalaziti u rječniku. Specijalizacija nadtipa u n podtipova (n binarnih veza) u kojoj je nadtip (jaki) entitet. Jaroslav: Projektovanje informacionih sistema Nespecifične veze se sastoje od asocijativnog entiteta + n binarnih veza 1:N. Zaposlen. u relacioni model podataka i izvršene normalizacije.1 0. 6. Ovaj alat na osnovu konceptualne sheme BP. Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda Proizvod 1. sa slike 6. npr. zajedno sa izvodom iz jednog dijagrama relacione sheme. Implementaciono projektovanje sheme BP pomoću CASE alata Implementaciono projektovanje sheme baze podataka započinje prevođenjem ERD konceptualne sheme BP u relacioni model. slika 6. opisane u rječniku podataka. npr.TipProizvoda i podtip (identifikaciono) slabi entitet.1 ES 0.20). Izgled korisničkog interfejsa za Design Editor/Server Model. Proizvod. Design Editor (Designer 2000. Za ovo prevođenje se može koristiti odgovarajući CASE alat. dok linije predstavljaju puteve prostiranja primarnog ključa. kome se po potrebi određuje klasifikacioni atribut. . čiji opis će se. Ključ asocijativnog entiteta je unija ključeva entiteta spojenih vezom (slika 6.120 Poliščuk E.19).1 Igla Avion Igla SifProizvoda <FK> Duzina Promjer Avion SifProizvoda <FK> BrSjedista DoletKM Slika 6.20. dobija se implementaciona shema BP. npr. Primjer: Proizvodi. Avion (slika 6. Svaki pravougaonik na shemi predstavlja jednu relaciju (tabelu) BP. je prikazan na slici 6.22. npr. ORACLE). takođe.3. Database Design Transformer (Designer 2000. Igla. Primjer specijalizacije nadtipa u n podtipova. ORACLE). Sastav. Tako integrisana relaciona shema se dorađuje odgovarajućim editorom. odnosno ograničenja stranog ključa.2.21.

se mogu oblikovati odgovarajućim CASE alatom.21. takođe. grafikonski prikaz podataka ili bibliotečkog modula. npr. ORACLE). Programska specifikacija modula za interaktivni rad sa bazom podataka.7. sa mogućnošću prenosa podataka između modula. Na osnovu implementacione sheme BP se automatski generiše ORACLE/SQL (ili ANSI/SQL) opis sheme BP. Pomoću istog alata se formira struktura ekranskih formi aplikacije i obezbjeđuje međusobno povezivanje programskih modula. . šta je detaljnije opisano u tački 10.23.Poliščuk E. Dijagram implementacione sheme aplikacije Komercijalni poslovi. slika 6. Design Editor/Modules (Designer 2000. koji treba implementirati na odgovarajućem serveru BP. Jaroslav: Projektovanje informacionih sistema 121 Slika 6. kao osnova za modeliranje programske specifikacije modula i samo generisanje programskih modula. Implementaciona shema služi. kreiranje izvještaja.

122 Poliščuk E. . Ekranska forma CASE alata Design Editor/Modules (Designer 2000. Jaroslav: Projektovanje informacionih sistema Slika 6. ORACLE). Slika 6. ORACLE).23.22. Ekranska forma CASE alata Design Editor/Server Model (Designer 2000.

5. učestalost (ulazni upravljački tokovi). npr. npr. Izrada dijagrama konteksta sistema. zahtjev za upis studenta ili zaprimanje narudžbe kupca.Poliščuk E. itd. Primjer: Kupac dostavom narudžbe pokreće proces provjere da li se radi o narudžbi postojećeg ili novog kupca. Modeliranje procesa vođeno događajima Događaj je zgoda ili zbivanje u sistemu koja vodi ili pokreće procese sistema. 6. Elementi popisa su događaj. Izrada dijagrama funkcionalne dekompozicije. Unutrašnji događaji su događaji stanja. Izrada dijagrama dekompozicije događaja.1. postavljanje početnog dometa projekta. dodavanje procesa za rukovanje događajima. Vremenski događaji su vremenski uslovljeni. Izrada dijagrama događaja. zaključivanje ispitnog roka i slično. Izrađuje se po jedan dijagram za svaki događaj. provjeru prethodnih zaduženja kupca. nego okidač procesa koji se njime pokreće. koji zahtijevaju informaciju ili ažuriranje podataka (ulazni tokovi podataka). isporuka robe sa skladišta zahtijeva naručivanje nove robe. odnosno razrada procesa za obradu događaja. utvrđivanje poslovnih događaja na koje sistem mora odgovoriti. npr. 4. odnosno udruživanjem dijagrama događaja. Imenuje se tako da naziv sadrži naziv vanjskog entiteta. Imenuju se tako da naziv sadrži vremensku oznaku. odnosno posljedica prelaza sistema iz jednog stanja u drugo na takav način da to zahtjeva obradu (ulazni upravljački tokovi). istek roka plaćanja računa. ulaz i izlaz. Modeliranje događaja 7. provjeru stanja skladišta. 3. spremišta i tokove za svaki pojedini događaj. Razrada dijagramom toka podataka koji sadrži osnovne procese.1. Izrada dijagrama sistema. Jaroslav: Projektovanje informacionih sistema 123 7. rok. Izrada primitivnih dijagrama. Opšti prikaz dijagrama sistema izrađen modeliranjem procesa vođenim događajima prikazan je na slici 7. Vanjski događaji se pokreću od strane vanjskih entiteta. Dodaje se po jedan proces za svaki utvrđeni događaj. vremenski i unutrašnji. podjela sistema u logičke podsisteme i/ili funkcije. 2. . mjesečni obračun plata. Raspodjela događaja vezanih za projektovanje IS: 1. Događaj može biti vanjski. npr. 7. Sâm događaj nije proces. proces stvaranja podataka o narudžbi i stavkama narudžbe. Izrada popisa događaja i odziva.

Matrica entiteti/događaji (Entity/Event Matrix) Matrica entiteti/događaji omogućava pogled na sistem usmjeren događajima.2. .R (read) (u nekim metodama se ne bilježi). a svaki entitet mora imati događaj koji ga stvara i briše. ažuriranje .D (elete). Završetak je kada se ostvari da svaki događaj ima učinak na barem jedan entitet. 7. Matrica sadrži događaje (redovi) i entitete (stupci).U (update) ili M (odify). Primjer modeliranja procesa vođeno događajima. Elementi koji prikazuju učinak događaja na entitete su: • • • • stvaranje – C (reate).124 Poliščuk E. čitanje . Jaroslav: Projektovanje informacionih sistema Sistem Sistem Funkcija 1 Funkcija n Događaj n-2 Događaj n-1 Događaj n Funkcija 2 Događaj 1 Događaj 2 Događaj 3 Događaj 4 Događaj 5 Događaj 1 Događaj 5 Događaj n Slika 7.1. brisanje .

Jaroslav: Projektovanje informacionih sistema 125 Pojednostavnjeni primjer matrice događaj/entitet za rezervaciju sobe u hotelu Proljeće. Primjer matrice događaj/entitet.1. ORACLE. Generisanje matrica CASE alatima Generisanje matrica CASE alatima biće ilustrovano kreiranjem matrica Funkcije/Tipovi entiteta i Funkcije/ Atributi pomoću Matrix Diagrammer-a iz sastava Designer-a 2000. Slika 7.2. 7.Poliščuk E.3. Matrica Elementarne funkcije/Tipovi entiteta.2. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije. prikazan je na slici 7. Slika 7. .2.

126 Poliščuk E.4. Retrieve (R). sa značenjem da je zadatak funkcije formiranje nove pojave posmatranog tipa entiteta. . Archive (A). Slike 7.3 je prikazana matrica Elementarne funkcije/Tipovi entiteta za aplikaciju Komercijalni poslovi. sa značenjem da funkcija ima zadatke koji prethodnim načinima upotrebe nisu pokriveni. sa značenjem da je zadatak funkcije da posebnim postupcima arhivira pojave tipa entiteta. sa značenjem da je zadatak funkcije modifikacija podataka o postojećim pojavama tipa entiteta. kod matrice Funkcije/Tipovi entiteta. a na slikama 7. i Other (O). sa značenjem da je zadatak funkcije brisanje pojave tipa entiteta. Delete (D). Jaroslav: Projektovanje informacionih sistema Na slici 7. mogu biti: • • • • • • Create (C). Matrica Elementarne funkcije/Atributi za tip entiteta KUPAC. Update (U). .4 do 7.6 su prikazane matrice Elementarne funkcije/Atributi. za tipove entiteta KUPAC. Načini upotrebe tipa entiteta u zavisnosti od funkcije. sa značenjem da je zadatak funkcije preuzimanje podataka o postojećim pojavama tipa entiteta. SKLADISTE i ROBA za istu aplikaciju.

. mogu biti: • • Insert (I). sa značenjem da je zadatak funkcije da prvi put zadaje vrijednost atributa tipa entiteta. Matrice Elementarne funkcije/Atributi za tip entiteta ROBA. Retrieve (R). Slike 7.5. sa značenjem da je zadatak funkcije preuzimanje postojeće vrijednost atributa tipa entiteta.Poliščuk E. Načini upotrebe atributa tipova entiteta u zavisnosti od funkcije. Matrica Elementarne funkcije/Atributi za tip entiteta SKLADISTE. kod matrice Funkcije /Atributi. Jaroslav: Projektovanje informacionih sistema 127 Slike 7.6.

Model istorije života entiteta (Entity Life History) Istorijat života entiteta je pogled na sistem usmjeren učincima događaja koji uzrokuju promjene stanja.sa značenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta. . Archive (A). u odnosu na vrijednosti atributa tipa entiteta. za opšti slučaj je prikazan na slici 7. blok redoslijedni redoslijedni događaj događaj (sekvenca) (sekvenca) Ο alternativni događaj (selekcija) operacije ponovljeni događaj (iteracija) n o ∗ m Slika 7. a za rezervaciju sobe u hotelu Proljeće na slici 7. sa značenjem da je zadatak funkcije omogućavanje zadavanja nula vrijednosti za atribut tipa entiteta. zadatke koji prethodnim načinima upotrebe nisu pokriveni.8.7. koji prethodno nije imao nula vrijednost. 7. sa značenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta.3. i Other (O).128 • • • • Poliščuk E. Nullify (N). odnosno prati promjene ponašanja entiteta koji prolazi kroz sistem.7. Jaroslav: Projektovanje informacionih sistema Update (U). Dijagram podudarnosti učinka (Effect Correspondence Diagram – ECD). Opisuje vremenski zavisno ponašanje (jednog) entiteta. Dijagram podudarnosti učinka za opšti slučaj. sa značenjem da funkcija ima. entitet.

Osloboditi sobu 7. Zauzeti sobu 3. Elementi prikaza su: stanje. uslov promjene stanja i akcija koja se obavlja (opis linije prelaza oblika događaj/akcija). jezičke analize (parsing) i dizajna korisničkog interfejsa.Poliščuk E. nenajavljen dolazak potvrda rezervacije 3 opoziv rezervacije ili nedolazak najavljeni dolazak 2 Ο stvaranje troška plaćanje usluga arhiviranje rezervacije 7 3 3 5 6 povećanje troška 4 ∗ privremena rezervacija 1 Ο dolazak gosta Ο opoziv rezervacije 3 nedolazak gosta 3 1 2 1. promjena stanja uzrokovana nekim događajem (usmjerena linija od jednog stanja prema drugom) i događaj. Dijagram prelaza stanja najčešće opisuje vremenski zavisno ponašanje čitavog sistema. Kreirati rezervaciju 2. Manji sistemi se mogu prikazati jednim dijagramom. Primjenjuju se kod razvoja sistema za rad u stvarnom vremenu (real-time system). Kreirati zaduženje 5. Poništiti zaduženje 6. dok veći sistemi se razlažu slično dijagramima toka podataka. Predstavljaju grafički prikaz promjena stanja. Dijagram prelaza stanja (State Transition Diagram (STD)) Dijagram prelaza stanja se zasniva na ideji mašine sa konačnim brojem stanja. 7. Dijagrami prelaza stanja sistema za rad u stvarnom vremenu se razlikuju po tome što sadrže posebno stanje . Dijagram podudarnosti učinka za rezervaciju sobe u hotelu Proljeće. kumulativni rezultat ponašanja nekog objekta (pravougaonik. Obrisati podatke o rezervaciji Slika 7. prelaz. pri čemu stanje na nekom nivou postaje početno stanje dijagrama na nižom nivou. krug ili elipsa).8. Ažurirati status rezervacije 4. hipotetičkom mehanizmu koji u nekom trenutku može biti u jednom od konačno mnogo diskretnih stanja. Jaroslav: Projektovanje informacionih sistema rezervacija sobe 129 rezervacija.4. tj vremenski zavisnog ponašanja sistema.

Jedan element interfejsa (odabirač. ali je konačan. Broj putanji kojima korisnik može mijenjati dijaloge je obično vrlo velik.9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro. i mogućnosti su. Mape dijaloga Korisnički interfejs u mnogim aplikacijama se može promatrati kao konačni automat.9. 7. poznate. doviđenja“ čekanje na izbor obavljen odabir/ „Pokupite“ izvađeno/ „Još nešto?“ natočeno (izbrojano) Slika 7.130 Poliščuk E. Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro. ali ništa ne govore o dizajnu ekranske forme. radna površina. Korisnik može doći do ograničenog broja drugih elemenata u zavisnosti o akcijama koje preduzima.5. Prikazuju elemente dijaloga u sistemu i mogućnost navigacije između njih. komandna linija ili dijalog prozor) može biti aktivan u određenom trenutku. Jaroslav: Projektovanje informacionih sistema "besposlen". prazni hod (idle) neispravna kartica/ „Neispravna“ kartica izvađena/ “Umetnite“ ispravna kartica/ „Izaberite“ čekanje na vađenje kartice izabran „Kraj“/ „Hvala. Korisnici i razvojni tim mogu zajednički razmatrati dijalog mape kako bi postigli zajednički stav o tome kakva treba biti korisnikova interakcija sa sistemom kako bi se izvršio određeni zadatak. najčešće. na kome su naglašena stanja „čekanje”. Mape dijaloga prikazuju sistem na visokom nivou apstrakcije. . Na slici 7.

Polazna tačka za ovaj model korištenja je popis traženih hemikalija koji se naziva "Trenutna lista zahtjeva". kao što je pogrešan unos koji pokreće pojavljivanje poruke o grešci. npr. dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom nivou. Uslov koji pokreće korisničku navigaciju prikazan je kao tekst na strelicama. korisne kod modeliranja vizuelne arhitekture web sjedišta. Navigacioni linkovi u sjedištu pojavljuju se kao tranzicije na dijalog mapi. kao što je pritisak tastera ili klik na link ili dugme dijalog prozora. sistemski uslov. pa se ponekad tako i nazivaju (eng. kao što je signal da je pisač ostao bez papira i kombinacija navedenih. Radi pojednostavnjenja mogu se izostaviti neke opšte funkcije.Poliščuk E. Primjer: Korisnik inicira model korištenja odabirom opcije "zatraži hemikaliju" iz glavnog odabirača. Koristi se notacija dijagrama prijelaza stanja. kao što je kucanje opcije iz ekranske forme i pritisak na taster Enter. pritiskanje tastera F1 da bi se dobila pomoć ili standardni navigacijski linkovi koji se pojavljuju na svakoj stranici. Dijalog mape mogu prikazati alternativne putove kao grane koje odstupaju od uobičajenog puta. a alternativno se hemikalija može dobiti iz zaliha hemijske laboratorije. uobičajeni put bi bio naručiti hemikaliju od vanjskog dobavljača. Postoji nekoliko vrsta pokretačkih uslova: korisnička akcija. vrijednost podataka. Konkretna ugradnja može biti drugačija. . takođe. npr. site maps). Prilikom analize zahtjeva. Jaroslav: Projektovanje informacionih sistema 131 Dijalog mape su.

. nezavisnu izgradnju podsistema. programiranje (realizacija programskog proizvoda). Faze životnog ciklusa programskog proizvoda su: strategija (strateško planiranje razvoja programskog proizvoda). integraciju nezavisno izgrađenih komponenti u jedinstvenu cjelinu (programski proizvod. analize. Metodologija životnog ciklusa polazi od činjenice da životni ciklus svakog programskog proizvoda. Strukturirani pristup se primjenjuje u okviru faza snimanja.132 Poliščuk E. informacioni sistem) i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije. uvođenje u upotrebu i eksploatacija sa održavanjem. snimanje i analiza (detaljna analiza ponašanja realnog sistema. prije pojave pojma CASE proizvoda. projektovanje (oblikovanje izvođačkog – implementacionog projekta programskog proizvoda). prolazi kroz iste faze. dođe kako do dovoljno kvalitetnog projekta programskog proizvoda. To znači da i razvoj programskog proizvoda treba da prati faznu logiku životnog ciklusa. Inženjerski pristup izgradnji IS 8. preciznom primjenom odgovarajućih tehnika. Jaroslav: Projektovanje informacionih sistema 8. odnosno projektovanje IS bez primjene odgovarajuće metodologije.1. projektovanja i programiranja programskog proizvoda. Pojam softverskog inženjerstva se javlja početkom 70-ih godina. dok se u fazi programiranja izrađuju i uputstva za upotrebu aplikacija. koja predstavljaju sastavni dio programskog proizvoda. Bitno je da sve nabrojane faze prati aktivnost izrade odgovarajuće projektne. Ideja softverskog inženjerstva je bila uvođenje metodološkog. tako i do dovoljno kvalitetnog samog programskog proizvoda. Okosnicu takvog koncepta predstavljaju metodologija životnog ciklusa i strukturirani pristup razvoju programskog proizvoda. inženjerskog pristupa pri razvoju programskih proizvoda sa ciljem da se u zadanim vremenskim rokovima. Uvod Razlog za uvođenje posebne discipline u računarstvu sa nazivom softversko inženjerstvo je prvi uzrok pojave softverska krize. odnosno izvođačke dokumentacije. odnosno životni vijek. Predstavlja opštu tehniku koja se zasniva na slijedećim principima: postepeno dekomponovanje složenog sistema na podsisteme manje složenosti. korisničkih zahtjeva i konceptualno projektovanje programskog proizvoda).

izrade programa. rane ’70-te: strukturirano programiranje – disciplinovano programiranje zasnovano na prikladnoj sintaksi proceduralnih jezika. dijela računarskog sistema koji nema fizičkih dimenzija. računarom podržana dokumentacija. pisanja dokumentacije. probnih izvedbi programa. 2. itd. oprema ili tehnika. Programsko inženjerstvo (Software Engineering) Programski proizvodi (software) se sastoji od: programske podrške.izrada hijerarhijskih sistema modularne programske opreme. Programsko inženjerstvo (softverski inženjering) ima više definicija.Poliščuk E. preporuka. Područje programskog inženjerstva su poslovi kojima se oblikuje i razvija programska oprema. ima za cilj ekonomičan razvoj visoko. Razvoj postupaka (metoda) programskog inženjerstva se može hronološki prikazati: • godina 1968: Prva NATO konferencija o programskom inženjerstvu. Biće navedene neke od njih: 1. Informaciona tehnologija (IT) je bilo koji oblik tehnologije. Računarska aplikacija je namjenski program. Jaroslav: Projektovanje informacionih sistema 133 8. 2000]. kao i sistemska primjena prikladnih alata i tehnika na čitav proces razvoja programske opreme. svih vrsta programa i programskih jezika. Informacioni sistem uobičajeno sadrži jednu ili više računarskih aplikacija. ne troše se.2. tj. 1994]. Programsko inženjerstvo je inženjerska disciplina koja obuhvata sve aspekte izrade programske opreme [Sommerville. odnosno računarom podržano rješenje jednog ili više poslovnih problema ili potreba. dugo se koriste i lako se kopiraju (zajedno sa greškama). • kraj '60-ih. primjenjeni programski proizvod (oprema). Programsko inženjerstvo je inženjerska disciplina koja se bavi praktičnim problemima razvoja velikih programskih sistema [Sommerville. analize vremenskog izvođenja. koju ljudi koriste za upravljanje informacijama (obavještenjima). stare. podložnost greškama.kvalitetne programske opreme“ [Pagel & Six. tehnika testiranja (provjere valjanosti). Računarski programi. posvećena problemima razvoja programske podrške (“softverska kriza”). podaci i dokumentacija imaju slijedeća svojstva: složenost. 1992]. . slika i zvuka). „Programsko inženjerstvo . Sastoji se od analiziranja i bližeg opisivanja (specifikacije) postupaka koje treba programirati. teško se mjere. • sredinom ’70-ih: strukturirani dizajn . 3.. U današnje vrijeme obuhvata računarsku tehnologiju (hardver i softver) i telekomunikacionu tehnologiju (mreže za prenos podataka.. itd.

softvera). Proizvodi softverskog inženjeringa (Software Product Engineering) su: zahtjevi softverskog inženjeringa (Software Requirements Engineering). . kodiranje softvera (Software Coding). • sredinom '80-ih: informaciono inženjerstvo. Jaroslav: Projektovanje informacionih sistema • kasne ’70-te. operativni sistemi (Operating Systems) i programski jezici (Programming Languages). združeni razvoj aplikacija (Joint Application Development). rane '80-te: strukturirana analiza . Računarsku osnovu (Computing Fundamentals) softverskog inženjeringa sačinjavaju: algoritmi i strukture podataka (Algorithms and Data Structures). arhitektura računara (Computer Architecture). odnosno način na koji se provodi određena aktivnost razvojnog procesa. izrada prototipova.3. rane 2000-te: automatizacija informatičkih tehnologija. a. uz korištenje dobro definisane notacije. . rad softvera i održavanje (Software Operation and Maintenance). kao što se to čini sa drugim proizvodima. U procesu razvoja IS mora biti zastupljena sistemska primjena prikladnog skupa metoda.134 Poliščuk E. tehnika i alata. softversko upravljanje konfiguracijom (Software Configuration Manage-ment). . matematička podrška (Mathematical Foundations). IDEF. • kasne ‘90-te. Definiše način provođenja određenog postupka i dokumentovanja rezultata tog postupka. softversko upravljanje odlučivanjem (Software Risk Management). Sugeriše proces obavljanja i način dokumentovanja. softversko upravljanje kvalitetom (Software Quality Management). oblikovanje podataka. • kasne '80-te: brzi razvoj aplikacija (Rapid Application Development). • rane ‘90-te: objektno usmjereni razvoj. Tehnika je način provođenja metode. softverski dizajn (Software Design)..odvajanje logičkog opisa od fizičkog opisa (informacionog) sistema. Metoda je smišljen i organizovan skup procedura izrade (modela.. Razvoju IS treba pristupiti kao strukturiranom i planiranom procesu podržanom računarom. IS mora biti projektovan. Informaciono inženjerstvo (Information Engineering) Informaciono inženjerstvo se bavi inženjerskim pristupom izgradnji IS i upravljanju informacijama. testiranje softvera (Software Testing). ERD. Upravljanje softverom (Software Management) u slijedećim segmentima: softversko upravljanje projektom (Software Project Management). 8. takođe. • rane '80-te: CASE alati. definiše primjenu tehnika i njihovo povezivanje (npr. softversko upravljanje procesima (Software Process Management) i softverska akvizicija (Software Acquisition). DFD).

Ipak. koncepti razvoja sistema i metodologije (Systems Development Concepts and Methodologies). upravljanje procesima za promjene (Managing the Process of Change). sredstvo koje se koristi u razvoju IS. upravljanje odlučivanjem (Risk Management). algoritmi i strukture podataka (Algorithms and Data Structures). pravni i etički aspekti IS (Legal and Ethical Aspects of IS). Osigurava djelotvornost i (dovoljno) rano donošenje odluka definisanjem zahtjeva i njihovim povezivanjem sa odgovarajućim oblikovanjem. za sistemsko inženjerstvo se može reći da: 1. 3. 4. Predstavlja interdisciplinarni i/ili timski pristup oblikovanju i razvoju. implementacija sistema i strategija testiranja (Systems Implementation and Testing Strategies). programski jezici (Programming Languages)). 8. 2. Upravlja ciklusom koji sadrži sve faze od dizajna do odumiranja. informaciona i poslovna analiza (Information and Business Analysis). planiranje aplikacija (Application Planning). pristup razvoju sistema (Approaches to Systems Development). operativni sistemi (Operating Systems). rad sistema i održavanje (Systems Operation and Maintenance) i razvoj posebnih vrsta informacionih sistema (Systems Development for Specific Types of Information Systems). Organizacioni i upravljački koncepti (Organizational and Management Concepts) informacione tehnologije su: opšta teorija organizacije (General Organization Theory). upravljanje projektom (Project Management).4. . upravljački informacioni sistemi (Information Systems Management). Sagledava sistem kao cjelinu pristupom sa vrha prema dolje (top-down). Informacionu tehnologiju (Information Technology) sačinjavaju: arhitektura kompjutera (Computer Architectures). Sistemsko inženjerstvo (System Engineering) Nema opšte prihvaćene definicije sistemskog inženjerstva. kojim se osigurava njihova djelotvornost i funkcionalnost. telekomunikacije (Telecommunications). baze podataka (Database) i vještačka inteligencija (Artificial Intelligence). profesionalizam (Professionalism) i interdisciplinarno znanje (Interpersonal Skills).Poliščuk E. teorija odlučivanja (Decision Theory). Jaroslav: Projektovanje informacionih sistema 135 Softverski alati (tool) je instrument. Teoriju i razvoj sistema (Theory and Development of Systems) sačinjavaju: sistemski i informacioni koncepti (Systems and Information Concepts). organizacioni postupci (Organizational Behavior). informacioni sistemski dizajn (Information Systems Design). alati za razvoj sistema i tehnike (Systems Development Tools and Techniques).

što u praksi ne mora biti uvijek obezbjeđeno.136 Poliščuk E. prevazilazi čovjekove moći percepcije i koncentracije. ili je namjenjen za kompletnu podršku projektovanju i realizaciji drugog programskog proizvoda. održavanje konzistentne projektne dokumentacije i kontrola kompleksnosti projekta postaju naporan posao. Iterativno vraćanje na ranije faze projekta u cilju otklanjanja grešaka. protivrječnih ograničenja i druge. dok je skraćenica CAISE akronim naziva Computer Aided Information System Engineering (informaciono/sistemsko inženjerstvo podržano računarom). Jaroslav: Projektovanje informacionih sistema 8. kao i kompleksnost zadataka i tehnika koje se u metodologiji životnog ciklusa i u strukturiranom pristupu primjenjuju. Osnovni ciljevi primjene CASE proizvoda su: obezbjeđenje zadovoljavajućeg kvaliteta projekta i projektne dokumentacije. CASE proizvodi Nepostojanje odgovarajućih softverskih alata za podršku razvoja softverskih proizvoda. odnosno ako broj identifikovanih atributa ne prelazi sto. Greške učinjene u ranijim fazama projekta se uočavaju tek u kasnijim fazama. potrebni za izradu projekta. homonima. može dovesti do pojave novih grešaka. sa neizvjesnim ishodom. skraćenje vremena projektovanja i realizacije programskog proizvoda. ručno projektovanje i sprovođenje ovih izmjena. Primjena strukturiranog pristupa i metodologije životnog ciklusa znače upotrebu većeg broja manje ili više formalnih tehnika i crtanja različitih dijagrama i matrica zavisnosti na različitim nivoima detaljnosti. barem jednog zadatka u okviru životnog ciklusa drugog programskog proizvoda. Skraćenica CASE je akronim naziva na engleskom jeziku Computer Aided Software Engineering ili Computer Aided System Engineering (programsko/sistemsko inženjerstvo podržano računarom). U projektu se javljaju greške u vidu: sinonima. Tako. o manuelnom projektovanju BP ima smisla govoriti samo ako broj tipova entiteta i veza konceptualne sheme ne prelazi nekoliko desetina. na primjer. ili automatizaciju.5. postaju teško prihvatljivi. odnosno drugi i treći uzrok softverske krize. Kada veličina konceptualne sheme prelazi ove granice. . pokazuje se da problem. izmjena na jednom nivou detaljnosti često zahtjeva izmjene i na drugim nivoima detaljnost. Pri tome. povećanje produktivnosti projektanata i programera. predstavlja motiv za pojavu CASE proizvoda. Ukoliko je riječ o projektu većeg obima. Strukturirani pristup zahtjeva od projektanta i programera da posjeduju visoki nivo ekspertnog znanja iz oblasti softverskog inženjerstva i zadovoljavajući nivo znanja iz predmetne oblasti za koju se pravi programski proizvod. čije otklanjanje zahtjeva dodatni napor. zbog kompleksnosti prouzrokovane obimom. obezbjeđenje zadovoljavajućeg kvaliteta samog programskog proizvoda. Tada vrijeme i napor. a kvalitet rezultata nepredvidiv. Pod CASE proizvodom se podrazumjeva bilo koji programski proizvod namjenjen za podršku. obezbjeđenje jednostavnog i jeftinog održavanja programskog proizvoda. kada ih je teže otkloniti.

• obavljanje izmjena na programskim proizvodima. Jaroslav: Projektovanje informacionih sistema 137 U skladu sa navedenim razlozima. od CASE proizvoda se očekuje da obezbjede što viši stepen automatizacije kada se obavljaju slijedeći zadaci: • izrada dokumentacije. CASE proizvodi su organizovani tako da rade nad jedinstvenom BP. Prema toj klasifikaciji. dokumentaciji. • integracija parcijalnih rezultata projektovanja u jedinstvenu cjelinu. • izrada (generisanje) programskih proizvoda. Alat za modeliranje dijagrama toka podataka Alat za modeliranje ER dijagrama Alat za modeliranje programskih specifikacija Rječnik podataka Alat za modeliranje matrica Generatori koda Slika 8.1.Poliščuk E. definisanim u okviru jednog. ili više projekata.1. dijagramima. • izrada dijagrama i matrica. šta je prikazano na slici 8. koja se naziva Rječnik podataka CASE proizvoda. Rječnik sadrži podatke o svim konceptima (objektima. koji se smještaju u rječnik. Jedna. itd. matricama. vezama. • projektovanje programskih proizvoda. je izvršena prema fazama životnog ciklusa koje CASE proizvod pokriva. uobičajena i ne suviše selektivna. Svi pojedinačni alati jednog CASE proizvoda koriste i smještaju podatke u isti rječnik podataka. Da bi zadovoljili navedene zahtjeve. itd.). • kontrola funkcionalnosti. konzistentnosti. razlikuju se: . kompletnosti i kvaliteta projekta. Međusobni odnos različitih CASE alata i jedinstvenog rječnika podataka. Mogu se sresti različite klasifikacije CASE proizvoda. • konceptualno i implementaciono projektovanje shema baza podataka.

CASE proizvod koji podržava fazu strategije. odnosno kompletan život programskog proizvoda. treba da sadrži alate za podršku: planiranja projekta (izbora metodologije i tehnika razvoja IS. Implementaciono projektovanje sheme BP se može sprovoditi neposredno. To znači da alati treba da primoravaju projektanta na poštovanje formalnih . 2. dijagrama toka podataka. Kada je u pitanju faza projektovanja. organizacione i prostorne strukture sistema. organizacione i prostorne strukture). bez prethodnog generisanja programskih specifikacija. 3. ili putem modifikacija prevedene konceptualne sheme. implementaciono projektovanje sheme BP. sve je naglašeniji zahtjev da CASE sadrži „inteligentne“ alate i alate koji u sebi uključuju elemente ekspertnog znanja. CASE proizvod treba da sadrži alate za izradu: strukturiranih modela sistema (model funkcionalne. Front-End CASE) Za podršku prve tri faze životnog ciklusa koriste se projektantski CASE proizvodi. kao i funkcionalne. generisanje programskih specifikacija aplikacija (struktura menia. tj. uvođenje u upotrebu. konceptualne sheme BP i matrica. kojima se iskazuju međuzavisnosti između elemenata konceptualne sheme BP. koji su namjenjeni za podršku prve („gornje“) tri faze životnog ciklusa. integrisani projektantski i programerski CASE proizvodi. snimanje i analiza. praćenja realizacije projekta i sprovođenje postupaka kontrole kvaliteta.138 Poliščuk E. CASE proizvod može da sadrži alate za: prevođenje konceptualne sheme BP u implementacionu shemu. namjenjeni da podrže svih šest faza životnog ciklusa. Integrisani CASE proizvodi. ili putem modifikacija prethodno generisanih programskih specifikacija.5.1. Programerski CASE proizvodi. bez prethodne izrade i prevođenja konceptualne sheme. opisa ekranskih ili štampanih formi. odnosno za podršku realizacije programskog proizvoda (programiranje. Projektantski CASE proizvodi. Projektantski CASE proizvodi (Upper CASE. eksploatacija i održavanje). upravljanja projektom (detaljnog planiranja i izdavanja zadataka. kadrovskim i finansijskim). Da bi podržao faze snimanja i analize. projektovanje). podshema i standardnih procedura za upite i ažuriranje BP) i implementaciono projektovanje programskih specifikacija aplikacija. planiranja i upravljanja resursima (materijalnim. Kod projektovanja IS. modela procesa koji se odvijaju u realnom sistemu. namjenjeni za podršku posljednje („donje“) tri faze životnog ciklusa. Pri razvoju savremenih projektantskih CASE proizvoda. 8. odnosno za podršku projektovanju programskog proizvoda (strategija. kao i vremenskog terminiranja projekta). Implementaciono projektovanje programskih specifikacija aplikacija se može sprovoditi neposredno. načina i standarda za primjenu izabrane metodologije i tehnika). Jaroslav: Projektovanje informacionih sistema 1.

različitih namjena i mogućnosti.2. generacije (4GL) predstavljaju dalju nadogradnju jezika 3. Generatori koda su u mogućnosti da. 8. generacije. Back-End CASE) U programerske CASE proizvode se najčešće svrstavaju generatori koda. generacije. Programerski CASE proizvodi (Lower CASE.Poliščuk E. generacije. jer on podrazumjeva široki spektar programerskih ili korisničkih alata. vrednuje i ocjenjuje rješenja. na višem nivou.2 su prikazani mogući elementi jednog 4GL okruženja. Teško je dati preciznu definiciju jezika 4. Na taj način projektant dobija tehničku pomoć u radu. pomoć u primjeni odgovarajuće tehnike. tj. ili na osnovu programskih specifikacija generišu 4GL programe aplikacija IS. očekuje se da alat „pruži“ projektantu i ekspertnu. Pored toga. Jaroslav: Projektovanje informacionih sistema 139 pravila upotrebe odgovarajuće tehnike. generacije Rječnik podataka Generatori i editori upita Slika 8. generišu DDL opis sheme BP za konkretni sistem za upravljanje BP. Na slici 8. Takva pomoć se ogleda u mogućnosti da sam alat pruža odgovarajuća projektantska rješenja ili da je u stanju da analizira. što znači da ova vrsta jezika i dalje ima svoje mjesto u postupku realizacije programskog proizvoda. Treba uočiti da u takvo okruženje ulaze i jezici 3. koja je napravio projektant softverskog proizvoda. preglednosti i lakoće programiranja jezici 4. od jednostavnih alata do razvijenih jezika. . Alati za programiranje logike aplikacija Generatori i editori ekranskih menia Generatori i editori ekranskih formi Relacioni upitni jezik SQL Generatori i editori izvještaja Programski jezici 3. Mogući elementi jednog 4GL okruženja. koji dani alat podržava. Zbog toga se često govori o pojmu okruženja 4. na osnovu opisa implementacione sheme BP. intelektualnu. generacije.5.2. U smislu povećanja nivoa deklarativnosti.

sporija od odgovarajuće aplikacije razvijene uz pomoć jezika 3.3. generacije je. čime se obezbjeđuje jedinstveno razvojno okruženje programskih proizvoda. 4GL okruženja i jezika 3. Funkcionalnost. uz očuvanje dovoljno dobrih performansi izvršavanja razvijene aplikacije i dovoljno dobre funkcionalnosti za rad. . iz istih razloga kao i CASE proizvodi. na istoj hardverskoj platformi.140 Poliščuk E. Jezik 4. Prednosti i nedostaci upotrebe generatora koda i 4GL okruženja ukazuju da se pravilnim izborom generatora koda i 4GL okruženja. kao i smanjenju troškova održavanja aplikacija. generatora koda i 4GL okruženja je manja od funkcionalnosti jezika 3. generacije. 2000]. Šta više. generacije. oslonjeni na jedinstveni rječnik podataka. Uloženi napor. mogu obezbjediti sve prednosti upotrebe generatora koda i 4GL okruženja. Prisutni su i negativni efekti primjene generatora koda i jezika 4. jezika 3. generacije ili generisana aplikacija pomoću jezika 4. Jaroslav: Projektovanje informacionih sistema Uočava se da su svi alati iz okruženja 4. nastoji se da ovi alati budu integrisani sa CASE proizvodima po pitanju korištenja zajedničkog rječnika podataka. budući da je olakšano otkrivanje. generacije. Neposredni pozitivni efekti primjene generatora koda i 4GL okruženja se ogledaju u ubrzanju i olakšanju procesa izrade programskog proizvoda.4. generacije [Mogin et al. Uočava se da ovi nedostaci predstavljaju kontinuitet trendova koji se odnose i na uvođenje i upotrebu jezika 3. generacije. odnosno širina primjene. generacije razvijeni su generatori koda i 4GL okruženje.3. potreban za realizaciju aplikacije Složenost aplikacije Slika 8. generacije. pronalaženje i ispravljanje uočenih grešaka. generacije i načina povezivanja sa 4GL okruženjem i odgovarajuće („jače“) hardverske platforme. To znači da se mogu postići velike uštede pri realizaciji i održavanju aplikacija IS dodatnim ulaganjima u hardver i alate za razvoj aplikacija. Problematika funkcionalnosti generatora koda. Posredni pozitivan efekat je mogućnost primjene prototipskog pristupa razvoju programskih proizvoda. o čemu je detaljnije bilo govora u podtački 2. Da se prevaziđe neproduktivno i dugotrajno programiranje uz upotrebu jezika 3.

generacije ilustrovana je dijagramom na slici 8. tako da svako slijedeće regenerisanje uzme u obzir i postojeća prilagođenja koda. Jaroslav: Projektovanje informacionih sistema 141 Problematika funkcionalnosti generatora koda. Drugi način se zasniva na sistematičnom evidentiranju dorađenih dijelova generisanog koda u okviru rječnika podataka. dok se vrlo složeni i dominantno proceduralni dijelovi aplikacija mogu uspješno realizovati samo upotrebom jezika 3.5. 4GL okruženja i jezika 3. Uočava se da se manje složene aplikacije mogu neposredno dobiti upotrebom generatora koda. nakon generisanja koda potrebno izvršiti dodatna prilagođavanja. . generacije. Iz navedenih razloga je prethodno i naglašena potreba kombinovane upotrebe alata 4. Takvi proizvodi. koji bi bez daljih dorada bio spreman za upotrebu. Smatra se da je samo 25 do 30% specifikacija prenosivo iz projektantskog (gornjeg) u programerski (donji) CASE. obavezno sadrže alate za projektovanje konceptualne.3. Cilj je da se pređe granica od 80% ukupno generisanog koda. nadzor i upravljanje izvedbom. generacije i jezika 3. Ukoliko sadrže i generatore opisa sheme BP. pripadaju klasi projektantskih CASE proizvoda. tada pripadaju i klasi programerskih CASE proizvoda. generacije. Potpuno integrirano CASE okruženje automatizuje izradu modela poslovnog sistema. koji su nomjenjeni za razvoj IS.4. tako da se pomoću generatora koda mogu izgraditi i složenije aplikacije. 8. Integracija programskih proizvoda se ostvaruje usvajanjem pravila određene metode razvoja.3. Ponovno generisanje aplikacije. te osiguranje kvaliteta IS. kao i izgradnju i primjenu IS. Savremeni trendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublaži na dva načina. implementacione i interne sheme BP. Upotreba generatora koda ima još jedan nedostatak.Poliščuk E. Integrisani CASE proizvodi (Integrated CASE (ICASE)) Integrisani CASE proizvodi pokrivaju sve faze razvoja. uglavnom. te automatizovanim proslijeđivanjem informacija iz jedne faze razvoja u drugu. upotrebom alata 4. prilagođene konkretnim SUBP. Projektovanje shema baze podataka pomoću CASE proizvoda Za projektovanje shema baza podataka postoje samostalni CASE proizvodi. što predstavlja ozbiljnu prepreku potpuno automatizovanoj izradi programskih proizvoda. generacije. upotrebom zajedničkog rječnika podataka i zajedničkog interfejsa. nakon već izvršenog prilagođavanja generisanog koda pomoću alata 4. Za složenije aplikacije je. može značiti „uništavanje“ prethodno izvršenih prilagođavanja. Prvi način predviđa pomjeranje granice upotrebljivosti generatora koda.5. planiranje razvoja IS. generacije. Integrisani CASE proizvodi. 8. a sadrže i dodatne module za povratno (reverzno) inženjerstvo.

reverzno inženjerstvo i generisanje programskog koda.142 Poliščuk E. nakon prevođenja u relacioni model podataka. zainteresovan da pomoću računara olakša. uvjek rezultuje u skup relacija. OOAD). Na slici 8. OMT.4. CASE proizvod tu izmjenu u ER dijagramu vrši automatski. prvenstveno. Rezultat ovakvog projektovanja je automatski generisan opis implementacione i interne sheme u relacionom upitnom jeziku SQL. Jaroslav: Projektovanje informacionih sistema Savremeni CASE proizvodi za projektovanje konceptualne. Nema dokaza da „pažljivo“ projektovanje ER dijagrama. najčešće u skupu tipa entiteta ili tipa veze. u suštini. Mogućnost definisanja funkcionalnih zavisnosti posjeduju samo pojedini CASE proizvodi. u praksi se često dešava da ovako nacrtan ER dijagram ne predstavlja lako razumljivu osnovu za komunikaciju između projektanta i korisnika. Sa druge strane. koji podržava OO metode (UML. … ). 8. koji je namjenjen za dizajn i reinžnjerstvo BP. podržavajući različite notacije projektovanja (IDEF1X. Ukoliko rezultat normalizacije pokaže da posmatrani tip entiteta ili tip veze treba dekomponovati. ili njihove prototipove. crtanje ER dijagrama se može posmatrati samo kao usputan. korak u projektovanju implementacione sheme i. apstraktnom i stranom notacijom. Booch. DM). koje su bar u trećem normalizovanom obliku (3NO). CASE proizvod za projektovanje ER konceptualne sheme se sastoji od grafičkog editora za poluautomatsko crtanje ER dijagrama i analizatora konzistentnosti nacrtanih shema. Na slici 8. Analizator konzistentnosti je namjenjen za provjeru usaglašenosti nacrtanog ER dijagrama sa pravilima strukturiranja. korisnik može da ocjeni da li mu rješenje odgovara.6 su prikazani primjeri nekih aktuelnih CASE proizvoda. Crtanje ER dijagrama se obavlja biranjem simbola i njihovim povezivanjem. Pojedini CASE proizvodi omogućavaju i projektovanje fizičke organizacije relacione BP. predstavlja heuristički postupak. Na slici 8. . koja je predstavljena.5 i 8.5 je prikazana ekranska forma alata za oblikovanje BP CA AllFusion ERwin. koji podržava više metodologija projektovanja IS (SSAD.4 je prikazana ekranska forma integrisanog CASE alata (ICASE) Popkin System Architect. Krajnji korisnik je. Grafički editor sadrži predefinisane standardne geometrijske simbole koncepata ER modela. zasnovanu na relacionom modelu podataka. Međutim.6 je prikazana ekranska forma alata za projektovanje objektno orijentisanog softvera Rational ROSE. Na slikama 8. za njega. IE. i ne baš jednostavan. ubrza i poveća kvalitet obavljanja svojih radnih zadataka i nije spreman da se udubljuje u analizu kvaliteta konceptualne sheme. Prema tome. implementacione i interne sheme najčešće omogućavaju projektovanje konceptualne sheme u modelu entiteti – veze (ER model) i automatsko prevođenje ER konceptualne u implementacionu shemu. kao i pronalaženje potencijalnih sinonima i homonima. Tek kada dobije gotove programe. u skladu sa pravilima strukturiranja ER dijagrama. programere interesuje podshema u implementacionom modelu podataka. CASE proizvod vrši normalizaciju relacija. Nakon definisanja skupa funkcionalnih zavisnosti.

Poliščuk E. Slika 8. Jaroslav: Projektovanje informacionih sistema 143 Slika 8.4. Ekranska forma integrisanog CASE alata (ICASE). Ekranska forma CASE alata za oblikovanje baza podataka. .5.

• uvođenje u upotrebu i eksploatacija IS.6. sa značajnom prisutnošću na tržištu informacione tehnologije u vrijeme pisanja ove knjige. • projektovanje IS.144 Poliščuk E. Ovakvim pristupom projektovanju. Ekranska forma CASE alata za projektovanje objektno orijentisanog softvera. 8. Designer 2000 radi sa jedinstvenim rječnikom podataka (rječnik podataka programskog proizvoda Designer 2000 se na engleskom jeziku zove Repository). IS se istovremeno razvija radom na više aplikativnih sistema. Jaroslav: Projektovanje informacionih sistema Slika 8. i predstavlja sveobuhvatni programski proizvod. Aplikativni sistem može predstavljati zaokruženu cjelinu. Projektantsko-programerske aktivnosti u okviru Designer-a 2000 se obavljaju u cjelinama. pod nazivom ORACLE/Designer 2000. namjenjen je za podršku slijedećih faza životnog ciklusa: • snimanje i analiza poslovnog sistema. Prikaz CASE proizvoda ORACLE/Designer 2000 Komercijalni CASE proizvod korporacije ORACLE (USA). • održavanje IS. • programiranje korisničkih aplikacija.5. podsistem ili IS. koje se nazivaju aplikativni sistemi. implementiranom u okviru ORACLE baze podataka. Razvoj IS pomoću više aplikativnih sistema omogućava veću fleksibilnost u radu. prvenstveno u pogledu lakšeg traženja podataka i sprovođenja .5.

Po svom sastavu Designer 2000 je integrisani skup programskih alata. Jaroslav: Projektovanje informacionih sistema 145 izmjena u okviru projekta. koja uključuje evolutivni. tako i na bilo kojoj od kombinacija. i primjenu tehnika reverznog inženjerstva BP i aplikacija IS. Prilikom prijavljivanja za rad sa Designer-om 2000. Slika 8. Postoji i mogućnost da se cjelokupni IS razvija putem samo jednog aplikativnog sistema. Ekranska forma ORACLE/Designer-a 2000.7. olakšava održavanje različitih verzija projektne dokumentacije i zaštitu sadržaja rječnika podataka od brisanja. Navedeni pristup ne uvodi ograničenja koja bi negativno uticala na integrisanost IS. Za fazu strategijskog planiranja.7. Takođe. Designer-a 2000 svoju metodologiju može da zasnovana. kao i faze snimanja i analize. nenamjernih izmjena ili neovlaštenog pristupa. kako na klasičnom modelu primjene metodologije životnog ciklusa. kao i na prototipskom razvoju. inkrementalni ili zvjezdasti model primjene metodologije životnog ciklusa. Odgovarajuća ovlaštenja za rad sa izabranim aplikativnim sistemom moraju biti prethodno dodjeljena korisniku.Poliščuk E. takođe. slika 8. korisnik se odlučuje za aplikativni sistem nad kojim će realizovati svoje projektantsko-programerske aktivnosti. različite namjene. Designer 2000 predviđa upotrebu slijedećih alata: . Designer 2000 omogućava.

• Design Editor / Modules. kao i struktura programskih modula (ekranskih formi aplikacija).alat za modeliranje tokova podataka unutar poslovnog i informacionog sistema. • Design Editor / Server Model. programiranje procedura. podshema i strukture ekranskih formi). za prevođenje ER konceptualne sheme baze podataka u relacionu shemu baze podataka. • Generate Database Administration Objects .tabela. zasnovanih na jeziku IV generacije Developer 2000 / Forms. koji je namjenjen za dijagramski prikaz procesa i tokova u realnom sistemu i podršku njihovog eventualnog reverznog inženjeringa. Jaroslav: Projektovanje informacionih sistema Process Modeller. • Application Design Transformer. grafički prikaz podataka i biblioteka procedura i funkcija). uvođenja u upotrebu i eksploataciju i održavanje informacionog sistema. implementacione sheme baze podataka (oblikovanje shema relacija .alat za modeliranje funkcionalne dekompozicije realnog sistema i strukture programske podrške informacionog sistema. programa za interaktivno ažuriranje baze podataka. paketa procedura i funkcija. • . • Dataflow Diagramer . zasnovanih na jeziku IV generacije Developer 2000 / Reports. generisanje izvještaja. za generisanje programskih modula za interaktivni pristup bazi podataka. • Generate Module / Forms. za generisanje programskih modula za formiranje izvještaja. za inicijalno generisanje programskih specifikacija (opisa programskih modula. • Design Editor / DB Admin. • Generate Module / Reports. • Function Hierarchy Diagramer . za projektovanje interne sheme baze podataka (zadavanje parametara fizičke organizacije podataka). za projektovanje relacione. i • Design Editor / Distribution. funkcija. i • Entity Relationship Diagramer . za projektovanje distribuirane sheme baze podataka. Kada su u pitanju faze: programiranja. Designer 2000 je opremljen slijedećim generatorima koda: • Generate Database From Server Model. Za fazu projektovanja informacionog sistema su namjenjeni slijedeci alati: Database Design Transformer.146 • Poliščuk E. kao i trigera baze podataka). putem dijagrama tokova podataka.alat za konceptualno modeliranje sheme baze podataka.generisanje SQL opisa interne sheme baze podataka. za implementaciono projektovanje programskih modula (tj. putem dijagrama tipova entiteta i veza. za generisanje SQL opisa implementacione sheme baze podataka.

Report Builder. • Generate Module / Web Server. za kreiranje interaktivnih programskih modula (koji se jos nazivaju i "forme"). namjenjen za prevođenje implementacione sheme baze podataka u konceptualnu shemu baze podataka. kreiranih u okviru alata Developer 2000/Reports. • Generate Module / Visual Basic. za kreiranje programskih modula za izvještavanje (koji se nazivaju i "izvještaji") i Graphics Builder. za generisanje programskih modula za prezentiranje uputstava i ostalih tekstualnih informacija. zasnovanih na jeziku IV generacije Developer 2000 / Graphics. koji se svrstavaju u oblast reverznog inženjerstva: • Capture Design of Database. namjenjen za reverzni inženjering interaktivnih programskih modula.Poliščuk E. za kreiranje programskih modula za grafički prikaz podataka ("grafikona"). u koje. dosta čvrsto povezan i sa ORACLE-ovim okruženjem četvrte generacije Developer 2000. za pristup bazi podataka preko Internet/Web servera. izmedju ostalih. u dijelu koji se odnosi na generatore koda. kao i utvrđivanje i eliminisanje razlika između stanja rječnika ciljne baze podataka i rječnika Designer-a 2000. Designer 2000 posjeduje slijedeće: • . na osnovu stanja rječnika ORACLE baze podataka. prikazanu putem dijagrama tipova entiteta i veza. Pored nabrojanih. namjenjen za reverzni inženjering bibliotečkih modula. Može se konstatovati da je Designer 2000. kreiranih pomoću alata Visual Basic. • Capture Design of Visual Basic. zasnovanih na Forms ili Microsoft Help korisničkom interfejsu. Designer 2000 posjeduje i slijedeće programe. • Capture Design of Report. • Table To Entity Retrofit. i • Capture Applicatoin Logic. spadaju alati: Form Builder. za generisanje programskih modula za interaktivni pristup bazi podataka. kreiranih u okviru alata Developer 2000/Forms. namjenjen za reverzni inženjering implementacione ili interne sheme baze podataka. zasnovanih na programskom jeziku Visual Basic. zasnovanih na HTML formatu. i • Generate Module / Help System. Jaroslav: Projektovanje informacionih sistema 147 Generate Module / Graphics. • Capture Design of Library. namjenjen za reverzni inženjering programskih modula za izvještaje. namjenjen za usaglašavanje implementacione specifikacije Forms modula iz Designer-a 2000 i postojećeg Forms modula iz Developer-a 2000. za generisanje programskih modula za grafički prikaz podataka. za generisanje ORACLE WebServer programskih modula. kreiranih u okviru paketa Developer 2000. • Capture Design of Form. namjenjen za reverzni inženjering interaktivnih programskih modula. U skupu alata opšte namjene.

Nastoji se da se sav uloženi napor. Tehnike reverznog inženjerstva se koriste za ostvarivanje slijedeća dva osnovna cilja.148 • Poliščuk E. Prvi cilj je generisanje projektne i programerske dokumentacije za aktuelnu verziju programskog proizvoda. Jedan od zahtjeva. U mnogim organizacijama uložena je velika količina materijalnih. kao alat za prezentiranje uputstava za korištenje Designer-a 2000. arhiviranje i dearhiviranje rječnika podataka. • Repository Administration Utility. Kada je u pitanju objektno orijentisani pristup razvoju informacionog sistema. jeste da se u razvoj inovirane verzije IS ne kreće iz početka. Drugi cilj je . i • SQL Plus. na osnovu stanja rječnika podataka Designer-a 2000. iskustvo. za generisanje velikog broja različitih tipova izvještaja. koji se postavlja prilikom prelaska na nove informacione tehnologije.6. kao što su: instalacija i deinstalacija rječnika podataka. Početak reverznog inženjerstva u razvoju programskih proizvoda se vezuje za postupak ručnog. za koju prethodno takva dokumentacija nije urađena. pomoću kojeg se obavljaju administrativni zadaci nad Designer-om 2000. Reverzno inženjerstvo Nastanak pojma i tehnika reverznog inženjerstva je motivisan slijedećom situacijom. itd. u cilju stvaranja osnova za održavanje tekuće verzije tog programskog proizvoda. namjenjen za izgradnju različitih tipova matričnih dijagrama. namjenjen za projektovanje dijagrama klasa objekata. na osnovu prethodno realizovanog programskog proizvoda. putem hijerarhijski organizovanog navigatora objekata. jer je to daleko ekonomičnije od ponovnog projektovanja IS. • Online Help. • Matrix Diagramer. za interaktivno izvršavanje SQL naredbi nad ORACLE bazom podataka. ili samo kao "papirna" projektna dokumentacija. prevođenje dijagrama klasa objekata u implementacionu shemu baze podataka i implementaciono i fizičko projektovanje sheme baze podataka. obavljanje određenih formalnih kontrola. dodjela prava pristupa korisnicima. pri čemu ti izvještaji služe za sprovođenje određenih kontrola i analiza kvaliteta projekta. Jaroslav: Projektovanje informacionih sistema Repository Object Navigator. finansijskih i ljudskih resursa u razvoj i eksploataciju IS. 8. ili automatizovanog generisanja projektnih i programskih specifikacija. • Repository Reports. postojeća rješenja i resursi što bolje iskoriste. u okviru Designer-a 2000 se pojavljuje alat pod nazivom: • Object Database Designer. namjenjen za direktni pristup objektima u rječniku podataka Designer-a 2000.

u okviru SUBP ORACLE/Designer 2000 prevođenje implementacione sheme BP u konceptualnu shemu BP obavlja program Table To Entity Retrofit). u okviru SUBP ORACLE /Designer . pomoću kojeg se želi razviti nova verzija tog programskog proizvoda. Na slici 8. Tehnike reverznog inženjerstva. Generisanje programskih specifikacija (struktura menia.8 je prikazana ekranska forma alata za reverzno inženjerstvo. stanja rječnika podataka konkretnog sistema za upravljanje bazama podataka (SUBP) pod kojim je posmatrana BP realizovana ili opisa datoteka i formata slogova u programskom kodu aplikacija tekuće verzije IS (npr. Generisanje konceptualne sheme BP. na osnovu implementacione sheme baze podataka (npr. na osnovu nekih od slijedećih parametara: realnih podataka koji postoje u BP. Ekranska forma CASE alata za reverzno inženjerstvo. u domenu IS. 2. obavlja program Capture Design of Database). Jaroslav: Projektovanje informacionih sistema 149 generisanje projektnih i programskih specifikacija programskog proizvoda u formatu "razumljivom" CASE proizvodu. se primjenjuju za ostvarenje slijedećih zadataka: 1. podshema i proceduralne logike) na osnovu programskih kodova aplikacija tekuće verzije IS (npr.8. na osnovu stanja rječnika ORACLE baze podataka i eliminisanja razlika između rječnika ciljne BP i rječnika Designer-a 2000.Poliščuk E. ekranskih formi ili formi za izvještaje. 3. Slika 8. u okviru SUBP ORACLE/Designer 2000 reverzni inženjering implementacione sheme BP. Generisanje implementacionog opisa sheme BP.

medjutim. tj. Izbor tehnike reverznog inženjerstva i njena automatizovana primjena u velikoj mjeri zavisi. a najlošiji ako se kao ulazna specifikacija koriste samo realni podaci iz BP. na koju se tehnika reverznog inženjerstva primjenjuje. na primjer. kako od prirode konkretnog zadataka koji se rješava. u opštom slučaju. Ukoliko se. Ukoliko rječnik podataka konkretnog sistema za upravljanje bazama podataka sam po sebi nije dovoljno informativan. najbolji rezultat se. . tada ni izlazni rezultat reverznog inženjerstva ne može biti dobar. Ova konstatacija. "informativnosti" ulazne specifikacije. Capture Design of Report i Capture Design of Library). namjenjeni su programi Capture Design of Form. Jaroslav: Projektovanje informacionih sistema 2000 za reverzni inženjering ekranskih formi. izvještaja i bibliotečkih modula. ili se u tom rječniku. može očekivati ukoliko se kao ulazna specifikacija koriste podaci iz rječnika podataka sistema za upravljanje bazama podataka. tako i od kvaliteta. tehnika reverznog inženjerstva primjenjuje za generisanje implementacione sheme BP.150 Poliščuk E. Samim tim je i kvalitet generisanog rezultata u reverznom inženjerstvu bitno određen kvalitetom ulazne specifikacije. ne nalaze svi potrebni podaci. ne mora biti uvijek tačna. iz nekog razloga.

Alternative i/ili nadopune su informaciono inženjerstvo. Oblikovanje i arhitektura informacionog sistema 9. Mogu se izdvojiti slijedeće faze definisanja opštog dizajna: Analiza i distribucija podataka. Analiza i distribucija procesa sadrži: 1. Izrada dobrog modela podataka. objektno-relacioni.1. Pretvaranje konceptualnog modela podataka u logički model (relacioni. koji mora biti jednostavan. Takođe. kao i analiza podataka i normalizacija modela. izrada prototipa. kojim se opisuje kako sistem radi. Određuju se i razvojni alati.1. odnosno izrada sheme aplikacije. Daje procjenu alternativa i detaljnu specifikaciju računarom podržanog rješenja. Pretvaranje logičkog modela procesa u fizički model za odabranu arhitekturu. određuje da li je softver nabavljen. izmjenu i brisanje podataka i po potrebi ažuriranje modela procesa. odnosno analiza entiteta normaliziranog modela i uočavanje događaja i uslova koji uzrokuju stvaranje. Analiza događaja. napravljen prema zahtjevima korisnika ili mješavina. neredundantan. Omogućava izradu modela za ugradnju. Moderni strukturirani dizajn je procesno usmjerena tehnika razrade velikog programa u hijerarhiju modula sa ciljem izrade programa koje je lakše napraviti i održavati. Daje odgovor da li je centralizirana ili distribuirana obrada i skladištenje podataka. Dizajn sistema daje odgovor kako sistem treba izgraditi ili kakav sistem treba biti. brzi razvoj aplikacija (RAD) i objektno usmjereni dizajn. 2. Oblikovanje (dizajn) sistema Analiza sistema treba da dâ odgovor šta sistem mora da raditi. Opšti dizajn sistema Opšti (konceptualni) dizajn daje funkcionalne specifikacije i omogućava odabir tehničke arhitekture sistema. odnosno tehničku specifikaciju sistema. objektni). Starije varijante su oblikovanje programa sa vrha nadolje (top-down program design) i strukturirano programiranje.1. Jaroslav: Projektovanje informacionih sistema 151 9. 9. 3. rad .Poliščuk E. postrelacioni. ako pretvaranje nije ranije učinjeno. elastičan i prilagodljiv. koju sačinjavaju: 1. način izvršenja i koje se tehnologije koriste. zajednički dizajn aplikacija (JAD). radne stanice. Fizički procesi su: serveri. šta predstavlja fizički dizajn.

Ovakav pristup postavlja velike zahtjeve za ljudskim resursima. Dizajn računarske mreže. Ovakav pristup je moguć kod velikih IS koji se daju rastaviti. Opšti dizajn interfejsa se odnosi na poboljšanje izgleda (ergonomija). a sadrži problem koordinacije izvođača. određivanje fizičkih parametara (volumetrija). Fazni pristup se sastoji u podjeli na podsisteme. uz razvoj i postupnu integraciju aplikacija. 9. 4. Izrada procedura za provjeru ispravnosti i konverziju sistema predstavlja posljednju fazu detaljnog dizajna. Definisanje prava pristupa logičkih grupa korisnika.152 Poliščuk E. Prototipski razvoj detalja dizajna je najprihvatljiviji. dok su fizička skladišta: baze podataka. postojećim. Sadrži izradu fizičkog modela podataka. Proces (logički) ili skup procesa može da se nalazi u jednom ili više programskih modula. Javlja se problem rastavljanja i povezivanja podsistema. 9. odnosno izradu sheme baze podataka. Grupisanje i distribucija obrade na različite lokacije. Izrada planova konverzije i instalacije predstavlja posljednju fazu definisanja opštog dizajna. povezivanje sa drugim. Detaljni dizajn sistema Detaljni dizajn su tehničke specifikacije sistema.3. 3.1. na početku razvoja.2. Dizajn interfejsa sadrži dizajn interfejsa sistema (protokoli pristupa i razmjene podataka). Pristupi oblikovanju i razvoju Pristup oblikovanju i razvoju sistema može biti cjelovit. odnosno pretvaranje logičkog modela podataka u fizički model podataka za odabrani SUBP. te je potrebno određivanje veza između modula (standardno strukturnim kartama). 2. Dizajn programa je utvrđivanje strukture programa na osnovu modela procesa. “frontalni”) razvoj cijelog IS. kao i oblikovanje ekranskih formi i izvještaja. U dizajn programa ulazi i preciziranje programske logike. tabele (relacije) i datoteke. Izrada sheme BP podrazumjeva prilagođavanje modela podataka mogućnostima i ograničenjima SUBP. uz kasniju integraciju. Jaroslav: Projektovanje informacionih sistema koji treba obaviti. nezavisnom razvoju pojedinih podsistema. ugađanje baze podataka i oblikovanje fizičkih datoteka.1. . sistemima. istovremeni (tzv. Optimalno rješenje je izrada jedinstvenog modela podataka.

Specifikacija hardvera i softvera je podloga za nabavku opreme. u prvom redu računarsku opremu. sistem zaštite i globalnu podršku aplikacija.2. Jaroslav: Projektovanje informacionih sistema 153 9. Distribuirana prezentacija mreža Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mreža Distribuirani podaci i logika (3-slojna) mreža Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mreža Podaci na serveru BP Sigurni Intranet provajder za pristup podacima.2. Arhitektura informacionog sistema 9. programsku podršku.1. Primjeri arhitekture sistema.Poliščuk E.1. logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zaštitu aplikacija i podataka mreža Korisnički interfejs na PC klijentu Korisnički interfejs na PC klijentu Podaci i procesi BP na serveru Logika i korisnički interfejs na PC Unutrašnji korisnički interfejs na PC Sigurna konekcija na server BP Konekcija na spoljnji svijet Dio logike na Internet serveru Internet provajder konekcija za pristup interfejsu i dijelu logike Vanjski korisnik PC klijent Slika 9. komunikacije. . Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema.

koja se sastoji u zamjeni znakovnog interfejsa grafičkim interfejsom. • klijent-server (client-server based) – kombinacija prethodne dvije. • mali računari (Minicomputer). personalni računari (PC). 9.2. Primjer centralizovane obrade. Produžava se vijek starih aplikacija. odnosno slojevi arhitekture. Ova zamjena se. • klijentski (client-based) – obrada se obavlja na personalnom računaru.154 Poliščuk E. ansi. Na slici 9. Jaroslav: Projektovanje informacionih sistema Uobičajeni modeli arhitekture su: • serverski (server-based) – obrada se obavlja na serveru. njihove fizičke lokacije i način njihovog međusobnog povezivanja. Centralizovana obrada podataka Centralizovana obrada (slika 9. Model mreže sadrži prikaz glavnih komponenti sistema. Ovom arhitekturom je omogućeno skladištenje podataka (datoteke i baze podatka). Prezentaciona logika Aplikaciona logika Logika pristupa podacima Skladištenje podataka . ali se funkcionalnost ne može značajno poboljšati. Klijenti su klasični terminali (npr. uglavnom.2. Internet kiosci. pristupom podacima (data access logic). su određeni pohranom podataka (data storage). korisnički interfejs (uobičajeno znakovni interfejs) i interfejs sistema (mrežne i druge komponente). elementima obrade (application logic) i interfejsom (presentation logic).2) se ostvaruje sa višekorisničkim računarom (mainframe. ručni računari i sl. koji omogućavaju pristup terminal emulatorima ili udaljenim radnim plohama. Funkcije sistema. izvodi na personalnim računarima. poslovna logika (programska podrška).2. Distribuirana prezentacija je proizvoljna nadogradnja centralnih aplikacija. Tu spadaju i terminali posebne namjene. kao što su bančini terminali (bankomati). • mikroračunari (Microcomputer). vt220) i mikroračunari (PC). Serveri mogu biti: • veliki računari (Mainframe). Klijent (terminal) Server Host (mainframe računar) Slika 9.1 su prikazani primjeri arhitekture IS. minicomputer) i terminalima.

2.3. veća samostalnost klijenta i rasterećenje glavnog računara (servera). Debeli klijent je onaj klijent kod koga je integrisana logika podataka. obradu podataka i servisiranje interfejsa. Dvoslojna arhitektura klijent-server. Prednosti debelog klijenta su: brzi početni razvoj aplikacije. Dvoslojna arhitektura klijent-server Klijent je jednokorisnički računar. Nema obrade podataka na serveru ili je obrada minimalna. Jaroslav: Projektovanje informacionih sistema 155 9. Posjeduje mogućnost povezivanja na servere (prema potrebi i na druge klijente).3) su u izolaciji promjena u pojedinom sloju. Kao debeli klijenti mogu se koristiti jeftini računari sa snažnim procesorima. Promjena poslovne logike znači . Nedostatak je da je poslovna logika integrisana na klijentu. Omogućava rad sa dijeljenom bazom podataka. Nedostak ove arhitekture je u otežanom održavanju aplikacione logike (programa) na svim klijentima i pojava „debelog klijenta”. kvalitetnijoj (lakšoj) obradi i središnjem upravljanju integritetom podataka na serveru. Korisnicima izgleda kao da jedan računar obavlja cijeli posao. Može imati lokalnu bazu podataka. Server je višekorisnički računar. Prednosti dvoslojne arhitekture klijent-server (slika 9.Poliščuk E. Klijent (mikroračunar) Server (mikroračunar) Prezentaciona logika Aplikaciona logika Logika pristupa podacima Klijent (mikroračunar) Skladištenje podataka Server (mikroračunar. Posjeduje minimalnu ili nikakvu elastičnost na promjenu poslovne politike. Sadrži interfejs. mali računar ili veliki računar) Prezentaciona logika Aplikaciona logika Logika skladištenja podataka Skladištenje podataka Slika 9.3. Posjeduje mogućnost povezivanja sa klijentima i drugim serverima. a omogućava obradu i skladištenje podataka.

4. a to znači skupi glavni računar. Prednosti troslojne arhitekture su: bolja raspodjela opterećenja. Kao tanki klijent može se koristiti npr.156 Poliščuk E. Razvoj velike aplikacije sa vremenom postaje vrlo kompleksan (sav programski kod je na klijentu). Kod na bazi podataka (stored procedure). Jaroslav: Projektovanje informacionih sistema instalisanje nove verzije aplikacije na svim klijentima. Manja je kompleksnost razvoja velikih aplikacija (kod je podijeljen na serverski dio i klijentski dio).formi (GUI . Takođe sadrži dio poslovne logike.Data Access Layer). 3. Troslojna i višeslojna arhitektura klijent-server Kod troslojne arhitekture klijent-server (slika 9. Prednosti tankog klijenta su: promjena poslovne logike ne znači obavezno i promjenu u klijentskom dijelu aplikacije. Nedostaci su: složeni (komplikovani) dizajn i razvoj. veća skalabilnost. 9. računari ne moraju imati veliku procesorsku snagu. Višeslojna arhitektura se koristi za razvoj složenih aplikacija. Velika je mogućnost rada sa zastarjelim podacima. npr. Namjena pojedinog sloja je slijedeća: 1. web pretraživač (dobro definisano i svima dostupno). Većinom se koriste u poslovnim sistemima.4) distribucija baza podataka i poslovne logike je izvršena na zasebne servere. Kod na prezentacionom sloju . Programski kod se može podijeliti u više nivoa. Server aplikacija obavlja upravljanje transakcijama "preuzetih" sa servera podataka. interfejsa. 3. povećanja broja korisnika. ukoliko sa vremenom obrada postane spora (zbog količine podataka) može se jednostavno povećati snaga središnjeg računara.Graphic User Interface). čime je dobijena arhitektura: server aplikacija + server baza podataka + klijent. i to onaj dio koji se ne mijenja. Tanki klijent je onaj klijent kod koga se logika podataka nalazi na serveru. promjena poslovne logike može se obaviti centralizovano. kao i veće opterećenje mreže. problem raspodjele podataka. a tipični primjer tankog klijenta je web pretraživač. procesa. Osnovna namjena tankog klijenta je prikaz podataka.4. treba promijeniti sve klijente. Ukoliko se kao klijent koristi web pretraživač moraju se poštivati njegova ograničenja. 2. Nedostaci su: veliko opterećenje glavnog računara. Dio ili čitava poslovna logika je "preuzeta" sa klijenta. Ako sa vremenom aplikacija postane spora (zbog količine podataka).: 1.Business Logic Layer ). Kod u sloju pristupa podacima (DAL .2. odnosno mogućnost ekspanzije (npr. . Klijent sadrži korisnički interfejs. ili logiku ličnog karaktera. Server baza podataka vrši upravljanje podacima. 2. bez preopterećenja ili potrebe za promjenom procedura). Smanjena je mogućnost rada sa zastarjelim podacima (gotovo za svaku promjenu ide se na server). Kod u sloju poslovne logike (BLL .

Troslojna arhitektura klijent-server.1): Tabela 9.5. 9. web servis) i baza podataka (npr.GUI (u web aplikaciji to je web pretraživač). Podacima bogate aplikacije (pretraživanje i upiti) sa veoma malo ili bez aplikativne obrade. Arhitekture Dvoslojne K/S arhitekture sa tankim klijentima Aplikacije Naslijeđeni aplikativni sistemi gdje je nepraktično i neisplativo odvojiti aplikativne obrade i upravljanje podacima. SQL Server). mogu se primijeniti sljedeći kriterijumi (tabela 9. Klijent (mikroračunar) Server aplikacija (mikroračunar) Server BP (mikroračunar. server aplikacija odnosno BLL (npr.2.Poliščuk E. . mali računar ili veliki računar) Aplikaciona logika Logika pristupa podacima Skladištenje podataka Slika 9.4.1. i to: klijent . Jaroslav: Projektovanje informacionih sistema 157 Često se vrši podjela u tri nivoa. Računarsko-zahtjevne aplikacije sa vrlo malo ili bez obrade podataka. Izbor arhitekture klijent-server Izbor arhitekture može zavisiti o raspoloživim računarima i mrežnoj infrastrukturi. mali računar ili veliki računar) Prezentaciona logika Klijent (mikroračunar) Aplikaciona logika Logika pristupa podacima Skladištenje podataka Web server (mikroračunar) Prezentaciona logika Server aplikacija (mikroračunar) Aplikaciona logika Server BP (mikroračunar. Općenito.

vršenje osnovnih provjera unijetih podataka. u programskom jeziku Visual C (C#).5: 1. Na debelom klijentu treba promijeniti SQL upite u izvornom kodu. Rješenje sa debelim klijentom glasi: na klijentu napraviti SQL upit kojim se obuhvataju podaci o zadnjih 20 narudžbi. Ovaj sloj sačinjavaju HTML. Jaroslav: Projektovanje informacionih sistema Aplikacije gdje se aplikativna obrada izvodi na klijentu sa COTS (Commercial Off-The Shelf Software) programskom podrškom. slika 9. Prezentacioni sloj se može generisati generatorom koda npr. Usput računati zbirne vrijednosti. • nazive artikala. • treba prikazivati zadnjih 20 narudžbi. 2005]: • kupce.158 Dvoslojne K/S arhitekture sa debelim klijentima Poliščuk E. korištene u okolini gdje je dobro uspostavljeno upravljanje sistemom. Sistemi u kojima su i podaci i aplikacije promjenljivi. jediničnu cijenu i količinu za pojedinu narudžbu. Troslojne ili višeslojne K/S arhitekture Primjer 1: Sa arhitekturom klijent-server potrebno je napraviti aplikaciju koja će prikazivati [Fertalj & Kalpić. na klijentu napraviti SQL upit kojim se obuhvataju detalji za zadnjih 20 narudžbi. klijent-server skriptovanje. predomislio i želi da se prikazuje zadnjih 50 narudžbi. Rješenje sa tankim klijentom je: na klijentu pozvati stored proceduru koja vraća podatke o zadnjih 20 narudžbi. Aplikacije u kojima se integrišu podaci iz višestrukih izvora. njihovo slanje sloju poslovne logike. kad se promjeni narudžba proći kroz sve detalje i ispisati one koje pripadaju trenutnoj narudžbi. prodavače i datume narudžbi. Ispunjenje promjene zahtjeva se sastoji u slijedećem. Aplikacije sa relativno čvrstom krajnje . Visual Studio. Prezentacioni sloj GUI. ActiveX kontrole. vizualizacija podataka – interaktivno ili u izvještajima). kad se promjeni trenutna narudžba pozvati stored proceduru koja vraća detalje trenutne narudžbe i zbirne vrijednosti.NET 2003. Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudžbi (brzo. itd. koji služi za prikupljanje informacija od korisnika. Aplikacije velikog opsega sa stotinama ili hiljadama klijenata. naravno. Aplikacije koje zahtjevaju računarsko zahtjevne obrade podataka (npr. Win32 aplikacije. prevesti ga u novu izvršnu opciju te dostaviti aplikaciju korisnicima (sporo i skupo). • ukupnu količinu i ukupnu vrijednost narudžbe. Java apleti. manje od pet minuta.korisničkom funkcionalno-šću. Primjer 2: Promjene zahtjeva navedenih u primjeru 1: korisnik se nakon mjesec dana rada aplikacije. Primjer 3: Rješenje razmatranog primjera u višeslojnoj arhitekturi sadrži slijedeće nivoe. DHTML. primanje rezultata od sloja poslovne logike i prezentaciju dobijenih rezultata korisniku u razumljivom formatu. i jeftino). .

U razmatranom primjeru treba konstruisati b-klasu i ispisati podatke u gridu. Sloj pristupa podacima DAL se može generisati generatorom koda npr. Sloj pristupa podacima DAL.5.Poliščuk E. u programskom jeziku C#. Tok izrade aplikacije u višeslojnoj arhitekturi je slijedeći. . Jaroslav: Projektovanje informacionih sistema 159 2. Nakon toga se okine event. Ovi servisi su čvrsto integrisani jedan sa drugim i sa OS i dostupni su preko komponentnog modula (COM+). pronalaženje i održavanje podataka. mail. // Postavi DataSource na oba grida 1. 3. obično. koji direktno ostvaruje interakciju sa podacima koji. Pristup podacima preko Windows DNA se naziva Universal Data Access (UDA). txt Osnovni servisi Slika 9. U konstruktoru b-klase se učitavaju podaci o narudžbama. egzistiraju u BP kao što su SQL Server ili ORACLE. koji se zovu OLE-DB. System. interakciju sa slojem za pristup podacima radi procesiranja podataka i slanje obrađenih informacija prezentacionom sloju. u programskom jeziku C#. Ovaj sloj služi za smještanje. asinhrone i servise redova. File system. Visual Studio. Prema pravilima višeslojnog programiranja na prezentacionom sloju (formi) koristi se sloj poslovne logike (b-klasa).EventArgs e){ // Konstruisi bklasu _bLastOrders = new BLastOrders(_connectionString).NET 2003. kao i za integritet podataka. LLBLGen. COM+ Prezentacioni sloj DHTML. transakcione i servise komponenti. Web servise. Sloj poslovne logike BLL. ADO i RDO. na kojem se prikazuju podatci o detaljima narudžbi.NET 2003 u programskom jeziku C#). Ovaj sloj obezbjeđuje poslovna pravila i servise koji pomažu tokom pisanja skalabilnih aplikacija (npr. Prezentacioni sloj GUI (generator koda Visual Studio. Forme Sistemski servisi Administracija Mrežni servisi Sloj poslovne logike Alati Zaštita Web server IIS Transakcije MTS Sloj pristupa podacima DBMS. Arhitektura Windows DNA (Distributed interNet Aplication architecture). Sloj poslovne logike BLL se može generisati generatorom koda npr. Programski kod glasi: private void FormLastOrders_Load(object sender. serverska skriptovanja). koji je namjenjen za primanje podataka od prezentacionog sloja. UDA je skup modela sistemskog i aplikacionog nivoa.

Ta metoda dohvata detalje neke narudžbe. a sve veće obrade i rad sa bazom moraju se odvijati u b-klasi. Programski kod glasi: private void dataGridOrders_CurrentCellChanged(object sender. Jaroslav: Projektovanje informacionih sistema dataGridOrders. e). Sloj poslovne logike treba pažljivo definisati. textBoxTotalQuantity.160 Poliščuk E. Programski kod glasi: public BLastOrders(string connectionString) { // Konstruiranje adaptera za pristup bazi podataka _dataAccessAdapter = new DataAccessAdapter(connectionString). 0])). Biće naveden primjer konstruktora u b-klasi (sloju poslovne logike). tako da GUI služi samo za prikazivanje podataka.NET 2003 u programskom jeziku C#). // Ispiši detalje trenutno selektirane narudžbe dataGridOrders_CurrentCellChanged(sender. // Definiranje EntityCollection-a za detalje narudžbe .OrderDetailsEntityCollection. U razmatranom primjeru uz bklasu postoji i sloj pristupa podacima (DAL) prije same baze podataka. To se radi tako da se pozove pripadajuća metoda u b-klasi (SelectOrderDetails). System. } Kod promjene selektirane narudžbe treba osvježiti podatke o detaljima. U b-klase se intenzivno koristi DAL.TotalQuantity.SelectOrderDetails(Convert. dataGridOrderDetalis. SelectLastOrders(). a iz priloženog koda se vidi da je programiranje znatno jednostavnije nego upotrebom SQL upita.ToString().ToString("C"). // Definiranje EntityCollection-a za narudžbe _ordersEntityCollection = new EntityCollection(new OrdersEntityFactory()).EventArgs e) { // Dohvati podatke o trenutno selektiranoj narudžbi _bLastOrders. // Ispiši zbirne podatke na formu textBoxTotalPrice. } 2.DataSource = bLastOrders.CurrentRowIndex. a usput računa i zbirne podatke (ti podaci su dostupni preko property-a b-klase).Text = _bLastOrders.DataSource = _bLastOrders.TotalPrice.Text = _bLastOrders. Sloj poslovne logike BLL (generator koda Visual Studio.ToInt32(dataGridOrde rs[ dataGridOrders.OrdersEntityCollection.

} 3. manja mogućnost greške. kao i preglednost koda. Na sličan način bi se riješio i dohvat detalja pojedine narudžbe. Programski kod glasi: public EntityCollection SelectLastOrders() { // Isprazni trenutni sadržaj _ordersEntityCollection. null. // Dohvat podataka iz baze (uz korištenje sortera i dodatnih staza za dohvat) _dataAccessAdapter. u praksi ima mnoge prednosti u odnosu na pisanje SQL upita. • Programski kod se generiše pomoću generatora koda. Radi se o primjeru pristupa bazi podataka preko objekata. • Ovaj sloj služi za pristup bazi podataka (DAL). Prednosti rješenja upotrebom generatora programskog koda: mogućnost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a).Create(OrdersFieldIndex. path). path. path. itd. nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka.objekti za pristup bazi koji su isti za sve baze i DALDBSpecific . 20. mogućnost promjene baze podataka.OrdersEntity). . // Vrati podatke dohvaćene iz baze return _ordersEntityCollection.Clear(). } Navedeni primjer sa dohvatom zadnjih 20 narudžbi u b-klasi se može promjeniti da se dohvati zadnjih 50 narudžbi.PrefetchPathEmployees). Sloj pristupa podacima DAL (generator koda LLBLGen u programskom jeziku C#). Mada se ne čini jednostavnim.Add(OrdersEntity. sorter.FetchEntityCollection(_ordersEntityCollec tion. Osnovna prednost je manja mogućnost greške. • DAL se u ovom primjeru dijeli na dva dijela: DALGeneric .PrefetchPathCustomers). // Narudžbe treba sortirati prema datumu unatrag ISortExpression sorter = new SortExpression( SortClauseFactory.objekti za pristup bazi koji su specifični za pojedine baze podataka.Descending)). // Definisanje dodatnih staza za dohvat podataka (treba dohvatiti podatke o kupcima i radnicima) IPrefetchPath2 path = new PrefetchPath2((int)EntityType. SortOperator.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 161 _orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory()).Add(OrdersEntity.OrderDate.

koje su nezamjenljive kod obrade poslovnih podataka. pohranjene procedure (stored procedures). stranog ključa i opisnih polja.1. dinamički skupovi podataka (cursor). 2006]. korisnički definisani tipovi podataka i funkcije. dovođenje modela u određeni normalizovani oblik (NO). . okidači .162 Poliščuk E. 9i Developer Microsoft InterSystems Corp.1. Takođe. odnosno tehnika organizovanosti atributa. sekundarnog ključa.1.. tehnički nacrt). obuhvata određivanje primarnog ključa. efikasno rukovanje podacima. normalizacija. . u prvom redu. obuhvata izradu sheme baze podataka (fizički model. kao i prevođenje modela podataka u strukture podržane odabranom tehnologijom (SUBP).trigeri (triggers). O zastupljenosti pojedinih tipova baza podataka za komercijalnu upotrebu. Relacione BP. Jaroslav: Projektovanje informacionih sistema 10.konzistentnost i integritet podataka. Tabela 10. IBM McObject FileMaker Microsoft IBM Matisse Software Objectivity Revelation Software Oracle License DB Type Commercial Relational Commercial Post-relational Commercial Relational Commercial Navigational Commercial FileMaker Commercial Relational Commercial Relational Commercial Object-oriented Commercial Object-oriented Commercial Multi-valued Commercial Relational .. Uvod u dizajn baza podataka Dizajn baza podataka. karakterišu slijedeći koncepti: strukturirani upitni jezik (SQL). najbolje govori tabela 10. Prednosti baza podataka su: pouzdanost . Product Access 2002 Cache DB2 eXtremeDB FileMaker FoxPro Informix Matisse Objectivity/DB OpenInsight Oracle 8i. [Internet. 3NO ili viši NO. prilagodljivost na promjene zahtjeva i skalabilnost. Dizajn baza podataka 10. Analizu podataka sačinjavaju priprema modela podataka za ugradnju.

ne može za atribut imati neku drugu relaciju. prost ili složen. Većina dizajnera se zaustavlja na 3NO ili na BCNO (Boyce-Codd NO). ako je u drugom. Commercial Relational Commercial Relational Commercial Nested relational Commercial Nested relational Commercial Object-oriented 10. Z) je u četvrtom normalizovanom obliku ako postojanje netrivijalne višeznačne zavisnosti X →→ Y uslovljava postojanje funkcionalne zavisnosti X → A za svaki atribut A relacije R. b) Relacija R je u prvom normalizovanom obliku ako je bilo koji podskup neprimarnih atributa funkcionalno zavisan od ključa.2. Relacija R (X. Informatičkim žargonom rečeno. ako je u prvom. od koga neki drugi atribut potpuno funkcionalno zavisi. c) Relacija R je u prvom normalizovanom obliku ako između kandidata za ključ i ostalih neprimarnih atributa postoje slijedeći tipovi preslikavanja: 1:1. Stepen normalizacije (normalizovani oblici) se povećava od 1NO do 5NO. 1989]: . Determinanta je svaki atribut. Jaroslav: Projektovanje informacionih sistema 163 SQL Server 2000 Sybase ASE 12. je postupak strukturiranja sheme relacione baze podataka tako da se ukloni što više neodređenosti (nekonzistentnosti).Poliščuk E. i ako svi njeni neprimarni atributi potpuno funkcionalno zavise od svih kandidata za ključeve. Relacija u 1NO ne može opisivati entitete ili veze u sistemu koji imaju višeznačne atribute. C:1 i C:M. "relacione zakletve" [Finkelstein. Y. Relacija R je u BCNO ako je svaka determinanta kandidat za ključ. normalizacija se svodi na ispunjenje tzv. Relacija R je u petom normalizovanom obliku ako i samo ako se svaka zavisnost spajanja u relaciji R može pripisati kandidatu za ključ. Relacija R je u trećem normalizovanom obliku. Formalne definicije normalizovanih oblika glase: a) Relacija R je u prvom normalizovanom obliku ako svi njeni atributi imaju samo "atomske" vrijednosti. odnosno tehnika organizovanosti atributa.5 UniData UniVerse Versant enJin Microsoft Sybase IBM IBM Versant Corp. Relacija R je u drugom normalizovanom obliku. 1:M. i ako ne sadrži tranzitivne zavisnosti neprimarnih atributa od kandidata za ključ. Normalizacija Normalizacija.

• ništa drugo nego ključ .1NO: nema ponavljajućih grupa. 2.164 Poliščuk E. definisan primarni ključ. Generisanje programskog koda okidača (trigera). Denormalizacija se svodi na ograničeno i kontrolisano narušavanje NO. Automatizovano dodjeljivanje stvarnih tipova podataka konkretnog SUBP.3NF: svaki neključni atribut je neposredno zavisan samo o PK.3. Denormalizacija Zamjenici (surogati) ključeva su ključevi sa samopovećavajućim vrijednostima (serial). 4. Primjer 2: Drzava 1:N Mjesto 1:N Osoba. Prevođenje modela i normalizacija uporabom CASE alata se odvija slijedećim redoslijedom: 1. koji se umeću ispred ključa sastavljenog od većeg broja atributa (npr. zbog poboljšanja elastičnosti i poboljšanja performansi. Primjer 1: @IdRadnogMjesta = @IdOrgJedinice... @DatZaposlenja. ≥ 3). Prije početka kodiranja obavlja se ograničeno uvođenje konzistentnosti i ugađanje baze podataka. . 3. Teorijski se ne preporučuje za asocijativne entitete. 6.. Praktično. @IdMjesta. • BCNO: svi atributi koji određuju druge atribute čine moguće ključeve. Jaroslav: Projektovanje informacionih sistema • ključ . . odnosno veza na tabele koje nisu uključene u generisanje modela.. Većina CASE alata normalizira u 1NO: zamjena veza više-prema-više asocijativnim entitetima i zamjena višeznačnih atributa entitetima. @IdZanimanja RadnoMjesto = @IdRadnogMjesta Zaposlenje = @IdOsobe. zamjenika ključa treba ugraditi kada je relacija (tabela) u koju se ugrađuje referensirana iz drugih relacija. @IdRadnogMjesta. 10. koji naslijeđuju ključeve svojih roditelja.2NO: svi neključni atributi u potpunosti zavisni o čitavom PK. jer se time gubi smisao identifikacione veze. Stvaranje relacija (tabela) za entitete nadtipa i podtipa. Na originalni ključ postavlja se jednoznačan (unique) kompozitni indeks. pri čemu je Mjesto = @IdDrzave. • cijeli ključ . gdje zahvat može rezultirati u logički model određenim brojem intervencija. Automatizovana migracija ključa i prepoznavanje tzv. Viši normalizovani oblici: problem prepoznavanja djelomičnih i tranzitivnih zavisnosti. visećih veza (dangling relationships). . 5. a to nije u suprotnosti sa poželjnim redundantnim vezama. . .

Dodavanje atributa čuvanja može biti za redundantne vrijednosti koje se inače dobijaju složenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje školovanje) ili dodavanje atributa kao što su zastavice za "trajno" označavanje zapisa. To mogu biti atributi čuvanja za izvedenu vrijednost koja se može izračunati agregiranom funkcijom (npr. i dolazi do gubitka izvorne vrijednosti stranog ključa. pod uslovom da su slične strukture i sadržaja. tj.not null). Kod referencijalnog integriteta mora postojati vrijednost stranog ključa (mandatory .4. Uvođenje konzistentnosti je dodavanje atributa za čuvanje izvedenih vrijednosti. stanje skladišta. obuhvata entitetski integritet i referencijalni integritet. obavezni unos (not null) stranog ključa i provjeru postojanja referensirane torke pri unosu. zamjenik postaje primarni a originalni postaje alternativni ključ. Jaroslav: Projektovanje informacionih sistema 165 “Čisti dizajn” je dosljedna ugradnja zamjenika ključa sa samopovećavajućim vrijednostima u sve tabele (relacije) baze podataka. ažuriranje odgovarajućih vrijednosti stranih ključeva (set null) i postavljanje na standardnu vrijednost (set default). Ugradnja referencijalnog integriteta može biti različita. Udruživanje relacija je uklanjanje pojedinih relacija stapanjem atributa obične veze 1:1 ili udruživanje nadtipa sa podtipovima kardinalnosti 1:1. npr: . strani ključ se smije postaviti na nul-vrijednost (optional null). Neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI . 10.Direct Referential Integrity). Entitetski integritet se ostvaruje postavljanjem primarnog ključa. Dijeljenje relacija je smještanje rijetko korištenih atributa u posebnu relaciju. Pravila referencijalnog integriteta. ažuriranja i brisanja roditelja ili djeteta i odnose se na: zabranu (restrict). nedefinisanog stranog ključa (null). ili kaskadnu obradu torki koje referensiraju roditelja koji se ažurira ili briše. su postupci prilikom unosa. a svodi se na restrikciju pri unosu. domenski integritet se ostvaruje postavljanjem ograničenja na skup vrijednosti.Poliščuk E. čime se pojednostavljuje ugradnja. Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nužno i na takav način da ne ugrožava integritet podataka. postojanje opcionog. dok se referencijalni integritet ostvaruje postavljanjem stranog ključa i ograničenja na unos. brisanje torki koje imaju odgovarajuću vrijednost stranog ključa (cascade). odnosno aplikativno upravljanje integritetom. stvaranjem objekata u rječniku BP. iznos računa kao suma iznosa stavki) ili oznake zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u relaciji sa velikim brojem zapisa (torki). tj. a alternativni ključevi su sa obaveznim atributima i jedinstvenim indeksima. za opšti slučaj. Dolazi do umnožavanja ključeva. Ugradnja pravila za očuvanje integriteta Očuvanje integriteta. npr.

naročito kod hibridnih sistema (4GL + GUI). CHECK_CONSTR). Grupni indeks (CLUSTERED INDEX). Javlja se problem umnožavanja programskog koda. da bi se referencijalni integritet očuvao u svim dijelovima baze podataka. 3.166 Poliščuk E.. Indeksi nad stranim ključem (ubrzanje provjere integriteta i spojnih upita).. Postupak kaskadnog ažuriranja ili brisanja torki treba provesti rekurzivno. Neki sistemi implicitno kreiraju indekse za primarne i strane ključeve. tj poljima koja se koriste za grupisanje. Jaroslav: Projektovanje informacionih sistema [ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ]. Upravljanje referensijalnim integritetom okidačima (triggers) je elastičniji pristup. Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa! Potrebno je ukloniti indekse prilikom masovnih obrada podataka. Jedinstveni indeksi nad primarnim i alternativnim ključevima (integritet).6). Preporučuje se koristiti naredbe i opcije za uvoz podataka (BULK INSERT . Neki atribut stranog ključa može biti primarni atribut. Mogući problemi su višestruki. pretraživanje će raditi brzo.. Podešavanje baze podataka Postavljanje indeksa se vrši radi osiguranja integriteta podataka i ubrzanja dobijanja podataka. Prilikom ažuriranja stranog atributa koji je ujedno i primarni atribut ne smije se narušiti jedinstvena vrijednost ključa. Indeksi nad najčešće korištenim poljima. . Postavlja se pitanje da li treba kreirati indekse u relacijama sa malim brojem podataka. Koriste se slijedeće preporuke za postavljanje indeksa.5. koji omogućava ugradnju i ostalih postupaka prilikom unosa/izmjene/ brisanja torki (vidjeti tačku 10. 4. faktor popunjenosti (FILL FACTOR). Aplikaciono upravljanje integritetom su postupci unosa/izmjene/brisanja podržani programskim kodom. a ne samo na mjestu obrade. sortiranje ili selekciju uz uslov (ubrzanje pretraživanja). Pokušaj ažuriranja na nul-vrijednost stranog ključa koji je dio primarnog ključa u suprotnosti je sa pravilom entitetskog integriteta. 10. . uglavnom po prvom polju. u tom slučaju ne treba posebno kreirati indekse. Ako su ključevi složeni. sa tim da neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI) ima prednost. 5. Promjene podataka uzrokuju ažuriranje indeksa. 2. . Uopšteno.. Mješovito upravljanje referencijalnim integritetom je kombinacija navedenih mogućnosti. a po potrebi postaviti dodatne indekse nad preostalim poljima. Indeksi treba da su: 1.

• dnevnici (audit. OPTION (FAST n_rows). gdje su strana polja posebne vrijednosti u šifrarnicima. Punjenje baze podataka se vrši različitim vrstama datoteka/relacija.. Jaroslav: Projektovanje informacionih sistema 167 Minimizaciji nul-vrijednosti treba posvetiti nužnu pažnju. • arhivske. WITH (INDEX(index. • primoravanje nekorištenja indeksa primjenom neškodljive funkcije nad poljem nad kojim se uobičajeno koristi indeks. SELECT . WHERE NULLIF ( polje. Racun. odnosno kopije istorijskih podataka za lakši dohvat i pregled bez regenerisanja dokumenata. predstavljaju zapise poslovnih događaja sa ograničenim vijekom. SELECT . zapisa i/ili polja u različite fizičke BP ili različite fizičke segmente BP.. a uklanjanje zapisa se vrši uz arhiviranje.. Fizičku raspodjelu podataka određuju faktor blokiranja (blocking factor). ..)). a može se mijenjati. Mjesto (poštanski brojevi). StatusNecega. npr. SELECT AVG(polje). problem operacija sa nulvrijednostima. zapisa i/ili polja u različite fizičke BP. koje su uklonjene iz medija za direktni (on-line) pristup. gdje polje ima/nema nulvrijednosti. npr. koga određuje broj logičkih zapisa koji se obrađuju jednim čitanjem (fizički zapis). log). index. Kupac. Predmet. npr. npr. Replikacija podataka predstavlja umnožavanje relacija. Ovaj faktor uobičajeno je određen i automatski podešen.. replikacija šifarnika između baze podataka na serveru i BP debelog klijenta. 0-nepoznata vrijednost. Može se pojaviti problem neodređenih vrijednosti agregatnih funkcija. Prijavnica. odvajanje matičnih datoteka i šifarnika od transakcionih relacija. OPTION (FORCE ORDER). npr.. • šifarnici. “” ) = . koje mogu biti: • matične. • transakcione (prometne).Poliščuk E. OrgJedinica. Distribucija podataka je raspodjela pojedinih relacija. npr. npr. . npr. • ostale opcije. • dokumentacione. gdje opisna polja mogu da sadrže zahtijevanu vrijednost + pretpostavljenu vrijednost. npr. ali se može i ručno podešavati. npr.. odnosno statički podaci koji se koriste od različitih aplikacija radi očuvanja konzistentnosti podataka i poboljšanja performansi.. npr.. Artikl. Može se pojaviti problem vanjskih spojnih upita. • primoravanje korištenja određenog indeksa. koji predstavljaju evidenciju pristupa i promjena podataka.. 999-nepostojeća vrijednost. SELECT . Ubrzanje upita omogućava: • analiza plana izvođenja (Execution Plan) i odabir poželjnog plana. gdje dodani zapis ostaje “zauvijek” u sistemu.

mogu se definisati veličine polja. Svako polje ima određenu veličinu..mdf E:\. U relacionom upitnom jeziku SQL (PL/SQL) takvi postupci se zovu trigeri (okidači)...log F:\. Ekranska forma. Svako polje se može postaviti pojedinačno ili se može pozvati automatski uslovni blok generatora aplikacija. Trigeri u relacionim bazama podataka 10. kakav je ORACLE/Designer-a 2000. Primjer: Dvije fizičke jedinice. Umjesto da se pišu programi.exe D:\. Generator aplikacija sadrži tri nivoa dizajniranja ekranske forme: • Prvi nivo predstavlja kreiranje blokova i polja.. ažuriranje i brisanje podataka. definišu se automatski postupci koji se izvršavaju nakon obavljanja radnji unošenja. a kao rezultat se dobije prototip aplikacije.168 Poliščuk E. U sastavu savremenih SUBP. Jaroslav: Projektovanje informacionih sistema Smještaj fizičkih datoteka obezbjeđuje povećanje sigurnosti i brzine pristupa odvajanjem SUBP.. pretraživanje.\log\*. . postavlja polja i vrši provjere učinjenog. Na ovaj način zadane instrukcije se kombinuju sa mogućnostima SUBP. u cilju očuvanja uslova integriteta. uslovne vrijednosti ili pomoćne poruke. • Treći nivo predstavlja definisanje trigera (okidača).\data\*.\binn\MSSQL. koja se dizajnira pomoću generatora aplikacija. Unutar bloka.\backup\* 10.. Korisnik određuje složenost dizajnirane forme i ima potpunu slobodu da izabere blokove. U okviru bloka postoje polja.1. Najjednostavnija forma predstavlja prozore na osnovne relacije. slog prikazuje jedan zapis (torku) osnovne relacije. Na primjer. Uvod U relacionim bazama podataka. prostora za podatke.. • Drugi nivo predstavlja definisanje blokova i polja. Na formi se mogu dodavati osnovne provjere ili uputstva za pružanje pomoći. poziciju i tip podatka. koji se u njega unosi. brisanja i ažuriranja podataka u relacijama. se sastoji od blokova i svaki blok odgovara jednoj relaciji BP. najčešće u cilju očuvanja uslova integriteta. četiri logičke podjele: C:\. nalaze se generatori aplikacija (Generate Module/Forms). Ovo je najnapredniji nivo i mogu se napraviti složene provjere i asistencije pisanjem kratkih SQL programa.6. dovoljno je naznačiti željenu aplikaciju upotrebom jednostavnih ekranskih formi. koji omogućavaju brzi razvoj aplikacija za unošenje. Polja se koriste za prikazivanje. unošenje i uređivanje podataka. prostora za vođenje evidencije i rezervnih kopija na različite fizičke uređaje. kao prazan prostor na formi.6..

unosi ili mijenja broj kupca u formi NARUČIVANJE. Triger može pretraživati ili modifikovati bilo koju relaciju za koju korisnik ima pravo pretraživanja ili modifikovanja. prije i nakon dobijanja sloga.BRKUPCA =:NARUDZBA.NAZIV FROM KUPAC WHERE KUPAC.6. SQL naredbe generatora aplikacija i korisničke izlazne naredbe. se mogu razvrstati u tri vrste. koje se koriste u trigerima. slog ili polje. Pretraživanje. SQL sintaksa dozvoljava trigerima da prenose vrijednosti između relacija i formi. Jaroslav: Projektovanje informacionih sistema 169 10. Makrotriger može biti vezan za funkcionalni taster. kao što su: C. nakon promjene vrijednosti i prije ili poslije prihvatanja unosa. Načini udruživanja trigera Trigeri se mogu udruživati za obavljanje različitih funkcija. Ovaj makrotriger se može izvršavati svaki put kada korisnik pregleda blok NARUDŽBA. tako da korisnik može dobiti slog stavki pritiskom samo na jedan taster. Naredbe. 10. pristupi poljima u relacijama i drugo.3. 2. Te naredbe se mogu kombinovati u jednom trigeru. Razvrstavanje naredbi u trigerima Trigeri se mogu definisati kao skup naredbi koje počinju da se izvršavaju u nekom trenutku rada forme generatora aplikacija. SQL naredbe generatora aplikacija simuliraju akcije funkcionalnih tastera i drugih operacija. Na primjer. ali ne i u jednom koraku. ažuriranja ili brisanja u BP. od kojih svaki korak sadrži jednu naredbu. Korisničkim izlaznim naredbama se mogu vršiti računske radnje na poljima formi. Pascal. 1. 3.BRKUPCA Navedeni triger izvršava naredbu uvijek kada korisnik javlja.Poliščuk E.2. Promjena. 3. pri pokretanju forme ili ulaska kursora u novi blok. 2. EXEQRY.6. slijedeći makrotriger pomiče kursor na blok ARTIKAL i izvršava pretraživanje: #EXEMACRO GOBLK ARTIKAL. koje korisnik može izvršavati. slijedeći SQL triger automatski javlja naziv kupca iz relacije KUPAC u polje forme: SELECT NAZIV INTO: NARUDZBA. Udruživanje trigera se može razvrstati u slijedećih pet grupa: 1. Vrste naredbi su SQL naredbe. Svaki triger može biti sastavljen od jednog ili više koraka. Korisničke izlazne naredbe pozivaju korisnikove programe napisane problemski orijentisanim programskim jezicima. Unos. Na primjer. SQL naredbe rade sa podacima iz relacija BP ili iz ekranske forme. COBOL i drugi. .

odnosno kada će se izvršavati. kada su udruženi sa određenim blokom i trigeri na nivou forme. Može se izdvojiti još jedna grupa trigera. će se primjenjivati na svako polje forme. Name (ime): imenovati triger ili upisati tip trigera koji se želi kreirati. Tip trigera važi na nivou u kojem se definiše. poslije sloga. 5. kada su udruženi sa cijelom formom. Trigeri imenovani od korisnika. koji sadrže listu mogućih trigera na tekućem nivou ili listu mogućih trigera za tastere na bilo kojem nivou. bloka ili forme. Na svakom nivou postoje određeni trigeri koji se mogu primjeniti. prije unosa. Trigeri se mogu definisati na tri nivoa forme. kada korisnik pritisne funkcionalni taster.170 Poliščuk E. triger "poslije promjene" definisan na nivou bloka će se primjenjivati na svako polje bloka. Na primjer. Pritisak na taster. prije ažuriranja. kada su udruženi sa određenim poljem. potrebno je: 1. prije brisanja. poslije ažuriranja. poslije brisanja. trigeri za tastere i trigeri imenovani od korisnika. Svaki tip trigera se može definisati na njegovom nivou ili bilo kojem višem nivou. prije sloga. Triger "poslije promjene".4. prije pretraživanja bloka. koji se pozivaju iz drugih trigera. Izlaz. poslije forme. koja se ne odnosi na naprijed navedene slučajeve: 6. odnosno izvršavaće se odmah nakon što korisnik promjeni vrijednost u bilo kojem polju bloka. Na primjer. trigeri za tastere i trigeri imenovani od korisnika. obični trigeri ili podtrigeri. Područje rada trigera je određeno nivoom na kojem je definisan. poslije bloka. uključujući: koji je tip trigera.6. poslije polja. koje naredbe će se izvršavati u svakom koraku i šta će se desiti ako korak uspije ili ne uspije. 33 10. slog ili polje. a ne samo kada korisnik napušta blok. trigeri za tastere i trigeri imenovani od korisnika. Na nivou forme se mogu primjeniti slijedeći trigeri: prije forme. trigeri na nivou bloka. Na nivou bloka se mogu primjeniti slijedeći trigeri: prije bloka. poslije pretraživanja sloga. Jaroslav: Projektovanje informacionih sistema 4. trigeri prihvatanja. Na nivou polja se mogu primjeniti slijedeći trigeri: prije polja. . triger "poslije promjene" se može definisati na nivou polja. i to: trigeri na nivou polja. Optimalni redoslijed definisanja trigera Da bi se trigeri definisali neophodno je navesti njegove korake i vlasništva. U slučaju potrebe dati naredbe TYPES ili KEYS. pri napuštanju forme ili kada kursor napusti blok.. Da se kreira novi triger. poslije promjene. definisan na nivou forme. da se dobiju LIST TYPES ili LIST KEYS prozori.

Poliščuk E. Atributi koraka trigera (korak 5) saopštavaju: šta se dešava kada korak uspije ili ne uspije ili koliko memorije se dodjeljuje korisniku. Reverse return code (obrnuto javljanje): ako je ovaj prekidač izabran. Pomenuti TRIGGER STEP prozor se koristi da se napišu ili promjene koraci trigera. u ovoj rubrici se upisuje oznaka koja to omogućava. 2. SQL naredbe generatora aplikacija ili korisničke izlazne naredbe. potrebno je: 1. 5. Za definisanje atributa koraka trigera (neobavezno). Korak se sastoji od jedne SQL naredbe. Return success when aborting trigger (javi uspjeh kada se prekine triger): ovaj prekidač ima značenje samo ako je izabran i Abort trigger when step fails (prekini triger kada korak ne uspije). koja će se izvršavati u ovom koraku. Poruka ako triger ne uspije: u ovu rubriku se upisuje poruka koja će se prikazati ako korak ne uspije. Abort trigger when step fails (prekini triger kada korak ne uspije): ako je ovaj prekidač odabran. Područje trigera: u ovu rubriku se upisuje SQL naredba ili SQL naredba generatora aplikacija. 4. brisanje trigera ili promjenu njegovog imena. Success and Failure labels (oznake uspjeha i neuspjeha): koraci trigera se normalno izvršavaju u nizu. 2. Seq#: upisati redoslijed za normalno izvršavanje koraka. 3. Jaroslav: Projektovanje informacionih sistema 171 2. 4. 3. a TRIGGER STEP ATTRIBUTES prozor da se kontroliše šta se događa kada korak uspije ili ne. Međutim. Label (oznaka): ako se želi drugačiji pristup koraku u trigeru. neuspjeh koraka će zaustaviti izvršavanje trigera. normalni kriterijum za uspjeh ili neuspjeh se obrće. ali ne uvijek. izvršavaju u nizu. gdje se mogu unijeti naredbe koje treba izvršiti. Separate cursor data area (odvojeni prostor memorije): svakom koraku trigera je dodjeljen vlastiti prostor u radnoj memoriji računara. Kada je izvršeno uspješno definisanje koraka trigera. 5. Za definisanje koraka trigera. a oznaka prekida nije specifirana. mogu se koristiti oznake koraka da se promjeni redoslijed izvršavanja. potrebno je izabrati ATTRIBUTES da se prikaže TRIGGER STEP ATTRIBUTES prozor. koji se obično. Triger se sastoji od serije koraka. . Izabrati CREATE da se prikaže TRIGGER STEP prozor. za dalji rad postoje dvije mogućnosti: da se izvrši dalje pomjeranje u slijedeći korak (NEXT STEP) ili da se kreira novi korak izborom CREATE i ponovi postupak. Definisanje atributa koraka trigera se vrši na slijedeći način: 1. Moguće je izvršiti modifikaciju postojećeg trigera.

Objašnjenje pojmova iz sintakse trigera Određeni pojmovi iz sintakse trigera biće objašnjeni u skladu sa izvršenim razvrstavanjem naredbi u trigerima na: SQL naredbe. Ako je vidljivo. ili ono koje ne odgovara. pozivanje druge forme.172 Poliščuk E. 10. Prema tome.6. Jaroslav: Projektovanje informacionih sistema Određivanje uspjeha i neuspjeha trigera je prilično složeno i zbog ograničenog prostora neće se dalje razmatrati u ovoj knjizi. to može biti polje koje je vidljivo. itd. Može se upotrijebiti sintaksa :(BLOK. U SELECT iskazu se može uključiti izraz INTO da se postave javljene vrijednosti u polja forme. se mogu koristiti samo u koracima trigera i to za: • • • • predefinisanje funkcionalnih tastera. koja omogućavaju vezu sa poljem forme: 1. Svaki SQL iskaz (naredba + pomoćni iskaz) je uključen u jedan korak trigera. Takođe. izvođenja serije akcija na formi bez pritiskanja tastera. 2. vrši računanje sa podacima u formi.(atribut_lista)|:(blok. postavljanje dvotačke (:) u INTO izrazu je nepotrebno. to može biti polje koje korisnik može da modifikuje (dozvoljen unos i/ili dozvoljeno ažuriranje) ili ne. To može biti polje koje odgovara osnovnoj relaciji za blok (polje BP). provjerava da li podaci postoje u BP i provjeravaju podaci u poljima forme. ili ono koje nije vidljivo. mijenja oblik podataka u formi. SQL naredbe u trigerima omogućavaju da se: postave podaci u polja forme. SQL naredbe se zasnivaju na standardnom relacionom upitnom jeziku SQL. za razliku od SQL naredbi koje imaju višestruku upotrebu. Dvotačka (:) označava upućivanje polju forme. SQL naredbe se unose neposredno u TRIGGER STEP prozor.5. SQL naredbe generatora aplikacija i korisničke izlazne naredbe. SQL naredbe generatora aplikacija. Proširena sintaksa SELECT naredbe je: SELECT ((relacija).)polje) FROM relacija_lista (WHERE klauzula) (HAVING klauzula) (GROUP BY klauzula) Podaci se mogu postaviti u bilo koje polje bloka. izvršenje trigera imenovanih od korisnika.)polje|) (INTO (:)(blok. umjesto atributu relacije. koji predstavlja osnovu za rad sa podacima u BP. . ali se može upotrijebiti radi pojašnjenja. SQL naredbe imaju dva proširenja.)POLJE da se izvrši obraćanje polju u formi. Osim toga.

slijedeća naredba u operativnom sistemu UNIX štampa datoteku dat1: #HOST 'lpr -b dat1' Korak trigera može privremeno izaći iz generatora aplikacija u neki drugi napisani program. on izvodi sve funkcije po redoslijedu. Iza naredbe #HOST se stavlja niz naredbi u navodnicima ili ime polja. Akcije mogu biti korisničke funkcije (kao da korisnik pritiska određene tastere). prikažu poruke i izvode druge radnje koje su izvan domašaja SQL naredbi i SQL naredbi generatora aplikacija.BRNARUDZBE GLOBAL. čije ime dolazi iza ključne riječi #ERASE.ID #ERASE naredba se upotrebljava za brisanje vrijednosti globalne varijable. #EXEMACRO naredba se koristi za izvršavanje serije akcija u formi. <Next Set of Record> i <Previous Block> navedenim redoslijedom. naredba: #EXEMACRO NXTBLK. radi kao da je korisnik pritisnuo tastere <Next Block>. Sve SQL naredbe generatora aplikacija počinju znakom #. kontroliše tok aplikacije (npr. Takvi izlazi se mogu koristiti da se obrade podaci iz polja relacija i formi. ili specijalne funkcije koje se mogu izvoditi samo sa trigerima. i to: #EXEMACRO. . NXTSET. Makroserija naredbi se koristi da: olakša korisniku složeno ukucavanje ili često ponavljanje. Jaroslav: Projektovanje informacionih sistema 173 • rad sa varijablama.ID #HOST naredba se koristi u koraku trigera da izvrši neku naredbu operativnog sistema.Poliščuk E. Na primjer.BRNARUDŽBE polja varijabli GLOBAL. #ERASE i #HOST. Kada generator aplikacija izvršava korak trigera koji sadrži makro. Na primjer.ID: #COPY NARUDZBA. Na primjer. Na primjer. Jedan korak trigera uključuje jedan iskaz (naredba + argument ili funkcija). slijedeća naredba dodjeljuje sadržaj NARUDŽBA. I izvorno i željeno mjesto prate ključnu riječ #COPY. i • izvođenje naredbi operativnog sistema. slijedeća naredba briše GLOBAL. SQL naredbe generatora aplikacija se unose neposredno u TRIGGER STEP prozor. usklađivanje slogova iz dva ili više blokova forme). #COPY. globalne varijable ili sistemske varijable sa izvornog na željeno mjesto. PRVBLK. Postoje četiri naredbe koje se mogu koristiti u koracima trigera. osigurava da se neke akcije izvode uvijek u nizu i obezbjedi pomoć (npr. #COPY naredba se može koristiti u koraku trigera da se kopiraju konstante. odnosno varijable koja sadrži niz naredbi. vrijednosti polja.ID varijablu iz prethodnog primjera: #ERASE GLOBAL. pozivanjem druge forme da se pročita traženi podatak).

Kada se napiše program korisničkog izlaza. Generisanje trigera CASE alatima 3 Postupak implementacionog projektovanja jednog trigera baze podataka.1. Ada. pa se koriste samo za one radnje koje ove triger naredbe ne mogu izvršiti. izvođenje složenih računa. Jaroslav: Projektovanje informacionih sistema Korisničke izlazne naredbe su mnogo komplikovanije za pisanje i izvođenje od SQL naredbi i SQL naredbi generatora aplikacija. PL/1.2 i 10.6. koji je definisan u okviru klase Trigger Definitions. izvođenje ažuriranja koja iniciraju vrijednosti u formi i optimiziranje izvođenja aplikacija. Riječ je o trigeru PP_Stav_Nal_INS. koji je definisan nad shemom relacije (tabele) Stav_Nal. pomoću alata softverskog inženjeringa Designer-a 2000.174 Poliščuk E. ORACLE. Korisnički izlazi se mogu pisati u bilo kojem od nekoliko programskih jezika.6. XML i HTML. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. Hijerarhijski navigator objekata je prikazan na lijevoj strani ekranske forme. slika 10. potrebno ga je ispraviti. Na desnoj strani ekranske forme. prikazan je na slikama 10. a kod najnovije verzije SUBP ORACLE 9i i u programskoim jezicima Java. 10. 10.1. pretkompajlirati. FORTRAN. COBOL. iskazano putem neproceduralnog jezika PL/SQL. prikazano je tijelo trigera. ista slika. uključujući C.: izvođenje složenih provjera polja. kao npr. Vidljivo je da je triger PP_Stav_Nal_INS direktno podređen tabeli Stav_Nal.3. Slika 10.1. Pascal. odnosno PL/SQL program. pod nazivom PP_Stav_Nal_INS. Cjelokupni programski kod trigera predstavlja objekat. . kompajlirati i povezati sa trigerom.

ili na nivou sloga (torke). trenutka okidanja trigera. Slika 10.2.3. Jaroslav: Projektovanje informacionih sistema 175 Na slici 10. Slika 10. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. kao i to da li je riječ o trigeru koji se pokreće na nivou polja (iskaza). Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. omogućava definisanje: događaja koji pokreće izvršenje trigera. prikazana na slici 10.Poliščuk E. . pridruženog trigeru.3. Slijedeća ekranska forma.2 je prikazana ekranska forma za zadavanje naziva. opisnog polja "svrha" i naziva PL/SQL programa.

Na slici 10. putem koje se zadaje skup obilježja tabele (relacije). tada se otvara posebna ekranska forma. NAS VARCHAR2(22)). ekranska forma "When" omogućava zadavanje takvog uslova. ograničenja torki. Osim SQL naredbi za kreiranje relacija BP. CREATE TABLE ZALIHA (IDS NUMBER(6) NOT NULL. Ukoliko triger treba da sadrži logički (WHEN) uslov. CREATE TABLE KUPAC (IDK NUMBER(6) NOT NULL. Riječ je o automatski generisanom kodu. BRN NUMBER(6) NOT NULL. 10.2. CREATE TABLE ZAG_NAL (IDS NUMBER(6) NOT NULL. generisanje i programiranje BP pomoću CASE alata 10. produkovanom pomoću generatora SQL koda Designer-a 2000. Jaroslav: Projektovanje informacionih sistema Ako se za dogadjaj izabere operacija UPDATE.1. CREATE TABLE SKLADISTE (IDS NUMBER(6) NOT NULL. JEM VARCHAR2(17) NOT NULL. ZAL NUMBER(12. CREATE TABLE ROBA (IDR NUMBER(6) NOT NULL. NAK VARCHAR2(36) NOT NULL. šta je detaljnije opisano u dokumentaciji SUBP. Opis implementacione sheme BP Na osnovu specifikacije implementacionog projekta sheme BP za aplikaciju Komercijalni poslovi. IDR NUMBER(6) NOT NULL.3. . RAS NUMBER(12.7. NAR VARCHAR2(32) NOT NULL).4) DEFAULT 0 NOT NULL).4) DEFAULT 0 NOT NULL. Implementaciono projektovanje. ADR VARCHAR2(62) NOT NULL).7. BON NUMBER(8) DEFAULT 6 NOT NULL).176 Poliščuk E. šta je razmatrano u podtački 6. ORACLE. kreiraju se ograničenja primarnog ključa. čija modifikacija dovodi do pokretanja trigera. ograničenja stranog ključa i trigeri. vrši se opis sheme BP pomoću jezika SQL.4 je prikazan izvod iz datoteke koja sadrzi SQL naredbe za kreiranje odgovarajućih relacija (tabela).

.4) DEFAULT 0 NOT NULL). Slika 10. CREATE TABLE STAV_NAL (IDS NUMBER(6) NOT NULL. generisanje programa je sprovedeno upotrebom generatora modula Developer 2000 Forms.2. Tokom postupka generisanja. OSN VARCHAR2(17)). IDR NUMBER(6) NOT NULL.Poliščuk E. Izvod iz datoteke koja sadrži SQL naredbe za kreiranje odgovarajućih relacija (tabela). koji je obično iterativne prirode. Generisanje programa i programiranje Za formiranje naloga za otpremu aplikacije Komercijalni poslovi. STA VARCHAR2(17) NOT NULL. ORACLE.7. vrše se dodatne modifikacije implementacione specifikacije modula u cilju otklanjanja eventualno uočenih nedostaka ili poboljšanja izgleda dobijene ekranske forme. STN VARCHAR2(17) NOT NULL.5. 177 Slika 10. Jaroslav: Projektovanje informacionih sistema IDK NUMBER(6) NOT NULL. Izgled ekranske forme za formiranje naloga za otpremu.5. Izgled ekranske forme za formiranje naloga za otpremu je prikazan na slici 10. KOL NUMBER(12. 10.4. BRN NUMBER(6) NOT NULL.

korisnik može da zada dodatne kriterijume za prikaz izvoda iz cjelokupne evidencije (u ovom slučaju cjelokupne evidencije kupaca). mogu se naći samo podaci o robi koja je evidentirana na zalihama onog skladišta.6.6. . Izgled ekranske forme za formiranje naloga za otpremu. Izgled prethodne ekranske forme. Izgled ekranske forme. U ovom primjeru. riječ je o skladištu sa identifikacionim brojem 10. U ovoj listi vrijednosti.7. je prikazan na slici 10. kao i svih drugih lista izbora u ovom modulu. Jaroslav: Projektovanje informacionih sistema Slika 10. U okviru ove. u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK). u trenutku kada se kursor nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvana lista izbora vrijednosti identifikacionog broja robe. prikazan je na slici 10.178 Poliščuk E. ciji je identifikacioni broj naveden u zaglavlju naloga. u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK) i kada je pozvana lista izbora vrijednosti identifikacionog broja kupca.

putem jedne transakcije. korisnik je obavezan da pokrene postupak ažuriranja podataka u BP. dok će za svaku torku u radnoj zoni programa. Postupak ažuriranja se sprovodi automatski. Logika izvršavanja interaktivnog modula naloga za otpremu jeste da korisnik. nakon pokretanja programa i prijavljivanja na server BP. Prikaz ekranske forme za formiranje naloga za otpremu. npr. Ti podaci se smještaju u radnu zonu programa. pokretanjem opcije menija Action/Save ili aktiviranjem odgovarajuće ikone. za svaku modifikovanu torku u radnoj zoni programa. transakcija će sadržavati jednu UPDATE naredbu. a korisnik će.Poliščuk E. transakcija sadržavati jednu DELETE naredbu. zadaje. U slučaju da je putem ekranske forme izvršeno ažuriranje podataka u radnoj zoni programa.7. izborom funkcije Save (Sačuvaj). na kraju izvođenja transakcije. . U suprotnom treba da odustane od izmjena podataka. Za svaku novododanu torku u radnoj zoni programa. koja je označena kao izbrisana. putem prikazane ekranske forme. Isto tako. Jaroslav: Projektovanje informacionih sistema 179 Slika 10. u okviru transakcije će automatski biti formirana jedna SQL INSERT naredba. biti obavješten o efektima njenog sprovođenja. može da selektira. modifikuje ili briše podatke o nalogu za otpremu.

standardom ili drugim propisima treba preuzeti i prilagoditi. Samogovoreće šifre (significant position codes) su svaki broj ili grupa brojeva koji opisuju neko svojstvo instance. Primjer: Šifarnik Studentska prehrana. Kao primjeri hijerarhijskih kodova mogu se navesti: šifra predmeta MAT03A3. semestru. 500-599 MUSIC-ONLY. Oznake definisane zakonom. Alfanumeričke oznake su ograničeni skup znakovnih oznaka. podgrupe itd. Sistem šifriranja treba biti smislen i prikladan. Šifra statusa Opis statusa Pravo prehrane R P U V L O redovne studije paralelne studije studije uz rad vanredne studije paralelne studije sa pravom prehrane studije za lične potrebe DA NE NE NE DA DA Primjer jedinstvene šifre: Jedinstveni matični broj akademskog građanina (JMBAG) je jedinstveni broj u sistemu koga student dobija prilikom upisa na studije i zadržava sve do kraja svog studija. DE. oznake država: MNE. U modernim SUBP mogu se generirati uz opciona ograničenja. s tim da su serijski brojevi grupisani prema značenju. IT. 400-499 ADULT. Tabela 10.. npr.8. često kombinovanih sa brojevima. npr.. sa značenjem MAT 3 obavezni predmet u 3. ili hijerarhija vojnih sredstava n*m cifara.180 Poliščuk E. Preporuke za izradu šifarnika su slijedeće. Pravilnikom o studentskoj prehrani propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu. ali dovoljno male da se mogu interpretirati bez računara. Blok šifre su sličane serijskim šiframa. kako bi dodavanje novih šifara bilo jednostavno. Izbjegavati samogovoreće šifre. Hijerarhijski kodovi predstavljaju podjelu u grupe. npr. Šifarski sistem Serijske šifre su brojevi koji se redoslijedom dodjeljuju svakoj novo dodanoj instanci entiteta. 300-399 SPORT.2. student mora biti upisan u tekuću akademsku godinu na redovnom studiju. a često se koriste i u skladišnoj evidenciji (dimenzije automobilskih guma. SQL Server IDENTITY [( seed . JMBG. Izrada šifarskog sistema je neophodna tamo gdje je nemoguće preuzeti postojeće šifarnike od drugih ustanova ili iz postojećih sistema. Jaroslav: Projektovanje informacionih sistema 10. increment )]. Šifre moraju biti dovoljno velike da opišu željene karakteristike. Ostale šifarnike definisati tako da se naknadno mogu nadograđivati. . 200-299 CABLE CHANNELS. Ako se isti student upiše na dvije ili više ustanova . npr.2). električne sijalice). satelitski TV kanali: 100-199 PAY PER VIEW. Posebno se evidentira način upisa (tabela 10. SLO. npr. .

katalog (Meta Modeling) Rječnik podataka sistema za upravljanje relacionom BP je grupa relacija i pogleda (view) koji sadrže informacije o BP. glasi 601983. već se on automatski generiše. i prema međunarodnom standardu ISO/IEC 7812 na jedinstven način identifikuje Studentsku karticu u međunarodnom sistemu kartičnog poslovanja. Rječnik podataka opisuje relacije. B . Unutar ustanove JMBAG i matični broj (broj indeksa) su također jedinstveni.jedinstveni broj u međunarodnom kartičnom poslovanju (IIN). To je baza podataka o bazi podataka ili meta baza.oznaka vrste kartice (1 broj) . atribute. privilegije i druge koncepte iz BP. Slijedećih 5 brojeva su oznaka vlasnika u ustanovi (matični broj vlasnika ili se generiše redoslijedom). Primjer strukture rječnika podataka je prikazan na slici 10. korisnike. grupe. Broj kartice se generiše automatski. a u sebi sadrži 6 grupa brojeva: (601983) 11 (0036324986) 0 A BC D E A . Prva četiri broja označavaju matičnu ustanovu vlasnika. D . modifikuje ili briše. Te relacije i poglede kreira SUBP prilikom kreiranja BP. Jaroslav: Projektovanje informacionih sistema 181 uvijek zadržava JMBAG koji je dobio na prvoj ustanovi. rječnik podataka uvijek sadrži trenutni opis BP.privremena kartica. E . indekse.8. JMBAG ima deset brojeva podijeljenih u dvije grupe.redni broj kartice koju je student dobio (1 broj).student i 4 . . SUBP ih automatski ažurira kad god se neki koncept kreira. C . Prema tome. Relacije rječnika se mogu čitati sa standardnim SQL pretraživanjem. te kontrolni broj (deseti). Rječnik podataka .JMBAG (10 brojeva). Radnici u ustanovama ne unose taj podatak. 10.9.npr: 1 .Poliščuk E.Kontrolni broj kartice (1 broj).

10 je predstavljen strukturirani prikaz (meta model) jednog poslovnog sistema.9 je prikazana praktična realizacija relacija iz sastava Rječnika podataka.8. Jaroslav: Projektovanje informacionih sistema Slika 10. na slici 10.11 strukturirani prikaz (meta model) za primjer Narudžba. Na slici 10. Na slici 10.13 je prikazan primjer ekranske forme aplikacije nad meta modelom.182 Poliščuk E. Primjer strukture rječnika podataka.12 strukturirani (meta model) aplikacije Prodaja i na slici 10. na slici 10. Meta modeliranje može korisno poslužiti za opis poslovnih sistema i funkcija poslovnog sistema. .

dokum. .10. Osnovno Potrošno Tehničko *** Vrsta sredstva Sastavnica sredstva Svojstvo Sredstvo Svojstvo sredstva Slika 10. Dokument Događaj Pravna osoba Fizička osoba Stavka sruktuir. Plan Događ. Vrsta dokumenta Osoba na dok. Materij. (rad. Finans. Pravni Inform.9. na dok. Primjer praktične realizacije rječnika podataka. Org cjelina Hijerar.mj) Osoba Propis Opis procesa Zakon Vrsta događaja Organiz.Poliščuk E. Strukturirani prikaz (meta model) jednog poslovnog sistema. Jaroslav: Projektovanje informacionih sistema 183 Slika 10.

FDD Sredstvo Svojstvo sredstva Slika 10. FDD. Menadž. Narudžbu izradio: Pero Odobrio njegov šef: Ivo Stavke: Računar IMB Šestium: xx kom MBO. CRD. . RAM. Veza: Ponuda preduzeća IMB br.200x.184 Poliščuk E.HDD.xx. Ponuda Narudžba Naručivanje Pravna osoba Fizička osoba Šestium Monitor Štampač Skener Osnovno Tehničko Vrsta sredstva Svojstvo MBO. Ivo. RAM.xx. xxxx od xx. xxxx od xx. Datum. Narudžba MBB-Nabava za osnovno tehničko sredstvo prema preduzeću IMB Br. CASE Monitor 15” xx kom Štampač xx kom Skener xx kom MBB Nabava Pravilnik o poslovanju Opis poslova naručiv. Strukturirani prikaz (meta model) za primjer Narudžba.CPU.200x. CPU. Zakon Vrsta događaja Pravni Finansij. CDR. Jaroslav: Projektovanje informacionih sistema Primjer: Narudžba.11. Pero Broj. HDD. Šef Narudžbenica Plan Osoba MBB.

. Primjer ekranske forme aplikacije nad meta modelom. Slika 10. Strukturirani prikaz (meta model) aplikacije Prodaja.Poliščuk E. Jaroslav: Projektovanje informacionih sistema Korisnik SifMje Zaglavlje SifZag VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Napomena SifNap NacinPlac SifPlac Otprema SifOtp 185 Parametar SkracParam Mjesto SifMje Tarifa TarBroj Dokument IdDok Partner SifPart SifMje VrDok IdPrethDok SifPart SifOtpr SifPlac SifZag SifNap Artikl SifArt TarBroj StavkaDok IdDok SifArt Uplata IdUplate IdDok Slika 10.13.12.

Podjela programa i/ili sistema u module. omogućava veliko unutrašnje prijanjanje modula (koheziju). a provode kontrolisanim naslijeđivanjem. primjenjuju. opis vrste podataka. Moduli trebaju biti minimalno međusobno zavisni. pri čemu program napisan pomoću PDL nema oblik izvedbenog programa. opis jezikom za oblikovanje programa (PDL . odnosno specifikacija programa. Kohezija i povezivanje se. blokova. interfejsom i sličnostima između klasa i komponenti. Programski modul je grupa instrukcija. Moduli moraju biti interno visoko povezani. a sastoji se od paragrafa. 2. Specifikacija i dizajn programske podrške Specifikacija programske podrške. Tako npr. svaki modul treba obavljati jednu i samo jednu funkciju. koji savladavanje veličine i složenosti programa ostvaruje razradom u hijerarhiju programskih modula. koje istovremeno sadrže strukture podataka i procedure (metode). Dizajn programske podrške 11. subrutina. Mora biti ostvarena mala vanjska zavisnost modula (skopčanost). opis ulaznih i izlaznih podataka. 11. 1. takođe. kao i specifikaciju prikaza podataka. Jaroslav: Projektovanje informacionih sistema 11. funkcionalni pristup oblikovanju programa (Yourdon & Constantine. 1981) zasniva se na tome da struktura podataka određuje strukturu programa.186 Poliščuk E. Objektno usmjereni pristup se zasniva na podjeli na klase. kao i postizanje ponovne upotrebljivosti u budućim programima.Progam Design Language (pseudokod)). 1979) sačinjavaju slijedeće faze. sadrži proces pretvaranja zahtjeva za programsku podršku u oblik koji omogućava programiranje. Pristup oblikovanju programa Pristup oblikovanju programa može biti različit. obuhvata navođenje svih zadataka koje program treba obaviti. crne kutije. Strukturirani dizajn programske podrške. odnosno dizajn programa. međusobne povezanosti različitih dijelova programa i podataka. Oblikovanje programa prema podacima usmjerenim pristupom (Jackson & Warnier. potprograma.2. Dizajn programske podrške. ili tzv. Procedure se obavljaju nad objektima (instancama) klasa.1. . odnosno ostvarena minimizacija uticaja promjene jednog modula na druge module.

transformacione i transakcione analize. Elementi prikaza strukturne karte. Strukturirani dizajn Strukturirani dizajn omogućava oblikovanje programa na osnovu dijagrama toka podataka korištenjem strukturnih karti. Jaroslav: Projektovanje informacionih sistema 187 11. Pseudokod Strukturna karta (Structure Chart) prikazuje modeliranje programske podrške na osnovu dijagrama toka podataka.1).1. . podatak (data couple) funkcija niz poziv ugrađena funkcija (modul) iteracija selekcija indikator (control couple) Slika 11.Poliščuk E. slika 11.2. Grafički prikaz sistema Dijagram toka podataka Dijagram toka podataka sa određenim granicama Strukturna karta Slika 11. kao i plošnim razlaganjem glavnog procesa u sastavne procese (slika 11. Dijagram toka podataka prikazuje ŠTA treba postići.2. a strukturnom kartom se izražava KAKO ostvariti te zahtjeve.3. Grafički prikaz strukturiranog dizajna.

188 Poliščuk E. koji se mogu prikazati linearnim tokom podataka. slika 11. Jaroslav: Projektovanje informacionih sistema Prikaz hijerarhije programskih modula uključuje prenos podataka i upravljanja između različitih nivoa obrade. . ponavljajuće i uslovne obrade. Sistem izvještaja o prodaji datum zbir datum zbir Uzmi datum datum Zapiši izvještaj zbir zbir Ispiši zbir zbir datum vrijednost EOF Uspjeh Katastrofa Zapiši zaglavlje Zapiši red datum EOF podatak vrijednost Računaj zbir podatak Čitaj podatak Piši podatak Slika 11. prikladna za ovakve sisteme. Strukturna karta za DTP izvještaja o poslovanju kompanije. obrada. tj. izlaz).3.3. koji pribavlja podatak C. • Put I. kao i prikaz naredne. • C → I. Primjer: Izvještaj o poslovanju kompanije Gazda & ortaci. Transformaciona analiza (transform analysis) je analiza promjene/ pretvaranja podataka. aplikacije sa jasno raspoznatljivim ulazima. koji obradom pretvara podatak C u podatak I. tj. Primjenljiva je na sisteme koji imaju strukturu oblika “ulaz–središte-izlaz”. koji ispisuje rezultat I. Struktura dizajna.4. slika 11. podsistema: • Get C. se sastoji od tri odgovarajuća elementa (ulaz. središnjom obradom i izlazima.

Slika 11. 4 ili 5).5. • rezultirajući podatak (C1. . a pojedini izlazi se kasnije koriste u daljnjoj obradi. Transakciona analiza (transaction analysis) je analiza izvršenja/obavljanja obrade. C2 ili C3) koristi se kao izlazni tok C. Primjenjuje se na sisteme sa jasno raspoznatljivim središtima izvršenja. interaktivne aplikacije). Primjer: • središte zaprima ulaz B.4. Ilustracija transformacione analize. B2 ili B3) u odgovarajući proces (3. tj. sisteme u kojima se donosi odluka o tome koji će se proces koristiti za pretvaranje ulaza u izlaze (npr.5.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 189 Slika 11. Ilustracija transakcione analize. Ulaz se usmjerava nekom od modula obrade. slika 11. koji se usmjerava (kao B1.

6.7. najčešće. primjenjuje kombinacija osnovnih postupaka. složeni sistemi. Najčešće se oblikuju plošnim razlaganjem glavnog procesa u sastavne procese.6. Jaroslav: Projektovanje informacionih sistema Sistemi koji nisu ni transformacioni ni transakcioni se obrađuju na poseban način. Prikaz složenog sistema dobijenog kombinacijom osnovnih postupaka. Primjer: Slika 11. Stvarni sistemi su. Za oblikovanje programa se. Strukturna karta za DTP razložen plošnom dekompozicijom.7. obično.190 Poliščuk E. Nadređeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podređenih procesa. Slika 11. te prikupiti i čuvati proizvedene rezultate obrade. . slika 11. slika 11.

Programska oprema mora imati standardni izgled ekranskih formi. . istorija i stanja evidencije). . Elementi grafičkog interfejsa za unos podataka Elementi grafičkog interfejsa za unos podataka su: Text Box (i varijante) služi za unos podataka u obliku slobodnog teksta. matrica) predstavlja kombinaciju osnovnih elemenata.3. računi). 11.Poliščuk E. List Box namjenjen je za unos umjereno velikog broja (?) poznatih. količini podataka te mogućim akcijama.4. 11.4.1. pen-based). iznimke). magnetski uređaji (magnetske kartice i drugo). Unos podataka može biti periodični za masovni unos (batch input) ili interaktivni unos (on-line). vrsti prikazanih podataka. međusobno isključivih vrijednosti. U svakom trenutku mora biti vidljiva informacija o dijelu obrade. Mora postojati područje za navigaciju (ekranska forma za izbor ili pregled podataka).. grafički izvještaji (tačkasti. najčešće. uzorci glasa).4.. NumericUpDown namjenjen je za unos nevelikog niza diskretnih vrijednosti. područje za prikaz statusa obrade i radno područje za rad sa podacima. zbirni izvještaji (grupisanje. štapićasti. Check Box omogućava unos binarnih vrijednosti. Grid (mreža. Oblikovanje i standardizacija interfejsa Organizacija interfejsa. uređaji osjetljivi na dodir (touch screen. Spin (Spinner). touch-pad. detaljni izvještaji (dokumentovanje obrade.. linijski). međusobno isključivih vrijednosti (2 do 3). Drop-Down ili Combination (Combo) Box omogućava unos umjereno velikog broja (?) poznatih (?).4. sortiranje. Dizajn interfejsa 11. Automatizovani unos može biti raznolik: biometrijski uređaji (otisci prstiju. Izlazi (izvještaji) mogu biti: dokumenti (prijavnice. elektromagnetski uređaji (identifikacija objekata pomoću radio talasa). memorija).2. Interfejsi Korisnički interfejsi su. optički čitači (optički čitači oznaka. DomainUpDown. optički čitači teksta). tekstualni ili grafički.. pametne kartice (mikroprocesor. . koji se obavlja na mjestu nastanka podataka. ne nužno isključivih vrijednosti. opciona vrijednost je "nepoznato". . Radio Button služi za unos vrijednosti iz konačnog malog skupa unaprijed poznatih. . Jaroslav: Projektovanje informacionih sistema 191 11.

Skočne forme (pop-up) nisu očigledne. Horizontalna ekranska forma za izbor (menu bar) je uvijek vidljiva i lako dohvatljiva. Izbjegavati računarski žargon . a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija. Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (npr. ali postoji problem ikona i skrivanja. Prikaz standardnog oblika ekranske forme. Ergonomija interfejsa. a korisnik nepotrebno ne opterećuje. Standardni izgled ekranske forme prikazan je na slici 11. Trake sa ikonama (toolbar) su vidljivi i lako se pamte.8. skaču na različitim mjestima. Padajuće (pull-down) i kaskadne ekranske forme su "nevidljive". u slučaju više istovremeno prikazanih "prozora"). vertikalne i kružne).. Unos se mora obavljati u redoslijedu kojim su polja fizički poredana. Doslijednost interfejsa nužan je uslov koji programska oprema mora ispuniti. precizne te zavisne o kontekstu.192 Poliščuk E. Tipke za obavljanje standardnih funkcija moraju biti definisane pažljivo i jednoznačno. Interfejs mora imati ujednačene standardne poruke.8. Polja ekranske forme moraju biti logički grupisana. kojima se pruža dovoljna informacija. ali se opcije daju grupisati. zvučne signale i upozorenja. uz mogućnost brzog odabira (funkcionalnom tipkom ili slovom opcije). Poruke moraju biti jednostavne. Jaroslav: Projektovanje informacionih sistema Interfejsom moraju biti podržane različite vrste ekranskih formi za izbor (npr. Slika 11.

Prilikom izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. Primjer grafičkog interfejsa.Poliščuk E. kojima se obavlja masovni unos podataka.9 je prikazana ekranska forma jednog grafičkog interfejsa. Dijelove aplikacije.9. pod uslovom da se tim prekidom ne narušava integritet podataka (npr. Mora biti ugrađena interaktivna pomoć zavisna o kontekstu. one koje javlja SUBP) i izbjegavati stručne izraze. Suženje skupa treba da se može obaviti na osnovu dijela tekstualnog opisa šifre. Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno došlo do promjene. po mogućnosti neposredno nakon promjene sadržaja polja ekranske forme. Slika 11. unos i izmjena podataka obavljaju na istoj ekranskoj formi i na isti način. Na polju za unos šifri treba omogućiti odabir iz suženog skupa podataka smještenih u šifarnik. Pregled na ekranskoj formi uklanja potrebu za ispisom na papiru i olakšava prilagođavanje uslova za selekciju podataka. Jaroslav: Projektovanje informacionih sistema 193 i skraćenice. prekid selekcija velikog broja zapisa. Unesene podatke treba provjeravati što ranije. Korisniku treba omogućiti pregled teksta koji će biti napisan u izvještaj. Treba omogućiti prekid akcija koje predugo traju. Poželjno je da se traženje. uz mogućnost upotrebe meta znakova. U svakom dijelu obrade treba omogućiti odustajanje uz potvrdu korisnika da to stvarno želi (npr. Na slici 11. Funkcionalnost interfejsa. prekid transakcija). . brisanje).

sa listom za pregled i odabir zahtijevanog podatka. 11. treba omogućiti otvaranje liste za pregled (uz prikaz ograničenog skupa zapisa na osnovu prethodno postavljenog uslova). uz prikaz svih zapisa u odgovarajućoj relaciji. Takođe. Primjer ulančavanja procedura. na kraju. aktiviranje čitavog modula za obradu vezanih podataka.10. vratiti se na mjesto gdje je ona bila potrebna.10. treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije. Programska oprema mora slijediti poslovne procese. Gdje god je to moguće. Jaroslav: Projektovanje informacionih sistema potrebno je prilagoditi kretanju unutar jedne ekranske forme i minimizirati potreban broj tastera. Slika 11. pohrani novu šifru. Rješenje je da se na polju za unos vrijednosti stranog ključa omogući otvaranje “prozora”. Ulančavanje procedura Često se događa da dio rada treba poništiti zbog toga što u sistemu ne postoji šifra koja se želi upotrijebiti. ponovi unos prije poništenih podataka i tek tada ih pohrani. aktiviranje funkcije za unos ili izmjenu vezanog podatka i. Problem je u tome što je korisnik. prisiljen da poništiti do tog trenutka unesene podatke. prođe kroz nekoliko ekranskih formi za izbor do šifarnika.5. Primjer ulančavanja procedura je prikazan na slici 11. .194 Poliščuk E. a nemoguće ju je pohraniti.

Postupak je slijedeći. Nakon toga se vrši postupno udruživanje i reorganizacija modula. π(j) reduciranih skupova funkcija te ρ(j) skupova ručno ugrađenih funkcija. skup standardnih funkcija {F}i te pridruženi reducirani skup funkcija {R}i (slika 11. Primjer modula pune i reducirane funkcionalnosti.Poliščuk E. proizvoljne dubine. dati prednost učestalijim poslovnim procesima i paziti da se grupisanje obavi po funkcionalnim cjelinama. Sistem nakon reorganizacije i kodiranja modula dobija hijerarhijski oblik (slika 11. x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx Pokretački meni P1 M1 F1 R1 P2 M2 F1 R1 Pi Mi Fi Ri Pn Mn Fn Fn Slika 11. Organizacija modula i aplikacija Pri izradi prve globalne podjele modula i definisanju ekranskih formi za izbor. Početni sistem je skup modula za obradu podataka u jednoj relaciji. n). nad ν izvedbenih programa.6.12). To je hijerarhijski ekranski meni. (i = 1. treba pažljivo grupisati poslovne procese u sisteme procedura. pri čemu svaki od njih podržava standardne funkcije i poziva druge module. koji sadrže udruženi glavni program M’j. ali dugoročno donosi prednosti. … . koji sadrže glavni program Mi za poziv ekranske forme za izbor standardnog modula. µ(j) skupova standardnih funkcija. Ovakav način izrade programske opreme zahtijeva veći početni rad. (j = 1. uz naknadno razdvajanje sistemskih od korisničkih promjenjivih elemenata.11). Jaroslav: Projektovanje informacionih sistema 195 11. ν). … .11. Početni sistem (moduli pune i reducirane funkcionalnosti) se sastoji od početne ekranske forme za izbor i izvedbenih programa Pi. .

entitetskog i referencijalnog integriteta.196 Poliščuk E. 2. Standardizacija i modularnost programske podrške 11.1. 3. Jaroslav: Projektovanje informacionih sistema x xxxxxxx x xxxxxxx x xxxxxxx Hijerarhijski meni x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx P’1 M’1 F’11 R’11 H11 F’1μ(j) R’1π(j) H1ρ(j) F’v1 R’v1 Hv1 P’v M’v F’vμ(j) R’vπ(j) Hvρ(j) Slika 11. podataka koji se nalaze u drugim relacijama. Primjer sistema nakon reorganizacije i kodiranja modula.12. a trenutno na ekranskoj formi prikazanog zapisa. a povezani su preko stranog ključa. Ako programski jezik nema neproceduralnih naredbi za konstrukciju uslova selekcije treba ih programski simulirati. Može biti prikazan niti jedan zapis. Ulaz u modul. 11.7. Izmjena postojećeg zapisa: omogućava se promjena vrijednosti prethodno učitanog. . svi zapisi ili odabrani zapisi (primarni ključ je uslov za selekciju zapisa). Standardizacija i modularnost Standardne funkcije modula aplikacije za rad sa bazom podataka su slijedeće: 1.7. 4. Načelno se zabranjuje izmjena vrijednosti identifikatora zapisa. Odabir referenciranih podataka obavlja se kao kod unosa. Treba omogućiti odabir. Traženje (selekcija) podataka: mora podržavati traženje po uzorcima (query by example). koje se unosi sa ekranske forme (query by form). Unos novog zapisa: obavlja odgovarajuću provjeru domenskog. koji ostvaruje automatski prikaz podataka na osnovu uslova/parametera. i po potrebi unos.

Ispisivanje izvještaja (report): sadržaj ispisa.IdVrste = Vrsta. odnosno osnovni podatci (šifra i naziv) ili svi podaci. Pregledanje (eng. Jaroslav: Projektovanje informacionih sistema 197 5.IdRoda = Rod. 6. po stranicama. Brisanje se obavlja uz dodatnu potvrdu.NazRoda LIKE "vitis*" AND NarodnoIme. svi učitani zapisi. Izlaz iz modula: sa prenosom informacija o odabranom zapisu (primarni ključ ili cijeli zapis). 8.* FROM Vrsta ORDER BY ImenaLat modifikuje se u: SELECT DISTINCTROW Vrsta.IdNarodnogImena WHERE Rod. format ispisa. pretraživanje liste podataka po dijelu naziva (filter) ili po želji koji može odabrati jedan ili više zapisa ili onemogućiti odabir.Poliščuk E.IdVrste) INNER JOIN NarodnoIme ON NarodnoImeVrste.* FROM (((Vrsta) INNER JOIN Rod ON Vrsta. Standardno se prikazuju samo osnovni elementi zapisa (primarni ključ i relevantni zavisni atributi). Brisanje učitanog i prikazanog zapisa uz odgovarajuće integritetske provjere i poruke. odredište ispisa. štampač. skok na prvi/zadnji/n-ti zapis. Pretpostavljena naredba za selekciju podataka: SELECT Vrsta. dodavanje na kraj postojeće datoteke). Primjer: Učitavanje po uzorku [Fertalj & Kalpić. npr. datoteka (nova datoteka. 7. trenutno prikazani zapis. ekranska forma.IdRoda) INNER JOIN NarodnoImeVrste ON NarodnoImeVrste. 9.NazNarodnogImen a LIKE "*loza*" ORDER BY ImenaLat .IdNarodnogImena = NarodnoIme. 2005]. browsing) prethodno učitanih podataka: grupni pregled većeg broja učitanih zapisa u “prozoru” po redovima. Poredak (sort) zapisa koji se prikazuju: određivanje poretka prije selekcije ili naknadni preraspored već učitanih zapisa.

dok se sofisticirane funkcije nadograđuju ručno (slika 11. Alternativno.198 Poliščuk E. Primjer: Udruživanje standardnih modula. univerzalni modul se može zamijeniti i pomoću polovine standardnih modula.13. mogu aktivirati i iz bilo kojeg drugog modula (slika 11. Univerzalni modul. Univerzalni modul treba realizovati tako da u pogonu može istovremeno postojati više instanci istog modula prilagođenih pojedinim relacijama. U zavisnosti od projekta. Jaroslav: Projektovanje informacionih sistema 11. Ugradnja opštih programskih rješenja Standardni modul. Poželjno je unaprijed oblikovati standardne module i to: modul za obradu pojedinačnih zapisa. . Primjer osnovnog standardnog modula.2. osim sa ekranskih formi unutar vlastitog modula. Standardne funkcije se ugrađuju tako da se. Za većinu relacija u bazi podataka dovoljno je napraviti modul sa ugrađenim standardnim funkcijama. Forma je kreirana kao kombinacija kopija osnovnih formi.13).14).7. modul za tabelarnu obradu i modul tipa glava-stavke (tzv. Masterdetail). koji se može dinamički prilagoditi tako da obrađuje podatke u različitim relacijama. preporučuje se ugraditi univerzalni modul sa standardnim funkcijama. Slika 11.

15). Sadrži samo osnovne objekte i pozive na standardne procedure (metode) za obradu događaja vezanih uz te objekte.14. Primjer univerzalnog modula za tabelarnu obradu.15. Primjer udruživanja standardnih modula. U trenutku aktiviranja obavlja se prilagođavanje relacije za obradu podataka strukturi relacije podataka (slika 11.Poliščuk E. Primjer: Univerzalni modul za tabelarnu obradu. . Jaroslav: Projektovanje informacionih sistema 199 Slika 11. Slika 11.

koji se prilikom aktiviranja modula dinamički umnožavaju u skladu sa strukturom relacije. te objekte za prikaz/obradu podataka (slika 11. Unaprijed se ugrađuju pozivi standardnih procedura vezanih uz standardne funkcije. Primjer univerzalnog modula za pojedinačnu obradu.16).16.200 Poliščuk E. . Jaroslav: Projektovanje informacionih sistema Primjer: Univerzalni modul za pojedinačnu obradu sadrži objekte za posluživanje standardnih funkcija. te po jednu instancu objekata za prikaz/obradu podataka. Slika 11.

ukratko. odnosno jezika različitih generacija. 4GL + C). Izrada IS. 12. Kod strukturiranog programiranja treba izbjegavati bezuslovne skokove (GOTO naredbe). svakodnevnu upotrebu. izrada detaljnog plana programiranja. uslovno grananje (npr. kao i objektno orijentisani jezici (Object Oriented Language). Automatsko kodiranje se koristi za generisanje programskog koda. kao i generisanje sheme baze podataka. tj. Implementacija informacionog sistema 12. sistema u poslovni sistem. naredbe if. se obavlja kroz slijedeće faze: formiranje razvojnog tima i dodjeljivanje odgovornosti članovima tima. sa unaprijed poznatim brojem koraka). objektno zasnovani jezici (Object Based Language). kada se žele ukloniti neki nedostaci osnovnog jezika kojim se obavlja razvoj (npr. blok naredbi sa jednim ulazom i izlazom).2. Istovremeno korištenje različitih programskih jezika. računarom podržanog. . predstavlja izradu novog sistema i isporuku tog sistema u eksploataciju.1. odnosno transfer probnih podataka i testiranje operacija nad podacima. pisanje i testiranje novih programa i. Drugim riječima. Jaroslav: Projektovanje informacionih sistema 201 12. kreiranje baze podataka. programske petlje (sa uslovom na početku. Programiranje (kodiranje) Programiranje (kodiranje) je pretvaranje detaljnog programskog opisa u stvarni program. pisanje programske dokumentacije. Nakon kreiranja baze podataka vrši se instalacija i testiranje novih softverskih paketa (po potrebi). generisanje interfejsa. Upotrebljavaju se programske strukture: linijska (tj. izrada i provjera baze podataka. Strukturirano programiranje (strukturno programiranje) je tehnika programiranja koja podrazumijeva pristup odozgo prema dolje (top-down programming). na kraju. sa uslovom na kraju.Poliščuk E. izgradnja i testiranje mreža (po potrebi). npr. tj. Izrada sistema Implementacija informacionog sistema podrazumjeva ugradnju novog. case/switch/select) i ponavljanje. Ručno kodiranje je neizbježno zbog veličine stvarnih problema i složenosti procesa. najčešće primjenom nekog formalnog programskog jezika. Ovo kodiranje je sporo i dugotrajno. te alat za otkrivanje pogrešaka (debugger). treba koristiti samo po potrebi. Koriste se programski jezci visokog nivoa: jezici četvrte generacije (4GL – Fourth Generation Language). Poželjno je da konkretni jezik uz prevodilac (compiler) uključuje interpretator (interpreter).

Pokretanje programa završava fatalnom greškom. glavni program. Prvo se kodiraju sve funkcije. Proslijeđuje probleme u primjenu i održavanje. Odgađa otkrivanje problema (grešaka u kodu i dizajnu). 12. 4. Omogućava pristup odozgo prema dolje. odozdo prema gore.1. Izrađuje se program čija je struktura prikazana slikom 12. pozvane funkcije se kodiraju kao . kao i ravnomjerniju podjelu posla. Inkrementalni pristup: struktura programa. Programski modul je skup logički povezanih programskih cjelina. potprogrami (procedure. 3. Rješenje je u postupnom kodiranju i udruživanju funkcija. Prilikom izrade funkcije koja poziva neke druge funkcije. 1. Problem: kako ustanoviti u kojoj funkciji se nalazi greška.3. a zatim niz ponavljanja oblika provjera+ispravka. Primjer: Inkrementalni pristup. 2. funkcije). Omogućava raniju provjeru i izdvajanje grešaka. Jaroslav: Projektovanje informacionih sistema Proceduralno programiranje je način programiranja koji omogućava da se program definiše kao skup programskih cjelina. Uvođenje programskog modula uslovljava pojavu modularnog programiranja.1. Komponenta je bilo koji sastavni dio softvera. Uobičajeno se podrazumijevaju fizičke cjeline. npr.202 Poliščuk E. a b e h c f i l j m d g k Slika 12. a zatim se udružuju. postupno programiranje) je niz ponavljanja oblika kodiranje+provjera+ispravka. Inkrementalni pristup (stupnjevito. Programska cjelina (unit) je skup programskih naredbi koje obavljaju jedan zadatak ili jedan dio zadatka. kao i mješoviti pristup. Pristup programiranju Monolitni pristup (build and fix) je dugotrajno kodiranje. 5. raniju raspoloživost djelomičnih (nedovršenih) verzija programa. poželjno takvih da se mogu ponovo koristiti.

"test". Programiranje od vrha prema dolje. onda se fDonja izrađuje prije fGornja. Mogući redoslijed kodiranja: abcdefghijklm. Prednost ovog pristupa programiranju je bolja provjera logičkih funkcija (na višem nivou hijerarhije. odnosno brže otkrivanje logičkih grešaka i manji utrošak odrezaka. Nakon što je funkcija a napravljena i provjerena. . Alternativni redoslijed je a+beh+cdfi+gjklm.2). Redoslijed kodiranja je lmhijkefgbcda (slika 12. bcd za a). …) Program DriverM poziv M (1. Nedostatak je nedovoljna provjera operativnih funkcija (na nižim nivoima obavljaju stvarni posao). u kojima se donose odluke).2. pisanjem odrezaka (npr.14. izrađuje se pogonska funkcija (driver): Funkcija M (a. Programiranje od dna prema gore (Bottom-Up). a b e h c f i l j m d g k Slika 12. Nakon što su završeni d i odrezak f. treći programer započinje gjklm (slika 12.Poliščuk E. Ako funkcija fGornja poziva funkciju fDonja. Ako se funkcija fDonja poziva iz funkcije fGornja. pristupa se konačnom udruživanju. drugi programer radi ifc i treći programer radi lmjkgd. Nakon što su završene b. c. jedan programer izrađuje beh. Jaroslav: Projektovanje informacionih sistema 203 odresci ili okrajci (stub). tako da je tijelo funkcije prazno ili sadrži poruku (“Tu sam B”): Funkcija A () poziv B() Funkcija B() ispis "Tu sam B" Prilikom izrade funkcije koja će biti pozvana iz neke druge. 3. b. još neugrađene funkcije. c i d.3): prvi programer radi heb. onda se fGornja kodira i integriše prije fDonja. …) Programiranje od vrha prema dolje (Top-Down). a drugi istovremeno radi cdfi.

efhiklm (slika 12. Programski standardi i preporuke Povećanje čitljivosti programa se ostvaruje: standardizacijom naziva. npr. 12. Zatim se od dna prema gore rade operativne funkcije. Takođe je potrebno izbjegavanje programskih redova . tehnikom i stilom programiranja. Prednost ovog pristupa programiranju je rano otkrivanje logičkih grešaka uz bolju provjeru operativnih funkcija.4. različitim označavanjem pojedinih elemenata jezika. abcdgj. Mješoviti pristup. opcije prevodilaca (različita boja ili "veličina" znakova).3. npr. korištenjem predefinisanih simboličkih oznaka i konstanti. identifikatori. Jaroslav: Projektovanje informacionih sistema Prednost ovog pristupa programiranju je bolja provjera operativnih funkcija i manji utrošak pogonskog koda. Mješoviti (sandwich) pristup. Prvo se od vrha prema dolje izrađuju logičke funkcije.204 Poliščuk E. Nedostatak je kasno otkrivanje logičkih grešaka.4.4). a b e h c f i l j m d g k Slika 12. a b e h c f i l j m d g k Slika 12. programskim komentarima. kao što su rezervisane riječi. komentari. Programiranje od dna prema gore.

Sifra. x1.* FROM Posao WHERE Posao. vode u nedoslijednost već pri prvoj pojavi iste skraćenice za različiti pojam. "uvlačenje". zbog smanjenja čitljivosti. Koristiti skraćenice opštih pojmova kao što su: broj. npr. dat.SifraMjesta.DatPosla … . SifMje za Mjeru i Mjesto. Dužina identifikatora treba da je do 18 znakova.SifNastav ili Nastavnik. 5. Osoba. podjela nizova naredbi na odsječke koji su u cjelini vidljivi na ekranskoj formi. Izbjegavati prekratke nazive koji. npr. Redni_broj_stavke_kalkulacije. osim za indekse i dimenzije polja: i. Nstvnk.Sifra.1. npr. skraćenica. umjesto: Osoba. operatori i znakovi kao što su: Dat-Rođ. Koristiti smislene nazive. Jaroslav: Projektovanje informacionih sistema 205 koji dužinom prelaze širinu ekranske forme.posao_datum … bolje je SELECT Posao. i. formatiranje izvornog koda. npr. datum respektivno br. k ili i. ozn. jer mogu djelovati nezgrapno unutar upita. bolje je Nastav. ii. Izbjegavati upotrebu posebnih znakova koje sintaksa jezika/sistema ne dozvoljava pri označavanju identifikatora. redni broj. Mjesto. iii.Poliščuk E. max za najveću vrijednost ili len za varijablu koja određuje dužinu. npr. npr. ili. 3. 2. n.Sifra. npr. rOsoba za izvještaje…. j. oznaka. Artikl.. frmOsoba ili fOsoba za ekransku formu. osim u nečitkost.SifNstvnk . x2. 2. 6. skr.SifraOsobe. produktivnosti ručnog kodiranja (pojava sintaksnih grešaka izazvanih greškama u pisanju produžava vrijeme ispravljanja i prevođenja) i mogućih ograničenja jezika. Izbjegavati preduge nazive. Davati nazive iz kojih se vidi na šta se odnose.. . rbr.4. 4. Smjernice za nazive Nazivi struktura podataka treba da budu pisani u skladu sa slijedećim preporukama: 1. 12. Izbjegavati nazive dobijene rutinskim spajanjem naziva entiteta i atributa. odnosno pomicanje u desnu stranu naredbi unutar programskih struktura. tzv. odnosno izbjegavati "jednoslovne" varijable. sif. Nazive odabirati u skladu sa značenjem sadržaja. 3. npr. umjesto SELECT Posao. Koristiti standardne prefikse/sufikse za srodne elemente/objekte. pisanje jedne programske naredbe u redu. repOsoba. Koristiti nazive koji se daju izgovoriti. Nazivi programskih varijabli treba da budu pisani u skladu sa slijedećim preporukama: 1.Sif Nastavnika. npr. 4. Mjesto. x3.* FROM Posao WHERE Posao. šifra.

Loš kôd je bolje ponovo napisati. BackColor. Preporuke. koji osim stvarnih naziva ima mogućnost evidentiranja kodova koji će se koristiti prilikom stvaranja objekata BP. umetanje podcrte između dijelova od kojih je sastavljen pojam (broj_cipela) ili kombinovanje spomenutih notacija.05 'Modified : I. koji se koristi kod imenovanja prostora: imena. public ili protected atributa. A. '*************************************************************** 'Function : FormatField 'Purpose : Formats a field 'Arguments: ' Col Index of field ' Value Value to format 'Returns : True if successful 'Created : I. postupaka i svojstava. koji se koristi kod zaštićenih atributa i lokalnih varijabli postupaka. početna slova ostalih riječi u imenu su velika slova. A. npr.Ras. da odgovaraju stvarnom stanju. čime se olakšava snalaženje u programskom kodu i uklanja moguća "neodređenost" sadržaja. sCount. sa druge strane.Kos.08. klasa. Poželjno je oblikovanje obaviti takvim alatom za modeliranje. npr. Standardizacija naziva. npr.05 '*************************************************************** Function FormatField(Col As Integer. Razlikovati nazive globalnih i lokalnih varijabli. Jaroslav: Projektovanje informacionih sistema 5. Preporučuje se upotreba različitih notacija. O tome treba voditi računa već prilikom oblikovanja baze podataka. camelCase. Dodjeljivanje naziva objektima modela podataka odražava se na nazive programskih varijabli. backColor. kao što su: korištenje velikih i malih slova (BrojCipela). Primjer: Komentar u zaglavlju potprograma. 22. zahtjeva da početno slovo prve riječi u imenu bude malo slovo. te formalnih argumenata koji se odnose na isti pojam. lCount. 12. tj. Primjeri: PascalCase. zahtjeva da početno slovo svake riječi u imenu bude veliko slovo. Dok. 24. static. gCount.09.Kos.206 Poliščuk E. Smjernice za komentare Programski komentari treba da budu ažurni. Value As String) As Integer . aCount. Identifikator klase može započeti znakom @.Ras.2.4. koristiti imenice za imena klasa i koristiti glagole za imena postupaka. Komentarisati smisao naredbi (izbjegavati prepričavanje"). interfejsa. kojih se treba pridržavati: imena interfejsa uobičajeno započinju slovom I. Ne pretjerivati u pisanju komentara. pobrojanih tipova. nego (bezuspješno) pojašnjavati.

" & _ '@ "NewNPFlag=NPFlag.2005 by K 'enum FTP files to compare Case-Insensitive Dim bFile As Long.C:\VbProjs\dh69cd\dh69libClient. RemoteFileName. UpdatedOnServer=True" '@ If MinImportedAdSN > 0 Then '@ SQL = SQL & " WHERE Ad.") '#'End Block Out 22.."already changed by" request '@ 'reset Status and Flags for imported ads '@ SQL = "UPDATE AD SET NewStatus=Status.. 0) If hFile = 0 Then Exit Function 'empty directory..bas 'Purpose: Client Library . 0) hFile = FtpFindFirstFileA(hservice.. FindData.2005 by J '#'Ellerman ..SN > " & MinImportedAdSN '@ End If '@ daoExecute SQL.cFileName = String(MAX_PATH. "Updating local flags. 0.Transfer related 'Modified: 14. '*************************************************************** 'Module: dh69libClient . NewCDFlag=CDFlag. 'Public Const FTP_APPDIR 'Public Const FTP_DIR '.09.Poliščuk E. '*************************************************************** Primjer: Komentar programskog redoslijeda i komentar naredbi.03. FindData... "*.. 0) If hFile = 0 Then '15. Jaroslav: Projektovanje informacionih sistema 207 Primjer: Komentar u zaglavlju modula.06. 'Public Const EXCHANGEINPROGRESS 'Public Const CHECKSYSTEMDATE 'Public Const TRYTOEXCHANGELATER '..2006 by K Primjer: Blok komentar. 'Public Variable ImmediateTransfer '.2005 by J . hFile = FtpFindFirstFileA(hservice.2005 by N '*************************************************************** 'Public Method TestTransfer 'Public Method SetConnectVars 'Public Method ErrExportImport '. FoundFile As String FindData. 05..09.*". "". '#'Block Out 22. IIf(QuietMode. 0.02.

Grupisanje funkcija interfejsa. funkcije za administriranje vanjskih uređaja (npr. Jaroslav: Projektovanje informacionih sistema 12. • kodirati sa osloncem na programske priručnike. • izbjegavati poređenje na jednakost brojeva sa pomičnim zarezom. • pripaziti na granične vrijednosti podataka.208 Poliščuk E.. provjera konzistentnosti podataka i izrada rezervnih kopija). • olakšati ispravljanje neispravnih ulaznih podataka. a zatim odabrani stil doslijedno primjenjivati! Tehnika i stil programiranja zahtjevaju: • eksplicitno deklarisati programske varijable. • rutinski posao i jednostavnu optimizaciju prepustiti prevodiocu. funkcije za rad sa podacima u bazi podataka (npr. nego ih prilagođavati radi višekratnog korištenja. • nedovoljno opšta rješenja bolje je reorganizovati. pomaže kod promjene kodne stranice ili u slučaju potrebe za prevodom na neki drugi jezik. . • postaviti početne vrijednosti varijabli prije upotrebe.1 nije uvijek 1. nego ga popravljati ("krpiti"). te rukovanje pravima pristupa programima i podacima). • loš kôd bolje je napisati ponovno. funkcije interfejsa (npr. • izbjegavati trikove (ne žrtvovati jasnoću radi "efikasnosti"). nizovi znakova i datumi). • provjeriti moguće numeričke greške (10. funkcija i korisnika.0). • koristiti zagrade radi naglašavanja redoslijeda izračunavanja izraza. funkcije za održavanje baze podataka (npr.3. Tu spadaju funkcije za rad sa opštim tipovima podataka (npr. funkcije za upravljanje transakcijama i provjeru statusa izvedenih upita). a zatim brzo rješenje. . • ponavljajuće blokove i izraze zamijeniti potprogramima. te poruka i tekstova pomoći. • doslijedno formatirati podatke.4. • prvo napraviti jasno i ispravno rješenje. • izbjegavati nepotrebna grananja. • neefikasan kôd ne usavršavati. kada sve tekstove treba odjednom mijenjati. sistem izbora. • izbjegavati programske varijable opšteg tipa. • rekurziju koristiti samo za rekurzivne strukture podataka. nego naći bolji algoritam. Programski priručnici. • provjeravati zahtijeve za ulaznim podacima i valjanost ulaznih podataka. • presložiti i pojednostaviti nerazumljive izraze.0 * 0.. • nakon pronađene i ispravljene greške provjeriti imali ih još. Prije početka kodiranja treba pripremiti programske priručnike sa funkcijama grupisanim po namjeni. naročito indeksiranih varijabli . poruka i pomoći). • ugraditi podrazumijevane vrijednosti ulaznih podataka. terminali i pisači). kao i programski dio sistema zaštite (npr. Programske preporuke Na početku izrade treba uspostaviti standarde kodiranja. definiranje programskih modula.

Cilj testiranja na greške je utvrđivanje grešaka. Vrše se slijedeće provjere: test korisničkog interfejsa (provjera svake funkcije interfejsa). kojom se utvrđuje da je napravljen pravi proizvod.5. Funkcionalni način provjere provjerava što cjelina radi. tj. te analizom rezultata obrade. Cilj testiranja sistema Provjera ispravnosti informacionog sistema. Integraciona provjera je ispitivanje grupa komponenti koje integrisane čine cijeli sistem ili neki njegov dio.5. Jaroslav: Projektovanje informacionih sistema 209 12. uz uporabu ispitnih podataka. Nedovršeni elementi mogu se simulirati (ostaci i pogonski moduli). test slučajeva korištenja (provjera svakog pojedinačnog slučaja). Provjera programa se vrši izvođenjem. to jest da li zadovoljava postavljene zahtjeve. Vrši se ispitivanje pojedinačnih cjelina (proceduralno programiranje). odnosno testiranja na greške i ispitivanja programa. 12. test toka podataka (provjera procesa korak-po-korak) i test interfejsa sistema (provjera prenosa podataka između sistema). Testovi su zasnovani na specifikaciji sistema.Poliščuk E. Ispitivanje provodi nezavisni tim za testiranje. Način provjere može biti strukturalni i funkcionalni. Ovu provjeru provode programeri. Verifikacija (ovjera ispravnosti) je dokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen. Ovu provjeru provodi osoblje proizvođača ili korisnici. Testiranje programa (provjera. Provjera sistema. Testovi proizilaze iz iskustva te osobe. Testiranje i ispravljanje grešaka se mora obavljati redoslijedom kojim su moduli kodirani. koji odgovara korisniku i namjeni. kojom se osigurava da svi nezavisno razvijeni aplikativni programi rade ispravno u skladu sa specifikacijama. ispitivanje programa). Vrste testiranja sistema Testiranje ostataka je testiranje upravljačkih struktura i vrijednosti sadržanih u kodu. Probni slučajevi se izvode uvidom u programski kôd (inspekcija koda). da odgovara specifikaciji zahtjeva. odnosno nedostataka unutar programa. Kod strukturalnog načina provjere se provjerava kako cjelina radi. su uspješni kada se dokaže postojanje grešaka.5. Ispitivanje provodi programer komponente (postoje iznimke za kritične sisteme). Provjera ispravnosti informacionog sistema 12. Vrše se slijedeće provjere: funkcionalno testiranje (gdje se vrši . Probni slučajevi se izvode iz specifikacija funkcija. odnosno provjera rada sistema kao cjeline. uobičajeno sa vrha prema dolje. Testiranje komponenti je ispitivanje pojedinih programskih komponenti.1. Validacija (potvrda valjanosti).2.

Provjeravaju se performanse sistema.provjera prava pristupa. naziv opcije sistema za ekransku formu).verifikacija velikog broja simultanih pristupa.. recovery .. Plan testiranja sistema Testiranje mora biti sistemsko. volume . Testiranje performansi (odnosno provjeru nefunkcionalnih zahtjeva) sačinjavaju: • • • • • stress . a provode ga korisnici kod izvođača. Prikupljeni dodatni zahtjevi se procjenjuju. vrstu preduzete akcije (npr. a greške uklanjaju po mogućnosti istog dana. u kojoj učestvuju poznati korisnici.brzina odziva. ispravan i spreman za primjenu. Po želji krajnji korisnik dodatno iznosi svoja zapažanja ili prijedloge.210 Poliščuk E. te se izrađuje lista prioriteta ugradnje. provjera korisničke dokumentacije i primjera). prema unaprijed napravljenom planu. vršna opterećenja.mogućnost oporavka pri “forsiranom” padu sistema. potvrda pohrane ili prekid obrade). fragmentaciju. 12. identifikator ili opis podatka koji se želi obraditi. Sastoji se od probne upotrebe sistema. bez prisustva izvođača. naziv funkcije (npr. koji sadrži: identifikator programa ili dijela obrade (npr. Testiranje provode korisnici kod sebe.3. nastoji obaviti svoje svakodnevne poslove. koristeći napravljena rješenja. traženje grešaka i propusta. timing . a po potrebi i očekivani rezultat. security .test na količinu podataka. testiranje performansi i testiranje dokumentacije (tj.5. Predstavlja potvrdu da je sistem gotov. pogrešan prikaz podataka). upotrebljivost i lakoća upotrebe metoda i procedura. Provjeru obavlja ogledna skupina krajnjih korisnika koja. Beta-testiranje je validaciono testiranje. Jaroslav: Projektovanje informacionih sistema provjera funkcionalnosti prema zahtjevima korisnika). Alfa-testiranje je verifikaciono testiranje. neispravni podaci. ponašanje programa (npr. Preporuke za provjeru. Vrši se simulacija stvarnog okruženja. To je sveobuhvatni i konačni test sa stvarnim podacima. Provjera se vrši u stvarnim uslovima. složenost algoritama. Test prihvatljivosti je test sistema kojim se dokazuje da proizvod zadovoljava korisničke zahtjeve i potrebe organizacije. te uslove pod kojima ga je naručilac spreman preuzeti. Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova naknadna ugradnja. Ovaj test provode nezavisne institucije za osiguravanje kvaliteta. neregularni završetak rada. unos ili izmjena). Nadzorni test se provodi prema potrebi.. Primjedbe se prikupljaju dnevno. izrada rezervnih kopija i oporavak sistema. . su slijedeće. .

Broj. 3. budući da sadrži plan razvoja. Omogućava upravljanje projektom i konfiguracijom sistema.Poliščuk E. Document za softverski dizajn . Dokumentacija softverskog testa . specifikaciju dizajna. 9. dnevnik promjena i programski priručnici). Specifikacija softverskih zahtjeva . 2. restore.startup/shutdown.restart. cue cards). Dokumentovanje razvoja Projektna dokumentacija treba da dokumentuje razvoj IS. Tehnička dokumentacija je namijenjena tehničkom osoblju. pocket guide. Plan softverskog upravljanja Management Plan (SCMP).Software Validation and Verification Plan (SVVP). konfiguracijom Software Configuration 4. Pored navedenog. izradu i održavanje sistema. opis izrade rezervnih kopija i vraćanja podataka . Korisnička dokumentacija mora pružiti pomoć korisnicima pri upotrebi sistema i mora biti prilagođena korisnicima različitog iskustva. Izvorni kod (Source code). upute za vježbu (training guide. Izrada dokumentacije 12. opis arhitekture sistema i specifikaciju interfejsa prema drugim sistemima. recovery). .Software Test Documentation (STD). 6. opis baze podataka. Plan upravljanja softverskim projektom . vrsta i obim dokumenata zavisi o aplikaciji. 5. Plan validacije i verifikacije softvera .backup. instalacioni priručnik (odnosno opis instalacione procedure) i upute za rukovanje i održavanje (opis procedura za pokretanje/zaustavljanje . probni podaci i rezultati provjere. Plan garancije kvaliteta softvera . instalacioni priručnik (installations manual). 8.Software Project Management Plan (SPMP).Software Quality Assurance Plan (SQAP). Korisničko uputstvo (User's manual).6.Software Requirements Specification (SRS). detaljni priručnik (reference manual). Potrebna je za razumijevanje. opis postupka ponovnog pokretanja i oporavka . Tu spadaju: upute za upotrebu (user manual). tutorial). 7. kao i proizvode pojedinih faza razvoja. Jaroslav: Projektovanje informacionih sistema 211 12.Software Design Document (SDD). tehničku dokumentaciju sačinjavaju: programska dokumentacija (izvorni kôd. podsjetnici ili kratke upute (quick reference guide. Dokumentaciju po IEEE standardu sačinjavaju: 1.1.6.

redoslijed popunjavanja šifarnika. dobra dokumentacija mora biti napisana sa gledišta čitaoca. opisivati postupak rada. kratka poglavlja. odražavati stvarno stanje opreme u primjeni (tj. biti ažurna) i uključivati rječnik korištenih izraza. radne procedure).2. prije završetka kodiranja i testiranja. Preporučuje se odvojeno čuvati odgovarajuću varijantu programske opreme (alata) kojom je proizvod napravljen. Dokumentacija mora biti dobro ilustrovana (slikama ekranskih formi i njihovog redoslijeda). Između ostalog. Mora biti planirana i započeti izradu dovoljno rano.6. naročito kada autor ili autori prestanu biti raspoloživi. . jednostavnost izraza. Nepostojanje dokumentacije može biti razlog za prestanak korištenja aplikacija.212 Poliščuk E. Takođe. Preporuke za izradu dokumentacije Izrada dokumentacije zahtijeva angažovanje i do nekoliko sati (3) po stranici. mora bilježiti načela (argumente odluka). a ne samo sadržaj ekranske forme (npr. Prilikom izrade treba izbjegavati ponavljanja i neodređenosti i koristiti standardizovane dokumente. Prije objavljivanja dokumentacije treba provjeriti/dokazati da odgovara namjeni. Jaroslav: Projektovanje informacionih sistema 12. a ne pisca. određivanje lozinki i prava pristupa. šta podrazumjeva konzistentnost pojmova.

1. nemogućnost opisa struktura podataka. Primjer 1: Slika 13. Za opis akcije ili odluke unutar simbola može se primijeniti bilo koja notacija. Dijagram toka (blok dijagram. nestrukturiranost. veliki i neprikladni dijagrami. Osim toga. Jaroslav: Projektovanje informacionih sistema 213 13. dijagrami toka su usredotočeni na akcije koje sistem/program mora obaviti. dozvola skokova koji vode upotrebi GOTO naredbe. kao i grafički prikaz programa (program flowchart). Specifikaciju predstavlja skup simbola koji opisuju upravljački tok.Poliščuk E. pseudokod ili prirodni jezik. nedostatak formalizma. Primjer dijagrama toka.1. . npr. Logičko projektovanje programa i programski jezici 13. ali ipak predstavlja tehniku koja (nikako ne) izlazi iz upotrebe. algoritam) Dijagrami toka (Flowcharts) omogućavaju grafički prikaz sistema (system flowchart) i predstavljaju zamjenu za fizičke DTP. Nedostaci dijagrama toka su veliki skup simbola.

Izlaz podat.2.3. .podat. Primjer 3: Prodaja Slika 13. NE Kraj obrade DA Završne radnje KRAJ Kontrola izlaza iz petlje Slika 13. Dijagram toka Prodaja (generator dijagrama toka Visio).214 Primjer 2: Poliščuk E. Jaroslav: Projektovanje informacionih sistema POČETAK Pripremne radnje Spojište tokova Učitav. Primjer opšteg oblika dijagrama toka. Obrada podat.

4. Jaroslav: Projektovanje informacionih sistema 215 Primjer 4: Slika 13.5.5 (2006). Simboli dijagrama toka.Poliščuk E.Ekranska forma generatora dijagrama toka Code Visual to Flowchart V3. Primjer 5: Slika 13. .

POSTAVI. Osnovni elementi pseudokoda Osnovne elemente pseudokoda sačinjavaju: • • • • • promjenljive. koji se ne mogu lako izraziti putem naredbi nekog drugog programskog jezika opšte namjene.216 Poliščuk E. 13. npr. aritmetički i algebarski operatori. • elementi pseudokoda moraju biti tako definisani da se mogu lako prevesti na većinu programskih jezika opšte namjene. operator dodjele. Predstavlja način opisa logičkog toka algoritma programa. Pseudokod je prilagođen strukturiranom načinu programiranja i otuda potiču njegova osnovna sintaksna pravila.2. koji poznaje osnovna pravila pisanja algoritma. specifične za rad sa datotekama. Glagoli: Svaka imperativna naredba pseudokoda počinje glagolom. Za potrebe ovog teksta. kao i pravila za konstruisanje procesa i naredbe pseudokoda. ali ne sadrži formalna pravila jezičke sintakse ni jednog od njih. glagoli. a ako se sastoji od više riječi povezuju se podcrtom („_“). .1. Ako to ne proizilazi iz njihovog naziva.2. Taj glagol se piše velikim slovima. npr. Jaroslav: Projektovanje informacionih sistema 13. • elementi pseudokoda moraju biti razumljivi čitaocu. su opisani u nastavku teksta. p. pošlo se od slijedećih zahtjeva: • svaki element pseudokoda mora biti jednoznačno definisan. nisu ograničene dužinom. Pri definisanju sintakse i semantike ovog pseudokoda.. Strukturirani prirodni jezik (pseudokod) Pseudokod je srodan višim programskim jezicima. Sintaksa i semantika osnovnih elemenata i osnovnih struktura pseudokoda. Pišu se „italic“ slovima. • pseudokod mora posjedovati naredbe za rad sa datotekama na eksternom memorijskom uređaju. prilagođen je našem govornom području. komentari. • elementi algoritma ne smiju posjedovati specifičnosti nekog programskog jezika. Promjenljive i njihovi tipovi se u pseudokodu posebno ne deklarišu. opisuju se u okviru komentara.

Redoslijed izvršavanja aktivnosti je određen redoslijedom njihovog navođenja u pseudokodu. koja predstavlja operator dodjele. koriste na uobičajen način. selekcija (razgranata struktura) i iteracija (ciklična struktura). To su glagol POSTAVI i strelica „←“. Jaroslav: Projektovanje informacionih sistema 217 Operator dodjele: Naredba dodjele vrijednosti promjenljivoj posjeduje dvije komponente. Primjer: ( * ovo je ispravan komentar * ) ( * ovo je neispravan komentar ( ** ) ( ********************************* ovo je ispravan komentar *********************************** ). 13. od tri aktivnosti u pseudokodu. Naredba ima oblik: POSTAVI p ← i. .2.2. izvršenju aktivnosti C mora prethoditi izvršenje aktivnosti B. gdje „( *“ označava početak.Poliščuk E. Komentar u pseudokodu ima slijedeću sintaksu: ( * tekst komentara * ). a „ *)“ kraj komentara. koji ne smije sadržavati oznake za početak ili kraj komentara. u naredbama pseudokoda. i odgovarajući blok dijagram. mada aktivnost može predstavljati i svaku od osnovnih struktura pseudokoda ili pak strukturu nad skupom osnovnih struktura.6 je prikazana sekvenca. Sekvencom se opisuje niz aktivnosti. a i neki izraz. U svakom slučaju. Sekvenca je osnovni oblik strukturiranja algoritma. gdje je p promjenljiva. promjenljiva p posjeduje vrijednost izraza i. predstavljaju i osnovne strukture pseudokoda. Na slici 13. Osnovne strukture pseudokoda Osnovne strukture strukturiranog načina pisanja algoritma. To su sekvenca (linijska struktura). Aritmetički i algebarski operatori: Aritmetički. Svaka aktivnost sekvence se piše u novom redu i počinje od iste kolone. Aktivnost je naredba pseudokoda ili struktura nad skupom naredbi pseudokoda. a izvršenju aktivnosti B mora prethoditi izvršenje aktivnosti A. koje se bezuslovno odvijaju jedna za drugom. Svaka aktivnost počinje glagolom u imperativnom obliku (IZVRŠI). Sam tekst komentara je niz alfanumeričkih znakova. kojoj se dodjeljuje vrijednost. logički i relacioni operatori se. skupovni. Nakon realizacije naredbe dodjele. Predstavlja linearnu strukturu nad skupom aktivnosti.

Pseudokod i blok dijagram selekcije. Semantika ove strukture se može opisati na slijedeći način.7.7 je prikazana sintaksa pseudokoda i blok dijagram selekcije.6. Selekcija je osnovna struktura koja služi za prikaz uslovnog grananja u algoritmima. počevši od iste kolone kao AKO . inače se izvršava aktivnost B. Pseudokod i blok dijagram sekvence. Tada će promjenljiva a imati vrijednost 1. nakon izvršenja selekcije: AKO JE a ≤ 0 TADA POSTAVI a ← a+1 INAČE POSTAVI a ← a-1 KRAJ AKO . U sintaksi selekcije se za svako AKO JE uslov TADA. Primjer: Neka je a promjenljiva čija je trenutna vrijednost 0. Jaroslav: Projektovanje informacionih sistema PSEUDOKOD: IZVRŠI A IZVRŠI B IZVRŠI C BLOK DIJAGRAM A B C Slika 13. tada se izvršava aktivnost A.218 Poliščuk E. Na slici 13. Ako je zadovoljen uslov P. PSEUDOKOD: AKO JE P TADA IZVRŠI A INAČE IZVRŠI B KRAJ AKO BLOK DIJAGRAM da P A B Slika 13. piše INAČE i jedno KRAJ AKO.

8 je prikazana sintaksa pseudokoda i blok dijagram iteracije tipa RADI DOK JE. bilo n ≤ 1. Da je. . Primjer: Neka je n = 10.9 je prikazana sintaksa pseudokoda i blok dijagram iteracije RADI DOK NE BUDE. aktivnost A se uopšte ne izvodi. Na slici 13. Aktivnost A će se sigurno izvršiti bar jedan put. Iteracija – RADI DOK JE je algoritamska struktura u kojoj se aktivnost A ponovljeno izvršava tako dugo dok je postavljeni uslov P zadovoljen. Na slici 13.Poliščuk E. Počinje glagolom RADI. tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK JE n > 1 POSTAVI n ← n . bez obzira na ispunjenje uslova P. Kada je riječ o iteraciji tipa RADI DOK JE. aktivnost A izvršava prije ispitivanja postavljenog uslova P. za razliku od iteracije tipa RADI DOK JE. nakon izvršenja selekcije bi imala vrijednost a = 0. Jaroslav: Projektovanje informacionih sistema 219 Da je inicijalna vrijednost promjenljive a bila 1. tada se oduzimanje ni jedan put ne bi izvršilo.1 KRAJ RADI oduzimanje_od_n izvršava 9 puta. koja se piše od iste kolone kao i RADI. Iteracija – RADI DOK NE BUDE je iteracija kod koje se. Aktivnost A se izvršava tako dugo dok ne bude zadovoljen uslov P. Pseudokod i blok dijagram iteracije RADI DOK JE. a završava se frazom KRAJ RADI. inicijalno . PSEUDOKOD: RADI naziv_radi DOK JE P IZVRŠI A KRAJ RADI naziv_radi BLOK DIJAGRAM A da P Slika 13. Svaka iteracija ima svoje ime.8. za nju je specifično da ukoliko uslov P nije zadovoljen kod prvog ispitivanja.

Jaroslav: Projektovanje informacionih sistema BLOK DIJAGRAM RADI naziv_radi DOK NE BUDE P IZVRŠI A KRAJ RADI naziv_radi A P da Slika 13. Primjer: Neka je n = 10. Da je. Moguće oznake za pisanje pseudokoda: Abc abc Abc := # " s v M IvI & Si I&I naziv algoritma rezervisana riječ pseudokoda za opis algoritama ugrađena ili trivijalna funkcija (procedura) pridruživanje zamjena vrijednosti komentar konstanta ili parametar skalar vektor matrica nula-vektor modul (dužina) vektora skup element skupa kardinalni broj skupa prazan skup .220 PSEUDOKOD: Poliščuk E. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE.1 KRAJ RADI oduzimanje_od_n izvršava 9 puta. tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen.9. tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n ← n . inicijalno bilo n ≤ 1.

Koriste se kod rada sa generatorima aplikacija (slika 13.3.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 221 13. Ekranska forma generatora aplikacija Advantage:Plex.10 je prikazan primjer prikazivanja procesa pomoću akcionog dijagrama.10. Akcioni dijagram Akcioni dijagram (Action Diagram) je formalizovana mješavina strukturiranog prirodnog jezika i pseudokoda. Primjer akcionog dijagrama za rad sa generatorom aplikacija Advantage:Plex. Slika 13. . Na slici 13.11. Slika 13.11).

Stablo odlučivanja je prikladno za opis složenih grananja u postupku odlučivanja. Jaroslav: Projektovanje informacionih sistema 13. Lako je razumljivo i predstavlja dobro sredstvo za komunikaciju sa korisnicima.12. • posjetioci u grupi imaju 10% popusta na punu cijenu. osim ako su studenti ili penzioneri.4. omladina do 18 godina plaća polovinu pune cijene ulaznice. Primjer stabla odlučivanja za zoološki vrt Životinje. Slika 13.14 pripadajući pseudokod. . Zavisno o donijetoj odluci tok programa prenosi se u podstablo čvora. • studentski popust ne vrijedi vikendom. osobe iznad 18 godina plaćaju punu cijenu. Na slici 13.12.13 je prikazano stablo odlučivanja za Videoteku i na slici 13. Primjer: Posjeta zoološkom vrtu Životinje. Može se uspostaviti veza između stabla odlučivanja i pseudokoda. Stablo odlučivanja Stablo odlučivanja (Decision Tree) je binarno stablo u kojem svaki nezavršni čvor predstavlja odluku koja se donosi u tom čvoru.222 Poliščuk E. List reprezentuje rezultat niza odluka na putu od korijena do tog lista. koji plaćaju polovinu cijene. Stablo odlučivanja za navedeni primjer izgleda kao na slici 13. • • • • ulaz za djecu do 3 godine je besplatan. djeca ispod 12 godina u pratnji odrase osobe plaćaju četvrtinu cijene.

13.14. cijena = 0 ako je hit film tada ⏐ rok iznajmljivanja = 1 dan Slika 14. Primjer pseudokoda za Videoteku.5) inače ⏐ ako je ukupni broj filmova manji od 3 tada ⏐ ⏐ rok iznajmljivanja = 1 dan ⏐ ⏐ cijena = cijena + osnovna cijena filma ⏐ inače ⏐ ⏐ ako je ukupni broj filmova manji od 7 ⏐ ⏐ ⏐ rok iznajmljivanja = 3 dana ⏐ ⏐ inače ⏐ ⏐ ⏐ rok iznajmljivanja = 7 dana ⏐ ⏐ ako film nije treći po redu (svaki treći obični film je besplatan) tada ⏐ ⏐ ⏐ cijena = cijena + osnovna cijena filma Slika 13. Primjer pseudokoda za Videoteku. ⏐ cijena = cijena + (osnovna cijena filma x 1.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 223 Kategorija filma: Ukupni broj filmova koje član želi iznajmiti: Rok za vraćanje posuđenog filma: Hit film Politika iznajmljivanja filmova: Običan film bilo koliko 1 dan 1 dan 3 dana 3 dana manje od 3 3-6 više od 6 Slika 13. . Primjer stabla odlučivanja za Videoteku.13.

nije uvijek svejedno kojim su redoslijedom napisane akcije. Potrebno je izbjegavati eventualno dupliranje izraza i značenja. Fortran i Basic). Međutim. npr. a ove ispred znakova N. koji podržavaju ovaj način izrade specifikacija. Neki CASE alati. 2. Kolone u desnom dijelu tabele treba rasporediti tako da u istom redu oznake "" budu ispred oznaka Y. Jaroslav: Projektovanje informacionih sistema 13. Pravila izrade tabela odlučivanja Prilikom izrade tabela odlučivanja preporučuje se koristiti slijedeća pravila: 1. Logika odlučivanja treba da bude nezavisna o tome kojim redoslijedom su uslovi napisani. C. kao i ograničene skupove mogućih odgovora. . U gornjem dijelu tabele treba pokušati rasporediti redove tako da oni redovi koji sadrže više potvrda uslova (znak Y) budu što više.5. generišu programski kôd različitih jezika (npr.1. Posjeduju relativno jednostavne uslove.224 Poliščuk E. Tabele odlučivanja Tabele odlučivanja (Decision Tables) predstavljaju tabelarni prikaz preslikavanja skupa ulaznih uslova u skup izlaznih akcija.1. Tabela 13. 3. dok oni koji sadrže oznake "-" budu niže.5. Pascal. 5. 4. Uslovi (condition stub) Dob Pratnja Student Vikend Grupa <3 3-12 D Ispunjenost uslova (condition entries) 3-12 N 12-18 >18 D N >18 D D D >18 D D N >18 N D >18 N N PEN Akcije (action stub) Slobodan ulaz Četvrtina cijene Polovina cijene 90% cijene Puna cijena X X X Izbor akcije (action entries) X X X X X X X 13. Predstavljaju dobro sredstvo za opis poslovnog odlučivanja. Primjer: Proširena tabela odlučivanja za zoološki vrt Životinje. da/ne ili nisko/srednje/visoko.

6. Neprikladan je za ručnu izradu. Osnovni elementi struktograma.5) cijena = cijena + osnovna cijena filma X X X X X X X X X X X X X X Y Y N Y Y N Y N Y N Y N N Y Y N N Y N Y N N Y N N N Y - 13. Na slici 13. Tabela 13.15.6 ukupni broj filmova manji od 3 film je treći po redu Akcije rok iznajmljivanja je 7 dana rok iznajmljivanja je 3 dana rok iznajmljivanja je 1 dan cijena = cijena + (osn. Znatno je prikladniji od dijagrama toka. Politika iznajmljivanja filmova hit film ukupni broj filmova veći od 6 ukupni broj filmova 3 . Nassi-Shneiderman dijagrami su pogodni za reverzni inženjering programa pisanih u C programskom jeziku i za generisanje koda.2. .Poliščuk E. naročito kada ga je potrebno često mijenjati. Struktogram Struktogram (Nassi-Shneiderman Chart) je grafički prikaz programskih struktura.16 je prikazan Nassi-Shneiderman dijagram urađen pomoću CASE alata Xper-C. Sekvenca Selekcija Iteracija Slika 13. Osnovni elementi struktograma su prikazani na slici 13.15. cijena filma x 1. Jaroslav: Projektovanje informacionih sistema 225 Primjer: Proširena tabela odlučivanja za Videoteku.

Jaroslav: Projektovanje informacionih sistema Slika 13. 13. • ALGOL (ALGOrithmic Language). Jezici za numeričke i naučne probleme: • FORTRAN (FORmula TRANslator).226 Poliščuk E. .1.7.7. prvobitno jednostavan interpretator za interaktivno rješavanje numeričkih problema. Programski jezici treće generacije Jezici treće generacije (eng. prvi rašireniji jezik za rješavanje numeričkih problema.High Level Languages). • BASIC (Beginner's All-Purpose Symbolic Instruction Code). Programski jezici 13. Ekranska forma Nassi-Shneiderman dijagrama u CASE alatu XperC. kasnije se razvio u Visual Basic.3GL) su jezici visokog nivoa (HLL . Može se izvršiti podjela programskih jezika po namjeni. odnosno proceduralno usmjereni programski jezici. jezik pogodan za rješavanje numeričkih i logičkih problema. 3rd generation languages .16.

proširenje Pascal-a podrškom sistemskom programiranju.Poliščuk E.4GL) su nastali krajem '70-ih i početkom '80-ih godina. danas predstavlja standard kada se radi o proceduralnom programiranju. Programski jezici četvrte generacije predstavljaju jezike posebne namjene. • C++. razvijen radi izrade operativnog sistema iz kojeg je nastao Unix. • C. a koji će biti pogodan za učenje programiranja kao logičke i sistematske discipline. 4th generation languages . Najčešće je u upotrebi SQL (Structured Query Language). pogodan za numeričko-inženjerske i poslovne aplikacije.7. jezik prikladan za poslovne aplikacije i rad sa podacima. Neki 4GL čini skup raznorodnih pomagala povezanih u cjelinu sa okruženjem 4. . nastao sa namjerom da se napravi jezik koji se može efikasno ugraditi na većinu računara.3. Jaroslav: Projektovanje informacionih sistema 227 Jezik za poslovne probleme: • COBOL (COmmon Business Oriented Language). Zadovoljavaju potrebe za izradu 60 80% svih aplikacija. Višenamjenski jezici: • PL/I. C sa svojstvima objektnog programiranja. Jezik vještačke inteligencije: • PROLOG (PROgramming in LOGic). generacije (4th Generation Environment). konceptom procesa i modula koji međusobno komuniciraju. te predstavljaju jezike vrlo visokog nivoa (Very High Level Languages). Većina današnjih 3GL su višenamjenski jezici. pokušaj postavljanja standarda za jezik integrisanih računarskih sistema (kontrola industrijskih pogona.SUBP (DBMS . Programski jezici četvrte generacije Jezici četvrte generacije (eng.7. • ADA.2. vazduhoplova ili bolničkih sistema).DataBase Management System). 13. Vrste i primjena 4GL Jezici za rad sa bazama podataka su strukturirani upitni jezici. 13. specijalizovane za određene klase problema. Jezik orijentisan listama i redovima: • LISP (LISt Processing). nastao sa namjerom da se razvije programski jezik pogodan za probleme iz područja vještačke inteligencije. 4GL naredbe integrišu naredbe jezika visokog nivoa. • Pascal. Za rad sa ovim jezikom u prednjem planu se mora nalaziti Sistem za upravljanje bazom podataka . • Modula-2 i Oberon. namjenjen logičkom programiranju.

NOT. statističke funkcije (npr. AVERAGE. MAX … . 2. EXP.. prodaja). Jaroslav: Projektovanje informacionih sistema Podjezici SQL-a su: 1.. … . MIN. programi za prenos podataka. kamatni račun). ). LN. Integrisana programska podrška (Integrated Software) objedinjuje matrični kalkulator. SQRT. Primjenjuje se za analizu. LOG. Grafički orijentisani jezici (računarska grafika) služe za sintezu slika pomoću računara (dijagrami. Programska proširenja operativnih sistema (skeleti. izmjena. odnosno jezik za definisanje sheme BP u rječniku podataka (kreiranje objekata).Data Manipulation Language). D31=ROUND(SUM(D1:D30) * 0. unos.65. brisanje).. . obradu teksta i grafički prikaz podataka. MS SQL Server. Matrični kalkulatori (Spreadsheet) su tabele organizovane kao mreža redova i kolona. kao i za pomoć pri donošenju odluka (problemi tipa "šta ako"). planiranje (finansije. Elementi jezika su aritmetičke i agregatne funkcije: SUM. matematičke funkcije: SIN. CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) su računarom podržano projektovanje i računarom podržana proizvodnja. kao i pristup bazama podataka (postavljanje upita) i kreiranje dijaloga. AND. logički izrazi: OR. očekivanje) i finansijske funkcije (npr. animacija. MS Access i drugim. programski paketi za prenos slika. Oracle. TAN. Nakon izračunavanja vrijednosti formula automatski slijedi promjena podataka. proizvodnja. izrazi (formule). digitalizacija). elektronska pošta .Data Definition Language). Informix. kao i koncept objekata. 3. npr. Jezik za upravljanje podacima (DCL – Data Control Language). telefax. grafički znakovi i objekti. za rad sa podacima (postavljanje upita. mogu se . COUNT.Geographic Information System) uključuju podatke o geometriji. Programi i jezici za prenos podataka se sreću u komunikacionim sistemima (modem. Jezici četvrte generacije (4GL) kao programski jezici se koriste za pisanje aplikacija nad bazom podataka.. za kontrolu pristupa podatcima (dodjeljivanje i ukidanje prava pristupa). Elementi tabele su: konstante. IF. Jezik za rukovanje podacima (DML . Unix-a). Jezik za opis podataka (DDL . Ovdje se još mogu svrstati simulatori. ASIN.228 Poliščuk E. koncept više slojeva. Geografski IS (GIS . kao i kod rada u mreži računara (emulatori terminala. ).-1). Primjer: Strukturirani upitni jezik SQL se koristi u sistemima za upravljanje slijedećim relacionim bazama podataka: DB2. Nad istim jezgrom (kernel). ljuske) predstavljaju najrašireniji pristup nadogradnje OS (npr. COS.

grupisanje.dat.. • obrada u pozadini (background processing) (prog &.Poliščuk E. ako nije EOF pomakni se. "otvori datoteku. Uz neproceduralne. fg).c . Svojstva jezika 4GL Osnovno svojstvo jezika 4GL je neproceduralna sintaksa. "dohvati podatke … koji zadovoljavaju uslov … ". cd.. NOT NULL ). podržavanju rada sa "prozorima". ). ). Skelet se koristi kao tumač (interpreter) naredbi.. . Ostala programska proširenja OS se zasnivaju na primjeni računarske grafike.7.. • ulančavanje naredbi na principu "cjevovoda" (cat | more). Mashey shell i dr. mnogi 4GL raspolažu proceduralnim naredbama da bi se omogućila ugradnja proceduralnih rješenja.: • kreiranje liste argumenata prilikom poziva programa (ls *. Primjer 1: Opisivanje podataka (SQL). • supstitucija varijabli (set TERM=vt100. . ). ). "ikone". SifMjesta SMALLINT. • usmjeravanje ulaza i izlaza (prog > output...dat). npr. • naredbe za kontrolu programskog toka (while. Adresa CHAR(20). ls. jobs. naredbe za izbor posla (menu).. ekranske forme i dr. Prezime CHAR(20) NOT NULL. npr. zatvori datoteku" i sl... echo $TERM). • redoslijedno izvođenje više programa (cd dir. Jaroslav: Projektovanje informacionih sistema 229 koristiti različiti skeleti (shell). Tipične neproceduralne naredbe su: naredbe za definisanje strukture podataka te rukovanje podacima u BP (nema potrebe za poznavanjem imena i lokacije datoteka. CREATE TABLE Osoba ( IdOsobe INTEGER NOT NULL. ). npr: Bourne shell.. if-then-else. case. • sposobnost testiranja rezultata prethodno izvršene naredbe (if test prog then . agregatne funkcije.. C shell. naredbe za unos ili ispis podataka putem ekranske forme (form). . .. Elementi programskog jezika su: • prenos i zamjena parametara (script prog arg1 arg2 ⇒ $1=arg1 $2=arg2).4.c ⇒ 1. . ). Neproceduralni jezici sadrže niz naredbi koji određuje ŠTA treba učiniti. . adresa. 13. Ime CHAR(20).. npr. . sortiranje. prog < input. kao i naredbe za izvještaje (selekcija..c 2. Proceduralni jezici koriste niz naredbi koji određuje KAKO se određena akcija obavlja.

SELECT * FROM Osoba..SifMjesta = Mjesto..SifMjesta AND Osoba. Mjesto WHERE Osoba. DEFINE rOsoba RECORD LIKE Osoba DEFINE rMjesto RECORD LIKE Mjesto ..SifMjesta Primjer 4: Rukovanje podacima (ZIM).. Stanuje := Osoba.230 Poliščuk E. MENU ”Osoba" COMMAND "Dohvat" "Postavljanje uslova za dohvat zapisa" CALL dohvat() IF status != NOTFOUND THEN NEXT OPTION "Slijedeci" END IF COMMAND "Slijedeci" "Dohvatanje slijedećeg zapisa" CALL slijed() . FIND ALL Osoba Stanuje Mjesto FIND ALL Osoba (UNRELATED) Stanuje Mjesto FIND ALL Osoba Stanuje Mjesto (COMPLETE) Primjer 5: Ekranski meni (Informix-4GL)... DISPLAY BY NAME rOsoba.SifMjesta) RETURNING rMjesto.* . COMMAND "Unos" "Unos novog zapisa" CALL unos() . Jaroslav: Projektovanje informacionih sistema Primjer 2: Rukovanje podacima (selekcija u jeziku SQL)..SifMjesta = Mjesto. INPUT BY NAME rOsoba..Prezime LIKE "K%" Primjer 3: Definicija veze u rječniku podataka (Zim Information Management (ZIM)). COMMAND "Kraj" "Kraj rada" EXIT MENU END MENU Primjer 6: Rukovanje podacima putem ekranske forme.* BEFORE FIELD SifMjesta MESSAGE "Unijeti šifru mjesta" AFTER FIELD SifMjesta CALL Sel_Mjesto (rOsoba.* IF status = NOTFOUND THEN MESSAGE "Ne postoji mjesto" NEXT FIELD SifMjesta ..

Ime FORMAT ACROSS 2 PAGESIZE 23 PAUSE 1 PAGE HEADING "Stranica:" $PAGE : MASK 'ZZ9' : DETAIL LINE Osoba. END INPUT 231 Primjer 7: Izvještaj (ZIM).Adresa : NEWLINE : Mjesto. Ista aplikacija napisana u jeziku SQL može na istom računaru biti od 5 do 20 puta brža od odgovarajuće aplikacije napisane u nekom 3GL. odnosno rješenja dobijena povezivanjem na 3GL. Sličnost programa strukturiranom govornom jeziku pojednostavnjenje izradu programske dokumentacije. koristeći prototipski razvoj.Prezime : NEWLINE : Osoba. REPORT ALL FROM Osoba Stanuje Mjesto SORTED BY Osoba.. Prave se kraće programske liste.Poliščuk E. a ujedno je olakšano otklanjanje grešaka.PostBr : NEWLINE : Mjesto. C. npr. jezgrovitiji i čitljiviji programski kod.NazGrada ENDREPORT Ford Alan Vancouver avenue 63 383260 New York Slika 13.17. Jaroslav: Projektovanje informacionih sistema END IF . Primjer izvještaja. Bitno je ubrzana izrada programa sa neproceduralnom sintaksom i generatorima koda. Povećanje efikasnosti je od 6 do 60 puta (ne i skraćenje vremena izrade!). Kodiranje je sa manje grešaka..Ime Osoba.Prezime. kao što su COBOL ili FORTRAN. Pojedina 4GL naredba zamjenjuje do nekoliko hiljada 3GL-a naredbi. Izradi programske opreme se pristupa u ranoj fazi razvoja. Prednost se gubi u slučajevima kada se radi o aplikacijama koje uključuju rješenja proceduralnog tipa. Povećanje efikasnosti se postiže smanjenjem broja naredbi i pomoću interne optimizacije. . Osoba.

232 Poliščuk E. Odlikuje se prikladnošću za učenje i rukovanje jezikom i podacima. UNIX.. Napred navedeno ne vrijedi jednako za sve 4GL! . korištenje višenivovskih prevodilaca (npr. kao i manje dijalekata (npr. Većina korisnika treba da može naučiti osnove 4GL za 2 do 3 dana. 4GL-EC-C-O-4GE). upravljački programi koji su nadgradnja OS (npr. Nakon toga korisnik bi morao biti u mogućnosti samostalno da obavlja neke manje poslove. Programska oprema razvijena pomoću 4GL posjeduje jednostavnu i razumljivu sintaksu. dvodnevnim testom (TWO DAY TEST). SQLEXEC). kvalitetniji razvojni i korisnički interfejs. ). Može se provjeriti tzv. sličnu govornom jeziku. . ANSI SQL standard). Poželjno je da korisnik nakon manjih prekida u radu (npr. Jaroslav: Projektovanje informacionih sistema Prenosivost (portabilnost) programske opreme omogućavaju: oslonac na standardne OS (MS-DOS/WINDOWS. 10 dana) bude u mogućnosti nastaviti sa radom bez poteškoća..

Pojedine funkcije mogu podržavati veći broj različitih projekata. inovativnost. 14. tj. poticanje identifikacije osoblja sa projektom.1. Prednosti timskog rada su kvalitetnije donošenje odluka. Projektnu organizaciju predstavlja osoblje organizirano unutar/oko projekta. motivacija članova. Organizacija i upravljanje projektom 14.2. Nedostatak je mogući sukob interesa. . Prednosti su u tome što projektna komponenta pogoduje uspješnosti projekta. Organizacija i timski rad Timski rad (teamwork). Ekipa je "samoupravljačka" jedinica. Prednosti su u potpomaganju specijalizacije (povećanju broja specijalista).1. koja posluje u duhu saradnje svojih članova. a nedostaci su u smanjenju osjećaja pripadnosti projektu. njihove koordinacije i njima unaprijed poznatih procedura. Generički modeli organizacije Generičke modele organizacije sačinjavaju: projektna. Jaroslav: Projektovanje informacionih sistema 233 14. osoblje izmiješano u različitim projektima.Poliščuk E. Uticaj karakteristika tima na njegovu uspješnost. dok su nedostaci u upotrebljivosti ove organizacije za male projekte i minimalna raspodjela ekspertize. Prednosti ove organizacije su brže odlučivanje. minimiziranje potreba susreta između članova. Uspješnost tima Formiranje „Jurišanje“ Normiranje Djelovanje Energija tima Slika 14. Matrična organizacija je u osnovi funkcionalna. koheziji projekta. funkcionalna i matrična organizacija. Funkcionalna organizacija predstavlja organizaciju osoblja po funkcionalnim odgovornostima. a funkcionalna komponenta pogoduje povećanju specijalizacije. sinergija i slično.

234 Poliščuk E. "jurišanje" (Storming). Glavni programer objedinjuje znanje i odlučivanje ekipe. Glavni programmer (rukovodilac) Administrator Programer * O Rezervni programmer (pomoćnik) Slika 14. saradnju sa korisnikom ostvaruje poslovni analitičar. sukobu ličnosti. povezivanje u efikasnu operativnu grupu. dok izrada dokumentacije je posao razvojnog tima. .3. koje podrazumjeva ljubaznost. Nabavka i pogon opreme je radni zadatak sistem inženjera za računare. rezervni programer (backup programmer). Uticaj karakteristika tima na njegovu uspješnost prikazan je slikom 14. Pomoćno osoblje se sastoji od administrativnog koordinatora. tj.2. mrežni servisi su zaduženje sistem inženjera za komunikacije. Modeli timova Klasičnu organizaciju tima (Chief Programmer Team) sačinjavaju: glavni programer (chief programmer). 14. koje se ogleda u neslozi. Mora istovremeno biti dobar (vrhunski) programer i rukovodilac. nesklonost iznošenju stavova. djelovanje. odnosno uviđanje dobrih strana zajedničkog rada. konceptualno i logičko oblikovanje obavlja sistem analitičar. Neki stvarni poslovni sistemi koriste gornju podjelu za opis radnih mjesta. Jaroslav: Projektovanje informacionih sistema Razvoj tima definišu slijedeće karakteristike: formiranje (Forming).1. odnosno viši sistem analitičar. U poboljšanoj (revidiranoj) organizaciji ima ulogu pomoćnika rukovodioca (slika 14. mlađi (junior) programer i administrator. Prikaz klasične organizacije tima. programsko inženjerstvo obavlja programeranalitičar. neuspješnosti dogovaranja. U poboljšanoj (revidiranoj) organizaciji ima ulogu rukovodioca ekipe. tehničara i činovnika. Rezervni programer služi kao zamjena za nekog od mlađih programera. međusobno uvažavanje i predstavljanje (Performing). a isporuku sistema/aplikacija vrši poslovni analitičar. grupašenju /stranačkoj pripadnosti.2). prepuštanje vođenju. Modernu organizaciju tima (4GL tim) sačinjavaju izvršioci slijedećih radnih zadataka: rukovodilac projekta. pomanjkanju kvalitetne komunikacije. normiranje (Norming).

a programer (programer aplikacija) vrši kodiranje i testiranje aplikacija. koji upravlja osobljem (plate. Organizacija velikih projekata Upravnik ili rukovodilac projekta (project manager. rukovodilac tima. . Posao može da obavlja više ekipa.3. Ovakav model tima se može primijeniti bez obzira na moguću različitu sistematizaciju radnih mjesta u nekom poslovnom sistemu. kao i rukovođenje ostalim članovima tima. ). Primjer: Ulogu upravnika tima i rukovodioca tima može imati ista osoba. Raspodjela uloga konkretnim članovima.4. režije.. Upravnik tima obavlja poslove planiranja.programer) je zadužen za analizu. projektant (analitičar . 14. Grafički prikaz organizacije velikih projekata. Upravnik projekta Upravnik Rukovodilac tima tima Članovi tima Slika 14.3. Tim može imati više programera. kao i broj članova pojedine kategorije. Upravnik je nadređen upravnicima/ rukovodiocima timova. upravljanja i nadzora. dok rukovodilac tima se bavi tehničkim aspektima aktivnosti koje se odnose na izradu i/ili uvođenje aplikacija/podsistema IS.. a sistem inženjer(i) obavlja(ju) održavanje mreže i računara. Administrator baze podataka je zadužen za BP. Uloga administratora BP i sistem inženjera može se dodijeliti istoj osobi. Jaroslav: Projektovanje informacionih sistema 235 Elastični model tima ima oblik: upravnik tima. zavisi o konkretnom projektu i raspoloživosti radnika. slika 14. Sastav tima odgovara poslovima koje treba obaviti. . Tim može imati i dva rukovodioca i to: upravnika tima (team manager) i rukovodioca tima (team leader). upravlja razvojem (organizacija posla). oblikovanje i izvedbu.Poliščuk E. project leader) upravlja projektom.

. unatoč posebnostima. . napor izrade (određivanje iznosa čovjek-mjeseci) i vrijeme izrade (u mjesecima). u planiranom vremenu i sa planiranim resursima.5. Murphy je bio optimista (Grimmov komentar). Programerski paradoks [Brooks. Jaroslav: Projektovanje informacionih sistema 14.236 Poliščuk E. obavlja kao neki drugi inženjerski poslovi. vremenski raspored i finansijska sredstva. procjena trajanja pojedinih aktivnosti. dodavanje osoblja usporava razvoj. Planiranje projekta mora: odrediti doseg. umjesto da ga ubrza. Plan je najbolja procjena. preraspodjelu sredstava i aktivnosti u skladu sa događajima. Šta je plan (a šta nije)? Plan ne predstavlja izvjesnost ili nešto što će se zaista dogoditi. na vrijeme i uz minimalne troškove. Upravljanje (nadzor) sadrži: određivanje postupka izvještavanja o napretku projekta. izabrati upravnika /rukovodioca projekta. identifikovati pokroviteljstvo kao garanciju realizacije. 14. . odabrati alate za upravljanje projektom i pokrenuti projekat. Uključuje različite aspekte: • plan – Koje aktivnosti i u kojem vremenskom razdoblju treba obaviti? • sredstva/resursi – Koji su kadrovi (osoblje) i oprema potrebni? • organizacija – Koji je odnos pojedinih resursa? • raspored – Koji je redoslijed aktivnosti? • upravljanje – Kako usmjeriti i motivisati izvođače (tim)? • nadzor – Poštuje li se plan? Elementi plana su: veličina projekta. Upravljanje projektom (Project management) Upravljanje projektom predstavlja proces organizovanja.]. Planiranje projekata Zašto planirati? Duhoviti odgovor na ovo pitanje glasi: ako nešto može poći pogrešno. zasnovana na pretpostavkama i iskustvu. upravljanja i nadzora razvoja sistema kojim će se postići prava funkcionalnost.6. troškovi . odnosno funkcionalne tačke (broj linija koda). Nakon što je odgovarajući broj osoba pridružen nekom zadatku. Elementi plana su aktivnosti. planiranja.. kao i ažuriranje vremenskog rasporeda. procjena i dodjeljivanje sredstava potrebnih za pojedinu aktivnost. Planiranje vremena (izrada rasporeda) sačinjavaju: određivanje aktivnosti. određivanje zavisnosti između aktivnosti i izrada vremenskog rasporeda za projekat. poći će pogrešno u najgore vrijeme i na najgorem mjestu (Murphyjev zakon). ključni događaji. praćenje napretka redovnim revizijama. 1982. resursi (sredstva). Izgradnja IS je posao koji se.

definisanje skupa provjera i izvještaja koji se koriste za nadzor realizacije. slika 14. Izrada plana sadrži slijedeće aktivnosti: utvrđivanje ključnih aktivnosti i događaja. a mogu se izdvojiti PRINCE (PRojects IN Controlled Environments) i COCOMO (COnstructive COst MOdel). Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti.4. Metode namijenjene za upravljanje projektima su mnogobrojne. Gantogram prikazuje predviđeni početak i kraj aktivnosi. Mrežni plan . Potrebno je racionalizovati pripadajuće troškove. iterativno razraditi plan i revidirati plan u skladu sa postojećim iskustvom/saznanjima. kao i utvrđivanje potrebnih sredstva.7. definisanje strukture i sadržaja plana projekta.Poliščuk E. Metoda PRINCE je strukturirana metoda za upravljanje projektom. Tehnike za vremensko planiranje Štapićasti/stupčasti dijagrami . Naglašava vremensko preklapanje aktivnosti.Gantogrami (Gantt Charts) omogućavaju prikaz aktivnosti linijama.4. povezati pojedine podprojekte/poslove u glavni projekat. May 1996 Slika 14. Vidljivo je . Jaroslav: Projektovanje informacionih sistema 237 Složeni projekti zahtijevaju velike ekipe. za definisanje organizacione strukture projekta. njihovu međusobnu zavisnost te odgovornost za izvođenje aktivnosti. određivanje vremenskih redoslijeda aktivnosti i događaja.PERT/CPM (Program Evaluation Review Technique/Critical Path Method) prikazuje vremensku predstavu aktivnosti i njihovih uslovljenosti. Primjer gantograma. Dužina linije je srazmjerna vremenu obavljanja aktivnosti. 14.

Zadatak T3 (npr. druge aktivnosti započinju nakon što se to ostvari ili pomak ključnog događaja ima za posljedicu vremenski preraspored. U određenim vremenskim trenutcima se razmatra stepen dovršenosti neke/nekih projektnih aktivnosti. Tabela 14. oblikovanje komponenti). Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Trajanje (u danima) 8 15 15 10 10 5 20 25 15 15 7 10 Zavisnosti T1(M1) T2.8. Izrada plana Definisanje zadataka i njihove međuzavisnosti biće objašnjeni preko slijedećeg primjera (tabela 14. Upravljanje ključnim događajima se vrši tabelarnim prikazima planiranih aktivnosti i trenutnog statusa njihovog izvršenja.5. Primjer mrežnog plana – PERT/CPM.5. Slika 14. ukoliko zavise o ranijim aktivnostima.T4(M2) T1. a koje u nizu. 14. ugradnja komponenti) zavisi o zadatku T1 (npr. slika 14. očekuje se da faza ili aktivnost bude gotova.T7(M7) T9(M6) T11(M8) .1. Jaroslav: Projektovanje informacionih sistema koje aktivnosti se mogu vršiti paralelno. kao npr. Ključni događaj je obično kraj neke faze ili aktivnosti.1). Naglašava kritični put projekta.238 Poliščuk E.T2(M3) T1(M1) T4(M5) T3. Oblikovanje mora biti završeno prije ugradnje.T6(M4) T5.

. Npr. Sve aktivnosti moraju završavati u ključnim tačkama (M1. Neke od aktivnosti su označene i zasjenjenim linijama. Primjer dijagrama mrežnog plana. U navedenom primjeru to je 11 sedmica ili 55 radnih dana.7). što pokazuje da postoji određena fleksibilnost u datumu njihovog završavanja.6. a ne leže na kritičnom putu ne bi trebale uzrokovati vremensko prekoračenje (npr. kritični put neće biti ugrožen sve do završetka zasjenjene linije. (T1-T3-T9-T11-T12. 14. Dolazak na tačku M4 pokazuje da su ti zadaci završeni. . odnosno najdužem putu na aktivnoj mreži.Poliščuk E. ne može započeti sve dok zadaci T3 i T6 nisu završeni. zadatak T9. M3. Prikaz plana Gantogram je alternativni način prikaza vremenskog rasporeda (slika 14.9. Tek kad se uspješno pređe ključna tačka može se započeti sa slijedećom aktivnosti. Aktivna mreža se čita sa desna na lijevo. T12 Slika 14.. M4.6). Jaroslav: Projektovanje informacionih sistema 239 Pristupa se izradi mrežnog plana na osnovu definisanih zadataka i zavisnosti (slika 14. ako T8 kasni ne bi trebalo uticati na krajnji datum. slika 14. Ako se aktivnost ne završi na vrijeme. Prekoračenje vremenskog roka najčešće je vezano uz kritični put. M2. Kritični put. Minimalno vrijeme potrebno za završetak projekta se može procjenjivati prema kritičnom putu. jer T8 ne leži na kritičnom putu). ).6). Aktivnosti koje kasne. .

7. 14. Raspodjela zadataka Štapićasti dijagram (gantogram). Angažovanje ne mora biti kontinuirano.10. pokazuje razdoblje u kojima je osoblje angažirano na projektu (slika 14.8). Tabela 14. Osobe mogu raditi na drugim projektima. Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Inženjer Nada Ana Nada Pero Mile Ana Igor Pero Nada Ana Pero Pero . Za razmatrani primjer prikazano je tabelom 14.2.240 Poliščuk E. ići na odmor ili obavljati neke druge aktivnosti. takođe. Primjer gantograma sa prikazom vremenskog rasporeda.2. Jaroslav: Projektovanje informacionih sistema Slika 14.

9. Evidencija projekta Za planiranje. CASE alati za planiranje.Poliščuk E.8. MS Project. Primjer vremenskog angažovanja osoblja pomoću gantograma. npr. Ekranske forme CASE alata za upravljanje projektima su prikazani na slikama 14.10. CA Process Continuum. praćenje istorije projekta mogu se koristiti različiti programski proizvodi.11. upravljanje. 14. Slika 14. Primjer ekranske forme CASE alata za upravljanje projektima. .9 i 14. Jaroslav: Projektovanje informacionih sistema 241 Pero Nada Ana Igor Iva Slika 14. praćenje napretka.

242 Poliščuk E.10. Postavljanje projektnih ograničenja Napraviti početnu procjenu projektnih parametara Definisanje ključnih tačaka i izvještavanje while projekt nije završen ili otkazan loop Nacrtaj vremenski raspored projekta Podijeli aktivnosti prema vremenskom rasporedu Čekaj Provjeri napredak projekta Revizija procijenjenih projektnih parametara Ažuriranje vremenskog rasporeda projekta Provjeri projektna ograničenja i izvještaje If (povećanje problema) then Ponovni tehnički pregled i moguća revizija end if end loop . 14. Drugi primjer ekranske forme CASE alata za upravljanje projektima. šta se može prikazati slijedećim programom. napisanom pomoću pseudokoda.12. Jaroslav: Projektovanje informacionih sistema Slika 14. Praćenje napretka (izvršenja) projekta Upravljanje projektom podrazumjeva stalni nadzor napredovanja.

tj. a pažnju usmjeriti na probleme koji se trenutno rješavaju. Načelno je dovoljan jedan plan (i pregled realizacije) mjesečno. Po potrebi treba prerasporediti postojeće poslove.13. 14. Takve je dovoljno predvidjeti i najaviti. . dok je na slici 14. Jaroslav: Projektovanje informacionih sistema 243 Na slici 14. Poslove i zadatke treba uravnoteženo raspodijeliti. Konkretno razdoblje za koje se radi plan može varirati u zavisnosti o veličini projekta. P1 prilagođavanje plana D1 plan projekta P2 praćenje napretka O rukovodilac projekta a član ekipe D2 radnih sati evidencija Slika 14. Zadatak Izvršioci Planirani početak Planirani završetak Prioritet Planirano trajanje Stvarno trajanje Status % ispunjenja Stvarni završetak Kašnjenje Komentar Slika 14.12.Poliščuk E. Primjer tabele za evidentiranje napretka. Primjer dijagrama za praćenje napretka. Izbjegavati detaljno planiranje poslova koji slijede u daljoj budućnosti. Više pažnje treba posvetiti članovima koji zaostaju u izvršenju plana ili rješavaju složeniji problem u odnosu na ostale članove. prilagođeni stvarnom stanju.12 prikazan primjer tabele za evidentiranje napretka.11 je prikazan primjer dijagrama za praćenje napretka projekta. Planovi trebaju biti što kraći. kako se vrijeme ne bi trošilo na detaljiziranje koje zbog moguće promjene stanja ionako neće biti istinito. Preporuke za planiranje poslova Planiranje poslova: Planovi moraju biti ažurni.11. s tim da uključuje raspored nedjeljnih aktivnosti.

Materijali. raspodjela moći i odgovornosti (ravnopravnost. Tmp. čuvanje informacija (mrežni rječnik. forma. Sastanci moraju biti pripremljeni (mjesto. sporo i jasno govori. Jaroslav: Projektovanje informacionih sistema Komunikacija može biti: verbalna (brzo slušaj i misli. a ne osoba). zapisivanje odluka (zapisivanje da bi se izbjegla pogrešna tumačenja). pisana (sadržaj. izbjegavanje "jedinih" rješenja (traženje alternativa). Chat. teme. konstruktivne povratne informacije (kritikovanje postupaka. elektronska (E-mail. itd). učesnici)! Tehnike za poboljšanje rada: Brainstorming (iznošenje ideja). Backup. vrijeme. učestalost). bilježi izrečeno). Druženja moraju biti efikasna! Izbjegavati raspravu o opštepoznatim ili nevažnim stvarima. News). FTP rječnik. . elektronskom poštom). Projekt.244 Poliščuk E. izbjegavanje hijerarhije). obavještavanje (pismenim putem. web server) ili u obliku organizacije rječnika (Admin. razumijevanje neuspjeha (analiza i poboljšanje svega što nije dobro). Rasprave treba prekinuti u trenutku kada se pretvore u razgovor o temama koje se ne odnose na posao.

te prelazak na novi način rada. Izrada plana konverzije (migracije) za uspješan prelazak na novi sistem. tj programima za premošćavanje. Uvođenje sistema može biti neposredno i paralelno. vidjeti tačku 12. Mogući problemi su pojava grešaka koje nisu bile uočene tokom testiranja. a zatim i na ostalim lokacijama.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 245 15. Uvođenje sistema u primjenu Uvođenje u primjenu projektovanog informacionog sistema uključuje instalisanje opreme. Nedostatak je potreba za dvostrukom obradom istih podataka. Poduka tehničkog osoblja i krajnjih korisnika. evaluacija projekta i sistema. nepredviđeno preopterećenje opreme u punom pogonu. Postupno uvođenje je uvođenje grupa lokacija. 5. Primjena i održavanje informacionog sistema 15. Probno uvođenje je neposredno/paralelno uvođenje sistema na jednoj lokaciji. 2. 3. 4. što stvara otpor korisnika. koja može biti verbalna ili putem raspodjele dokumentacije. prenos postojećih podataka uz konverziju. Mogući problemi su potreba za spojnim programima. Bitno je manje rizičan postupak u odnosu na neposredno uvođenje. Nedostatak je neposredna izloženost korisnika greškama sistema. . Paralelno uvođenje podrazumjeva istovremeni rad starog i novog sistema tako dugo dok se ne pokaže da novi sistem ispravno radi i da su se korisnici navikli na novi način rada. prelazak na novi način rada. Definisati način uvođenja.1. uvođenjem po dijelovima. uobičajeno nakon završetka poslovnog razdoblja. dok istovremeno uvođenje predstavlja jednovremeno uvođenje na svim lokacijama. Konverzija sistema. Aktivnosti i preduslovi su: 1. po mogućnosti na kraju sedmice. uspostava sistema zaštite i održavanja. nakon što se utvrdi da sistem ispravno radi. Instalacija opreme. Modularno uvođenje je postupna zamjena starog sistema novim. izradu plana testa prihvatljivosti ukoliko nije urađen ranije. Izvodljivo je samo ako je moguć istovremeni rad oba (nekompletna) sistema. aplikacija i baze (baza) podataka novog sistema. Provodi se na određeni dan. odgovornosti. resurse i redoslijed izvedbe. Testiranje sistema. poslove. u starom i u novom sistemu.5. inicijalni unos podataka. završni prenos podataka. Neposredno uvođenje podrazumjeva početak rada novog sistema uz istovremeni prestanak rada starog sistema. Korisnici mogu biti raspoređeni na različitim lokacijama.

Postupci i tehnike obuke su kursevi. Bez obzira kako je dobro sistem dizajniran. upotreba personalnih računara). funkcije sistema i način upotrebe sistema.3. ali se ona uobičajeno provode.). Jaroslav: Projektovanje informacionih sistema Karakteristike različitih načina uvođenja sistema u primjenu su prikazani u tabeli 15.1. odjel informatike ili grupa za to odabranih i osposobljenih radnika) ili vanjski izvođači obuke.3. Prvo se obavlja obuka tehničkog osoblja koje će održavati sistem i pružati podršku krajnjim korisnicima. 15. administriranje baze podataka. Obuku mogu obaviti radnici naručioca (npr.2. prikladna dokumentacija i podrška tokom primjene. Održavanje samo po sebi ne podrazumijeva ugradnju poboljšanja ili novih mogućnosti. Obuka korisnika IS Vrši se obuka tehničkog osoblja korisnika i krajnjih korisnika sistema. ili obuku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr. Nakon toga treba obrazovati (niže) rukovodstvo. konstruisan i testiran.1. greške će se neizbježno pojaviti! Ispravljanje grešaka u primjeni se naziva održavanjem sistema ili održavanjem programa. Slijedi školovanje (krajnjih) korisnika. da bi se mogla pokrenuti primjena IS. Redoslijed obuke je slijedeći. Uvođenje Rizik Trošak Trajanje neposredno paralelno ostalo visok nizak srednji niski (ako uspije) visok srednji kratko (ako uspije) dugo varijabilno 15. kvalitetni sistem interaktivne pomoći. . probni rad u fazi provjere rada sistema. koje treba prilagoditi funkcijama koje oni obavljaju u svakodnevnom radu. Održavanje i nadgradnja Održavanje je trajna aktivnost koja započinje odmah nakon uvođenja sistema u primjenu. operaciona istraživanja.1.246 Poliščuk E. Obuka tehničkog osoblja može uključivati operativni sistem i uslužne programe. Održavanje informacionog sistema 15. programske jezike i CASE alate. to jest korištenje aplikacija. da bi se stekla njegova podrška pri obuci ostalih korisnika tokom primjene. Tabela 15. projektovanje primjenom računara i sl. Obuka krajnjih korisnika može uključivati opštu informatičku kulturu (npr.

Editovanje i testiranje.4. Potrebno je poznavanje programa. 15.2. kao i ažuriranje dokumentacije. Bekap se obavlja periodično (dnevno. Adaptivno održavanje je prilagođavanje funkcionalnosti (načina posluživanja).3. ako je ta bila bolja. Održavanje . odnosno upravljanje verzijama. Ocjenjivanje sposobnosti. prilagođavanja strukture (promjene strukture podataka) ili poboljšanje performansi (optimizacija programa). Većina . tj. Potrebno je vršiti redovnu izradu sigurnosnih kopija (backup).Poliščuk E. da bi se izbjegle različite verzije u primjeni kod različitih korisnika. sedmično. analiza novih zahtjeva i povratak u odgovarajuću fazu (analiza. ponavljanje svih testova da bi se provjerilo da izmjene nisu uzrokovale nove greške.3. dizajn. odnosno problem reprodukcije greške. Nepostojanje funkcije čija ugradnja nije bila planirana nije bug. 15. Perfektivno održavanje je nadgradnja sistema da bi se riješili novi problemi ili ugradnja novih mogućnosti. Takođe je potrebno regresivno testiranje. te tako započinje novi ciklus razvoja. programi treba da budu “izmjereni” da bi se utvrdila osnovica prema kojoj će se ocijeniti izmijenjeni programi. Poboljšanje sistema i reinženjerstvo Poboljšanje sistema je dorada i nadgradnja sistema prema novim zahtjevima. Neophodna je mogućnost povratka na prethodnu verziju. Vrši se vraćanje podataka iz sigurnosne kopije (restore) ili uklanjanje uzroka greške (ispravljanje programa). Pod korektivnim održavanjem se podrazumijeva popravka nakon što se problem pojavio. izrada). 15. mjesečno). problem različitog tumačenja greške koje nastaje uslijed nerazumijevanja ili pogrešnog korištenja programa. Jaroslav: Projektovanje informacionih sistema 247 Tokom primjene i održavanja obavlja se analiza dodatnih zahtjeva. planiranje i priprema aktivnosti koje slijede. Održavanje može imati neželjene popratne učinke na funkcionalnost i performanse aplikacija.servisiranje sistema Preventivno održavanje sistema podrazumijeva zaštitu od mogućih problema.3. Uklanjanje grešaka i izmjene programa Definicija i validacija problema podrazumjeva uočavanje uzroka grešaka u primjeni (bugova). Prije izmjene programa.

ispravka sistema prije nego što dođe do mogućeg prekida u radu. Reinženjerstvo je adaptacija sa ciljem smanjenja troškova održavanja. Poboljšanja i reinženjerstvo moraju biti planski provedeni. uslijed zastarjelosti tehnologije).1. kao i ispravka sistema koji će biti lakše popraviti ako dođe do prekida. Jaroslav: Projektovanje informacionih sistema novih zahtjeva uzrokovana je promjenama u poslovanju. Reinženjerstvo.5. Konfiguracija je imenovani skup konfiguracijskih elemenata u određenoj tački životnog ciklusa. Primjeri takvih programa su pretraživanje i pregledanje podataka. Jednostavni program je onaj program koji koristi samo postojeće podatke. Slika 15. Elementi konfiguracije Element konfiguracije (prema IEEE) je agregacija hardvera i/ili softvera koja se tretira kao jedinka u procesu upravljanja konfiguracijom. odnosno prilagođavanje većim promjenama tehnologije. potrebama za dodatnim informacijama ili novim idejama (željama korisnika). kao i generisanje izvještaja. Rezanje koda ili odsjecanje koda je izdvajanje dijelova programa radi izrade odvojenog programa ili potprograma. . Konfiguracija elemenata u određenoj tački životnog ciklusa. Reinženjerstvo programa je reorganizacija koda. a trošak održavanja pojedinih aplikacija može doseći trošak izrade novih. Konverzija koda je prelazak na novi programski jezik.248 Poliščuk E. Prelazak na novu tehnologiju upravljanja podacima predstavlja veliki rizik. odnosno restrukturiranje organizacije modula ili programske logike. Restukturiranje datoteka i baza podataka je promjena strukture u postojećoj bazi podataka. Neke aplikacije je teško održavati (npr.1. slika 15. Pisanje jednostavnih novih programa. Ove promjene su najčešće i najsigurnije. 15.

v1.4. Na slici 15. npr.1 V 1. • varijanta (variant) – alternativa originalu (hardverska platforma. • objava. • revizija (revision) – ona koja se koristi umjesto originalne. isporuka (release) – originalna verzija u primjeni.1. release) proizvoda.1 V 1.2.2. podrazumijeva izmjene u određenim vremenskim intervalima. živi paralelno sa njim. zadnja v2.0 V 1. npr. v1.1. V 1.0 V 1. različiti jezik).2 V 2.2 V 1. Jaroslav: Projektovanje informacionih sistema 249 Verzije konfiguracije su slijedeće: • verzija (version) – određeno izdanje (issue.4.1 V 1.1.2.2.0.2 shematski su prikazane navedene verzije konfiguracije.1.2 Slika 15. Verzije konfiguracije. .1.2.1. npr.Poliščuk E.

250 Poliščuk E. Jaroslav: Projektovanje informacionih sistema .

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

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

J. Taylor & Francis Group.: Neki problemi korišćenja informacione tehnologije. INFO SCIENCE.: The Analysis Of Experimental Results Of Machine Learning Approach. PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka. 215-233. J. vol. ISSN 0929 – 6174.stručni skup: Informacione tehnologije – sadašnjost i budućnost. Comunication and Computer Sciences.3. Elektrotehnički fakultet. 48.: The Machine Learning Method: Analysis of Experimental Results. ISSN 1109 . Zbornik radova '92 “OFFICE AUTOMATION”. 51.: Informatičko obrazovanje "inženjera budućnosti". 52. . 1992. Poliščuk E. Poliščuk E. 47. 2004. Poliščuk E. and Stojanovic. Apatin. IX međunarodna konferencija "Informatika u obrazovanju.2777. No. Zrenjanin. Poliščuk E. 1998. Poliscuk E. R. 27. 2004. Univerzitet u Novom Sadu. J. J. III međunarodni simpozij informacijske i komunikacijske tehnologije u uredskom poslovanju '92 "OFFICE AUTOMATION". Novi Sad. Zbornik radova sa VI naučno – stručnog skupa IT ‘01.sadašnjost i budućnost. J. IV naučno . WSEAS Transactions on Systems. 2003. Poliscuk. časopis Jugoslovenskog informatičkog saveza . Poliščuk E. Žabljak. ISSN 0351-1804. Zbornik radova sa IV naučno – stručnog skupa IT '99. Sveučilište u Zagrebu. J. No. Vol. J. 57. Issue 10. J. pp. Zbornik radova I. Journal of Information and Organizational Sciences. Poliscuk. 2001. 1991. E.: Novi pristup razvoju informacionih sistema. 1998. 53. Poliščuk E. Univerzitet u Novom Sadu. Varaždin. 11. E. J. Zbornik radova. 1996. 1.: Some Features of Object Data Management Concepts. 1999. 58. Zbornik radova. 55. 1996. J. Jaroslav: Projektovanje informacionih sistema 253 45. V međunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije". kvalitet i nove informacione tehnologije". 29-42. Poliščuk E. 50. Vol. J. Beograd. 1992. 54. Beograd. 3248 – 3253. Podgorica. VI međunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije".: Neki aspekti razvoja sistema za podršku odlučivanju. pp. E. J. 1995. Beograd.stručni skup: Informacione tehnologije .: Neke osobine sistema za objektno upravljanje podacima. Poliščuk E. Univerzitet u Novom Sadu. 2000. PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka. J. Poliščuk E. D. Journal of Quantitative Linguistics. 3. VI naučno .: Koncepti objektno orijentisanog modela podataka. 56. Beograd.Poliščuk E. J.: The Intelligent Agent: An Analysis of the Experimental Results. Žabljak. 46. Journal of Information. Poliščuk E.: Informatička organizacija ili "organizacija budućnosti". 49. Poliscuk. JISA INFO.: Projektovanje informacionih sistema (skripta).: Koncepti hijerarhija klasa i naslijeđivanje u objektno orijentisanom modelu podataka. pp.: Savremeni pristup razvoju informacionih sistema.

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

Sign up to vote on this title
UsefulNot useful