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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. mogu se uočiti slijedeće tri vrste prototipskog modela. Prototipski pristup postaje u punoj mjeri praktično primjenljiv (iako je ideja o prototipskom pristupu u softverskom inženjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda. prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se može primjeniti u okviru metodologije životnog ciklusa. Jaroslav: Projektovanje informacionih sistema 41 Test prihvatljivosti Testirani sistem Analiza Scenariji aplikacije Specifikacija zahtjeva Strukturirano oblikovanje Ogledni slučajevi Integracija sistema Model sistema Detaljno oblikovanje Dizajn modula Kodiranje i testiranje Testirani softver Integracija modula Testirani moduli Ogledni slučajevi Slika 2. koji su integrisani sa okruženjem četvrte generacije. Prototipski model razvoja informacionog sistema Uz strukturirani pristup.3.4. U zavisnosti od njegove namjene. Primjer “V” modela.Poliščuk E. 2. odnosno jednoekranski ili . Model oponašanja (model u prirodnoj veličini).

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

76

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Glagol

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

77

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

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

78

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

79

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

Proces

Slika 5.2. Elementi dijagrama dekompozicije.
MARKET

Nabava

Knjigovodstvo

Prodaja

Evidentiranje dobavljača

Naručivanje robe

Knjiženje

robe

Evidentiranje kupca

Fakturisanje robe

Prodaja robe

Izrada narudžbi

Zaprimanje robe

Izrada otpremnice

Otprema robe

Dodavanje

Ažuriranje

Brisanje

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

80

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sistem zaštite i globalnu podršku aplikacija.2. Arhitektura informacionog sistema 9.1.1. logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zaštitu aplikacija i podataka mreža Korisnički interfejs na PC klijentu Korisnički interfejs na PC klijentu Podaci i procesi BP na serveru Logika i korisnički interfejs na PC Unutrašnji korisnički interfejs na PC Sigurna konekcija na server BP Konekcija na spoljnji svijet Dio logike na Internet serveru Internet provajder konekcija za pristup interfejsu i dijelu logike Vanjski korisnik PC klijent Slika 9. . u prvom redu računarsku opremu.2.Poliščuk E. Primjeri arhitekture sistema. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema. Specifikacija hardvera i softvera je podloga za nabavku opreme. komunikacije. 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. programsku podršku. Jaroslav: Projektovanje informacionih sistema 153 9.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

242 Poliščuk E. šta se može prikazati slijedećim programom. 14.10. 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.12. napisanom pomoću pseudokoda. Jaroslav: Projektovanje informacionih sistema Slika 14.

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful