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

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

.................................................................13...3............................. 14................................... 15..... 13.................... 251 ................. Evidencija projekta ............ 15.. Upravljanje projektom ............. Literatura ...............................4.................... Obuka korisnika IS .......................................................................... 13............................ Generički modeli organizacije ...... 15.......... 14.....Poliščuk E........... 14.......... Programiranje (kodiranje) .................2........................... Primjena i održavanje informacionog sistema ....3......................... Preporuke za planiranje poslova .........2.............6.......................8.....................................................1............................... 14.. Dijagram toka (blok dijagram.................... 13....................3............... Izrada sistema ....6.........................3................................... Strukturirani prirodni jezik (pseudokod) ....... 13..... Izrada dokumentacije ...................... Akcioni dijagram ............................. 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....... Implementacija informacionog sistema ................................................................. Prikaz plana .......7.......................................... 15.......................... Planiranje projekata ........... 14............. 14.......................5.......... Tehnike za vremensko planiranje ...................10........ 14...... Raspodjela zadataka ................................. Stablo odlučivanja .......................................................................................................................1.......2......9....................5............4.. Održavanje informacionog sistema ..................................... algoritam) ..........5...................................1......... 12..... Programski standardi i preporuke .................................... 14.........................12...................................4................................................. Logičko projektovanje programa i programski jezici ............2.......................................................................... 14........................................... 13............ Organizacija velikih projekata .....7................. Elementi konfiguracije ................... 14................................................ 14.................................................. Uvođenje sistema u primjenu ............ 12.............. Izrada plana ..................................................4............................................................................................1....................................................................... Programski jezici ........ 14.. 13........ Modeli timova ...11........ 14................................. 15... 12........ 12.................... Organizacija i timski rad . Organizacija i upravljanje projektom ................................... 12............................ Praćenje napretka (izvršenja) projekta ...................6..................5.................. Provjera ispravnosti informacionog sistema ........ Poboljšanje sistema i reinženjerstvo ........... Struktogram ........................................................................................... 14..................................................................................... Pristup programiranju ................. 12....... 13... Tabele odlučivanja .... 15. 13....................

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ocjenjivanje kriterijuma za izbor sistema Na osnovu opisa karakteristika ne može se sa sigurnošću procijeniti koji je sistem najbolji. Ulazi su napravljena analiza izvodljivosti. 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 . od 1 do 4). Prijedlog rješenja sistema koji će se oblikovati i ugraditi se donosi na osnovu izbora onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivosti.9. procjena veličine projekta. 2005]. a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloženog sistema. plan projekta. a izlazi analiza izvodljivosti za svako moguće rješenje. karakteristike i cijene hardvera i softvera. Procedura bodovanja kriterijuma je slijedeća. te se dobije broj bodova [Fertalj & Kalpić. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. Odredi se težinski faktor za svaki kriterijum (npr. Tabela 2.1. 2. od 0 do 5).Poliščuk E. Jaroslav: Projektovanje informacionih sistema 25 karakteristike mogućih rješenja. referense i uslovi dobavljača. Oni kriterijumi koji su značajniji u uporedbi sistema dobivaju veće težinske faktore.1. Da bi se pravilno uporedio značaj različitih kriterijuma koristi se sistem bodovanja. Primjer: Analiza izvodljivosti za moguća rješenja. Dodjeljena ocjena se pomnoži težinskim faktorom kriterijuma za koji je donesena.

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

2. tačne. Analiza organizaciono . opreme.2. itd.operativne izvodljivosti projekta sadrži procjenu hitnosti rješavanja problema (planiranje). Praktično gledano. ali i kasnije. novca. (5) eventualni povratak u studiju izvodljivosti.1. 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). ekonomiske aspekte (gdje spadaju problemi troškova i mogućnosti ušteda). zadovoljstvo). elastičnost i mogućnost prilagođavanja. Analiza izvodljivosti projekta Za pojedine projekte se vrši analiza njihove izvodljivosti. (3) procjenjuje se da li projekat omogućava poboljšanja. odnosno revidirani izvještaj. točnost procjene izvodljivosti raste sa dubinom analize. (2) procjenu da li je projekat izvodljiv obzirom na raspoloživa sredstva.Poliščuk E. 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. odnosno mjerenje korisnosti. informacije (da li su dovoljne.2. Izvještaj o izvodljivosti projekta Izvještaj o izvodljivosti projekta sačinjavaju slijedeće analize: • • • • organizaciono . ekonomska izvodljivost. kao i procjenu prihvatljivosti rješenja (kasnije faze). 2. Ove analize treba da se vrše tokom planiranja. troškova i koristi projekta 2. korisne). pravovremene. tehničko . ažurne. Analiza izvodljivosti. npr. Treba na vrijeme uočiti otpore ulozi ili tehničkim .operativna izvodljivost.). vremenska izvodljivost. koju provode sistem analitičari. nakon faze sistemske analize.tehnološka izvodljivost. (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). prikladne. kontrolu (u prvom redu sigurnost i zaštitu podataka). kao i usluge (poželjni i pouzdani servisi. Studija izvodljivosti (feasibility study) sadrži: (1) detaljnu provjeru projekta. praktičnosti i isplativosti projekta IS. efikasnost (odnosno poboljšavanje upotrebe raspoloživih resursa: ljudi. Jaroslav: Projektovanje informacionih sistema 27 2. Nakon odluke o pokretanju projekta složenost i opseg projekta se mogu promijeniti.2. te početno izvodljiv projekat može postati neizvodljiv.

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

Nizak ROI (~ manji od 10% godišnje) može pokazivati da je korist preniska da bi bila isplativa. Jaroslav: Projektovanje informacionih sistema 29 • Korist projekta u iznosu od $30.417 Povrat investicije (Return On Investment (ROI)) se obično dijeli sa dužinom trajanja projekta kako bi se dobio godišnji ROI.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. Primjer: Analiza trošak – korist [Fertalj & Kalpić. . 2005].2.000 / (1 + 0. Tabela 2.Poliščuk E.

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

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

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

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

Izrada slijedeće faze/verzije programa.Kratko objašnjenje sadržaja izvještaja Prikupljene informacije . 11.4. 9. Izvještaj o projektu Izvještaj o projektu obrađuje probleme i dostignuća projekta. 14.34 Poliščuk E.Zahtjev za uslugama sistema .4. Uvođenje korištenja programa kod ostalih korisnika. a može imati oblik prikazan tabelom 2. Testiranje kod korisnika u paralelnom radu sa dosadašnjim programom. Nabavka sistema za upravljanje bazama podataka. tabela 2.6. 16. 4. 2. 12. Povratak na tačku 5). 1.Kratak opis projektnog zadatka .verzije u informacionim sistemima.5. 13. Tabela 2. Jaroslav: Projektovanje informacionih sistema Primjer: Početni (preliminarni) plan informacionog sistema.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 . 3. Obuka opšte informatičke pismenosti za rukovodioce odjeljenja. Obuka za administratore baze podataka. Uklanjanje nedostataka i izrada stabilne verzije. Testiranje α . Obuka za ostale korisnike. 7. Izrada prototipa programske podrške za i-tu fazu realizacije. Obuka za upoznavanje sa mogućnostima programa za odabrano poslovodstvo. • Sažetak . Zamjena dotadašnjeg programa novim programom.(ostala dokumentacija) .5.verziji.verzije aplikacije.Sažetak prijedloga .Matrica obrazloženja problema . Tabela 2. 10.verzije programa. 8. 6. 5. 2.3. 15.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 . Uklanjanje uočenih nedostataka i izrada β . Izrada α . Obuka za odabrane korisnike na β . uz preuzimanje podataka. Prikupljanje primjedbi korisnika i novih zahtjeva. 17.Kratko obrazloženje očekivanih koristi . Obuka za programere u jeziku za upravljanje bazama podataka.

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.. Određivanje poslovnih ciljeva Za projekte koji prođu početnu selekciju vrši se produbljivanje analize problema. Mogu se koristiti različite formalne metode.koristi. Uzroci i posljedice problema. odnos cijene i kvaliteta proizvoda. 3. Planiranje poslovnog sistema (Business Systems Planning (BSP)) firme IBM. Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rješavanja i da li je gradnja IS isplativa. a može biti posljedica pomanjkanja osoblja. Analiza kritičnih faktora uspjeha (Critical Success Factors (CSF)). kojima poslovodstvo posvećuje posebnu pažnju.3. od kojih su najznačajnije: 1. odnosno činilaca. koji mogu biti raznovrsni. 2. Jaroslav: Projektovanje informacionih sistema 35 2. .8. Ti činioci treba srazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr. njihovih uzroka i posljedica. Vrši se detaljnija analiza problema.3.. 2. . odnosno analiza poslovnih procesa analizom od vrha prema dolje i uočavanje podataka povezanih sa procesima. Drugi primjer: Dug red u videoteci nije poseban problem. ciljevi i ograničenja Istraživanje uzroka problema. ). Analiza izvodljivosti i procjena troškova . 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica ručnog unosa podataka i izdavanja računa. brzi odgovor na zahtjeve klijenata. 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.7.Poliščuk E.

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

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

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

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

Tim rezultatima se testiraju elementi IS na različitim stepenima razvoja.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. Analiza Analiza Oblikovanje Izrada Evaluacija Primjena Primjena (a) (b) Oblikovanje Izrada Evaluacija Slika 2. 1.1(b)) sadrži povratnu vezu i mogućnost promjene rezultata prethodnih faza. Prikladan je kada se unaprijed ne zna konačni izgled sistema. programskih jezika četvrte generacije (4GL) i generatora aplikacija. . Radikalni (strukturirani) razvoj (slika 2. 2. Ovaj model razvoja IS omogućava primjenu tehnika strukturiranog programiranja.2. Uporedni prikaz klasičnog razvoja (a). “V” model razvoja informacionog sistema “V” model razvoja IS (slika 2. Dozvoljava korištenje rječnika podataka.40 Poliščuk E.4. Jaroslav: Projektovanje informacionih sistema Pseudostrukturirani vodopadni model (slika 2. pseudostrukturiranog i radikalnog razvoja (b).

Poliščuk E. Model oponašanja (model u prirodnoj veličini).4. 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.3. Prototipski model razvoja informacionog sistema Uz strukturirani pristup. odnosno jednoekranski ili . koji su integrisani sa okruženjem četvrte generacije.2. 2. U zavisnosti od njegove namjene. mogu se uočiti slijedeće tri vrste prototipskog modela. prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa. Primjer “V” modela. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. “usitnjavanje” razgovora i često udaljavanje od tema.Poliščuk E. 2000]. Otpor sjednici je srazmjeran nivou položaja konkretnog učesnika. 3. Razlog tome može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak . Njihovim organizovanjem se izbjegavaju specifični (egzotični) i nejasni zahtjevi. 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. Slika 3.3. Prostor za radne sjednice [A. Sjednice treba da traju više dana (5 do 10) u nekoliko sedmica. ali teško prihvataju nove ideje. Jaroslav: Projektovanje informacionih sistema 65 koristan tamo gdje postoje korisnici koji dobro poznaju sistem. Nedostaci radnih sjednica su pasivnost učesnika.Dennis & B. Ovom zahtjevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika. Systems Analysis and Design. 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. 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.11. jer se podrazumijeva da je informatizacija isključivo njihov posao. John Wiley & Sons.

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

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

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

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

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

Poliščuk E. Koliko dugo ostaje vidljiva?. Primjećuje se da u zahtjevu nije detaljno opisano kako i gdje će se poruka ispisivati. Problem je rastavljen u više zahtjeva budući da će svaki zahtijevati posebno testiranje. To će biti odlučeno tokom dizajna. Ukoliko je više zahtjeva grupisano u jedan lakše je previdjeti neki od njih tokom izrade ili testiranja. Modul za nadzor će ispisati "Zadatak obavljen" nakon što se zadatak obavi. student . Dosadašnja praksa je bila da svaki izvršilac usluga izdaje svoje bonove koji se mogu koristiti samo u određenim restoranima. Modul će ispisati poruku o grešci ukoliko dođe do zastoja u izvođenju. Koji dio proizvoda će ispisati poruku?. modul za nadzor će ispisivati postotak obavljenog posla. smještaj u studentskim domovima. Ukoliko se pozadinski zadatak izvodi normalno. itd. Ukinuti plaćanje unaprijed: Treba izbjeći bilo kakvo plaćanje od strane studenata za potrebe ostvarivanja prava. kina. npr. javni prijevoz po povlaštenoj cijeni. 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. Koliko doslijedni intervali moraju biti? Zahtjev definisan preciznije i detaljnije: Modul za nadzor će ispisivati statusnu poruku u za to određeni dio interfejsa. Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemogućiti zloupotrebu stečenih prava. 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. Jaroslav: Projektovanje informacionih sistema 71 U idealnom slučaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima! Primjer 2: Zahtjevi krajnjih korisnika. Zahtjev "Softverski proizvod će ispisati statusnu poruku u redovnim intervalima. Primjer 4: Neostvariv zahtjev. Primjer 3: Nepotpuni zahtjev. cijeli dokument ili nešto . Lakše ostvarivanje ostalih prava iz studentskog standarda. 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. Poruka će se ažurirati svakih 60 s (±10 s) nakon što započne izvođenje pozadinskog zadatka i biće vidljiva cijelo vrijeme. pozorišta. ne manjim od 60 sekundi" nameće slijedeća pitanja: Šta je statusna poruka i pod kojim uslovima će biti ispisana?.servis. a naročito unaprijed.

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

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

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

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

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.

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

Dijagram organizacije. Jaroslav: Projektovanje informacionih sistema Dekan XXX Sekretarica XXX Prodekan za nastavu XXX Stud. Slika 5. 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.Ekranska forma CASE alata Repository Object Navigator (Designer 2000. .6. ORACLE).5.82 Poliščuk E.

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

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

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

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

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

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

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

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

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

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

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

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

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

tok dokumenata ili tok upravljanja (npr. Opisivanje podataka Rječnik podataka (Data Dictionary) je mjesto pohrane definicija elemenata podataka i struktura podataka. = + () {} [] | 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.19.96 a Poliščuk E. Standardno se upotrebljava BNF notacija (Backus-Naur Form). tj. ni jednom do konačni broj puta Alternativa (selekcija) elemenata u zagradi Odvajanje alternativnih elemenata u [ ] izrazu . kao i posebnih simbola za tok resursa. Predstavlja strukturirano spremište meta-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. različite linije ili ikone). koja se inače koristi za opis sintakse programskih jezika. podataka o podacima. tabela 5. zatim posebnih simbola za prikaz ponavljanja procesa.1. Notacije koje se koriste kod izrade DTP. 5. za pohranu opisa spremišta podataka i tokova podataka.6. Prvobitno se pojavio kao proširenje dijagrama toka podataka.3. koji prikazuju učestalost procesa (npr. tri puta dnevno). razdvajanje i spajanje tokova (alternativni tokovi). Može se koristiti kao alternativna tehnika za prikaz modela podataka. Tabela 5. Proširenja modela je izvršeno uvođenjem okidača (trigera).1.

šta definiše strukturu podataka.20. Vrijednost } + (IznosRac) Može se napisati i kao: Racun = @BrRac + DatRac + BrKupca + { StavkaRac } + ( IznosRac ) StavkaRac = @SifArt. odnosno elementarnih podataka. kao i tokove podataka (slika 5. Primjer opisivanja podataka.20). Cijena. Kol. Nakon toga se opisuju grupe sačinjene od elementarnih podataka. NazArt. Kol. 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. Racun = @BrRac + DatRac + BrKupca + { SifArt. NazArt. . Vrijednost Primjer: Opis podataka može započeti opisom najmanje logičke cjeline podataka. 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. Cijena.Poliščuk E. Struktura podataka određuje sadržaj spremišta podataka.

2. 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: . Budući da se ne kreiraju automatski na osnovu prethodno unesenih opisa (modela procesa i modela podataka).4. Jaroslav: Projektovanje informacionih sistema 5.3). Opis procesa sadrži algoritam zadatka koji se procesom obavlja. u zavisnosti od alata. ali imaju nekoliko zajedničkih elemenata: naziv i broj procesa. Primjer 1: Definisanje procesa (1). 2005]. kao i tijelo opisa procesa. Mogu poprimiti različite oblike. Na osnovu ovog algoritma može se. listu podataka koji ulaze u proces (ulazni tokovi podataka). koji može poprimiti različite oblike (dizajn programa.98 Poliščuk E. generisati programski kôd (tabele 5. Mini-specifikacije kreira korisnik CASE alata.2 i 5. neosjetljive su na izmjene dijagrama [Fertalj & Kalpić. odnosno opis programske logike). Elementarni procesi Mini-specifikacije (funkcionalne primitive) se koriste za opisivanje osnovnih procesa u dijagramu toka podataka. Tabela 5. listu podataka koji izlaze iz procesa (izlazni tokovi podataka).

tj. Film je raspoloživ. pri čemu se radi model procesa poslovnog sistema (globalni model procesa). dodavanjem upravljačkih komponenti i resursa. . Prikupljanje i sređivanje informacija o funkcijama i procesima se može obaviti pomoću tabela prije. Identifikuju se poslovna područja i poslovne funkcije. Primjer 2: Definisanje procesa (2).3. Izrađuju se dijagrami toka podataka sa fizikalnim primjesama. Dizajn sistema se bavi fizičkim modelima procesa. Reinženjerstvo poslovnih procesa je analiza i restrukturiranje poslovnih procesa radi poboljšanja efikasnosti i uklanjanja birokratije.Poliščuk E.4).1. Primjena modela procesa Strateško planiranje sistema predstavlja definisanje arhitekture sistema u okviru strateškog plana. koje uključuju vremensku dimenziju. dijagramom konteksta određuju se domašaj i interfejs sistema). Postojeći procesi se analiziraju i dokumentuju prikladnim modelima procesa. izrade dijagrama (tabela 5. moguće je proizvesti DTP povratnim inženjerstvom postojećih aplikacija. 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. Analiza sistema razmatra aplikacione modele procesa. 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. Teorijski. ali će takav dijagram biti preopterećen fizikalnim primjesama. odnosno logičke modele procesa sistema ili aplikacije. najčešće u obliku dijagrama dekompozicije funkcija ili nerazrađenog DTP (npr. protočnost podataka i troškove.4. ali i umjesto. Jaroslav: Projektovanje informacionih sistema 99 Tabela 5. prije primjene informacijskih tehnologija.

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

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

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

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

@) je atribut ili skup atributa koji (svojim vrijednostima) jednoznačno identifikuju svaki od entiteta u nekom skupu entiteta. dok minimalnost znači da ne postoji podskup atributa ključa koji je.5. koji ne moraju . ).... sastavljeni. Osim navedenih uslova. Jaroslav: Projektovanje informacionih sistema 6. . 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 ... neutralnost (obzirom na značenje vrijednosti ključa). Entitet može imati više mogućih ključeva. . Ključevi Ključ (key) ili identifikator (Id. .. Povezivanje entiteta ili skupova entiteta stranim ključem. . Mora se sastojati od bar jednog atributa (jednostavni ključ): npr. takođe.. stabilnost (otpornost na promjene tokom vremena). 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. dobar primjer: KURS = @OznakaValute + @DatumKursa + . OSOBA = @JMBG + Prezime + Ime. Entitet može imati jedan ili više ključeva.1. tj.104 Poliščuk E. kandidata za primarni ključ. Entitet mora imati barem jedan ključ. a može se sastojati od više atributa (složeni... MJESTO = @ŠifraDržave +@ŠifraMjesta. ulančani ključ): npr. ne smiju postojati 2 osobe sa JMBG=2209964100028).. jednoznačan (npr. MJESTO = @ŠifraMjesta + NazivMjesta. ključ mora zadovoljiti i slijedeće uslove: određenost (postojanje vrijednosti u trenutku stvaranja instance)...3. Ključ mora zadovoljavati uslove jednoznačnosti i minimalnosti. loš primjer: OSOBA = @JMBG + @Prezime + . raspoloživost (dostupnost svim korisnicima). 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.

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

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

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

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

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

mora pratiti istorijat svakog pakovanja hemikalija od trenutka kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen". Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Takođe.1. Jaroslav: Projektovanje informacionih sistema Zanimanje Pripada Stanuje Osoba Zaposlen OrgJed Sastav Proizvod Račun Radnik Saradnik Stavka računa Igla Avion Slika 6. 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. 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.110 2. Mjesto Poliščuk E. Primjer dijagrama entitet–veze jednog preduzeća (prema Martin-u).10.10. 6. Izrada ERD analizom izjava korisnika Dijagrama entitet–veze (ERD) može biti izrađen na osnovu izjava korisnika. Martin-ova notacija. .

Poliščuk E. model podataka sa .1.2.11. Primjer dijagrama entiteti–veze za hemijsku laboratoriju [Fertalj & Kalpić. model konteksta podataka (context data model). 6. Uvod u razvoj modela podataka Može da se razvija jedan od slijedećih modela podataka: globalni model podataka (enterprise data model). Razvoj modela podataka 6.2. 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. model podataka sa definisanim ključevima (key-based data model).

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).

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

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

1 sa stranim ključem transformiše se u identifikaciono slabi entitet bez deskriptora: npr. . Taj ključ može biti spojni ključ.1:0. Po potrebi se može razmotriti udruživanje entiteta u binarnoj vezi 1.N Osoba 1. Prezime.18. Binarna veza 1.Poliščuk E. SlikaOsobe (IdOsobe. … . … . TekstKom). SifProizvoda.1 (1. Slika). Staz). JedCijena. Prezime.19. Staz.N OrgJed Proizvodi Proizvod Zanimanje SifZan NazZan Zanimanje 1. Prezime.1) u jednu relaciju: Osoba (IdOsobe.1:1.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. Komentar (IdOsobe. slika 6. TekstKom). StavkaRacuna (BrRacuna. Osoba (IdOsobe. SifProizvoda. 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.M Cjelina Sastav SifProizvod<FK1> SifDjela <FK2> BrDjelova BrDjelova Proizvodi SifOrgJed <FK1> SifProizvod<FK2> Proizvod Dio Sastav Slika 6. Kolicina) ili kompozitni ključ. Primjeri složenog ključa. Jaroslav: Projektovanje informacionih sistema 119 Identifikaciono slabi entitet naslijeđuje ključ jakog entiteta. StavkaRacuna (BrRacuna.M 0. JedCijena. Kolicina). Osoba (IdOsobe. npr. RbrStRac. … . Primjer ključeva asocijativnog entiteta.1:0. npr. Staz). 0.N Zaposlen 1.18.

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

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

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

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

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

2.2. Primjer matrice događaj/entitet. 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.1. ORACLE. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije. Slika 7.2. prikazan je na slici 7. Jaroslav: Projektovanje informacionih sistema 125 Pojednostavnjeni primjer matrice događaj/entitet za rezervaciju sobe u hotelu Proljeće. 7. Slika 7. Matrica Elementarne funkcije/Tipovi entiteta. .3.Poliščuk E.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.8 je prikazana ekranska forma alata za reverzno inženjerstvo. 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. u okviru SUBP ORACLE/Designer 2000 reverzni inženjering implementacione sheme BP. Generisanje programskih specifikacija (struktura menia. Jaroslav: Projektovanje informacionih sistema 149 generisanje projektnih i programskih specifikacija programskog proizvoda u formatu "razumljivom" CASE proizvodu. ekranskih formi ili formi za izvještaje. na osnovu implementacione sheme baze podataka (npr. se primjenjuju za ostvarenje slijedećih zadataka: 1. pomoću kojeg se želi razviti nova verzija tog programskog proizvoda. Slika 8. u domenu IS. 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. 3. Generisanje implementacionog opisa sheme BP. Na slici 8. Ekranska forma CASE alata za reverzno inženjerstvo. Tehnike reverznog inženjerstva. u okviru SUBP ORACLE/Designer 2000 prevođenje implementacione sheme BP u konceptualnu shemu BP obavlja program Table To Entity Retrofit). obavlja program Capture Design of Database). Generisanje konceptualne sheme BP. podshema i proceduralne logike) na osnovu programskih kodova aplikacija tekuće verzije IS (npr. 2. u okviru SUBP ORACLE /Designer . na osnovu nekih od slijedećih parametara: realnih podataka koji postoje u BP.

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

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

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

Jaroslav: Projektovanje informacionih sistema 153 9.1.2. programsku podršku.Poliščuk E. . u prvom redu računarsku opremu. Specifikacija hardvera i softvera je podloga za nabavku opreme. Primjeri arhitekture sistema.1. sistem zaštite i globalnu podršku aplikacija. komunikacije. 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. 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.2. Arhitektura informacionog sistema 9. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema.

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

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

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

2.4. Izbor arhitekture klijent-server Izbor arhitekture može zavisiti o raspoloživim računarima i mrežnoj infrastrukturi.1. web servis) i baza podataka (npr. server aplikacija odnosno BLL (npr.Poliščuk E.1): Tabela 9.5. mogu se primijeniti sljedeći kriterijumi (tabela 9. Klijent (mikroračunar) Server aplikacija (mikroračunar) Server BP (mikroračunar. Podacima bogate aplikacije (pretraživanje i upiti) sa veoma malo ili bez aplikativne obrade. 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. 9.GUI (u web aplikaciji to je web pretraživač). Troslojna arhitektura klijent-server. i to: klijent . Općenito. Računarsko-zahtjevne aplikacije sa vrlo malo ili bez obrade podataka. Jaroslav: Projektovanje informacionih sistema 157 Često se vrši podjela u tri nivoa. 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). . mali računar ili veliki računar) Aplikaciona logika Logika pristupa podacima Skladištenje podataka Slika 9.

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

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

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

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

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

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

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

odnosno aplikativno upravljanje integritetom. Uvođenje konzistentnosti je dodavanje atributa za čuvanje izvedenih vrijednosti. stvaranjem objekata u rječniku BP. Pravila referencijalnog integriteta. 10. tj.4. čime se pojednostavljuje ugradnja. obuhvata entitetski integritet i referencijalni integritet. ili kaskadnu obradu torki koje referensiraju roditelja koji se ažurira ili briše. npr.not null). strani ključ se smije postaviti na nul-vrijednost (optional null). zamjenik postaje primarni a originalni postaje alternativni ključ. tj. brisanje torki koje imaju odgovarajuću vrijednost stranog ključa (cascade).Direct Referential Integrity). Dijeljenje relacija je smještanje rijetko korištenih atributa u posebnu relaciju. 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). Neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI . Udruživanje relacija je uklanjanje pojedinih relacija stapanjem atributa obične veze 1:1 ili udruživanje nadtipa sa podtipovima kardinalnosti 1:1. Kod referencijalnog integriteta mora postojati vrijednost stranog ključa (mandatory . su postupci prilikom unosa. 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. domenski integritet se ostvaruje postavljanjem ograničenja na skup vrijednosti. Jaroslav: Projektovanje informacionih sistema 165 “Čisti dizajn” je dosljedna ugradnja zamjenika ključa sa samopovećavajućim vrijednostima u sve tabele (relacije) baze podataka. pod uslovom da su slične strukture i sadržaja. To mogu biti atributi čuvanja za izvedenu vrijednost koja se može izračunati agregiranom funkcijom (npr.Poliščuk E. npr: . a svodi se na restrikciju pri unosu. Ugradnja pravila za očuvanje integriteta Očuvanje integriteta. a alternativni ključevi su sa obaveznim atributima i jedinstvenim indeksima. nedefinisanog stranog ključa (null). ažuriranje odgovarajućih vrijednosti stranih ključeva (set null) i postavljanje na standardnu vrijednost (set default). za opšti slučaj. obavezni unos (not null) stranog ključa i provjeru postojanja referensirane torke pri unosu. postojanje opcionog. 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. dok se referencijalni integritet ostvaruje postavljanjem stranog ključa i ograničenja na unos. stanje skladišta. Ugradnja referencijalnog integriteta može biti različita. Entitetski integritet se ostvaruje postavljanjem primarnog ključa. i dolazi do gubitka izvorne vrijednosti stranog ključa. Dolazi do umnožavanja ključeva. ažuriranja i brisanja roditelja ili djeteta i odnose se na: zabranu (restrict).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pero Broj.200x. RAM.11. CPU. .xx. CDR. Jaroslav: Projektovanje informacionih sistema Primjer: Narudžba.HDD.xx. xxxx od xx. xxxx od xx. Veza: Ponuda preduzeća IMB br. HDD.FDD Sredstvo Svojstvo sredstva Slika 10.200x. RAM. 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. Datum. FDD. CRD. Šef Narudžbenica Plan Osoba MBB. Strukturirani prikaz (meta model) za primjer Narudžba. Menadž. Ponuda Narudžba Naručivanje Pravna osoba Fizička osoba Šestium Monitor Štampač Skener Osnovno Tehničko Vrsta sredstva Svojstvo MBO. Narudžbu izradio: Pero Odobrio njegov šef: Ivo Stavke: Računar IMB Šestium: xx kom MBO.CPU. Ivo. Zakon Vrsta događaja Pravni Finansij.184 Poliščuk E.

Poliščuk E. Slika 10.13. 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.12. . Strukturirani prikaz (meta model) aplikacije Prodaja. Primjer ekranske forme aplikacije nad meta modelom.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

220 PSEUDOKOD: Poliščuk E.9. Primjer: Neka je n = 10. 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. tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. inicijalno bilo n ≤ 1. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE. tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n ← n .1 KRAJ RADI oduzimanje_od_n izvršava 9 puta. 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 . Da je.

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

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

14. ⏐ cijena = cijena + (osnovna cijena filma x 1.13.13.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. 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 pseudokoda za Videoteku. . cijena = 0 ako je hit film tada ⏐ rok iznajmljivanja = 1 dan Slika 14. Primjer stabla odlučivanja za Videoteku. Primjer pseudokoda za Videoteku.Poliščuk E.

dok oni koji sadrže oznake "-" budu niže. 2. Fortran i Basic). da/ne ili nisko/srednje/visoko. Kolone u desnom dijelu tabele treba rasporediti tako da u istom redu oznake "" budu ispred oznaka Y.224 Poliščuk E. 4. Tabele odlučivanja Tabele odlučivanja (Decision Tables) predstavljaju tabelarni prikaz preslikavanja skupa ulaznih uslova u skup izlaznih akcija. C. 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. Posjeduju relativno jednostavne uslove. nije uvijek svejedno kojim su redoslijedom napisane akcije. 5. Neki CASE alati. Logika odlučivanja treba da bude nezavisna o tome kojim redoslijedom su uslovi napisani. Pascal. koji podržavaju ovaj način izrade specifikacija. npr.1. Međutim. Jaroslav: Projektovanje informacionih sistema 13.1. 3.5. Pravila izrade tabela odlučivanja Prilikom izrade tabela odlučivanja preporučuje se koristiti slijedeća pravila: 1. Potrebno je izbjegavati eventualno dupliranje izraza i značenja. Predstavljaju dobro sredstvo za opis poslovnog odlučivanja.5. a ove ispred znakova N. generišu programski kôd različitih jezika (npr. 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. Primjer: Proširena tabela odlučivanja za zoološki vrt Životinje. . kao i ograničene skupove mogućih odgovora. Tabela 13.

15.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. Na slici 13. Sekvenca Selekcija Iteracija Slika 13. Politika iznajmljivanja filmova hit film ukupni broj filmova veći od 6 ukupni broj filmova 3 . Znatno je prikladniji od dijagrama toka. Nassi-Shneiderman dijagrami su pogodni za reverzni inženjering programa pisanih u C programskom jeziku i za generisanje koda. Jaroslav: Projektovanje informacionih sistema 225 Primjer: Proširena tabela odlučivanja za Videoteku. Tabela 13. Neprikladan je za ručnu izradu. naročito kada ga je potrebno često mijenjati.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. cijena filma x 1.2.Poliščuk E.16 je prikazan Nassi-Shneiderman dijagram urađen pomoću CASE alata Xper-C. Struktogram Struktogram (Nassi-Shneiderman Chart) je grafički prikaz programskih struktura. Osnovni elementi struktograma.6. . Osnovni elementi struktograma su prikazani na slici 13.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jaroslav: Projektovanje informacionih sistema Slika 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 . Tabela 14.8). takođe.2. Raspodjela zadataka Štapićasti dijagram (gantogram). Primjer gantograma sa prikazom vremenskog rasporeda. Za razmatrani primjer prikazano je tabelom 14.10.2. 14.240 Poliščuk E.7. Angažovanje ne mora biti kontinuirano. pokazuje razdoblje u kojima je osoblje angažirano na projektu (slika 14. ići na odmor ili obavljati neke druge aktivnosti.

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

napisanom pomoću pseudokoda.242 Poliščuk E. 14. Jaroslav: Projektovanje informacionih sistema Slika 14. Drugi primjer ekranske forme CASE alata za upravljanje projektima.10. Praćenje napretka (izvršenja) projekta Upravljanje projektom podrazumjeva stalni nadzor napredovanja.12. 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 . šta se može prikazati slijedećim programom.

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

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

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

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

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

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

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

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

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

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

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

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