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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tabela 2. Ulazi su napravljena analiza izvodljivosti. Oni kriterijumi koji su značajniji u uporedbi sistema dobivaju veće težinske faktore.1.Poliščuk E. 2. a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloženog sistema. procjena veličine projekta. referense i uslovi dobavljača. Da bi se pravilno uporedio značaj različitih kriterijuma koristi se sistem bodovanja. karakteristike i cijene hardvera i softvera. Karakteristike: Operativni sistem Baza podataka Brzina pretraživanja i dohvat podataka Programski jezik Raspoloživ izvorni kod Korisnički interfejs Integrisani sistem pomoći (on-line help) Dokumentacija (na papiru) Mogućnosti aplikacije Integracija sa drugim aplikacijama Brzina ispisa računa Rad sa različitim štampačima Rad u mreži Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instalisanih paketa Datum prve instalacije Cijena paketa Cijena računara i sistemskog softvera Težinski Super Video Video Boss Video ZZ Video faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9 Ukupno bodova: 171 124 97 124 . Primjer: Analiza izvodljivosti za moguća rješenja. Dodjeljena ocjena se pomnoži težinskim faktorom kriterijuma za koji je donesena. od 0 do 5).1. od 1 do 4). Odredi se težinski faktor za svaki kriterijum (npr. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. Procedura bodovanja kriterijuma je slijedeća. plan projekta. Jaroslav: Projektovanje informacionih sistema 25 karakteristike mogućih rješenja. a izlazi analiza izvodljivosti za svako moguće rješenje. Ocjenjivanje kriterijuma za izbor sistema Na osnovu opisa karakteristika ne može se sa sigurnošću procijeniti koji je sistem najbolji.9. Prijedlog rješenja sistema koji će se oblikovati i ugraditi se donosi na osnovu izbora onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivosti. 2005]. te se dobije broj bodova [Fertalj & Kalpić.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. koji su integrisani sa okruženjem četvrte generacije.Poliščuk E.2. Prototipski pristup postaje u punoj mjeri praktično primjenljiv (iako je ideja o prototipskom pristupu u softverskom inženjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda. 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. U zavisnosti od njegove namjene. mogu se uočiti slijedeće tri vrste prototipskog modela. prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa.3.4. Prototipski model razvoja informacionog sistema Uz strukturirani pristup. Model oponašanja (model u prirodnoj veličini). Primjer “V” modela. odnosno jednoekranski ili .

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful