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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Prikladan je kada se unaprijed ne zna konačni izgled sistema.4.1(b)) sadrži povratnu vezu i mogućnost promjene rezultata prethodnih faza. 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). Radikalni (strukturirani) razvoj (slika 2.2. . Jaroslav: Projektovanje informacionih sistema Pseudostrukturirani vodopadni model (slika 2. programskih jezika četvrte generacije (4GL) i generatora aplikacija. Analiza Analiza Oblikovanje Izrada Evaluacija Primjena Primjena (a) (b) Oblikovanje Izrada Evaluacija Slika 2. 1.1(b)) omogućava da se aktivnosti različitih faza mogu obavljati istovremeno. Dozvoljava korištenje rječnika podataka.40 Poliščuk E. “V” model razvoja informacionog sistema “V” model razvoja IS (slika 2. Tim rezultatima se testiraju elementi IS na različitim stepenima razvoja. Ovaj model razvoja IS omogućava primjenu tehnika strukturiranog programiranja.

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

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

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

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

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

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

(a)

(b)

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

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

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

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

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

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Slika 11. Poželjno je da se traženje. Prilikom izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. Mora biti ugrađena interaktivna pomoć zavisna o kontekstu. Primjer grafičkog interfejsa. .9. Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno došlo do promjene.9 je prikazana ekranska forma jednog grafičkog interfejsa. brisanje). Korisniku treba omogućiti pregled teksta koji će biti napisan u izvještaj. pod uslovom da se tim prekidom ne narušava integritet podataka (npr. uz mogućnost upotrebe meta znakova. Funkcionalnost interfejsa. prekid transakcija). one koje javlja SUBP) i izbjegavati stručne izraze. kojima se obavlja masovni unos podataka. 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. Treba omogućiti prekid akcija koje predugo traju. Jaroslav: Projektovanje informacionih sistema 193 i skraćenice. Na slici 11. 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. prekid selekcija velikog broja zapisa. Dijelove aplikacije. Unesene podatke treba provjeravati što ranije. po mogućnosti neposredno nakon promjene sadržaja polja ekranske forme. Na polju za unos šifri treba omogućiti odabir iz suženog skupa podataka smještenih u šifarnik.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful