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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.2. u prvom redu računarsku opremu.Poliščuk E. sistem zaštite i globalnu podršku aplikacija. komunikacije. Distribuirana prezentacija mreža Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mreža Distribuirani podaci i logika (3-slojna) mreža Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mreža Podaci na serveru BP Sigurni Intranet provajder za pristup podacima. Jaroslav: Projektovanje informacionih sistema 153 9. Arhitektura informacionog sistema 9.2. programsku podršku. 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. . Specifikacija hardvera i softvera je podloga za nabavku opreme. Primjeri arhitekture sistema.1. Dizajn arhitekture sistema Dizajn arhitekture se sastoji od planova koji definišu pojedine komponente sistema.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. .3. Na slici 13.Poliščuk E. Jaroslav: Projektovanje informacionih sistema 221 13. Akcioni dijagram Akcioni dijagram (Action Diagram) je formalizovana mješavina strukturiranog prirodnog jezika i pseudokoda. 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. Primjer akcionog dijagrama za rad sa generatorom aplikacija Advantage:Plex.11).11. Slika 13. Slika 13.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful