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

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

...... Tabele odlučivanja ..................................... 12..............................3........................................................ 13.....................3................................... 14........................................... 14...........................................................................................2............ Uvođenje sistema u primjenu ...................................................................................8.................. Praćenje napretka (izvršenja) projekta ............ 15........................ 13. Izrada plana ..........12.......4...................13.. 14............ Dijagram toka (blok dijagram................. Prikaz plana ................ Struktogram ............................ 14...................6............................................ Preporuke za planiranje poslova ..................................................................................... Stablo odlučivanja ................ 12.... Programski jezici .9.........7................... Poboljšanje sistema i reinženjerstvo ................. 14.............................6.....5....................... 12... Održavanje informacionog sistema . Implementacija informacionog sistema .......................................................................................................................... Programiranje (kodiranje) ........ 15.... 251 ............................... algoritam) ....................................... Pristup programiranju .......7... 14..... Provjera ispravnosti informacionog sistema ..............................6..... Tehnike za vremensko planiranje ....... 15...... Izrada dokumentacije ............................................................................... Organizacija velikih projekata .............. Programski standardi i preporuke ..........11......................3.1......................................2......... 13........................... Literatura ................................................... Organizacija i upravljanje projektom ................ 12.1.........Poliščuk E.......... Strukturirani prirodni jezik (pseudokod) ......4..... 14..........................................................1....... Evidencija projekta ......................... Izrada sistema ...............................................4............................... Primjena i održavanje informacionog sistema .......... 14..4............................ 15..... 13..... 15................................ Elementi konfiguracije . 13..............................3........................................5................. Raspodjela zadataka . 12............................ 13.. 14.............1........ Logičko projektovanje programa i programski jezici ............... 12.. 14. 13..... 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...............................................................10.................... 14...........................2........................................................ 14................ 14.... Akcioni dijagram .........................................................................5.... 14...............................2....................................................................................... 15.............................. 13.................. Obuka korisnika IS .......... Upravljanje projektom ...................................................... Generički modeli organizacije ................... Organizacija i timski rad ...............................5.............. Modeli timova ...... Planiranje projekata .........................................

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2005].000 / (1 + 0.417 Povrat investicije (Return On Investment (ROI)) se obično dijeli sa dužinom trajanja projekta kako bi se dobio godišnji ROI. Jaroslav: Projektovanje informacionih sistema 29 • Korist projekta u iznosu od $30. Primjer: Analiza trošak – korist [Fertalj & Kalpić.2 i grafičkim prikazom tabele. Odnos trošak/korist je prikazan tabelom 2.2. .Poliščuk E. 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.08)5 = $20. Tabela 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. kao pri primjeni sekvencijalnog modela metodologije životnog ciklusa. Mogući evolutivni model primjene metodologije životnog ciklusa. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije životnog ciklusa i prototipskog pristupa. Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Analiza Oblikovanje Izrada Evaluacija Slika 2. kao metodom za tačno utvrđivanje informacionih zahtjeva. potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. a projekti podsistema se usaglašavaju sa shemom integrisane BP. 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. koraci konceptualnog i implementacionog projektovanja. .46 Poliščuk E. Prema drugoj varijanti. ali ne rješava probleme dugog vremenskog intervala od početka projekta do pojave prvih. Jaroslav: Projektovanje informacionih sistema nedovoljno precizno identifikovanih informacionih zahtjeva. a ne postupno. može dovesti do nižeg stepena integrisanosti IS. nakon utvrđivanja preciznih informacionih zahtjeva. rezultati konceptualnog i implementacionog projektovanja BP se integrišu. Primjenjuju se dvije varijante evolutivnog pristupa. Za utvrđivanje informacionih zahtjeva se pretežno primjenjuju odbacivi prototipovi. potprojekti se ponovo posmatraju kao cjelina i na njih se primjenjuju. smatra se da njegova praktična primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom. nešto izmjenjeni. Prema prvoj. i potrebe ulaganja finansijskih sredstava odjednom. međutim. Ovakav nezavisan rad. operativno primjenljivih rezultata kod korisnika. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednu fazu treba da obezbjedi bolju osnovu za kasniji uspješni završetak prethodne faze. 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.2. projektanta i menadžera. priprema obuke. prototipovi za test uporabljivosti. završetak projekta. informaciono inženjerstvo je procesno osjetljiva tehnika usmjerena na podatke i primjenjuje se na organizaciju kao cjelinu ili na neki njen značajni dio.Information Strategy Planning (ISP). obuka korisnika. koja se odvija projekat-po-projekat. završetak dizajna.provjera rada. Osnovno načelo je da se IS moraju graditi kao što se grade drugi “unikatni” proizvodi. izrada dokumentacije. završno testiranje. planiranje završetka. Završetak projekta . 4. 5. . druga JAD sjednica. Aplikacije postaju projekti u kojima se provode postupci analize i dizajna da bi se razvili produkcioni sistemi.52 Poliščuk E. koje obuhvata posmatranje poslovanja kao cjeline sa ciljem definisanja opšteg.iterativna izrada prototipa. Informaciono inženjerstvo (Information Engineering (IE)) Informaciono inženjerstvo (IE) se zasniva na analizi poslovnih zahtjeva iz koje se izdvajaju aplikacije IS i prioriteti tih aplikacija. priprema konverzije. Sedmice 10-14 • razvoj i testiranje. JAD (Joint Application Design) – združeno oblikovanje aplikacija. Primjer: RAD projekat. Za razliku od klasične strukturirane analize. istraživanje. Planiranje strategije IS . priprema JAD sjednice. Sedmice 1-4 • pokretanje projekta. npr. početak dizajna. obavljanje JRP sjednice. Konstrukcija . priprema JRP sjednice. konsolidacija JAD dizajna i prototipa. Jaroslav: Projektovanje informacionih sistema 3. Sedmice 5-9 • prva JAD sjednica.6. u građevinarstvu ili brodogradnji. Faze informacionog inženjerstva su slijedeće: 1. obuka. Zahtijeva tijesnu saradnju korisnika. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. Sedmice 15-20 • izrada dokumentacije.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Jaroslav: Projektovanje informacionih sistema Primjer 2: Rukovanje podacima (selekcija u jeziku SQL)..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.230 Poliščuk E.. DISPLAY BY NAME rOsoba..* .. FIND ALL Osoba Stanuje Mjesto FIND ALL Osoba (UNRELATED) Stanuje Mjesto FIND ALL Osoba Stanuje Mjesto (COMPLETE) Primjer 5: Ekranski meni (Informix-4GL). Mjesto WHERE Osoba. COMMAND "Kraj" "Kraj rada" EXIT MENU END MENU Primjer 6: Rukovanje podacima putem ekranske forme..SifMjesta) RETURNING rMjesto.SifMjesta Primjer 4: Rukovanje podacima (ZIM). COMMAND "Unos" "Unos novog zapisa" CALL unos() .* IF status = NOTFOUND THEN MESSAGE "Ne postoji mjesto" NEXT FIELD SifMjesta ... Stanuje := Osoba. INPUT BY NAME rOsoba. DEFINE rOsoba RECORD LIKE Osoba DEFINE rMjesto RECORD LIKE Mjesto ..SifMjesta = Mjesto..SifMjesta AND Osoba. SELECT * FROM Osoba. MENU ”Osoba" COMMAND "Dohvat" "Postavljanje uslova za dohvat zapisa" CALL dohvat() IF status != NOTFOUND THEN NEXT OPTION "Slijedeci" END IF COMMAND "Slijedeci" "Dohvatanje slijedećeg zapisa" CALL slijed() .SifMjesta = Mjesto.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful