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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yourdon/DeMarco.Poliščuk E. šta je učinjeno sa tokom podataka b.14). a mogu se koristiti za prikaz posebnih stanja kao što je dojava poruke sistema (npr. 3. koje su navedenim redoslijedom prikazane na slici 5. . 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.Primjer prespajanja toka podataka. Slika 5.18.18. 5.5. dojava greške). U tom slučaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova. Najčešće primjenjivane notacije su: 1.19. Gane/Sarson (korištena u primjerima). SSADM (korištena na slici 5.3. slika 5. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. 2. Procesi se mogu odvijati istovremeno. Notacije koje koriste DTP Postoje različite notacije koje se koriste kod izrade DTP. Neposredno povezani procesi su kada jedan od procesa čeka na završetak prethodnog.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful