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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

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

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

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

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

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

(a)

(b)

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

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

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

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

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

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

Slika 7.Poliščuk E. ORACLE. 7.2.2. Primjer matrice događaj/entitet. prikazan je na slici 7.1. Matrica Elementarne funkcije/Tipovi entiteta.3. Slika 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. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije.2. .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Primjeri arhitekture sistema. Specifikacija hardvera i softvera je podloga za nabavku opreme. programsku podršku. Jaroslav: Projektovanje informacionih sistema 153 9.1. u prvom redu računarsku opremu. sistem zaštite i globalnu podršku aplikacija. komunikacije.Poliščuk E. Arhitektura informacionog sistema 9.2. logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zaštitu aplikacija i podataka mreža Korisnički interfejs na PC klijentu Korisnički interfejs na PC klijentu Podaci i procesi BP na serveru Logika i korisnički interfejs na PC Unutrašnji korisnički interfejs na PC Sigurna konekcija na server BP Konekcija na spoljnji svijet Dio logike na Internet serveru Internet provajder konekcija za pristup interfejsu i dijelu logike Vanjski korisnik PC klijent Slika 9.1.2. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema. . 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) se ostvaruje sa višekorisničkim računarom (mainframe. ručni računari i sl. • klijentski (client-based) – obrada se obavlja na personalnom računaru. elementima obrade (application logic) i interfejsom (presentation logic). Internet kiosci. ali se funkcionalnost ne može značajno poboljšati. personalni računari (PC). • mali računari (Minicomputer). Funkcije sistema. Tu spadaju i terminali posebne namjene. Ovom arhitekturom je omogućeno skladištenje podataka (datoteke i baze podatka). uglavnom.2. ansi. koja se sastoji u zamjeni znakovnog interfejsa grafičkim interfejsom.154 Poliščuk E. Na slici 9. Serveri mogu biti: • veliki računari (Mainframe). koji omogućavaju pristup terminal emulatorima ili udaljenim radnim plohama. Centralizovana obrada podataka Centralizovana obrada (slika 9.1 su prikazani primjeri arhitekture IS. Ova zamjena se. su određeni pohranom podataka (data storage).2. odnosno slojevi arhitekture. 9. Model mreže sadrži prikaz glavnih komponenti sistema. Produžava se vijek starih aplikacija. • mikroračunari (Microcomputer). Prezentaciona logika Aplikaciona logika Logika pristupa podacima Skladištenje podataka . kao što su bančini terminali (bankomati). Primjer centralizovane obrade. korisnički interfejs (uobičajeno znakovni interfejs) i interfejs sistema (mrežne i druge komponente). vt220) i mikroračunari (PC). izvodi na personalnim računarima. Jaroslav: Projektovanje informacionih sistema Uobičajeni modeli arhitekture su: • serverski (server-based) – obrada se obavlja na serveru. poslovna logika (programska podrška). pristupom podacima (data access logic). • klijent-server (client-server based) – kombinacija prethodne dvije. Klijent (terminal) Server Host (mainframe računar) Slika 9.2. Klijenti su klasični terminali (npr. Distribuirana prezentacija je proizvoljna nadogradnja centralnih aplikacija. njihove fizičke lokacije i način njihovog međusobnog povezivanja. minicomputer) i terminalima.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

232 Poliščuk E. sličnu govornom jeziku. Poželjno je da korisnik nakon manjih prekida u radu (npr. Može se provjeriti tzv. Nakon toga korisnik bi morao biti u mogućnosti samostalno da obavlja neke manje poslove. Većina korisnika treba da može naučiti osnove 4GL za 2 do 3 dana. korištenje višenivovskih prevodilaca (npr. . Programska oprema razvijena pomoću 4GL posjeduje jednostavnu i razumljivu sintaksu. kao i manje dijalekata (npr. dvodnevnim testom (TWO DAY TEST). UNIX. ANSI SQL standard). 4GL-EC-C-O-4GE). 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.. Napred navedeno ne vrijedi jednako za sve 4GL! . 10 dana) bude u mogućnosti nastaviti sa radom bez poteškoća. ).. kvalitetniji razvojni i korisnički interfejs. SQLEXEC). upravljački programi koji su nadgradnja OS (npr.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful