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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. 2000]. 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. Haley Wixom.2.11. 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.Dennis & B. jer se podrazumijeva da je informatizacija isključivo njihov posao. Systems Analysis and Design. Nedostaci radnih sjednica su pasivnost učesnika. “usitnjavanje” razgovora i često udaljavanje od tema. John Wiley & Sons. 3. Jaroslav: Projektovanje informacionih sistema 65 koristan tamo gdje postoje korisnici koji dobro poznaju sistem. Prednosti radnih sjednica su njihova pogodnost za projekte kojima se rješavaju problemi važni za cijeli poslovni sistem ili veći dio poslovanja. ali teško prihvataju nove ideje. preciznije se ustanovljava doseg projekta i bolje uočava protivrječnost zahtjeva. Prostor za radne sjednice [A. Sjednice treba da traju više dana (5 do 10) u nekoliko sedmica. Otpor sjednici je srazmjeran nivou položaja konkretnog učesnika. Otpor je naročito naglašen kada poslovni sistem zapošljava informatičare.3. Ovom zahtjevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Arhitektura informacionog sistema 9. .Poliščuk E. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema. Specifikacija hardvera i softvera je podloga za nabavku opreme. sistem zaštite i globalnu podršku aplikacija. u prvom redu računarsku opremu.2.2.1. Jaroslav: Projektovanje informacionih sistema 153 9. logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zaštitu aplikacija i podataka mreža Korisnički interfejs na PC klijentu Korisnički interfejs na PC klijentu Podaci i procesi BP na serveru Logika i korisnički interfejs na PC Unutrašnji korisnički interfejs na PC Sigurna konekcija na server BP Konekcija na spoljnji svijet Dio logike na Internet serveru Internet provajder konekcija za pristup interfejsu i dijelu logike Vanjski korisnik PC klijent Slika 9. komunikacije. programsku podršku. Primjeri arhitekture sistema. 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.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Elementi prikaza strukturne karte. Strukturirani dizajn Strukturirani dizajn omogućava oblikovanje programa na osnovu dijagrama toka podataka korištenjem strukturnih karti.2. slika 11. Pseudokod Strukturna karta (Structure Chart) prikazuje modeliranje programske podrške na osnovu dijagrama toka podataka. kao i plošnim razlaganjem glavnog procesa u sastavne procese (slika 11. Grafički prikaz sistema Dijagram toka podataka Dijagram toka podataka sa određenim granicama Strukturna karta Slika 11.1). a strukturnom kartom se izražava KAKO ostvariti te zahtjeve.1. transformacione i transakcione analize. Jaroslav: Projektovanje informacionih sistema 187 11. 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. .3.Poliščuk E. Grafički prikaz strukturiranog dizajna.2.

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

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

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

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

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

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

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

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

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

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

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

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

16. Slika 11. koji se prilikom aktiviranja modula dinamički umnožavaju u skladu sa strukturom relacije. Primjer univerzalnog modula za pojedinačnu obradu. te po jednu instancu objekata za prikaz/obradu podataka. te objekte za prikaz/obradu podataka (slika 11.200 Poliščuk E. . 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

14.13. . Primjer pseudokoda za Videoteku. cijena = 0 ako je hit film tada ⏐ rok iznajmljivanja = 1 dan Slika 14.Poliščuk E. ⏐ cijena = cijena + (osnovna cijena filma x 1.5) inače ⏐ ako je ukupni broj filmova manji od 3 tada ⏐ ⏐ rok iznajmljivanja = 1 dan ⏐ ⏐ cijena = cijena + osnovna cijena filma ⏐ inače ⏐ ⏐ ako je ukupni broj filmova manji od 7 ⏐ ⏐ ⏐ rok iznajmljivanja = 3 dana ⏐ ⏐ inače ⏐ ⏐ ⏐ rok iznajmljivanja = 7 dana ⏐ ⏐ ako film nije treći po redu (svaki treći obični film je besplatan) tada ⏐ ⏐ ⏐ cijena = cijena + osnovna cijena filma Slika 13. Primjer stabla odlučivanja za Videoteku. 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.13. Primjer pseudokoda za Videoteku.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful