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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Matrica „organizacione jedinice/procesi” se definiše pomoću dijagrama procesa. omogućava prikaz protoka. te dokumentovanje logike poslovnih pravila i procedura (slika 5. 5.3. 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.Poliščuk E. ORACLE). koja se proteže u visini odgovarajuće organizacione jedinice. Jaroslav: Projektovanje informacionih sistema 89 pogledu izvođenja pojedinih aktivnosti.12. . Dijagram procesa na ekranskoj formi CASE alata Process Modeller (Designer 2000.13). To znači da je za sve procese u danoj oblasti zadužena nadležna organizaciona jedinica. Slika 5. Oblast nadležnosti je na dijagramu prikazana u obliku horizontalne trake.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

7.sa značenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta. Nullify (N). u odnosu na vrijednosti atributa tipa entiteta. sa značenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta.7. 7. . odnosno prati promjene ponašanja entiteta koji prolazi kroz sistem. Dijagram podudarnosti učinka (Effect Correspondence Diagram – ECD). 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. koji prethodno nije imao nula vrijednost. i Other (O). Jaroslav: Projektovanje informacionih sistema Update (U). Dijagram podudarnosti učinka za opšti slučaj. sa značenjem da funkcija ima. Opisuje vremenski zavisno ponašanje (jednog) entiteta. za opšti slučaj je prikazan na slici 7. entitet. a za rezervaciju sobe u hotelu Proljeće na slici 7. Model istorije života entiteta (Entity Life History) Istorijat života entiteta je pogled na sistem usmjeren učincima događaja koji uzrokuju promjene stanja.3.8. Archive (A). sa značenjem da je zadatak funkcije omogućavanje zadavanja nula vrijednosti za atribut tipa entiteta.128 • • • • Poliščuk E.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Obrada podat. . Jaroslav: Projektovanje informacionih sistema POČETAK Pripremne radnje Spojište tokova Učitav.podat. Izlaz podat.214 Primjer 2: Poliščuk E. Dijagram toka Prodaja (generator dijagrama toka Visio). 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.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful