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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Prototipski model razvoja informacionog sistema Uz strukturirani pristup.2. Primjer “V” modela. mogu se uočiti slijedeće tri vrste prototipskog modela.4. koji su integrisani sa okruženjem četvrte generacije.Poliščuk E.3. Model oponašanja (model u prirodnoj veličini). U zavisnosti od njegove namjene. 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. Jaroslav: Projektovanje informacionih sistema 41 Test prihvatljivosti Testirani sistem Analiza Scenariji aplikacije Specifikacija zahtjeva Strukturirano oblikovanje Ogledni slučajevi Integracija sistema Model sistema Detaljno oblikovanje Dizajn modula Kodiranje i testiranje Testirani softver Integracija modula Testirani moduli Ogledni slučajevi Slika 2. prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa. odnosno jednoekranski ili .

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

Slika 5.6.5. . služba XXX Prodekan za naučni rad XXX Finansijska služba Prodekan za finansije XXX Sekretar XXX Institut XXX Biblioteka Računarska tehnika Informacioni sistemi Slika 5. Dijagram organizacije. 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. ORACLE).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1 0.1 0.1 NS 0.N 0. Racun 1. .8.1 RačStRač OdnosiSeNa 0.N 1.N StavkaRačuna ES Radnik Saradnik 0.1 Zanimanje 1. 6.N Igla Avion Slika 6.1 PodJed 1.9.N 0.1 Stanuje 0.1 Račun 1.M Sastav Dio 0. 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).N Proizvodi 0. slike 6.N Stanuj Osoba 1.Poliščuk E.1 NadJed Pripada 0.9.9 i 6.M 1.N StavkaRacuna Slika 6.N 0.N 1.10. Mjesto 1. Chen-ova notacija: Mjesto 1.1 0.N Zaposlen OrgJed 0.1. Primjer dijagrama entitet–veze jednog preduzeća (prema Chen-u). Primjeri slabih entiteta.N Cjelina 1.1 Osoba Primjer: Identifikaciona veza i identifikacioni slab entitet.1 RacStRac 1.1 Proizvod 1. 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Arhitektura informacionog sistema 9. komunikacije. sistem zaštite i globalnu podršku aplikacija. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema.1. u prvom redu računarsku opremu. Jaroslav: Projektovanje informacionih sistema 153 9. Specifikacija hardvera i softvera je podloga za nabavku opreme.2.1. Primjeri arhitekture sistema. Distribuirana prezentacija mreža Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mreža Distribuirani podaci i logika (3-slojna) mreža Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mreža Podaci na serveru BP Sigurni Intranet provajder za pristup podacima. programsku podršku.Poliščuk E. 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. .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

177 Slika 10. Izvod iz datoteke koja sadrži SQL naredbe za kreiranje odgovarajućih relacija (tabela).2. Izgled ekranske forme za formiranje naloga za otpremu je prikazan na slici 10. 10. Izgled ekranske forme za formiranje naloga za otpremu.Poliščuk E. STA VARCHAR2(17) NOT NULL. BRN NUMBER(6) NOT NULL.5. Jaroslav: Projektovanje informacionih sistema IDK NUMBER(6) NOT NULL. generisanje programa je sprovedeno upotrebom generatora modula Developer 2000 Forms. 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. OSN VARCHAR2(17)).7.4. Generisanje programa i programiranje Za formiranje naloga za otpremu aplikacije Komercijalni poslovi. Tokom postupka generisanja. ORACLE. IDR NUMBER(6) NOT NULL. STN VARCHAR2(17) NOT NULL. Slika 10. . koji je obično iterativne prirode. CREATE TABLE STAV_NAL (IDS NUMBER(6) NOT NULL.4) DEFAULT 0 NOT NULL).5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful