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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Prikladan je kada se unaprijed ne zna konačni izgled sistema. 1.1(b)) sadrži povratnu vezu i mogućnost promjene rezultata prethodnih faza. programskih jezika četvrte generacije (4GL) i generatora aplikacija.1(b)) omogućava da se aktivnosti različitih faza mogu obavljati istovremeno. Radikalni (strukturirani) razvoj (slika 2.40 Poliščuk E. pseudostrukturiranog i radikalnog razvoja (b). Dozvoljava korištenje rječnika podataka.4. Analiza Analiza Oblikovanje Izrada Evaluacija Primjena Primjena (a) (b) Oblikovanje Izrada Evaluacija Slika 2. Tim rezultatima se testiraju elementi IS na različitim stepenima razvoja.2. Jaroslav: Projektovanje informacionih sistema Pseudostrukturirani vodopadni model (slika 2. . Uporedni prikaz klasičnog razvoja (a). “V” model razvoja informacionog sistema “V” model razvoja IS (slika 2. 2.

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful