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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

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

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

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

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

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

(a)

(b)

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

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

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

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

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

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

76

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Primjer dobro postavljenih korisničkih zahtjeva:
“Hemičar ili član osoblja hemijske laboratorije može podnijeti zahtjev za jednom ili više hemikalija. Zahtjev može biti udovoljen ili dostavom pakovanja hemikalije koja se već nalazila na zalihi hemijske laboratorije ili upućivanjem narudžbe za novim pakovanjem hemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kada je ispunjen do trenutka kada je udovoljen ili otkazan. Takođe, mora pratiti istoriju svakog pakovanja hemikalija od trenutka kada stigne u kompaniju do trenutka kad je potpuno upotrebljen ili odbačen.”

Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sistema (procesi, podaci, događaji). Mogu se definisati preslikavanja uočenih imenica i glagola u konkretne komponente analitičkog modela. Moguća preslikavanja su opisana u tabeli 4.2. Tabela 4.2.
Tip riječi Imenica Primjer - Ljudi, organizacije, softverski sistemi, jedinice podataka ili postojeći objekti Komponente analitičkog modela - Skladišta podataka (DFD – modeliranje toka podataka) - Entiteti ili njihovi atributi (ERD – dijagram entiteti - veze) - Klase ili njihovi atributi (dijagram klasa) - Procesi (DFD) - Odnosi (ERD) - Prelazi (iz stanja u stanje) (STD – dijagram prelaza stanja) - Metode klasa (dijagram klasa)

Glagol

- Akcije, ono što korisnik može poduzeti ili događaji koji se mogu dogoditi

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

77

5. Modeliranje fukcija i procesa
5.1. Uvod u modeliranje funkcija i procesa
Logički procesi (koje sačinjavaju funkcije, događaji i elementarni procesi) su akcije koji se obavljaju bez obzira na način ugradnje i raspoložive resurse sistema. Neke metode poistovjećuju funkcije i procese. Stvarni problemi su preveliki i presloženi da bi se riješili odjednom („u komadu”), te je potrebno njihovo strukturno raščlanjivanje (razlaganje). Načelo je poznato i glasi „podijeli pa s/vladaj” (lat. divide et impera, eng. divide and conquer). Sistem se razlaže i opisuje hijerarhijskim modelima. Modeli sistema se oblikuju iterativnim razlaganjem sa vrha prema dolje. Razlagati se mogu: funkcije i procesi, organizaciona struktura, struktura podataka i struktura programske opreme.

5.1.1. Logički procesi
Funkcije su skup logički povezanih trajnih poslovnih aktivnosti i zadataka (npr. djelatnost, posao). Funkcije se obavljaju stalno (nemaju određeni početak i kraj). Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline. Primjeri funkcija: Prodaja, proizvodnja, otprema, računovodstvo. Funkcija se može sastojati od desetina pa i stotina diskretnih procesa. Funkcije se mogu hijerarhijski razložiti do nivoa diskretnih procesa, koji obavljaju određeni zadatak kojim odgovaraju na poslovne događaje. Događaj je logički dio posla koji se obavlja kao nedjeljiva cjelina. Često je u upotrebi i naziv transakcija. Pokreće se diskretnim ulazom i završava nakon što proces odgovori odgovarajućim izlazom. Poslovni događaj može se predstaviti jednim procesom kojim sistem reaguje na taj događaj. Logički događaj dalje se razlaže do elementarnih procesa kojima se prikazuje reakcija sistema na taj događaj. Proces (elementarni, primitivni proces) je postupak, način rada, doslijedna izmjena stanja. Takođe, proces je diskretna odluka, aktivnost ili zadatak kojim se obavlja neki posao.

78

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Proces se obavlja uvijek na isti način (za određeni ulaz se dobija isti izlaz). Trajanje procesa je konačno i odredivo (poznati: početak, završetak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska). Poslovna pravila su instrukcije i logika koji određuju proceduru obavljanja procesa. Ugrađuju se u računarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa). Poslovna politika je skup poslovnih pravila. U većini poslovnih sistema predstavlja osnovu za donošenje odluka.

5.1.2. Modeliranje funkcija
Funkcionalna dekompozicija (dekompozicija funkcija) se koristi za izradu opšteg modela funkcija (modela poslovnih funkcija) posmatranog sistema u fazi planiranja, što predstavlja strukturirano planiranje. Hijerarhija funkcija iterativno se razlaže do nivoa procesa, tj. do trenutka kada se počne opisivati šta se nekom funkcijom obavlja (slika 5.1).

Slika 5.1. Iterativno razlaganje hijerarhija funkcija do nivoa procesa. Dijagram funkcionalne dekompozicije (Functional Decomposition Diagram (FDD)) koristi istu notaciju za razlaganje bilo koje hijerarhijske strukture, pa se često zove samo Dijagram dekompozicije ili Mapa hijerarhije.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

79

Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi. Funkcije se označavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osušiti dio), spojnice su spojevi između funkcija i procesa, a vanjski spojevi su spojevi sa dijelovima dijagrama na drugim stranicama (slika 5.2). Primjer dijagrama dekompozicije za jedan sistem /podsistem prikazan je na slici 5.3.
Funkcija

Proces

Slika 5.2. Elementi dijagrama dekompozicije.
MARKET

Nabava

Knjigovodstvo

Prodaja

Evidentiranje dobavljača

Naručivanje robe

Knjiženje

robe

Evidentiranje kupca

Fakturisanje robe

Prodaja robe

Izrada narudžbi

Zaprimanje robe

Izrada otpremnice

Otprema robe

Dodavanje

Ažuriranje

Brisanje

Slika 5.3. Primjer dijagrama dekompozicije za jedan sistem/podsistem.

80

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Izrada globalnog modela funkcija može započeti izradom hijerarhijske liste funkcija po pojedinim organizacionim cjelinama. Primjer: • NABAVA • Evidentiranje dobavljača • Nabavka robe - Izrada narudžbi - Zaprimanje robe UPRAVLJANJE OSOBLJEM • Evidentiranje službe - Prijem u službu - Praćenje službe » redovni rad » prekovremeni rad » bolovanje » godišnji odmori - Otpuštanje iz službe • Obračun plata

Izrada dijagrama dekompozicije odvija se po slijedećem postupku. Polazi se od korijena dijagrama, kome se dodjeljuje ime sistema. Slijedi razrada u podsisteme i poslovne funkcije. Daljnja razrada je do nivoa operacionalizacije. Pri izradi dijagrama dekompozicije potrebno je pridržavati se slijedećih pravila: svaki proces je roditelj ili dijete, roditelj mora imati barem dvoje djece, dok po većini standarda, dijete smije imati samo jednog roditelja. Preporuke: Izostaviti procese koji samo premještaju ili preusmjeravaju podatke, a pri tome ih ostavljaju nedirnute. Pažnju usmjeriti na procese koji: nešto računaju (npr. prosjek ocjena), donose ili potpomažu odluke (npr. određivanje raspoloživosti robe pri naručivanju), filtriraju ili sumiraju podatke (npr. računi kojima je istekao rok plaćanja), organizuju podatke u korisne informacije (npr. generisanje izvještaja), pokreću druge procese (npr. mijenjaju modalitet rada uređaja) ili rukuju podacima (npr. stvaranje, čitanje, ažuriranje, brisanje i slično). Pomoću hijerarhijskih dijagrama se može prikazati funkcionalna dekompozicija realnog sistema. Takav jedan dijagram, dobijen pomoću alata Function Hierarchy Diagramer (Designer 2000, ORACLE), je prikazan na slici 5.4. Svaka funkcija, koja se kreira putem navedenog alata istovremeno predstavlja i proces u budućim dijagramima toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju sinonime u terminologiji mnogih CASE alata.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

Matrica entiteti/događaji (Entity/Event Matrix) Matrica entiteti/događaji omogućava pogled na sistem usmjeren događajima. brisanje .D (elete). Primjer modeliranja procesa vođeno događajima.U (update) ili M (odify). ažuriranje . 7. Matrica sadrži događaje (redovi) i entitete (stupci).1. Jaroslav: Projektovanje informacionih sistema Sistem Sistem Funkcija 1 Funkcija n Događaj n-2 Događaj n-1 Događaj n Funkcija 2 Događaj 1 Događaj 2 Događaj 3 Događaj 4 Događaj 5 Događaj 1 Događaj 5 Događaj n Slika 7.124 Poliščuk E. 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).2. čitanje . Završetak je kada se ostvari da svaki događaj ima učinak na barem jedan entitet.R (read) (u nekim metodama se ne bilježi). .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. 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.11 strukturirani prikaz (meta model) za primjer Narudžba.182 Poliščuk E. Na slici 10. na slici 10. Na slici 10.12 strukturirani (meta model) aplikacije Prodaja i na slici 10.13 je prikazan primjer ekranske forme aplikacije nad meta modelom.8.10 je predstavljen strukturirani prikaz (meta model) jednog poslovnog sistema.9 je prikazana praktična realizacija relacija iz sastava Rječnika podataka. na slici 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. 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. Unaprijed se ugrađuju pozivi standardnih procedura vezanih uz standardne funkcije.16. Primjer univerzalnog modula za pojedinačnu obradu.200 Poliščuk E. koji se prilikom aktiviranja modula dinamički umnožavaju u skladu sa strukturom relacije.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n ← n . Da je. 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 . inicijalno bilo n ≤ 1.1 KRAJ RADI oduzimanje_od_n izvršava 9 puta. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE.9. Primjer: Neka je n = 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful