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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2005].000 / (1 + 0.2 i grafičkim prikazom tabele. Tabela 2.08)5 = $20. . Odnos trošak/korist je prikazan tabelom 2. 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.Poliščuk E.2.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo: $30. Primjer: Analiza trošak – korist [Fertalj & Kalpić. Nizak ROI (~ manji od 10% godišnje) može pokazivati da je korist preniska da bi bila isplativa.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

47

Na slici 2.5 je prikazan mogući evolutivni model primjene metodologije životnog ciklusa. Razvoj se vrši u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporučuje i koji generiše naredne zahtjeve.

2.4.5. Inkrementalni model razvoja informacionog sistema
Kao i u slučaju evolutivnog modela, na početku primjene inkrementalnog modela, kompletno se sprovodi faza strategije metodologije životnog ciklusa. Nakon toga, formiraju se relativno manji potprojekti sa nižim stepenom međusobne integracije i utvrde se slijedeći parametri potprojekata: ciljevi, resursi i rok predaje u upotrebu. Ciljevi i resursi su varijabilni parametri, koji se po potrebi mogu mijenjati u toku samog projekta, dok je rok predaje u upotrebu programskog proizvoda obavezno fiksni parametar. Potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. Inkrementalni model se može posmatrati kao posebna varijanta evolutivnog modela životnog ciklusa.

2.4.6. Spiralni i zvjezdasti model razvoja informacionog sistema
Kod spiralnog modela primjene metodologije životnog ciklusa, na početku svake faze provodi se procjena rizika. Nastoje se utvditi mogući rizici i razriješiti ih prije nastavka (uklanjanjem ili svođenjem na najmanju moguću mjeru). U slučaju da je rizik prevelik, projekat se prekida (slika 2.6).
Analiza rizika ANALIZA Verifikacija Analiza rizika OBLIKOVANJE Verifikacija Analiza rizika IZRADA Testiranje Analiza rizika INTEGRACIJA Verifikacija

PRIMJENA

Slika 2.6. Dijagram procjene rizika.

48

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Spiralni model metodologije životnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni trošak, a na x osi svaka petlja spirale predstavlja jednu fazu razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza može biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.
kumulativni trošak integracija izrada oblikovanje analiza

Programiranje

Projektovanje

Upravljanje projektom Uvođenje u upotrebu Snimanje i analiza

1. 2. 3. 4.

Analiza rizika, procjena alternativa; Razvoj i verifikacija slijedećeg „proizvoda”; Planiranje slijedeće faze; Pregled – određivanje ciljeva, alternativa i ograničenja.

(a)

(b)

Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije životnog ciklusa. Zvjezdasti model, slika 2.7(b), ne uvodi stroga ograničenja u redoslijedu primjene faza i koraka metodologije životnog ciklusa. To ne znači da prirodnog redoslijeda izvršavanja određenih koraka metodologije u ovom modelu nema, već da on zavisi od više faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno inženjerstvo, ili potreba za reinženjeringom postojećeg IS, mogu zahtjevati potpuno obrnuti redoslijed primjene faza životnog ciklusa (primjena "odozdo na gore").

2.5. Metodologija razvoja informacionih sistema
2.5.1. Uvod u metodologiju razvoja informacionog sistema
Metodologija se može definisati kao metoda + idejni pristup. Sadrži u sebi kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih filozofijom, koji potpomažu izgradnju informacionih sistema [Avison & Fitzgerald, 1995]. Metodologija predstavlja skup načela izrade IS, koji se u određenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland, 1994].

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

49

Komponente metodologije se mogu razvrstati u slijedećih pet tačaka: 1. 2. 3. 4. 5. Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodič) upotrebe odabranih tehnika i pomagala; Način upravljanja projektom i nadzorom projekta.

Cilj metodologije je da omogući sistemski postupak razvoja kojim će se moći pratiti napredak, uspostavi komunikaciju između učesnika uključenih u izgradnju IS (poslovodstvo, korisnici, analitičari, programeri), osigura skup tehnika koje će omogućiti da se zadaci izvršavaju na standardne i provjerene načine, osigura efikasan nadzor sa ciljem uočavanja grešaka u ranim fazama. Osim navedenog, cilj metodologije je da omogući elastične promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom će se ukloniti ad hoc rješavanje problema, odredi ili ukaže kada i u kojoj mjeri je potrebno uključivanje korisnika, te potiče i omogućava uključivanje korisnika kada se za to ukaže potreba. Metodologija omogućava da se dovoljno pažnje posveti analizi poslovanja, čime će se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti grešku u ranim fazama, jer je lakše popraviti dokumentaciju nego mijenjati programski kôd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lakše je pronaći grešku tokom faze u kojoj je nastala, nego tražiti je i popravljati na osnovu posljedičnih učinaka primijećenih u kasnijim fazama.

C i j e n a Plan Analiza Oblikovanje Izrada Održavanje

Slika 2.8. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama. Relativno trajanje i cijena otkrivanja grešaka u različitim fazama razvoja IS prikazani su na slici 2.8.

50

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

2.5.2. Pristup razvoju informacionog sistema
Tokom projektovanja IS primjenjuju se, uglavnom, sve vrste modela metodologija životnog ciklusa, ali se razlikuju pristupi razvoju. Mogu se izdvojiti slijedeći pristupi razvoju. Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup jer omogućava opisivanje specifičnih funkcija. Prisutan je problem određivanja nivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna pažnja je posvećena modelu podataka, šta za posljedicu može imati neodgovarajući model baze podataka i otežanu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjerenost podacima (npr. IEM) obezbjeđuje složeniji opis strukture podataka, ali jednostavnije tokove podataka. Procesi se definišu analizom podataka (grupišu oko podataka) i brže konvergira kraju, jer je skup objekata (entiteta) modela konačan. Početak razvoja definisanjem događaja (npr. JSD) je primjereniji sistemima za rad u stvarnom vremenu.

2.5.3. Komercijalne metodologije za razvoj informacionog sistema
Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su navedeni u originalu: • AD/Cycle (Application Development Cycle), • BSP (Business System Planning), • CASE*Method, • IEM (Information Engineering Methodology, Martin), • JSD/JSP (Jackson System Development/ Jackson System Programming), • SA/SD (Structured Analysis / Structured Design), • SASS (Structured Analysis and System Specification), • SSM/M (Soft Systems Method / Multiview), • SSA (Structured System Analysis), • SSADM (Structured System Analysis and Design Method), • Yourdon (Yourdon Structured Method). Objektno usmjerene metodologije: • • • • • Yourdon/OO (Yourdon / Object Oriented), OMT (Object Modelling Technique), BOOCH (Booch’93), Schlaer-Mellor, Unified Modelling Process (Rational).

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

51

Primjena neke od ovih metodologija ne znači da će IS biti dobar! Zahtjevi korisnika se mogu mijenjati u vremenu. Preporučene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Insistiranje na provođenju propisanih procedura vodi u zanemarivanje stvarnih problema, što za posljedicu može imati formalno dobro napravljen, ali neuspješan sistem. Većina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije podržavaju sve faze životnog ciklusa (npr. IEM). Metodologije treba da su podržane odgovarajućim alatima za upravljanje i projektovanje (CASE), što nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano u praksi, prečice do rješenja problema zasnovane na sličnim iskustvima, kao i prilagođavanje razvojnog procesa.

2.6. Savremeni postupci razvoja informacionog sistema
2.6.1. Brzi razvoj aplikacija
Brzi razvoj aplikacija (Rapid Application Development (RAD)) je efikasna izrada programskog proizvoda u relativno kratkom vremenu. Ovo se postiže sistemskom i vremenski sažetom primjenom slijedećih tehnika i alata: aktivno i efikasno uključivanje korisnika, odgovarajuće upravljanje projektom, ispravna upotreba metoda i tehnika razvoja, upotreba CASE alata i modernih programskih jezika (4GL), kao i upravljana izrada prototipa. RAD se obavlja malim ekipama u trajanju od 60 do 120 dana (približno 20 sedmica) za podsistem veličine od 25 do 30 relacija (tabela). Cijena postignutog ubrzanja može biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu priručnih rješenja) i “prljavi” razvoj. Faze brzog razvoja su: 1. JEM (Joint Enterprise Modeling ) – združeno modeliranje organizacije, odnosno sjednice na kojima poslovodstvo i analitičari traže načine usmjerenja organizacije i načine kako je učiniti kompetentnom. Istražuju se ciljevi organizacije, problemi, kritični činioci uspjeha te strategijske mogućnosti; 2. JRP (Joint Requirements Planning) – združeno planiranje zahtjeva, odnosno analiza zahtjeva za razmatrani poslovni sistem. Proučavaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istražuju i definišu informacione potrebe;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13 je prikazan primjer ekranske forme aplikacije nad meta modelom. Jaroslav: Projektovanje informacionih sistema Slika 10.11 strukturirani prikaz (meta model) za primjer Narudžba. . Na slici 10.182 Poliščuk E. Na slici 10. Meta modeliranje može korisno poslužiti za opis poslovnih sistema i funkcija poslovnog sistema. 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.12 strukturirani (meta model) aplikacije Prodaja i na slici 10.

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

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

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

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

a strukturnom kartom se izražava KAKO ostvariti te zahtjeve. Grafički prikaz strukturiranog dizajna.1).2. Jaroslav: Projektovanje informacionih sistema 187 11. Elementi prikaza strukturne karte.2.Poliščuk E. podatak (data couple) funkcija niz poziv ugrađena funkcija (modul) iteracija selekcija indikator (control couple) Slika 11.1. Dijagram toka podataka prikazuje ŠTA treba postići. Strukturirani dizajn Strukturirani dizajn omogućava oblikovanje programa na osnovu dijagrama toka podataka korištenjem strukturnih karti. . Grafički prikaz sistema Dijagram toka podataka Dijagram toka podataka sa određenim granicama Strukturna karta Slika 11. 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. transformacione i transakcione analize.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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