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

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

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

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

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

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

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

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

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

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

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

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

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

1. najčešće. Novi razvojni ciklus. Prikaz faza životnog ciklusa razvoja softvera.1.4 su navedene tipične faze životnog ciklusa razvoja softvera. unutar zadanih granica. Održavanje podrazumjeva i podršku dobavljača opreme. kao i izradu plana održavanja. Održavanje se sastoji od izmjena sistema radi poboljšanja njegovih radnih karakteristika (performansi). poboljšanja ili prilagođavanja načina upotrebe.6.18 Poliščuk E. Novi razvojni ciklus se provodi nakon preispitivanja čitavog sistema i konstatacije da su potrebne veće izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. To podrazumjeva izgraditi sistem koji zadovoljava poslovne ciljeve.6. prema zahtjevima korisnika. Na slici 1. Ciljevi i problemi razvoja informacionih sistema Osnovni cilj razvoja informacionog sistema je izgraditi sistem koji radi i koji je pouzdan. Slika 1. 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. predstavlja novi projekat. Kompleksnost razvoja informacionog sistema 1.4. bez naglašavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

Na slici 2.5 je prikazan mogući evolutivni model primjene metodologije životnog ciklusa. Razvoj se vrši u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporučuje i koji generiše naredne zahtjeve.

2.4.5. Inkrementalni model razvoja informacionog sistema
Kao i u slučaju evolutivnog modela, na početku primjene inkrementalnog modela, kompletno se sprovodi faza strategije metodologije životnog ciklusa. Nakon toga, formiraju se relativno manji potprojekti sa nižim stepenom međusobne integracije i utvrde se slijedeći parametri potprojekata: ciljevi, resursi i rok predaje u upotrebu. Ciljevi i resursi su varijabilni parametri, koji se po potrebi mogu mijenjati u toku samog projekta, dok je rok predaje u upotrebu programskog proizvoda obavezno fiksni parametar. Potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. Inkrementalni model se može posmatrati kao posebna varijanta evolutivnog modela životnog ciklusa.

2.4.6. Spiralni i zvjezdasti model razvoja informacionog sistema
Kod spiralnog modela primjene metodologije životnog ciklusa, na početku svake faze provodi se procjena rizika. Nastoje se utvditi mogući rizici i razriješiti ih prije nastavka (uklanjanjem ili svođenjem na najmanju moguću mjeru). U slučaju da je rizik prevelik, projekat se prekida (slika 2.6).
Analiza rizika ANALIZA Verifikacija Analiza rizika OBLIKOVANJE Verifikacija Analiza rizika IZRADA Testiranje Analiza rizika INTEGRACIJA Verifikacija

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Spiralni model metodologije životnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni trošak, a na x osi svaka petlja spirale predstavlja jednu fazu razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza može biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.
kumulativni trošak integracija izrada oblikovanje analiza

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

Analiza rizika, procjena alternativa; Razvoj i verifikacija slijedećeg „proizvoda”; Planiranje slijedeće faze; Pregled – određivanje ciljeva, alternativa i ograničenja.

(a)

(b)

Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije životnog ciklusa. Zvjezdasti model, slika 2.7(b), ne uvodi stroga ograničenja u redoslijedu primjene faza i koraka metodologije životnog ciklusa. To ne znači da prirodnog redoslijeda izvršavanja određenih koraka metodologije u ovom modelu nema, već da on zavisi od više faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno inženjerstvo, ili potreba za reinženjeringom postojećeg IS, mogu zahtjevati potpuno obrnuti redoslijed primjene faza životnog ciklusa (primjena "odozdo na gore").

2.5. Metodologija razvoja informacionih sistema
2.5.1. Uvod u metodologiju razvoja informacionog sistema
Metodologija se može definisati kao metoda + idejni pristup. Sadrži u sebi kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih filozofijom, koji potpomažu izgradnju informacionih sistema [Avison & Fitzgerald, 1995]. Metodologija predstavlja skup načela izrade IS, koji se u određenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland, 1994].

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

Komponente metodologije se mogu razvrstati u slijedećih pet tačaka: 1. 2. 3. 4. 5. Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodič) upotrebe odabranih tehnika i pomagala; Način upravljanja projektom i nadzorom projekta.

Cilj metodologije je da omogući sistemski postupak razvoja kojim će se moći pratiti napredak, uspostavi komunikaciju između učesnika uključenih u izgradnju IS (poslovodstvo, korisnici, analitičari, programeri), osigura skup tehnika koje će omogućiti da se zadaci izvršavaju na standardne i provjerene načine, osigura efikasan nadzor sa ciljem uočavanja grešaka u ranim fazama. Osim navedenog, cilj metodologije je da omogući elastične promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom će se ukloniti ad hoc rješavanje problema, odredi ili ukaže kada i u kojoj mjeri je potrebno uključivanje korisnika, te potiče i omogućava uključivanje korisnika kada se za to ukaže potreba. Metodologija omogućava da se dovoljno pažnje posveti analizi poslovanja, čime će se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti grešku u ranim fazama, jer je lakše popraviti dokumentaciju nego mijenjati programski kôd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lakše je pronaći grešku tokom faze u kojoj je nastala, nego tražiti je i popravljati na osnovu posljedičnih učinaka primijećenih u kasnijim fazama.

C i j e n a Plan Analiza Oblikovanje Izrada Održavanje

Slika 2.8. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama razvoja IS prikazani su na slici 2.8.

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

2.5.2. Pristup razvoju informacionog sistema
Tokom projektovanja IS primjenjuju se, uglavnom, sve vrste modela metodologija životnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijedeći pristupi razvoju. Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup jer omogućava opisivanje specifičnih funkcija. Prisutan je problem određivanja nivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna pažnja je posvećena modelu podataka, šta za posljedicu može imati neodgovarajući model baze podataka i otežanu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjerenost podacima (npr. IEM) obezbjeđuje složeniji opis strukture podataka, ali jednostavnije tokove podataka. Procesi se definišu analizom podataka (grupišu oko podataka) i brže konvergira kraju, jer je skup objekata (entiteta) modela konačan. Početak razvoja definisanjem događaja (npr. JSD) je primjereniji sistemima za rad u stvarnom vremenu.

2.5.3. Komercijalne metodologije za razvoj informacionog sistema
Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su navedeni u originalu: • AD/Cycle (Application Development Cycle), • BSP (Business System Planning), • CASE*Method, • IEM (Information Engineering Methodology, Martin), • JSD/JSP (Jackson System Development/ Jackson System Programming), • SA/SD (Structured Analysis / Structured Design), • SASS (Structured Analysis and System Specification), • SSM/M (Soft Systems Method / Multiview), • SSA (Structured System Analysis), • SSADM (Structured System Analysis and Design Method), • Yourdon (Yourdon Structured Method). Objektno usmjerene metodologije: • • • • • Yourdon/OO (Yourdon / Object Oriented), OMT (Object Modelling Technique), BOOCH (Booch’93), Schlaer-Mellor, Unified Modelling Process (Rational).

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

Primjena neke od ovih metodologija ne znači da će IS biti dobar! Zahtjevi korisnika se mogu mijenjati u vremenu. Preporučene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Insistiranje na provođenju propisanih procedura vodi u zanemarivanje stvarnih problema, što za posljedicu može imati formalno dobro napravljen, ali neuspješan sistem. Većina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije podržavaju sve faze životnog ciklusa (npr. IEM). Metodologije treba da su podržane odgovarajućim alatima za upravljanje i projektovanje (CASE), što nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano u praksi, prečice do rješenja problema zasnovane na sličnim iskustvima, kao i prilagođavanje razvojnog procesa.

2.6. Savremeni postupci razvoja informacionog sistema
2.6.1. Brzi razvoj aplikacija
Brzi razvoj aplikacija (Rapid Application Development (RAD)) je efikasna izrada programskog proizvoda u relativno kratkom vremenu. Ovo se postiže sistemskom i vremenski sažetom primjenom slijedećih tehnika i alata: aktivno i efikasno uključivanje korisnika, odgovarajuće upravljanje projektom, ispravna upotreba metoda i tehnika razvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao i upravljana izrada prototipa. RAD se obavlja malim ekipama u trajanju od 60 do 120 dana (približno 20 sedmica) za podsistem veličine od 25 do 30 relacija (tabela). Cijena postignutog ubrzanja može biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu priručnih rješenja) i “prljavi” razvoj. Faze brzog razvoja su: 1. JEM (Joint Enterprise Modeling ) – združeno modeliranje organizacije, odnosno sjednice na kojima poslovodstvo i analitičari traže načine usmjerenja organizacije i načine kako je učiniti kompetentnom. Istražuju se ciljevi organizacije, problemi, kritični činioci uspjeha te strategijske mogućnosti; 2. JRP (Joint Requirements Planning) – združeno planiranje zahtjeva, odnosno analiza zahtjeva za razmatrani poslovni sistem. Proučavaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istražuju i definišu informacione potrebe;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

služba XXX Prodekan za naučni rad XXX Finansijska služba Prodekan za finansije XXX Sekretar XXX Institut XXX Biblioteka Računarska tehnika Informacioni sistemi Slika 5. ORACLE). .6. Dijagram organizacije. Jaroslav: Projektovanje informacionih sistema Dekan XXX Sekretarica XXX Prodekan za nastavu XXX Stud. Slika 5.5.82 Poliščuk E.Ekranska forma CASE alata Repository Object Navigator (Designer 2000.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Razvoj modela podataka 6.2.2.Poliščuk E. 6. model podataka sa .1.11. 2005]. model podataka sa definisanim ključevima (key-based data model). Jaroslav: Projektovanje informacionih sistema 111 M zahtjeva Inventar hemijske laboratorije 1 pohranjuje M M ispunjava 1 Zahtjev za hemikalijom M 1 popisuje Zahtjevač M M 1 M Pakovanje hemikalija 1 prati 1 sadrži Hemikalija opisuje M Istorija pakovanja hemikalija Dobavljačev katalog Slika 6. model konteksta podataka (context data model). Primjer dijagrama entiteti–veze za hemijsku laboratoriju [Fertalj & Kalpić. Uvod u razvoj modela podataka Može da se razvija jedan od slijedećih modela podataka: globalni model podataka (enterprise 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. sistem zaštite i globalnu podršku aplikacija.1. Specifikacija hardvera i softvera je podloga za nabavku opreme.1. komunikacije. Arhitektura informacionog sistema 9.2. Primjeri arhitekture sistema. u prvom redu računarsku opremu. Distribuirana prezentacija mreža Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mreža Distribuirani podaci i logika (3-slojna) mreža Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mreža Podaci na serveru BP Sigurni Intranet provajder za pristup podacima. logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zaštitu aplikacija i podataka mreža Korisnički interfejs na PC klijentu Korisnički interfejs na PC klijentu Podaci i procesi BP na serveru Logika i korisnički interfejs na PC Unutrašnji korisnički interfejs na PC Sigurna konekcija na server BP Konekcija na spoljnji svijet Dio logike na Internet serveru Internet provajder konekcija za pristup interfejsu i dijelu logike Vanjski korisnik PC klijent Slika 9. Jaroslav: Projektovanje informacionih sistema 153 9.Poliščuk E. programsku podršku. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12 strukturirani (meta model) aplikacije Prodaja i na slici 10.11 strukturirani prikaz (meta model) za primjer Narudžba. . Na slici 10. na slici 10.13 je prikazan primjer ekranske forme aplikacije nad meta modelom.8.182 Poliščuk E. Na slici 10.10 je predstavljen strukturirani prikaz (meta model) jednog poslovnog sistema. na slici 10. Jaroslav: Projektovanje informacionih sistema Slika 10.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. Primjer strukture rječnika podataka.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Specifikaciju predstavlja skup simbola koji opisuju upravljački tok. Dijagram toka (blok dijagram. dozvola skokova koji vode upotrebi GOTO naredbe.Poliščuk E. 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. algoritam) Dijagrami toka (Flowcharts) omogućavaju grafički prikaz sistema (system flowchart) i predstavljaju zamjenu za fizičke DTP. nemogućnost opisa struktura podataka. nedostatak formalizma.1. nestrukturiranost. kao i grafički prikaz programa (program flowchart). npr. Primjer dijagrama toka. Primjer 1: Slika 13. Logičko projektovanje programa i programski jezici 13. . veliki i neprikladni dijagrami. Osim toga. Nedostaci dijagrama toka su veliki skup simbola.1. pseudokod ili prirodni jezik. Jaroslav: Projektovanje informacionih sistema 213 13. ali ipak predstavlja tehniku koja (nikako ne) izlazi iz upotrebe.

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

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

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

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

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

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

Primjer: Neka je n = 10. Jaroslav: Projektovanje informacionih sistema BLOK DIJAGRAM RADI naziv_radi DOK NE BUDE P IZVRŠI A KRAJ RADI naziv_radi A P da Slika 13. Da je. tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n ← n .220 PSEUDOKOD: Poliščuk E. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE. 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 . inicijalno bilo n ≤ 1.1 KRAJ RADI oduzimanje_od_n izvršava 9 puta.9.

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

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

Primjer pseudokoda za Videoteku. Jaroslav: Projektovanje informacionih sistema 223 Kategorija filma: Ukupni broj filmova koje član želi iznajmiti: Rok za vraćanje posuđenog filma: Hit film Politika iznajmljivanja filmova: Običan film bilo koliko 1 dan 1 dan 3 dana 3 dana manje od 3 3-6 više od 6 Slika 13. ⏐ cijena = cijena + (osnovna cijena filma x 1.Poliščuk E.14.13.13. . Primjer pseudokoda za Videoteku. Primjer stabla odlučivanja za Videoteku. cijena = 0 ako je hit film tada ⏐ rok iznajmljivanja = 1 dan Slika 14.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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful