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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa. odnosno jednoekranski ili .3. Prototipski model razvoja informacionog sistema Uz strukturirani pristup. Jaroslav: Projektovanje informacionih sistema 41 Test prihvatljivosti Testirani sistem Analiza Scenariji aplikacije Specifikacija zahtjeva Strukturirano oblikovanje Ogledni slučajevi Integracija sistema Model sistema Detaljno oblikovanje Dizajn modula Kodiranje i testiranje Testirani softver Integracija modula Testirani moduli Ogledni slučajevi Slika 2. U zavisnosti od njegove namjene. koji su integrisani sa okruženjem četvrte generacije. 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. Model oponašanja (model u prirodnoj veličini).4. 2.Poliščuk E. mogu se uočiti slijedeće tri vrste prototipskog modela.2.

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

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

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

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

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

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

(a)

(b)

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

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

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

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

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

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

76

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Glagol

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

77

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

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

78

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

79

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

Proces

Slika 5.2. Elementi dijagrama dekompozicije.
MARKET

Nabava

Knjigovodstvo

Prodaja

Evidentiranje dobavljača

Naručivanje robe

Knjiženje

robe

Evidentiranje kupca

Fakturisanje robe

Prodaja robe

Izrada narudžbi

Zaprimanje robe

Izrada otpremnice

Otprema robe

Dodavanje

Ažuriranje

Brisanje

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

80

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pseudokod Strukturna karta (Structure Chart) prikazuje modeliranje programske podrške na osnovu dijagrama toka podataka. Strukturirani dizajn Strukturirani dizajn omogućava oblikovanje programa na osnovu dijagrama toka podataka korištenjem strukturnih karti.Poliščuk E. a strukturnom kartom se izražava KAKO ostvariti te zahtjeve.1. podatak (data couple) funkcija niz poziv ugrađena funkcija (modul) iteracija selekcija indikator (control couple) Slika 11. transformacione i transakcione analize. Jaroslav: Projektovanje informacionih sistema 187 11. . Dijagram toka podataka prikazuje ŠTA treba postići. 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.2.3.1). Grafički prikaz strukturiranog dizajna. Elementi prikaza strukturne karte. slika 11.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema 223 Kategorija filma: Ukupni broj filmova koje član želi iznajmiti: Rok za vraćanje posuđenog filma: Hit film Politika iznajmljivanja filmova: Običan film bilo koliko 1 dan 1 dan 3 dana 3 dana manje od 3 3-6 više od 6 Slika 13. ⏐ cijena = cijena + (osnovna cijena filma x 1.5) inače ⏐ ako je ukupni broj filmova manji od 3 tada ⏐ ⏐ rok iznajmljivanja = 1 dan ⏐ ⏐ cijena = cijena + osnovna cijena filma ⏐ inače ⏐ ⏐ ako je ukupni broj filmova manji od 7 ⏐ ⏐ ⏐ rok iznajmljivanja = 3 dana ⏐ ⏐ inače ⏐ ⏐ ⏐ rok iznajmljivanja = 7 dana ⏐ ⏐ ako film nije treći po redu (svaki treći obični film je besplatan) tada ⏐ ⏐ ⏐ cijena = cijena + osnovna cijena filma Slika 13. Primjer stabla odlučivanja za Videoteku.14.13. Primjer pseudokoda za Videoteku. cijena = 0 ako je hit film tada ⏐ rok iznajmljivanja = 1 dan Slika 14.13. . Primjer pseudokoda za Videoteku.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful