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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gane/Sarson (korištena u primjerima). 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. U tom slučaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova.18. Notacije koje koriste DTP Postoje različite notacije koje se koriste kod izrade DTP. Neposredno povezani procesi su kada jedan od procesa čeka na završetak prethodnog.19. koje su navedenim redoslijedom prikazane na slici 5. Procesi se mogu odvijati istovremeno. šta je učinjeno sa tokom podataka b. 2. Slika 5.3. Obično imaju posebno značenje. 3.5. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. Yourdon/DeMarco.14).Primjer prespajanja toka podataka. 5. slika 5. SSADM (korištena na slici 5. . dojava greške).Poliščuk E.18. Najčešće primjenjivane notacije su: 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ORACLE. Slika 7. Jaroslav: Projektovanje informacionih sistema 125 Pojednostavnjeni primjer matrice događaj/entitet za rezervaciju sobe u hotelu Proljeće. . Primjer matrice događaj/entitet.Poliščuk E. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije.2.1.3. 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. Slika 7.2. Matrica Elementarne funkcije/Tipovi entiteta. 7. prikazan je na slici 7.2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. 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. Moguće oznake za pisanje pseudokoda: Abc abc Abc := # " s v M IvI & Si I&I naziv algoritma rezervisana riječ pseudokoda za opis algoritama ugrađena ili trivijalna funkcija (procedura) pridruživanje zamjena vrijednosti komentar konstanta ili parametar skalar vektor matrica nula-vektor modul (dužina) vektora skup element skupa kardinalni broj skupa prazan skup . Da je. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE. inicijalno bilo n ≤ 1.220 PSEUDOKOD: Poliščuk E.9. 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. Primjer: Neka je n = 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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