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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

karakteristike i cijene hardvera i softvera. od 1 do 4). a izlazi analiza izvodljivosti za svako moguće rješenje. Karakteristike: Operativni sistem Baza podataka Brzina pretraživanja i dohvat podataka Programski jezik Raspoloživ izvorni kod Korisnički interfejs Integrisani sistem pomoći (on-line help) Dokumentacija (na papiru) Mogućnosti aplikacije Integracija sa drugim aplikacijama Brzina ispisa računa Rad sa različitim štampačima Rad u mreži Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instalisanih paketa Datum prve instalacije Cijena paketa Cijena računara i sistemskog softvera Težinski Super Video Video Boss Video ZZ Video faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3 4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3 8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9 4 4 4 5 0 5 0 0 1 3 3 5 0 5 0 5 2 3 5 2 8 4 16 5 0 10 0 0 4 9 12 15 0 5 0 15 2 3 10 6 1 2 1 2 5 3 0 0 2 0 5 0 0 5 5 0 5 5 4 5 2 2 4 2 5 6 0 0 8 0 20 0 0 5 10 0 5 5 8 15 3 1 4 2 0 3 0 4 5 0 5 0 0 3 5 3 5 5 2 3 6 1 16 2 0 6 0 8 20 0 20 0 0 3 10 9 5 5 4 9 Ukupno bodova: 171 124 97 124 . Dodjeljena ocjena se pomnoži težinskim faktorom kriterijuma za koji je donesena. a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloženog sistema. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. procjena veličine projekta. Prijedlog rješenja sistema koji će se oblikovati i ugraditi se donosi na osnovu izbora onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti. od 0 do 5). Jaroslav: Projektovanje informacionih sistema 25 karakteristike mogućih rješenja. referense i uslovi dobavljača. Tabela 2.9. Procedura bodovanja kriterijuma je slijedeća.Poliščuk E. Ocjenjivanje kriterijuma za izbor sistema Na osnovu opisa karakteristika ne može se sa sigurnošću procijeniti koji je sistem najbolji. te se dobije broj bodova [Fertalj & Kalpić. Primjer: Analiza izvodljivosti za moguća rješenja. Oni kriterijumi koji su značajniji u uporedbi sistema dobivaju veće težinske faktore. 2. 2005]. plan projekta. Da bi se pravilno uporedio značaj različitih kriterijuma koristi se sistem bodovanja. Odredi se težinski faktor za svaki kriterijum (npr.1.1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Slika 11.16. te objekte za prikaz/obradu podataka (slika 11. Jaroslav: Projektovanje informacionih sistema Primjer: Univerzalni modul za pojedinačnu obradu sadrži objekte za posluživanje standardnih funkcija. 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. te po jednu instancu objekata za prikaz/obradu podataka.200 Poliščuk E. Primjer univerzalnog modula za pojedinačnu obradu.16).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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