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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

Razmatrani poslovni sistem je obavezno dio nekog projekta izgradnje ili razvoja korporativnog IS. Model parcijalnih procesa omogućava uočavanje i tačno određivanje poslovnih pravila.Poliščuk E. rus. DocFlow. koji se informacioni objekti koriste pri izvršavanju poslovnih procesa i zasebnih operacija. koja se koriste u radu poslovnog sistema. 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. Poslovna pravila. 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. Izgrađeni funkcionalni modeli KAKO JE omogućavaju jasno utvrđivanje koji poslovni procesi se ostvaruju u poslovnom sistemu.9. odnosno određuje uzajamnu vezu između sistema koji se modelira i njegovog okruženja. Na slici 5. Postojeći modeli KAKO JE. документооборот – kretanje dokumenata u organizaciji od trenutka nastajanja ili dobijanja do završetka korištenja ili odašiljanja). Grafički prikaz dijela funkcionalnog modela toka dokumenata. pojave problema i „uskih grla“ u razradi projekta usavršavanja poslovnih procesa. Instrukcija Dokument za rukovodstvo Sortirati dokumente Neregistrovani dokumenti Dokumenti za direktora podliježu registraciji Registrovati dokumente Registrovani dokumenti Prijemno Slika 5. On „određuje“ granice modeliranja poslovnog sistema.9 je predstavljen dio funkcionalnog modela toka dokumenata (eng. Pri izvršavanju operacije „sortirati dokumente“ koristi se poslovno pravilo: „ne podležu registraciji kopirani .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

113

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

114

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

115

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

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

116

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

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

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

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

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

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

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

Implementaciona shema služi. ORACLE). Na osnovu implementacione sheme BP se automatski generiše ORACLE/SQL (ili ANSI/SQL) opis sheme BP. se mogu oblikovati odgovarajućim CASE alatom.7.23.Poliščuk E. sa mogućnošću prenosa podataka između modula. takođe.21. 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. Design Editor/Modules (Designer 2000. Programska specifikacija modula za interaktivni rad sa bazom podataka. . kao osnova za modeliranje programske specifikacije modula i samo generisanje programskih modula. npr. grafikonski prikaz podataka ili bibliotečkog modula. kreiranje izvještaja. koji treba implementirati na odgovarajućem serveru BP. Jaroslav: Projektovanje informacionih sistema 121 Slika 6. slika 6. Dijagram implementacione sheme aplikacije Komercijalni poslovi.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful