Informacioni Sistemi (Napredni Kurs)

prof. dr ing poliuk e.
jaroslav
projektovanje informacionih sistema
Poliuk E. Jaroslav: Projektovanje informacionih sistema
Prof. dr ing Poliuk E. Jaroslav PROJEKTOVANJE INFORMACIONIH SISTEMA
Kompjuterska obrada knjige: autor E-mail: jaroslav@cg.ac.yu
Sva prava zadrava autor.
PREDGOVOR
"Klasina 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 mogui. Jedino mogue materijalistiko tumaenje odravanja organizovanosti je neprekidno izvlaenje iz spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju" [A. Lerner, 2003]. Predvianje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA, vodea u svijetu u analizi kretanja u oblasti globalne industrije informatike tehnologije, glasi: Trend automatizacije informatikih tehnologija e imati veliki uticaj na razvoj softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehniku podrku i umreavanje. Neka informatika zaduenja e biti vea, neka e biti umanjena, neka prebaena u druge dijelove kompanije, a neka e biti ukinuta". Specijalizovani informatiki radnici, koji se istiu samo svojim poznavanjem informatikih tehnologija i vjetinama vezanim za raunare, bez posjedovanja drugih funkcionalnih znanja, bie manje potrebni, predviaju Gartner-ovi analitiari. Prosjeno informatiko odijeljenje u srednjim i velikim kompanijama e do 2010. godine biti za trideset procenata manje, tvrde analitiari trita kompanije Gartner, i zakljuuju: Informatiki radnici budunosti e biti zaposleni u jednom od etiri glavna podruja: tehnolokoj infrastrukturi, projektovanju i upravljanju informatikim sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima. Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, raena na osnovu dostupne literature i obrauje 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 koritene literature. Zahvaljujem se autorima iji su manji dijelovi radova, u djelimino izmijenjenom obliku, uli u sastav ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglaeno, taj propust e rado biti naknadno otklonjen. U pojedinim sluajevima bilo je nemogue razgraniiti autorstvo pojedinih tekstova, jer se isti ili slian tekst mogao nai u razliitim izvorima. Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalistikog studija Elektrotehnikog fakulteta u Podgorici i moe posluiti kao potrebna literatura.
Knjiga moe korisno posluiti 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
SADRAJ
1. Opte 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, trokova 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 tehnolokih procesa ................................................... 83 5.3. Modeliranje toka podataka ..................................................................... 89 5.4. Elementarni procesi ............................................................................... 98
6. Modeliranje podataka ............................................................................... 101 6.1. Osnovni pojmovi modela podataka ...................................................... 101 6.2. Razvoj modela podataka ..................................................................... 111 6.3. Logiko modeliranje podataka ............................................................. 116 7. Modeliranje dogaaja ................................................................................. 123 7.1. Modeliranje procesa voeno dogaajima .............................................. 123 7.2. Matrica entiteti/dogaaji ......................................................................... 124 7.3. Model istorije ivota entiteta .................................................................. 128 7.4. Dijagram prelaza stanja ............................................ 129 7.5. Mape dijaloga .. 130 8. Inenjerski pristup izgradnji IS ................................................................. 132 8.1. Uvod ...................................................................................................... 132 8.2. Programsko inenjerstvo ....................................................................... 133 8.3. Informaciono inenjerstvo ..................................................................... 134 8.4. Sistemsko inenjerstvo ......................................................................... 135 8.5. CASE proizvodi ..................................................................................... 136 8.6. Reverzno inenjerstvo ........................................................................... 148 9. Oblikovanje i arhitektura informacionog sistema .................................. 151 9.1. Oblikovanje (dizajn) sistema ............................................................... 151 9.2. Arhitektura informacionog sistema ..................................................... 153 10. Dizajn baza podataka ................................................................................ 162 10.1. Uvod u dizajn baza podataka ............................................................. 162 10.2. Normalizacija ...................................................................................... 163 10.3. Denormalizacija .................................................................................. 164 10.4. Ugradnja pravila za ouvanje integriteta ............................................ 165 10.5. Podeavanje baze podataka .............................................................. 166 10.6. Trigeri u relacionim bazama podataka ............................................... 168 10.7. Implementaciono projektovanje, generisanje i programiranje BP pomou CASE alata ............................................... 176 10.8. ifarski sistem .................................................................................... 180 10.9. Rjenik podataka katalog ................................................................ 181 11. Dizajn programske podrke ..................................................................... 11.1. Specifikacija i dizajn programske podrke ......................................... 11.2. Pristup oblikovanju programa ............................................................. 11.3. Strukturirani dizajn ............................................................................. 11.4. Dizajn interfejsa .................................................................................. 11.5. Ulanavanje procedura .................................................................... 11.6. Organizacija modula i aplikacija ........................................................ 11.7. Standardizacija i modularnost programske podrke ....................... 186 186 186 187 191 194 195 196
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. Implementacija informacionog sistema .................................................. 12.1. Izrada sistema .................................................................................... 12.2. Programiranje (kodiranje) .................................................................... 12.3. Pristup programiranju ......................................................................... 12.4. Programski standardi i preporuke ...................................................... 12.5. Provjera ispravnosti informacionog sistema ....................................... 12.6. Izrada dokumentacije ......................................................................... 13. Logiko projektovanje programa i programski jezici ............................. 13.1. Dijagram toka (blok dijagram, algoritam) ............................................ 13.2. Strukturirani prirodni jezik (pseudokod) .............................................. 13.3. Akcioni dijagram ................................................................................. 13.4. Stablo odluivanja .............................................................................. 13.5. Tabele odluivanja .............................................................................. 13.6. Struktogram ........................................................................................ 13.7. Programski jezici ................................................................................ 14. Organizacija i upravljanje projektom ....................................................... 14.1. Generiki modeli organizacije ............................................................ 14.2. Organizacija i timski rad ..................................................................... 14.3. Modeli timova ..................................................................................... 14.4. Organizacija velikih projekata ............................................................ 14.5. Upravljanje projektom ........................................................................ 14.6. Planiranje projekata ........................................................................... 14.7. Tehnike za vremensko planiranje ...................................................... 14.8. Izrada plana ....................................................................................... 14.9. Prikaz plana ....................................................................................... 14.10. Raspodjela zadataka ....................................................................... 14.11. Evidencija projekta .......................................................................... 14.12. Praenje napretka (izvrenja) projekta ............................................ 14.13. Preporuke za planiranje poslova ..................................................... 15. Primjena i odravanje informacionog sistema ....................................... 15.1. Uvoenje sistema u primjenu ............................................................. 15.2. Obuka korisnika IS ............................................................................. 15.3. Odravanje informacionog sistema .................................................... 15.4. Poboljanje sistema i reinenjerstvo .................................................. 15.5. Elementi konfiguracije ........................................................................
Literatura .......................................................................................................... 251
1. Opte o informacionim sistemima

1.1. Uvod
Projektovanje informacionih sistema (IS) je kompleksna kreativna djelatnost koja zahtijeva sistemski pristup, metodologiju primjerenu tehnolokim mogunostima. Za organizaciju koja modernizuje IS, i prati dostignua u tehnologiji i metodologiji projektovanja, nije svrsishodno teiti za standardom koji bi vrsto definisao pristup, metodu, sredstva i dokumentaciju, ne uzimajui u obzir vrstu primjene, stepen razvoja IS, karakteristike korisnika i osobine realnog sistema u kome IS djeluje. Brzi tehnoloki razvoj zahtjeva da se dugorono zna ta se hoe. Neophodno je imati strategijsku sliku razvoja IS, koja e obezbjediti kompatibilnost sistema i biti fleksibilna u prihvatanju nove tehnologije. Totalno integrisani IS je nedostian i nepotreban. Ono to je potrebno je dovoljno slobode kako bi korisnici mogli da razvijaju svoju inicijativu u kreiranju sistema koji im je potreban. Pri tome je potrebno potovanje pravila koja e omoguiti da razmjenjuju podatke, ta podrazumjeva zajedniku mreu za prenos, zajedniki model podataka i njihov standardni oblik. U prolosti je razvoj programskih proizvoda bio oslonjen na razliite tipove alata za programiranje. U prvoj fazi razvoja u upotrebi su bili mainski jezici (jezici 1. generacije), ija je itljivost bila veoma mala i koji su zavisili od hardvera. U drugoj fazi se koriste asembleri (jezici 2. generacije), koji su, takoe, bili zavisni od hardvera i teko itljivi. Poslije jezika 1. i 2. generacije, u treoj fazi, u upotrebu su uli jezici 3. generacije (3rd generation languages (3GL)). Jezici 3. generacije su, kao i mainski jezici i asembleri, proceduralno orijentisani. Sa jezicima 3GL, u upotrebu je ula i tehnika strukturiranog programiranja. Bitna karakteristika 3GL je njihova nezavisnost od hardvera. Osnovna prednost uvoenja u upotrebu jezika 3. generacije je bilo poveanje produktivnosti programiranja, odnosno poveanje kvaliteta i brzine realizacije programskih proizvoda. Sa druge strane, poveanje produktivnosti je uzrokovalo smanjenje performansi (brzine rada) tadanjih programskih proizvoda i funkcionalnosti (irine primjene) 3GL. Problem smanjenja performansi je rjeavan uvoenjem u upotrebu sve monijeg hardvera, a problem smanjene funkcionalnosti je rjeavan
10
tehnikom povezivanja programa, pisanih pomou 3GL, sa asemblerskim programima, ili daljim poveanjem mogunosti samih 3GL. Meutim, oekivanja da e programski proizvodi, koji su razvijeni upotrebom 3GL, pratiti potrebe krajnjih korisnika i mogunosti hardvera se ve 70-ih godina nisu ostvarila, to je dovelo do fenomena nazvanog softverska kriza. Osnovni pojavni oblik softverske krize je bio u tome da oekivani efekti od razvoja programskih proizvoda brzo izostaju, bez obzira na znatno poveanje ulaganja u ovu djelatnost, to je ilustrovano dijagramom na slici 1.1. Identifikovani su slijedei problemi kroz koje se softverska kriza prelamala. Programiranje upotrebom 3GL je bilo neefikasno i dugotrajno. Najvei dio programerskog vremena je odlazio na odravanje postojeih programskih proizvoda, to je blokiralo dalji razvoj IS. Tvrdnja da je najvei dio programerskog vremena odlazio na odravanje postojeih programskih proizvoda se moe potkrijepiti slijedeim statistikim podacima. Prema tim podacima 64% greaka pri razvoju IS se pravilo u toku analize korisnikih zahtjeva i projektovanja IS, dok se preostalih 36% greaka pojavljivalo tokom realizacije IS. Od pomenutih 64% ranih greaka, svega 30% je otklonjeno prije isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje greaka iz poetnih faza razvoja programskih proizvoda dovodi do eksponencijalnog rasta trokova uvoenja u upotrebu i odravanje proizvoda. Tako, na primjer, otklanjanje strateke greke u fazi odravanja kota 100 puta vie nego kad se greka otkrije na poetku rada na projektu. Ovo je dovelo do jedne neprirodne raspodjele finansijskih sredstava, uloenih u razvoj IS, prema kojoj preko 70% ukupnih sredstava uloenih u razvoj IS odlazi na njegovo odravanje [Mogin et al. 2000].
Oekivani efekti ulaganja
Ulaganje u softver, hardver, ljudske resurse i razvoj programskog proizvoda
Slika 1.1. Grafiki prikaz fenomena softverska kriza. Poveanje cijene odravanja i neefikasno programiranje su doveli do velikih zakanjenja u realizaciji projekata IS. Prema nekim podacima, veliki projekti u SAD su
11
1985. godine kasnili od 30 do 45 mjeseci. U skladu sa navedenim injenicama, vremenom su identifikovani slijedei uzroci softverske krize: 1. Projektovanje IS bez primjene odgovarajue metodologije dovodi do loeg projekta, pojave velikog broja greaka i prekoraenja zadanih vremenskih rokova zavretka projekta; 2. Nedostatak softverskih alata, koji bi podrali projektovanje IS ili automatizovali postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo, takoe, vodi ka nekvalitetnom projektu uslijed oteanog rukovoenja projektom, fragmentiranog i nekonzistentnog dokumentovanja i neusaglaenosti dijelova projekta IS; 3. Nedostatak odgovarajuih softverskih alata za razvoj aplikacija IS, to vodi ka neefikasnoj realizaciji i odravanju IS. Svi ovi uzroci su doveli do prethodno opisanih posljedica. Rjeenje softverske krize je, prema tome, trebalo traiti u otklanjanju navedena tri uzroka. To je vodilo ka formalizaciji metodologija i tehnika projektovanja IS i pojavi CASE proizvoda i jezika 4. generacije (4th generation languages (4GL)), kao podrke odgovarajuim tehnikama i metodologijama.
1.2. Pojam informacionog sistema

Metodologija razvoja informacionih sistema (IS) treba da bude opta, primjenljiva na sisteme bilo koje vrste, odnosno na neki "opti sistem". Zahtjeva da se precizno definie ta se pod pojmom IS podrazumjeva, koje su njegove funkcije i kakav je njegov poloaj u sistemu u kome djeluje. Iz tih razloga je potrebno poi od slijedeih optih pojmova i definicija. Sistem je skup objekata i njihovih veza (medjusobno povezanih objekata). Objekti u sistemu se opisuju preko svojih svojstava koja se nazivaju atributima. Objekti nekog sistema su povezani sa objektima van njegovih granica, a ovi sa nekim drugim "daljim" i tako dalje. Granice sistema definiu skup objekata koji e se u tom sistemu posmatrati. Zato je neophodno odrediti granice sistema koje izoluju objekte od interesa od "okoline" sistema. Dejstvo okoline na sistem naziva se "ulaz", a dejstvo sistema na okolinu "izlaz" sistema. Sistem na slici 1.2 moe predstavljati poslovni sistem, mreu puteva ili ulica, sistem za prenos elektrine energije, cirkulaciju
12
dokumenata unutar nekog poslovnog sistema, kretanje materijala koji se obrauje, itd. Objekti u sistemu mogu biti veoma razliiti, a veze izmedju objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri naina: razmjenom materije, energije ili informacija.
OKOLINA O1 O2 (interfejs) IZLAZ
ULAZ
O3
On
Slika 1.2. Opti prikaz sistema. Rije informacija, u svakodnevnom govoru, ima smisao obavjetavanja, objanjenja, prenoenja znanja. Za pojam informacije uobiajene su slijedee definicije: "Informacija je kapacitet poveanja znanja" [I. Wilson, 1975]; "Informacija je neto to ukida ili smanjuje neodreenost" [N. Winer, 1979]. Iz ugla upravljanja i donoenja odluka, informacija se moe razmatrati kao svaka vrsta znanja ili poruka koja moe da se upotrijebi za poboljanje upravljanja u nekom sistemu. Ako se poveu definicije pojmova sistema i informacije, moe se izvesti slijedea opta definicija informacionog sistema: Informacioni sistem (eng. Information System) je sistem u kome se veze izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija. Takoe, informacioni sistemi su sastavni deo upravljanja ("odranja eljene organizovanosti") nekog sistema. Iz tog ugla posmatranja moe im se pridodati atribut "upravljaki" i definisati upravljaki IS kao sistem koji prenosi, uva i obrauje podatke pretvarajui ih u informacije potrebne za upravljanje. Pojmovi podatak i informacija se, u svakodnevnom govoru, koriste kao sinonimi. Medjutim, za precizno razgranienje koncepata o kojima se govori, neophodno je i ova dva pojma precizno definisati i razgraniiti.
13
Podatak je kodirana predstava o nekoj injenici iz realnog svijeta, on je nosilac informacije i slui za tehniko uobliavanje informacija, kako bi se one mogle sauvati ili prenijeti. Informacija je protumaeni podatak o pojavi koju podatak prikazuje. Krajnje tumaenje nekom podatku daje sam primalac (ovjek), uz pomo razliitih postupaka obrade podataka. Osnovna funkcija IS je uvanje i prenos podataka o injenicama iz sistema i njegove okoline i njihova obrada u informacije koje zahtjeva korisnik. Znanje se gradi na osnovu novih informacija koje se nadovezuju na postojee znanje. Isti podaci mogu biti razliito interpretirani od strane razliitih ljudi u zavisnosti o njihovom znanju.
1.3. Elementi i osobine sistema i informacionih sistema

Mogu se izdvojiti slijedei elementi sistema i definisati njihove glavne osobine: 1. Podsistemi, odnosno komponente koje pripadaju sistemu; 2. Granice, definiu opseg i domaaj sistema; 3. Okolina je sve to je izvan granica sistema, ali se jo uvijek tie sistema; 4. Ulazi su elementi koji ulaze u sistem iz okoline; 5. Izlazi su elementi koji naputaju sistem; 6. Interfejs je veze izmeu sistema i njegove okoline; 7. Ogranienja, koja sainjavaju unutranji i vanjski inioci koji odreuju i ograniavaju funkcionisanje sistema; 8. Karakteristike, integrisanost. koje opisuju organizaciju, interakciju, meuzavisnost i
Organizacija je struktura i poredak, odnosno hijerarhijske veze koje odreuju formalnu komunikaciju i upravljaki lanac (npr. ustanova, preduzee). Interakcija predstavlja nain na koji pojedine komponente sarauju sa drugim komponentama (npr. Nabavka sa Proizvodnjom, Proizvodnja sa Prodajom). Meuzavisnost pokazuje
14
da jedan podsistem zavisi od drugog (ulaz) da bi mogao funkcionisati, dok je integrisanost mjera povezanosti komponenti. Za informacione sisteme se mogu izdvojiti bitni elementi i definisati njihovne glavne osobine: (1) sistemi za obavjetavanje, odnosno informacioni sistemi; (2) sistemi za upravljanje informacijama vanim za organizaciju i drutvo; (3) sistemi za upravljanje sadrajem ljudskih aktivnosti [Checkland, 1980]. Pojam informacionog sistema podrazumijeva sisteme koji su podrani raunarom, tj. raunarski (kompjuterizovani, kompjuterski) i sisteme koji se ne oslanjaju na raunare, ali obrauju informacije. Namjena IS je prikupljanje i pruanje informacija korisnicima u jednom ili vie poslovnih sistema, te se mogu nazvati organizacioni IS. Korisnici informacionih sistema su poslovodstvo, radnici (zaposleni, osoblje), klijenti i drugi. Upravljanje informacijama se obavlja bez obzira na vrstu sistema, a sainjavaju ga: prikupljanje podataka, zapisivanje i pamenje podataka, obrada podataka, skladitenje i pronalaenje informacija, kao i prikaz informacija u odgovarajuem obliku. Informacioni sistem je podsistem poslovnog sistema. Sainjavaju ga ulazni podaci i izlazne informacije, procesi (obrada podataka o stanjima stvarnog sistema) i izvrioci (osobe, programi, raunari). Poslovne sisteme sainjavaju materijalni ulazi i izlazi (sirovine, energija, proizvodi) i informacioni tokovi (poruke, dokumenti). Ulaz u neki poslovni sistem predstavlja izlaz iz nekog drugog poslovnog sistema. Poslovni sistemi sadre procese (npr. obrada, prerada, proizvodnja), povratne veze (npr. poreenje plana i realizacije), skladita podataka (informacija), izvrioce (osobe, maine, alati, sirovine), skladita materijala, ... . Informacioni sistem odreuju slijedee karakteristike: sloena okolina, koju je teko u potpunosti definisati, sloeni interfejs prema okolini, koji ukljuuje razliite ulaze i izlaze, sloene veze izmeu ulaza i izlaza (strukturno i algoritmiki), kao i veliki obim i sloenost podataka. Problemi projektovanja, izrade i odravanja IS se prevazilaze zbog vanosti IS za jedan poslovni sistem. Informacija je postala upravljaki resurs jednake vanosti kao to su vlasnitvo (osnovna sredstva), ljudski resursi ili kapital. Informacioni sistem sadri/predstavlja znanje organizacije koju podrava. IS i aplikacije pokazuju se prijeko potrebnim za odravanje konkurentnosti ili postizanje kompetitivnog prestia poslovnog sistema. Poslovni sistemi u kojima se IS primjenjuju visoko su zavisni o stalnoj raspoloivosti IS kroz due vrijeme.
15
1.4. Vrste informacionih sistema

Mogu se izdvojiti slijedee vrste informacionih sistema: 1. Transakcioni informacioni sistemi (TIS) [Transaction Processing System (TPS), sinonim Data Processing System], ija je namjena da evidentiraju i obrauju podatke o poslovnim transakcijama; 2. Upravljaki informacioni sistemi (UIS) [Management Information System (MIS)], koji imaju zadatak da podravaju upravljaku funkciju na osnovu dokazanih matematikih/statistikih metoda; 3. Sistemi za podrku odluivanju (SPO) [Decision Support System (DSS)], koji slue za odluivanje na osnovu nestrukturiranih podataka iz razliitih izvora; 4. Izvrni informacioni sistemi [Executive Information System (EIS)], koji predstavljaju podvarijantu IS za izvrne rukovodioce; 5. Ekspertni sistemi (ES) [Expert Systems (ES)], odnosno sistemi sa ugraenim znanjem i simulacijom zakljuivanja; 6. Sistemi za automatizaciju kancelarijskog poslovanja [Office Automation Systems (OAS)]; 7. Sistemi za grupnu podrku [Group Support System, Groupware (GSS)]. Upravljanje i nivoi IS su prikazani tabelom 1.1. Tabela 1.1.
Informacioni sistem Transakcioni Upravljaki Za podrku odluivanju Informacije, kada Obrada podataka, dnevno Zbirne, periodino Sintetizovane, ad hoc Korisnici, ko Nie poslovodstvo Srednje poslovodstvo Vie poslovodstvo, uprava Upravljanje Operativno Taktiko (trendovi) Strategijsko (ta ako, )
16
1.5. ivotni ciklus razvoja sistema (Systems Development Life-Cycle (SDLC))

1.5.1. Pojam ivotnog ciklusa razvoja
Naziv ivotnog ciklusa razvoja zavisi od konteksta u kome je upotrebljen. Mogu se izdvojiti slijedei nazivi ivotnog ciklusa: ivotni ciklus razvoja IS, ivotni ciklus razvoja softvera i ivotni ciklus razvoja aplikacija. Praenje ivotnog ciklusa obezbjeuje konzistentan i standardizovan nain razvoja IS. Svrha praenja ivotnog ciklusa razvoja omoguava pravilno planiranje, izvravanje i nadzor razvojnog projekta. ivotni ciklus definie faze i zadatke (aktivnosti), koje nuno treba obaviti tokom razvoja, bez obzira na veliinu sistema koji se gradi. Svaka pojedina aktivnost proizvodi skup rezultata. Ciklus osigurava kontrolne toke za praenje napretka, procjenu postignutih rezultata i donoenje odluka o daljnjim koracima. Projekat prolazi kroz faze ivotnog ciklusa. Primjer: Za ivotni ciklus razvoja softvera mogu se definisati slijedee faze i zadaci: Potreba analize i dizajna (Requirements Analysis & Specification); Konceptualni/sistemski dizajn (Conceptual/System Design); Detaljni/programski dizajn (Detailed/Program Design); Implementacija/kodiranje (Implementation/Coding); Pojedinano i integralno testiranje (Unit & Integration Testing); Sistemsko testiranje (System Testing); Predaja sistema (System Delivery).
1.5.2. ivotni ciklus i faze razvoja informacionog sistema

Za ivotni ciklus razvoja IS (slika 1.3) potrebno je definisati mnogo kompleksnije faze. Strategijsko planiranje razvoja IS poinje snimanjem stanja (inicijalna strategija). Doprinosi odreivanju poslovnih ciljeva, identifikovanju problema i ideja, odreivanju naina njihovog rjeavanja, te definisanju zahtjeva koji se postavljaju pred sistem. Sadri studiju izvodljivosti, odnosno preglednu analizu problemskog podruja i
17
odreivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada, odreivanja kadrova za projekat, upravljanje i nadzor projekta. Poslovni cilj je izrada glavnog projekta informatizacije. Analiza zahtjeva je detaljna analiza kojom se preciziraju granice projekta i poslovni zahtjevi. Vri se detaljna analiza postojeeg sistema, problema i poslovnih zahtjeva. Specifikacija zahtjeva je detaljni opis zahtjeva za IS, oblikovan tako da ga razumiju dizajneri. Predstavlja model budueg sistema. Oblikovanje sistema, odnosno dizajn (modeliranje) IS, predstavlja pogled projektanta na budui IS. Slui za donoenje odluke o tome kako graditi sistem. Sadri dizajn potrebnih rjeenja. Postoje rjeenja koja ne treba dizajnirati. Detaljni dizajn predstavlja razradu rjeenja, odnosno izradu tehnolokog modela IS (pogled izvoaa). Potrebno je izvriti dizajn arhitekture, interfejsa, pohranjivanja podataka i programa, drugim rijeima izvriti tehniku specifikaciju sistema. Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP), kodiranje procesa (funkcija) novog IS, a vri se nakon odabira raunarske platforme. Testiranje je provjera ugraenih komponenti. Integracija i provjera sistema je udruivanje dijelova i provjera cjeline, da bi se dokazalo da sistem radi (da je ispravno napravljen), te da radi ono to je zahtijevano (da je napravljen pravi sistem koji ispunjava zahtjeve korisnika).
Slika 1.3. Dijagram ivotnog ciklusa i faza razvoja IS [Fertalj & Kalpi, 2005].
18
Uvoenje u primjenu sistema predstavlja prenoenje radnih aktivnosti i konverzija podataka sa starog na novi sistem. Odravanje se sastoji od izmjena sistema radi poboljanja njegovih radnih karakteristika (performansi), poboljanja ili prilagoavanja naina upotrebe. Odravanje podrazumjeva i podrku dobavljaa opreme, pomo tehnikog osoblja korisnicima informacionog sistema u toku njegove upotrebe, kao i izradu plana odravanja. Novi razvojni ciklus se provodi nakon preispitivanja itavog sistema i konstatacije da su potrebne vee izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. Novi razvojni ciklus, najee, predstavlja novi projekat. Na slici 1.4 su navedene tipine faze ivotnog ciklusa razvoja softvera, bez naglaavanja da se radi o diskretnim i/ili sekvencijalnim aktivnostima.
Slika 1.4. Prikaz faza ivotnog ciklusa razvoja softvera.
1.6. Kompleksnost razvoja informacionog sistema

1.6.1. 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, prema zahtjevima korisnika, u prihvatljivom vremenu i po opravdanoj
19
cijeni. Neki od problema koji se mogu pojaviti prilikom razvoja IS su: prekoraenje planiranog vremena i finansijskih sredstava, neispunjavanje zahtjeva, odnosno neodgovarajui sistem, nepouzdanost, nesigurnost, neelastinost IS u primjeni, kao i tekoe u odravanju IS. Oko 70% informacionih sistema u svijetu se smatra neuspjenim. Prosjeno kotanje projekta prema The CHAOS Report [Standish Group, 1994, http://www.standishgroup.com] iznosi: velike kompanije 2,32 miliona $, srednje kompanije 1,33 miliona $ i male kompanije 434 hiljade $. Prosjeno prekoraenje trokova je 189%, a prosjeno prekoraenje rokova 222%. Projekti zavreni na vrijeme, u okviru predvienih sredstava i sa predvienim funkcijama, sainjavaju 16,2%, a projekti zavreni i u funkciji, ali uz vee trokove, due trajanje i/ili reduciranu funkcionalnost 52,7%. Prekinutih projekata je 31,1%. Procenat uspjenih i neuspjenih projekata IS prema Standish Group, 2002. iznosi 34% uspjenih projekata i 17% potpunih neuspjeha.
1.6.2. Neki primjeri neuspjenih projekata i sistema

London Ambulance System (1992): Nakon uvoenja u eksploataciju IS se dva puta "raspao" zbog niza greaka, naroito zbog greaka u upravljanju razvojem IS. Neposredni troak je bio relativno nizak (9 miliona ), ali se vjeruje da su neki ljudi umrli, jer se do njih nije stiglo na vrijeme. Taurus (1993): Projekat sistema automatizovanih transakcija Londonske berze prekinut je nakon 5 godina razvoja i troka od 75 miliona , te posljedini gubitak klijenata od 450 miliona . Ukupni gubici smatra se da su neizraunljivi. Denver Airport (1994): Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odlaganje otvaranja vazdune luke u trajanju od 16 mjeseci, uz trokove od 1,1 miliona $/dan. Ariane 5 (1996): Raketa eksplodirala u lanseru radi niza softverskih greaka.
1.6.3. Uzroci neuspjeha projekata informacionih sistema

Razlozi neuspjenih projekata IS su razliiti. Mogu se izdvojiti slijedei razlozi: sloenost aplikacija, nedostatak usmjerenosti korisniku, zanemarivanje okruenja
20
organizacije, pretjerani optimizam, izostanak praenja napretka i nedostatak komunikacije izmeu korisnika i izvoaa. U naem okruenju uzroci neuspjeha se, uglavnom, ne istrauju, a informacije o neuspjenim projektima nerado se objavljuju. Meu najeim uzrocima moe se pretpostaviti da su: loa organizacija i voenje projekata, oslonac na vanjske projektante i savjetnike, delegirano upravljanje projektima, nerealno planiranje, formalno izvjetavanje o napretku, formalni nadzor nad projektom, kao i podcijenjena uloga vlastitih strunjaka. Ne treba iskljuiti i slijedee uzroke neuspjeha: loa izvedba projekata, neodgovarajua analiza sistema, greke u dizajnu i kontroli kvaliteta, neodgovarajui CASE alati i krivo koritenje, pa ak i svojevrsna zloporaba CASE alata. Mnogi sistemi su propali, ili su bili odbaeni, jer su se izvoai trudili napraviti lijepa programska rjeenja, a nisu razumjeli sutinu poslovnog sistema i poslovanja.
1.6.4. Poboljanje uspjenosti informacionih sistema

Da bi se poboljala uspjenost IS potrebno je: projektovanje IS, planiranje, upravljanje izvedbom, praenje napretka, ukljuivanje korisnika. Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe, a informatiar upoznaje(?) poslovanje i zna(?) kako izraditi IS. Vano je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogunostima i koristima uvoenja IS, naroito jer donosi konane (za poslovni sistem sudbonosne) odluke.
21
2. Planiranje razvoja informacionog sistema

2.1. Modaliteti razvoja informacionog sistema
2.1.1. Vlastiti razvoj informacionog sistema
Postoje razliiti modaliteti razvoja informacionog sistema. U ovoj knjizi e biti razmatrani modaliteti razvoja koji se najee koriste. Razvoj vlastitim informatikim snagama podrazumjeva osposobljavanje i angairanje netehnikog osoblja, kao i povremeno ili dugorono angaovanje spoljnih saradnika. Prednosti ovakvog pristupa su fleksibilnost, kreativnost i poveanje strunosti vlastitog osoblja. Nedostaci su da ovaj pristup zahtijeva znaajno vrijeme i napor, razvoj je skuplji i dugotrajniji i moe poveati gomilanje zaostalog posla. Razvoj vlastitim snagama ima smisla kada se radi o programskoj podrci koja je posebnost organizacije, takva da ne postoje gotova rjeenja na tritu ili takva da organizacija pomou nje postie komparativnu prednost u odnosu na konkurenciju. Postoje dodatni ili posebni razlozi kao to su poveana tajnost podataka i poslovnih procesa ili poveana zatita IS.
2.1.2. Vanjski razvoj informacionog sistema

Angaovanje vanjskih saradnika za razvoj informacijskog sistema, ili njegovih dijelova, podrazumjeva pruanje pomoi u obrazovanju radnika informatike struke, pomo pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja. Takoe se podrazumjeva kodiranje (generisanje) cjelovitog programskog sistema, upravljanje izvoenjem i/ili nadzor izvoenja, kao i konsultativna pomo prilikom ugradnje sloenih poslovnih funkcija. Varijante su slijedee: ugovoreni razvoj, odnosno ugovara se isporuka gotovog proizvoda ili dugorona saradnja sa isporuiocem, uz izdvajanje vlastitog informatikog odjela u glavnog izvoaa. Mogua varijanta je i nalaenje stratekog partnera na dui vremenski period, npr. softverske kue. Prednosti su viestruke. IS ili njegovi dijelovi izrauju se po mjeri naruioca, sistem je prilagoen organizaciji/poslovanju, a po mogunosti treba istovremeno poboljati organizaciju/poslovanje poslovnog sistema. Ovakav razvoj podrazumijeva dugotrajan postupak i odgovarajuu visoku cijenu.
22
Nedostaci i rizici su takoe prisutni. Dolazi do gubitka povjerljivih informacija, gubitka nadzora nad sadanjim i/ili buduim razvojem (zavisnost o dobavljau), kao i gubitak vlastite strunosti. Nuno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogunost odluivanja.
2.1.3. Nabavka gotovih aplikacija

Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe. Poeljno je da se mogu prilagoditi potrebama. Primjeri aplikativnih paketa, koji se mogu nabaviti kao gotovi proizvodi, su: programski paketi za kancelarijsko poslovanje (npr. Microsoft Office), programi za upravljanje dokumentima (npr. Lotus Domino) ili specijalistike aplikacije za odreene namjene. Mogu se nabaviti slijedei sistemi za upravljanje poslovanjem, koji nose komercijalne nazive: Enterprise Resource Planning (ERP) systems, SAP, BAAN, J.D. Edvards, Peoplesoft. Cjeloviti sistemi za podrku poslovanju, uglavnom, podravaju slijedee aplikacije: finansijsko poslovanje (accounting), proizvodnju (manufacturing), robno-materijalno poslovanje (material management/distribution), upravljanje ljudskim resursima i plate (CG management, payroll).
2.1.4. Nabavka poslovnih aplikacija

Slijedei modalitet razvoja IS je nabavka i prilagoavanje postojeih domaih poslovnih aplikacija. Prednost ovog pristupa je usklaenost vaeim uslovima, npr. propisima, ta olakava prilagoavanje aplikacija organizaciji/poslovanju. Nedostatci su nepostojanje ili manjkavost pojedinih komponenti, mjestimina tehnoloka zastarjelost, prekapacitiranost dobavljaa. Modaliteti ovakvog pristupa su slijedei: otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz samostalno odravanje. Nabavka gotovih stranih poslovnih aplikacija, takoe, ima svoje prednosti i nedostatke. Prednosti su raskona funkcionalnost i kompatibilnost sa svjetskim poslovnim standardima, dok se nedostatci ogledaju u neprilagoenosti domaim uslovima i konkretnoj organizaciji/poslovanju, ta zahtijeva istovremeno prilagoavanje programske opreme i promjenu organizacije/poslovanja. Prilagoavanje se obavlja slino razvoju, ta moe uzrokovati da rjeenja gube moguu komparativnu prednost (brzinu i lakou primjene). Glomazni paketi mogu zahtijevati angaovanje velikog broja
23
konsultanata. Mogui modalitet nabavke je da se prilagoavanje vri vlastitim snagama uz savjetovanje i pomo dobavljaa.
2.1.5. Kriterijumi za donoenje odluke o nabavci

Opti kriterijumi za donoenje odluke o razvoju IS su: cijena, funkcionalnost, kapacitet, brzina, broj korisnika, mogunost obuke i trajne podrke, kredibilitet i odrivost dobavljaa na tritu, to se dokazuje referensama, elastinost, tj. mogunost prilagoavanja i prepravki, raspoloivost dokumentacije.
U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost, interoperabilnost), tehnike mogunosti (Client-Server, OLTP, OLAP), referense dobavljaa (prisutnost dobavljaa na lokalnom tritu) i podrka korisnicima. Pod podrkom korisnicima se podrazumjeva: kolovanje, tehnike konsultacije, odravanje (dinamika razvoja i mogunosti nabavke novih verzija), blagovremeno otklanjanje problema, ponuda gotovih aplikacija, kao i pomo u razvoju vlastitih aplikacija.
2.1.6. Nabavka izvedbenog programskog koda

Prednosti nabavke izvedbenog koda su: izvedbeni kd je jeftiniji, brigu i odgovornost o njegovom odravanju preuzima isporuilac, uz izuzetak nekih opte primjenjivih komercijalnih programa. Prednost izvedbenog koda je i ta da se ne mora kupiti (skupi) razvojni programski alat u kojem je programski proizvod razvijan. Mane izvedbenog koda, obzirom na korisnika, su: izvedbeni kd podrazumijeva potpunu zavisnost od isporuioca, ne postoji mogunost prilagoavanja specifinim vlastitim potrebama, osim putem posebnog dogovora sa isporuiocem. Dodatna prilagoavanja lako mogu postati predmetom ucjene. Takoe, ne postoji mogunost razvoja programske opreme vlastitim snagama.
2.1.7. Nabavka izvornog programskog koda

Prednosti nabavke izvornog programskog koda su znatne. Izvorni kd omoguava stalni razvoj i praenje vlastitih posebnosti, to se moe pokazati kao prednost u odnosu na konkurenciju. Osim toga, prua mogunost prilagavanja vlastitim
24
potrebama, ta daje elastinost pri promjenama organizacije poslovanja. Nema bojazni da e nakon prve potrebne izmjene prestati upotreba IS zbog toga to isporuilac nije trenutno dostupan, postavlja nerazumne uslove ili je u meuvremenu nestao sa trita. Uvidom u kvalitetna gotova rjeenja pomae se razvoju vlastitih informatikih radnika. Mane narudbe izvornog koda su, takoe, prisutne. Izvorni kd je viestruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. Naruilac se izlae iskuenju da nekompetentno mijenja nabavljeni izvorni kd, onesposobi aplikaciju za rad i izgubi pravo na odravanje. Odravanje je skuplje ukoliko se radi o programskoj opremi podlonoj promjenama. Snienje cijene izvornog koda moe se postii automatizacijom kodiranja, upotrebom generatora izvornog koda. Preporuke za izbor programskog koda su slijedee. Izvedbeni kd treba preporuiti u slijedeim sluajevima: kada se radi o standardnim, masovno prodavanim aplikacijama, kada korisnik nema vlastite informatike strunjake, kada se radi o visokostrunim aplikacijama koje se nee mnogo mijenjati, a korisnik nema namjeru da se baviti detaljima te struke, kada korisnik nema novaca ili elje za vlastiti informatiki razvoj. Izvorni kd treba preporuiti onda: kada programska oprema predstavlja strateku investiciju, kada korisnik raspolae kompetentnim informatiarima ili ima motiva razvijati vlastitu informatiku djelatnost, kada isporuilac ne moe preuzeti obavezu odravanja ili ne moe garantovati da e ostati na tritu, kada na tritu ne postoji IS koji odgovara potrebama, ne moe se povoljno kupiti slian, a korisnik raspolae vlastitim informatikim snagama dovoljnim za projektovanje novog.
2.1.8. Izbor modaliteta razvoja

Odreivanje moguih rjeenja podrazumjeva identifikaciju rjeenja na osnovu poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija raunarske opreme i programske podrke, te odabrana tehnoloka arhitektura, dok su izlazi mogua rjeenja novog sistema i njihove karakteristike. Analiza izvodljivosti alternativnih rjeenja se sastoji od procjena alternativa obzirom na tehniku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi su
25
karakteristike moguih rjeenja, karakteristike i cijene hardvera i softvera, referense i uslovi dobavljaa, a izlazi analiza izvodljivosti za svako mogue rjeenje. Prijedlog rjeenja sistema koji e se oblikovati i ugraditi se donosi na osnovu izbora onog rjeenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti, plan projekta, procjena veliine projekta, a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloenog sistema.
2.1.9. Ocjenjivanje kriterijuma za izbor sistema

Na osnovu opisa karakteristika ne moe se sa sigurnou procijeniti koji je sistem najbolji. Da bi se pravilno uporedio znaaj razliitih kriterijuma koristi se sistem bodovanja. Procedura bodovanja kriterijuma je slijedea. Odredi se teinski faktor za svaki kriterijum (npr. od 1 do 4). Oni kriterijumi koji su znaajniji u uporedbi sistema dobivaju vee teinske faktore. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. od 0 do 5). Dodjeljena ocjena se pomnoi teinskim faktorom kriterijuma za koji je donesena, te se dobije broj bodova [Fertalj & Kalpi, 2005]. Primjer: Analiza izvodljivosti za mogua rjeenja. Tabela 2.1.
Karakteristike:
Operativni sistem Baza podataka Brzina pretraivanja i dohvat podataka Programski jezik Raspoloiv izvorni kod Korisniki interfejs Integrisani sistem pomoi (on-line help) Dokumentacija (na papiru) Mogunosti aplikacije Integracija sa drugim aplikacijama Brzina ispisa rauna Rad sa razliitim tampaima Rad u mrei Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instalisanih paketa Datum prve instalacije Cijena paketa Cijena raunara i sistemskog softvera
Teinski 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
26
Na kraju se saberu dodjeljeni bodovi po svim kriterijumima za svaki sistem:
Si = 3sij wj
j =1
gdje su: Si = ukupna vrijednost i - tog rjeenja, sij = vrijednost j - tog kriterijuma za i - to rjeenje, wj = vanost ili teina j - tog kriterijuma. Najbolji je onaj sistem sa najveim brojem bodova (npr. Super Video, tabela 2.1). esto se mogu javiti slijedee nedoumice: ta uiniti kada su sistemi (pod)jednako bodovani? ta uiniti ako pojedino svojstvo ima vie podsvojstava?
2.1.10. Izbor dobavljaa proizvoda ili usluga

Definisanje kriterijuma i opcija, kod izbora dobavljaa proizvoda ili usluga, vri se na osnovu slijedeih ulaza i izlaza. Ulazi sadre specifikacije zahtjeva za programsku podrku i raunarsku opremu: funkcionalnost, dodatna svojstva, kljune parametre performansi, ... . Izlazi su lista potencijalnih dobavljaa proizvoda ili usluga, te kriterijumi za izbor. Kod prikupljanja ponuda treba potencijalnom dobavljau uputiti zahtjev za dostavljanje referensi (kada postoje razliiti dobavljai i/ili proizvodi, a eli se odabrati najbolje rjeenje, prikupljaju se ponude koje su skup referensi"), kao i zahtjev za dostavljanje ponude sa informacijama o konfiguracijama, cijenama, odravanju (kada se odreeni proizvod moe nabaviti od razliitih dobavljaa). Izbor ponuda se obavlja slijedeim redoslijedom: (1) provjera sadraja ponuda, (2) izrada rang liste, poeljno odvojenim ocjenjivanjem pojedinanih ponuda, (3) izbor objektivno najboljeg ponuaa (to se, naalost, vrlo teko uklapa u zakonske odredbe po kojima treba tano specificirati to se eli, a mora se kupiti najjeftinije). Ugovaranje posla se zavrava sklapanjem ugovora koji definie uslove saradnje, isporuke i naplate, integracije sa postojeim sistemom, odravanja i slino. Ugovori se mogu raskinuti ili ne ispuniti kako je bilo zamiljeno. Izvrilac projekta treba biti stimulisan proporcionalno ostvarenoj, u praksi dokazanoj i od korisnika prihvaenoj, funkcionalnosti sistema.
27
2.2. Analiza izvodljivosti, trokova i koristi projekta

2.2.1. Analiza izvodljivosti projekta
Za pojedine projekte se vri analiza njihove izvodljivosti, odnosno mjerenje korisnosti, praktinosti i isplativosti projekta IS. Ove analize treba da se vre tokom planiranja, ali i kasnije, npr. nakon faze sistemske analize. Nakon odluke o pokretanju projekta sloenost i opseg projekta se mogu promijeniti, te poetno izvodljiv projekat moe postati neizvodljiv. Praktino gledano, tonost procjene izvodljivosti raste sa dubinom analize. Studija izvodljivosti (feasibility study) sadri: (1) detaljnu provjeru projekta, koju provode sistem analitiari, (2) procjenu da li je projekat izvodljiv obzirom na raspoloiva sredstva, (3) procjenjuje se da li projekat omoguava poboljanja, (4) radi se izvjetaj o izvodljivosti i prezentira se relevantnim uesnicima radi komentara i miljenja (moe biti dio idejnog rjeenja), (5) eventualni povratak u studiju izvodljivosti, odnosno revidirani izvjetaj.
2.2.2. Izvjetaj o izvodljivosti projekta

Izvjetaj o izvodljivosti projekta sainjavaju slijedee analize: organizaciono - operativna izvodljivost, tehniko - tehnoloka izvodljivost, vremenska izvodljivost, ekonomska izvodljivost.
Analiza organizaciono - operativne izvodljivosti projekta sadri procjenu hitnosti rjeavanja problema (planiranje), kao i procjenu prihvatljivosti rjeenja (kasnije faze). Tu se neminovno nameu i slijedea pitanja: Vrijedi li rjeavati problem? i Da li predloeno rjeenje rjeava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno protonost i odziv sistema u odnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, aurne, tane, korisne), ekonomiske aspekte (gdje spadaju problemi trokova i mogunosti uteda), kontrolu (u prvom redu sigurnost i zatitu podataka), efikasnost (odnosno poboljavanje upotrebe raspoloivih resursa: ljudi, opreme, novca, itd.), kao i usluge (poeljni i pouzdani servisi, elastinost i mogunost prilagoavanja, zadovoljstvo). Nita manje bitni nisu ni odgovori na slijedea pitanja: Koji je stav korisnika prema rjeenju? i Da li e se sistem koristiti? Neophodni su podrka uprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uoiti otpore ulozi ili tehnikim
28
rjeenjima sistema i predloiti naine njihovog otklanjanja. Krajnjeg korisnika treba na vrijeme pripremiti za promjenu radnog okruenja i procedura. Procjena upotrebljivosti sistema se najlake moe izvriti koritenjem prototipa. Potrebno je pravilno ocjeniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema. Namjeniti jednostavni interfejs za poetnike i povremene korisnike, sloenije operacije za iskusne korisnike. Obezbjediti da korisnik daje prednost ponuenom rjeenju u odnosu na postojei nain rada. Analiza tehniko - tehnoloke izvodljivosti projekta sadri procjenu moguih rjeenja i alternativa. U prvom redu potrebno je izvriti procjenu stanja na tritu opreme, procjenu postojeih rjeenja u drugim organizacijama (tamo gdje je mogue), kao i procjenu primjenjivosti razliitih tehnologija. Veoma bitna osobina je da se zastupljena tehnoloka rjeenja mogu jednostavno primijeniti. Raspoloivost tehnologije podrazumijeva da se primjenljiva tehnologija moe nabaviti. Ako je rije o gotovom rjeenju, ima li to rjeenje potrebne karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Nita manje bitno nije ni injenica da li postoje potrebni strunjaci za primjenu nove tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija moe savladati. Analiza vremenske izvodljivosti projekta treba da d odgovor da li su predvieni rokovi ostvarivi, obzirom na raspoloivu strunost. Oekivano vrijeme zavretka moe biti poeljno ili obavezno. Bolje je isporuiti ispravan sistem dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme! Ekonomska izvodljivost projekta e biti objanjena preko analiza i uporedbe ukupnih trokova - koristi (cost-benefit analysis (CBA)). Trokovi i korist mogu biti mjerljivi (npr. cijena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr. zadovoljstvo korisnika, brzina odluivanja, dobra referensa). Finansijski troak i korist se mogu izraziti formulama: (1) razlika korist troak u nekom razdoblju (Net Present Value), (2) povrat investicije (korist troak)/troak (Internal Rate of Return), (3) trenutak u kojem korist nadvlada troak (Payback Point). CBA rauna trokove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Dananja vrijednost onoga to e postati $1,00 nakon n godina u budunosti, ako se uzmu u obzir kamate I iznosi: PV = 1/(1 + I)n = (1 + I) n Razlika predstavlja kamatu koja se moe zaraditi tim novcem ($ oznaava novanu jedinicu u bilo kojoj valuti). . Primjeri: Trokovi razvoja od $100.000 imaju trenutnu vrijednost od $100.000;
29
Korist projekta u iznosu od $30.000 za pet godina uz kamatnu stopu od 8% ima trenutnu vrijednost od samo: $30.000 / (1 + 0.08)5 = $20.417 Povrat investicije (Return On Investment (ROI)) se obino dijeli sa duinom trajanja projekta kako bi se dobio godinji ROI. Nizak ROI (~ manji od 10% godinje) moe pokazivati da je korist preniska da bi bila isplativa. Odnos troak/korist je prikazan tabelom 2.2 i grafikim prikazom tabele. Primjer: Analiza troak korist [Fertalj & Kalpi, 2005]. Tabela 2.2.
30
2.3. Strategija i planiranje razvoja informacionog sistema

2.3.1. Definisanje poslovne strategije
Poslovni ciljevi zahtjevaju definisanje poslovne strategije, odnosno planiranje akcija za postizanje ciljeva. Uprava definie viziju i misiju poslovnog sistema, tj. strategijske ciljeve. Na osnovu strategijskih ciljeva se definiu poslovni ciljevi i odreuju zadaci, kojima e poslovni sistem u nekom razdoblju ispuniti svoju misiju. Pri tome se dobijaju odgovori: ta se eli postii (prepoznatljivost, kvalitet, prihodi), kako eljeno postii (promjenom organizacije, poboljanjem sistema administracije), kako ostvariti poveanje proizvodnje ulaganjem u nove proizvodne tehnologije, uz istovremeno odravanje kvaliteta proizvoda, i kako osigurati zadovoljstva i radne sposobnosti zaposlenih dokolovavanjem i mogunostima napredovanja. inioci koji utjeu na postavljanje ciljeva su slijedei: ogranienja (organizaciona, finansijska, zakonska), potrebe i elje uprave, poslovodstva, zaposlenih (ugled, uticaj), vremenski okviri, gdje je kratkorono razdoblje obino manje od 2 godine, srednjorono 2 do 5 godina i dugorono vie od 5 godina [Awad, 1985].
2.3.2. Planiranje razvoja informacionog sistema

Planiranje razvoja informacionog sistema treba da d odgovor na slijedea pitanja: ime se poslovni sistem bavi (grana, proizvodi, trite, konkurencija)? Koji su problemi, zadaci i ciljevi poslovnog sistema? Koja je eljena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, emu i kako slue, koje i kakve podatke sadre? Postoje li aplikacije iji je razvoj u toku? U kojem su stadijumu razvojni projekti? Koje su potrebne aplikacije? Koji su raspoloivi resursi (osoblje, tehnika sredstva, tehnologija)?
Razlozi zbog kojih treba planirati IS su viestruki. Na primjer, u Poslovnom sistemu koji se sastoji od vie cjelina, kao to su Uprava, Finansije, Proizvodnja i Informatika esto postoji vie razliitih tehnikih sistema ili aplikacija, takozvanih informatikih ostrva. To ima za posljedicu umnoavanje informacija uz razliito tumaenje u razliitim dijelovima, nepotpunost informacija, naroito kada svaka cjelina prikuplja samo njoj vane informacije, problem povezivanja informacija pri pokuaju cjelovite interpretacije, kao i problem razliitog posluivanja, razmjene podataka i odravanja.
31
Tradicionalno planiranje IS se provodi odvojeno od poslovnog planiranja ili provodi se kao reakcija na promjene u poslovnoj politici. Strategojsko planiranje IS je prikladno za stabilne poslovne sisteme. U praksi je teko izvodljivo u uslovima preivljavanja. Sastoji se od uspostave smjera i prioriteta usklaivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podrka promjeni poslovnog sistema i poslovnih procesa. Jo se mogu navesti primjene metoda analize i dizajna za prouavanje poslovnog sistema, sa ciljem definisanja opteg (sveobuhvatnog) plana i arhitekture IS iji razvoj slijedi. U praksi situacija je slijedea. Umjesto prema strategijskom planu, poslovni sistem se "dovodi u red" tokom informatizacije i pomou informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budui da se dizajnom sistema predlau ili nameu poboljanja.
2.3.3. Odabir i pokretanje projekta

Prvenstveno pokretai promjena su korisnici, odnosno njihovo nezadovoljstvo aplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokuje nedostatak podataka, to naglaava potrebu uvoenja novih funkcija. Nezadovoljstvo podacima nastaje uslijed njihove nepouzdanosti, nedostupnosti, manjkavosti, a nezadovoljstvo reorganizacijom nastaje uslijed promjene organizacione strukture, promjene poslovnih procesa (npr. promjene na Univerzitetu uzrokovane novim zakonom). Pokretai promjena mogu biti i pokazatelji poslovanja (npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno poveanje trokova), kao i zastarila tehnologija (npr. zastario razvojni alat i prisutan problem njihovog odravanja, zastario interfejs Internet-a, zastarile BP). Odabir projekta se vri na osnovu prijedloga projekta, koga sastavlja sponzor projekta (organizator, predlaga). Prijedlog projekta sadri saetak projekta (naziv, cilj, svrha), poslovne potrebe, oekivanu funkcionalnost, oekivanu korist, kao i posebnosti i ogranienja. Radna grupa za odabir projekta odobrava projekat. Prije pokretanja projekta potrebno je izvriti snimak stanja, odnosno prethodno istraivanje, tj. istraivanje koje prethodi projektu, prepoznavanje problema i potreba, kao i traenje odgovora na pitanje "Da li je projekt vrijedan panje?". Slijedi faza prouavanja problema, produbljivanje snimka, postavljanje ciljeva, prijedlozi rjeenja, procjena izvodljivosti, traenje odgovora na pitanja "Da li su problemi vrijedni rjeavanja? i "Da li je gradnja isplativa?". Planiranje projekta, odnosno organizacija i upravljanje projektom, sastoji se od slijedeih aktivnosti: izrada plana rada, oformljenje projektantske ekipe (ukljuivanje
32
uesnika iz razliitih djelatnosti, npr. radnici razliitih poslovnih podruja ili organizacijskih jedinica, uprava, vanjski konsultanti), pri emu je vano osigurati predanost uesnika zajednikom cilju, i, na kraju, uspostava upravljanja i nadzora projekta.
2.3.4. Snimanje stanja

Snimanje stanja omoguava brzo istraivanje i evaluaciju problema, moguih prilika i direktiva. Pod problemom se podrazumjeva neeljena situacija koja sprjeava potpuno ispunjenje svrhe, postizanje ciljeva, obavljanje zadataka. Mogua prilika je mogunost pozitivne promjene, ak i kada ne postoji problem, dok je direktiva zahtjev ili ogranienje koji su nametnuti poslovnom politikom (npr. pravilnik) ili vanjskim uticajem (npr. zakon). Mogue je opciono provoenje procjena moguih tehnikih rjeenja, pri emu treba imati na umu da to treba biti detaljnije provedeno u kasnijim fazama, kao i odreivanje dosega projekta i poetnog plana projekta. Snimanje poslovnog sistema se sastoji od pregleda poslovnih planova, ako takvi postoje ili nisu tajna, prikupljanja informacija, najee intervjuisanjem korisnika, vlasnika i viih rukovodilaca, kao i evidentiranja problema i prijedloga. Snimanje stanja obuhvata identifikaciju korisnika i opsega postojeeg (postojeih) IS, uoavanje problema i nedostataka postojeeg IS, procjenu potreba za nadogradnjom (poboljanjima), pocjenu potreba za izmjenama (prilagoavanjem i popravkama) i procjenu potreba za izradom novih IS ili podsistema IS (Tabela 2.3). Primjer: Postojei problemi i prijedlozi rjeenja [Fertalj & Kalpi, 2005]. Tabela 2.3.
Kratko obrazloenje problema, mogunosti ili direktive 1. Vrijeme odgovora na narudbu mjereno od vremena zaprimanja narudbe do isporuke klijentu se povealo na prosjeno 15 dana. 2. Nedavno preuzimanje kompanija: Privatna predstava i Filmsko platno nametnulo je poveanje zahtjeva za protokom informacija i dokumenata. 3. Trenutno 3 razliita sistema za unos narudbi servisiraju odjele za audio, video i video igre. Svaki sistem ima vlastiti interfejs prema razliitom skladinom sistemu, pa treba objediniti skladinu evidenciju. 4. Postoji nedostatak pristupa informacijama nunim za upravljanje i donoenje odluka. Ovo e se jo pogorati preuzimanjem dva dodatna sistema za obradu narudbi (iz Privatna predstava i Filmsko platno). 5. Izraena je nedoslijednost (nekonzistentnost) izmeu podataka u evidencijama lanova i narudbi. Hitnost HITNO 6 mjeseci 6 mjeseci Vidljivost Visoka Srednja Korist 175000 75000 Prioritet 2 2 Predloeno rjeenje Novi razvoj Novi razvoj
Srednja
515000
Novi razvoj
12 mjeseci
Niska
15000
3 mjeseca
Visoka
35000
Nakon razvoja novog sistema, pruiti korisnicima lako savladive alate za pisanje izvjetaja. Brza ispravka, a zatim novi razvoj.

6. Sistemi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni sa onim u Zvuna pozornica. Problemi sa podacima obuhvataju nedoslijednosti u podacima i nedostatak upravljanja ulazom i izmjenama. 7. Postoji mogunost uvoenja sistema naruivanja putem Interneta, ali su sigurnost i kontrola pristupa problematini. 8. Postojei sistem unosa narudbi nije kompatibilan sa planiranim sistemom za automatsku identifikaciju (tapiasti kod) koji se razvija za skladite. 6 mjeseci Srednja nepoznata 2
33
Novi razvoj, dodatna ocjena koristi moe poveati aurnost. Budue verzije tek razvijenog sistema. Brza ispravka, a zatim novi razvoj.
12 mjeseci 3 mjeseca
Niska Visoka
nepoznata 65000
4 1
Vidljivost: U kojoj mjeri e rjeenje ili novi sistem biti vidljivi korisnicima. Korist: Paualna procjena koliko bi rjeenje povealo dobit ili smanjilo troak u jednoj godini.
2.3.5. Planiranje projekta

Planiranje projekta podrazumjeva odreivanje namjene projekta i izdvajanje zadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Domet i razgranienje projekata ili podprojekata (System boundary, Constraints, Objectives, Permissions, End products (SCOPE)) daje odgovore na slijedea pitanja: Koje su granice sistema? Koji e zahtjevi biti ispunjeni? ta ne moe biti napravljeno? ta nee biti napravljeno? Ko e, kako i pod kojim uslovima moi koristiti rjeenje? Kako se mjeri ili odreuje uspjeh (neuspjeh)? Kako e se znati da je projekat gotov?
Vremensko planiranje obuhvata odreivanje prioritetnih zadataka i vremenskih okvira prioriteta. Izrada poetnog (preliminarnog) plana razvoja IS zapoinje podjelom projekta u manje cjeline i odreivanje redoslijeda realizacije pojedinih podprojekata. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada i raspodjela poslova, kao i odreivanje prioriteta. Nastoji se pronai takva podjela posla na cjeline da cjelinu moe obaviti jedna osoba ili ekipa, da se cjelina moe obaviti jednom metodom i posao zavri jednim proizvodom (dokumentom, aplikacijom ili podsistemom). Poetni plan razvoja IS sadri nazive podprojekata i omoguava doradu i auriranje u skladu sa napretkom projekta. Moe se koristiti za prezentaciju projekta radi traenja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta moe posluiti kao interni ugovor projekta (tabela 2.4).
34
Primjer: Poetni (preliminarni) plan informacionog sistema, tabela 2.4. Tabela 2.4.
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Nabavka sistema za upravljanje bazama podataka; Obuka opte informatike pismenosti za rukovodioce odjeljenja; Obuka za programere u jeziku za upravljanje bazama podataka; Obuka za administratore baze podataka; Izrada prototipa programske podrke za i-tu fazu realizacije; Izrada - verzije aplikacije; Testiranje - verzije u informacionim sistemima; Uklanjanje uoenih nedostataka i izrada - verzije programa; Obuka za odabrane korisnike na - verziji; Testiranje kod korisnika u paralelnom radu sa dosadanjim programom; Uklanjanje nedostataka i izrada stabilne verzije; Zamjena dotadanjeg programa novim programom, uz preuzimanje podataka; Obuka za ostale korisnike; Uvoenje koritenja programa kod ostalih korisnika; Obuka za upoznavanje sa mogunostima programa za odabrano poslovodstvo; Prikupljanje primjedbi korisnika i novih zahtjeva; Izrada slijedee faze/verzije programa. Povratak na taku 5).
2.3.6. Izvjetaj o projektu

Izvjetaj o projektu obrauje probleme i dostignua projekta, a moe imati oblik prikazan tabelom 2.5. Tabela 2.5.
Saetak - Saetak prijedloga - Kratko obrazloenje oekivanih koristi - Kratko objanjenje sadraja izvjetaja Prikupljene informacije - Kratak opis projektnog zadatka - Kratko objanjenje provedenih aktivnosti injenice i zakljuci
(moe se potkrijepiti matricom problema i moguih rjeenja)
Problemi i analiza problema Mogunosti i analiza mogunosti Direktive i implikacije
Detaljan prijedlog - Obrazloenje prijedloga * Hitne prepravke * Brze prepravke * Unapreenja * Novi razvoj Plan projekta * Poetni ciljevi projekta * Poetni glavni plan projekta (na nivou faza) * Detaljni plan za slijedeu fazu Prilozi - Zahtjev za uslugama sistema - Matrica obrazloenja problema - (ostala dokumentacija)
35
2.3.7. Odreivanje poslovnih ciljeva

Za projekte koji prou poetnu selekciju vri se produbljivanje analize problema. Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rjeavanja i da li je gradnja IS isplativa. Vri se detaljnija analiza problema, njihovih uzroka i posljedica, imajui na umu misao: "Ne pokuavaj popraviti prije nego shvati kako radi!" Takoe je potrebno izvriti analizu poslovnih procesa odgovarajui na pitanja: Koji su najvei problemi? Koja su mogua rjeenja problema? Kako informatizacija moe pomoi? kao i grubo modeliranje postojeeg sistema. Mogu se koristiti razliite formalne metode, od kojih su najznaajnije: 1. Analiza kritinih faktora uspjeha (Critical Success Factors (CSF)), odnosno inilaca, kojima poslovodstvo posveuje posebnu panju. Ti inioci treba srazmjerno brzo i lako da doprinose ostvarivanju ciljeva (npr. brzi odgovor na zahtjeve klijenata, odnos cijene i kvaliteta proizvoda, ... ); 2. Planiranje poslovnog sistema (Business Systems Planning (BSP)) firme IBM, odnosno analiza poslovnih procesa analizom od vrha prema dolje i uoavanje podataka povezanih sa procesima; 3. Analiza izvodljivosti i procjena trokova - koristi.
2.3.8. Uzroci i posljedice problema, ciljevi i ogranienja

Istraivanje uzroka problema, koji mogu biti raznovrsni, se mogu ilustrovati na slijedeem jednostavnom primjeru:
Problem: Vidljivi znak: Razlog: Uzrok: pad prodaje poveani opoziv (storno) narudbi nezadovoljstvo kupaca spor sistem za naruivanje
Zadatak analitiara je da razdvoji uzroke i posljedice problema. Drugi primjer: Dug red u videoteci nije poseban problem, a moe biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica runog unosa podataka i izdavanja rauna.
36
U razmatranom primjeru analitiar treba razmotriti da li je zahtjev vlasnika videoteke za ubrzanjem procesa izdavanja filmova realan. Primjeri poslovnih ciljeva mogu biti raznovrsni. Ovdje e biti navedeni, kao primjeri, neki od moguih ciljeva: pomoi reorganizaciju u trino orijentisanom poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troka u sistemu, uskladiti hijerarhiju odluivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utroak novca za ... . Ogranienja mogu biti slijedea: osoblje (npr. odjel informatike smije zaposliti najvie tri stalno zaposlena radnika), materijalni troak (npr. nabavka kancelarijskog i potronog materijala ne smije premaiti XXX ),raunarska oprema (npr. projekat se mora obaviti bez nabavke novog hardvera ili poeljno je da troak opreme predstavlja najmanje 33% budeta), finansijska sredstva (npr. ukupni budet projekta je XXXXX ) ili naknade izvoaima ne smiju prekoraiti XX% ukupnog iznosa). Analiza uzroka i posljedice problema, njihovi ciljevi i ogranienja su prikazani u tabeli 2.6 [Fertalj & Kalpi, 2005]. Tabela 2.6.
ANALIZA UZROKA I POSLJEDICA Problem ili mogunost 1. Vrijeme odgovora na narudbu je neprihvatljivo dugo. Uzroci i posljedice 1. Promet je povean, a broj slubenika smanjen. Vrijeme obrade narudbe je isto. 2. Sistem previe zavisi o runom unosu. Pojedine vrijednosti se unose vie puta. Posljedica je da se narudbe obrauju due nego je potrebno. 3. Sredinji raunar radi na maksimumu svoga kapaciteta, ta se ogleda u sporijem radu aplikacije za unos narudbi. Budui da slubenici pokuavaju bre raditi, poveao se broj greaka pri unosu. CILJEVI I OGRANIENJA SISTEMA Ciljevi sistema 1. Smanjiti vrijeme unosa pojedine narudbe za 30%. 2. Runi unos narudbi svesti na 50% ukupnog broja. 3. Na ekranskoj formi raunara za runi unos smanjiti broj potrebnih pritisaka na tastaturu. 4. Prenijeti unos podataka sa sredinjeg raunara na PC. 5. Zamjeniti postojee obrasce za prikupljanje narudbi mrenim sistemom izmeu skladita i prodaje, tako da se eliminie upotreba Ogranienja sistema 1. Broj zaposlenih u obradi narudbi se ne moe poveati. 2. Novi sistem mora biti kompatibilan sa postojeim Windows XX standardom. 3. Novi sistem mora biti kompatibilan sa ve odabranim sistemom za automatsku identifikaciju tapiastim kodom.
37
4. Obrasci za prikupljanje narudbi iz skladita nisu oblikovani za racionalno popunjavanje, to dodatno usporava unos narudbi.
papirne dokumentacije.
2.3.9. Modeliranje postojeeg sistema

Svrha modeliranja postojeeg sistema je preciziranje dometa projekta, kao i verifikacija razumijevanja problema i usaglaavanje percepcije sistema i stavova izmeu uesnika (korisnici, informatiari). Pri tome primjeniti taktiku skrivanja zanemarivanja detalja i usredotoenje na ono to je zaista vano (npr. izbjegavanje prouavanja tehnikih detalja u ranim fazama). Kreirati globalni, okvirni, grubi model sistema i to: model organizacije i resursa (kontekst, organizaciona struktura, prostorni raspored sredstava), globalni model procesa (funkcionalna dekompozicija, tok kljunih poslovnih procesa, kruenje dokumenata i protok informacija) i globalni model entiteti-veze (kategorije podataka, klase podataka (ne klase objekata!)).
2.3.10. Planiranje informacionog sistema

Planiranje informacionog sistema se sastoji od analize problema, povoljnih prilika i moguih rjeenja problema, definisanja ciljeva i zadataka informacionog sistema, kao i procjena ogranienja. Tu spada ponovna procjena i preciziranje opsega projekta, a po potrebi i revizija glavnog plana. Tokom izvoenja projekta esto se dogaa polagano, ali znaajno, poveanje obima uslijed pogrene procjene ili razliitog tumaenja ciljeva izmeu korisnika i izvoaa, tzv. puzei domet projekta. Granice projekta moraju biti definisane to je mogue preciznije. Time se kasnije poveanje projekta, moda, nee ukloniti, ali e se barem moi kontrolisati. Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspjenosti. Planira se prototip koji se moe uspjeno i brzo realizirati (npr. 3 do 9 mjeseci, u zavisnosti o veliini itavog projekta). Poeljno je realizovati takav prototip koji e omoguiti procjenu moguih tehnikih rjeenja IS
38
(alternativa) i prijedlog najboljeg rjeenja, a pored toga vratiti uloenu investiciju. Na kraju se (opet!) moe oekivati pokretanje, odbacivanje, odgaanje ili prilagavanje (ostalih, pojedinih) projekata. Tabela 2.7 prikazuje idejno rjeenje plana razvoja IS. Tabela 2.7.
Saetak - Saetak prijedloga - Saetak problema, mogunosti i direktiva - Kratki navod ciljeva unapreenja sistema - Kratki navod sadraja izvjetaja Poznate informacije - Popis odranih razgovora i kordinisanih grupnih sastanaka - Popis ostalih izvora informacija - Opis tehnika koritenih u analizi Pregled postojeeg sistema - Strategijske odrednice - Modeli postojeeg sistema * Model interfejsa (kontekst) * Model resursa (prostor) * Model procesa (funkcija) * Model podataka (kategorije) Analiza postojeeg sistema
* problemi, mogunosti i analiza uzroka i posljedica za pojedine elemente
- Performanse - Informacije - Ekonomija - Kontrola - Djelotvornost - Usluge (servisi) Detaljni prijedlozi - Ciljevi i prioriteti unapreenja sistema - Preporuke unapreenja sistema - Plan projekta * Precizirati domet projekta * Revidirati glavni plan * Detaljni plan za slijedei korak Dodaci - Modeli sistema (ako nisu dio studije) - (ostala dokumentacija prema potrebi)
2.4. Modeli razvoja informacionih sistema

2.4.1. Sekvencijalni (vodopadni) model razvoja informacionog sistema
Polazna pretpostavka metodologije ivotnog ciklusa je da se faze razvoja realizuju strogo sekvencijalno, istovremeno za cijeli programski proizvod. Kada je rije o informacionom sistemu, tada se svaka faza istovremeno primjenjuje na svaki od podsistema, u okviru identifikovane arhitekture IS. Istovremeno se, takoe, projektuje i shema baze podataka IS. Realizacija naredne faze ne zapoinje dok se tekua faza ne zavri. Greke iz prethodnih faza, otkrivene u tekuoj, zahtjevaju da se one otklone i dokumentuju vraanjem u prethodne i prolaskom kroz sve faze koje slijede iza faze
39
gdje je greka napravljena. Ovakav nain primjene metodologije ivotnog ciklusa i strukturiranog pristupa se zove sekvencijalni ili vodopadni (waterfall) model primjene metodologije ivotnog ciklusa. Dobre strane ovog pristupa su: integrisanost IS, dobra dokumentovanost i praktino istovremeni zavretak svih podsistema IS. Zahvaljujui dobroj dokumentovanosti pojednostavljeno je odravanje aplikacija IS. Takoe, ovaj pristup daje dobre garancije da e, u konanom vremenu, doi do zadovoljavajueg rjeenja programskog proizvoda, ime se smanjuje rizik od neuspjeha razvoja. Sekvencijalni pristup, pored dobrih osobina, ne daje uvijek prave efekte kada je u pitanju ostvarenje prethodno definisanih ciljeva. Uzroci su viestruki, a neki od njih su slijedei [Mogin et al. 2000]: 1. U sekvencijalnom modelu primjene metodologije ivotnog ciklusa krajnji korisnik nije dovoljno ukljuen u proces razvoja programskog proizvoda; 2. Izmeu poetka projekta i prvih operativno primjenljivih rezultata kod korisnika vremenski interval je dosta dug; 3. esto se javlja potreba da se precizni, metodoloki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtjeva; 4. Umjesto da to bude postupno, postoji potreba da se u razvoj IS odjednom uloe znaajna finansijska sredstva. Uzajamnio djelovanje prva tri nedostatka sekvencijalnog pristupa ima za posljedicu da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisniki zahtjevi esto otkrivaju tek u fazi uvoenja aplikacije u upotrebu, to je jako kasno jer se korekcija greaka i odravanje komplikuju, a produava se vrijeme potrebno za dobijanje konanog rjeenja aplikacije. U cilju izbjegavanja negativnih efekata sekvencijalnog pristupa javio se prototipski pristup, kao i evolutivni, inkrementalni, spiralni, zvjezdasti, V model i drugi manje znaajni modeli. Mogu se izdvojiti slijedee varijante sekvencijalnog (vodopadnog) modela: klasini vodopadni model, pseudostrukturirani vodopadni model i radikalni (strukturirani) razvoj. Klasini vodopadni model (slika 2.1(a)) redoslijedno (sekvencijalno) napreduje iz faze u fazu. Nisu dozvoljene naknadne promjene rezultata prethodnih faza. Prikladan je velikim projektima (investicijama), za dobro definisano okruenje, gdje postoje razraene procedure rune obrade ili raunarski sistem koji treba unaprijediti. Nedostaci ovog modela su izraeni u sluaju greaka ili novih/promijenjenih zahtjeva, kao i u potrebi uvoenja prema gore (bottom up) modula, podsistema i sistema. Sistem nije upotrebljiv dok nije u potpunosti gotov. Problem predstavlja i predodba o proizvodu na osnovu pisane specifikacije.
40
Pseudostrukturirani vodopadni model (slika 2.1(b)) sadri povratnu vezu i mogunost promjene rezultata prethodnih faza. Ovaj model razvoja IS omoguava primjenu tehnika strukturiranog programiranja.
Analiza
Analiza Oblikovanje Izrada Evaluacija Primjena Primjena (a) (b)
Oblikovanje
Izrada
Evaluacija
Slika 2. 1. Uporedni prikaz klasinog razvoja (a), pseudostrukturiranog i radikalnog razvoja (b). Radikalni (strukturirani) razvoj (slika 2.1(b)) omoguava da se aktivnosti razliitih faza mogu obavljati istovremeno. Dozvoljava koritenje rjenika podataka, programskih jezika etvrte generacije (4GL) i generatora aplikacija. Prikladan je kada se unaprijed ne zna konani izgled sistema.
2.4.2. V model razvoja informacionog sistema

V model razvoja IS (slika 2.2) omogua definisanje rezultata (proizvoda) pojedinih faza koji se proslijeuju u slijedee faze. Tim rezultatima se testiraju elementi IS na razliitim stepenima razvoja.
41
Test prihvatljivosti Testirani sistem
Analiza
Scenariji aplikacije
Specifikacija zahtjeva
Strukturirano oblikovanje
Ogledni sluajevi
Integracija sistema
Model sistema Detaljno oblikovanje Dizajn modula Kodiranje i testiranje
Testirani softver Integracija modula Testirani moduli
Ogledni sluajevi
Slika 2.2. Primjer V modela.
2.4.3. Prototipski model razvoja informacionog sistema

Uz strukturirani pristup, prototipski pristup razvoju programskog proizvoda predstavlja koncept koji se moe primjeniti u okviru metodologije ivotnog ciklusa. Prototipski pristup postaje u punoj mjeri praktino primjenljiv (iako je ideja o prototipskom pristupu u softverskom inenjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda, koji su integrisani sa okruenjem etvrte generacije. U zavisnosti od njegove namjene, mogu se uoiti slijedee tri vrste prototipskog modela. Model oponaanja (model u prirodnoj veliini), odnosno jednoekranski ili
42
vieekranski model kojim se prikazuje kako e izgledati dio sistema (npr. interfejs), istraivaki model, za istraivanje dijelova sistema kako bi se provjerile neke kljune postavke (npr. provjera performansi odreenog modula) i, na kraju, ugradbeni model, tj. traenje razliitih naina na koje se sistem moe izgraditi (npr. koji sistem za upravljanje BP, programski jezik, raunari). Prototip moe postupno, inkrementalnom doradom, da postane dio zavrnog IS. Prototipski razvoj podrazumijeva iteraktivni pristup, obino koritenjem 4GL. Radni model daje se na uvid korisniku i omoguava korisniku stvaranje slike o izgledu sistema. Korisnik daje primjedbe za popravak i poboljanja, ime se stie bolja slika o zahtjevima korisnika. Ujedno se uklanjaju mogua iznenaenja na kraju razvoja. Savremeni softverski alati omoguavaju brzu izradu prototipa. Funkcionalni prototip dogradnjom moe da postane radni sistem (slika 2.3). Ovakav pristup razvoju IS je prikladan za male projekte. Prednosti su u iteracijama promjena (korisnici se smiju predomisliti), poveanju kreativnosti i brzini razvoja. Nedostaci su u tome to se zaboravlja da prototip nije pravi sistem, mogui neuspjeh zamjene prototipa radnim sistemom, dokumentacija proizlazi iz izrade pa postoji opasnost da pisane specifikacije nikad nee biti napravljene, kao i nemogunost ispravne procjene i planiranja resursa. Ogranieni/strukturirani razvoj prototipa slui kao sredstvo za odreivanje zahtjeva. Dobija se nefunkcionalni prototip (koji se ne moe koristiti u obavljanju radnih zadataka korisnika, a sadri izgled ekranskih formi, menia i izvjetaja), iji se razvoj u odreenom trenutku prekida i slijedi faza oblikovanja sistema (slika 2.4). Odreivanje zahtjeva
Dizajn prototipa Izrada prototipa Razvoj prototipa
Radni sistem
Slika 2.3. Dijagram brzog razvoja prototipa.
43
Odreivanje zahtjeva Dizajn prototipa Izrada prototipa Razvoj prototipa Radni sistem Prototip Dokumentovanje zahtjeva Oblikovanje Specifikacije zahtjeva
Slika 2.4. Dijagram ogranienog/strukturiranog razvoja prototipa. Praktini aspekti primjene prototipskog pristupa su viestruki. Rije je, uglavnom, o injenicama proisteklim iz iskustva u praktinoj primjeni prototipskog pristupa. Zbog toga, moe se rei da su te injenice prije savjetodavnog, nego formalno strogog karaktera. Opte preporuke za primjenu prototipskog pristupa su slijedee [Mogin et al. 2000]: 1. Potrebno je, prije poetka primjene prototipskog pristupa, precizno definisati standarde za izgled korisnikog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti sa mogunostima odabranog CASE proizvoda, a generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi za programiranje i izgled korisnikog interfejsa, a sve u cilju postizanja bolje podrke standarda; 2. Preporuuje se dekomponovanje cjeline IS na manje projekte, a zatim definisanje nieg stepena meusobne integracije informacionih podsistema, u odnosu na klasinu primjenu metodologije ivotnog ciklusa; 3. Kako korisnik ne bi bio doveden u zabludu, prilikom predaje korisniku prototipa aplikacije, obavezno ga upoznati sa injenicom da je u pitanju prototip a ne konano rjeenje. Pri tome treba precizirati nain upotrebe prototipa od strane korisnika;
44
4. Ne treba praviti vie od tri prototipa jedne aplikacije, ukoliko je to mogue, kako se ne bi produilo ukupno vrijeme izrade aplikacije i dolo do zamora krajnjih korisnika i projektantskog tima; 5. Treba se orijentisati preteno ka odbacivim prototipovima aplikacija, ukoliko se eli postii to krae vrijeme dolaska do prototipa, jer se time izrada samog prototipa pojednostavljuje (odbacivi prototip se dobija primjenom generatora koda, a koristi BP ija shema ne mora biti blizu konanog rjeenja); 6. Radei sa prototipom aplikacije, korisnik treba da upotrebljava iskljuivo test podatke. On mora biti prethodno pripremljen na injenicu da, ukoliko u meuvremenu doe do prestrukturiranja sheme BP, uneseni test podaci mogu biti izgubljeni. Do gubitka test podataka moe doi u situaciji kada je za njihovo prestrukturiranje potrebno uloiti veliki napor, pa se od predstrukturiranja svjesno odustaje, ili kada je takvo prestrukturiranje nemogue izvriti zbog izmjena u shemi BP; 7. Prototip aplikacije moe da predstavlja rjeenje koje je dobijeno pomou generatora koda nekog CASE proizvoda, prvenstveno na osnovu specifikacija konceptualnog nivoa. To znai da se detalji, koji se definiu tek u implementacionom projektu, a nisu podrani odgovarajuim generatorom, ne realizuju u okviru prototipa aplikacije kako slijedea generisanja ne bi unitila tako isprogramirane cjeline. Na taj nain se postie kratko vrijeme izrade prototipskog rjeenja, ali ne i njegova potpuna funkcionalnost; 8. Ako je mogue, u prototip aplikacije treba ukljuiti i odgovarajue izvjetaje, jer tada korisnik lake sagledava upotrebljivost aplikacije; 9. Rjeenja IS, istih ili slinih poslovnih sistema, mogu biti dobra osnova u primjeni prototipskog razvoja. Potekoe koje se mogu izbjei primjenom prethodno opisanih preporuka, a koje se mogu javiti prilikom primjene prototipskog razvoja, su slijedee. Iterativni pristup moe dovesti do zamora krajnjih korisnika i projektanata. U cilju izbjegavanja problema, posebno treba obratiti panju na preporuke 3 i 4. Upotreba generatora koda je mogua tek kada je formiran odgovarajui dio sheme BP, a sa druge strane treba koristiti prototip aplikacije upravo da bi se pribavile sve relevantne informacije za strukturiranje sheme BP, to znai da su ova dva zahtjeva meu sobom u suprotnosti. Primjena preporuka 5, 7 i 9 vodi ublaavanju ovog konflikta. Ako se radi o neodbacivim prototipovima (neodbacivi prototipovi se evolutivnim podeavanjem pretvaraju u konana rjeenja aplikacija), dorada izgenerisanih aplikacija moe biti zamoran i vremenski zahtjevan posao. U cilju pribliavanja korisnikog interfejsa i funkcionalnosti generisane aplikacije konanom rjeenju, odnosno olakavanja postupka dorade izgenerisanih aplikacija, vano je preduzeti mjere predviene
45
preporukom 1. Usaglaavanje podataka, unesenih putem neodbacivog prototipa sa bitno prestrukturiranom shemom BP, je esto vremenski zahtjevan i neizvjestan posao. U cilju izbjegavanja problema, posebno treba obratiti panju na preporuke 5 i 6. Intervencije na prototipu kod korisnika mogu stvoriti lani utisak da je projektovanje IS trivijalan posao. Da bi se problem izbjegao, posebno treba obratiti panju na preporuku 3. Primjena preporuke 9, ako za nju postoje uslovi, moe biti u funkciji ublaavanja ovog problema. Ako je rije o manje iskusnim korisnicima ili projektantima, moe se dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva, odnosno pravovremeno identifikovanje informacionih zahtjeva, a da pri tome projektant ne uoi takav propust na vrijeme. Primjena preporuka 8 i 9 moe pozitivno uticati na ublaavanje ili izbjegavanje ovog problema. Primjena prototipskog pristupa IS je pokazala da on nije primjeren razvoju integrisanih IS, jer insistiranje na brzom uvoenju aplikacija u funkciju dovodi do parcijalizacije IS. Zbog toga je vano obratiti panju na preporuku 2. Aplikacije koje se razvijaju samo primjenom prototipskog pristupa mogu postati izolovana ostrva. Imajui u vidu tu injenicu, direktna primjena iskljuivo prototipskog pristupa je mogua u sluaju da treba razvijati skoro izolovane podsisteme sa niskim stepenom meusobne integracije. Sa druge strane, oekuje se da prototipski pristup doivi svoju punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primjene metodologije ivotnog ciklusa. U tom smislu, posebno znaajnu ulogu ima evolutivni pristup razvoju IS.
2.4.4. Evolutivni model razvoja informacionog sistema

Primjena IS mijenja pogled korisnika, a njegove potrebe se mijenjaju (rastu) tokom primjene. Moe se zakljuiti da IS raste sa poslovnim sistemom koga podrava. Te iste pojave su prisutne i u razvoju IS. Jedan od osnovnih principa, na kome se zasniva primjena sekvencijalnog modela metodologije ivotnog ciklusa, je da realizacija naredne faze ne zapoinje dok se tekua faza ne zavri. Uoava se da upravo primjena ovog principa, kod nekih projekata, moe intenzivirati negativne efekte primjene metodologije ivotnog ciklusa. Evolutivni model primjene metodologije ivotnog ciklusa, nasuprot sekvencijalnom, predvia da je za odreene faze ivotnog ciklusa programskog proizvoda mogue da naredna faza zapone prije nego to se prethodna zavri, to dovodi do odreenog stepena paralelizma u realizaciji tih faza. Prema tome, faze ivotnog ciklusa poinju da se sprovode iterativno. Do ove ideje se dolo na osnovu pretpostavke da ne treba odjednom realizovati kompletnu fazu i utroiti za to veliku koliinu vremena i novca, u situaciji kada se projektantske aktivnosti izvode na osnovu
46
nedovoljno precizno identifikovanih informacionih zahtjeva. Brzi prelazak u narednu fazu treba da obezbjedi bolju osnovu za kasniji uspjeni zavretak prethodne faze. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva, smatra se da njegova praktina primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom, kao metodom za tano utvrivanje informacionih zahtjeva. Za utvrivanje informacionih zahtjeva se preteno primjenjuju odbacivi prototipovi. Primjenjuju se dvije varijante evolutivnog pristupa. Prema prvoj, nakon utvrivanja preciznih informacionih zahtjeva, rezultati konceptualnog i implementacionog projektovanja BP se integriu, a projekti podsistema se usaglaavaju sa shemom integrisane BP. Drugim rijeima, potprojekti se ponovo posmatraju kao cjelina i na njih se primjenjuju, neto izmjenjeni, koraci konceptualnog i implementacionog projektovanja, kao pri primjeni sekvencijalnog modela metodologije ivotnog ciklusa. Ova varijanta evolutivnog pristupa kombinuje mnoge dobre strane sekvencijalnog modela metodologije ivotnog ciklusa i prototipskog pristupa, ali ne rjeava probleme dugog vremenskog intervala od poetka projekta do pojave prvih, operativno primjenljivih rezultata kod korisnika, i potrebe ulaganja finansijskih sredstava odjednom, a ne postupno. Prema drugoj varijanti, potprojekti se realizuju meusobno nezavisno i mogu biti fazno pomjereni u vremenu. Na taj nain se rjeavaju problemi dugog vremenskog intervala od poetka projekta do pojave prvih rezultata i potrebe ulaganja odjednom finansijskih sredstava. Ovakav nezavisan rad, meutim, moe dovesti do nieg stepena integrisanosti IS. Analiza Oblikovanje Izrada Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
Analiza
Oblikovanje
Izrada
Evaluacija
Slika 2.5. Mogui evolutivni model primjene metodologije ivotnog ciklusa.
47
Na slici 2.5 je prikazan mogui evolutivni model primjene metodologije ivotnog ciklusa. Razvoj se vri u inkrementalnim koracima, dovoljno malim da se mogu obavljati prototipski. Svaki od nizova razvojnih aktivnosti (analiza, oblikovanje, izrada, evaluacija) vodi operatibilnom proizvodu koji se isporuuje i koji generie naredne zahtjeve.
2.4.5. Inkrementalni model razvoja informacionog sistema

Kao i u sluaju evolutivnog modela, na poetku primjene inkrementalnog modela, kompletno se sprovodi faza strategije metodologije ivotnog ciklusa. Nakon toga, formiraju se relativno manji potprojekti sa niim stepenom meusobne integracije i utvrde se slijedei 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 meusobno nezavisno i mogu biti fazno pomjereni u vremenu. Inkrementalni model se moe 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 poetku svake faze provodi se procjena rizika. Nastoje se utvditi mogui rizici i razrijeiti ih prije nastavka (uklanjanjem ili svoenjem na najmanju moguu mjeru). U sluaju 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
Spiralni model metodologije ivotnog ciklusa prikazan je na slici 2.7(a). Y osa predstavlja kumulativni troak, a na x osi svaka petlja spirale predstavlja jednu fazu razvoja i to: analizu, oblikovanje, izradu i integraciju. Faza moe biti realizovana redoslijedno, prototipski ili evolutivno, a odluka o nastavku razvoja donosi se prolaskom kroz osu x.
kumulativni troak integracija izrada oblikovanje analiza
Programiranje
Projektovanje
Upravljanje projektom Uvoenje u upotrebu Snimanje i analiza
1. 2. 3. 4.
Analiza rizika, procjena alternativa; Razvoj i verifikacija slijedeeg proizvoda; Planiranje slijedee faze; Pregled odreivanje ciljeva, alternativa i ogranienja.
(a)
(b)
Slika 2.7. Spiralni (a) i zvjezdasti (b) model metodologije ivotnog ciklusa. Zvjezdasti model, slika 2.7(b), ne uvodi stroga ogranienja u redoslijedu primjene faza i koraka metodologije ivotnog ciklusa. To ne znai da prirodnog redoslijeda izvravanja odreenih koraka metodologije u ovom modelu nema, ve da on zavisi od vie faktora, impliciranih konkretnim projektom. Tako, na primjer, reverzno inenjerstvo, ili potreba za reinenjeringom postojeeg 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 moe definisati kao metoda + idejni pristup. Sadri u sebi kolekciju procedura, tehnika, alata i dokumentacionih pomagala, potkrijepljenih filozofijom, koji potpomau izgradnju informacionih sistema [Avison & Fitzgerald, 1995]. Metodologija predstavlja skup naela izrade IS, koji se u odreenoj situaciji svodi na metodu jedinstveno prikladnu toj situaciji [Checkland, 1994].
49
Komponente metodologije se mogu razvrstati u slijedeih pet taaka: 1. 2. 3. 4. 5. Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodi) upotrebe odabranih tehnika i pomagala; Nain upravljanja projektom i nadzorom projekta.
Cilj metodologije je da omogui sistemski postupak razvoja kojim e se moi pratiti napredak, uspostavi komunikaciju izmeu uesnika ukljuenih u izgradnju IS (poslovodstvo, korisnici, analitiari, programeri), osigura skup tehnika koje e omoguiti da se zadaci izvravaju na standardne i provjerene naine, osigura efikasan nadzor sa ciljem uoavanja greaka u ranim fazama. Osim navedenog, cilj metodologije je da omogui elastine promjene poslovanja i tehnologije (npr. odvajanjem analize i oblikovanja), uokviri razvojnu strategiju kojom e se ukloniti ad hoc rjeavanje problema, odredi ili ukae kada i u kojoj mjeri je potrebno ukljuivanje korisnika, te potie i omoguava ukljuivanje korisnika kada se za to ukae potreba. Metodologija omoguava da se dovoljno panje posveti analizi poslovanja, ime e se osigurati izrada sistema koji odgovara poslovanju i zahtjevima korisnika. Jeftinije je otkriti i popraviti greku u ranim fazama, jer je lake popraviti dokumentaciju nego mijenjati programski kd. Izmjene u kasnijim fazama zahtjevaju promjene rezultata prethodnih faza. Lake je pronai greku tokom faze u kojoj je nastala, nego traiti je i popravljati na osnovu posljedinih uinaka primijeenih u kasnijim fazama.
C i j e n a Plan Analiza Oblikovanje Izrada Odravanje
Slika 2.8. Relativno trajanje i cijena otkrivanja greaka u razliitim fazama. Relativno trajanje i cijena otkrivanja greaka u razliitim fazama razvoja IS prikazani su na slici 2.8.
50
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 slijedei pristupi razvoju. Usmjerenost procesima (npr. SA/SD), koji je za korisnika jednostavniji pristup jer omoguava opisivanje specifinih funkcija. Prisutan je problem odreivanja nivoa dekompozicije (nivoa osnovnih procesa). Nedovoljna panja je posveena modelu podataka, ta za posljedicu moe imati neodgovarajui model baze podataka i oteanu integraciju aplikacija uslijed nekompatibilnih podataka. Usmjerenost podacima (npr. IEM) obezbjeuje sloeniji opis strukture podataka, ali jednostavnije tokove podataka. Procesi se definiu analizom podataka (grupiu oko podataka) i bre konvergira kraju, jer je skup objekata (entiteta) modela konaan. Poetak razvoja definisanjem dogaaja (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 (Booch93), Schlaer-Mellor, Unified Modelling Process (Rational).
51
Primjena neke od ovih metodologija ne znai da e IS biti dobar! Zahtjevi korisnika se mogu mijenjati u vremenu. Preporuene aktivnosti ne moraju uvijek biti prikladne, primjenjive ili potrebne. Insistiranje na provoenju propisanih procedura vodi u zanemarivanje stvarnih problema, to za posljedicu moe imati formalno dobro napravljen, ali neuspjean sistem. Veina metodologija je namijenjena analizi i oblikovanju. Rijetke metodologije podravaju sve faze ivotnog ciklusa (npr. IEM). Metodologije treba da su podrane odgovarajuim alatima za upravljanje i projektovanje (CASE), to nije uvijek ispunjeno u praksi. Alternative komercijalnim metodologijama je zdrav razum, najbolje dokazano u praksi, preice do rjeenja problema zasnovane na slinim iskustvima, kao i prilagoavanje 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 postie sistemskom i vremenski saetom primjenom slijedeih tehnika i alata: aktivno i efikasno ukljuivanje korisnika, odgovarajue 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 (priblino 20 sedmica) za podsistem veliine od 25 do 30 relacija (tabela). Cijena postignutog ubrzanja moe biti gubitak pregleda nad cjelinom sistema. Treba paziti da brzina ne postane sebi svrhom, jer tada vodi u improvizaciju (izradu prirunih rjeenja) i prljavi razvoj. Faze brzog razvoja su: 1. JEM (Joint Enterprise Modeling ) zdrueno modeliranje organizacije, odnosno sjednice na kojima poslovodstvo i analitiari trae naine usmjerenja organizacije i naine kako je uiniti kompetentnom. Istrauju se ciljevi organizacije, problemi, kritini inioci uspjeha te strategijske mogunosti; 2. JRP (Joint Requirements Planning) zdrueno planiranje zahtjeva, odnosno analiza zahtjeva za razmatrani poslovni sistem. Prouavaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne funkcije, te istrauju i definiu informacione potrebe;
52
3. JAD (Joint Application Design) zdrueno oblikovanje aplikacija. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. Zahtijeva tijesnu saradnju korisnika, projektanta i menadera; 4. Konstrukcija - iterativna izrada prototipa; 5. Zavretak projekta - provjera rada, izrada dokumentacije, obuka korisnika. Primjer: RAD projekat. Sedmice 1-4 pokretanje projekta, istraivanje, priprema JRP sjednice, obavljanje JRP sjednice, priprema JAD sjednice; Sedmice 5-9 prva JAD sjednica, poetak dizajna, konsolidacija JAD dizajna i prototipa, prototipovi za test uporabljivosti, druga JAD sjednica, zavretak dizajna; Sedmice 10-14 razvoj i testiranje, priprema konverzije, planiranje zavretka; Sedmice 15-20 izrada dokumentacije, priprema obuke, obuka, zavrno testiranje, zavretak projekta.
2.6.2. Informaciono inenjerstvo (Information Engineering (IE))

Informaciono inenjerstvo (IE) se zasniva na analizi poslovnih zahtjeva iz koje se izdvajaju aplikacije IS i prioriteti tih aplikacija. Aplikacije postaju projekti u kojima se provode postupci analize i dizajna da bi se razvili produkcioni sistemi. Za razliku od klasine strukturirane analize, koja se odvija projekat-po-projekat, informaciono inenjerstvo je procesno osjetljiva tehnika usmjerena na podatke i primjenjuje se na organizaciju kao cjelinu ili na neki njen znaajni dio. Osnovno naelo je da se IS moraju graditi kao to se grade drugi unikatni proizvodi, npr. u graevinarstvu ili brodogradnji. Faze informacionog inenjerstva su slijedee: 1. Planiranje strategije IS - Information Strategy Planning (ISP), koje obuhvata posmatranje poslovanja kao cjeline sa ciljem definisanja opteg,
53
sveobuhvatnog plana i arhitekture za redoslijedni razvoj informacionih (pod)sistema. Vri se izdvajanje poslovnih podruja i odreivanje prioriteta. Pod poslovnim podrujem se podrazumjeva skup poslovnih procesa koji se proteu organizacijom, a moraju biti visoko integrisani da bi se ostvarila strategija ili misija; 2. Analiza poslovnih podruja - Business Area Analysis (BAA); 3. Prouavanje poslovnih podruja i definisanje poslovnih zahtjeva za visoko organizirani i integrisani skup informacionih (pod)sistema i aplikacija podrke poslovnog podruja; 4. Definisanje aplikacija, odnosno izdvajanje aplikacija i definisanje njihovih prioriteta na osnovu analize poslovnih podruja. Aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna. Budui da je informacija proizala iz podataka, podaci moraju biti prvi planirani. Modeliranje zapoinje modelima podataka. Nakon toga se rade modeli procesa, slino onima u strukturiranoj analizi. Napomena: O informacionom inenjerstvu bie jo govora u poglavlju 8.
2.6.3. Ekstremno programiranje (eXtreme Programming (XP))

Naela ekstremnog programiranja nastala su prije desetak godina [Kent Beck, 1996]. XP zahtijeva komunikaciju u svim fazama projekta, meu svim njegovim uesnicima. Ovdje se prvenstveno misli na komunikaciju meu lanovima razvojnog tima, zatim na meusobnu komunikaciju lanova tima sa rukovodiocem projekta, te komunikaciju naruioca sa izvoaima (lanovima razvojnog tima i njihovim rukovodiocima). Dijelovi softvera, kao i njegova cjelokupna arhitektura, moraju u svakoj fazi projekta biti jednostavni. Jednostavnost se ostvaruje kontinuiranim prilagoavanjem programskog kda i svoenjem projektne dokumentacije na minimalno prihvatljivi nivo. XP nalae kontinuirane povratne informacija od svih uesnika projekta, to znaajno podie kvalitet rada i ispunjenje rokova. Dobre povratne informacije onemoguavaju nerazumijevanje meu uesnicima projekta, te dre projekt na "pravom putu". U XP hrabrost podrazumijeva sposobnost provoenja tekih 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. Takoe, hrabrost podrazumijeva meusobnu iskrenost svih lanova projektantskog tima.
54
XP uvaava mogunost promjene specifikacija koje definiu funkcionalnost sistema. Prihvati promjenu! je jedan od osnovnih XP postulata. Igra planiranja definie funkcionalnosti slijedee verzije, prije nego to njen razvoj stvarno i pone. U poetku se kreira grubi plan koji se redefinie kroz razgovore sa naruiocima i korisnicima. Korisnici se izraavaju "priama", tako da svaka pria definie jedan dio funkcionalnosti sistema. Priama se dodjeljuju prioriteti i ciljano vrijeme implementacije (1 do 3 sedmice po zahtjevu). XP preporuuje relativno esto izdavanje novih verzija sistema, obino u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sistem zadovoljava funkcionalnost traenu od strane naruioca. esto izdavanje novih verzija pojaava komunikaciju, a time i dotok povratnih informacija i igru planiranja. Metafora sistema je analogna onome to veina drugih metodologija naziva arhitekturom sistema. Metafora mora biti jasno izraena te nedvosmisleno shvatljiva svim lanovima projektantskog tima. XP ne definie format ili tehniku u kojoj metafora mora biti izraena. Najei argument osporavaoca XP-a je u tvrdnji da XP zanemaruje dizajn sistema. U stvati, dizajn arhitekture sistema je kontinuirani proces koji se u malim koracima odvija tokom itavog razvoja. Testiranje se sastoji od testova komponenti i testova prihvatljivosti. Prilagoavanje programskog kda (refactoring) je tehnika kojom se pojednostavljuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) sloenog koda. Programeri rade u parovima, na nain da jedan pie kd, a drugi prati pisanje i revidira kd, pazei da kd bude jasan i razumljiv. Zajedniko vlasnitvo se sastoji u tome da svi inenjeri koji uestvuju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku. XP nalae izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake implementirane funkcionalnosti. Zastupljeno je potovanje 40-satne radne sedmice. Smatra se da umorni projektanti ne mogu postii maksimalnu efikasnost u radu, pa se zabranjuje prekovremeni rad dvije sedmice zaredom. Naruilac ili predstavnik naruioca mora biti prisutan prilikom razvoja sistema kako bi bio dostupan u sluaju potrebe za pojanjenima, te kako bi pomogao u definisanju sistema i pisanju testova. Programeri moraju pisati kd u skladu sa dogovorenim standardima.
2.6.4. Ujedinjeni razvojni proces (Unified software development process (UDP))

Ujedinjeni razvojni proces, izvorno nazvan Objectory, kasnije je dobio ime Rational Unified Process (RUP). Zastupljen je iterativni i inkrementalni razvoj, koji se obavlja na slijedei nain:
55
1. Softver se razvija i objavljuje po dijelovima; 2. Glavne faze razvoja se obavljaju kroz niz iteracija; 3. Faza konstrukcije (izrade) slijedi nakon provoenja prethodnih faza. Svaka iteracija se obavlja standardnim ivotnim ciklusom koji ukljuuje analizu, oblikovanje, ugradnju i provjeru. Rezultat iteracije je proizvod zavrnog kvaliteta, provjeren i integrisan, koji zadovoljava podskup ukupnih zahtjeva. Isporuke mogu biti interne ili prema korisnicima. Mogu se izdvojiti slijedee glavne faze razvoja (slika 2.9). Poetak (Inception), koga sainjavaju opravdanje razloga za pokretanje projekta, prikupljanje najvanijih zahtjeva (10% detaljno) i odreivanje dosega projekta.
Poetak Zahtjevi Analiza
Elaboracija
Gradnja
Prelaz
Oblikovanje Ugradnja
Provjera
iter. #1
iter. #2
Inkrementi
iter. #n-1
iter. #n
Slika 2.9. Dijagram glavnih faza razvoja. Elaboracija (Elaboration), odnosno prikupljanje detaljnih zahtjeva (80%), globalna analiza i dizajn, ustanovljavanje osnovne arhitekture i planiranje konstrukcije. Konstrukcija (Construction), gradnja, se sastoji od prikupljanja ostalih zahtjeva plus promjene zahtjeva, razrade arhitekture i izrade sistema, kao i kontinuirane integracije. Prelaz (Transition) sainjavaju beta testiranje, podeavanje performansi, obuka korisnika, provjera prihvatljivosti i zadovoljstva korisnika.
56
Post-implementacija (Post-deployment) ouvanje integriteta aplikacije.
je
nastavak
evolutivnog
razvoja,
Broj i trajanje iteracija za ujedinjeni razvojni proces, za projekte do 18 mjeseci, je okvirno 3 do 6 iteracija. Uobiajeno, iteracije imaju podjednako trajanje. Trajanje iteracije moe varirati u zavisnosti od faze. U fazi konstrukcije to vrijeme je due. Prva iteracija je najee i najtea. Zahtijeva pripremu okruenja, ekipe i posla. Opasna je zbog mogueg pretjeranog optimizma. Ako se krivo procjeni moe izazvati pomake i neeljene uinke. Smanjenje broja iteracija za posljedicu ima slabije rezultate razvoja.
2.6.5. Izbor pristupa razvoju informacionog sistema

Izbor opte metodologije po kojoj e programski proizvod biti razvijen vri se tokom ustanovljavanja projekta razvoja programskog proizvoda. Ukoliko je izabrana metodologija ivotnog ciklusa, tada najkasnije do zavretka faze strategije, rukovodei tim projekta mora da se opredjeli za odgovarajui model primjene metodologije ivotnog ciklusa i izvri dodatna prilagoavanja izabranog modela potrebama projekta. Ne postoje formalna pravila na osnovu kojih ovaj izbor treba napraviti, ve se moe govoriti samo o preporukama. Dosta preporuka za izbor odgovarajueg modela primjene metodologije ivotnog ciklusa proizilazi iz razmatranja danih u okviru taaka 2.4 i 2.5. Neki od parametara, koji se mogu navesti i koji utiu na izbor modela primjene metodologije, su slijedei: koliko je poslovni sistem sloen sa stanovita funkcija koje se u njemu obavljaju, kakav je stepen ureenosti poslovanja u samom poslovnom sistemu, da li je opta ekonomska i politika situacija u okruenju poslovnog sistema stabilna ili ne, koji se ciljevi projekta smatraju prioritetnim i u kojoj mjeri su ciljevi ambiciozno postavljeni, sa kolikim finansijskim sredstvima za realizaciju projekta se raspolae i kakva je dinamika obezbjeenja tih sredstava. Ovom navoenju parametara moe se dodati: kakve informacione tehnologije stoje na raspolaganju za realizaciju projekta, da li je rukovodei i izvoaki tim projekta iskusan u primjeni odgovarajuih informacionih tehnologija, da li je veina korisnika budueg programskog proizvoda iskusna u upotrebi rjeenja vezanih za informacione tehnologije ili ne, da li su rukovodee strukture iz poslovnog sistema, a dijelom i budui korisnici, zainteresovani i stimulisani za uvoenje novog programskog proizvoda, da li su, u cjelini, oteane ili ne mogunosti za obezbjeivanje komunikacija.
57
3. Uvod u projektovanje i definisanje zahtjeva za informacionim sistemom

3.1. Uvod u projektovanje i izgradnju informacionog sistema
3.1.1. Redoslijed izrade fizikog i logikog modela
Fiziki i logiki model postojeeg IS, a zatim logiki i fiziki model budueg IS, izrauje se na osnovu poslovnih zahtjeva i zahtjeva krajnjih korisnika. Fiziki model (ugradni, implementacioni, tehniki) opisuje kako je sistem fiziki i tehniki izgraen, te ko, gdje i kada neto radi. Logiki model (esencijalni, konceptualni, poslovni) opisuje ta je sistem, ta radi, ta su podaci (slika 3.1). Operativni (budui fiziki) sistem prikazuje ta, ko i kada, ali ne i gdje radi, a prema potrebi moe se razmatrati organizacijski nivo, odnosno razliito znaenje podataka zavisno od podruja unutar poslovnog sistema i okruenja.
Postojei fiziki IS Postojei logiki IS Budui logiki IS Budui fiziki IS
Korisniki/poslovni zahtjev
Budui organizacijski IS
Slika 3.1. Prikaz redoslijeda izrade fizikog i logikog modela IS.
3.1.2. Modeliranje informacionog sistema

Potrebna je izrada modela koji odgovaraju dijelovima poslovnog sistema. Model je apstrakcija ili reprezentacija dijela stvarnog svijeta. Ukoliko od ranije ne postoji IS, potrebno je odrediti "surogat" postojeeg sistema po ugledu na istovjetne sisteme u
58
drugim poslovnim sistemima ili razvoj zapoeti sa izradom logikog modela. Tehnika oblikovanja dijagramima odvija se na slijedei nain. Izradom modela nastoji se opisati situacija u kojoj dogaaj iz vanjskog svijeta pokree (okida) process. Proces ima odreeni uinak na podatke u nekom stanju. Obavljanjem procesa podaci prelaze u novo stanje (slika 3.2).
Dogaaj Staro stanje podataka
Sinhronizacija (koncept okidaa)
Proces (naredbe i pravila)
uinak
Struktura podataka
Novo stanje podataka
Slika 3.2. Dijagram modeliranja IS [Fertalj & Kalpi, 2005].
3.1.3. Vrste modela informacionog sistema

Model podataka opisuje TA su podaci, odnosno TA opisuju podaci. Konceptualni model opisuje podatke i veze izmeu podataka. Najei konceptualni model je model entiteti-veze. Logiki model opisuje strukturu podataka i logikih datoteka, a najei logiki model je relacioni model podataka. Model funkcija i procesa opisuje KAKO se prikupljaju, obrauju i distribuiraju podaci. Model funkcija se oblikuje razlaganjem (dekompozicijom) funkcija, iterativno od vrha prema dolje (od globalnih funkcija do osnovnih procesa). Model procesa opisuje obradu podataka posmatranog sistema. Najei model procesa je dijagram toka podataka. Model dogaaja opisuje KADA se podaci obrauju, odnosno razmatra uinke koje dogaaji imaju na procese i podatke, te vri opis stanja. Kao primjer se moe navesti dijagram promjene stanja. Model resursa/sredstava opisuje izvrioce, odnosno KO obrauje podatke, GDJE se podaci nalaze i GDJE se podaci obrauju. Modeliranje programa podrazumjeva predstavljanje struktura (programskih) modula IS, npr. strukturnim kartama.
59
3.1.4. Kljune aktivnosti i uesnici

Kljune aktivnosti, u nekim metodama, zajedno se zovu informaciono inenjerstvo. Kao kljune aktivnosti mogu se uoiti sistemska analiza i sistemski dizajn. Sistemska analiza (analiza sistema) prouava poslovanje sa ciljem da d preporuke za poboljanja sistema i specifikacije zahtjeva za rjeavanje. Sistemski dizajn (dizajn sistema) omoguava specifikaciju ili konstrukciju raunarom podranog rjeenja identifikovanih poslovnih zahtjeva. Uesnici (nosioci uloga) u navedenim aktivnostima su: Korisnik (korisnik usluga, klijent, osoba ili grupa za koju se gradi IS), ta podrazumjeva korisnika sistema i vlasnika sistema. Korisnik sistema (krajnji korisnik) neposredno koristi IS pri obavljanju svakodnevnih poslova ili koristi informaciju dobijenu iz IS. Vlasnik sistema (naruilac, stvarni vlasnik ili predstavnik uprave) naruuje i plaa razvoj i odravanje sistema, postavlja prioritete i odreuje politiku njegovog koritenja; Projektant (dizajner sistema) je tehniki strunjak koji oblikuje sistem tako da zadovolji zahtjeve korisnika, prevodi poslovne zahtjeve i ogranienja u tehniko rjeenje, oblikuje datoteke, baze podataka, ulaze, izlaze, ekranske forme, mreu i programe, integrie rjeenje, a moe biti i graditelj sistema; Graditelj sistema (programer, projektant, strunjak koji izgrauje sistem) provjerava njegovu ispravnost te ga isporuuje u primjenu, konstruie komponente sistema na osnovu specifikacija koje rade dizajneri sistema. Sistem analitiari razumiju i poslovanje i raunarsku obradu podataka. Njihov zadatak je da provode sistemsku analizu i dizajn. Povezuju one koji trebaju raunar i one koji poznaju informacione tehnologije (IT). Formalna definicija [Whitten et. al, 2000] sistem analitiara glasi: Sistem analitiar pomae prouavanju problema i potreba poslovanja radi odreivanja kako poslovni sistem i informaciona tehnologija mogu najbolje rijeiti problem i postii unaprijeenje poslovanja. Plodovi ove aktivnosti su poboljani poslovni procesi, poboljani informacioni sistemi te nove ili poboljane aplikacije, a esto sve zajedno. Sistem analitiar je istraiva, arhitekta i kontrolor, rjeavalac poslovnih problema, zagovornik promjena, psiholog, trgovac, politiar. Veina sistem analitiara koristi specifinost pristupa, koja se naziva ivotni ciklus razvoja sistema, odnosno sistematian i metodian pristup rjeavanju problema sistema.
60
3.2. Definisanje zahtjeva za informacionim sistemom

3.2.1. Kljune aktivnosti
Kljune aktivnosti, koje se mogu izdvojiti u definisanju zahtjeva za informacionim sistemom, su prikupljanje informacija, prikupljanje podataka i ustanovljavanje injenica, to e u narednom tekstu biti detaljnije opisano.
3.2.2. Prikupljanje informacija

Jedna od aktivnosti kod definisanja zahtjeva za IS su intervjui sa kljunim korisnicima i radne sjednice. Ako naruilac zapoljava informatiare svakako ih treba ukljuiti u analizu. Sueljavanje korisnika i informatiara ubrzava rjeavanje proturjenih iskaza. Kao zamjena za intervjue koriste se upitnici i ankete, koji su pogodni i za prikupljanje informacija o resursima. Analiza dokumentacije podrazumjeva prikupljanje cjelokupne dokumentacije znaajne za poslovanje, radi boljeg utvrivanja pravila, poslovne politike, ciljeva poslovanja i strukture informacija. Nuna je ocjena postojeih aplikacija i/ili raunarom podranih podataka, radi analize podataka, ali i zbog njihove konverzije u novi sistem. Posmatranje, odnosno neposredni uvid u poslovne procese posmatranjem radnih sredina (nain izrade i razmjene dokumenata, procesi osnovne djelatnosti), je znaajan vid definisanja zahtjeva za IS. Postupak analize mora biti prilagoen korisniku. Evidentiranje rezultata analize poeljno je obaviti CASE alatima.
3.2.3. Postupak intervjuisanja

Intervju mora biti neusiljen i elastian razgovor sa ispitanikom u obliku niza pitanja i odgovora. Ispitanik se pojavljuje u ulozi pasivnog sagovornika (!?). Sagovornici su rukovodioci, krajnji korisnici i ostali uesnici iz poslovnog sistema. Standardno ukljuuje dva sagovornika, ali moe i vie, i to korisnika i ispitivaa. Individualni intervju je kada uestvuje jedan korisnik, ili uesnici koji rade isti posao, dok je intervjuisanje grupe kada se razgovara sa vie korisnika iz razliitih podruja. Informacije se prikupljaju nizom pojedinanih razgovora. (Prve) razgovore treba voditi prema unaprijed dogovorenom planu i rasporedu, ta treba da obezbjedi koordinator intervjua. Postupak intervjua je spor i neefikasan, jer se organizacija razgovora mora obaviti za svaki pojedini razgovor. Nakon zavretka analize i sinteze dobijenih informacija, neke razgovore (ponekad i itavu seriju) treba ponoviti da bi se
61
upotpunile dobijene informacije ili uskladili proturjeni iskazi. Ukupan broj razgovora ne moe se unaprijed tano odrediti i treba ga prilagoditi stvarnoj situaciji.
3.2.4. Tehnika intervjuisanja

Priprema za razgovor treba da sadri utvrivanje informacija koje treba saznati, prouavanje postojee dokumentacije i prethodnih nalaza, odreivanje dokumentacije koju treba prikupiti i priprema pitanja koja e biti postavljena tokom razgovora. Priprema pitanja podrazumjeva izradu jezgra tema, to jest standardnih pitanja, i izradu sveobuhvatnog potsjetnika i izdvajanje prikladnih pitanja. Mogui plan i obavljanje razgovora moe da se odvija na slijedei nain: 1. Trajanje prvog razgovora je 2 sata (okvirno 1,5 do 2,5 sata); 2. Poetak razgovora, koji sadri predstavljanje uesnika i upoznavanje sa svrhom razgovora (prikupljanje informacija o ); 3. Voenje razgovora, odnosno postavljanje pitanja i zapisivanje odgovora, prikupljanje dokumentacije, ... ; 4. Zavretak razgovora je priblino 5 do10 minuta prije isteka planiranog vremena. Prekida se redoslijed postavljanja pitanja, provjerava se da li postoji neto to je sagovornik htjeo rei a nije bilo pitano, provjerava se da li treba proiriti krug sagovornika, dogovara se nastavak razgovora (dopunski razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra da je razgovor nametnuo nova pitanja; 5. Zahvala na razgovoru. Preispitivanje i pojanjenje sadraja se sastoji od provjera zapisanih navoda radi upotpunjavanja biljeki: telefonom, elektronskom potom ili novim sastankom. Dokumentovanje razgovora sainjavaju: Samostalno pisanje zapisnika (Ko ne razumije, ne moe zapisivati.). Kada u razgovoru sudjeluje vie analitiara, odreuje se voditelj razgovora koji je ujedno i zapisniar, a ostali ulau primjedbe; Zapisnik treba da sadri: naziv projekta, vrijeme i mjesto odravanja razgovora, spisak uesnika, sadraj razgovora (tekst zapisnika), popis prikupljene dokumentacije i ime zapisniara; Zapisnik mora sadravati ono to je reeno i slijediti tok razgovora; Zapisnik ne smije nametati zakljuke, jer su oni rezultat analize.
62
Autorizacija (ovjera) zapisnika se vri tako da se zapisnik dostavlja na uvid sagovorniku, koji potvruje vjerodostojnost zapisnika. Po potrebi sagovornik moe nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su pogreno protumaeni.
3.2.5. Preporuke za voenje intervjua

Tokom provoenja intervjua treba pitati o svemu to se smatra vanim. Nita nije samo po sebi razumljivo i svima jasno. Ne pretpostavljati da se unaprijed zna o emu se radi. Repertoar i vrste pitanja moe biti slijedei: 1. Pitanja zatvorenog tipa: Koliko ... obraujete (u nekom razdoblju)?, Na koji nain obraujete ... ?; 2. Pitanja otvorenog tipa: to mislite o ... ?, Koji su najvei problemi ... ?; 3. Probna pitanja: Zato?, Moete li navesti primjer za takvu situaciju?, Molim detaljnije objanjenje za ... . Analizom odgovora se razdvajaju injenice od miljenja, utvruje se da li pojedine injenice odgovaraju drugima, analiziraju injenice koje se ne poklapaju i vri provjera odgovora razliitih sagovornika na isto pitanje. Preporuuje se slijedee ponaanje: iskrenost i nepristranost (cilj je nai za korisnika najprikladnije rjeenje, a ne naturati odreeno programsko rjeenje ili raunarsku platformu), panja i jezgrovitost tj. brzo misli, jasno govori, izbjegavanje sugestivnih pitanja, nenametanje zakljuaka i leernost (plus praenje reakcija sagovornika). Grupno intervjuiranje je potrebno izbjegavati i po potrebi nadoknaditi radnim sjednicama. Ovu vrstu intervjuisanja iznimno provesti kada se eli utvrditi zajedniki interes ili protivrjenost.
3.2.6. Upitnici i ankete

Upitnik je, u sutini, pismeni intervju. Sadri pitanja koja se postavljaju tokom razgovora (okvirno 20 pitanja). Moe se dostaviti korisniku prije ili nakon intervjua. Nedostaci upitnika su slijedei: ispitanik moe prilagoditi (kontrolisati) svoje odgovore, teko je procijeniti iskrenost (spontanost) odgovora, a moe i obeshrabriti ispitanika. Anketa moe da obuhvatiti vie ispitanika. Pitanja su zatvorenog tipa, a odgovori i obrada odgovora mogu se standardizovati. Pogodna je za popis resursa.
63
Na osnovu navedenog, moe se zakljuiti da Pomou intervjua se moe vie nauiti o stavovima, Tokom intervjua analitiar i ispitanik se nalaze jedan moe posmatrati nain na koji ispitanik odgovara i pitanja.
je intervjuisanje najelastinije! osjeajima i motivaciji osoblja. nasuprot drugom, pa analitiar po potrebi proiriti ili usmjeriti
3.2.7. Prouavanje dokumenata

Prikupljaju se svi dokumenti do kojih se moe doi. U prvom redu treba prikupiti dokumente koji su nastali kao rezultat analize procesa, tipine dokumente (pravilnici, zakoni, obrasci, izvjetaji) i dokumente nastale analizom podataka. Poeljno je da dokumenti budu reprezentativni, tj. popunjeni na tipian nain (tako se moe ustanoviti koje informacije se unose i na koji nain). Reprezentativni dokumenti najee ne ukazuju na izuzetke, to jest podatke koji se rjee biljee, ali ipak trebaju. Stalno biljeenje nekih podataka ne mora znaiti da su ti podaci stvarno potrebni. Treba prikupiti vie uzoraka iste vrste dokumenta! Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska. Praksa moe odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zato i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni, te ta treba promijeniti da bi se popravili (sadraj, lakoa popunjavanja i itanja). Nuno je modele (podataka), razmatrane analizom, provjeriti kod korisnika.
3.2.8. Evidencija i analiza postojeih aplikacija

Budui da su nedostaci opreme, podrke i podataka najei razlozi za izgradnju novog IS, potrebno ih je evidentirati i analizirati. Vri se procjena aplikacija i (baza) podataka u primjeni, i to: koriteni programski jezici i alati, ukljuujui programe za kancelarijsko poslovanje (npr. Excel), podrane funkcije i nain posluivanja programa, meusobna povezanost razliitih aplikacija i podataka, postojee platforme (raunari, operativni sistem, mrea, SUBP), kao i sastav i stepen informatike obuenosti korisnika. Analiziraju se nedostaci sistemske opreme i programske podrke. U prvom redu se analizira nepovezanost aplikacija (tzv. informatika ostrva), loa programska rjeenja (funkcionalnost, ergonomija), nepouzdanost, integritet, zatita i sigurnost podataka. Takoe se analizira nepostojanje programske dokumentacije, tehnoloka zastarjelost (programski jezici i alati, nemogunost rada u viekorisnikom okruenju, grafiki interfejs).
64
Nedostaci modela podataka mogu biti razliiti. Najei nedostaci su razliitost modela podataka postojeih aplikacija i nedostaci unutar pojedinih modela. Razliitost modela podataka postojeih aplikacija se oituje u tome da entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojeim modelima, isti entitet iz stvarnog svijeta pojavljuje se pod razliitim nazivima, isti entitet iz stvarnog svijeta opisan je razliitim atributima, dva ili vie entiteta iz stvarnog svijeta su prikazani razliitim brojem entiteta u modelu podataka. Nedostaci unutar pojedinih modela su, najee, nedefinisanost identifikatora (primarnih kljueva), nedefinisanost veza meu podacima, najee kao posljedica nepostojanja primarnih kljueva, nedefinisanost veza i pored postojanja primarnih i drugih (stranih) kljueva. Navedene pojave su posljedica razvoja tokom upotrebe i nedoslijednosti tog razvoja, naglaenog ponavljanje uvedenog prilikom izrade zahtjevnih ili sloenih programskih rjeenja, kao i ukupne nenormalizovanosti modela.
3.2.9. Posmatranje poslovnog sistema

Definisanje zahtjeva za IS se moe dopuniti uvidom u poslovne procese, odnosno posmatranjem radnih sredina. Posmatra se lokacija i kretanje ljudi, tok izvravanja poslova, fiziki ulazi i izlazi sistema, zaprimanje, izrada i razmjena dokumenata, procesi osnovne djelatnosti, npr. proizvodnje. Prednost ovakvog pristupa je u tome to je analitiar u stanju da realno sagleda poslovni proces. Ovaj pristup je efikasan, ako se dobro provede, i obezbjeuje pouzdanost prikupljenih informacija. Nedostaci posmatranja poslovnog sistema su neefikasnost, ako se dobro ne provede, znatan utroak vremena, ometanje i nelagodnost posmatranih osoba, mogunost manipulacije posmatraa, npr. prikrivanjem uobiajenog krenja radnih procedura. Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani i netani. Posmatranje na licu mjesta je najtea metoda za utvrivanje injenica.
3.2.10. Radni sastanci

Radni sastanci (sjednice) se organizuju da analitiari i korisnici zajedniki provode analizu i oblikovanje. Cilj sjednice je (zajedniko) pronalaenje najboljeg rjeenja. Za to je potreban poseban prostor i izolacija, moderator, dnevni red i zapisnici (slika 3.3). Genijalnost grupe se koristi za prikupljanje ideja i definisanje informacionih potreba, pri emu se korisnici potiu na aktivno i kreativno sudjelovanje. Izvodi se tako da se od svakog ispitanika iz grupe trai da definie svoj pogled na idealno rjeenje. Svaki uesnik iznosi sve to mu pada na pamet u vezi sa problemom koji se rjeava. Od predloenih rjeenja odabira se najbolje prema realnoj izvodljivosti. Postupak je
65
koristan tamo gdje postoje korisnici koji dobro poznaju sistem, ali teko prihvataju nove ideje.
Slika 3.3. Prostor za radne sjednice [A.Dennis & B. Haley Wixom, Systems Analysis and Design, John Wiley & Sons, 2000]. Prednosti radnih sjednica su njihova pogodnost za projekte kojima se rjeavaju problemi vani za cijeli poslovni sistem ili vei dio poslovanja. Njihovim organizovanjem se izbjegavaju specifini (egzotini) i nejasni zahtjevi, preciznije se ustanovljava doseg projekta i bolje uoava protivrjenost zahtjeva. Nedostaci radnih sjednica su pasivnost uesnika, usitnjavanje razgovora i esto udaljavanje od tema. Sjednice treba da traju vie dana (5 do 10) u nekoliko sedmica. Ovom zahtjevu u praksi je vrlo teko udovoljiti zbog obaveza uesnika. Otpor sjednici je srazmjeran nivou poloaja konkretnog uesnika. Otpor je naroito naglaen kada poslovni sistem zapoljava informatiare, jer se podrazumijeva da je informatizacija iskljuivo njihov posao.
3.2.11. Razvoj prototipa

Razvoj prototipa se koristi kada korisnik ne moe tano da definie svoje informacione potrebe prije nego to se izgradi informacioni sistem. Razlog tome moe biti nedostatak postojeeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak
66
teka vizuelizacija budueg sistema. Da bi se olakala vizuelizacija budueg sistema izgrauje se sistem koji zadovoljava neke osnovne, inicijalne potrebe. U radu sa takvim sistemom korisnik otkriva svoje informacione potrebe, te se sistem modifikuje kako bi se zadovoljile te potrebe. Postupak koritenje sistema i modifikovanje istog iterativno se ponavlja, a informacione potrebe korisnika otkrivaju koritenjem sistema. Izrada prototipa pogodna je u onim okruenjima gdje je teko definisati konkretni model sistema, te u okruenjima gdje se informacione potrebe korisnika mjenjaju ili razvijaju (prototipski model razvoja IS je obraen u podtaki 2.4.3).
3.2.12. Najei problemi pri prikupljanju informacija

Ponaanja korisnika esto moe da uzrokuje niz problema pri definisanju zahtjeva za IS. Informatikim argonom su opisana ponaanja koja se mogu oekivati od korisnika. 1. Taktika kuhinjskog sudopera: korisnik navodi (preko)brojne potrebe, gomilu nepotrebnih izvjetaja, ekranskih formi, sortiranja, izraunavanja i sl. Ovakav pristup obino je uzrokovan pomanjkanjem iskustva korisnika, koji ne zna ta bi mu stvarno moglo zatrebati ili nije u stanju izdvojiti ono ta je bitno; 2. Taktika dimne zavjese: korisnik trai vie mogunosti, a zapravo mu je potrebna samo jedna ili dvije. Dodatni zahtjevi slue za postizanje bolje nagodbe sa analitiarom. Ova taktika obino oslikava korisnika sa dobrim poznavanjem onoga ta eli, a zahtjeve treba reducirati na one realne i izvodljive; 3. Taktika "Treba mi isto, ali u boljem obliku": korisniku koji koristi ovu taktiku nedostaje volja ili znanje, a ponekad oboje. anse za uspjeno definisanje problema su male, jer samo korisnik moe izraziti svoje potrebe i probleme. Korisnik je sklon preutjeti izuzetke, koji su bitni (nuni!) za uspjenu realizaciju, a obino izuzeci zahtijevaju i najvie napora tokom ugradnje: "To je naa jedina procedura (osim kada )". Ne izjednaavati tako se uvijek radi sa tako treba raditi!
67
4. Analiza sistema
4.1. Uvod u analizu sistema
Analiza sistema (sistemska analiza) je ralanjivanje sistema na njegove komponente da bi se prouilo kako te komponente rade i meusobno komuniciraju. Analiza sistema se provodi sa namjerom slijedee sinteze sistema i razvoja aplikacija. Sinteza sistema je ponovno objedinjavanje komponenti u cjeloviti, poeljno poboljani, sistem. Bie navedene mogue definicije analize sistema. Analiza sistema je: (1) razmatranje i planiranje sistema i projekta, (2) prouavanje i analiza postojeeg poslovnog i informacionog sistema, te (3) definisanje poslovnih zahtjeva i prioriteta novog ili poboljanog postojeeg sistema [Whitten et. al, 2000]. Svrha, cilj i dubina analize sistema mogu se predstaviti slijedeim aktivnostima: Automatizacijom poslovnih procesa (Business Process Automation (BPA)), odnosno poveanjem efikasnosti korisnika analizom problema i uklanjanjem uzroka; Poboljanjem poslovnih procesa (Business Process Improvement (BPI)), tj. poveanjem efikasnosti i djelotvornosti, analizom trajanja i kotanja poslovnih procesa, te predlaganjem poboljanja (udruivanje procesa, paralelizam izvedbe); Reinenjeringom poslovnih procesa (Business Process Reengineering (BPR)) ili preoblikovanjem poslovnih procesa (Business Process Redesign (BPR)), ta predstavlja radikalni redizajn poslovnih procesa analizom moguih posljedica, procjenom alternativnih tehnologija, ukidanjem ili zamjenom pojedinih aktivnosti, analizom trokova - koristi i analizom rizika.
4.2. Aktivnosti analize

4.2.1. Uvod u aktivnosti analize
Aktivnosti analize se mogu sistematizovati u tri nivoa, gdje svaki nivo trai odgovor na odgovarajua pitanja.
68
1. Detaljna analiza postojeeg sistema, te utvrivanje potreba i zahtjeva: Kako radi postojei sistem?, Na koji nain korisnici koriste sistem da bi obavili svoj posao?, Koji su problemi pri koritenju aplikacija? 2. Detaljna specifikacija zahtjeva za IS: Koji su podaci potrebni?, Ko ih treba?, Kada?, Od koga?, Ko ih stvara?, Koji su izlazni podaci?, Kakav im je oblik?, Koji su izvori izlaznih podataka?, Na koji nain se podaci prikupljaju i objedinjuju? 3. Daljnja razrada granica projekta. Primjeri: ProtokDokumenata, RazmjenaPodataka. Pozadinska analiza treba da pomogne razumjevanju strukture organizacije, ko u njoj radi, ko je kome potinjen, kako sarauju razliiti odjeli, itd. Za potrebe pozadinske analize moe se izraditi shema organizacione strukture iz koje e biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Za ostale elemente, takoe, se rade odgovarajui modeli (modeliranje procesa, modeliranje podataka).
4.2.2. Postupci i tehnike analize

Moderna strukturirana analiza je procesno usmjerena tehnika modeliranja poslovnih zahtjeva za sistem. Informaciono inenjerstvo je procesno osjetljiva tehnika, usmjerena podacima i prouavanju poslovnog sistema ili njegovih veih dijelova kao cjeline, a ne projekat po projekat. Brzi razvoj aplikacija (Rapid Application Development (RAD)) je razvoj djelominih verzija aplikacija, koje mogu evoluirati do konanog rjeenja. Zdrueni razvoj aplikacija (Joint Application Development (JAD)) je analiza zasnovana na intenzivnim radnim sjednicama na kojima vlasnici, korisnici, analitiari, dizajneri i projektanti zajedniki definiu i oblikuju sistem. Objektno usmjerena analiza omoguava: modeliranje uaurivanjem podataka i procesa u objekte, prouavanje postojeih objekata da bi se vidjelo mogu li se ponovno iskoristiti ili prilagoditi za nove primjene, kao i definisanje novih ili modifikovanih objekata koji e skupa sa postojeim objektima graditi novu aplikaciju. Navedeni postupci se mogu komplementarno primjenjivati i pored uvrijeenog miljenja da je rije o meusobno iskljuivim metodama!
69
4.2.3. Strukturirana analiza

Moderna strukturirana analiza i Logiki dizajn su esti sinonimi koji su u upotrebi. Strukturirana analiza omoguava provoenje strukturiranog procesa i dobijanje rezultatata analize. Sainjavaju je: Tehnika modeliranja poslovnih zahtjeva za sistem, koja je usmjerena procesima, ali se razvila tako da obuhvata i podatke. Omoguava strukturiranje procesa, ulaza, izlaza i skladita podataka potrebnih da bi se odgovorilo na poslovne dogaaje; Logiki modeli kojima se prikazuje TA je sistem i TA mora raditi (a ne KAKO radi). Koriste se dijagrami toka podataka za logiki prikaz poslovnih zahtjeva, nezavisno od tehnikih rjeenja, ta predstavlja logiki dizajn. Ti modeli izraavaju sutinu sistema (sinonimi: esencijalni, konceptualni ili poslovni modeli); Ukljuivanje odreivanja prioriteta zahtjeva. Analiza sa ciljem automatizacije poslovnih procesa omoguava razumijevanje postojeeg sistema, ekstenzivno prikupljanje informacija i zahtjeva, kao i oblikovanje procesa i podataka. Osim toga, omoguava uoavanje moguih poboljanja (ako nije uinjeno ranije), analizu problema, odnosno identifikovanje problema, ustanovljavanje eljenih poboljanja, kao i analizu i traenje uzroka problema i prioritete njihovog rjeavanja. Razvoj koncepata budueg sistema obuhvata prikupljanje dodatnih informacija, reviziju i doradu modela.
4.3. Definisanje zahtjeva koje sistem mora posjedovati

4.3.1. Uvod u definisanje zahtjeva
IEEE (Institute of Electrical and Electronics Engineers) standard definie zahtjeve koje mora posjedovati sistem kao: (1) uslov ili sposobnost koje korisnik treba da ima da bi rijeio problem ili ostvario cilj, (2) uslov ili sposobnost koju mora posjedovati sistem ili komponenta sistema da bi zadovoljila ugovor, standard, specifikacije ili neki drugi ugovoreni document, (3) dokumentovanu reprezentaciju uslova ili mogunosti definisanih pod (1) ili (2); [IEEE Std 830-1998, IEEE Std 610.12-1990]. Zahtjevi ne sadre detalje dizajna, detalje implementacije ili informacije vezane uz planiranje projekta. Panja se usmjerava na ono TA se eli izgraditi, a ne ulazi se u detalje kako i kada to napraviti.
70
Za 40 do 60% greaka u projektu uzrok lei u grekama napravljenim u fazi postavljanja zahtjeva. Tipina posljedica su "prazna oekivanja", razlika izmeu onog to oekuje naruilac i onoga ta je izvrilac mislio da treba napraviti. Naknadne prepravke mogu predstavljati do 40% trokova razvoja, od ega je 70 do 85% pripisivo pogrenim zahtjevima. Nepotpuno definisani zahtjevi ine nemoguim planiranje projekta i praenje promjena [Leffingwell, 1997].
4.3.2. Vrste zahtjeva

Zahtjevi mogu biti: poslovni zahtjevi (zato), korisniki zahtjevi (zahtjevi krajnjih korisnika), funkcionalni zahtjevi (ta) ili nefunkcionalni zahtjevi (kako ili kako dobro). Poslovni zahtjevi definiu ciljeve organizacije (korisniki zahtjevi na viem nivou), odnosno daju opis problema koje treba rijeiti (npr. poslovna potreba "Poboljanje usluge postojeim klijentima i pridobijanje novih") ili sadrani u dokumentima u kojima se opisuje vizija i opseg projekta (npr. poslovni zahtjev "Omoguiti Internet prodaju"). Korisniki zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik mora moi obaviti sluei se aplikacijama ili koji su sadrani u opisima sluajeva koritenja, tj. opisima scenarija rada. Funkcionalni zahtjevi (ta) definiu softversku funkcionalnost (oekivano ponaanje i operacije koje sistem moe izvoditi), koju treba ugraditi u proizvod da bi omoguio korisnicima obavljanje njihovih zadataka. U ovu grupu zahtjeva spadaju posebno zanimljive mogunosti programa, odnosno skup logiki povezanih funkcionalnih zahtjeva koje korisniku omoguavaju ispunjavanje poslovnih zahtjeva. Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi, pravila i ugovori koje proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtjevi za performansama, ogranienja za dizajn i implementaciju, te osobine kvaliteta koje preciziraju opis proizvoda navodei karakteristike proizvoda u razliitim dimenzijama, a bitne su ili korisniku ili projektantu. Potrebno je jo naglasiti da je potrebno odrediti prioritetete pojedinih zahtjeva. Primjer 1: Zahtjevi vlasnika sistema za studentsku subvencioniranu prehranu [Fertalj & Kalpi, 2005]. Oekivana novana uteda: Sistem mora biti tako koncipiran da prava na subvencioniranu prehranu moe koristiti samo student koji ih je stekao i da ih moe koristiti samo u svrhu prehrane. Sistem mora onemoguiti: koritenje subvencije od strane osoba koje nemaju na to pravo, zaradu ilegalnih posrednika, koritenje subvencije za druge svrhe osim prehrane, naplatu usluga koje nisu pruene.
71
U idealnom sluaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima! Primjer 2: Zahtjevi krajnjih korisnika. Prehrana kod bilo kojeg izvrioca usluga: Novi sistem mora omoguiti da student ostvaruje svoje pravo kod bilo kojeg izvrioca usluge subvencionirane prehrane. Dosadanja praksa je bila da svaki izvrilac usluga izdaje svoje bonove koji se mogu koristiti samo u odreenim restoranima. Ukinuti plaanje unaprijed: Treba izbjei bilo kakvo plaanje od strane studenata za potrebe ostvarivanja prava, a naroito unaprijed. Ukloniti nepotrebne postupke za ostvarivanje prava: Sistem mora biti tako koncipiran da kad se studentu jednom zavedu prava na matinoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod izvrioca usluga. Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemoguiti zloupotrebu steenih prava. Lake ostvarivanje ostalih prava iz studentskog standarda, npr. javni prijevoz po povlatenoj cijeni, pozorita, kina, smjetaj u studentskim domovima, student - servis, itd. Primjer 3: Nepotpuni zahtjev. Zahtjev "Softverski proizvod e ispisati statusnu poruku u redovnim intervalima, ne manjim od 60 sekundi" namee slijedea pitanja: ta je statusna poruka i pod kojim uslovima e biti ispisana?, Koliko dugo ostaje vidljiva?, Koji dio proizvoda e ispisati poruku?, Koliko doslijedni intervali moraju biti? Zahtjev definisan preciznije i detaljnije: Modul za nadzor e ispisivati statusnu poruku u za to odreeni dio interfejsa. Poruka e se aurirati svakih 60 s (10 s) nakon to zapone izvoenje pozadinskog zadatka i bie vidljiva cijelo vrijeme. Ukoliko se pozadinski zadatak izvodi normalno, modul za nadzor e ispisivati postotak obavljenog posla. Modul za nadzor e ispisati "Zadatak obavljen" nakon to se zadatak obavi. Modul e ispisati poruku o greci ukoliko doe do zastoja u izvoenju. Problem je rastavljen u vie zahtjeva budui da e svaki zahtijevati posebno testiranje. Ukoliko je vie zahtjeva grupisano u jedan lake je previdjeti neki od njih tokom izrade ili testiranja. Primjeuje se da u zahtjevu nije detaljno opisano kako i gdje e se poruka ispisivati. To e biti odlueno tokom dizajna. Primjer 4: Neostvariv zahtjev. Zahtjev "Softverski proizvod e se trenutno prebaciti izmeu ispisivanja i skrivanja oznaka koji se ne mogu tampati" je neostvariv zahtjev iz slijedeih razloga: Raunari nita ne mogu napraviti trenutno! Da li programska podrka sama odluuje 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 oznaeni tekst, cijeli dokument ili neto
72
tree?. Uoava se i nejednoznanost: da li su "oznake koje se ne mogu tampati" skrivene oznake, posebne oznake ili kontrolne oznake? Bolji zahtjev glasi: "Korisnik e posebno dogovorenom akcijom, 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, te da korisnik mora moi da obavi nekakvu akciju, ali nije tono navedeno kakvu (npr. kombinacija tipki), ta se preputa dizajnerima. Primjer 5: Neodreeni zahtjev. U zahtjevu "Parser e brzo generisati izvjetaj o grekama HTML oznaka, koji omoguava brzu ispravku greaka kada program koriste poetnici u HTML-u" uoavaju se slijedee neodreenosti: rije "brzo" je neodreena, nije definisano ta predstavlja izvjetaj i to ini zahtjev nekompletnim. Postavljaju se i slijedea pitanja: Kako se ovjerava zahtjev?, Kako pronai nekoga ko se smatra poetnikom u HTML-u i zatim vidjeti kako brzo e, uz pomo izvjetaja, ispraviti greke?, Kada se generie izvjetaj? Bolje rjeenje glasi: Nakon to je HTML analizator obradio datoteku, generisae izvjetaj koji sadri broj linije i tekst pronaenih HTML greaka, te opis svake greke. Ukoliko nema greaka prilikom analize, nee se generisati izvjetaj.
4.3.3. Odreivanje zahtjeva

Poslovni zahtjevi: Sve to opisuje finansijski, trgovaki ili drugi poslovni prodor koji korisnici, ili organizacija koja razvija sistem, mogu dobiti je, najvjerovatnije, poslovni zahtjev. Sluajevi koritenja ili scenariji: Opte izjave o korisnikim ciljevima ili poslovnim zadacima, koje korisnici moraju obavljati, najvjerojatnije su sluajevi koritenja, dok specifini opisi zadataka predstavljaju korisnike scenarije. Specifine zadatke treba generalisati u opte sluajeve koritenja. Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod odreenim uslovima, on moda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Ona nisu funkcionalni zahtjevi. Funkcionalni zahtjevi: Izjava koja poinje sa Korisnik mora moi da obavi neku funkciju, ili Sistem treba moi da demonstrira odreeno ponaanje je najvjerovatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponaanje sistema i definiu ta e sistem raditi. Treba svima biti jasno zato sistem mora biti u stanju da obavlja
73
odreene funkcije. Predloeni funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neefikasne poslovne procese koji ne trebaju biti ukljueni u novi sistem. Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poeljne karakteristike sistema: brzinu, jednostavnost, intuitivnost, robustnost, pouzdanost, sigurnost i efikasnost treba razmotriti sa korisnicima, da bi se precizno utvrdilo ta oni misle pod tim dvosmislenim i subjektivnim terminima. Zahtjevi vanjskih interfejsa: Ova klasa zahtjeva opisuje veze izmeu sistema i vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da ukljuuje odlomke za ove zahtjeve, ukljuujui i interfejse, te mehanizme komunikacije za korisnike, hardver i druge softverske sisteme. Ogranienja su uslovi koji ograniavanju izbor rjeenja raspoloivih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani. Neopravdana ogranienja treba pokuati odbaciti jer onemoguavaju postizanje najboljeg rjeenja. Takoe, mogu umanjiti primjenu komercijalnog softvera i komponenti u rjeenju. Neka ogranienja mogu pomoi u zadovoljavaju atributa kvaliteta. Primjer je poboljanje prenosivosti programa koritenjem samo standardnih naredbi nekog programskog jezika. Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija sloenih struktura podataka. Sve definicije treba pohraniti u Rjenik podataka, kao glavni orjentir za uesnike na projektu. Ideje o rjeenju: Ako korisnik opisuje specifian nain interakcije sa sistemom, kojom bi mogao obaviti neku akciju, npr. Korisnik odabira podatak koji eli iz padajue liste, on predlae rjeenje, a ne zahtjev. Predloeno rjeenje moe odvui panju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono to je potrebno obaviti, a ne na nain realizacije. Treba istraiti zato korisnik predlae odreenu ugradnju, jer to moe pomoi u razumijevanju stvarne potrebe i korisnikovih oekivanja o nainu kako sistem treba da raditi.
4.3.4. Postavljanje prioriteta zahtjeva

Nuno svojstvo sistema namee pitanje: Da li vlasnik sistema neto stvarno mora imati? Postoji tendencija da se previe zahtjeva proglasi nunim! Po definiciji, ako sistem ne ukljuuje nune zahtjeve, taj sistem ne moe ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nunim i probati ga rangirati. Ako se zahtjev moe rangirati onda nije obavezan. Potpuno obavezni zahtjevi se ne mogu rangirati, jer su nuni za prvu verziju sistema.
74
Poeljno svojstvo sistema su funkcije koje korisnik eli na kraju da ima. Ranije verzije sistema mogu pruiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poeljni zahtjevi mogu i trebaju biti rangirani. Neobvezna svojstva sistema su proizvoljni zahtjevi, svojstva i mogunosti bez kojih se moe, iako bi lijepo bilo ih imati. To nisu pravi zahtjevi. Ovi zahtjevi, takoe, mogu biti rangirani.
4.3.5. Dokumentovanje analize zahtjeva

Kratke definicije zahtjeva glase: (1) izjava o stanju, ogranienjima i potrebama sistema, (2) narativni dokument namijenjen korisniku, ili ga pie korisnik, a sainjavaju ga poslovni i korisniki zahtjevi, kao i njihovi prioriteti, uoeni problemi, kljune pretpostavke i preporuke za njihovo rjeavanje. Specifikacija zahtjeva, esto nazvana i funkcionalnom specifikacijom, je strukturirani dokument sa detaljnim opisom oekivanog ponaanja sistema (tabela 4.1). Namijenjen je ugovaraima i izvriocima razvoja. Predstavlja cjeloviti i nezavisan pogled na sistem. Sainjavaju ga funkcionalni i nefunkcionalni zahtjevi te njihovi Tabela 4.1.
1. Uvod 1.1 Namjena 1.2 Pregled dokumenata 1.3 Ko treba itati dokumente i savjeti za itanje dokumenata 1.4 Opseg proizvoda 1.5 Referense 2. Sveobuhvatni pregled 2.1 Kontekst proizvoda 2.2 Funkcije proizvoda 2.3 Kategorije korisnika i svojstva 2.4 Okruenje u kojem se izvodi proizvod 2.5 Ogranienja dizajna i ugradnje 2.6 Pretpostavke i zavisnosti 3. Zahtjevi za interfejsom 3.1 Korisniki interfejs 3.2 Hardverski interfejs 3.3 Softverski interfejs 3.4 Komunikacioni interfejs 4. Svojstva sistema 4.x Svojstvo X 4.x.1 Opis i prioriteti 4.x.2 Nizovi pobuda/odziv 4.x.3 Funkcionalni zahtjevi 5. Ostali nefunkcionalni zahtjevi 5.1 Zahtjevi za performansama sistema 5.2 Zahtjevi za sigurnou korisnika 5.3 Zahtjevi za sigurnou podataka 5.4 Kvalitet programske podrke 5.5 Poslovna pravila 5.6 Korisnika dokumentacija 6. Ostali zahtjevi Dodatak A: Rjenik Dodatak B: Modeli i dijagrami Dodatak C: Lista nedovrenih/neodreenih zahtjeva
75
prioriteti, model organizacione strukture (strukturirani dijagrami), opis toka dokumenata (dijagrami toka), model procesa (dijagrami toka podataka), kao i konceptualni model podataka (dijagrami entiteti - veze).
4.3.6. Uzroci loeg planiranja zahtjeva

Nedovoljna ukljuenost korisnika: Bez korisnika se ne moe tono znati ta korisnici ele. Takvi proizvodi su neprihvatljivi. udni korisniki zahtjevi: Neopravdana promjena miljenja tokom izvedbe uzrokuje prekoraenje predvienog roka za realizaciju, kao i degradaciju kvaliteta proizvoda. Nejasni (dvosmisleni) zahtjevi: Situacija u kojoj italac(i) zahtjeva taj zahtjev tumai(e) na vie naina. To uzrokuje prepravljanje i gubljenje vremena. Pretjerano ukraavanje: elja izvoaa da dodaju novu funkcionalnost "koja treba da se svidi korisnicima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti. Izrada takvih dodataka je nepotrebna i predstavlja gubljenje vremena. Minimalistike specifikacije: Tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepata, uz elju da ih izvoai nadopune tokom izvedbe, izaziva frustracije izvoaa i neispunjena oekivanja korisnika. Zanemarivanje potreba: Zanemarivanje potreba odreenih (grupa) korisnika izaziva stvaranje opozicije projektu.
4.3.7. Svojstva dobro postavljenih zahtjeva

Svojstva dobro postavljenih korisnikih zahtjeva su definisana IEEE standardom [1998]. Ta svojstva su: potpunost (cjelovitost), tanost, ostvarivost (izvodljivost), nunost, poredak po prioritetima, nedvosmislenost i mogunost provjere. Dobra specifikacija zahtjeva korisnika mora da sadri slijedea svojstva: potpunost, konzistentnost, mogunost izmjene i mogunost praenja. Cilj je napisati dovoljno dobre zahtjeve, na osnovu kojih se moe pristupiti dizajnu i ugradnji pojedinih komponenata sistema, uz prihvatljiv stepen rizika.
76
Primjer dobro postavljenih korisnikih zahtjeva:

Hemiar ili lan osoblja hemijske laboratorije moe podnijeti zahtjev za jednom ili vie hemikalija. Zahtjev moe biti udovoljen ili dostavom pakovanja hemikalije koja se ve nalazila na zalihi hemijske laboratorije ili upuivanjem narudbe za novim pakovanjem hemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga hemikalija vanjskog dobavljaa dok sastavlja narudbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kada je ispunjen do trenutka kada je udovoljen ili otkazan. Takoe, mora pratiti istoriju svakog pakovanja hemikalija od trenutka kada stigne u kompaniju do trenutka kad je potpuno upotrebljen ili odbaen.
Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sistema (procesi, podaci, dogaaji). Mogu se definisati preslikavanja uoenih imenica i glagola u konkretne komponente analitikog modela. Mogua preslikavanja su opisana u tabeli 4.2. Tabela 4.2.
Tip rijei Imenica Primjer - Ljudi, organizacije, softverski sistemi, jedinice podataka ili postojei objekti Komponente analitikog modela - Skladita 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 moe poduzeti ili dogaaji koji se mogu dogoditi
77
5. Modeliranje fukcija i procesa

5.1. Uvod u modeliranje funkcija i procesa
Logiki procesi (koje sainjavaju funkcije, dogaaji i elementarni procesi) su akcije koji se obavljaju bez obzira na nain ugradnje i raspoloive resurse sistema. Neke metode poistovjeuju funkcije i procese. Stvarni problemi su preveliki i presloeni da bi se rijeili odjednom (u komadu), te je potrebno njihovo strukturno ralanjivanje (razlaganje). Naelo je poznato i glasi podijeli pa s/vladaj (lat. divide et impera, eng. divide and conquer). Sistem se razlae 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. Logiki procesi

Funkcije su skup logiki povezanih trajnih poslovnih aktivnosti i zadataka (npr. djelatnost, posao). Funkcije se obavljaju stalno (nemaju odreeni poetak i kraj). Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline. Primjeri funkcija: Prodaja, proizvodnja, otprema, raunovodstvo. Funkcija se moe sastojati od desetina pa i stotina diskretnih procesa. Funkcije se mogu hijerarhijski razloiti do nivoa diskretnih procesa, koji obavljaju odreeni zadatak kojim odgovaraju na poslovne dogaaje. Dogaaj je logiki dio posla koji se obavlja kao nedjeljiva cjelina. esto je u upotrebi i naziv transakcija. Pokree se diskretnim ulazom i zavrava nakon to proces odgovori odgovarajuim izlazom. Poslovni dogaaj moe se predstaviti jednim procesom kojim sistem reaguje na taj dogaaj. Logiki dogaaj dalje se razlae do elementarnih procesa kojima se prikazuje reakcija sistema na taj dogaaj. Proces (elementarni, primitivni proces) je postupak, nain rada, doslijedna izmjena stanja. Takoe, proces je diskretna odluka, aktivnost ili zadatak kojim se obavlja neki posao.
78
Proces se obavlja uvijek na isti nain (za odreeni ulaz se dobija isti izlaz). Trajanje procesa je konano i odredivo (poznati: poetak, zavretak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska). Poslovna pravila su instrukcije i logika koji odreuju proceduru obavljanja procesa. Ugrauju se u raunarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa). Poslovna politika je skup poslovnih pravila. U veini poslovnih sistema predstavlja osnovu za donoenje odluka.
5.1.2. Modeliranje funkcija

Funkcionalna dekompozicija (dekompozicija funkcija) se koristi za izradu opteg modela funkcija (modela poslovnih funkcija) posmatranog sistema u fazi planiranja, to predstavlja strukturirano planiranje. Hijerarhija funkcija iterativno se razlae do nivoa procesa, tj. do trenutka kada se pone 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.
79
Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi. Funkcije se oznaavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osuiti dio), spojnice su spojevi izmeu 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 dobavljaa
Naruivanje robe
Knjienje
robe
Evidentiranje kupca
Fakturisanje robe
Prodaja robe
Izrada narudbi
Zaprimanje robe
Izrada otpremnice
Otprema robe
Dodavanje
Auriranje
Brisanje
Slika 5.3. Primjer dijagrama dekompozicije za jedan sistem/podsistem.
80
Izrada globalnog modela funkcija moe zapoeti izradom hijerarhijske liste funkcija po pojedinim organizacionim cjelinama. Primjer: NABAVA Evidentiranje dobavljaa Nabavka robe - Izrada narudbi - Zaprimanje robe UPRAVLJANJE OSOBLJEM Evidentiranje slube - Prijem u slubu - Praenje slube redovni rad prekovremeni rad bolovanje godinji odmori - Otputanje iz slube Obraun plata
Izrada dijagrama dekompozicije odvija se po slijedeem 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 pridravati se slijedeih pravila: svaki proces je roditelj ili dijete, roditelj mora imati barem dvoje djece, dok po veini standarda, dijete smije imati samo jednog roditelja. Preporuke: Izostaviti procese koji samo premjetaju ili preusmjeravaju podatke, a pri tome ih ostavljaju nedirnute. Panju usmjeriti na procese koji: neto raunaju (npr. prosjek ocjena), donose ili potpomau odluke (npr. odreivanje raspoloivosti robe pri naruivanju), filtriraju ili sumiraju podatke (npr. rauni kojima je istekao rok plaanja), organizuju podatke u korisne informacije (npr. generisanje izvjetaja), pokreu druge procese (npr. mijenjaju modalitet rada ureaja) ili rukuju podacima (npr. stvaranje, itanje, auriranje, brisanje i slino). Pomou hijerarhijskih dijagrama se moe prikazati funkcionalna dekompozicija realnog sistema. Takav jedan dijagram, dobijen pomou 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 buduim dijagramima toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju sinonime u terminologiji mnogih CASE alata.
81
Slika 5.4. Primjer dijagrama dekompozicije funkcija (procesa). Pored osnovnih podataka za funkcije, za svaku funkciju se odreuje da li je rije o elementarnoj funkciji ili ne. Za funkciju se kae da je elementarna ukoliko njeno zapoinjanje podrazumjeva da e se ona u cjelosti izvriti, ili e efekti njenog izvravanja u cjelosti biti poniteni. Elementarne funkcije se, u principu, ne moraju dalje dekomponovati i tada one predstavljaju listove u hijerarhijskoj strukturi funkcija. U cilju preciznijeg specificiranja, postoji mogunost da se elementarna funkcija dalje dekomponuje na atomine funkcije, koje u tom sluaju predstavljaju listove u hijerarhijskoj strukturi funkcija.
5.1.3. Dijagram organizacije

Dijagram organizacije (shema, mapa, karta organizacije) daje prikaz strukture organizacije hijerarhijom pravougaonika (kuica"). Svaki pravougaonik predstavlja odreenu ulogu ili odgovornost u organizaciji (slika 5.5.). Osim dijagramsko orijentisanog alata, za definisanje organizacione strukture sistema, moe se upotrijebiti alat za neposredni pristup rjeniku podataka, pomou hijerarhijskog navigatora objekata. U ovu grupu alata spada Repository Object Navigator (Designer 2000, ORACLE), ija je ekranska forma prikazana na slici 5.6.
82
Dekan XXX Sekretarica XXX
Prodekan za nastavu XXX Stud. sluba XXX
Prodekan za nauni rad XXX Finansijska sluba
Prodekan za finansije XXX
Sekretar XXX Institut XXX
Biblioteka
Raunarska tehnika
Informacioni sistemi
Slika 5.5. Dijagram organizacije.
Slika 5.6.Ekranska forma CASE alata Repository Object Navigator (Designer 2000, ORACLE).
83
Prozor na lijevoj strani ekranske forme prikazuje hijerarhijski navigator objekata rjenika. Elementi organizacione strukture se definiu kreiranjem pojava tipa objekta pod nazivom Business Units, odnosno poslovne (organizacione) cjeline. Navoenjem oznake neposredno nadreene organizacione cjeline, prilikom unoenja nove organizacione cjeline, uspostavlja se hijerarhijska struktura organizacionih cjelina (desna strana ekranske forme).
5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnolokih procesa

5.2.1. Metodologija funkcionalnog modeliranja IDEF0
Za realizaciju programa integrisane kompjuterizacije proizvodnje razraena je familija metoda IDEF (Integrated Definition Function Modeling), koja je definisana nizom standarda (IDEF0, IDEF1, IDEF1x, IDEF3, IDEF4, IDEF5 i IDEF9). Ova familija metoda se uspjeno primjenjuje u najrazliitijim oblastima i pokazala kao efikasno sredstvo za analizu, projektovanje i predstavljanje (modeliranje) tehnolokih procesa. Metodologija funkcionalnog modeliranja IDEF0 je zamiljena kao inenjerska disciplina za razvoj sloenih sistema, koja ukljuuje ureaje i ljude. Predstavlja metodu za modeliranje tehnolokih procesa i funkcija. Ranije tehnike za ovu namjenu su Structured Analysis and Design Technique - SADT i SofTech, nastale 1960-ih godina. Osnovni pojmovi IDEF0. U osnovi IDEF0 metodologije se nalazi pojam bloka, koji odraava nekoliko poslovnih funkcija. etiri strane bloka imaju slijedee uloge: lijeva strana ima ulogu ulaza, desna izlaza, gornja upravljanja i donja mehanizma.
Upravljanje
Ulaz
Poslovna funkcija
Izlaz
Mehanizam
Slika 5.7. Prikaz bloka poslovna funkcija.
84
Uzajamno dejstvo izmeu funkcija u IDEF0 se predstavlja u obliku duge, koja odraava tok podataka ili materijala, koji sa izlaza jedne funkcije dolaze na ulaz druge. U zavisnosti od toga sa koje strane bloka se nalazi, tok dobija naziv ulazni, izlazni ili upravljaki. Drugim rjeima, poslovne funkcije se mogu prikazati ICOM konceptom (slika 5.7), koji se sastoji od: ulaz (I = Input): neto to se troi u procesu (nije obavezan), upravljanje (C = Control): ogranienje na izvravanje procesa (obavezno), izlaz (O = Output): rezultat procesa (obavezan), mehanizam (M = Mechanism): koristi se u procesu, ali se ne troi (nije obavezan).
Principi modeliranja u IDEF0. U IDEF0 su realizovana tri osnovna principa modeliranja procesa: princip funkcionalne dekompozicije, princip ogranienja sloenosti i princip konteksta. Princip funkcionalne dekompozicije se sastoji u predstavljanju sloene poslovne funkcije skupom elementarnih funkcija, slika 5.8. Princip ogranienja sloenosti se sastoji u tome da broj blokova na dijagramu mora biti od 2 do 6. Princip konteksta se sastoji u tome da modeliranje poslovnog procesa poinje sa crtanjem kontekstnog dijagrama. Na kontekstnom dijagramu se prikazuje samo jedan blok, odnosno samo glavna poslovna funkcija sistema koji se modelira. Pri odreivanju glavne poslovne funkcije, neophodno je imati u vidu cilj modeliranja. Jedan poslovni sistem se moe opisati na razne naine, u zavisnosti od toga sa kog stanovita se posmatra.
Slika 5.8. Grafiki prikaz funkcionalne dekompozicije.
85
Kontekstni dijagram ima jo jednu ulogu u funkcionalnom modeliranju. On odreuje granice modeliranja poslovnog sistema, odnosno odreuje uzajamnu vezu izmeu sistema koji se modelira i njegovog okruenja. Nakon upoznavanja s osnovnim pojmovima funkcionalnog modeliranja poslovnih procesa, neminovno se postavlja pitanje kako ovo modeliranje pomae poveanju efikasnosti i kvaliteta djelatnosti poslovnog sistema. Postojei modeli KAKO JE. Razmatrani poslovni sistem je obavezno dio nekog projekta izgradnje ili razvoja korporativnog IS. Izgraeni funkcionalni modeli KAKO JE omoguavaju jasno utvrivanje koji poslovni procesi se ostvaruju u poslovnom sistemu, koji se informacioni objekti koriste pri izvravanju poslovnih procesa i zasebnih operacija. Funkcionalni model KAKO JE je polazna taka za analizu zahtjeva poslovnog sistema, pojave problema i uskih grla u razradi projekta usavravanja poslovnih procesa. Poslovna pravila. Model parcijalnih procesa omoguava uoavanje i tano odreivanje poslovnih pravila, koja se koriste u radu poslovnog sistema.
Instrukcija Dokument za rukovodstvo
Sortirati dokumente
Neregistrovani dokumenti
Dokumenti za direktora podlijeu registraciji
Registrovati dokumente
Registrovani dokumenti
Prijemno
Slika 5.9. Grafiki prikaz dijela funkcionalnog modela toka dokumenata. Na slici 5.9 je predstavljen dio funkcionalnog modela toka dokumenata (eng. DocFlow, rus. kretanje dokumenata u organizaciji od trenutka nastajanja ili dobijanja do zavretka koritenja ili odailjanja). Pri izvravanju operacije sortirati dokumente koristi se poslovno pravilo: ne podleu registraciji kopirani
86
dokumenti, telegrami i pisma. Ovo pravilo je definisano u instrukciji o toku podataka. Funkcionalni model omoguava ne samo identifikaciju postojanja pravila, nego i na kom radnom mjestu poslovno pravilo se mora primjeniti. U okviru funkcionalnog modela poslovno pravilo ima slijedei oblik: ukoliko je u prijemno doao dokument namjenjen rukovodstvu, on podlijee sortiranju, a kao rezultat, na osnovu instrukcije, se odreuje da li dokument podlijee registraciji ili ne. Informacioni objekti. Funkcionalni model omoguava identifikaciju svih informacionih objekata, koje koristi poslovni sistem u svojoj djelatnosti. Za razliku od nekih informacionih modela (Data Flow Diagrams (DFD), IDEF1x), funkcionalni model IDEF0 odreuje kako se koriste informacioni objekti u okvirima poslovnih procesa. Izgraeni modeli KAKO E BITI. Razvoj i implementacija korporativnog IS dovodi do promjena uslova izvravanja pojedinih operacija, kao i strukture poslovnih procesa. To zahtjeva promjenu poslovnih pravila, promjena u poslovnom sistemu, modifikaciju vaeih instrukcija zaposlenih. Funkcionalni model KAKO E BITI omoguava ve u fazi projektovanja budueg IS predvianje tih promjena. Primjena funkcionalnog modela KAKO E BITI omoguava, ne samo skraenje roka implementacije IS, nego i smanjenje mogueg rizika uslijed neprilagoenosti korisnika informacionim tehnologijama. Raspodjela resursa. Funkcionalni model omoguava jasnu raspodjelu resursa izmeu operacija poslovnog procesa, ta doprinosi efikasnosti koritenja resursa. Taj zadatak je naroito aktuelan pri uvoenju novih poslovnih procesa u poslovnom sistemu. Daljnja razrada metodologije funkcionalnog modeliranja IDEF0 je razvoj slijedee dvije tehnike, i to: tehnike za dokumentovanje tehnolokih procesa (IDEF3) i tehnike za oblikovanje tokova podataka (DFD), koja prikazuje tok informacija.
5.2.2. Dokumentovanje tehnolokih procesa IDEF3

Metoda IDEF3 predstavlja standard za dokumentovanje tehnolokih procesa, koji se odvijaju u poslovnim sistemima, i predstavlja alat za vizuelno praenje i modeliranje njihovih scenarija. Pod scenarijom se podrazumjeva opis redoslijeda promjena svojstava objekata, u okvirima razmatranog procesa (npr. opis redoslijeda etapa obrade dijelova u radionici i promjena njihovih svojstava nakon zavretka svake etape). Izvravanje svakog scenarija prati odgovarajui tok dokumenata, koji je dvojak: tok dokumenata koji odreuju strukturu i redoslijed procesa (npr. tehnoloke napomene, opis standarda) i tok dokumenata koji odraavaju hod njegovog izvrenja (npr. rezultati testova, ekspertiza).
87
Postoje dva tipa dijagrama u standardu IDEF3, koji predstavljaju opise jednog te istog scenarija tehnolokog procesa iz razliitih uglova posmatranja. Dijagrami prvog tipa su Dijagrami opisa redoslijeda faza procesa (Process Flow Description Diagrams (PFDD)), a drugi tip su Dijagrami stanja objekta i njegovi transformacioni procesi (Object State Transition Network (OSTN)). Primjer: Potrebno je opisati proces farbanja dijelova u proizvodnoj radionici. Pomou dijagrama PFDD dokumentuje se redoslijed i opis faza obrade dijela u okviru razmatranog tehnolokog procesa. Dijagrami OSTN se koriste za ilustraciju transformacija dijela, koje se javljaju u svakoj fazi obrade. Razmatrani proces se sastoji od farbanja i faze kontrole kvaliteta, koja odreuje da li je potrebno dio ponovo ofarbati (u sluaju odstupanja od standarda) ili ga poslati na dalju obradu.
OFARBATI PONOVO OFARBATI DIO OSUITI DIO TESTIRATI DIO POSLATI U SLIJEDEU RADIONICU
Slika 5.10. Primjer PFDD dijagrama. Na slici 5.10 je prikazan dijagram PFDD, koji predstavlja grafiku predstavu scenarija obrade dijela. Pravougaonici na dijagramu PFDD se zovu funkcionalni elementi ili elementi ponaanja (Unit of Behavior (UOB)) i oznaavaju aktivnosti, fazu procesa ili primljena rjeenja. Svaki UOB se imenuje glagolskim izrazima oblika infinitiv + objekat i jedinstvenim brojem. Dijagrami PFDD slue za vizuelni prikaz scenarija odvijanja procesa u realnom sistemu. Na dijagramima za veze izmeu funkcija se koriste slijedei grafiki simboli: - prethoenje (Precedence), prethodna aktivnost se mora zavriti da bi slijedea zapoela (crta se slijeva nadesno ili odozgo prema dole), - tok objekata (Object Flow), izlaz prethodne je ulaz u slijedeu aktivnost, - relacioni (Relational Link), povezivanje uz korisniki definisani uslov. Prelazi, veze (J - junction) su slijedee: & (logiko I) - svaka povezana aktivnost uvijek se obavlja/zavrava, X (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnosti, O (ILI) - obavlja se jedna ili vie povezanih aktivnosti.
88
Ako je dijagram PFDD tehnoloki proces sa stanovita posmatraa, onda dijagram OSTN omoguava posmatranje istog procesa sa stanovita objekta, slika 5.11. Stanje objekta, dijela u razmatranom primjeru, i promjena tog stanja su kljuni pojmovi OSTN dijagrama. Stanje objekta je prikazano krugovima, a promjene stanja usmjerenim linijama. Svaka linija je povezana sa odgovarajuim funkcionalnim blokom UOB, a kao rezultat je prikazana promjena stanja objekta.
UOB/ Testirati sloj boje UOB/ Ofarbati dio
Novi sloj boje
Rijetka boja
Tvrda boja na dijelu
UOB/ Osuiti dio
UOB/ Testirati sloj boje
Ispolirati sloj boje
Slika 5.11. Primjer OSTN dijagrama. Na slici 5.12 je prikazana ekranska forma, sa izvodom iz jednog dijagrama, CASE alata Process Modeller (Designer 2000, ORACLE), koji je namjenjen za izradu dijagrama procesa. Process Modeller je zasnovan na slijedeim konceptima: organizaciona jedinica, proces (funkcija), depozit, tok, okida (triger) i ciljni rezultat. Organizacija dijagrama procesa prati funkcionalnu dekompoziciju IS. Za svaki proces u hijerarhiji dekompozicije se formira jedan dijagram. Prilikom otvaranja novog dijagrama bira se proces za koji se dijagram crta i taj proces se zove kontekstni proces. Procesi, koji se na samom dijagramu prikazuju, su prevashodno neposredno podreeni procesi kontekstnom procesu, ali to moe biti i bilo koji drugi proces iz funkcionalne dekompozicije. Procesi na dijagramu se, u terminologiji ovog alata, nazivaju koracima ili aktivnostima. CASE alat Process Modeller omoguava oblikovanje i prikaz organizacione strukture poslovnog sistema, pri emu se cjelokupna hijerarhija organizacionih jedinica, ili neki njen dio, prikazuje na krajnjem lijevom dijelu dijagrama. Svaka organizaciona jedinica, prikazana na dijagramu, ima svoju oblast nadlenosti u
89
pogledu izvoenja pojedinih aktivnosti. Oblast nadlenosti je na dijagramu prikazana u obliku horizontalne trake, koja se protee u visini odgovarajue organizacione jedinice. To znai da je za sve procese u danoj oblasti zaduena nadlena organizaciona jedinica. Matrica organizacione jedinice/procesi se definie pomou dijagrama procesa.
Slika 5.12. Dijagram procesa na ekranskoj formi CASE alata Process Modeller (Designer 2000, ORACLE).
5.3. Modeliranje toka podataka (Data Flow Diagram (DFD))

Dijagram toka podataka (DTP) je skup sredstava za dokumentovanje fizikog i logikog modela sistema, omoguava prikaz protoka, strukture i obrade podataka, te dokumentovanje logike poslovnih pravila i procedura (slika 5.13).
90
Sinonimi za dijagram toka podataka su: transformacioni grafikon, mjehurasti grafikon, mjehurasti dijagram (Bubble Chart). Tehnika, koja se koristi za modeliranje toka podataka, se primjenjuje pri razvoju aplikacija, odakle je i potekla. Ne moe se koristiti za opis programske logike, opis promjene stanja, izradu upravljakih specifikacija ili dizajn korisnikog interfejsa.
D1
Spremite podataka
Tok podataka
a P1
Vanjski entitet
Tok materijala
Proces
5.13. Uproteni dijagram toka podataka.
5.3.1. Elementi dijagrama toka podataka

Tok podataka (data flow) predstavlja skupove podataka koji se kreu kroz sistem. Tokovi ulaze u procese (ulazni), koriste se i mijenjaju u toku obavljanja procesa (ulazno/izlazni) ili nastaju kao rezultat procesa (izlazni). Tokovima se dodjeljuju jedinstveni nazivi oblika imenica ili pridjev+imenica, npr. Potvrena prijavnica, Izlazni raun. Proces predstavlja aktivnost pretvaranja podataka (ulaznog u izlazni tok podataka). Procesi se imenuju glagolskim izrazima oblika infinitiv+objekat (npr. Prijaviti ispit) ili glagolskom imenicom (npr. Prodaja, Prijava ispita). Nazivom treba izraziti ta proces obavlja, to jest treba izbjegavati opte nazive (npr. Obavljanje poslova nabavke). Opis procesa sadri opis aktivnosti (algoritam) njegovog djelovanja. Spremite podataka (data store) predstavlja organizovani i trajni skup podataka. Oznaava mjesto pohrane podataka, npr. dokument, registrator, datoteka, relacija (tabela) u bazi podataka. Promjena sadraja spremita (punjenje, auriranje, pranjenje) i koritenje (itanje) obavlja se procesima. Spremite se oznaava imenicom (imenicom u mnoini), npr. Prijavnica (Prijavnice).
91
Vanjski entitet (external entity, external agent) je objekat vanjskog svijeta povezan sa posmatranim sistemom. Odreuje granice posmatranog sistema. Vanjski entiteti predstavljaju izvorita i odredita podataka, to jest izvore i ponore podataka. Vanjski entiteti mogu biti osobe, orgazicione jedinice, ustanove, drugi sistemi. Za oznaavanje entiteta se koriste imenice, npr. Student, Kupac, Dobavlja.
5.3.2. Izrada dijagrama toka podataka

Dekompozicija procesa se odvija na slijedei nain. Polazni dijagram ili dijagram konteksta hijerarhijski se razlae na poddijagrame do nivoa osnovnih procesa. Proces na nekom nivou razrauje se dijagramom na niem nivou. Preporuuje se izrada dijagrama koji sadre izmeu 2 i 9 procesa, a poeljno je slijediti pravilo 72 (slika 5.14)..
Slika 5.14. Primjer dijagrama toka podataka oblikovan pomou alata Dataflow Diagramer (Designer 2000, ORACLE) .
92
Postupak se zaustavlja kada postane oigledna ugradnja (implementacija) procesa na najniem nivou. Preporuke za oznaavanje elemenata kojih se treba pridravati prilikom crtanja dijagrama su slijedee. Hijerarhijski nivoi nose brojane oznake. Nivo konteksta se oznaava 0. Nazivi spremita, izvora i odredita se oznaavaju velikim slovima, slovne oznake, ili slovo+broj. Procesi i tokovi podataka se oznaavaju malim slovima. Dijagram konteksta prikazuje sistem na najviem nivou hijerarhije prikaza. Definie okruenje sistema i podruje analize. Prikazuje jedan proces i vanjske entitete. Zapoinje se procesom koji prikazuje sistem u cjelini, a nakon toga odreuju vanjski entiteti i njihova povezanost sa sistemom (slika 5.15). Pregledni dijagram (initial diagram) omoguava uoavanje glavnih tokova informacija (npr. koriteni dokumenti, potrebni podaci), odreivanje glavnih aktivnosti sistema i njihovo prikazivanje odgovarajuim procesima. Osim navedenog, pregledni dijagram omoguava ukljuivanje vanjskih entiteta i tokova podataka sa dijagrama konteksta, utvrivanje sa korisnikom granica sistema, kao i utvrivanje procesa i spremita podataka (slika 5.16).
Zahtjev za identifikaciju
P0
Narudba
Osoba
Identifikacija lanska karta
Videoteka
Novi video
Dobavlja
Rezultat upita
Zahtjev za rezervaciju Video lanska karta i plaanje
Upit
lan
Slika 5.15. Primjer dijagrama konteksta: Videoteka.
93
Primjer: Pregledni dijagram, odreivanje granica sistema.
Rezervisati video
Slika 5.16. Odreivanje dometa dijagrama toka podataka: Videoteka [Fertalj & Kalpi, 2005]. U toku razrade procesa na poddijagramu, potrebno je za svaki proces sa preglednog dijagrama identifikovati podaktivnosti. Na primjer, za proces Upisati novog lana, podaktivnosti su: zatraiti line podatke, evidentirati novog lana i izraditi lansku kartu (slika 5.17). Ponavljati postupak za svaki od procesa na poddijagramu. Uspostaviti nivo detalja slijedei pravilo 72. Na kraju je potrebno provjeriti potpunost i ispravnost modela. Model obrazloiti korisniku, a zatim ga po potrebi aurirati. Dubinu i uravnoteenost modela teko je odrediti. U praksi to moe znaiti doradu dijagrama u veem broju ponavljanja, ak i kada dijagrame rade iskusni analitiari.
94
Poliuk E. Jaroslav: Projektovanje informacionih sistema Zahtjev za identifikaciju P1.1
Identifikacija
Zatraiti line podatke
Lini podaci P1.4 Evidentirati novog lana

D1 lan
P1.3
lan
lan
Izraditi lansku kartu
lanska karta
Slika 5.17. Odreivanje dubine i uravnoteenosti modela podataka.
5.3.3. Pravila i ogranienja kod izrade DTP

Pravilo balansa (ouvanja) tokova glasi: Koliina tokova koji ulaze u proces i izlaze iz procesa mora odgovarati koliini tokova podprocesa na niem nivou hijerarhije. Nije dozvoljeno variranje tokova nekog nivoa na niim nivoima (npr. tok T na niim nivoima prikazivati kao T1, T2). Ogranienja i posebni sluajevi su slijedei. Svi objekti modela moraju biti povezani. Nepovezanost pojedinih objekata ukazuje na nepotpunost modela, npr.: postojanje procesa bez ulaza i/ili izlaza (tzv. crne rupe), izlaza za koje ne postoji dovoljno ulaza (tzv. sive rupe) i postojanje nepovezanih spremita ili vanjskih entiteta. Ne dozvoljava se neposredna povezanost vanjskih entiteta, spremita, spremita i vanjskog entiteta. Nije dozvoljeno grananje toka u razliite tokove, spajanje razliitih tokova, kao i postojanje rekurzivnih procesa.
5.3.4. Preporuke za izradu DTP

Prilikom izrade DTP treba voditi rauna o trivijalnim tokovima podataka, neposredno povezanim procesima i procesima koji ne obavljaju pretvaranje podataka.
95
Trivijalni tokovi su izlazi iz procesa koji ne ulaze u spremita ili odredita. Obino imaju posebno znaenje, a mogu se koristiti za prikaz posebnih stanja kao to je dojava poruke sistema (npr. dojava greke). Neposredno povezani procesi su kada jedan od procesa eka na zavretak prethodnog. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. U tom sluaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova, ta je uinjeno sa tokom podataka b, slika 5.18. Procesi se mogu odvijati istovremeno.
Slika 5.18.Primjer prespajanja toka podataka.
5.3.5. Notacije koje koriste DTP

Postoje razliite notacije koje se koriste kod izrade DTP. Najee primjenjivane notacije su: 1. Gane/Sarson (koritena u primjerima), 2. Yourdon/DeMarco, 3. SSADM (koritena na slici 5.14), koje su navedenim redoslijedom prikazane na slici 5.19.
96
a
Poliuk E. Jaroslav: Projektovanje informacionih sistema P1
Vanjski entitet
Ulazni tok
Proces
D1
Izlazni tok
Spremite podataka
Vanjski entitet Ulazni tok
Proces
Izlazni tok
Spremite podataka
Vanjski entitet
Ulazni tok
Proces
D1
Izlazni tok
Spremite podataka
Slika 5.19. Notacije koje se koriste kod izrade DTP. Proirenja modela je izvreno uvoenjem okidaa (trigera), koji prikazuju uestalost procesa (npr. tri puta dnevno), zatim posebnih simbola za prikaz ponavljanja procesa, razdvajanje i spajanje tokova (alternativni tokovi), kao i posebnih simbola za tok resursa, tok dokumenata ili tok upravljanja (npr. razliite linije ili ikone).
5.3.6. Opisivanje podataka

Rjenik podataka (Data Dictionary) je mjesto pohrane definicija elemenata podataka i struktura podataka. Predstavlja strukturirano spremite meta-podataka, tj. podataka o podacima. Prvobitno se pojavio kao proirenje dijagrama toka podataka, za pohranu opisa spremita podataka i tokova podataka. Moe se koristiti kao alternativna tehnika za prikaz modela podataka. Standardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inae koristi za opis sintakse programskih jezika, tabela 5.1. Tabela 5.1. = + () {} [] |
Struktura s lijeva se sastoji od dijelova s desna (sastavljeno od) Agregacija elemenata (logiko I) Opcionalnost elemenata u zagradi (0 ili 1) Ponavljanje (iteracija) elemenata u zagradi, ni jednom do konani broj puta Alternativa (selekcija) elemenata u zagradi Odvajanje alternativnih elemenata u [ ] izrazu
97
** @
Poetna i zavrna vrijednost raspona definisanog [ ] izrazom Komentar Oznaka kljua
Primjer: Opis rauna i stavki rauna koritenjem BNF notacije.

Racun = @BrRac + DatRac + BrKupca + { SifArt, NazArt, Cijena, Kol, Vrijednost } + (IznosRac)
Moe se napisati i kao:

Racun = @BrRac + DatRac + BrKupca + { StavkaRac } + ( IznosRac ) StavkaRac = @SifArt, NazArt, Cijena, Kol, Vrijednost
Primjer: Opis podataka moe zapoeti opisom najmanje logike cjeline podataka, odnosno elementarnih podataka. Nakon toga se opisuju grupe sainjene od elementarnih podataka, ta definie strukturu podataka. Struktura podataka odreuje sadraj spremita podataka, kao i tokove podataka (slika 5.20).
Najmanja logika cjelina podataka Grupe sainjene od elementarnih podataka
Elementarni podatak Struktura podataka
Grupe sainjene od struktura podataka
Tok podataka
Spremite podataka
Slika 5.20. Primjer opisivanja podataka.
98
5.4. Elementarni procesi

Mini-specifikacije (funkcionalne primitive) se koriste za opisivanje osnovnih procesa u dijagramu toka podataka. Mogu poprimiti razliite oblike, ali imaju nekoliko zajednikih elemenata: naziv i broj procesa, listu podataka koji ulaze u proces (ulazni tokovi podataka), listu podataka koji izlaze iz procesa (izlazni tokovi podataka), kao i tijelo opisa procesa. Opis procesa sadri algoritam zadatka koji se procesom obavlja, koji moe poprimiti razliite oblike (dizajn programa, odnosno opis programske logike). Na osnovu ovog algoritma moe se, u zavisnosti od alata, generisati programski kd (tabele 5.2 i 5.3). Mini-specifikacije kreira korisnik CASE alata. Budui da se ne kreiraju automatski na osnovu prethodno unesenih opisa (modela procesa i modela podataka), neosjetljive su na izmjene dijagrama [Fertalj & Kalpi, 2005]. Primjer 1: Definisanje procesa (1). Tabela 5.2.
Proces 1: Opis: Ulazni tokovi: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film) Rezervacije Posuivanje Rezultat upita (Raspoloiv | Nije raspoloiv | Ne postoji) izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posuivanja + broj rezervacija) rezultat = Raspoloiv inae rezultat = Nije raspoloiv inae poruka Ne postoji
Izlazni tokovi: Logika procesa:
99
Tabela 5.3.
Primjer 2: Definisanje procesa (2).

Proces 1: Opis: Ulazni tokovi: Izlazni tokovi: Logika procesa: Provjera raspoloivosti filma Provjera da li u videoteci postoji kopija filma koja se moe iznajmiti Upit (Film) Rezervacije Posuivanje Film nije raspoloiv, Film je raspoloiv, Ne postoji izraunaj broj kopija traenog filma u videoteci ako je broj kopija vei od nule tada ako je broj kopija vei od (broj posuivanja + broj rezervacija) rezultat = Film je raspoloiv inae ako lan eli rezervisati film tada upii rezervaciju (izlazni tok Film nije raspoloiv) inae poruka Ne postoji
5.4.1. Primjena modela procesa

Strateko planiranje sistema predstavlja definisanje arhitekture sistema u okviru stratekog plana, pri emu se radi model procesa poslovnog sistema (globalni model procesa). Identifikuju se poslovna podruja i poslovne funkcije, najee u obliku dijagrama dekompozicije funkcija ili nerazraenog DTP (npr. dijagramom konteksta odreuju se domaaj i interfejs sistema). Reinenjerstvo poslovnih procesa je analiza i restrukturiranje poslovnih procesa radi poboljanja efikasnosti i uklanjanja birokratije, prije primjene informacijskih tehnologija. Postojei procesi se analiziraju i dokumentuju prikladnim modelima procesa. Izrauju se dijagrami toka podataka sa fizikalnim primjesama, koje ukljuuju vremensku dimenziju, protonost podataka i trokove. Analiza sistema razmatra aplikacione modele procesa, odnosno logike modele procesa sistema ili aplikacije. Teorijski, mogue je proizvesti DTP povratnim inenjerstvom postojeih aplikacija, ali e takav dijagram biti preoptereen fizikalnim primjesama. Dizajn sistema se bavi fizikim modelima procesa, tj. dodavanjem upravljakih komponenti i resursa. Prikupljanje i sreivanje informacija o funkcijama i procesima se moe obaviti pomou tabela prije, ali i umjesto, izrade dijagrama (tabela 5.4).
100
Proces Ulaz (od)
Tabela 5.4.
Izlaz (prema) Vanjski entitet Spremite Komentar/Algoritam
Izraditi narudbu ... Prijem u slubu
Podaci o dobavljau, Artikli za naruivanje ... Zahtjev za prijem (osoba)
Ispisana narudba (dobavlja) ... Rjeenje zahtjeva (osoba, ... )
Dobavlja
... Osoba
Narudba, Dobavlja, Stavka, Artikl ... Osoba, Tok slube
Struktura tokova ne mora u potpunosti odgovarati strukturi spremita Provjeri zahtjev prema Pravilniku o zapoljavanju, pa napii rjeenje
Dijagram toka podataka (DTP) iz stvarnog projekta prikazan je na slici 5.21.
Slika 5.21. DTP iz stvarnog projekta [Fertalj & Kalpi, 2005].
101
6. Modeliranje podataka
6.1. Osnovni pojmovi modela podataka
6.1.1. Uvod u modeliranje
Modeliranje podataka je tehnika organizovanja i dokumentovanja podataka IS. Sinonim je modeliranje baze podataka, budui da se podaci najee pohranjuju u BP. Prema mnogim autorima modeliranje podataka je najvanija tehnika oblikovanja informacionog sistema. Podaci su resurs koji se dijeli izmeu veeg broja procesa i zbog toga moraju biti organizirani na nain koji je prilagodljiv poslovnim zahtjevima. Strukture podataka i njihova svojstva su trajniji i stabilniji od procesa. Modeliranje podataka se zavrava bre nego modeliranje procesa i modeli podataka se bre pribliavaju rezultatu nego modeli procesa. Pored toga, modeli podataka su bitno manji od modela procesa. Modeli podataka postojeeg i budueg sistema meusobno su sliniji nego modeli procesa postojeeg i budueg sistema, a i lake ih je preoblikovati, pa se manje posla baca. Omoguavaju dobru komunikaciju sa korisnicima i lake utvrivanje naziva.
6.1.2. Dijagram entiteti-veze

Dijagram entiteti-veze (Entity-Relationship Diagram (ERD)) se naziva jo i dijagram objekti-veze, skraeno DOV, (slika 6.1). Postoje razliite notacije ovih dijagrama, npr. Chen, Martin. Osim osnovnih modela, koriste se i proireni modeli, koji su i obraeni u ovoj knjizi. Ne postoje jednoznani standardi postupka njihove izrade.
Slika 6.1. Ilustracija dijagrama entiteti-veze.
102
6.1.3. Entiteti
Entitet (entity) je neto to postoji u stvarnom svijetu i posjeduje osobine koje ga opisuju i po kojima se razlikuje od svoje okoline. Definicije entiteta istaknutih autora su: (1) stvar koja se moe zasebno identifikovati [Chen, 1976], (2) bilo koji objekat koji se moe razlikovati i predstaviti u bazi podataka [Date, 1986], (3) logika reprezentacija podatka [Finkelstein, 1989], (4) bilo ta o emu pohranjujemo informaciju [Martin, 1989]. Entitet moe biti: osoba, npr. Ivo Ban, objekat, npr. roman Zloin i kazna, apstraktni pojam, npr. engleski jezik ili iskustvo (poznavanje jezika), ustanova (ETF), poslovni sistem (Hotel Proljee ili Elektroprivreda), dogaaj (situacija, stanje) - proli, sadanji ili budui, npr. roenje, kolovanje, zaposlenje, penzionisanje, povezanost razliitih objekata stvarnog svijeta, npr. srodstvo.
Pojedinane pojave (instance), u zavisnosti o metodi, se grupiu u: skup entiteta (entity set), tip entiteta (entity type) i klasu entiteta (entity class). U praksi se moe poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podaci. Oznaava se imenicom (u jednini), npr. Osoba, Fakultet. Entiteti mogu poprimiti razliite uloge u zavisnosti od konteksta, npr. Osoba je Kupac i/ili Dobavlja, Student ili Nastavnik.
6.1.4. Atributi i domeni

Atribut predstavlja neko obiljeje, odnosno znaenje entiteta. Sinonimi za atribut su: svojstvo (property), polje (field). Pojedinane vrijednosti atributa se pohranjuju u bazu podataka kao elementarni podaci. Po vrijednostima koje predstavljaju, atributi mogu biti: jednostavni atributi, kod kojih je vrijednost pojedinani podatak: npr. Prezime, Ime, sloeni (sastavljeni) atributi, gdje je vrijednost ureena torka ili logika grupa jednostavnih atributa: npr. datum = (dan, mjesec, godina), vieznani atributi, odnosno atributi koji predstavljaju ponavljajue grupe podataka, tj. atributi sa vie istovrsnih vrijednosti: npr. Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon).
103
Obzirom na uskladitenu vrijednosti, atributi mogu biti atributi za uskladitenje i izvedeni atributi, gdje im se vrijednost moe odrediti na osnovu vrijednosti drugih atributa: starost = (DananjiDatumDatumRoenja). Vrijednosti atributa definiu tip podatka (domen) i pretpostavljena ili standardna vrijednost (default). Tipovi podataka mogu biti netehniki (logiki) ili tehniki. Netehniki tipovi podataka su opti tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva (npr. broj, datum-vrijeme, znakovni niz, tekst, BLOB (Binary Large OBject)), dok su tehniki tipovi podataka generiki tipovi podataka koji se mogu preslikati u konkretne tipove (npr. integer, character ili konkretni tipovi char, int, byte (iz sastava SUBP SQLserver)). Standardna vrijednost atributa je vrijednost koja se zapisuje kada je korisnik ne specificira. Uopteno reeno, veina atributa treba da ima standardnu vrijednost. Domeni su skup moguih vrijednosti koje, nad njima definisani atributi, mogu poprimiti. Domeni mogu biti jednostavni i sloeni, isto kao i atributi. Nad svakim domenom se moe definisati po volji mnogo atributa. Skup vrijednosti (domen) se moe definisati: tipom podatka (npr. integer), podskupom vrijednosti tipa podatka (npr. formula CC66, interval [10-99]) ili skupom konstanti (npr. Pol = {M, }). Ilustracija atributa i domena dana je na slici 6.2.
8746 37528 1164 ...
Ford Karson Rock ...
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
... ... ... ...
038 001 282
Slika 6.2. Ilustracija atributa i domena.
104
6.1.5. Kljuevi
Klju (key) ili identifikator (Id, @) je atribut ili skup atributa koji (svojim vrijednostima) jednoznano identifikuju svaki od entiteta u nekom skupu entiteta. Mora se sastojati od bar jednog atributa (jednostavni klju): npr. OSOBA = @JMBG + Prezime + Ime; MJESTO = @ifraMjesta + NazivMjesta, a moe se sastojati od vie atributa (sloeni, sastavljeni, ulanani klju): npr. MJESTO = @ifraDrave +@ifraMjesta. Klju mora zadovoljavati uslove jednoznanosti i minimalnosti. Jednoznanost se definie na slijedei nain: u skupu entiteta ne smiju postojati dvije pojave sa istim vrijednostima svih kljunih atributa (npr. ne smiju postojati 2 osobe sa JMBG=2209964100028), dok minimalnost znai da ne postoji podskup atributa kljua koji je, takoe, jednoznaan (npr. lo primjer: OSOBA = @JMBG + @Prezime + ... , dobar primjer: KURS = @OznakaValute + @DatumKursa + ... ). Osim navedenih uslova, klju mora zadovoljiti i slijedee uslove: odreenost (postojanje vrijednosti u trenutku stvaranja instance), stabilnost (otpornost na promjene tokom vremena), raspoloivost (dostupnost svim korisnicima), neutralnost (obzirom na znaenje vrijednosti kljua).
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
... ... ... ...
038 001 282
ifra mjesta (SifMjesta) 038
Potanski broj (PostBr)
Naziv mjesta (NazMjesta)
001 282
10000 20000 30000
Roma New York

Los Angeles
Slika 6.3. Povezivanje entiteta ili skupova entiteta stranim kljuem. Entitet moe imati jedan ili vie kljueva. Entitet mora imati barem jedan klju. Entitet moe imati vie moguih kljueva, tj. kandidata za primarni klju, koji ne moraju
105
biti meusobno disjunktivni, tj. mogu imati atribute presjeka. Jedan od kljueva se odabira za primarni klju (primary key): npr. Osoba.IdOsobe, Mjesto.SifMjesta. Nakon odabira primarnog kljua, ostali mogui kljuevi postaju alternativni kljuevi (alternate key (AK)): npr. Osoba.JMBG, Mjesto.PostBr. Strani klju (foreign key (FK)) je skup atributa koji se odnosi na klju drugog skupa entiteta, tj. skup atributa ije se vrijednosti odnose na vrijednosti kljua drugog entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta). Strani klju ukazuje na povezanost izmeu entiteta, odnosno skupova entiteta (slika 6.3.). Moe poprimiti vrijednost primarnog kljua drugog entiteta ili nula-vrijednost (null value). Primjer: Osoba.SifMjesta odnosi se na Mjesto.SifMjesta, odnosno Entitet Osoba (IdOsobe=8746) ima SifMjesta=038, tj. referensira entitet Mjesto sa IdMjesta=038. Nula-vrijednost oznaava nepoznatu vrijednost atributa ili neodreenu vrijednost atributa, tj. nadomjeta vrijednost atributa koji se ne koristi. Nula-vrijednost nije 0 (nula) niti (prazan znakovni niz). Primjer: Mogue nula-vrijednosti: Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta neodreena (nepoznata) vrijednost; Vozilo (tipa putniki automobil) nepoznatog registarskog broja, nasuptot vozila (tipa buldoer) koje se ne registruje na isti nain (neprimjenljiva vrijednost).
6.1.6. Veze
Veza (relationship) pokazuje odnos izmeu entiteta. Analogno entitetima, pojedinana veza uspostavlja se na nivou instanci entiteta, a veze se grupiu u skupove veza (relationship sets). Kada se ne razmatraju instance, pojam veza podrazumijeva skup veza. Veza moe izraavati ulogu entiteta koje povezuje, a imenuje se glagolom ili glagolskom imenicom. Primjer: Veza i uloge: Osoba STANUJE u Mjestu (Osoba je STANOVNIK Mjesta), u Mjestu STANUJE Osoba (Mjesto je MJESTO STANOVANJA Osobe).
106
Mjesto MjestoStan
Stanuje Stanovnik
Osoba
Slika 6.4. Primjer veze i uloga. Stepen veze je broj entiteta koji sudjeluju u vezi. Uopteno, moe se povezati bilo koji broj entiteta (pri emu treba biti oprezan!). Tako veza drugog stepena je binarna veza, veza treeg stepena je ternarna veza, dok je, uopte, veza n-tog stepena: n-arna veza. Posebni sluaj je veza nekog entiteta sa tim istim entitetom. To je veza prvog stepena: unarna veza (refleksivna, rekurzivna, involucijska). U nekim metodama se smatra posebnim sluajem binarne veze, tj. posebnom vezom 2. stepena. Tip, klasifikacija veze (type of relationship) oznaava nain pridruivanja pojava entiteta u vezi: jedan-prema-jedan (1:1), jedan-prema-vie (1:N) - moe postojati vie (paralelnih) veza izmeu dva entiteta, vie-prema-vie (M:N). Kardinalnost veze (donja i gornja granica kardinalnosti) je minimalni i maksimalni broj pojava jednog entiteta za pojedinanu pojavu sa njim povezanog entiteta. Donja granica moe biti 0, 1, pozitivni cijeli broj ili znak (npr. M). Kada je donja granica jednaka nuli postoji djelomino, neobavezno pridruivanje. Ne mora postojati nijedna instanca sa druge strane veze. Kada je donja granica razliita od nule postoji potpuno, obavezno pridruivanje. Mora postojati barem neki broj ili openito M instanci sa druge strane veze. Gornja granica moe biti 1, pozitivni cijeli broj ili znak (npr. N). Moe imati konkretan broj ili openito N instanci sa druge strane veze. Veze su dvosmjerne pa se kardinalnost definia za oba smjera veze. Primjer: Binarna veza 1:N. 1,1
Mjesto
Stanuje
0,N
Osoba
107
Primjer: Binarna veza M:N. OrgJed 0,M 0,N Proizvod
Proizvodi
Slika 6.5. Primjeri binarnih veza 1:N i M:N. Primjer: Ternarna veza. Zanimanje 1,N Osoba 1,N Zaposlen 1,N OrgJed
Primjer: Unarna veza 1:N i unarna veza M:N. 0,1 Pripada PodJed 0,N Proizvod Dio 0,N 0,M Sastav
NadJed OrgJed
Cjelina
Slika 6.6. Primjer ternarne veze i unarnih veza 1:N i M:N.
6.1.7. Specijalizacija/generalizacija
Specijalizacija/generalizacija se zove i "je" veza (is a relationship). Ova veza opisuje posebne sluajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip). Podreeni entiteti stvaraju se na osnovu njima nadreenog entiteta sa kojim dijele zajednike atribute:
108
nadtip (supertype) - sadri zajednike atribute i predstavlja generalizaciju podreenih entiteta, podtip (subtype) - sadri samo njemu svojstvene atribute i predstavlja specijalizaciju nadreenog entiteta. Primjeri: 1. B je podtip od A ako: B je uvijek A, A je ponekad B; 2. Radnik je uvijek Osoba, Osoba je ponekad Radnik (Saradnik); 3. Igla je uvijek Proizvod, Proizvod je ponekad Igla (Avion). Specijalizacija moe biti neekskluzivna (npr. Osoba je Radnik ili Saradnik, ali u isto vrijeme moe biti i Radnik i Saradnik) ili ekskluzivna (Proizvod je Igla ili Avion, ali ne moe istovremeno biti Igla i Avion). Osoba Proizvod 11 0,1 Radnik NS 0,N Saradnik 0,1 Igla ES 0,1 Avion
Slika 6.7. Neekskluzivna i ekskluzivna specijalizacija.
6.1.8. Jaki i slabi entiteti

Jaki entitet je entitet koji postoji (egzistira) samostalno, nezavisan/dominantan entitet, npr. Mjesto. Slabi entitet postoji samo ako postoji jaki entitet u vezi, predstavlja zavisan/podreen entitet. Egzistencijalno slabi entitet je entitet koji ne postoji samostalno, entitet sa stranim kljuem (npr. Osoba). Identifikaciono slabi entitet je entitet koji se ne identifikuje samostalno, entitet koji nema vlastiti klju nego se njegov klju sastoji od kljua jakog entiteta i, prema potrebi, vlastitog atributa (deskriptora), npr. Radnik, Saradnik, StavkaRacuna. Identifikaciono zavisan entitet je ujedno i egzistencijalno zavisan. Egzistencijalno zavisan entitet nije ujedno i identifikaciono zavisan.
109
Primjer: Egzistencijalno slab entitet Osoba.

Mjesto
1,1 Stanuje 0,1
Osoba
Primjer: Identifikaciona veza i identifikacioni slab entitet.

Racun
1,1 RacStRac 1,N
StavkaRacuna
Slika 6.8. Primjeri slabih entiteta.
6.1.9. ERD notacije

Najvie je u upotrebi Chen-ova i Martin-ova notacija dijagrama entitetveze (ERD), slike 6.9 i 6.10. 1. Chen-ova notacija: Mjesto
1,1
Zanimanje
1,N 0,N
0,1 NadJed
Pripada
0,N Proizvodi 0,M Sastav Dio 0,N 0,1
PodJed 1,N
Stanuj
Osoba
1,N
Zaposlen
OrgJed
0,M
1,1 0,N 1,1
Raun
1,1
RaStRa OdnosiSeNa
0,N Cjelina 1,1
Proizvod
1,1 0,1
NS
0,1 0,N
1,N
StavkaRauna
ES
Radnik
Saradnik
0,N
Igla
Avion
Slika 6.9. Primjer dijagrama entitetveze jednog preduzea (prema Chen-u).
110
2. Martin-ova notacija.
Mjesto
Zanimanje
Pripada Stanuje
Osoba
Zaposlen
OrgJed
Sastav
Proizvod Raun
Radnik
Saradnik
Stavka rauna
Igla
Avion
Slika 6.10. Primjer dijagrama entitetveze jednog preduzea (prema Martin-u).
6.1.10. Izrada ERD analizom izjava korisnika

Dijagrama entitetveze (ERD) moe biti izraen na osnovu izjava korisnika. Tekst izjave korisnika za izradu dijagrama entitetiveze za hemijsku laboratoriju moe da glasi: "Hemiar ili lan osoblja hemijske laboratorije moe podnijeti zahtjev za jednom ili vie hemikalija. Zahtjev moe biti udovoljen ili dostavom pakovanja hemikalije koja se ve nalazila na zalihi hemijske laboratorije ili upuivanjem narudbe za novim pakovanjem hemikalije od vanjskog dobavljaa. Osoba koja upuuje zahtjev mora imati mogunost pretraivanja kataloga hemikalija vanjskog dobavljaa dok sastavlja narudbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takoe, mora pratiti istorijat svakog pakovanja hemikalija od trenutka kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbaen".
111
M zahtjeva
Inventar hemijske laboratorije 1 pohranjuje M M ispunjava 1
Zahtjev za hemikalijom
popisuje
Zahtjeva
M M 1 M
Pakovanje hemikalija 1 prati 1
sadri
Hemikalija
opisuje M
Istorija pakovanja hemikalija
Dobavljaev katalog
Slika 6.11. Primjer dijagrama entitetiveze za hemijsku laboratoriju [Fertalj & Kalpi, 2005].
6.2. Razvoj modela podataka

6.2.1. Uvod u razvoj modela podataka
Moe da se razvija jedan od slijedeih modela podataka: globalni model podataka (enterprise data model), model konteksta podataka (context data model), model podataka sa definisanim kljuevima (key-based data model), model podataka sa
112
potpuno odreenim atributima (fully attributed data model) i potpuno opisani model podataka (fully described data model). Kategorije entiteta, koji ulaze u sastav modela podataka, su slijedee: 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 izrauje u fazi planiranja. Dobijeni konceptualni model entiteti-veze, koji najee sadri neodreene veze i nerazraene kategorije podataka, moe da ne sadri pojedine veze. Definie se mogui domet sistema, kao i ukupne informacione potrebe. Model konteksta podataka se izrauje na poetku analize. Konceptualni model, koji sadri samo one entitete koji e biti obuhvaeni tehnikim rjeenjem, predstavlja aplikativni model podataka. Takav model usklauje doseg bez detalja o entitetima ili detalja o poslovnim pravilima. ERD sa entitetima i vezama (esto nespecifinim), bez atributa ili samo sa osnovnim atributima, sadri: obine veze, tj. veze tipa 1:N, npr. "raun ima vie stavki" ili veze vieg stepena, npr. zaposlenje osobe u organizacionoj jedinici na radnom mjestu, odnosno Zaposlen. Preporuka je da se izbjegavaju entiteti koji se odnose na specifini 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 podrava. 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 rjenika podataka, bilo da pripadaju izabranom ili nekom drugom aplikativnom sistemu. Na ovaj nain se obezbjeuje mehanizam za oblikovanje jedinstvene konceptualne sheme BP informacionog 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 pomou jedne linije koja povezuje dva tipa entiteta. Ta linija moe biti puna, isprekidana ili djelimino isprekidana i na sebi imati dodatne oznake u zavisnosti od parametara tipa veze. Pored optih pravila za tumaenje prikazanog ERD-a, koja se mogu nai u literaturi o BP, potrebno je naglasiti da simbol: "#" uz atribut (obiljeje) oznaava da je rije o atributu koje je u sastavu primarnog kljua tipa entiteta, "*" uz atribut oznaava da je rije o atributu koji je obavezan za unos, odnosno korespondira ogranienju Null(N, A) = , "o" uz atribut oznaava da je rije o atributu koji nije obavezan za unos, odnosno korespondira ogranienju Null(N, A) = T,
114
"|" na tipu veze oznaava da je tip entiteta na strani gdje se nalazi simbol "|" identifikaciono zavisan od tipa entiteta na drugoj strani, to znai da e u sastav primarnog kljua takvog tipa entiteta ui i svi atributi primarnog kljua tipa entiteta na drugoj strani posmatranog tipa veze, a " " na tipu veze oznaava 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. Logiki modeli podataka

Model sa definisanim kljuevima entiteta ne sadri neodreene veze. One su nadomjetene asocijativnim entitetima. Vri se odreivanje kljueva (primarnih, alternativnih, stranih). Ako se primarni klju (PK) ne moe odrediti, moda se ne radi o skupu entiteta. Odreivanje kardinalnosti veza se vri odgovaranjem na pitanja oblika: mora/ moe: ni jedan (0), barem jedan (1), vie (N), odnosno donja/gornja granica kardinalnosti. Primjeri: 1. Koliko stavki rauna mora/moe imati raun? odgovor je: 1 (donja granica kardinalnosti), N (gornja granica kardinalnosti); 2. Koliko se osoba mora/moe nalaziti u mjestu? odgovor je: 0 (donja granica kardinalnosti), N (gornja granica kardinalnosti). Definisanje generalizacionih hijerarhija (odreivanje specijalizacija, tj. podtipova entiteta), npr. Igla i Avion, vri se definisanjem klasifikacionog atributa nadtipa (diskriminator podtipa), npr. Proizvod.TipProizvoda {Igla, Avion}. Model sa definisanim atributima entiteta se dobija dodavanjem preostalih opisnih atributa, odreivanjem podskupova podataka, definisanjem domena, logikih tipova podataka i standardnih vrijednosti atributa (slika 6.13).
115
Slika 6.13. Primjer modela podataka sa definisanim atributima entiteta i kljuevima entiteta (konceptualna shema).
6.2.4. Dokumentovanje i konverzija modela entiteti-veze

Potpuno opisani model podataka je ostvaren kada raspolae sa putpunim opisom atributa, logikih tipova podataka i standardnih vrijednosti. Dodatni opisi su prava pristupa podacima i trajnost podataka (arhiviranje). Dobijanje potpuno opisanog modela vremenski je najzahtjevniji zadatak. Uobiajeno se provodi na kraju, ali moe zapoeti uporedno sa izradom modela zasnovanog na kljuevima ili definisanjem opisnih atributa. Dalja konverzija modela se sastoji u prevoenju modela entiteti-veze u relacioni model podataka. Faza dizajna, odnosno fiziko oblikovanje podataka, se sastoji od konverzije logikog u fiziki model (izrada sheme baze podataka), kao i od normalizacije i prilagoavanja uslijed tehnikih ogranienja i performansi.
116
6.2.5. Definisanje koncepata modela podataka

Definisanje entiteta podrazumjeva dodjeljivanje jedinstvenih naziva i izradu opisa entiteta, odnosno definisanje znaenja i namjene entiteta, poslovnih zahtjeva i ogranienja. Treba koristiti kratki naziv (kd), koji je esto potreban zbog ogranienja alata ili programskog jezika. Izbjegavati skraenice zbog mogue pojave akronima. Atributi kljueva i opisni atributi su vani za razumijevanje sutine modela. Voditi rauna o tragu zahtjeva, odnosno porijeklu i primjeni entiteta. Potrebno je definisati ovlatenja nad meta-podacima i odgovornost za podatke. Definisanje veza se sastoji u odreivanju jedinstvenog naziva, koji se sastoji od glagola, odnosno glagolske imenice (npr.Roditelj-Dijete). Takoe je potrebno definisati: znaenje veze (sastavni dio dokumentacije), tip veze (identifikaciona ili neidentifikaciona veza), modalitet i kardinalnost, kljueve, diskriminator generalizacije /specijalizacije, kao i pravila za ouvanje integriteta pri unosu i brisanju instanci. Odreivanje kljueva se sastoji u odreivanju kljua jakog entiteta (identifikacioni atribut) i kljua identifikaciono slabog entiteta (klju jakog entiteta i vlastiti atribut). Potrebno je obratiti panju na kljueve sastavljene od vie atributa, kao i na atribute kljua koji su ujedno kljuevi drugih entiteta. Odrediti mogue zamjenitelje kljueva. Kod stranih kljueva obratiti panju na moguu migraciju primarnog u strani klju. Treba ukloniti neodreenosti stranih atributa. Definisanje atributa podrazumjeva da naziv atributa mora biti jedinstven, sa izuzetkom stranih kljueva. Treba povesti rauna o znaenju atributa, domenu atributa i kardinalnosti atributa. Atributi mogu biti izvedeni atributi (iz razliitih instanci) i izraunati atributi (jedne instance).
6.3. Logiko modeliranje podataka

6.3.1. Prevoenje modela E-V u relacioni model
Osnovni koncepti koji se javljaju u modelu entiteti veze (EV) su: entiteti, atributi, kljuevi i veze. U narednom tekstu je predstavljeno parcijalno prevoenje modela E-V u relacioni model. Entiteti (skup entiteta) se predstavljaju relacijama (tabelama). Stanovnici Mjesta XX su Osobe XXX (relacije: Mjesto, Osoba).
117
Atributi mogu imati slijedee kardinalnosti preslikavanja: kardinalnost 0 - opciona vrijednost (null), kardinalnost 1 - zahtijevana vrijednost (not null) i kardinalnost N vieznani atribut (npr. Osoba.Telefon). Atribut Prezime entiteta Osoba se predstavlja sa Osoba.Prezime. Izvedeni atribut je atribut koji se pamti ili se izostavlja, npr. Osoba.Staz, dok je sloeni atribut dobijen grupisanjem, npr. grupisanjem (dan, mjesec, godina) dobija se atribut Datum (slika 6.14).
Osoba IdOsobe Prezime Ime Adresa DatRodj Staz
Slika 6.14. Atributi skupa entiteta Osoba. Vieznani atribut je skup odgovarajuih atributa, npr. Osoba.Telefon: Osoba.TelefonNaPoslu, Osoba.TelefonKodKuce, Osoba.MobilniTelefon ili prikazano kao slabi entitet, npr. Osoba.Telefon: Telefon (IdOsobe, VrstaTelefona, BrojTelefona), slika 6.15.
Osoba IdOsobe Prezime Ime TelefonNaPoslu TelefonKodKuce MobilniTelefon Adresa DatRodj Staz Osoba 1,1 0,N Telefon
Telefon VrstaTelefona BrojTelefona
Slika 6.15. Primjeri vieznanih atributa.
118
Kljuevi mogu biti primarni, npr. Osoba.IdOsobe, Mjesto.SifMjesta ili alternativni (AK), koga sainjava indeks nad jedinstvenim vrijednostima (unique index) + oznaka zahtijevane vrijednosti (not null), npr. Mjesto.PostBr (slika 6.16).
OsobaSKljucem IdOsobe Prezime Ime Adresa DatRodj Staz
Mjesto SifMjesta PostBr <AK> NazMjesta
Slika 6.16. Primjeri primarnog i alternativnog kljua <AK>. Veza moe biti binarna veza 1:N sa stranim kljuem. Na slici 6.17 su prikazane binarne veze egzistencijalno slabog entiteta sa obinim stranim kljuem i to: Stanuje (Osoba.SifMjesta) <FK1>, Pripada (OrgJed.SifNadJed) <FK2> i RacunOsoba (Racun.IdOsobe) <FK3>.
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.17. Primjeri stranog kljua <FK>.
119
Identifikaciono slabi entitet naslijeuje klju jakog entiteta. Taj klju moe biti spojni klju, npr. StavkaRacuna (BrRacuna, SifProizvoda, JedCijena, Kolicina) ili kompozitni klju, npr. StavkaRacuna (BrRacuna, RbrStRac, SifProizvoda, JedCijena, Kolicina), slika 6.18.
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.18. Primjeri sloenog kljua. Binarna veza 1,1:0,1 sa stranim kljuem transformie se u identifikaciono slabi entitet bez deskriptora: npr. Osoba (IdOsobe, Prezime, , Staz), SlikaOsobe (IdOsobe, Slika). Po potrebi se moe razmotriti udruivanje entiteta u binarnoj vezi 1,1:1,1 (1,1:0,1) u jednu relaciju: Osoba (IdOsobe, Prezime, , Staz), Komentar (IdOsobe, TekstKom), Osoba (IdOsobe, Prezime, , Staz, TekstKom).
0,M 0,N
OrgJed
Proizvodi
Proizvod
Zanimanje SifZan NazZan
Zanimanje 1,N Osoba 1,N

Zaposlen
1,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,M
Cjelina
Sastav SifProizvod<FK1> SifDjela <FK2> BrDjelova

BrDjelova
Proizvodi SifOrgJed <FK1> SifProizvod<FK2>
Proizvod
Dio
Sastav
Slika 6.19. Primjer kljueva asocijativnog entiteta.
120
Nespecifine veze se sastoje od asocijativnog entiteta + n binarnih veza 1:N. Klju asocijativnog entiteta je unija kljueva entiteta spojenih vezom (slika 6.19). Primjer: Proizvodi, Zaposlen, Sastav. Specijalizacija nadtipa u n podtipova (n binarnih veza) u kojoj je nadtip (jaki) entitet, kome se po potrebi odreuje klasifikacioni atribut, npr. Proizvod.TipProizvoda i podtip (identifikaciono) slabi entitet, npr. Igla, Avion (slika 6.20).
Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda Proizvod
1,1 0,1
ES
0,1
Igla
Avion
Igla SifProizvoda <FK> Duzina Promjer
Avion SifProizvoda <FK> BrSjedista DoletKM
Slika 6.20. Primjer specijalizacije nadtipa u n podtipova.
6.3.2. Implementaciono projektovanje sheme BP pomou CASE alata

Implementaciono projektovanje sheme baze podataka zapoinje prevoenjem ERD konceptualne sheme BP u relacioni model. Nakon postupka prevoenja konceptualne sheme BP, sa slike 6.13, u relacioni model podataka i izvrene normalizacije, dobija se implementaciona shema BP, slika 6.21. Svaki pravougaonik na shemi predstavlja jednu relaciju (tabelu) BP, dok linije predstavljaju puteve prostiranja primarnog kljua, odnosno ogranienja stranog kljua. Za ovo prevoenje se moe koristiti odgovarajui CASE alat, npr. Database Design Transformer (Designer 2000, ORACLE). Ovaj alat na osnovu konceptualne sheme BP, opisane u rjeniku podataka, generie prvu verziju relacione sheme BP, iji opis e se, takoe, nalaziti u rjeniku. Tako integrisana relaciona shema se dorauje odgovarajuim editorom, npr. Design Editor (Designer 2000, ORACLE). Izgled korisnikog interfejsa za Design Editor/Server Model, zajedno sa izvodom iz jednog dijagrama relacione sheme, je prikazan na slici 6.22.
121
Slika 6.21. Dijagram implementacione sheme aplikacije Komercijalni poslovi. Na osnovu implementacione sheme BP se automatski generie ORACLE/SQL (ili ANSI/SQL) opis sheme BP, koji treba implementirati na odgovarajuem serveru BP. Implementaciona shema slui, takoe, kao osnova za modeliranje programske specifikacije modula i samo generisanje programskih modula, ta je detaljnije opisano u taki 10.7. Programska specifikacija modula za interaktivni rad sa bazom podataka, kreiranje izvjetaja, grafikonski prikaz podataka ili bibliotekog modula, se mogu oblikovati odgovarajuim CASE alatom, npr. Design Editor/Modules (Designer 2000, ORACLE), slika 6.23. Pomou istog alata se formira struktura ekranskih formi aplikacije i obezbjeuje meusobno povezivanje programskih modula, sa mogunou prenosa podataka izmeu modula.
122
Slika 6.22. Ekranska forma CASE alata Design Editor/Server Model (Designer 2000, ORACLE).
Slika 6.23. Ekranska forma CASE alata Design Editor/Modules (Designer 2000, ORACLE).
123
7. Modeliranje dogaaja
7.1. Modeliranje procesa voeno dogaajima
Dogaaj je zgoda ili zbivanje u sistemu koja vodi ili pokree procese sistema. Sm dogaaj nije proces, nego okida procesa koji se njime pokree. Primjer: Kupac dostavom narudbe pokree proces provjere da li se radi o narudbi postojeeg ili novog kupca, proces stvaranja podataka o narudbi i stavkama narudbe, provjeru prethodnih zaduenja kupca, provjeru stanja skladita, itd. Dogaaj moe biti vanjski, vremenski i unutranji. Vanjski dogaaji se pokreu od strane vanjskih entiteta, koji zahtijevaju informaciju ili auriranje podataka (ulazni tokovi podataka). Imenuje se tako da naziv sadri naziv vanjskog entiteta, npr. zahtjev za upis studenta ili zaprimanje narudbe kupca. Vremenski dogaaji su vremenski uslovljeni, npr. rok, uestalost (ulazni upravljaki tokovi). Imenuju se tako da naziv sadri vremensku oznaku, npr. istek roka plaanja rauna, mjeseni obraun plata, zakljuivanje ispitnog roka i slino. Unutranji dogaaji su dogaaji stanja, odnosno posljedica prelaza sistema iz jednog stanja u drugo na takav nain da to zahtjeva obradu (ulazni upravljaki tokovi), npr. isporuka robe sa skladita zahtijeva naruivanje nove robe. Raspodjela dogaaja vezanih za projektovanje IS: 1. Izrada dijagrama konteksta sistema, postavljanje poetnog dometa projekta; 2. Izrada dijagrama funkcionalne dekompozicije, podjela sistema u logike podsisteme i/ili funkcije; 3. Izrada popisa dogaaja i odziva, utvrivanje poslovnih dogaaja na koje sistem mora odgovoriti. Elementi popisa su dogaaj, ulaz i izlaz; 4. Izrada dijagrama dekompozicije dogaaja, dodavanje procesa za rukovanje dogaajima. Dodaje se po jedan proces za svaki utvreni dogaaj; 5. Izrada dijagrama dogaaja, odnosno razrada procesa za obradu dogaaja. Izrauje se po jedan dijagram za svaki dogaaj; 6. Izrada dijagrama sistema, odnosno udruivanjem dijagrama dogaaja; 7. Izrada primitivnih dijagrama. Razrada dijagramom toka podataka koji sadri osnovne procese, spremita i tokove za svaki pojedini dogaaj. Opti prikaz dijagrama sistema izraen modeliranjem procesa voenim dogaajima prikazan je na slici 7.1.
124
Sistem
Sistem Funkcija 1 Funkcija n Dogaaj n-2 Dogaaj n-1 Dogaaj n
Funkcija 2
Dogaaj 1
Dogaaj 2
Dogaaj 3
Dogaaj 4
Dogaaj 5
Dogaaj 1
Dogaaj 5
Dogaaj n
Slika 7.1. Primjer modeliranja procesa voeno dogaajima.
7.2. Matrica entiteti/dogaaji (Entity/Event Matrix)

Matrica entiteti/dogaaji omoguava pogled na sistem usmjeren dogaajima. Matrica sadri dogaaje (redovi) i entitete (stupci). Elementi koji prikazuju uinak dogaaja na entitete su: stvaranje C (reate), itanje - R (read) (u nekim metodama se ne biljei), auriranje - U (update) ili M (odify), brisanje - D (elete).
Zavretak je kada se ostvari da svaki dogaaj ima uinak na barem jedan entitet, a svaki entitet mora imati dogaaj koji ga stvara i brie.
125
Pojednostavnjeni primjer matrice dogaaj/entitet za rezervaciju sobe u hotelu Proljee, prikazan je na slici 7.2.
Slika 7.2. Primjer matrice dogaaj/entitet.
7.2.1. Generisanje matrica CASE alatima

Generisanje matrica CASE alatima bie ilustrovano kreiranjem matrica Funkcije/Tipovi entiteta i Funkcije/ Atributi pomou Matrix Diagrammer-a iz sastava Designer-a 2000, ORACLE. Matrice Funkcije/Tipovi entiteta i Funkcije/ Atributi se projektuju tako da se u njima pojavljuju sve elementarne funkcije.
Slika 7.3. Matrica Elementarne funkcije/Tipovi entiteta.
126
Na slici 7.3 je prikazana matrica Elementarne funkcije/Tipovi entiteta za aplikaciju Komercijalni poslovi, a na slikama 7.4 do 7.6 su prikazane matrice Elementarne funkcije/Atributi, za tipove entiteta KUPAC, SKLADISTE i ROBA za istu aplikaciju. Naini upotrebe tipa entiteta u zavisnosti od funkcije, kod matrice Funkcije/Tipovi entiteta, mogu biti: Create (C), sa znaenjem da je zadatak funkcije formiranje nove pojave posmatranog tipa entiteta, Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje podataka o postojeim pojavama tipa entiteta, Update (U), sa znaenjem da je zadatak funkcije modifikacija podataka o postojeim pojavama tipa entiteta, Delete (D), sa znaenjem da je zadatak funkcije brisanje pojave tipa entiteta, Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima arhivira pojave tipa entiteta, i Other (O), sa znaenjem da funkcija ima zadatke koji prethodnim nainima upotrebe nisu pokriveni.
Slike 7.4. Matrica Elementarne funkcije/Atributi za tip entiteta KUPAC.
127
Slike 7.5. Matrica Elementarne funkcije/Atributi za tip entiteta SKLADISTE.
Slike 7.6. Matrice Elementarne funkcije/Atributi za tip entiteta ROBA. Naini upotrebe atributa tipova entiteta u zavisnosti od funkcije, kod matrice Funkcije /Atributi, mogu biti: Insert (I), sa znaenjem da je zadatak funkcije da prvi put zadaje vrijednost atributa tipa entiteta, Retrieve (R), sa znaenjem da je zadatak funkcije preuzimanje postojee vrijednost atributa tipa entiteta,
128

Update (U),sa znaenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta, Nullify (N), sa znaenjem da je zadatak funkcije omoguavanje zadavanja nula vrijednosti za atribut tipa entiteta, koji prethodno nije imao nula vrijednost, Archive (A), sa znaenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta, i Other (O), sa znaenjem da funkcija ima, u odnosu na vrijednosti atributa tipa entiteta, zadatke koji prethodnim nainima upotrebe nisu pokriveni.
7.3. Model istorije ivota entiteta (Entity Life History)

Istorijat ivota entiteta je pogled na sistem usmjeren uincima dogaaja koji uzrokuju promjene stanja. Opisuje vremenski zavisno ponaanje (jednog) entiteta, odnosno prati promjene ponaanja entiteta koji prolazi kroz sistem. Dijagram podudarnosti uinka (Effect Correspondence Diagram ECD), za opti sluaj je prikazan na slici 7.7, a za rezervaciju sobe u hotelu Proljee na slici 7.8. entitet, blok
redoslijedni redoslijedni dogaaj dogaaj (sekvenca) (sekvenca)
alternativni dogaaj (selekcija) operacije
ponovljeni dogaaj (iteracija) n o
Slika 7.7. Dijagram podudarnosti uinka za opti sluaj.
Poliuk E. Jaroslav: Projektovanje informacionih sistema rezervacija sobe
129
rezervacija, nenajavljen dolazak
potvrda rezervacije 3
opoziv rezervacije ili nedolazak
najavljeni dolazak 2
stvaranje troka
plaanje usluga
arhiviranje rezervacije 7
3 3 5 6 poveanje troka 4
privremena rezervacija 1
dolazak gosta
opoziv rezervacije 3
nedolazak gosta 3
1. Kreirati rezervaciju 2. Zauzeti sobu 3. Aurirati status rezervacije 4. Kreirati zaduenje 5. Ponititi zaduenje 6. Osloboditi sobu 7. Obrisati podatke o rezervaciji
Slika 7.8. Dijagram podudarnosti uinka za rezervaciju sobe u hotelu Proljee.
7.4. Dijagram prelaza stanja (State Transition Diagram (STD))

Dijagram prelaza stanja se zasniva na ideji maine sa konanim brojem stanja, hipotetikom mehanizmu koji u nekom trenutku moe biti u jednom od konano mnogo diskretnih stanja. Predstavljaju grafiki prikaz promjena stanja, tj vremenski zavisnog ponaanja sistema. Elementi prikaza su: stanje, kumulativni rezultat ponaanja nekog objekta (pravougaonik, krug ili elipsa), prelaz, promjena stanja uzrokovana nekim dogaajem (usmjerena linija od jednog stanja prema drugom) i dogaaj, uslov promjene stanja i akcija koja se obavlja (opis linije prelaza oblika dogaaj/akcija). Dijagram prelaza stanja najee opisuje vremenski zavisno ponaanje itavog sistema. Manji sistemi se mogu prikazati jednim dijagramom, dok vei sistemi se razlau slino dijagramima toka podataka, pri emu stanje na nekom nivou postaje poetno stanje dijagrama na niom nivou. Primjenjuju se kod razvoja sistema za rad u stvarnom vremenu (real-time system), jezike analize (parsing) i dizajna korisnikog interfejsa. Dijagrami prelaza stanja sistema za rad u stvarnom vremenu se razlikuju po tome to sadre posebno stanje
130
"besposlen". Na slici 7.9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljee ili Bankomata banke Montenegro, na kome su naglaena stanja ekanje.
prazni hod (idle)

neispravna kartica/ Neispravna
kartica izvaena/ Umetnite
ispravna kartica/ Izaberite
ekanje na vaenje kartice

izabran Kraj/ Hvala, dovienja
ekanje na izbor
obavljen odabir/ Pokupite izvaeno/ Jo neto?
natoeno (izbrojano) Slika 7.9. Dijagram prelaza stanja Sokomata hotela Proljee ili Bankomata banke Montenegro.
7.5. Mape dijaloga

Korisniki interfejs u mnogim aplikacijama se moe promatrati kao konani automat. Jedan element interfejsa (odabira, radna povrina, komandna linija ili dijalog prozor) moe biti aktivan u odreenom trenutku. Korisnik moe doi do ogranienog broja drugih elemenata u zavisnosti o akcijama koje preduzima. Broj putanji kojima korisnik moe mijenjati dijaloge je obino vrlo velik, ali je konaan, i mogunosti su, najee, poznate. Mape dijaloga prikazuju sistem na visokom nivou apstrakcije. Prikazuju elemente dijaloga u sistemu i mogunost navigacije izmeu njih, ali nita ne govore o dizajnu ekranske forme. Korisnici i razvojni tim mogu zajedniki razmatrati dijalog mape kako bi postigli zajedniki stav o tome kakva treba biti korisnikova interakcija sa sistemom kako bi se izvrio odreeni zadatak.
131
Dijalog mape su, takoe, korisne kod modeliranja vizuelne arhitekture web sjedita, pa se ponekad tako i nazivaju (eng. site maps). Navigacioni linkovi u sjeditu pojavljuju se kao tranzicije na dijalog mapi. Koristi se notacija dijagrama prijelaza stanja. Uslov koji pokree korisniku navigaciju prikazan je kao tekst na strelicama. Postoji nekoliko vrsta pokretakih uslova: korisnika akcija, kao to je pritisak tastera ili klik na link ili dugme dijalog prozora, vrijednost podataka, kao to je pogrean unos koji pokree pojavljivanje poruke o greci, sistemski uslov, kao to je signal da je pisa ostao bez papira i kombinacija navedenih, kao to je kucanje opcije iz ekranske forme i pritisak na taster Enter. Radi pojednostavnjenja mogu se izostaviti neke opte funkcije, npr. pritiskanje tastera F1 da bi se dobila pomo ili standardni navigacijski linkovi koji se pojavljuju na svakoj stranici. Dijalog mape mogu prikazati alternativne putove kao grane koje odstupaju od uobiajenog puta, npr. uobiajeni put bi bio naruiti hemikaliju od vanjskog dobavljaa, a alternativno se hemikalija moe dobiti iz zaliha hemijske laboratorije. Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom nivou. Konkretna ugradnja moe biti drugaija. Primjer: Korisnik inicira model koritenja odabirom opcije "zatrai hemikaliju" iz glavnog odabiraa. Polazna taka za ovaj model koritenja je popis traenih hemikalija koji se naziva "Trenutna lista zahtjeva".
132
8. Inenjerski pristup izgradnji IS

8.1. Uvod
Razlog za uvoenje posebne discipline u raunarstvu sa nazivom softversko inenjerstvo je prvi uzrok pojave softverska krize, odnosno projektovanje IS bez primjene odgovarajue metodologije. Pojam softverskog inenjerstva se javlja poetkom 70-ih godina, prije pojave pojma CASE proizvoda. Ideja softverskog inenjerstva je bila uvoenje metodolokog, inenjerskog pristupa pri razvoju programskih proizvoda sa ciljem da se u zadanim vremenskim rokovima, preciznom primjenom odgovarajuih tehnika, doe kako do dovoljno kvalitetnog projekta programskog proizvoda, tako i do dovoljno kvalitetnog samog programskog proizvoda. Okosnicu takvog koncepta predstavljaju metodologija ivotnog ciklusa i strukturirani pristup razvoju programskog proizvoda. Metodologija ivotnog ciklusa polazi od injenice da ivotni ciklus svakog programskog proizvoda, odnosno ivotni vijek, prolazi kroz iste faze. To znai da i razvoj programskog proizvoda treba da prati faznu logiku ivotnog ciklusa. Faze ivotnog ciklusa programskog proizvoda su: strategija (strateko planiranje razvoja programskog proizvoda), snimanje i analiza (detaljna analiza ponaanja realnog sistema, korisnikih zahtjeva i konceptualno projektovanje programskog proizvoda), projektovanje (oblikovanje izvoakog implementacionog projekta programskog proizvoda), programiranje (realizacija programskog proizvoda), uvoenje u upotrebu i eksploatacija sa odravanjem. Bitno je da sve nabrojane faze prati aktivnost izrade odgovarajue projektne, odnosno izvoake dokumentacije, dok se u fazi programiranja izrauju i uputstva za upotrebu aplikacija, koja predstavljaju sastavni dio programskog proizvoda. Strukturirani pristup se primjenjuje u okviru faza snimanja, analize, projektovanja i programiranja programskog proizvoda. Predstavlja optu tehniku koja se zasniva na slijedeim principima: postepeno dekomponovanje sloenog sistema na podsisteme manje sloenosti, nezavisnu izgradnju podsistema, integraciju nezavisno izgraenih komponenti u jedinstvenu cjelinu (programski proizvod, informacioni sistem) i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.
133
8.2. Programsko inenjerstvo (Software Engineering)

Programski proizvodi (software) se sastoji od: programske podrke, dijela raunarskog sistema koji nema fizikih dimenzija, svih vrsta programa i programskih jezika, preporuka, itd. Raunarski programi, podaci i dokumentacija imaju slijedea svojstva: sloenost, podlonost grekama, ne troe se, teko se mjere, stare, dugo se koriste i lako se kopiraju (zajedno sa grekama). Raunarska aplikacija je namjenski program, primjenjeni programski proizvod (oprema), odnosno raunarom podrano rjeenje jednog ili vie poslovnih problema ili potreba. Informacioni sistem uobiajeno sadri jednu ili vie raunarskih aplikacija. Informaciona tehnologija (IT) je bilo koji oblik tehnologije, tj. oprema ili tehnika, koju ljudi koriste za upravljanje informacijama (obavjetenjima). U dananje vrijeme obuhvata raunarsku tehnologiju (hardver i softver) i telekomunikacionu tehnologiju (mree za prenos podataka, slika i zvuka). Programsko inenjerstvo (softverski inenjering) ima vie definicija. Bie navedene neke od njih: 1. Programsko inenjerstvo je inenjerska disciplina koja obuhvata sve aspekte izrade programske opreme [Sommerville, 2000]; 2. Programsko inenjerstvo je inenjerska disciplina koja se bavi praktinim problemima razvoja velikih programskih sistema [Sommerville, 1992]; 3. Programsko inenjerstvo ... ima za cilj ekonomian razvoj visoko- kvalitetne programske opreme [Pagel & Six, 1994]. Podruje programskog inenjerstva su poslovi kojima se oblikuje i razvija programska oprema, kao i sistemska primjena prikladnih alata i tehnika na itav proces razvoja programske opreme. Sastoji se od analiziranja i blieg opisivanja (specifikacije) postupaka koje treba programirati, izrade programa, tehnika testiranja (provjere valjanosti), pisanja dokumentacije, probnih izvedbi programa, analize vremenskog izvoenja, itd. Razvoj postupaka (metoda) programskog inenjerstva se moe hronoloki prikazati: godina 1968: Prva NATO konferencija o programskom inenjerstvu, posveena problemima razvoja programske podrke (softverska kriza), kraj '60-ih, rane 70-te: strukturirano programiranje disciplinovano programiranje zasnovano na prikladnoj sintaksi proceduralnih jezika, sredinom 70-ih: strukturirani dizajn - izrada hijerarhijskih sistema modularne programske opreme, raunarom podrana dokumentacija,
134
kasne 70-te, rane '80-te: strukturirana analiza - odvajanje logikog opisa od fizikog opisa (informacionog) sistema, oblikovanje podataka, rane '80-te: CASE alati; izrada prototipova, sredinom '80-ih: informaciono inenjerstvo, zdrueni razvoj aplikacija (Joint Application Development), kasne '80-te: brzi razvoj aplikacija (Rapid Application Development), rane 90-te: objektno usmjereni razvoj, kasne 90-te, rane 2000-te: automatizacija informatikih tehnologija, ... . Raunarsku osnovu (Computing Fundamentals) softverskog inenjeringa sainjavaju: algoritmi i strukture podataka (Algorithms and Data Structures), arhitektura raunara (Computer Architecture), matematika podrka (Mathematical Foundations), operativni sistemi (Operating Systems) i programski jezici (Programming Languages). Proizvodi softverskog inenjeringa (Software Product Engineering) su: zahtjevi softverskog inenjeringa (Software Requirements Engineering), softverski dizajn (Software Design), kodiranje softvera (Software Coding), testiranje softvera (Software Testing), rad softvera i odravanje (Software Operation and Maintenance). Upravljanje softverom (Software Management) u slijedeim segmentima: softversko upravljanje projektom (Software Project Management), softversko upravljanje odluivanjem (Software Risk Management), softversko upravljanje kvalitetom (Software Quality Management), softversko upravljanje konfiguracijom (Software Configuration Manage-ment), softversko upravljanje procesima (Software Process Management) i softverska akvizicija (Software Acquisition).
8.3. Informaciono inenjerstvo (Information Engineering)

Informaciono inenjerstvo se bavi inenjerskim pristupom izgradnji IS i upravljanju informacijama. IS mora biti projektovan, kao to se to ini sa drugim proizvodima. Razvoju IS treba pristupiti kao strukturiranom i planiranom procesu podranom raunarom. U procesu razvoja IS mora biti zastupljena sistemska primjena prikladnog skupa metoda, tehnika i alata. Metoda je smiljen i organizovan skup procedura izrade (modela, softvera), uz koritenje dobro definisane notacije. Sugerie proces obavljanja i nain dokumentovanja, a, takoe, definie primjenu tehnika i njihovo povezivanje (npr. ERD, IDEF, DFD). Tehnika je nain provoenja metode. Definie nain provoenja odreenog postupka i dokumentovanja rezultata tog postupka, odnosno nain na koji se provodi odreena aktivnost razvojnog procesa.
135
Softverski alati (tool) je instrument, sredstvo koje se koristi u razvoju IS. Informacionu tehnologiju (Information Technology) sainjavaju: arhitektura kompjutera (Computer Architectures), algoritmi i strukture podataka (Algorithms and Data Structures), programski jezici (Programming Languages)), operativni sistemi (Operating Systems), telekomunikacije (Telecommunications), baze podataka (Database) i vjetaka inteligencija (Artificial Intelligence). Organizacioni i upravljaki koncepti (Organizational and Management Concepts) informacione tehnologije su: opta teorija organizacije (General Organization Theory), upravljaki informacioni sistemi (Information Systems Management), teorija odluivanja (Decision Theory), organizacioni postupci (Organizational Behavior), upravljanje procesima za promjene (Managing the Process of Change), pravni i etiki aspekti IS (Legal and Ethical Aspects of IS), profesionalizam (Professionalism) i interdisciplinarno znanje (Interpersonal Skills). Teoriju i razvoj sistema (Theory and Development of Systems) sainjavaju: sistemski i informacioni koncepti (Systems and Information Concepts), pristup razvoju sistema (Approaches to Systems Development), koncepti razvoja sistema i metodologije (Systems Development Concepts and Methodologies), alati za razvoj sistema i tehnike (Systems Development Tools and Techniques), planiranje aplikacija (Application Planning), upravljanje odluivanjem (Risk Management), upravljanje projektom (Project Management), informaciona i poslovna analiza (Information and Business Analysis), informacioni sistemski dizajn (Information Systems Design), implementacija sistema i strategija testiranja (Systems Implementation and Testing Strategies), rad sistema i odravanje (Systems Operation and Maintenance) i razvoj posebnih vrsta informacionih sistema (Systems Development for Specific Types of Information Systems).
8.4. Sistemsko inenjerstvo (System Engineering)

Nema opte prihvaene definicije sistemskog inenjerstva. Ipak, za sistemsko inenjerstvo se moe rei da: 1. Sagledava sistem kao cjelinu pristupom sa vrha prema dolje (top-down); 2. Upravlja ciklusom koji sadri sve faze od dizajna do odumiranja; 3. Osigurava djelotvornost i (dovoljno) rano donoenje odluka definisanjem zahtjeva i njihovim povezivanjem sa odgovarajuim oblikovanjem; 4. Predstavlja interdisciplinarni i/ili timski pristup oblikovanju i razvoju, kojim se osigurava njihova djelotvornost i funkcionalnost.
136
8.5. CASE proizvodi

Nepostojanje odgovarajuih softverskih alata za podrku razvoja softverskih proizvoda, kao i kompleksnost zadataka i tehnika koje se u metodologiji ivotnog ciklusa i u strukturiranom pristupu primjenjuju, odnosno drugi i trei uzrok softverske krize, predstavlja motiv za pojavu CASE proizvoda. Skraenica CASE je akronim naziva na engleskom jeziku Computer Aided Software Engineering ili Computer Aided System Engineering (programsko/sistemsko inenjerstvo podrano raunarom), dok je skraenica CAISE akronim naziva Computer Aided Information System Engineering (informaciono/sistemsko inenjerstvo podrano raunarom). Pod CASE proizvodom se podrazumjeva bilo koji programski proizvod namjenjen za podrku, ili automatizaciju, barem jednog zadatka u okviru ivotnog ciklusa drugog programskog proizvoda, ili je namjenjen za kompletnu podrku projektovanju i realizaciji drugog programskog proizvoda. Osnovni ciljevi primjene CASE proizvoda su: obezbjeenje zadovoljavajueg kvaliteta projekta i projektne dokumentacije, obezbjeenje zadovoljavajueg kvaliteta samog programskog proizvoda, poveanje produktivnosti projektanata i programera, skraenje vremena projektovanja i realizacije programskog proizvoda, obezbjeenje jednostavnog i jeftinog odravanja programskog proizvoda. Primjena strukturiranog pristupa i metodologije ivotnog ciklusa znae upotrebu veeg broja manje ili vie formalnih tehnika i crtanja razliitih dijagrama i matrica zavisnosti na razliitim nivoima detaljnosti. Pri tome, izmjena na jednom nivou detaljnosti esto zahtjeva izmjene i na drugim nivoima detaljnost. Ukoliko je rije o projektu veeg obima, runo projektovanje i sprovoenje ovih izmjena, odravanje konzistentne projektne dokumentacije i kontrola kompleksnosti projekta postaju naporan posao, sa neizvjesnim ishodom. Tako, na primjer, o manuelnom projektovanju BP ima smisla govoriti samo ako broj tipova entiteta i veza konceptualne sheme ne prelazi nekoliko desetina, odnosno ako broj identifikovanih atributa ne prelazi sto. Kada veliina konceptualne sheme prelazi ove granice, pokazuje se da problem, zbog kompleksnosti prouzrokovane obimom, prevazilazi ovjekove moi percepcije i koncentracije. Tada vrijeme i napor, potrebni za izradu projekta, postaju teko prihvatljivi, a kvalitet rezultata nepredvidiv. U projektu se javljaju greke u vidu: sinonima, homonima, protivrjenih ogranienja i druge. Greke uinjene u ranijim fazama projekta se uoavaju tek u kasnijim fazama, kada ih je tee otkloniti. Iterativno vraanje na ranije faze projekta u cilju otklanjanja greaka, moe dovesti do pojave novih greaka, ije otklanjanje zahtjeva dodatni napor. Strukturirani pristup zahtjeva od projektanta i programera da posjeduju visoki nivo ekspertnog znanja iz oblasti softverskog inenjerstva i zadovoljavajui nivo znanja iz predmetne oblasti za koju se pravi programski proizvod, to u praksi ne mora biti uvijek obezbjeeno.
137
U skladu sa navedenim razlozima, od CASE proizvoda se oekuje da obezbjede to vii stepen automatizacije kada se obavljaju slijedei zadaci: izrada dokumentacije, izrada dijagrama i matrica, konceptualno i implementaciono projektovanje shema baza podataka, projektovanje programskih proizvoda, izrada (generisanje) programskih proizvoda, obavljanje izmjena na programskim proizvodima, integracija parcijalnih rezultata projektovanja u jedinstvenu cjelinu, kontrola funkcionalnosti, konzistentnosti, kompletnosti i kvaliteta projekta, itd. Da bi zadovoljili navedene zahtjeve, CASE proizvodi su organizovani tako da rade nad jedinstvenom BP, koja se naziva Rjenik podataka CASE proizvoda. Rjenik sadri podatke o svim konceptima (objektima, vezama, dijagramima, matricama, dokumentaciji, itd.), definisanim u okviru jednog, ili vie projekata, koji se smjetaju u rjenik. Svi pojedinani alati jednog CASE proizvoda koriste i smjetaju podatke u isti rjenik podataka, ta je prikazano na slici 8.1.
Alat za modeliranje dijagrama toka podataka Alat za modeliranje ER dijagrama
Alat za modeliranje programskih specifikacija
Rjenik podataka
Alat za modeliranje matrica
Generatori koda
Slika 8.1. Meusobni odnos razliitih CASE alata i jedinstvenog rjenika podataka. Mogu se sresti razliite klasifikacije CASE proizvoda. Jedna, uobiajena i ne suvie selektivna, je izvrena prema fazama ivotnog ciklusa koje CASE proizvod pokriva. Prema toj klasifikaciji, razlikuju se:
138
1. Projektantski CASE proizvodi, koji su namjenjeni za podrku prve (gornje) tri faze ivotnog ciklusa, odnosno za podrku projektovanju programskog proizvoda (strategija, snimanje i analiza, projektovanje); 2. Programerski CASE proizvodi, namjenjeni za podrku posljednje (donje) tri faze ivotnog ciklusa, odnosno za podrku realizacije programskog proizvoda (programiranje, uvoenje u upotrebu, eksploatacija i odravanje); 3. Integrisani CASE proizvodi, tj. integrisani projektantski i programerski CASE proizvodi, namjenjeni da podre svih est faza ivotnog ciklusa, odnosno kompletan ivot programskog proizvoda.
8.5.1. Projektantski CASE proizvodi (Upper CASE, Front-End CASE)

Za podrku prve tri faze ivotnog ciklusa koriste se projektantski CASE proizvodi. Kod projektovanja IS, CASE proizvod koji podrava fazu strategije, treba da sadri alate za podrku: planiranja projekta (izbora metodologije i tehnika razvoja IS, naina i standarda za primjenu izabrane metodologije i tehnika), upravljanja projektom (detaljnog planiranja i izdavanja zadataka, kao i vremenskog terminiranja projekta), planiranja i upravljanja resursima (materijalnim, kadrovskim i finansijskim), praenja realizacije projekta i sprovoenje postupaka kontrole kvaliteta. Da bi podrao faze snimanja i analize, CASE proizvod treba da sadri alate za izradu: strukturiranih modela sistema (model funkcionalne, organizacione i prostorne strukture), modela procesa koji se odvijaju u realnom sistemu, dijagrama toka podataka, konceptualne sheme BP i matrica, kojima se iskazuju meuzavisnosti izmeu elemenata konceptualne sheme BP, kao i funkcionalne, organizacione i prostorne strukture sistema. Kada je u pitanju faza projektovanja, CASE proizvod moe da sadri alate za: prevoenje konceptualne sheme BP u implementacionu shemu, implementaciono projektovanje sheme BP, generisanje programskih specifikacija aplikacija (struktura menia, opisa ekranskih ili tampanih formi, podshema i standardnih procedura za upite i auriranje BP) i implementaciono projektovanje programskih specifikacija aplikacija. Implementaciono projektovanje sheme BP se moe sprovoditi neposredno, bez prethodne izrade i prevoenja konceptualne sheme, ili putem modifikacija prevedene konceptualne sheme. Implementaciono projektovanje programskih specifikacija aplikacija se moe sprovoditi neposredno, bez prethodnog generisanja programskih specifikacija, ili putem modifikacija prethodno generisanih programskih specifikacija. Pri razvoju savremenih projektantskih CASE proizvoda, sve je naglaeniji zahtjev da CASE sadri inteligentne alate i alate koji u sebi ukljuuju elemente ekspertnog znanja. To znai da alati treba da primoravaju projektanta na potovanje formalnih
139
pravila upotrebe odgovarajue tehnike, koji dani alat podrava. Na taj nain projektant dobija tehniku pomo u radu. Pored toga, na viem nivou, oekuje se da alat prui projektantu i ekspertnu, tj. intelektualnu, pomo u primjeni odgovarajue tehnike. Takva pomo se ogleda u mogunosti da sam alat prua odgovarajua projektantska rjeenja ili da je u stanju da analizira, vrednuje i ocjenjuje rjeenja, koja je napravio projektant softverskog proizvoda.
8.5.2. Programerski CASE proizvodi (Lower CASE, Back-End CASE)

U programerske CASE proizvode se najee svrstavaju generatori koda. Generatori koda su u mogunosti da, na osnovu opisa implementacione sheme BP, generiu DDL opis sheme BP za konkretni sistem za upravljanje BP, ili na osnovu programskih specifikacija generiu 4GL programe aplikacija IS. U smislu poveanja nivoa deklarativnosti, preglednosti i lakoe programiranja jezici 4. generacije (4GL) predstavljaju dalju nadogradnju jezika 3. generacije. Teko je dati preciznu definiciju jezika 4. generacije, jer on podrazumjeva iroki spektar programerskih ili korisnikih alata, razliitih namjena i mogunosti, od jednostavnih alata do razvijenih jezika. Zbog toga se esto govori o pojmu okruenja 4. generacije. Na slici 8.2 su prikazani mogui elementi jednog 4GL okruenja. Treba uoiti da u takvo okruenje ulaze i jezici 3. generacije, to znai da ova vrsta jezika i dalje ima svoje mjesto u postupku realizacije programskog proizvoda. Alati za programiranje logike aplikacija Generatori i editori ekranskih menia Generatori i editori ekranskih formi
Relacioni upitni jezik SQL
Generatori i editori izvjetaja
Programski jezici 3. generacije Rjenik podataka
Generatori i editori upita
Slika 8.2. Mogui elementi jednog 4GL okruenja.
140
Uoava se da su svi alati iz okruenja 4. generacije, iz istih razloga kao i CASE proizvodi, oslonjeni na jedinstveni rjenik podataka. ta vie, nastoji se da ovi alati budu integrisani sa CASE proizvodima po pitanju koritenja zajednikog rjenika podataka, ime se obezbjeuje jedinstveno razvojno okruenje programskih proizvoda. Da se prevazie neproduktivno i dugotrajno programiranje uz upotrebu jezika 3. generacije razvijeni su generatori koda i 4GL okruenje. Neposredni pozitivni efekti primjene generatora koda i 4GL okruenja se ogledaju u ubrzanju i olakanju procesa izrade programskog proizvoda, kao i smanjenju trokova odravanja aplikacija, budui da je olakano otkrivanje, pronalaenje i ispravljanje uoenih greaka. Posredni pozitivan efekat je mogunost primjene prototipskog pristupa razvoju programskih proizvoda, o emu je detaljnije bilo govora u podtaki 2.4.3. Prisutni su i negativni efekti primjene generatora koda i jezika 4. generacije. Jezik 4. generacije ili generisana aplikacija pomou jezika 4. generacije je, na istoj hardverskoj platformi, sporija od odgovarajue aplikacije razvijene uz pomo jezika 3. generacije. Funkcionalnost, odnosno irina primjene, generatora koda i 4GL okruenja je manja od funkcionalnosti jezika 3. generacije. Uoava se da ovi nedostaci predstavljaju kontinuitet trendova koji se odnose i na uvoenje i upotrebu jezika 3. generacije. Prednosti i nedostaci upotrebe generatora koda i 4GL okruenja ukazuju da se pravilnim izborom generatora koda i 4GL okruenja, jezika 3. generacije i naina povezivanja sa 4GL okruenjem i odgovarajue (jae) hardverske platforme, mogu obezbjediti sve prednosti upotrebe generatora koda i 4GL okruenja, uz ouvanje dovoljno dobrih performansi izvravanja razvijene aplikacije i dovoljno dobre funkcionalnosti za rad. To znai da se mogu postii velike utede pri realizaciji i odravanju aplikacija IS dodatnim ulaganjima u hardver i alate za razvoj aplikacija.
Uloeni napor, potreban za realizaciju aplikacije
Sloenost aplikacije
Slika 8.3. Problematika funkcionalnosti generatora koda, 4GL okruenja i jezika 3. generacije [Mogin et al. 2000].
141
Problematika funkcionalnosti generatora koda, 4GL okruenja i jezika 3. generacije ilustrovana je dijagramom na slici 8.3. Uoava se da se manje sloene aplikacije mogu neposredno dobiti upotrebom generatora koda. Za sloenije aplikacije je, nakon generisanja koda potrebno izvriti dodatna prilagoavanja, upotrebom alata 4. generacije, dok se vrlo sloeni i dominantno proceduralni dijelovi aplikacija mogu uspjeno realizovati samo upotrebom jezika 3. generacije. Iz navedenih razloga je prethodno i naglaena potreba kombinovane upotrebe alata 4. generacije i jezika 3. generacije. Upotreba generatora koda ima jo jedan nedostatak. Ponovno generisanje aplikacije, nakon ve izvrenog prilagoavanja generisanog koda pomou alata 4. generacije, moe znaiti unitavanje prethodno izvrenih prilagoavanja. Savremeni trendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublai na dva naina. Prvi nain predvia pomjeranje granice upotrebljivosti generatora koda, tako da se pomou generatora koda mogu izgraditi i sloenije aplikacije. Cilj je da se pree granica od 80% ukupno generisanog koda, koji bi bez daljih dorada bio spreman za upotrebu. Drugi nain se zasniva na sistematinom evidentiranju doraenih dijelova generisanog koda u okviru rjenika podataka, tako da svako slijedee regenerisanje uzme u obzir i postojea prilagoenja koda.
8.5.3. Integrisani CASE proizvodi (Integrated CASE (ICASE))

Integrisani CASE proizvodi pokrivaju sve faze razvoja, a sadre i dodatne module za povratno (reverzno) inenjerstvo, nadzor i upravljanje izvedbom, te osiguranje kvaliteta IS. Potpuno integrirano CASE okruenje automatizuje izradu modela poslovnog sistema, planiranje razvoja IS, kao i izgradnju i primjenu IS. Integracija programskih proizvoda se ostvaruje usvajanjem pravila odreene metode razvoja, upotrebom zajednikog rjenika podataka i zajednikog interfejsa, te automatizovanim proslijeivanjem informacija iz jedne faze razvoja u drugu. Smatra se da je samo 25 do 30% specifikacija prenosivo iz projektantskog (gornjeg) u programerski (donji) CASE, to predstavlja ozbiljnu prepreku potpuno automatizovanoj izradi programskih proizvoda.
8.5.4. Projektovanje shema baze podataka pomou CASE proizvoda

Za projektovanje shema baza podataka postoje samostalni CASE proizvodi. Takvi proizvodi, uglavnom, pripadaju klasi projektantskih CASE proizvoda. Ukoliko sadre i generatore opisa sheme BP, prilagoene konkretnim SUBP, tada pripadaju i klasi programerskih CASE proizvoda. Integrisani CASE proizvodi, koji su nomjenjeni za razvoj IS, obavezno sadre alate za projektovanje konceptualne, implementacione i interne sheme BP.
142
Savremeni CASE proizvodi za projektovanje konceptualne, implementacione i interne sheme najee omoguavaju projektovanje konceptualne sheme u modelu entiteti veze (ER model) i automatsko prevoenje ER konceptualne u implementacionu shemu, zasnovanu na relacionom modelu podataka. Pojedini CASE proizvodi omoguavaju i projektovanje fizike organizacije relacione BP. Rezultat ovakvog projektovanja je automatski generisan opis implementacione i interne sheme u relacionom upitnom jeziku SQL. CASE proizvod za projektovanje ER konceptualne sheme se sastoji od grafikog editora za poluautomatsko crtanje ER dijagrama i analizatora konzistentnosti nacrtanih shema. Grafiki editor sadri predefinisane standardne geometrijske simbole koncepata ER modela. Crtanje ER dijagrama se obavlja biranjem simbola i njihovim povezivanjem, u skladu sa pravilima strukturiranja ER dijagrama. Analizator konzistentnosti je namjenjen za provjeru usaglaenosti nacrtanog ER dijagrama sa pravilima strukturiranja, kao i pronalaenje potencijalnih sinonima i homonima. Mogunost definisanja funkcionalnih zavisnosti posjeduju samo pojedini CASE proizvodi, najee u skupu tipa entiteta ili tipa veze. Nakon definisanja skupa funkcionalnih zavisnosti, CASE proizvod vri normalizaciju relacija. Ukoliko rezultat normalizacije pokae da posmatrani tip entiteta ili tip veze treba dekomponovati, CASE proizvod tu izmjenu u ER dijagramu vri automatski. Meutim, u praksi se esto deava da ovako nacrtan ER dijagram ne predstavlja lako razumljivu osnovu za komunikaciju izmeu projektanta i korisnika. Krajnji korisnik je, prvenstveno, zainteresovan da pomou raunara olaka, ubrza i povea kvalitet obavljanja svojih radnih zadataka i nije spreman da se udubljuje u analizu kvaliteta konceptualne sheme, koja je predstavljena, za njega, apstraktnom i stranom notacijom. Tek kada dobije gotove programe, ili njihove prototipove, korisnik moe da ocjeni da li mu rjeenje odgovara. Sa druge strane, programere interesuje podshema u implementacionom modelu podataka. Prema tome, crtanje ER dijagrama se moe posmatrati samo kao usputan, i ne ba jednostavan, korak u projektovanju implementacione sheme i, u sutini, predstavlja heuristiki postupak. Nema dokaza da paljivo projektovanje ER dijagrama, nakon prevoenja u relacioni model podataka, uvjek rezultuje u skup relacija, koje su bar u treem normalizovanom obliku (3NO). Na slikama 8.4, 8.5 i 8.6 su prikazani primjeri nekih aktuelnih CASE proizvoda. Na slici 8.4 je prikazana ekranska forma integrisanog CASE alata (ICASE) Popkin System Architect, koji podrava vie metodologija projektovanja IS (SSAD, OOAD), reverzno inenjerstvo i generisanje programskog koda. Na slici 8.5 je prikazana ekranska forma alata za oblikovanje BP CA AllFusion ERwin, koji je namjenjen za dizajn i reinnjerstvo BP, podravajui razliite notacije projektovanja (IDEF1X, IE, DM). Na slici 8.6 je prikazana ekranska forma alata za projektovanje objektno orijentisanog softvera Rational ROSE, koji podrava OO metode (UML, OMT, Booch, ).
143
Slika 8.4. Ekranska forma integrisanog CASE alata (ICASE).
Slika 8.5. Ekranska forma CASE alata za oblikovanje baza podataka.
144
Slika 8.6. Ekranska forma CASE alata za projektovanje objektno orijentisanog softvera.
8.5.5. Prikaz CASE proizvoda ORACLE/Designer 2000

Komercijalni CASE proizvod korporacije ORACLE (USA), pod nazivom ORACLE/Designer 2000, namjenjen je za podrku slijedeih faza ivotnog ciklusa: snimanje i analiza poslovnog sistema, projektovanje IS, programiranje korisnikih aplikacija, uvoenje u upotrebu i eksploatacija IS, odravanje IS. i predstavlja sveobuhvatni programski proizvod, sa znaajnom prisutnou na tritu informacione tehnologije u vrijeme pisanja ove knjige. Designer 2000 radi sa jedinstvenim rjenikom podataka (rjenik podataka programskog proizvoda Designer 2000 se na engleskom jeziku zove Repository), implementiranom u okviru ORACLE baze podataka. Projektantsko-programerske aktivnosti u okviru Designer-a 2000 se obavljaju u cjelinama, koje se nazivaju aplikativni sistemi. Aplikativni sistem moe predstavljati zaokruenu cjelinu, podsistem ili IS. Ovakvim pristupom projektovanju, IS se istovremeno razvija radom na vie aplikativnih sistema. Razvoj IS pomou vie aplikativnih sistema omoguava veu fleksibilnost u radu, prvenstveno u pogledu lakeg traenja podataka i sprovoenja
145
izmjena u okviru projekta. Takoe, olakava odravanje razliitih verzija projektne dokumentacije i zatitu sadraja rjenika podataka od brisanja, nenamjernih izmjena ili neovlatenog pristupa. Navedeni pristup ne uvodi ogranienja koja bi negativno uticala na integrisanost IS. Postoji i mogunost da se cjelokupni IS razvija putem samo jednog aplikativnog sistema. Prilikom prijavljivanja za rad sa Designer-om 2000, korisnik se odluuje za aplikativni sistem nad kojim e realizovati svoje projektantsko-programerske aktivnosti. Odgovarajua ovlatenja za rad sa izabranim aplikativnim sistemom moraju biti prethodno dodjeljena korisniku. Designer-a 2000 svoju metodologiju moe da zasnovana, kako na klasinom modelu primjene metodologije ivotnog ciklusa, tako i na bilo kojoj od kombinacija, koja ukljuuje evolutivni, inkrementalni ili zvjezdasti model primjene metodologije ivotnog ciklusa, kao i na prototipskom razvoju. Designer 2000 omoguava, takoe, i primjenu tehnika reverznog inenjerstva BP i aplikacija IS. Po svom sastavu Designer 2000 je integrisani skup programskih alata, razliite namjene, slika 8.7.
Slika 8.7. Ekranska forma ORACLE/Designer-a 2000. Za fazu strategijskog planiranja, kao i faze snimanja i analize, Designer 2000 predvia upotrebu slijedeih alata:
146
Process Modeller, koji je namjenjen za dijagramski prikaz procesa i tokova u realnom sistemu i podrku njihovog eventualnog reverznog inenjeringa, Function Hierarchy Diagramer - alat za modeliranje funkcionalne dekompozicije realnog sistema i strukture programske podrke informacionog sistema, Dataflow Diagramer - alat za modeliranje tokova podataka unutar poslovnog i informacionog sistema, putem dijagrama tokova podataka, i Entity Relationship Diagramer - alat za konceptualno modeliranje sheme baze podataka, putem dijagrama tipova entiteta i veza. Za fazu projektovanja informacionog sistema su namjenjeni slijedeci alati: Database Design Transformer, za prevoenje ER konceptualne sheme baze podataka u relacionu shemu baze podataka, Design Editor / Server Model, za projektovanje relacione, implementacione sheme baze podataka (oblikovanje shema relacija - tabela, programiranje procedura, funkcija, paketa procedura i funkcija, kao i trigera baze podataka), Application Design Transformer, za inicijalno generisanje programskih specifikacija (opisa programskih modula, podshema i strukture ekranskih formi), Design Editor / Modules, za implementaciono projektovanje programskih modula (tj. programa za interaktivno auriranje baze podataka, generisanje izvjetaja, grafiki prikaz podataka i biblioteka procedura i funkcija), kao i struktura programskih modula (ekranskih formi aplikacija), Design Editor / DB Admin, za projektovanje interne sheme baze podataka (zadavanje parametara fizike organizacije podataka), i Design Editor / Distribution, za projektovanje distribuirane sheme baze podataka. Kada su u pitanju faze: programiranja, uvoenja u upotrebu i eksploataciju i odravanje informacionog sistema, Designer 2000 je opremljen slijedeim generatorima koda: Generate Database From Server Model, za generisanje SQL opisa implementacione sheme baze podataka, Generate Database Administration Objects - generisanje SQL opisa interne sheme baze podataka, Generate Module / Forms, za generisanje programskih modula za interaktivni pristup bazi podataka, zasnovanih na jeziku IV generacije Developer 2000 / Forms, Generate Module / Reports, za generisanje programskih modula za formiranje izvjetaja, zasnovanih na jeziku IV generacije Developer 2000 / Reports,
147
Generate Module / Graphics, za generisanje programskih modula za grafiki prikaz podataka, zasnovanih na jeziku IV generacije Developer 2000 / Graphics, Generate Module / Visual Basic, za generisanje programskih modula za interaktivni pristup bazi podataka, zasnovanih na programskom jeziku Visual Basic, Generate Module / Web Server, za generisanje ORACLE WebServer programskih modula, za pristup bazi podataka preko Internet/Web servera, zasnovanih na HTML formatu, i Generate Module / Help System, za generisanje programskih modula za prezentiranje uputstava i ostalih tekstualnih informacija, zasnovanih na Forms ili Microsoft Help korisnikom interfejsu. Moe se konstatovati da je Designer 2000, u dijelu koji se odnosi na generatore koda, dosta vrsto povezan i sa ORACLE-ovim okruenjem etvrte generacije Developer 2000, u koje, izmedju ostalih, spadaju alati: Form Builder, za kreiranje interaktivnih programskih modula (koji se jos nazivaju i "forme"), Report Builder, za kreiranje programskih modula za izvjetavanje (koji se nazivaju i "izvjetaji") i Graphics Builder, za kreiranje programskih modula za grafiki prikaz podataka ("grafikona"). Pored nabrojanih, Designer 2000 posjeduje i slijedee programe, koji se svrstavaju u oblast reverznog inenjerstva: Capture Design of Database, namjenjen za reverzni inenjering implementacione ili interne sheme baze podataka, na osnovu stanja rjenika ORACLE baze podataka, kao i utvrivanje i eliminisanje razlika izmeu stanja rjenika ciljne baze podataka i rjenika Designer-a 2000, Table To Entity Retrofit, namjenjen za prevoenje implementacione sheme baze podataka u konceptualnu shemu baze podataka, prikazanu putem dijagrama tipova entiteta i veza, Capture Design of Form, namjenjen za reverzni inenjering interaktivnih programskih modula, kreiranih u okviru alata Developer 2000/Forms, Capture Design of Report, namjenjen za reverzni inenjering programskih modula za izvjetaje, kreiranih u okviru alata Developer 2000/Reports, Capture Design of Library, namjenjen za reverzni inenjering bibliotekih modula, kreiranih u okviru paketa Developer 2000, Capture Design of Visual Basic, namjenjen za reverzni inenjering interaktivnih programskih modula, kreiranih pomou alata Visual Basic, i Capture Applicatoin Logic, namjenjen za usaglaavanje implementacione specifikacije Forms modula iz Designer-a 2000 i postojeeg Forms modula iz Developer-a 2000. U skupu alata opte namjene, Designer 2000 posjeduje slijedee:
148
Repository Object Navigator, namjenjen za direktni pristup objektima u rjeniku podataka Designer-a 2000, putem hijerarhijski organizovanog navigatora objekata, Matrix Diagramer, namjenjen za izgradnju razliitih tipova matrinih dijagrama, Repository Reports, za generisanje velikog broja razliitih tipova izvjetaja, na osnovu stanja rjenika podataka Designer-a 2000, pri emu ti izvjetaji slue za sprovoenje odreenih kontrola i analiza kvaliteta projekta, ili samo kao "papirna" projektna dokumentacija, Repository Administration Utility, pomou kojeg se obavljaju administrativni zadaci nad Designer-om 2000, kao to su: instalacija i deinstalacija rjenika podataka, dodjela prava pristupa korisnicima, arhiviranje i dearhiviranje rjenika podataka, obavljanje odreenih formalnih kontrola, itd, Online Help, kao alat za prezentiranje uputstava za koritenje Designer-a 2000, i SQL Plus, za interaktivno izvravanje SQL naredbi nad ORACLE bazom podataka. Kada je u pitanju objektno orijentisani pristup razvoju informacionog sistema, u okviru Designer-a 2000 se pojavljuje alat pod nazivom: Object Database Designer, namjenjen za projektovanje dijagrama klasa objekata, prevoenje dijagrama klasa objekata u implementacionu shemu baze podataka i implementaciono i fiziko projektovanje sheme baze podataka.
8.6. Reverzno inenjerstvo

Nastanak pojma i tehnika reverznog inenjerstva je motivisan slijedeom situacijom. U mnogim organizacijama uloena je velika koliina materijalnih, finansijskih i ljudskih resursa u razvoj i eksploataciju IS. Jedan od zahtjeva, koji se postavlja prilikom prelaska na nove informacione tehnologije, jeste da se u razvoj inovirane verzije IS ne kree iz poetka. Nastoji se da se sav uloeni napor, iskustvo, postojea rjeenja i resursi to bolje iskoriste, jer je to daleko ekonominije od ponovnog projektovanja IS. Poetak reverznog inenjerstva u razvoju programskih proizvoda se vezuje za postupak runog, ili automatizovanog generisanja projektnih i programskih specifikacija, na osnovu prethodno realizovanog programskog proizvoda. Tehnike reverznog inenjerstva se koriste za ostvarivanje slijedea dva osnovna cilja. Prvi cilj je generisanje projektne i programerske dokumentacije za aktuelnu verziju programskog proizvoda, za koju prethodno takva dokumentacija nije uraena, u cilju stvaranja osnova za odravanje tekue verzije tog programskog proizvoda. Drugi cilj je
149
generisanje projektnih i programskih specifikacija programskog proizvoda u formatu "razumljivom" CASE proizvodu, pomou kojeg se eli razviti nova verzija tog programskog proizvoda. Na slici 8.8 je prikazana ekranska forma alata za reverzno inenjerstvo.
Slika 8.8. Ekranska forma CASE alata za reverzno inenjerstvo. Tehnike reverznog inenjerstva, u domenu IS, se primjenjuju za ostvarenje slijedeih zadataka: 1. Generisanje implementacionog opisa sheme BP, na osnovu nekih od slijedeih parametara: realnih podataka koji postoje u BP, stanja rjenika podataka konkretnog sistema za upravljanje bazama podataka (SUBP) pod kojim je posmatrana BP realizovana ili opisa datoteka i formata slogova u programskom kodu aplikacija tekue verzije IS (npr. u okviru SUBP ORACLE/Designer 2000 reverzni inenjering implementacione sheme BP, na osnovu stanja rjenika ORACLE baze podataka i eliminisanja razlika izmeu rjenika ciljne BP i rjenika Designer-a 2000, obavlja program Capture Design of Database); 2. Generisanje konceptualne sheme BP, na osnovu implementacione sheme baze podataka (npr. u okviru SUBP ORACLE/Designer 2000 prevoenje implementacione sheme BP u konceptualnu shemu BP obavlja program Table To Entity Retrofit); 3. Generisanje programskih specifikacija (struktura menia, ekranskih formi ili formi za izvjetaje, podshema i proceduralne logike) na osnovu programskih kodova aplikacija tekue verzije IS (npr. u okviru SUBP ORACLE /Designer
150
2000 za reverzni inenjering ekranskih formi, izvjetaja i bibliotekih modula, namjenjeni su programi Capture Design of Form, Capture Design of Report i Capture Design of Library). Izbor tehnike reverznog inenjerstva i njena automatizovana primjena u velikoj mjeri zavisi, kako od prirode konkretnog zadataka koji se rjeava, tako i od kvaliteta, tj. "informativnosti" ulazne specifikacije, na koju se tehnika reverznog inenjerstva primjenjuje. Samim tim je i kvalitet generisanog rezultata u reverznom inenjerstvu bitno odreen kvalitetom ulazne specifikacije. Ukoliko se, na primjer, tehnika reverznog inenjerstva primjenjuje za generisanje implementacione sheme BP, najbolji rezultat se, u optom sluaju, moe oekivati ukoliko se kao ulazna specifikacija koriste podaci iz rjenika podataka sistema za upravljanje bazama podataka, a najloiji ako se kao ulazna specifikacija koriste samo realni podaci iz BP. Ova konstatacija, medjutim, ne mora biti uvijek tana. Ukoliko rjenik podataka konkretnog sistema za upravljanje bazama podataka sam po sebi nije dovoljno informativan, ili se u tom rjeniku, iz nekog razloga, ne nalaze svi potrebni podaci, tada ni izlazni rezultat reverznog inenjerstva ne moe biti dobar.
151
9. Oblikovanje i arhitektura informacionog sistema

9.1. Oblikovanje (dizajn) sistema
Analiza sistema treba da d odgovor ta sistem mora da raditi. Dizajn sistema daje odgovor kako sistem treba izgraditi ili kakav sistem treba biti. Daje procjenu alternativa i detaljnu specifikaciju raunarom podranog rjeenja, odnosno tehniku specifikaciju sistema. Omoguava izradu modela za ugradnju, kojim se opisuje kako sistem radi, ta predstavlja fiziki dizajn. Moderni strukturirani dizajn je procesno usmjerena tehnika razrade velikog programa u hijerarhiju modula sa ciljem izrade programa koje je lake napraviti i odravati. Starije varijante su oblikovanje programa sa vrha nadolje (top-down program design) i strukturirano programiranje. Alternative i/ili nadopune su informaciono inenjerstvo, izrada prototipa, zajedniki dizajn aplikacija (JAD), brzi razvoj aplikacija (RAD) i objektno usmjereni dizajn.
9.1.1. Opti dizajn sistema

Opti (konceptualni) dizajn daje funkcionalne specifikacije i omoguava odabir tehnike arhitekture sistema. Daje odgovor da li je centralizirana ili distribuirana obrada i skladitenje podataka, nain izvrenja i koje se tehnologije koriste. Takoe, odreuje da li je softver nabavljen, napravljen prema zahtjevima korisnika ili mjeavina. Odreuju se i razvojni alati. Mogu se izdvojiti slijedee faze definisanja optog dizajna: Analiza i distribucija podataka, koju sainjavaju: 1. Pretvaranje konceptualnog modela podataka u logiki model (relacioni, postrelacioni, objektno-relacioni, objektni), ako pretvaranje nije ranije uinjeno; 2. Izrada dobrog modela podataka, koji mora biti jednostavan, neredundantan, elastian i prilagodljiv, kao i analiza podataka i normalizacija modela; 3. Analiza dogaaja, odnosno analiza entiteta normaliziranog modela i uoavanje dogaaja i uslova koji uzrokuju stvaranje, izmjenu i brisanje podataka i po potrebi auriranje modela procesa. Analiza i distribucija procesa sadri: 1. Pretvaranje logikog modela procesa u fiziki model za odabranu arhitekturu, odnosno izrada sheme aplikacije. Fiziki procesi su: serveri, radne stanice, rad
152
koji treba obaviti, dok su fizika skladita: baze podataka, tabele (relacije) i datoteke; 2. Grupisanje i distribucija obrade na razliite lokacije; 3. Dizajn raunarske mree, povezivanje sa drugim, postojeim, sistemima; 4. Definisanje prava pristupa logikih grupa korisnika. Opti dizajn interfejsa se odnosi na poboljanje izgleda (ergonomija). Izrada planova konverzije i instalacije predstavlja posljednju fazu definisanja optog dizajna.
9.1.2. Detaljni dizajn sistema

Detaljni dizajn su tehnike specifikacije sistema. Sadri izradu fizikog modela podataka, odnosno pretvaranje logikog modela podataka u fiziki model podataka za odabrani SUBP, odnosno izradu sheme baze podataka. Izrada sheme BP podrazumjeva prilagoavanje modela podataka mogunostima i ogranienjima SUBP, odreivanje fizikih parametara (volumetrija), ugaanje baze podataka i oblikovanje fizikih datoteka. Dizajn programa je utvrivanje strukture programa na osnovu modela procesa. Proces (logiki) ili skup procesa moe da se nalazi u jednom ili vie programskih modula, te je potrebno odreivanje veza izmeu modula (standardno strukturnim kartama). U dizajn programa ulazi i preciziranje programske logike. Dizajn interfejsa sadri dizajn interfejsa sistema (protokoli pristupa i razmjene podataka), kao i oblikovanje ekranskih formi i izvjetaja. Prototipski razvoj detalja dizajna je najprihvatljiviji. Izrada procedura za provjeru ispravnosti i konverziju sistema predstavlja posljednju fazu detaljnog dizajna.
9.1.3. Pristupi oblikovanju i razvoju

Pristup oblikovanju i razvoju sistema moe biti cjelovit, istovremeni (tzv. frontalni) razvoj cijelog IS. Ovakav pristup postavlja velike zahtjeve za ljudskim resursima, a sadri problem koordinacije izvoaa. Fazni pristup se sastoji u podjeli na podsisteme, nezavisnom razvoju pojedinih podsistema, uz kasniju integraciju. Ovakav pristup je mogu kod velikih IS koji se daju rastaviti. Javlja se problem rastavljanja i povezivanja podsistema. Optimalno rjeenje je izrada jedinstvenog modela podataka, na poetku razvoja, uz razvoj i postupnu integraciju aplikacija.
153
9.2. Arhitektura informacionog sistema

9.2.1. Dizajn arhitekture sistema
Dizajn arhitekture se sastoji od planova koji definiu pojedine komponente sistema, u prvom redu raunarsku opremu, programsku podrku, komunikacije, sistem zatite i globalnu podrku aplikacija. Specifikacija hardvera i softvera je podloga za nabavku opreme.
Distribuirana prezentacija
mrea Svi podaci na mainframe serveru Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mrea Distribuirani podaci i logika (3-slojna) mrea Podaci i procesi BP na serveru Poslovna logika na aplikativnom serveru Internet i Intranet mrea Podaci na serveru BP Sigurni Intranet provajder za pristup podacima, logici i Dio logike na Intranet serveru interfejsu Siguran ulaz za zatitu aplikacija i podataka mrea Korisniki interfejs na PC klijentu Korisniki interfejs na PC klijentu
Podaci i procesi BP na serveru
Logika i korisniki interfejs na PC
Unutranji korisniki interfejs na PC
Sigurna konekcija na server BP
Konekcija na spoljnji svijet
Dio logike na Internet serveru
Internet provajder konekcija za pristup interfejsu i dijelu logike
Vanjski korisnik PC klijent
Slika 9.1. Primjeri arhitekture sistema.
154
Uobiajeni modeli arhitekture su: serverski (server-based) obrada se obavlja na serveru, klijentski (client-based) obrada se obavlja na personalnom raunaru, klijent-server (client-server based) kombinacija prethodne dvije. Model mree sadri prikaz glavnih komponenti sistema, njihove fizike lokacije i nain njihovog meusobnog povezivanja. Funkcije sistema, odnosno slojevi arhitekture, su odreeni pohranom podataka (data storage), pristupom podacima (data access logic), elementima obrade (application logic) i interfejsom (presentation logic). Serveri mogu biti: veliki raunari (Mainframe), mali raunari (Minicomputer), mikroraunari (Microcomputer), personalni raunari (PC). Klijenti su klasini terminali (npr. ansi, vt220) i mikroraunari (PC), koji omoguavaju pristup terminal emulatorima ili udaljenim radnim plohama. Tu spadaju i terminali posebne namjene, kao to su banini terminali (bankomati), Internet kiosci, runi raunari i sl. Na slici 9.1 su prikazani primjeri arhitekture IS.
9.2.2. Centralizovana obrada podataka

Centralizovana obrada (slika 9.2) se ostvaruje sa viekorisnikim raunarom (mainframe, minicomputer) i terminalima. Ovom arhitekturom je omogueno skladitenje podataka (datoteke i baze podatka), poslovna logika (programska podrka), korisniki interfejs (uobiajeno znakovni interfejs) i interfejs sistema (mrene i druge komponente). Distribuirana prezentacija je proizvoljna nadogradnja centralnih aplikacija, koja se sastoji u zamjeni znakovnog interfejsa grafikim interfejsom. Ova zamjena se, uglavnom, izvodi na personalnim raunarima. Produava se vijek starih aplikacija, ali se funkcionalnost ne moe znaajno poboljati.
Klijent (terminal) Server Host (mainframe raunar)
Slika 9.2. Primjer centralizovane obrade.
Prezentaciona logika Aplikaciona logika Logika pristupa podacima Skladitenje podataka
155
9.2.3. Dvoslojna arhitektura klijent-server

Klijent je jednokorisniki raunar. Sadri interfejs, a omoguava obradu i skladitenje podataka. Posjeduje mogunost povezivanja na servere (prema potrebi i na druge klijente).
Klijent (mikroraunar) Server (mikroraunar)
Prezentaciona logika Aplikaciona logika Logika pristupa podacima

Klijent (mikroraunar)
Skladitenje podataka
Server (mikroraunar, mali raunar ili veliki raunar)
Prezentaciona logika Aplikaciona logika
Logika skladitenja podataka Skladitenje podataka
Slika 9.3. Dvoslojna arhitektura klijent-server. Server je viekorisniki raunar. Omoguava rad sa dijeljenom bazom podataka, obradu podataka i servisiranje interfejsa. Posjeduje mogunost povezivanja sa klijentima i drugim serverima. Korisnicima izgleda kao da jedan raunar obavlja cijeli posao. Prednosti dvoslojne arhitekture klijent-server (slika 9.3) su u izolaciji promjena u pojedinom sloju, kvalitetnijoj (lakoj) obradi i sredinjem upravljanju integritetom podataka na serveru. Nedostak ove arhitekture je u oteanom odravanju aplikacione logike (programa) na svim klijentima i pojava debelog klijenta. Debeli klijent je onaj klijent kod koga je integrisana logika podataka. Nema obrade podataka na serveru ili je obrada minimalna. Posjeduje minimalnu ili nikakvu elastinost na promjenu poslovne politike. Prednosti debelog klijenta su: brzi poetni razvoj aplikacije, vea samostalnost klijenta i rastereenje glavnog raunara (servera). Moe imati lokalnu bazu podataka. Kao debeli klijenti mogu se koristiti jeftini raunari sa snanim procesorima. Nedostatak je da je poslovna logika integrisana na klijentu. Promjena poslovne logike znai
156
instalisanje nove verzije aplikacije na svim klijentima. Velika je mogunost rada sa zastarjelim podacima. Ako sa vremenom aplikacija postane spora (zbog koliine podataka), treba promijeniti sve klijente. Razvoj velike aplikacije sa vremenom postaje vrlo kompleksan (sav programski kod je na klijentu). Tanki klijent je onaj klijent kod koga se logika podataka nalazi na serveru. Osnovna namjena tankog klijenta je prikaz podataka. Veinom se koriste u poslovnim sistemima, a tipini primjer tankog klijenta je web pretraiva. Prednosti tankog klijenta su: promjena poslovne logike ne znai obavezno i promjenu u klijentskom dijelu aplikacije, promjena poslovne logike moe se obaviti centralizovano, raunari ne moraju imati veliku procesorsku snagu, ukoliko sa vremenom obrada postane spora (zbog koliine podataka) moe se jednostavno poveati snaga sredinjeg raunara. Kao tanki klijent moe se koristiti npr. web pretraiva (dobro definisano i svima dostupno). Smanjena je mogunost rada sa zastarjelim podacima (gotovo za svaku promjenu ide se na server). Manja je kompleksnost razvoja velikih aplikacija (kod je podijeljen na serverski dio i klijentski dio). Nedostaci su: veliko optereenje glavnog raunara, a to znai skupi glavni raunar. Ukoliko se kao klijent koristi web pretraiva moraju se potivati njegova ogranienja.
9.2.4. Troslojna i vieslojna arhitektura klijent-server

Kod troslojne arhitekture klijent-server (slika 9.4) distribucija baza podataka i poslovne logike je izvrena na zasebne servere, ime je dobijena arhitektura: server aplikacija + server baza podataka + klijent. Namjena pojedinog sloja je slijedea: 1. Server aplikacija obavlja upravljanje transakcijama "preuzetih" sa servera podataka. Dio ili itava poslovna logika je "preuzeta" sa klijenta; 2. Server baza podataka vri upravljanje podacima; 3. Klijent sadri korisniki interfejs. Takoe sadri dio poslovne logike, i to onaj dio koji se ne mijenja, ili logiku linog karaktera. Prednosti troslojne arhitekture su: bolja raspodjela optereenja, vea skalabilnost, odnosno mogunost ekspanzije (npr. poveanja broja korisnika, bez preoptereenja ili potrebe za promjenom procedura). Nedostaci su: sloeni (komplikovani) dizajn i razvoj, problem raspodjele podataka, procesa, interfejsa, kao i vee optereenje mree. Vieslojna arhitektura se koristi za razvoj sloenih aplikacija. Programski kod se moe podijeliti u vie nivoa, npr.: 1. Kod na prezentacionom sloju - formi (GUI - Graphic User Interface); 2. Kod u sloju poslovne logike (BLL - Business Logic Layer ); 3. Kod u sloju pristupa podacima (DAL - Data Access Layer); 4. Kod na bazi podataka (stored procedure).
157
esto se vri podjela u tri nivoa, i to: klijent - GUI (u web aplikaciji to je web pretraiva), server aplikacija odnosno BLL (npr. web servis) i baza podataka (npr. SQL Server).
Klijent (mikroraunar) Server aplikacija (mikroraunar) Server BP (mikroraunar, mali raunar ili veliki raunar)
Prezentaciona logika
Klijent (mikroraunar)
Aplikaciona logika
Logika pristupa podacima Skladitenje podataka

Web server (mikroraunar)
Prezentaciona logika
Server aplikacija (mikroraunar)
Aplikaciona logika
Server BP (mikroraunar, mali raunar ili veliki raunar)
Aplikaciona logika
Logika pristupa podacima Skladitenje podataka
Slika 9.4. Troslojna arhitektura klijent-server.
9.2.5. Izbor arhitekture klijent-server

Izbor arhitekture moe zavisiti o raspoloivim raunarima i mrenoj infrastrukturi. Openito, mogu se primijeniti sljedei kriterijumi (tabela 9.1): Tabela 9.1.
Arhitekture Dvoslojne K/S arhitekture sa tankim klijentima Aplikacije Naslijeeni aplikativni sistemi gdje je nepraktino i neisplativo odvojiti aplikativne obrade i upravljanje podacima. Raunarsko-zahtjevne aplikacije sa vrlo malo ili bez obrade podataka. Podacima bogate aplikacije (pretraivanje i upiti) sa veoma malo ili bez aplikativne obrade.
158
Dvoslojne K/S arhitekture sa debelim klijentima
Aplikacije gdje se aplikativna obrada izvodi na klijentu sa COTS (Commercial Off-The Shelf Software) programskom podrkom. Aplikacije koje zahtjevaju raunarsko zahtjevne obrade podataka (npr. vizualizacija podataka interaktivno ili u izvjetajima). Aplikacije sa relativno vrstom krajnje - korisnikom funkcionalno-u, koritene u okolini gdje je dobro uspostavljeno upravljanje sistemom. Aplikacije velikog opsega sa stotinama ili hiljadama klijenata. Sistemi u kojima su i podaci i aplikacije promjenljivi. Aplikacije u kojima se integriu podaci iz viestrukih izvora.
Troslojne ili vieslojne K/S arhitekture
Primjer 1: Sa arhitekturom klijent-server potrebno je napraviti aplikaciju koja e prikazivati [Fertalj & Kalpi, 2005]: kupce, prodavae i datume narudbi, nazive artikala, jedininu cijenu i koliinu za pojedinu narudbu, ukupnu koliinu i ukupnu vrijednost narudbe, treba prikazivati zadnjih 20 narudbi. Rjeenje sa debelim klijentom glasi: na klijentu napraviti SQL upit kojim se obuhvataju podaci o zadnjih 20 narudbi, na klijentu napraviti SQL upit kojim se obuhvataju detalji za zadnjih 20 narudbi, kad se promjeni narudba proi kroz sve detalje i ispisati one koje pripadaju trenutnoj narudbi. Usput raunati zbirne vrijednosti. Rjeenje sa tankim klijentom je: na klijentu pozvati stored proceduru koja vraa podatke o zadnjih 20 narudbi, kad se promjeni trenutna narudba pozvati stored proceduru koja vraa detalje trenutne narudbe i zbirne vrijednosti. Primjer 2: Promjene zahtjeva navedenih u primjeru 1: korisnik se nakon mjesec dana rada aplikacije, naravno, predomislio i eli da se prikazuje zadnjih 50 narudbi. Ispunjenje promjene zahtjeva se sastoji u slijedeem. Na debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvrnu opciju te dostaviti aplikaciju korisnicima (sporo i skupo). Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudbi (brzo, manje od pet minuta, i jeftino). Primjer 3: Rjeenje razmatranog primjera u vieslojnoj arhitekturi sadri slijedee nivoe, slika 9.5: 1. Prezentacioni sloj GUI, koji slui za prikupljanje informacija od korisnika, vrenje osnovnih provjera unijetih podataka, njihovo slanje sloju poslovne logike, primanje rezultata od sloja poslovne logike i prezentaciju dobijenih rezultata korisniku u razumljivom formatu. Ovaj sloj sainjavaju HTML, DHTML, Win32 aplikacije, klijent-server skriptovanje, Java apleti, ActiveX kontrole, itd. Prezentacioni sloj se moe generisati generatorom koda npr. Visual Studio.NET 2003, u programskom jeziku Visual C (C#);
159
2. Sloj poslovne logike BLL, koji je namjenjen za primanje podataka od prezentacionog sloja, interakciju sa slojem za pristup podacima radi procesiranja podataka i slanje obraenih informacija prezentacionom sloju. Ovaj sloj obezbjeuje poslovna pravila i servise koji pomau tokom pisanja skalabilnih aplikacija (npr. Web servise, transakcione i servise komponenti, asinhrone i servise redova, serverska skriptovanja). Ovi servisi su vrsto integrisani jedan sa drugim i sa OS i dostupni su preko komponentnog modula (COM+). Sloj poslovne logike BLL se moe generisati generatorom koda npr. Visual Studio.NET 2003, u programskom jeziku C#; 3. Sloj pristupa podacima DAL, koji direktno ostvaruje interakciju sa podacima koji, obino, egzistiraju u BP kao to su SQL Server ili ORACLE. Ovaj sloj slui za smjetanje, pronalaenje i odravanje podataka, kao i za integritet podataka. Pristup podacima preko Windows DNA se naziva Universal Data Access (UDA). UDA je skup modela sistemskog i aplikacionog nivoa, koji se zovu OLE-DB, ADO i RDO. Sloj pristupa podacima DAL se moe generisati generatorom koda npr. LLBLGen, u programskom jeziku C#.
COM+
Prezentacioni sloj
DHTML, Forme
Sistemski servisi
Administracija
Mreni servisi
Sloj poslovne logike
Alati
Zatita
Web server IIS Transakcije MTS
Sloj pristupa podacima

DBMS, File system, mail, txt
Osnovni servisi
Slika 9.5. Arhitektura Windows DNA (Distributed interNet Aplication architecture). Tok izrade aplikacije u vieslojnoj arhitekturi je slijedei. Prezentacioni sloj GUI (generator koda Visual Studio.NET 2003 u programskom jeziku C#). Prema pravilima vieslojnog programiranja na prezentacionom sloju (formi) koristi se sloj poslovne logike (b-klasa). U razmatranom primjeru treba konstruisati b-klasu i ispisati podatke u gridu. U konstruktoru b-klase se uitavaju podaci o narudbama. Nakon toga se okine event, na kojem se prikazuju podatci o detaljima narudbi. Programski kod glasi: private void FormLastOrders_Load(object sender, System.EventArgs e){ // Konstruisi bklasu _bLastOrders = new BLastOrders(_connectionString); // Postavi DataSource na oba grida 1.
160
dataGridOrders.DataSource = _bLastOrders.OrdersEntityCollection; dataGridOrderDetalis.DataSource = bLastOrders.OrderDetailsEntityCollection; // Ispii detalje trenutno selektirane narudbe dataGridOrders_CurrentCellChanged(sender, e); } Kod promjene selektirane narudbe treba osvjeiti podatke o detaljima. To se radi tako da se pozove pripadajua metoda u b-klasi (SelectOrderDetails). Ta metoda dohvata detalje neke narudbe, a usput rauna i zbirne podatke (ti podaci su dostupni preko property-a b-klase). Programski kod glasi: private void dataGridOrders_CurrentCellChanged(object sender, System.EventArgs e) { // Dohvati podatke o trenutno selektiranoj narudbi _bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrde rs[ dataGridOrders.CurrentRowIndex, 0])); // Ispii zbirne podatke na formu textBoxTotalPrice.Text = _bLastOrders.TotalPrice.ToString("C"); textBoxTotalQuantity.Text = _bLastOrders.TotalQuantity.ToString(); } 2. Sloj poslovne logike BLL (generator koda Visual Studio.NET 2003 u programskom jeziku C#). Bie naveden primjer konstruktora u b-klasi (sloju poslovne logike). Sloj poslovne logike treba paljivo definisati, tako da GUI slui samo za prikazivanje podataka, a sve vee obrade i rad sa bazom moraju se odvijati u b-klasi. U razmatranom primjeru uz bklasu postoji i sloj pristupa podacima (DAL) prije same baze podataka. U b-klase se intenzivno koristi DAL, a iz priloenog koda se vidi da je programiranje znatno jednostavnije nego upotrebom SQL upita. Programski kod glasi: public BLastOrders(string connectionString) { // Konstruiranje adaptera za pristup bazi podataka _dataAccessAdapter = new DataAccessAdapter(connectionString); // Definiranje EntityCollection-a za narudbe _ordersEntityCollection = new EntityCollection(new OrdersEntityFactory()); SelectLastOrders(); // Definiranje EntityCollection-a za detalje narudbe
161
_orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory()); } Navedeni primjer sa dohvatom zadnjih 20 narudbi u b-klasi se moe promjeniti da se dohvati zadnjih 50 narudbi. Radi se o primjeru pristupa bazi podataka preko objekata. Mada se ne ini jednostavnim, u praksi ima mnoge prednosti u odnosu na pisanje SQL upita. Osnovna prednost je manja mogunost greke, kao i preglednost koda. Na slian nain bi se rijeio i dohvat detalja pojedine narudbe. Programski kod glasi: public EntityCollection SelectLastOrders() { // Isprazni trenutni sadraj _ordersEntityCollection.Clear(); // Narudbe treba sortirati prema datumu unatrag ISortExpression sorter = new SortExpression( SortClauseFactory.Create(OrdersFieldIndex.OrderDate, SortOperator.Descending)); // Definisanje dodatnih staza za dohvat podataka (treba dohvatiti podatke o kupcima i radnicima) IPrefetchPath2 path = new PrefetchPath2((int)EntityType.OrdersEntity); path.Add(OrdersEntity.PrefetchPathCustomers); path.Add(OrdersEntity.PrefetchPathEmployees); // Dohvat podataka iz baze (uz koritenje sortera i dodatnih staza za dohvat) _dataAccessAdapter.FetchEntityCollection(_ordersEntityCollec tion, null, 20, sorter, path); // Vrati podatke dohvaene iz baze return _ordersEntityCollection; } 3. Sloj pristupa podacima DAL (generator koda LLBLGen u programskom jeziku C#). Ovaj sloj slui za pristup bazi podataka (DAL); Programski kod se generie pomou generatora koda; DAL se u ovom primjeru dijeli na dva dijela: DALGeneric - objekti za pristup bazi koji su isti za sve baze i DALDBSpecific - objekti za pristup bazi koji su specifini za pojedine baze podataka; Prednosti rjeenja upotrebom generatora programskog koda: mogunost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a), mogunost promjene baze podataka, nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka, manja mogunost greke, itd.
162
10. Dizajn baza podataka

10.1. Uvod u dizajn baza podataka
Dizajn baza podataka, u prvom redu, obuhvata izradu sheme baze podataka (fiziki model, tehniki nacrt), kao i prevoenje modela podataka u strukture podrane odabranom tehnologijom (SUBP). Takoe, obuhvata odreivanje primarnog kljua, sekundarnog kljua, stranog kljua i opisnih polja. Relacione BP, koje su nezamjenljive kod obrade poslovnih podataka, karakteriu slijedei koncepti: strukturirani upitni jezik (SQL), okidai - trigeri (triggers), pohranjene procedure (stored procedures), dinamiki skupovi podataka (cursor), korisniki definisani tipovi podataka i funkcije, ... . Prednosti baza podataka su: pouzdanost - konzistentnost i integritet podataka, efikasno rukovanje podacima, prilagodljivost na promjene zahtjeva i skalabilnost. Analizu podataka sainjavaju priprema modela podataka za ugradnju, normalizacija, odnosno tehnika organizovanosti atributa, dovoenje modela u odreeni normalizovani oblik (NO), 3NO ili vii NO. O zastupljenosti pojedinih tipova baza podataka za komercijalnu upotrebu, najbolje govori tabela 10.1. [Internet, 2006]. Tabela 10.1.
Product Access 2002 Cache DB2 eXtremeDB FileMaker FoxPro Informix Matisse Objectivity/DB OpenInsight Oracle 8i, 9i
Developer Microsoft InterSystems Corp. 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
163
SQL Server 2000 Sybase ASE 12.5 UniData UniVerse Versant enJin
Microsoft Sybase IBM IBM Versant Corp.
Commercial Relational Commercial Relational Commercial Nested relational Commercial Nested relational Commercial Object-oriented
10.2. Normalizacija
Normalizacija, odnosno tehnika organizovanosti atributa, je postupak strukturiranja sheme relacione baze podataka tako da se ukloni to vie neodreenosti (nekonzistentnosti). Stepen normalizacije (normalizovani oblici) se poveava od 1NO do 5NO. Veina dizajnera se zaustavlja na 3NO ili na BCNO (Boyce-Codd NO). Formalne definicije normalizovanih oblika glase: a) Relacija R je u prvom normalizovanom obliku ako svi njeni atributi imaju samo "atomske" vrijednosti. Relacija u 1NO ne moe opisivati entitete ili veze u sistemu koji imaju vieznane atribute, ne moe za atribut imati neku drugu relaciju. b) Relacija R je u prvom normalizovanom obliku ako je bilo koji podskup neprimarnih atributa funkcionalno zavisan od kljua. c) Relacija R je u prvom normalizovanom obliku ako izmeu kandidata za klju i ostalih neprimarnih atributa postoje slijedei tipovi preslikavanja: 1:1, 1:M, C:1 i C:M. Relacija R je u drugom normalizovanom obliku, ako je u prvom, i ako svi njeni neprimarni atributi potpuno funkcionalno zavise od svih kandidata za kljueve. Relacija R je u treem normalizovanom obliku, ako je u drugom, i ako ne sadri tranzitivne zavisnosti neprimarnih atributa od kandidata za klju. Relacija R je u BCNO ako je svaka determinanta kandidat za klju. Determinanta je svaki atribut, prost ili sloen, od koga neki drugi atribut potpuno funkcionalno zavisi. Relacija R (X, Y, Z) je u etvrtom normalizovanom obliku ako postojanje netrivijalne vieznane zavisnosti X Y uslovljava postojanje funkcionalne zavisnosti X A za svaki atribut A relacije R.
Relacija R je u petom normalizovanom obliku ako i samo ako se svaka zavisnost spajanja u relaciji R moe pripisati kandidatu za klju. Informatikim argonom reeno, normalizacija se svodi na ispunjenje tzv. "relacione zakletve" [Finkelstein, 1989]:
164
klju - 1NO: nema ponavljajuih grupa, definisan primarni klju, cijeli klju - 2NO: svi nekljuni atributi u potpunosti zavisni o itavom PK, nita drugo nego klju - 3NF: svaki nekljuni atribut je neposredno zavisan samo o PK, BCNO: svi atributi koji odreuju druge atribute ine mogue kljueve. Prevoenje modela i normalizacija uporabom CASE alata se odvija slijedeim redoslijedom: 1. Automatizovano dodjeljivanje stvarnih tipova podataka konkretnog SUBP; 2. Stvaranje relacija (tabela) za entitete nadtipa i podtipa; 3. Automatizovana migracija kljua i prepoznavanje tzv. viseih veza (dangling relationships), odnosno veza na tabele koje nisu ukljuene u generisanje modela; 4. Veina CASE alata normalizira u 1NO: zamjena veza vie-prema-vie asocijativnim entitetima i zamjena vieznanih atributa entitetima; 5. Vii normalizovani oblici: problem prepoznavanja djelominih i tranzitivnih zavisnosti; 6. Generisanje programskog koda okidaa (trigera). Prije poetka kodiranja obavlja se ogranieno uvoenje konzistentnosti i ugaanje baze podataka, zbog poboljanja elastinosti i poboljanja performansi, gdje zahvat moe rezultirati u logiki model odreenim brojem intervencija. Denormalizacija se svodi na ogranieno i kontrolisano naruavanje NO.
10.3. Denormalizacija
Zamjenici (surogati) kljueva su kljuevi sa samopoveavajuim vrijednostima (serial), koji se umeu ispred kljua sastavljenog od veeg broja atributa (npr. 3). Na originalni klju postavlja se jednoznaan (unique) kompozitni indeks. Teorijski se ne preporuuje za asocijativne entitete, koji naslijeuju kljueve svojih roditelja, jer se time gubi smisao identifikacione veze. Praktino, zamjenika kljua treba ugraditi kada je relacija (tabela) u koju se ugrauje referensirana iz drugih relacija, a to nije u suprotnosti sa poeljnim redundantnim vezama. Primjer 1: @IdRadnogMjesta = @IdOrgJedinice, @IdZanimanja RadnoMjesto = @IdRadnogMjesta Zaposlenje = @IdOsobe, @IdRadnogMjesta, @DatZaposlenja, ... .
Primjer 2: Drzava 1:N Mjesto 1:N Osoba, pri emu je Mjesto = @IdDrzave, @IdMjesta, ... .
165
isti dizajn je dosljedna ugradnja zamjenika kljua sa samopoveavajuim vrijednostima u sve tabele (relacije) baze podataka, ime se pojednostavljuje ugradnja. Dolazi do umnoavanja kljueva, zamjenik postaje primarni a originalni postaje alternativni klju, i dolazi do gubitka izvorne vrijednosti stranog kljua. Dijeljenje relacija je smjetanje rijetko koritenih atributa u posebnu relaciju. Udruivanje relacija je uklanjanje pojedinih relacija stapanjem atributa obine veze 1:1 ili udruivanje nadtipa sa podtipovima kardinalnosti 1:1, pod uslovom da su sline strukture i sadraja. Uvoenje konzistentnosti je dodavanje atributa za uvanje izvedenih vrijednosti. To mogu biti atributi uvanja za izvedenu vrijednost koja se moe izraunati agregiranom funkcijom (npr. iznos rauna kao suma iznosa stavki) ili oznake zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u relaciji sa velikim brojem zapisa (torki), npr. stanje skladita. Dodavanje atributa uvanja moe biti za redundantne vrijednosti koje se inae dobijaju sloenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje kolovanje) ili dodavanje atributa kao to su zastavice za "trajno" oznaavanje zapisa. Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nuno i na takav nain da ne ugroava integritet podataka, odnosno aplikativno upravljanje integritetom.
10.4. Ugradnja pravila za ouvanje integriteta

Ouvanje integriteta, stvaranjem objekata u rjeniku BP, obuhvata entitetski integritet i referencijalni integritet. Entitetski integritet se ostvaruje postavljanjem primarnog kljua, dok se referencijalni integritet ostvaruje postavljanjem stranog kljua i ogranienja na unos. Kod referencijalnog integriteta mora postojati vrijednost stranog kljua (mandatory - not null), strani klju se smije postaviti na nul-vrijednost (optional null), domenski integritet se ostvaruje postavljanjem ogranienja na skup vrijednosti, a alternativni kljuevi su sa obaveznim atributima i jedinstvenim indeksima. Pravila referencijalnog integriteta, za opti sluaj, su postupci prilikom unosa, auriranja i brisanja roditelja ili djeteta i odnose se na: zabranu (restrict), brisanje torki koje imaju odgovarajuu vrijednost stranog kljua (cascade), auriranje odgovarajuih vrijednosti stranih kljueva (set null) i postavljanje na standardnu vrijednost (set default). Ugradnja referencijalnog integriteta moe biti razliita. Neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI - Direct Referential Integrity), a svodi se na restrikciju pri unosu, tj. obavezni unos (not null) stranog kljua i provjeru postojanja referensirane torke pri unosu, postojanje opcionog, tj. nedefinisanog stranog kljua (null), ili kaskadnu obradu torki koje referensiraju roditelja koji se aurira ili brie, npr:
166
[ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ]. Upravljanje referensijalnim integritetom okidaima (triggers) je elastiniji pristup, koji omoguava ugradnju i ostalih postupaka prilikom unosa/izmjene/ brisanja torki (vidjeti taku 10.6). Aplikaciono upravljanje integritetom su postupci unosa/izmjene/brisanja podrani programskim kodom. Javlja se problem umnoavanja programskog koda, naroito kod hibridnih sistema (4GL + GUI). Mjeovito upravljanje referencijalnim integritetom je kombinacija navedenih mogunosti, sa tim da neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI) ima prednost. Mogui problemi su viestruki. Neki atribut stranog kljua moe biti primarni atribut. Pokuaj auriranja na nul-vrijednost stranog kljua koji je dio primarnog kljua u suprotnosti je sa pravilom entitetskog integriteta. Prilikom auriranja stranog atributa koji je ujedno i primarni atribut ne smije se naruiti jedinstvena vrijednost kljua. Postupak kaskadnog auriranja ili brisanja torki treba provesti rekurzivno, da bi se referencijalni integritet ouvao u svim dijelovima baze podataka, a ne samo na mjestu obrade.
10.5. Podeavanje baze podataka

Postavljanje indeksa se vri radi osiguranja integriteta podataka i ubrzanja dobijanja podataka. Koriste se slijedee preporuke za postavljanje indeksa. Indeksi treba da su: 1. Jedinstveni indeksi nad primarnim i alternativnim kljuevima (integritet); 2. Indeksi nad stranim kljuem (ubrzanje provjere integriteta i spojnih upita); 3. Indeksi nad najee koritenim poljima, tj poljima koja se koriste za grupisanje, sortiranje ili selekciju uz uslov (ubrzanje pretraivanja); 4. Neki sistemi implicitno kreiraju indekse za primarne i strane kljueve. Uopteno, u tom sluaju ne treba posebno kreirati indekse. Ako su kljuevi sloeni, pretraivanje e raditi brzo, uglavnom po prvom polju, a po potrebi postaviti dodatne indekse nad preostalim poljima; 5. Grupni indeks (CLUSTERED INDEX), faktor popunjenosti (FILL FACTOR), ... . Promjene podataka uzrokuju auriranje indeksa. Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa! Potrebno je ukloniti indekse prilikom masovnih obrada podataka. Preporuuje se koristiti naredbe i opcije za uvoz podataka (BULK INSERT ... CHECK_CONSTR). Postavlja se pitanje da li treba kreirati indekse u relacijama sa malim brojem podataka.
167
Minimizaciji nul-vrijednosti treba posvetiti nunu panju. Moe se pojaviti problem neodreenih vrijednosti agregatnih funkcija, problem operacija sa nulvrijednostima, gdje opisna polja mogu da sadre zahtijevanu vrijednost + pretpostavljenu vrijednost, npr. SELECT AVG(polje), gdje polje ima/nema nulvrijednosti. Moe se pojaviti problem vanjskih spojnih upita, gdje su strana polja posebne vrijednosti u ifrarnicima, npr. 0-nepoznata vrijednost, 999-nepostojea vrijednost. Ubrzanje upita omoguava: analiza plana izvoenja (Execution Plan) i odabir poeljnog plana, npr. SELECT ... OPTION (FORCE ORDER), primoravanje koritenja odreenog indeksa, npr. SELECT ... WITH (INDEX(index, index...)), primoravanje nekoritenja indeksa primjenom nekodljive funkcije nad poljem nad kojim se uobiajeno koristi indeks, npr. WHERE NULLIF ( polje, ) = ... , ostale opcije, npr. SELECT ... OPTION (FAST n_rows). Punjenje baze podataka se vri razliitim vrstama datoteka/relacija, koje mogu biti: matine, gdje dodani zapis ostaje zauvijek u sistemu, a moe se mijenjati, npr. Kupac, Artikl, Predmet, OrgJedinica, transakcione (prometne), predstavljaju zapise poslovnih dogaaja sa ogranienim vijekom, a uklanjanje zapisa se vri uz arhiviranje, npr. Racun, Prijavnica, ifarnici, odnosno statiki podaci koji se koriste od razliitih aplikacija radi ouvanja konzistentnosti podataka i poboljanja performansi, npr. Mjesto (potanski brojevi), StatusNecega, dokumentacione, odnosno kopije istorijskih podataka za laki dohvat i pregled bez regenerisanja dokumenata, arhivske, koje su uklonjene iz medija za direktni (on-line) pristup, dnevnici (audit, log), koji predstavljaju evidenciju pristupa i promjena podataka. Fiziku raspodjelu podataka odreuju faktor blokiranja (blocking factor), koga odreuje broj logikih zapisa koji se obrauju jednim itanjem (fiziki zapis). Ovaj faktor uobiajeno je odreen i automatski podeen, ali se moe i runo podeavati. Distribucija podataka je raspodjela pojedinih relacija, zapisa i/ili polja u razliite fizike BP ili razliite fizike segmente BP, npr. odvajanje matinih datoteka i ifarnika od transakcionih relacija. Replikacija podataka predstavlja umnoavanje relacija, zapisa i/ili polja u razliite fizike BP, npr. replikacija ifarnika izmeu baze podataka na serveru i BP debelog klijenta.
168
Smjetaj fizikih datoteka obezbjeuje poveanje sigurnosti i brzine pristupa odvajanjem SUBP, prostora za podatke, prostora za voenje evidencije i rezervnih kopija na razliite fizike ureaje. Primjer: Dvije fizike jedinice, etiri logike podjele: C:\...\binn\MSSQL.exe D:\...\data\*.mdf E:\...\log\*.log F:\...\backup\*
10.6. Trigeri u relacionim bazama podataka

10.6.1. Uvod
U relacionim bazama podataka, u cilju ouvanja uslova integriteta, definiu se automatski postupci koji se izvravaju nakon obavljanja radnji unoenja, brisanja i auriranja podataka u relacijama. U relacionom upitnom jeziku SQL (PL/SQL) takvi postupci se zovu trigeri (okidai). U sastavu savremenih SUBP, kakav je ORACLE/Designer-a 2000, nalaze se generatori aplikacija (Generate Module/Forms), koji omoguavaju brzi razvoj aplikacija za unoenje, pretraivanje, auriranje i brisanje podataka. Umjesto da se piu programi, dovoljno je naznaiti eljenu aplikaciju upotrebom jednostavnih ekranskih formi. Na ovaj nain zadane instrukcije se kombinuju sa mogunostima SUBP, a kao rezultat se dobije prototip aplikacije. Ekranska forma, koja se dizajnira pomou generatora aplikacija, se sastoji od blokova i svaki blok odgovara jednoj relaciji BP. Unutar bloka, slog prikazuje jedan zapis (torku) osnovne relacije. U okviru bloka postoje polja, kao prazan prostor na formi. Polja se koriste za prikazivanje, unoenje i ureivanje podataka. Svako polje ima odreenu veliinu, poziciju i tip podatka, koji se u njega unosi. Korisnik odreuje sloenost dizajnirane forme i ima potpunu slobodu da izabere blokove, postavlja polja i vri provjere uinjenog. Generator aplikacija sadri tri nivoa dizajniranja ekranske forme: Prvi nivo predstavlja kreiranje blokova i polja. Najjednostavnija forma predstavlja prozore na osnovne relacije. Svako polje se moe postaviti pojedinano ili se moe pozvati automatski uslovni blok generatora aplikacija; Drugi nivo predstavlja definisanje blokova i polja. Na formi se mogu dodavati osnovne provjere ili uputstva za pruanje pomoi. Na primjer, mogu se definisati veliine polja, uslovne vrijednosti ili pomone poruke; Trei nivo predstavlja definisanje trigera (okidaa). Ovo je najnapredniji nivo i mogu se napraviti sloene provjere i asistencije pisanjem kratkih SQL programa, najee u cilju ouvanja uslova integriteta.
169
10.6.2. Razvrstavanje naredbi u trigerima

Trigeri se mogu definisati kao skup naredbi koje poinju da se izvravaju u nekom trenutku rada forme generatora aplikacija. Svaki triger moe biti sastavljen od jednog ili vie koraka, od kojih svaki korak sadri jednu naredbu. Naredbe, koje se koriste u trigerima, se mogu razvrstati u tri vrste. Te naredbe se mogu kombinovati u jednom trigeru, ali ne i u jednom koraku. Vrste naredbi su SQL naredbe, SQL naredbe generatora aplikacija i korisnike izlazne naredbe. 1. SQL naredbe rade sa podacima iz relacija BP ili iz ekranske forme. Triger moe pretraivati ili modifikovati bilo koju relaciju za koju korisnik ima pravo pretraivanja ili modifikovanja. SQL sintaksa dozvoljava trigerima da prenose vrijednosti izmeu relacija i formi. Na primjer, slijedei SQL triger automatski javlja naziv kupca iz relacije KUPAC u polje forme: SELECT NAZIV INTO: NARUDZBA.NAZIV FROM KUPAC WHERE KUPAC.BRKUPCA =:NARUDZBA.BRKUPCA Navedeni triger izvrava naredbu uvijek kada korisnik javlja, unosi ili mijenja broj kupca u formi NARUIVANJE. 2. SQL naredbe generatora aplikacija simuliraju akcije funkcionalnih tastera i drugih operacija, koje korisnik moe izvravati. Na primjer, slijedei makrotriger pomie kursor na blok ARTIKAL i izvrava pretraivanje: #EXEMACRO GOBLK ARTIKAL; EXEQRY; Makrotriger moe biti vezan za funkcionalni taster, tako da korisnik moe dobiti slog stavki pritiskom samo na jedan taster. Ovaj makrotriger se moe izvravati svaki put kada korisnik pregleda blok NARUDBA. 3. Korisnike izlazne naredbe pozivaju korisnikove programe napisane problemski orijentisanim programskim jezicima, kao to su: C, Pascal, COBOL i drugi. Korisnikim izlaznim naredbama se mogu vriti raunske radnje na poljima formi, pristupi poljima u relacijama i drugo.
10.6.3. Naini udruivanja trigera

Trigeri se mogu udruivati za obavljanje razliitih funkcija. Udruivanje trigera se moe razvrstati u slijedeih pet grupa: 1. Unos, pri pokretanju forme ili ulaska kursora u novi blok, slog ili polje; 2. Pretraivanje, prije i nakon dobijanja sloga; 3. Promjena, nakon promjene vrijednosti i prije ili poslije prihvatanja unosa, auriranja ili brisanja u BP;
170
4. Izlaz, pri naputanju forme ili kada kursor napusti blok, slog ili polje; 5. Pritisak na taster, kada korisnik pritisne funkcionalni taster. Moe se izdvojiti jo jedna grupa trigera, koja se ne odnosi na naprijed navedene sluajeve: 6. Trigeri imenovani od korisnika, obini trigeri ili podtrigeri, koji se pozivaju iz drugih trigera. Trigeri se mogu definisati na tri nivoa forme, i to: trigeri na nivou polja, kada su udrueni sa odreenim poljem, trigeri na nivou bloka, kada su udrueni sa odreenim blokom i trigeri na nivou forme, kada su udrueni sa cijelom formom. Na svakom nivou postoje odreeni trigeri koji se mogu primjeniti. Na nivou polja se mogu primjeniti slijedei trigeri: prije polja, poslije promjene, poslije polja, trigeri za tastere i trigeri imenovani od korisnika. Na nivou bloka se mogu primjeniti slijedei trigeri: prije bloka, prije pretraivanja bloka, poslije bloka, prije sloga, poslije pretraivanja sloga, trigeri prihvatanja, prije brisanja, poslije brisanja, prije unosa, prije auriranja, poslije auriranja, poslije sloga, trigeri za tastere i trigeri imenovani od korisnika. Na nivou forme se mogu primjeniti slijedei trigeri: prije forme, poslije forme, trigeri za tastere i trigeri imenovani od korisnika. Svaki tip trigera se moe definisati na njegovom nivou ili bilo kojem viem nivou. Na primjer, triger "poslije promjene" se moe definisati na nivou polja, bloka ili forme. Podruje rada trigera je odreeno nivoom na kojem je definisan. Na primjer, triger "poslije promjene" definisan na nivou bloka e se primjenjivati na svako polje bloka, odnosno izvravae se odmah nakon to korisnik promjeni vrijednost u bilo kojem polju bloka, a ne samo kada korisnik naputa blok. Triger "poslije promjene", definisan na nivou forme, e se primjenjivati na svako polje forme.
33
10.6..4. Optimalni redoslijed definisanja trigera

Da bi se trigeri definisali neophodno je navesti njegove korake i vlasnitva, ukljuujui: koji je tip trigera, odnosno kada e se izvravati, koje naredbe e se izvravati u svakom koraku i ta e se desiti ako korak uspije ili ne uspije. Da se kreira novi triger, potrebno je: 1. Name (ime): imenovati triger ili upisati tip trigera koji se eli kreirati. Tip trigera vai na nivou u kojem se definie. U sluaju potrebe dati naredbe TYPES ili KEYS, da se dobiju LIST TYPES ili LIST KEYS prozori, koji sadre listu moguih trigera na tekuem nivou ili listu moguih trigera za tastere na bilo kojem nivou.
171
2. Izabrati CREATE da se prikae TRIGGER STEP prozor, gdje se mogu unijeti naredbe koje treba izvriti. Mogue je izvriti modifikaciju postojeeg trigera, brisanje trigera ili promjenu njegovog imena. Pomenuti TRIGGER STEP prozor se koristi da se napiu ili promjene koraci trigera, a TRIGGER STEP ATTRIBUTES prozor da se kontrolie ta se dogaa kada korak uspije ili ne. Triger se sastoji od serije koraka, koji se obino, ali ne uvijek, izvravaju u nizu. Korak se sastoji od jedne SQL naredbe, SQL naredbe generatora aplikacija ili korisnike izlazne naredbe. Za definisanje koraka trigera, potrebno je: 1. Seq#: upisati redoslijed za normalno izvravanje koraka; 2. Label (oznaka): ako se eli drugaiji pristup koraku u trigeru, u ovoj rubrici se upisuje oznaka koja to omoguava; 3. Podruje trigera: u ovu rubriku se upisuje SQL naredba ili SQL naredba generatora aplikacija, koja e se izvravati u ovom koraku; 4. Poruka ako triger ne uspije: u ovu rubriku se upisuje poruka koja e se prikazati ako korak ne uspije; 5. Za definisanje atributa koraka trigera (neobavezno), potrebno je izabrati ATTRIBUTES da se prikae TRIGGER STEP ATTRIBUTES prozor. Kada je izvreno uspjeno definisanje koraka trigera, za dalji rad postoje dvije mogunosti: da se izvri dalje pomjeranje u slijedei korak (NEXT STEP) ili da se kreira novi korak izborom CREATE i ponovi postupak. Atributi koraka trigera (korak 5) saoptavaju: ta se deava kada korak uspije ili ne uspije ili koliko memorije se dodjeljuje korisniku. Definisanje atributa koraka trigera se vri na slijedei nain: 1. Abort trigger when step fails (prekini triger kada korak ne uspije): ako je ovaj prekida odabran, a oznaka prekida nije specifirana, neuspjeh koraka e zaustaviti izvravanje trigera; 2. Reverse return code (obrnuto javljanje): ako je ovaj prekida izabran, normalni kriterijum za uspjeh ili neuspjeh se obre; 3. Return success when aborting trigger (javi uspjeh kada se prekine triger): ovaj prekida ima znaenje samo ako je izabran i Abort trigger when step fails (prekini triger kada korak ne uspije); 4. Separate cursor data area (odvojeni prostor memorije): svakom koraku trigera je dodjeljen vlastiti prostor u radnoj memoriji raunara; 5. Success and Failure labels (oznake uspjeha i neuspjeha): koraci trigera se normalno izvravaju u nizu. Meutim, mogu se koristiti oznake koraka da se promjeni redoslijed izvravanja.
172
Odreivanje uspjeha i neuspjeha trigera je prilino sloeno i zbog ogranienog prostora nee se dalje razmatrati u ovoj knjizi.
10.6.5. Objanjenje pojmova iz sintakse trigera

Odreeni pojmovi iz sintakse trigera bie objanjeni u skladu sa izvrenim razvrstavanjem naredbi u trigerima na: SQL naredbe, SQL naredbe generatora aplikacija i korisnike izlazne naredbe. SQL naredbe se zasnivaju na standardnom relacionom upitnom jeziku SQL, koji predstavlja osnovu za rad sa podacima u BP. Osim toga, SQL naredbe u trigerima omoguavaju da se: postave podaci u polja forme, vri raunanje sa podacima u formi, mijenja oblik podataka u formi, provjerava da li podaci postoje u BP i provjeravaju podaci u poljima forme. SQL naredbe se unose neposredno u TRIGGER STEP prozor. Svaki SQL iskaz (naredba + pomoni iskaz) je ukljuen u jedan korak trigera. SQL naredbe imaju dva proirenja, koja omoguavaju vezu sa poljem forme: 1. Moe se upotrijebiti sintaksa :(BLOK.)POLJE da se izvri obraanje polju u formi. Dvotaka (:) oznaava upuivanje polju forme, umjesto atributu relacije; 2. U SELECT iskazu se moe ukljuiti izraz INTO da se postave javljene vrijednosti u polja forme. Prema tome, postavljanje dvotake (:) u INTO izrazu je nepotrebno, ali se moe upotrijebiti radi pojanjenja. Proirena sintaksa SELECT naredbe je: SELECT ((relacija).(atribut_lista)|:(blok.)polje|) (INTO (:)(blok.)polje) FROM relacija_lista (WHERE klauzula) (HAVING klauzula) (GROUP BY klauzula) Podaci se mogu postaviti u bilo koje polje bloka. To moe biti polje koje odgovara osnovnoj relaciji za blok (polje BP), ili ono koje ne odgovara. Takoe, to moe biti polje koje je vidljivo, ili ono koje nije vidljivo. Ako je vidljivo, to moe biti polje koje korisnik moe da modifikuje (dozvoljen unos i/ili dozvoljeno auriranje) ili ne, itd. SQL naredbe generatora aplikacija, za razliku od SQL naredbi koje imaju viestruku upotrebu, se mogu koristiti samo u koracima trigera i to za: predefinisanje funkcionalnih tastera, izvoenja serije akcija na formi bez pritiskanja tastera, izvrenje trigera imenovanih od korisnika, pozivanje druge forme,
173
rad sa varijablama, i izvoenje naredbi operativnog sistema. SQL naredbe generatora aplikacija se unose neposredno u TRIGGER STEP prozor. Jedan korak trigera ukljuuje jedan iskaz (naredba + argument ili funkcija). Sve SQL naredbe generatora aplikacija poinju znakom #. Postoje etiri naredbe koje se mogu koristiti u koracima trigera, i to: #EXEMACRO, #COPY, #ERASE i #HOST. #EXEMACRO naredba se koristi za izvravanje serije akcija u formi. Akcije mogu biti korisnike funkcije (kao da korisnik pritiska odreene tastere), ili specijalne funkcije koje se mogu izvoditi samo sa trigerima. Makroserija naredbi se koristi da: olaka korisniku sloeno ukucavanje ili esto ponavljanje, kontrolie tok aplikacije (npr. usklaivanje slogova iz dva ili vie blokova forme), osigurava da se neke akcije izvode uvijek u nizu i obezbjedi pomo (npr. pozivanjem druge forme da se proita traeni podatak). Kada generator aplikacija izvrava korak trigera koji sadri makro, on izvodi sve funkcije po redoslijedu. Na primjer, naredba: #EXEMACRO NXTBLK; NXTSET; PRVBLK; radi kao da je korisnik pritisnuo tastere <Next Block>, <Next Set of Record> i <Previous Block> navedenim redoslijedom. #COPY naredba se moe koristiti u koraku trigera da se kopiraju konstante, vrijednosti polja, globalne varijable ili sistemske varijable sa izvornog na eljeno mjesto. I izvorno i eljeno mjesto prate kljunu rije #COPY. Na primjer, slijedea naredba dodjeljuje sadraj NARUDBA.BRNARUDBE polja varijabli GLOBAL.ID: #COPY NARUDZBA.BRNARUDZBE GLOBAL.ID #ERASE naredba se upotrebljava za brisanje vrijednosti globalne varijable, ije ime dolazi iza kljune rijei #ERASE. Na primjer, slijedea naredba brie GLOBAL.ID varijablu iz prethodnog primjera: #ERASE GLOBAL.ID #HOST naredba se koristi u koraku trigera da izvri neku naredbu operativnog sistema. Iza naredbe #HOST se stavlja niz naredbi u navodnicima ili ime polja, odnosno varijable koja sadri niz naredbi. Na primjer, slijedea naredba u operativnom sistemu UNIX tampa datoteku dat1: #HOST 'lpr -b dat1' Korak trigera moe privremeno izai iz generatora aplikacija u neki drugi napisani program. Takvi izlazi se mogu koristiti da se obrade podaci iz polja relacija i formi, prikau poruke i izvode druge radnje koje su izvan domaaja SQL naredbi i SQL naredbi generatora aplikacija.
174
Korisnike izlazne naredbe su mnogo komplikovanije za pisanje i izvoenje od SQL naredbi i SQL naredbi generatora aplikacija, pa se koriste samo za one radnje koje ove triger naredbe ne mogu izvriti, kao npr.: izvoenje sloenih provjera polja, izvoenje sloenih rauna, izvoenje auriranja koja iniciraju vrijednosti u formi i optimiziranje izvoenja aplikacija. Korisniki izlazi se mogu pisati u bilo kojem od nekoliko programskih jezika, ukljuujui C, COBOL, FORTRAN, PL/1, Pascal, Ada, a kod najnovije verzije SUBP ORACLE 9i i u programskoim jezicima Java, XML i HTML. Kada se napie program korisnikog izlaza, potrebno ga je ispraviti, pretkompajlirati, kompajlirati i povezati sa trigerom.
10.6.6. Generisanje trigera CASE alatima

3
Postupak implementacionog projektovanja jednog trigera baze podataka, pomou alata softverskog inenjeringa Designer-a 2000, ORACLE, prikazan je na slikama 10.1, 10.2 i 10.3. Rije je o trigeru PP_Stav_Nal_INS, koji je definisan nad shemom relacije (tabele) Stav_Nal. Hijerarhijski navigator objekata je prikazan na lijevoj strani ekranske forme, slika 10.1. Vidljivo je da je triger PP_Stav_Nal_INS direktno podreen tabeli Stav_Nal. Na desnoj strani ekranske forme, ista slika, prikazano je tijelo trigera, iskazano putem neproceduralnog jezika PL/SQL. Cjelokupni programski kod trigera predstavlja objekat, odnosno PL/SQL program, pod nazivom PP_Stav_Nal_INS, koji je definisan u okviru klase Trigger Definitions.
Slika 10.1. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000.
175
Na slici 10.2 je prikazana ekranska forma za zadavanje naziva, opisnog polja "svrha" i naziva PL/SQL programa, pridruenog trigeru.
Slika 10.2. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. Slijedea ekranska forma, prikazana na slici 10.3, omoguava definisanje: dogaaja koji pokree izvrenje trigera, trenutka okidanja trigera, kao i to da li je rije o trigeru koji se pokree na nivou polja (iskaza), ili na nivou sloga (torke).
Slika 10.3. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000.
176
Ako se za dogadjaj izabere operacija UPDATE, tada se otvara posebna ekranska forma, putem koje se zadaje skup obiljeja tabele (relacije), ija modifikacija dovodi do pokretanja trigera. Ukoliko triger treba da sadri logiki (WHEN) uslov, ekranska forma "When" omoguava zadavanje takvog uslova.
10.7. Implementaciono projektovanje, generisanje i programiranje BP pomou CASE alata

10.7.1. Opis implementacione sheme BP
Na osnovu specifikacije implementacionog projekta sheme BP za aplikaciju Komercijalni poslovi, ta je razmatrano u podtaki 6.3.2, vri se opis sheme BP pomou jezika SQL. Rije je o automatski generisanom kodu, produkovanom pomou generatora SQL koda Designer-a 2000, ORACLE. Na slici 10.4 je prikazan izvod iz datoteke koja sadrzi SQL naredbe za kreiranje odgovarajuih relacija (tabela). Osim SQL naredbi za kreiranje relacija BP, kreiraju se ogranienja primarnog kljua, ogranienja torki, ogranienja stranog kljua i trigeri, ta je detaljnije opisano u dokumentaciji SUBP.
CREATE TABLE KUPAC (IDK NUMBER(6) NOT NULL, NAK VARCHAR2(36) NOT NULL, ADR VARCHAR2(62) NOT NULL), BON NUMBER(8) DEFAULT 6 NOT NULL); CREATE TABLE ROBA (IDR NUMBER(6) NOT NULL, JEM VARCHAR2(17) NOT NULL, NAR VARCHAR2(32) NOT NULL); CREATE TABLE SKLADISTE (IDS NUMBER(6) NOT NULL, NAS VARCHAR2(22)); CREATE TABLE ZALIHA (IDS NUMBER(6) NOT NULL, IDR NUMBER(6) NOT NULL, ZAL NUMBER(12,4) DEFAULT 0 NOT NULL, RAS NUMBER(12,4) DEFAULT 0 NOT NULL); CREATE TABLE ZAG_NAL (IDS NUMBER(6) NOT NULL, BRN NUMBER(6) NOT NULL,
Poliuk E. Jaroslav: Projektovanje informacionih sistema IDK NUMBER(6) NOT NULL, STN VARCHAR2(17) NOT NULL, OSN VARCHAR2(17)); CREATE TABLE STAV_NAL (IDS NUMBER(6) NOT NULL, BRN NUMBER(6) NOT NULL, IDR NUMBER(6) NOT NULL, STA VARCHAR2(17) NOT NULL, KOL NUMBER(12,4) DEFAULT 0 NOT NULL);
177
Slika 10.4. Izvod iz datoteke koja sadri SQL naredbe za kreiranje odgovarajuih relacija (tabela).
10.7.2. Generisanje programa i programiranje

Za formiranje naloga za otpremu aplikacije Komercijalni poslovi, generisanje programa je sprovedeno upotrebom generatora modula Developer 2000 Forms, ORACLE. Tokom postupka generisanja, koji je obino iterativne prirode, vre se dodatne modifikacije implementacione specifikacije modula u cilju otklanjanja eventualno uoenih nedostaka ili poboljanja izgleda dobijene ekranske forme. Izgled ekranske forme za formiranje naloga za otpremu je prikazan na slici 10.5.
Slika 10.5. Izgled ekranske forme za formiranje naloga za otpremu.
178
Slika 10.6. Izgled prethodne ekranske forme, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK). Izgled ekranske forme, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja kupca (IDK) i kada je pozvana lista izbora vrijednosti identifikacionog broja kupca, prikazan je na slici 10.6. U okviru ove, kao i svih drugih lista izbora u ovom modulu, korisnik moe da zada dodatne kriterijume za prikaz izvoda iz cjelokupne evidencije (u ovom sluaju cjelokupne evidencije kupaca). Izgled ekranske forme za formiranje naloga za otpremu, u trenutku kada se kursor nalazio na polju za unos identifikacionog broja robe (IDR) i kada je pozvana lista izbora vrijednosti identifikacionog broja robe, je prikazan na slici 10.7. U ovoj listi vrijednosti, mogu se nai samo podaci o robi koja je evidentirana na zalihama onog skladita, ciji je identifikacioni broj naveden u zaglavlju naloga. U ovom primjeru, rije je o skladitu sa identifikacionim brojem 10.
179
Slika 10.7. Prikaz ekranske forme za formiranje naloga za otpremu. Logika izvravanja interaktivnog modula naloga za otpremu jeste da korisnik, nakon pokretanja programa i prijavljivanja na server BP, moe da selektira, zadaje, modifikuje ili brie podatke o nalogu za otpremu, putem prikazane ekranske forme. Ti podaci se smjetaju u radnu zonu programa. U sluaju da je putem ekranske forme izvreno auriranje podataka u radnoj zoni programa, korisnik je obavezan da pokrene postupak auriranja podataka u BP, izborom funkcije Save (Sauvaj), npr. pokretanjem opcije menija Action/Save ili aktiviranjem odgovarajue ikone. U suprotnom treba da odustane od izmjena podataka. Postupak auriranja se sprovodi automatski, putem jedne transakcije, a korisnik e, na kraju izvoenja transakcije, biti obavjeten o efektima njenog sprovoenja. Za svaku novododanu torku u radnoj zoni programa, u okviru transakcije e automatski biti formirana jedna SQL INSERT naredba. Isto tako, za svaku modifikovanu torku u radnoj zoni programa, transakcija e sadravati jednu UPDATE naredbu, dok e za svaku torku u radnoj zoni programa, koja je oznaena kao izbrisana, transakcija sadravati jednu DELETE naredbu.
180
10.8. ifarski sistem

Serijske ifre su brojevi koji se redoslijedom dodjeljuju svakoj novo dodanoj instanci entiteta. U modernim SUBP mogu se generirati uz opciona ogranienja, npr. SQL Server IDENTITY [( seed , increment )]. Blok ifre su sliane serijskim iframa, s tim da su serijski brojevi grupisani prema znaenju, npr. satelitski TV kanali: 100-199 PAY PER VIEW, 200-299 CABLE CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ... . Alfanumerike oznake su ogranieni skup znakovnih oznaka, esto kombinovanih sa brojevima, npr. oznake drava: MNE, DE, IT, SLO. Samogovoree ifre (significant position codes) su svaki broj ili grupa brojeva koji opisuju neko svojstvo instance, npr. JMBG, a esto se koriste i u skladinoj evidenciji (dimenzije automobilskih guma, elektrine sijalice). Hijerarhijski kodovi predstavljaju podjelu u grupe, podgrupe itd. Kao primjeri hijerarhijskih kodova mogu se navesti: ifra predmeta MAT03A3, sa znaenjem MAT 3 obavezni predmet u 3. semestru, ili hijerarhija vojnih sredstava n*m cifara. Izrada ifarskog sistema je neophodna tamo gdje je nemogue preuzeti postojee ifarnike od drugih ustanova ili iz postojeih sistema. Oznake definisane zakonom, standardom ili drugim propisima treba preuzeti i prilagoditi. Ostale ifarnike definisati tako da se naknadno mogu nadograivati. Preporuke za izradu ifarnika su slijedee. ifre moraju biti dovoljno velike da opiu eljene karakteristike, ali dovoljno male da se mogu interpretirati bez raunara. Sistem ifriranja treba biti smislen i prikladan, kako bi dodavanje novih ifara bilo jednostavno. Izbjegavati samogovoree ifre. Primjer: ifarnik Studentska prehrana. Pravilnikom o studentskoj prehrani propisan je status upisa potreban za ostvariranje prava na subvencioniranu prehranu, npr. student mora biti upisan u tekuu akademsku godinu na redovnom studiju. Posebno se evidentira nain upisa (tabela 10.2). Tabela 10.2.
ifra statusa Opis statusa Pravo prehrane
R P U V L O
redovne studije paralelne studije studije uz rad vanredne studije paralelne studije sa pravom prehrane studije za line potrebe
DA NE NE NE DA DA
Primjer jedinstvene ifre: Jedinstveni matini broj akademskog graanina (JMBAG) je jedinstveni broj u sistemu koga student dobija prilikom upisa na studije i zadrava sve do kraja svog studija. Ako se isti student upie na dvije ili vie ustanova
181
uvijek zadrava JMBAG koji je dobio na prvoj ustanovi. Radnici u ustanovama ne unose taj podatak, ve se on automatski generie. JMBAG ima deset brojeva podijeljenih u dvije grupe, te kontrolni broj (deseti). Prva etiri broja oznaavaju matinu ustanovu vlasnika. Slijedeih 5 brojeva su oznaka vlasnika u ustanovi (matini broj vlasnika ili se generie redoslijedom). Unutar ustanove JMBAG i matini broj (broj indeksa) su takoer jedinstveni. Broj kartice se generie automatski, a u sebi sadri 6 grupa brojeva: (601983) 11 (0036324986) 0 A BC D E A - jedinstveni broj u meunarodnom kartinom poslovanju (IIN), glasi 601983, i prema meunarodnom standardu ISO/IEC 7812 na jedinstven nain identifikuje Studentsku karticu u meunarodnom sistemu kartinog poslovanja, B - oznaka vrste kartice (1 broj) - npr: 1 - student i 4 - privremena kartica, C - redni broj kartice koju je student dobio (1 broj), D - JMBAG (10 brojeva), E - Kontrolni broj kartice (1 broj).
10.9. Rjenik podataka - katalog (Meta Modeling)

Rjenik podataka sistema za upravljanje relacionom BP je grupa relacija i pogleda (view) koji sadre informacije o BP. To je baza podataka o bazi podataka ili meta baza. Te relacije i poglede kreira SUBP prilikom kreiranja BP. Rjenik podataka opisuje relacije, atribute, indekse, grupe, korisnike, privilegije i druge koncepte iz BP. SUBP ih automatski aurira kad god se neki koncept kreira, modifikuje ili brie. Prema tome, rjenik podataka uvijek sadri trenutni opis BP. Relacije rjenika se mogu itati sa standardnim SQL pretraivanjem. Primjer strukture rjenika podataka je prikazan na slici 10.8.
182
Slika 10.8. Primjer strukture rjenika podataka. Na slici 10.9 je prikazana praktina realizacija relacija iz sastava Rjenika podataka. Meta modeliranje moe korisno posluiti za opis poslovnih sistema i funkcija poslovnog sistema. Na slici 10.10 je predstavljen strukturirani prikaz (meta model) jednog poslovnog sistema, na slici 10.11 strukturirani prikaz (meta model) za primjer Narudba, na slici 10.12 strukturirani (meta model) aplikacije Prodaja i na slici 10.13 je prikazan primjer ekranske forme aplikacije nad meta modelom.
183
Slika 10.9. Primjer praktine realizacije rjenika podataka. Org cjelina Hijerar. (rad.mj) Osoba Propis Opis procesa Zakon Vrsta dogaaja
Organiz. Pravni Inform. Finans. Materij.
Vrsta dokumenta
Osoba na dok.
Plan
Doga. na dok.
Dokument
Dogaaj
Pravna osoba
Fizika osoba
Stavka sruktuir. dokum.
Osnovno Potrono Tehniko
***
Vrsta sredstva
Sastavnica sredstva
Svojstvo
Sredstvo
Svojstvo sredstva
Slika 10.10. Strukturirani prikaz (meta model) jednog poslovnog sistema.
184
Primjer: Narudba. Narudba MBB-Nabava za osnovno tehniko sredstvo prema preduzeu IMB Br. xxxx od xx.xx.200x. Veza: Ponuda preduzea IMB br. xxxx od xx.xx.200x. Narudbu izradio: Pero Odobrio njegov ef: Ivo Stavke: Raunar IMB estium: xx kom MBO, CPU, RAM, HDD, CDR, FDD, CASE Monitor 15 xx kom tampa xx kom Skener xx kom
MBB Nabava Pravilnik o poslovanju Opis poslova naruiv. Zakon Vrsta dogaaja Pravni Finansij. Menad.
ef
Narudbenica
Plan
Osoba
MBB, Ivo, Pero
Broj, Datum, Ponuda
Narudba
Naruivanje
Pravna osoba
Fizika osoba
estium Monitor tampa Skener
Osnovno Tehniko Vrsta sredstva Svojstvo
MBO,CPU, RAM,HDD, CRD,FDD
Sredstvo
Svojstvo sredstva
Slika 10.11. Strukturirani prikaz (meta model) za primjer Narudba.
Poliuk E. Jaroslav: Projektovanje informacionih sistema Korisnik SifMje Zaglavlje SifZag VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Napomena SifNap NacinPlac SifPlac Otprema SifOtp
185
Parametar SkracParam
Mjesto SifMje
Tarifa TarBroj
Dokument IdDok Partner SifPart SifMje VrDok IdPrethDok SifPart SifOtpr SifPlac SifZag SifNap
Artikl SifArt TarBroj StavkaDok IdDok SifArt
Uplata IdUplate IdDok
Slika 10.12. Strukturirani prikaz (meta model) aplikacije Prodaja.
Slika 10.13. Primjer ekranske forme aplikacije nad meta modelom.
186
11. Dizajn programske podrke

11.1. Specifikacija i dizajn programske podrke
Specifikacija programske podrke, odnosno specifikacija programa, obuhvata navoenje svih zadataka koje program treba obaviti, meusobne povezanosti razliitih dijelova programa i podataka, opis vrste podataka, opis ulaznih i izlaznih podataka, kao i specifikaciju prikaza podataka. Dizajn programske podrke, odnosno dizajn programa, sadri proces pretvaranja zahtjeva za programsku podrku u oblik koji omoguava programiranje, opis jezikom za oblikovanje programa (PDL - Progam Design Language (pseudokod)), pri emu program napisan pomou PDL nema oblik izvedbenog programa.
11.2. Pristup oblikovanju programa

Pristup oblikovanju programa moe biti razliit. Tako npr. funkcionalni pristup oblikovanju programa (Yourdon & Constantine, 1979) sainjavaju slijedee faze. 1. Strukturirani dizajn programske podrke, koji savladavanje veliine i sloenosti programa ostvaruje razradom u hijerarhiju programskih modula. Programski modul je grupa instrukcija, a sastoji se od paragrafa, blokova, potprograma, subrutina. 2. Podjela programa i/ili sistema u module, ili tzv. crne kutije, omoguava veliko unutranje prijanjanje modula (koheziju). Moduli moraju biti interno visoko povezani, svaki modul treba obavljati jednu i samo jednu funkciju, kao i postizanje ponovne upotrebljivosti u buduim programima. Mora biti ostvarena mala vanjska zavisnost modula (skopanost). Moduli trebaju biti minimalno meusobno zavisni, odnosno ostvarena minimizacija uticaja promjene jednog modula na druge module. Oblikovanje programa prema podacima usmjerenim pristupom (Jackson & Warnier, 1981) zasniva se na tome da struktura podataka odreuje strukturu programa. Objektno usmjereni pristup se zasniva na podjeli na klase, koje istovremeno sadre strukture podataka i procedure (metode). Procedure se obavljaju nad objektima (instancama) klasa. Kohezija i povezivanje se, takoe, primjenjuju, a provode kontrolisanim naslijeivanjem, interfejsom i slinostima izmeu klasa i komponenti.
187
11.3. Strukturirani dizajn

Strukturirani dizajn omoguava oblikovanje programa na osnovu dijagrama toka podataka koritenjem strukturnih karti, transformacione i transakcione analize, kao i plonim razlaganjem glavnog procesa u sastavne procese (slika 11.1).
Grafiki prikaz sistema
Dijagram toka podataka
Dijagram toka podataka sa odreenim granicama
Strukturna karta
Slika 11.1. Grafiki prikaz strukturiranog dizajna.
Pseudokod
Strukturna karta (Structure Chart) prikazuje modeliranje programske podrke na osnovu dijagrama toka podataka. Dijagram toka podataka prikazuje TA treba postii, a strukturnom kartom se izraava KAKO ostvariti te zahtjeve, slika 11.2. podatak (data couple) funkcija niz poziv ugraena funkcija (modul) iteracija selekcija
indikator (control couple)
Slika 11.2. Elementi prikaza strukturne karte.
188
Prikaz hijerarhije programskih modula ukljuuje prenos podataka i upravljanja izmeu razliitih nivoa obrade, kao i prikaz naredne, ponavljajue i uslovne obrade. Primjer: Izvjetaj o poslovanju kompanije Gazda & ortaci, slika 11.3. Sistem izvjetaja o prodaji
datum zbir datum zbir
Uzmi datum
datum
Zapii izvjetaj
zbir
zbir
Ispii zbir
zbir
datum
vrijednost EOF
Uspjeh
Katastrofa
Zapii zaglavlje
Zapii red
datum EOF podatak
vrijednost
Raunaj zbir
podatak
itaj podatak
Pii podatak
Slika 11.3. Strukturna karta za DTP izvjetaja o poslovanju kompanije. Transformaciona analiza (transform analysis) je analiza promjene/ pretvaranja podataka. Primjenljiva je na sisteme koji imaju strukturu oblika ulazsredite-izlaz, tj. aplikacije sa jasno raspoznatljivim ulazima, sredinjom obradom i izlazima, koji se mogu prikazati linearnim tokom podataka, slika 11.4. Struktura dizajna, prikladna za ovakve sisteme, se sastoji od tri odgovarajua elementa (ulaz, obrada, izlaz), tj. podsistema: Get C, koji pribavlja podatak C, C I, koji obradom pretvara podatak C u podatak I, Put I, koji ispisuje rezultat I.
189
Slika 11.4. Ilustracija transformacione analize. Transakciona analiza (transaction analysis) je analiza izvrenja/obavljanja obrade. Primjenjuje se na sisteme sa jasno raspoznatljivim sreditima izvrenja, tj. sisteme u kojima se donosi odluka o tome koji e se proces koristiti za pretvaranje ulaza u izlaze (npr. interaktivne aplikacije). Ulaz se usmjerava nekom od modula obrade, a pojedini izlazi se kasnije koriste u daljnjoj obradi, slika 11.5. Primjer: sredite zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajui proces (3, 4 ili 5), rezultirajui podatak (C1, C2 ili C3) koristi se kao izlazni tok C.
Slika 11.5. Ilustracija transakcione analize.
190
Sistemi koji nisu ni transformacioni ni transakcioni se obrauju na poseban nain. Najee se oblikuju plonim razlaganjem glavnog procesa u sastavne procese. Nadreeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podreenih procesa, te prikupiti i uvati proizvedene rezultate obrade, slika 11.6. Primjer:
Slika 11.6. Strukturna karta za DTP razloen plonom dekompozicijom. Stvarni sistemi su, obino, sloeni sistemi. Za oblikovanje programa se, najee, primjenjuje kombinacija osnovnih postupaka, slika 11.7.
Slika 11.7. Prikaz sloenog sistema dobijenog kombinacijom osnovnih postupaka.
191
11.4. Dizajn interfejsa

11.4.1. Interfejsi
Korisniki interfejsi su, najee, tekstualni ili grafiki. Unos podataka moe biti periodini za masovni unos (batch input) ili interaktivni unos (on-line), koji se obavlja na mjestu nastanka podataka. Automatizovani unos moe biti raznolik: biometrijski ureaji (otisci prstiju, uzorci glasa), elektromagnetski ureaji (identifikacija objekata pomou radio talasa), magnetski ureaji (magnetske kartice i drugo), optiki itai (optiki itai oznaka, optiki itai teksta), pametne kartice (mikroprocesor, memorija), ureaji osjetljivi na dodir (touch screen, touch-pad, pen-based), ... . Izlazi (izvjetaji) mogu biti: dokumenti (prijavnice, rauni), detaljni izvjetaji (dokumentovanje obrade, istorija i stanja evidencije), zbirni izvjetaji (grupisanje, sortiranje, iznimke), grafiki izvjetaji (takasti, tapiasti, linijski), ... .
11.4.2. Elementi grafikog interfejsa za unos podataka

Elementi grafikog interfejsa za unos podataka su: Text Box (i varijante) slui za unos podataka u obliku slobodnog teksta. Radio Button slui za unos vrijednosti iz konanog malog skupa unaprijed poznatih, meusobno iskljuivih vrijednosti (2 do 3). Check Box omoguava unos binarnih vrijednosti, opciona vrijednost je "nepoznato". Drop-Down ili Combination (Combo) Box omoguava unos umjereno velikog broja (?) poznatih (?), meusobno iskljuivih vrijednosti. List Box namjenjen je za unos umjereno velikog broja (?) poznatih, ne nuno iskljuivih vrijednosti. Spin (Spinner), DomainUpDown, NumericUpDown namjenjen je za unos nevelikog niza diskretnih vrijednosti. Grid (mrea, matrica) predstavlja kombinaciju osnovnih elemenata.
11.4.3. Oblikovanje i standardizacija interfejsa

Organizacija interfejsa. Programska oprema mora imati standardni izgled ekranskih formi. U svakom trenutku mora biti vidljiva informacija o dijelu obrade, vrsti prikazanih podataka, koliini podataka te moguim akcijama. Mora postojati podruje za navigaciju (ekranska forma za izbor ili pregled podataka), podruje za prikaz statusa obrade i radno podruje za rad sa podacima.
192
Interfejsom moraju biti podrane razliite vrste ekranskih formi za izbor (npr. vertikalne i krune), uz mogunost brzog odabira (funkcionalnom tipkom ili slovom opcije). Horizontalna ekranska forma za izbor (menu bar) je uvijek vidljiva i lako dohvatljiva. Padajue (pull-down) i kaskadne ekranske forme su "nevidljive", ali se opcije daju grupisati. Skone forme (pop-up) nisu oigledne, skau na razliitim mjestima. Trake sa ikonama (toolbar) su vidljivi i lako se pamte, ali postoji problem ikona i skrivanja. Tipke za obavljanje standardnih funkcija moraju biti definisane paljivo i jednoznano, a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija. Doslijednost interfejsa nuan je uslov koji programska oprema mora ispuniti. Standardni izgled ekranske forme prikazan je na slici 11.8..
Slika 11.8. Prikaz standardnog oblika ekranske forme. Ergonomija interfejsa. Polja ekranske forme moraju biti logiki grupisana. Unos se mora obavljati u redoslijedu kojim su polja fiziki poredana. Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (npr. u sluaju vie istovremeno prikazanih "prozora"). Interfejs mora imati ujednaene standardne poruke, zvune signale i upozorenja, kojima se prua dovoljna informacija, a korisnik nepotrebno ne optereuje. Poruke moraju biti jednostavne, precizne te zavisne o kontekstu. Izbjegavati raunarski argon
193
i skraenice. Mora biti ugraena interaktivna pomo zavisna o kontekstu. Prilikom izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. one koje javlja SUBP) i izbjegavati strune izraze. Na slici 11.9 je prikazana ekranska forma jednog grafikog interfejsa.
Slika 11.9. Primjer grafikog interfejsa. Funkcionalnost interfejsa. Poeljno je da se traenje, unos i izmjena podataka obavljaju na istoj ekranskoj formi i na isti nain. Treba omoguiti prekid akcija koje predugo traju, pod uslovom da se tim prekidom ne naruava integritet podataka (npr. prekid selekcija velikog broja zapisa, prekid transakcija). U svakom dijelu obrade treba omoguiti odustajanje uz potvrdu korisnika da to stvarno eli (npr. brisanje). Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno dolo do promjene. Unesene podatke treba provjeravati to ranije, po mogunosti neposredno nakon promjene sadraja polja ekranske forme. Na polju za unos ifri treba omoguiti odabir iz suenog skupa podataka smjetenih u ifarnik. Suenje skupa treba da se moe obaviti na osnovu dijela tekstualnog opisa ifre, uz mogunost upotrebe meta znakova. Korisniku treba omoguiti pregled teksta koji e biti napisan u izvjetaj. Pregled na ekranskoj formi uklanja potrebu za ispisom na papiru i olakava prilagoavanje uslova za selekciju podataka. Dijelove aplikacije, kojima se obavlja masovni unos podataka,
194
potrebno je prilagoditi kretanju unutar jedne ekranske forme i minimizirati potreban broj tastera.
11.5. Ulanavanje procedura

esto se dogaa da dio rada treba ponititi zbog toga to u sistemu ne postoji ifra koja se eli upotrijebiti, a nemogue ju je pohraniti. Problem je u tome to je korisnik, prisiljen da ponititi do tog trenutka unesene podatke, proe kroz nekoliko ekranskih formi za izbor do ifarnika, pohrani novu ifru, vratiti se na mjesto gdje je ona bila potrebna, ponovi unos prije ponitenih podataka i tek tada ih pohrani.
Slika 11.10. Primjer ulanavanja procedura. Rjeenje je da se na polju za unos vrijednosti stranog kljua omogui otvaranje prozora, sa listom za pregled i odabir zahtijevanog podatka, uz prikaz svih zapisa u odgovarajuoj relaciji. Takoe, treba omoguiti otvaranje liste za pregled (uz prikaz ogranienog skupa zapisa na osnovu prethodno postavljenog uslova), aktiviranje funkcije za unos ili izmjenu vezanog podatka i, na kraju, aktiviranje itavog modula za obradu vezanih podataka. Programska oprema mora slijediti poslovne procese. Gdje god je to mogue, treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije. Primjer ulanavanja procedura je prikazan na slici 11.10.
195
11.6. Organizacija modula i aplikacija

Pri izradi prve globalne podjele modula i definisanju ekranskih formi za izbor, treba paljivo grupisati poslovne procese u sisteme procedura, dati prednost uestalijim poslovnim procesima i paziti da se grupisanje obavi po funkcionalnim cjelinama. Postupak je slijedei. Poetni sistem je skup modula za obradu podataka u jednoj relaciji, pri emu svaki od njih podrava standardne funkcije i poziva druge module. Nakon toga se vri postupno udruivanje i reorganizacija modula, uz naknadno razdvajanje sistemskih od korisnikih promjenjivih elemenata. Ovakav nain izrade programske opreme zahtijeva vei poetni rad, ali dugorono donosi prednosti. Poetni sistem (moduli pune i reducirane funkcionalnosti) se sastoji od poetne ekranske forme za izbor i izvedbenih programa Pi, (i = 1, , n), koji sadre glavni program Mi za poziv ekranske forme za izbor standardnog modula, skup standardnih funkcija {F}i te pridrueni reducirani skup funkcija {R}i (slika 11.11).
x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx x xxxxxxx Pokretaki meni
P1 M1 F1 R1
P2 M2 F1 R1
Pi Mi Fi Ri
Pn Mn Fn Fn
Slika 11.11. Primjer modula pune i reducirane funkcionalnosti. Sistem nakon reorganizacije i kodiranja modula dobija hijerarhijski oblik (slika 11.12). To je hijerarhijski ekranski meni, proizvoljne dubine, nad izvedbenih programa, koji sadre udrueni glavni program Mj, (j) skupova standardnih funkcija, (j) reduciranih skupova funkcija te (j) skupova runo ugraenih funkcija, (j = 1, , ).
196
x xxxxxxx x xxxxxxx x xxxxxxx
Hijerarhijski meni
P1 M1 F11 R11 H11 F1(j) R1(j) H1(j) Fv1 Rv1 Hv1
Pv Mv Fv(j) Rv(j) Hv(j)
Slika 11.12. Primjer sistema nakon reorganizacije i kodiranja modula.
11.7. Standardizacija i modularnost programske podrke

11.7.1. Standardizacija i modularnost
Standardne funkcije modula aplikacije za rad sa bazom podataka su slijedee: 1. Ulaz u modul, koji ostvaruje automatski prikaz podataka na osnovu uslova/parametera. Moe biti prikazan niti jedan zapis, svi zapisi ili odabrani zapisi (primarni klju je uslov za selekciju zapisa); 2. Traenje (selekcija) podataka: mora podravati traenje po uzorcima (query by example), koje se unosi sa ekranske forme (query by form). Ako programski jezik nema neproceduralnih naredbi za konstrukciju uslova selekcije treba ih programski simulirati; 3. Unos novog zapisa: obavlja odgovarajuu provjeru domenskog, entitetskog i referencijalnog integriteta. Treba omoguiti odabir, i po potrebi unos, podataka koji se nalaze u drugim relacijama, a povezani su preko stranog kljua; 4. Izmjena postojeeg zapisa: omoguava se promjena vrijednosti prethodno uitanog, a trenutno na ekranskoj formi prikazanog zapisa. Naelno se zabranjuje izmjena vrijednosti identifikatora zapisa. Odabir referenciranih podataka obavlja se kao kod unosa;
197
5. Brisanje uitanog i prikazanog zapisa uz odgovarajue integritetske provjere i poruke. Brisanje se obavlja uz dodatnu potvrdu; 6. Pregledanje (eng. browsing) prethodno uitanih podataka: grupni pregled veeg broja uitanih zapisa u prozoru po redovima, po stranicama, skok na prvi/zadnji/n-ti zapis, pretraivanje liste podataka po dijelu naziva (filter) ili po elji koji moe odabrati jedan ili vie zapisa ili onemoguiti odabir. Standardno se prikazuju samo osnovni elementi zapisa (primarni klju i relevantni zavisni atributi); 7. Poredak (sort) zapisa koji se prikazuju: odreivanje poretka prije selekcije ili naknadni preraspored ve uitanih zapisa; 8. Ispisivanje izvjetaja (report): sadraj ispisa, trenutno prikazani zapis, svi uitani zapisi, format ispisa, odnosno osnovni podatci (ifra i naziv) ili svi podaci, odredite ispisa, npr. tampa, ekranska forma, datoteka (nova datoteka, dodavanje na kraj postojee datoteke); 9. Izlaz iz modula: sa prenosom informacija o odabranom zapisu (primarni klju ili cijeli zapis). Primjer: Uitavanje po uzorku [Fertalj & Kalpi, 2005]. Pretpostavljena naredba za selekciju podataka: SELECT Vrsta.* FROM Vrsta ORDER BY ImenaLat modifikuje se u: SELECT DISTINCTROW Vrsta.* FROM (((Vrsta) INNER JOIN Rod ON Vrsta.IdRoda = Rod.IdRoda) INNER JOIN NarodnoImeVrste ON NarodnoImeVrste.IdVrste = Vrsta.IdVrste) INNER JOIN NarodnoIme ON NarodnoImeVrste.IdNarodnogImena = NarodnoIme.IdNarodnogImena WHERE Rod.NazRoda LIKE "vitis*" AND NarodnoIme.NazNarodnogImen a LIKE "*loza*" ORDER BY ImenaLat
198
11.7.2. Ugradnja optih programskih rjeenja

Standardni modul. Za veinu relacija u bazi podataka dovoljno je napraviti modul sa ugraenim standardnim funkcijama. Standardne funkcije se ugrauju tako da se, osim sa ekranskih formi unutar vlastitog modula, mogu aktivirati i iz bilo kojeg drugog modula (slika 11.13). Poeljno je unaprijed oblikovati standardne module i to: modul za obradu pojedinanih zapisa, modul za tabelarnu obradu i modul tipa glava-stavke (tzv. Masterdetail). Univerzalni modul. Alternativno, preporuuje se ugraditi univerzalni modul sa standardnim funkcijama, koji se moe dinamiki prilagoditi tako da obrauje podatke u razliitim relacijama. Univerzalni modul treba realizovati tako da u pogonu moe istovremeno postojati vie instanci istog modula prilagoenih pojedinim relacijama. U zavisnosti od projekta, univerzalni modul se moe zamijeniti i pomou polovine standardnih modula.
Slika 11.13. Primjer osnovnog standardnog modula. Primjer: Udruivanje standardnih modula. Forma je kreirana kao kombinacija kopija osnovnih formi, dok se sofisticirane funkcije nadograuju runo (slika 11.14).
199
Slika 11.14. Primjer udruivanja standardnih modula. Primjer: Univerzalni modul za tabelarnu obradu. Sadri samo osnovne objekte i pozive na standardne procedure (metode) za obradu dogaaja vezanih uz te objekte. U trenutku aktiviranja obavlja se prilagoavanje relacije za obradu podataka strukturi relacije podataka (slika 11.15).
Slika 11.15. Primjer univerzalnog modula za tabelarnu obradu.
200
Primjer: Univerzalni modul za pojedinanu obradu sadri objekte za posluivanje standardnih funkcija, te po jednu instancu objekata za prikaz/obradu podataka, koji se prilikom aktiviranja modula dinamiki umnoavaju u skladu sa strukturom relacije. Unaprijed se ugrauju pozivi standardnih procedura vezanih uz standardne funkcije, te objekte za prikaz/obradu podataka (slika 11.16).
Slika 11.16. Primjer univerzalnog modula za pojedinanu obradu.
201
12. Implementacija informacionog sistema

12.1. Izrada sistema
Implementacija informacionog sistema podrazumjeva ugradnju novog, raunarom podranog, sistema u poslovni sistem. Drugim rijeima, predstavlja izradu novog sistema i isporuku tog sistema u eksploataciju, tj. svakodnevnu upotrebu. Izrada IS, ukratko, se obavlja kroz slijedee faze: formiranje razvojnog tima i dodjeljivanje odgovornosti lanovima tima, izgradnja i testiranje mrea (po potrebi), izrada i provjera baze podataka, kreiranje baze podataka, odnosno transfer probnih podataka i testiranje operacija nad podacima. Nakon kreiranja baze podataka vri se instalacija i testiranje novih softverskih paketa (po potrebi), izrada detaljnog plana programiranja, pisanje i testiranje novih programa i, na kraju, pisanje programske dokumentacije.
12.2. Programiranje (kodiranje)

Programiranje (kodiranje) je pretvaranje detaljnog programskog opisa u stvarni program, najee primjenom nekog formalnog programskog jezika. Runo kodiranje je neizbjeno zbog veliine stvarnih problema i sloenosti procesa. Ovo kodiranje je sporo i dugotrajno. Koriste se programski jezci visokog nivoa: jezici etvrte generacije (4GL Fourth Generation Language), objektno zasnovani jezici (Object Based Language), kao i objektno orijentisani jezici (Object Oriented Language). Poeljno je da konkretni jezik uz prevodilac (compiler) ukljuuje interpretator (interpreter), te alat za otkrivanje pogreaka (debugger). Automatsko kodiranje se koristi za generisanje programskog koda, generisanje interfejsa, kao i generisanje sheme baze podataka. Istovremeno koritenje razliitih programskih jezika, odnosno jezika razliitih generacija, treba koristiti samo po potrebi, npr. kada se ele ukloniti neki nedostaci osnovnog jezika kojim se obavlja razvoj (npr. 4GL + C). Strukturirano programiranje (strukturno programiranje) je tehnika programiranja koja podrazumijeva pristup odozgo prema dolje (top-down programming). Upotrebljavaju se programske strukture: linijska (tj. blok naredbi sa jednim ulazom i izlazom), uslovno grananje (npr. naredbe if, case/switch/select) i ponavljanje, tj. programske petlje (sa uslovom na poetku, sa uslovom na kraju, sa unaprijed poznatim brojem koraka). Kod strukturiranog programiranja treba izbjegavati bezuslovne skokove (GOTO naredbe).
202
Proceduralno programiranje je nain programiranja koji omoguava da se program definie kao skup programskih cjelina, poeljno takvih da se mogu ponovo koristiti. Programska cjelina (unit) je skup programskih naredbi koje obavljaju jedan zadatak ili jedan dio zadatka, npr. glavni program, potprogrami (procedure, funkcije). Programski modul je skup logiki povezanih programskih cjelina. Uvoenje programskog modula uslovljava pojavu modularnog programiranja. Komponenta je bilo koji sastavni dio softvera. Uobiajeno se podrazumijevaju fizike cjeline.
12.3. Pristup programiranju

Monolitni pristup (build and fix) je dugotrajno kodiranje, a zatim niz ponavljanja oblika provjera+ispravka. Odgaa otkrivanje problema (greaka u kodu i dizajnu). Proslijeuje probleme u primjenu i odravanje. Inkrementalni pristup (stupnjevito, postupno programiranje) je niz ponavljanja oblika kodiranje+provjera+ispravka. Omoguava raniju provjeru i izdvajanje greaka, raniju raspoloivost djelominih (nedovrenih) verzija programa, kao i ravnomjerniju podjelu posla. Omoguava pristup odozgo prema dolje, odozdo prema gore, kao i mjeoviti pristup. Primjer: Inkrementalni pristup. 1. Izrauje se program ija je struktura prikazana slikom 12.1; a b e h c f i l j m d g k
Slika 12.1. Inkrementalni pristup: struktura programa. 2. Prvo se kodiraju sve funkcije, a zatim se udruuju; 3. Pokretanje programa zavrava fatalnom grekom; 4. Problem: kako ustanoviti u kojoj funkciji se nalazi greka; 5. Rjeenje je u postupnom kodiranju i udruivanju funkcija. Prilikom izrade funkcije koja poziva neke druge funkcije, pozvane funkcije se kodiraju kao
203
odresci ili okrajci (stub), tako da je tijelo funkcije prazno ili sadri poruku (Tu sam B): Funkcija A () poziv B() Funkcija B() ispis "Tu sam B" Prilikom izrade funkcije koja e biti pozvana iz neke druge, jo neugraene funkcije, izrauje se pogonska funkcija (driver): Funkcija M (a, b, c, ) Program DriverM poziv M (1, "test", 3.14, ) Programiranje od vrha prema dolje (Top-Down). Ako funkcija fGornja poziva funkciju fDonja, onda se fGornja kodira i integrie prije fDonja. Mogui redoslijed kodiranja: abcdefghijklm, pisanjem odrezaka (npr. bcd za a). Alternativni redoslijed je a+beh+cdfi+gjklm. Nakon to je funkcija a napravljena i provjerena, jedan programer izrauje beh, a drugi istovremeno radi cdfi. Nakon to su zavreni d i odrezak f, trei programer zapoinje gjklm (slika 12.2). Prednost ovog pristupa programiranju je bolja provjera logikih funkcija (na viem nivou hijerarhije, u kojima se donose odluke), odnosno bre otkrivanje logikih greaka i manji utroak odrezaka. Nedostatak je nedovoljna provjera operativnih funkcija (na niim nivoima obavljaju stvarni posao). a b e h c f i l j m d g k
Slika 12.2. Programiranje od vrha prema dolje. Programiranje od dna prema gore (Bottom-Up). Ako se funkcija fDonja poziva iz funkcije fGornja, onda se fDonja izrauje prije fGornja. Redoslijed kodiranja je lmhijkefgbcda (slika 12.3): prvi programer radi heb, drugi programer radi ifc i trei programer radi lmjkgd. Nakon to su zavrene b, c i d, pristupa se konanom udruivanju.
204
Prednost ovog pristupa programiranju je bolja provjera operativnih funkcija i manji utroak pogonskog koda. Nedostatak je kasno otkrivanje logikih greaka. a b e h c f i l j m d g k
Slika 12.3. Programiranje od dna prema gore. Mjeoviti (sandwich) pristup. Prvo se od vrha prema dolje izrauju logike funkcije, npr. abcdgj. Zatim se od dna prema gore rade operativne funkcije, npr. efhiklm (slika 12.4). Prednost ovog pristupa programiranju je rano otkrivanje logikih greaka uz bolju provjeru operativnih funkcija. a b e h c f i l j m d g k
Slika 12.4. Mjeoviti pristup.
12.4. Programski standardi i preporuke

Poveanje itljivosti programa se ostvaruje: standardizacijom naziva, programskim komentarima, tehnikom i stilom programiranja, razliitim oznaavanjem pojedinih elemenata jezika, kao to su rezervisane rijei, identifikatori, komentari, opcije prevodilaca (razliita boja ili "veliina" znakova), koritenjem predefinisanih simbolikih oznaka i konstanti. Takoe je potrebno izbjegavanje programskih redova
205
koji duinom prelaze irinu ekranske forme, pisanje jedne programske naredbe u redu, podjela nizova naredbi na odsjeke koji su u cjelini vidljivi na ekranskoj formi, formatiranje izvornog koda, odnosno pomicanje u desnu stranu naredbi unutar programskih struktura, tzv. "uvlaenje".
12.4.1. Smjernice za nazive

Nazivi struktura podataka treba da budu pisani u skladu sa slijedeim preporukama: 1. Davati nazive iz kojih se vidi na ta se odnose, npr. Osoba.SifraOsobe, Mjesto.SifraMjesta, umjesto: Osoba.Sifra, Mjesto.Sifra, Artikl.Sifra; 2. Izbjegavati upotrebu posebnih znakova koje sintaksa jezika/sistema ne dozvoljava pri oznaavanju identifikatora, npr. operatori i znakovi kao to su: Dat-Ro; 3. Izbjegavati prekratke nazive koji, osim u neitkost, vode u nedoslijednost ve pri prvoj pojavi iste skraenice za razliiti pojam, npr. SifMje za Mjeru i Mjesto; 4. Izbjegavati preduge nazive, npr. Redni_broj_stavke_kalkulacije, zbog smanjenja itljivosti, produktivnosti runog kodiranja (pojava sintaksnih greaka izazvanih grekama u pisanju produava vrijeme ispravljanja i prevoenja) i moguih ogranienja jezika. Duina identifikatora treba da je do 18 znakova; 5. Izbjegavati nazive dobijene rutinskim spajanjem naziva entiteta i atributa, jer mogu djelovati nezgrapno unutar upita, npr. umjesto SELECT Posao.* FROM Posao WHERE Posao.posao_datum bolje je SELECT Posao.* FROM Posao WHERE Posao.DatPosla ; 6. Koristiti nazive koji se daju izgovoriti, npr. Nstvnk.SifNstvnk ... bolje je Nastav.SifNastav ili Nastavnik.Sif Nastavnika. Nazivi programskih varijabli treba da budu pisani u skladu sa slijedeim preporukama: 1. Koristiti smislene nazive, odnosno izbjegavati "jednoslovne" varijable, npr. i, j, k ili i, ii, iii, ili, x1, x2, x3, osim za indekse i dimenzije polja: i, n; 2. Nazive odabirati u skladu sa znaenjem sadraja, npr. max za najveu vrijednost ili len za varijablu koja odreuje duinu; 3. Koristiti standardne prefikse/sufikse za srodne elemente/objekte, npr. frmOsoba ili fOsoba za ekransku formu, repOsoba, rOsoba za izvjetaje; 4. Koristiti skraenice optih pojmova kao to su: broj, redni broj, ifra, skraenica, oznaka, datum respektivno br, rbr, sif, skr, ozn, dat;
206
5. Razlikovati nazive globalnih i lokalnih varijabli, te formalnih argumenata koji se odnose na isti pojam, ime se olakava snalaenje u programskom kodu i uklanja mogua "neodreenost" sadraja, npr. gCount, sCount, lCount, aCount. Standardizacija naziva. Dodjeljivanje naziva objektima modela podataka odraava se na nazive programskih varijabli. O tome treba voditi rauna ve prilikom oblikovanja baze podataka. Poeljno je oblikovanje obaviti takvim alatom za modeliranje, koji osim stvarnih naziva ima mogunost evidentiranja kodova koji e se koristiti prilikom stvaranja objekata BP. Preporuuje se upotreba razliitih notacija, kao to su: koritenje velikih i malih slova (BrojCipela), umetanje podcrte izmeu dijelova od kojih je sastavljen pojam (broj_cipela) ili kombinovanje spomenutih notacija. Primjeri: PascalCase, koji se koristi kod imenovanja prostora: imena, klasa, interfejsa, pobrojanih tipova, postupaka i svojstava, static, public ili protected atributa, zahtjeva da poetno slovo svake rijei u imenu bude veliko slovo, npr. BackColor. Identifikator klase moe zapoeti znakom @. Dok, sa druge strane, camelCase, koji se koristi kod zatienih atributa i lokalnih varijabli postupaka, zahtjeva da poetno slovo prve rijei u imenu bude malo slovo, poetna slova ostalih rijei u imenu su velika slova, npr. backColor. Preporuke, kojih se treba pridravati: imena interfejsa uobiajeno zapoinju slovom I, koristiti imenice za imena klasa i koristiti glagole za imena postupaka.
12.4.2. Smjernice za komentare

Programski komentari treba da budu aurni, tj. da odgovaraju stvarnom stanju. Ne pretjerivati u pisanju komentara. Lo kd je bolje ponovo napisati, nego (bezuspjeno) pojanjavati. Komentarisati smisao naredbi (izbjegavati prepriavanje"). Primjer: Komentar u zaglavlju potprograma.
'*************************************************************** 'Function : FormatField 'Purpose : Formats a field 'Arguments: ' Col Index of field ' Value Value to format 'Returns : True if successful 'Created : I.Ras, A.Kos, 24.08.05 'Modified : I.Ras, A.Kos, 22.09.05 '*************************************************************** Function FormatField(Col As Integer, Value As String) As Integer
207
Primjer: Komentar u zaglavlju modula.

'*************************************************************** 'Module: dh69libClient - C:\VbProjs\dh69cd\dh69libClient.bas 'Purpose: Client Library - Transfer related 'Modified: 14.02.2005 by N '*************************************************************** 'Public Method TestTransfer 'Public Method SetConnectVars 'Public Method ErrExportImport '... 'Public Const EXCHANGEINPROGRESS 'Public Const CHECKSYSTEMDATE 'Public Const TRYTOEXCHANGELATER '... 'Public Variable ImmediateTransfer '... 'Public Const FTP_APPDIR
'Public
Const
FTP_DIR
'... '***************************************************************
Primjer: Komentar programskog redoslijeda i komentar naredbi.

hFile = FtpFindFirstFileA(hservice, RemoteFileName, FindData, 0, 0) If hFile = 0 Then '15.06.2005 by K 'enum FTP files to compare Case-Insensitive Dim bFile As Long, FoundFile As String FindData.cFileName = String(MAX_PATH, 0) hFile = FtpFindFirstFileA(hservice, "*.*", FindData, 0, 0) If hFile = 0 Then Exit Function 'empty directory, 05.03.2006 by K
Primjer: Blok komentar.

'#'Block Out 22.09.2005 by J '#'Ellerman - "already changed by" request '@ 'reset Status and Flags for imported ads '@ SQL = "UPDATE AD SET NewStatus=Status, NewCDFlag=CDFlag, " & _ '@ "NewNPFlag=NPFlag, UpdatedOnServer=True" '@ If MinImportedAdSN > 0 Then '@ SQL = SQL & " WHERE Ad.SN > " & MinImportedAdSN '@ End If '@ daoExecute SQL, IIf(QuietMode, "", "Updating local flags...") '#'End Block Out 22.09.2005 by J
208
12.4.3. Programske preporuke

Na poetku izrade treba uspostaviti standarde kodiranja, a zatim odabrani stil doslijedno primjenjivati! Tehnika i stil programiranja zahtjevaju: eksplicitno deklarisati programske varijable, izbjegavati programske varijable opteg tipa, postaviti poetne vrijednosti varijabli prije upotrebe, ugraditi podrazumijevane vrijednosti ulaznih podataka, provjeravati zahtijeve za ulaznim podacima i valjanost ulaznih podataka, doslijedno formatirati podatke, olakati ispravljanje neispravnih ulaznih podataka, pripaziti na granine vrijednosti podataka, naroito indeksiranih varijabli ... , provjeriti mogue numerike greke (10.0 * 0.1 nije uvijek 1.0), izbjegavati poreenje na jednakost brojeva sa pominim zarezom, koristiti zagrade radi naglaavanja redoslijeda izraunavanja izraza, presloiti i pojednostaviti nerazumljive izraze, izbjegavati nepotrebna grananja, izbjegavati trikove (ne rtvovati jasnou radi "efikasnosti"), ponavljajue blokove i izraze zamijeniti potprogramima, rekurziju koristiti samo za rekurzivne strukture podataka, prvo napraviti jasno i ispravno rjeenje, a zatim brzo rjeenje, neefikasan kd ne usavravati, nego nai bolji algoritam, rutinski posao i jednostavnu optimizaciju prepustiti prevodiocu, nakon pronaene i ispravljene greke provjeriti imali ih jo, lo kd bolje je napisati ponovno, nego ga popravljati ("krpiti"), nedovoljno opta rjeenja bolje je reorganizovati, nego ih prilagoavati radi viekratnog koritenja, kodirati sa osloncem na programske prirunike. Programski prirunici. Prije poetka kodiranja treba pripremiti programske prirunike sa funkcijama grupisanim po namjeni. Tu spadaju funkcije za rad sa optim tipovima podataka (npr. nizovi znakova i datumi), funkcije za rad sa podacima u bazi podataka (npr. funkcije za upravljanje transakcijama i provjeru statusa izvedenih upita), funkcije interfejsa (npr. sistem izbora, poruka i pomoi), funkcije za odravanje baze podataka (npr. provjera konzistentnosti podataka i izrada rezervnih kopija), funkcije za administriranje vanjskih ureaja (npr. terminali i pisai), kao i programski dio sistema zatite (npr. definiranje programskih modula, funkcija i korisnika, te rukovanje pravima pristupa programima i podacima). Grupisanje funkcija interfejsa, te poruka i tekstova pomoi, pomae kod promjene kodne stranice ili u sluaju potrebe za prevodom na neki drugi jezik, kada sve tekstove treba odjednom mijenjati.
209
12.5. Provjera ispravnosti informacionog sistema

12.5.1. Cilj testiranja sistema
Provjera ispravnosti informacionog sistema, odnosno testiranja na greke i ispitivanja programa, su uspjeni kada se dokae postojanje greaka. Testiranje programa (provjera, ispitivanje programa). Provjera programa se vri izvoenjem, uz uporabu ispitnih podataka, te analizom rezultata obrade. Testiranje i ispravljanje greaka se mora obavljati redoslijedom kojim su moduli kodirani, uobiajeno sa vrha prema dolje. Cilj testiranja na greke je utvrivanje greaka, odnosno nedostataka unutar programa. Nain provjere moe biti strukturalni i funkcionalni. Kod strukturalnog naina provjere se provjerava kako cjelina radi. Probni sluajevi se izvode uvidom u programski kd (inspekcija koda). Ovu provjeru provode programeri. Funkcionalni nain provjere provjerava to cjelina radi, to jest da li zadovoljava postavljene zahtjeve. Probni sluajevi se izvode iz specifikacija funkcija. Ovu provjeru provodi osoblje proizvoaa ili korisnici. Verifikacija (ovjera ispravnosti) je dokazivanje da je faza dobro provedena ili da je proizvod dobro napravljen, tj. da odgovara specifikaciji zahtjeva. Validacija (potvrda valjanosti), kojom se utvruje da je napravljen pravi proizvod, koji odgovara korisniku i namjeni.
12.5.2. Vrste testiranja sistema

Testiranje ostataka je testiranje upravljakih struktura i vrijednosti sadranih u kodu. Vri se ispitivanje pojedinanih cjelina (proceduralno programiranje). Nedovreni elementi mogu se simulirati (ostaci i pogonski moduli). Testiranje komponenti je ispitivanje pojedinih programskih komponenti. Ispitivanje provodi programer komponente (postoje iznimke za kritine sisteme). Testovi proizilaze iz iskustva te osobe. Integraciona provjera je ispitivanje grupa komponenti koje integrisane ine cijeli sistem ili neki njegov dio. Vre se slijedee provjere: test korisnikog interfejsa (provjera svake funkcije interfejsa), test sluajeva koritenja (provjera svakog pojedinanog sluaja), test toka podataka (provjera procesa korak-po-korak) i test interfejsa sistema (provjera prenosa podataka izmeu sistema). Ispitivanje provodi nezavisni tim za testiranje. Testovi su zasnovani na specifikaciji sistema. Provjera sistema, odnosno provjera rada sistema kao cjeline, kojom se osigurava da svi nezavisno razvijeni aplikativni programi rade ispravno u skladu sa specifikacijama. Vre se slijedee provjere: funkcionalno testiranje (gdje se vri
210
provjera funkcionalnosti prema zahtjevima korisnika), testiranje performansi i testiranje dokumentacije (tj. provjera korisnike dokumentacije i primjera). Testiranje performansi (odnosno provjeru nefunkcionalnih zahtjeva) sainjavaju: stress - verifikacija velikog broja simultanih pristupa, volume - test na koliinu podataka, sloenost algoritama, fragmentaciju, ..., security - provjera prava pristupa, timing - brzina odziva, recovery - mogunost oporavka pri forsiranom padu sistema.
Test prihvatljivosti je test sistema kojim se dokazuje da proizvod zadovoljava korisnike zahtjeve i potrebe organizacije, te uslove pod kojima ga je naruilac spreman preuzeti. To je sveobuhvatni i konani test sa stvarnim podacima. Alfa-testiranje je verifikaciono testiranje. Sastoji se od probne upotrebe sistema, a provode ga korisnici kod izvoaa. Vri se simulacija stvarnog okruenja, traenje greaka i propusta. Beta-testiranje je validaciono testiranje. Testiranje provode korisnici kod sebe, bez prisustva izvoaa. Provjera se vri u stvarnim uslovima. Provjeravaju se performanse sistema, vrna optereenja, upotrebljivost i lakoa upotrebe metoda i procedura, izrada rezervnih kopija i oporavak sistema. Nadzorni test se provodi prema potrebi. Predstavlja potvrdu da je sistem gotov, ispravan i spreman za primjenu. Ovaj test provode nezavisne institucije za osiguravanje kvaliteta.
12.5.3. Plan testiranja sistema

Testiranje mora biti sistemsko, prema unaprijed napravljenom planu, koji sadri: identifikator programa ili dijela obrade (npr. naziv opcije sistema za ekransku formu), naziv funkcije (npr. unos ili izmjena), vrstu preduzete akcije (npr. potvrda pohrane ili prekid obrade), identifikator ili opis podatka koji se eli obraditi, ponaanje programa (npr. neregularni zavretak rada, neispravni podaci, pogrean prikaz podataka), a po potrebi i oekivani rezultat. Preporuke za provjeru, u kojoj uestvuju poznati korisnici, su slijedee. Provjeru obavlja ogledna skupina krajnjih korisnika koja, koristei napravljena rjeenja, nastoji obaviti svoje svakodnevne poslove. Po elji krajnji korisnik dodatno iznosi svoja zapaanja ili prijedloge. Primjedbe se prikupljaju dnevno, a greke uklanjaju po mogunosti istog dana. Prikupljeni dodatni zahtjevi se procjenjuju, te se izrauje lista prioriteta ugradnje. Nerealni i preveliki zahtjevi se odbacuju ili se planira njihova naknadna ugradnja.
211
12.6. Izrada dokumentacije

12.6.1. Dokumentovanje razvoja
Projektna dokumentacija treba da dokumentuje razvoj IS, kao i proizvode pojedinih faza razvoja. Dokumentaciju po IEEE standardu sainjavaju: 1. Plan validacije i verifikacije softvera - Software Validation and Verification Plan (SVVP); 2. Plan garancije kvaliteta softvera - Software Quality Assurance Plan (SQAP); 3. Plan softverskog upravljanja Management Plan (SCMP); konfiguracijom Software Configuration
4. Plan upravljanja softverskim projektom - Software Project Management Plan (SPMP); 5. Specifikacija softverskih zahtjeva - Software Requirements Specification (SRS); 6. Document za softverski dizajn - Software Design Document (SDD); 7. Izvorni kod (Source code); 8. Dokumentacija softverskog testa - Software Test Documentation (STD); 9. Korisniko uputstvo (User's manual). Korisnika dokumentacija mora pruiti pomo korisnicima pri upotrebi sistema i mora biti prilagoena korisnicima razliitog iskustva. Tu spadaju: upute za upotrebu (user manual), instalacioni prirunik (installations manual), detaljni prirunik (reference manual), upute za vjebu (training guide, tutorial), podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards). Broj, vrsta i obim dokumenata zavisi o aplikaciji. Tehnika dokumentacija je namijenjena tehnikom osoblju. Potrebna je za razumijevanje, izradu i odravanje sistema. Omoguava upravljanje projektom i konfiguracijom sistema, budui da sadri plan razvoja, specifikaciju dizajna, opis arhitekture sistema i specifikaciju interfejsa prema drugim sistemima. Pored navedenog, tehniku dokumentaciju sainjavaju: programska dokumentacija (izvorni kd, opis baze podataka, probni podaci i rezultati provjere, dnevnik promjena i programski prirunici), instalacioni prirunik (odnosno opis instalacione procedure) i upute za rukovanje i odravanje (opis procedura za pokretanje/zaustavljanje - startup/shutdown, opis izrade rezervnih kopija i vraanja podataka - backup, restore, opis postupka ponovnog pokretanja i oporavka - restart, recovery).
212
12.6.2. Preporuke za izradu dokumentacije

Izrada dokumentacije zahtijeva angaovanje i do nekoliko sati (3) po stranici. Mora biti planirana i zapoeti izradu dovoljno rano, prije zavretka kodiranja i testiranja. Prije objavljivanja dokumentacije treba provjeriti/dokazati da odgovara namjeni. Prilikom izrade treba izbjegavati ponavljanja i neodreenosti i koristiti standardizovane dokumente. Izmeu ostalog, dobra dokumentacija mora biti napisana sa gledita itaoca, a ne pisca, ta podrazumjeva konzistentnost pojmova, jednostavnost izraza, kratka poglavlja. Dokumentacija mora biti dobro ilustrovana (slikama ekranskih formi i njihovog redoslijeda), opisivati postupak rada, a ne samo sadraj ekranske forme (npr. redoslijed popunjavanja ifarnika, odreivanje lozinki i prava pristupa, radne procedure). Takoe, mora biljeiti naela (argumente odluka), odraavati stvarno stanje opreme u primjeni (tj. biti aurna) i ukljuivati rjenik koritenih izraza. Nepostojanje dokumentacije moe biti razlog za prestanak koritenja aplikacija, naroito kada autor ili autori prestanu biti raspoloivi. Preporuuje se odvojeno uvati odgovarajuu varijantu programske opreme (alata) kojom je proizvod napravljen.
213
13. Logiko projektovanje programa i programski jezici

13.1. Dijagram toka (blok dijagram, algoritam)
Dijagrami toka (Flowcharts) omoguavaju grafiki prikaz sistema (system flowchart) i predstavljaju zamjenu za fizike DTP, kao i grafiki prikaz programa (program flowchart). Osim toga, dijagrami toka su usredotoeni na akcije koje sistem/program mora obaviti. Specifikaciju predstavlja skup simbola koji opisuju upravljaki tok. Za opis akcije ili odluke unutar simbola moe se primijeniti bilo koja notacija, npr. pseudokod ili prirodni jezik. Nedostaci dijagrama toka su veliki skup simbola, veliki i neprikladni dijagrami, nedostatak formalizma, nemogunost opisa struktura podataka, nestrukturiranost, dozvola skokova koji vode upotrebi GOTO naredbe, ali ipak predstavlja tehniku koja (nikako ne) izlazi iz upotrebe. Primjer 1:
Slika 13.1. Primjer dijagrama toka.
214
Primjer 2:
Poliuk E. Jaroslav: Projektovanje informacionih sistema POETAK Pripremne radnje

Spojite tokova
Uitav.podat. Obrada podat.
Izlaz podat. NE Kraj obrade DA Zavrne radnje KRAJ

Kontrola izlaza iz petlje
Slika 13.2. Primjer opteg oblika dijagrama toka. Primjer 3:

Prodaja
Slika 13.3. Dijagram toka Prodaja (generator dijagrama toka Visio).
215
Primjer 4:
Slika 13.4. Simboli dijagrama toka. Primjer 5:
Slika 13.5.Ekranska forma generatora dijagrama toka Code Visual to Flowchart V3.5 (2006).
216
13.2. Strukturirani prirodni jezik (pseudokod)

Pseudokod je srodan viim programskim jezicima, ali ne sadri formalna pravila jezike sintakse ni jednog od njih. Predstavlja nain opisa logikog toka algoritma programa. Pseudokod je prilagoen strukturiranom nainu programiranja i otuda potiu njegova osnovna sintaksna pravila. Za potrebe ovog teksta, prilagoen je naem govornom podruju. Pri definisanju sintakse i semantike ovog pseudokoda, polo se od slijedeih zahtjeva: svaki element pseudokoda mora biti jednoznano definisan, elementi pseudokoda moraju biti razumljivi itaocu, koji poznaje osnovna pravila pisanja algoritma, elementi algoritma ne smiju posjedovati specifinosti nekog programskog jezika, koji se ne mogu lako izraziti putem naredbi nekog drugog programskog jezika opte namjene, elementi pseudokoda moraju biti tako definisani da se mogu lako prevesti na veinu programskih jezika opte namjene, pseudokod mora posjedovati naredbe za rad sa datotekama na eksternom memorijskom ureaju. Sintaksa i semantika osnovnih elemenata i osnovnih struktura pseudokoda, kao i pravila za konstruisanje procesa i naredbe pseudokoda, specifine za rad sa datotekama, su opisani u nastavku teksta..
13.2.1. Osnovni elementi pseudokoda

Osnovne elemente pseudokoda sainjavaju: promjenljive, glagoli, operator dodjele, aritmetiki i algebarski operatori, komentari.
Promjenljive i njihovi tipovi se u pseudokodu posebno ne deklariu. Ako to ne proizilazi iz njihovog naziva, opisuju se u okviru komentara. Piu se italic slovima, nisu ograniene duinom, a ako se sastoji od vie rijei povezuju se podcrtom (_), npr. p. Glagoli: Svaka imperativna naredba pseudokoda poinje glagolom. Taj glagol se pie velikim slovima, npr. POSTAVI.
217
Operator dodjele: Naredba dodjele vrijednosti promjenljivoj posjeduje dvije komponente. To su glagol POSTAVI i strelica , koja predstavlja operator dodjele. Naredba ima oblik: POSTAVI p i, gdje je p promjenljiva, kojoj se dodjeljuje vrijednost, a i neki izraz. Nakon realizacije naredbe dodjele, promjenljiva p posjeduje vrijednost izraza i. Aritmetiki i algebarski operatori: Aritmetiki, skupovni, logiki i relacioni operatori se, u naredbama pseudokoda, koriste na uobiajen nain. Komentar u pseudokodu ima slijedeu sintaksu: ( * tekst komentara * ), gdje ( * oznaava poetak, a *) kraj komentara. Sam tekst komentara je niz alfanumerikih znakova, koji ne smije sadravati oznake za poetak ili kraj komentara. Primjer: ( * ovo je ispravan komentar * ) ( * ovo je neispravan komentar ( ** ) ( ********************************* ovo je ispravan komentar *********************************** ).
13.2.2. Osnovne strukture pseudokoda

Osnovne strukture strukturiranog naina pisanja algoritma, predstavljaju i osnovne strukture pseudokoda. To su sekvenca (linijska struktura), selekcija (razgranata struktura) i iteracija (ciklina struktura). Sekvenca je osnovni oblik strukturiranja algoritma. Predstavlja linearnu strukturu nad skupom aktivnosti. Aktivnost je naredba pseudokoda ili struktura nad skupom naredbi pseudokoda. Svaka aktivnost sekvence se pie u novom redu i poinje od iste kolone. Sekvencom se opisuje niz aktivnosti, koje se bezuslovno odvijaju jedna za drugom. Redoslijed izvravanja aktivnosti je odreen redoslijedom njihovog navoenja u pseudokodu. Na slici 13.6 je prikazana sekvenca, od tri aktivnosti u pseudokodu, i odgovarajui blok dijagram. Svaka aktivnost poinje glagolom u imperativnom obliku (IZVRI), mada aktivnost moe predstavljati i svaku od osnovnih struktura pseudokoda ili pak strukturu nad skupom osnovnih struktura. U svakom sluaju, izvrenju aktivnosti C mora prethoditi izvrenje aktivnosti B, a izvrenju aktivnosti B mora prethoditi izvrenje aktivnosti A.
218
PSEUDOKOD: IZVRI A IZVRI B IZVRI C
BLOK DIJAGRAM A B C
Slika 13.6. Pseudokod i blok dijagram sekvence. Selekcija je osnovna struktura koja slui za prikaz uslovnog grananja u algoritmima. Semantika ove strukture se moe opisati na slijedei nain. Ako je zadovoljen uslov P, tada se izvrava aktivnost A, inae se izvrava aktivnost B. Na slici 13.7 je prikazana sintaksa pseudokoda i blok dijagram selekcije. U sintaksi selekcije se za svako AKO JE uslov TADA, pie INAE i jedno KRAJ AKO, poevi od iste kolone kao AKO . PSEUDOKOD: AKO JE P TADA IZVRI A INAE IZVRI B KRAJ AKO BLOK DIJAGRAM da P A B
Slika 13.7. Pseudokod i blok dijagram selekcije. Primjer: Neka je a promjenljiva ija je trenutna vrijednost 0. Tada e promjenljiva a imati vrijednost 1, nakon izvrenja selekcije: AKO JE a 0 TADA POSTAVI a a+1 INAE POSTAVI a a-1 KRAJ AKO
219
Da je inicijalna vrijednost promjenljive a bila 1, nakon izvrenja selekcije bi imala vrijednost a = 0. Iteracija RADI DOK JE je algoritamska struktura u kojoj se aktivnost A ponovljeno izvrava tako dugo dok je postavljeni uslov P zadovoljen. Svaka iteracija ima svoje ime. Poinje glagolom RADI, a zavrava se frazom KRAJ RADI, koja se pie od iste kolone kao i RADI. Kada je rije o iteraciji tipa RADI DOK JE, za nju je specifino da ukoliko uslov P nije zadovoljen kod prvog ispitivanja, aktivnost A se uopte ne izvodi. Na slici 13.8 je prikazana sintaksa pseudokoda i blok dijagram iteracije tipa RADI DOK JE.
PSEUDOKOD: RADI naziv_radi DOK JE P IZVRI A KRAJ RADI naziv_radi
BLOK DIJAGRAM
A da P
Slika 13.8. Pseudokod i blok dijagram iteracije RADI DOK JE. Primjer: Neka je n = 10, tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK JE n > 1 POSTAVI n n - 1 KRAJ RADI oduzimanje_od_n izvrava 9 puta. Da je, inicijalno , bilo n 1, tada se oduzimanje ni jedan put ne bi izvrilo. Iteracija RADI DOK NE BUDE je iteracija kod koje se, za razliku od iteracije tipa RADI DOK JE, aktivnost A izvrava prije ispitivanja postavljenog uslova P. Aktivnost A e se sigurno izvriti bar jedan put, bez obzira na ispunjenje uslova P. Aktivnost A se izvrava tako dugo dok ne bude zadovoljen uslov P. Na slici 13.9 je prikazana sintaksa pseudokoda i blok dijagram iteracije RADI DOK NE BUDE.
220
PSEUDOKOD:
BLOK DIJAGRAM
RADI naziv_radi DOK NE BUDE P IZVRI A KRAJ RADI naziv_radi
A P da
Slika 13.9. Pseudokod i blok dijagram iteracije RADI DOK NE BUDE. Primjer: Neka je n = 10, tada se oduzimanje u iteraciji: RADI oduzimanje_od_n DOK NE BUDE n = 1 POSTAVI n n - 1 KRAJ RADI oduzimanje_od_n izvrava 9 puta. Da je, inicijalno bilo n 1, tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. Mogue oznake za pisanje pseudokoda: Abc abc Abc := # " s v M IvI & Si I&I naziv algoritma rezervisana rije pseudokoda za opis algoritama ugraena ili trivijalna funkcija (procedura) pridruivanje zamjena vrijednosti komentar konstanta ili parametar skalar vektor matrica nula-vektor modul (duina) vektora skup element skupa kardinalni broj skupa prazan skup
221
13.3. Akcioni dijagram

Akcioni dijagram (Action Diagram) je formalizovana mjeavina strukturiranog prirodnog jezika i pseudokoda. Na slici 13.10 je prikazan primjer prikazivanja procesa pomou akcionog dijagrama. Koriste se kod rada sa generatorima aplikacija (slika 13.11).
Slika 13.10. Primjer akcionog dijagrama za rad sa generatorom aplikacija Advantage:Plex.
Slika 13.11. Ekranska forma generatora aplikacija Advantage:Plex.
222
13.4. Stablo odluivanja

Stablo odluivanja (Decision Tree) je binarno stablo u kojem svaki nezavrni vor predstavlja odluku koja se donosi u tom voru. Zavisno o donijetoj odluci tok programa prenosi se u podstablo vora. List reprezentuje rezultat niza odluka na putu od korijena do tog lista. Stablo odluivanja je prikladno za opis sloenih grananja u postupku odluivanja. Lako je razumljivo i predstavlja dobro sredstvo za komunikaciju sa korisnicima. Primjer: Posjeta zoolokom vrtu ivotinje. ulaz za djecu do 3 godine je besplatan, omladina do 18 godina plaa polovinu pune cijene ulaznice, djeca ispod 12 godina u pratnji odrase osobe plaaju etvrtinu cijene, osobe iznad 18 godina plaaju punu cijenu, osim ako su studenti ili penzioneri, koji plaaju polovinu cijene, posjetioci u grupi imaju 10% popusta na punu cijenu, studentski popust ne vrijedi vikendom.
Stablo odluivanja za navedeni primjer izgleda kao na slici 13.12.
Slika 13.12. Primjer stabla odluivanja za zooloki vrt ivotinje. Moe se uspostaviti veza izmeu stabla odluivanja i pseudokoda. Na slici 13.13 je prikazano stablo odluivanja za Videoteku i na slici 13.14 pripadajui pseudokod.
223
Kategorija filma:
Ukupni broj filmova koje lan eli iznajmiti:
Rok za vraanje posuenog filma:
Hit film Politika iznajmljivanja filmova: Obian film
bilo koliko
1 dan 1 dan 3 dana 3 dana
manje od 3 3-6 vie od 6
Slika 13.13. Primjer stabla odluivanja za Videoteku. cijena = 0 ako je hit film tada rok iznajmljivanja = 1 dan Slika 14.13. Primjer pseudokoda za Videoteku. cijena = cijena + (osnovna cijena filma x 1,5) inae ako je ukupni broj filmova manji od 3 tada rok iznajmljivanja = 1 dan cijena = cijena + osnovna cijena filma inae ako je ukupni broj filmova manji od 7 rok iznajmljivanja = 3 dana inae rok iznajmljivanja = 7 dana ako film nije trei po redu (svaki trei obini film je besplatan) tada cijena = cijena + osnovna cijena filma
Slika 13.14. Primjer pseudokoda za Videoteku.
224
13.5. Tabele odluivanja

Tabele odluivanja (Decision Tables) predstavljaju tabelarni prikaz preslikavanja skupa ulaznih uslova u skup izlaznih akcija. Posjeduju relativno jednostavne uslove, kao i ograniene skupove moguih odgovora, npr. da/ne ili nisko/srednje/visoko. Neki CASE alati, koji podravaju ovaj nain izrade specifikacija, generiu programski kd razliitih jezika (npr. C, Pascal, Fortran i Basic). Predstavljaju dobro sredstvo za opis poslovnog odluivanja. Primjer: Proirena tabela odluivanja za zooloki vrt ivotinje. Tabela 13.1.
Uslovi (condition stub)
Dob Pratnja Student Vikend Grupa <3 3-12 D
Ispunjenost uslova (condition entries)

3-12 N 12-18 >18 D N >18 D D D >18 D D N >18 N D >18 N N PEN
Akcije (action stub)

Slobodan ulaz etvrtina cijene Polovina cijene 90% cijene Puna cijena X X X
Izbor akcije (action entries)

X X X X X X X
13.5.1. Pravila izrade tabela odluivanja

Prilikom izrade tabela odluivanja preporuuje se koristiti slijedea pravila: 1. Logika odluivanja treba da bude nezavisna o tome kojim redoslijedom su uslovi napisani; 2. Meutim, nije uvijek svejedno kojim su redoslijedom napisane akcije; 3. Potrebno je izbjegavati eventualno dupliranje izraza i znaenja; 4. U gornjem dijelu tabele treba pokuati rasporediti redove tako da oni redovi koji sadre vie potvrda uslova (znak Y) budu to vie, dok oni koji sadre oznake "-" budu nie; 5. Kolone u desnom dijelu tabele treba rasporediti tako da u istom redu oznake "" budu ispred oznaka Y, a ove ispred znakova N.
225
Primjer: Proirena tabela odluivanja za Videoteku. Tabela 13.2.

Politika iznajmljivanja filmova hit film ukupni broj filmova vei od 6 ukupni broj filmova 3 - 6 ukupni broj filmova manji od 3 film je trei po redu Akcije rok iznajmljivanja je 7 dana rok iznajmljivanja je 3 dana rok iznajmljivanja je 1 dan cijena = cijena + (osn. cijena filma x 1,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.6. Struktogram
Struktogram (Nassi-Shneiderman Chart) je grafiki prikaz programskih struktura. Znatno je prikladniji od dijagrama toka. Neprikladan je za runu izradu, naroito kada ga je potrebno esto mijenjati. Osnovni elementi struktograma su prikazani na slici 13.15.
Sekvenca
Selekcija
Iteracija
Slika 13.15. Osnovni elementi struktograma. Nassi-Shneiderman dijagrami su pogodni za reverzni inenjering programa pisanih u C programskom jeziku i za generisanje koda. Na slici 13.16 je prikazan Nassi-Shneiderman dijagram uraen pomou CASE alata Xper-C.
226
Slika 13.16. Ekranska forma Nassi-Shneiderman dijagrama u CASE alatu XperC.
13.7. Programski jezici

13.7.1. Programski jezici tree generacije
Jezici tree generacije (eng. 3rd generation languages - 3GL) su jezici visokog nivoa (HLL - High Level Languages), odnosno proceduralno usmjereni programski jezici. Moe se izvriti podjela programskih jezika po namjeni. Jezici za numerike i naune probleme: FORTRAN (FORmula TRANslator), prvi raireniji jezik za rjeavanje numerikih problema, ALGOL (ALGOrithmic Language), jezik pogodan za rjeavanje numerikih i logikih problema, BASIC (Beginner's All-Purpose Symbolic Instruction Code), prvobitno jednostavan interpretator za interaktivno rjeavanje numerikih problema, kasnije se razvio u Visual Basic.
227
Jezik za poslovne probleme: COBOL (COmmon Business Oriented Language), jezik prikladan za poslovne aplikacije i rad sa podacima. Jezik orijentisan listama i redovima: LISP (LISt Processing), nastao sa namjerom da se razvije programski jezik pogodan za probleme iz podruja vjetake inteligencije. Jezik vjetake inteligencije: PROLOG (PROgramming in LOGic), namjenjen logikom programiranju. Vienamjenski jezici: PL/I, pogodan za numeriko-inenjerske i poslovne aplikacije, C, razvijen radi izrade operativnog sistema iz kojeg je nastao Unix, danas predstavlja standard kada se radi o proceduralnom programiranju, C++, C sa svojstvima objektnog programiranja, Pascal, nastao sa namjerom da se napravi jezik koji se moe efikasno ugraditi na veinu raunara, a koji e biti pogodan za uenje programiranja kao logike i sistematske discipline, ADA, pokuaj postavljanja standarda za jezik integrisanih raunarskih sistema (kontrola industrijskih pogona, vazduhoplova ili bolnikih sistema), Modula-2 i Oberon, proirenje Pascal-a podrkom sistemskom programiranju, konceptom procesa i modula koji meusobno komuniciraju. Veina dananjih 3GL su vienamjenski jezici.
13.7.2. Programski jezici etvrte generacije

Jezici etvrte generacije (eng. 4th generation languages - 4GL) su nastali krajem '70-ih i poetkom '80-ih godina. Neki 4GL ini skup raznorodnih pomagala povezanih u cjelinu sa okruenjem 4. generacije (4th Generation Environment). 4GL naredbe integriu naredbe jezika visokog nivoa, te predstavljaju jezike vrlo visokog nivoa (Very High Level Languages). Programski jezici etvrte generacije predstavljaju jezike posebne namjene, specijalizovane za odreene klase problema. Zadovoljavaju potrebe za izradu 60 80% svih aplikacija.
13.7.3. Vrste i primjena 4GL

Jezici za rad sa bazama podataka su strukturirani upitni jezici. Najee je u upotrebi SQL (Structured Query Language). Za rad sa ovim jezikom u prednjem planu se mora nalaziti Sistem za upravljanje bazom podataka - SUBP (DBMS - DataBase Management System).
228
Podjezici SQL-a su: 1. Jezik za opis podataka (DDL - Data Definition Language), odnosno jezik za definisanje sheme BP u rjeniku podataka (kreiranje objekata); 2. Jezik za rukovanje podacima (DML - Data Manipulation Language), za rad sa podacima (postavljanje upita, unos, izmjena, brisanje); 3. Jezik za upravljanje podacima (DCL Data Control Language), za kontrolu pristupa podatcima (dodjeljivanje i ukidanje prava pristupa). Jezici etvrte generacije (4GL) kao programski jezici se koriste za pisanje aplikacija nad bazom podataka. Primjer: Strukturirani upitni jezik SQL se koristi u sistemima za upravljanje slijedeim relacionim bazama podataka: DB2, Oracle, Informix, MS SQL Server, MS Access i drugim. Matrini kalkulatori (Spreadsheet) su tabele organizovane kao mrea redova i kolona. Elementi tabele su: konstante, izrazi (formule), grafiki znakovi i objekti. Elementi jezika su aritmetike i agregatne funkcije: SUM, COUNT, AVERAGE, MIN, MAX , logiki izrazi: OR, IF, AND, NOT, matematike funkcije: SIN, COS, TAN, ASIN, EXP, SQRT, LN, LOG, statistike funkcije (npr. oekivanje) i finansijske funkcije (npr. kamatni raun). Nakon izraunavanja vrijednosti formula automatski slijedi promjena podataka, npr. D31=ROUND(SUM(D1:D30) * 0.65;-1). Integrisana programska podrka (Integrated Software) objedinjuje matrini kalkulator, obradu teksta i grafiki prikaz podataka, kao i pristup bazama podataka (postavljanje upita) i kreiranje dijaloga. Primjenjuje se za analizu, planiranje (finansije, proizvodnja, prodaja), kao i za pomo pri donoenju odluka (problemi tipa "ta ako"). Grafiki orijentisani jezici (raunarska grafika) slue za sintezu slika pomou raunara (dijagrami, animacija, digitalizacija). CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) su raunarom podrano projektovanje i raunarom podrana proizvodnja. Ovdje se jo mogu svrstati simulatori, programski paketi za prenos slika, . Geografski IS (GIS - Geographic Information System) ukljuuju podatke o geometriji, koncept vie slojeva, kao i koncept objekata. Programi i jezici za prenos podataka se sreu u komunikacionim sistemima (modem, telefax, elektronska pota ... ), kao i kod rada u mrei raunara (emulatori terminala, programi za prenos podataka, ... ). Programska proirenja operativnih sistema (skeleti, ljuske) predstavljaju najraireniji pristup nadogradnje OS (npr. Unix-a). Nad istim jezgrom (kernel), mogu se
229
koristiti razliiti skeleti (shell), npr: Bourne shell, C shell, Mashey shell i dr. Skelet se koristi kao tuma (interpreter) naredbi, npr.: kreiranje liste argumenata prilikom poziva programa (ls *.c 1.c 2.c ... ), sposobnost testiranja rezultata prethodno izvrene naredbe (if test prog then ... ), redoslijedno izvoenje vie programa (cd dir, ls, cd, ... ), obrada u pozadini (background processing) (prog &, jobs, fg), usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat), ulanavanje naredbi na principu "cjevovoda" (cat | more). Elementi programskog jezika su: prenos i zamjena parametara (script prog arg1 arg2 $1=arg1 $2=arg2), supstitucija varijabli (set TERM=vt100, echo $TERM), naredbe za kontrolu programskog toka (while, if-then-else, case, ... ). Ostala programska proirenja OS se zasnivaju na primjeni raunarske grafike, podravanju rada sa "prozorima", "ikone", ekranske forme i dr.
13.7.4. Svojstva jezika 4GL

Osnovno svojstvo jezika 4GL je neproceduralna sintaksa. Proceduralni jezici koriste niz naredbi koji odreuje KAKO se odreena akcija obavlja, npr. "otvori datoteku, ako nije EOF pomakni se, ... , zatvori datoteku" i sl. Neproceduralni jezici sadre niz naredbi koji odreuje TA treba uiniti, npr. "dohvati podatke koji zadovoljavaju uslov ". Tipine neproceduralne naredbe su: naredbe za definisanje strukture podataka te rukovanje podacima u BP (nema potrebe za poznavanjem imena i lokacije datoteka, adresa, ... ), naredbe za unos ili ispis podataka putem ekranske forme (form), naredbe za izbor posla (menu), kao i naredbe za izvjetaje (selekcija, grupisanje, sortiranje, agregatne funkcije, ... ). Uz neproceduralne, mnogi 4GL raspolau proceduralnim naredbama da bi se omoguila ugradnja proceduralnih rjeenja. Primjer 1: Opisivanje podataka (SQL).
CREATE TABLE Osoba ( IdOsobe INTEGER NOT NULL, Prezime CHAR(20) NOT NULL, Ime CHAR(20), Adresa CHAR(20), SifMjesta SMALLINT, NOT NULL );
230
Primjer 2: Rukovanje podacima (selekcija u jeziku SQL).

SELECT * FROM Osoba, Mjesto WHERE Osoba.SifMjesta = Mjesto.SifMjesta AND Osoba.Prezime LIKE "K%"
Primjer 3: Definicija veze u rjeniku podataka (Zim Information Management (ZIM)).

Stanuje := Osoba.SifMjesta = Mjesto.SifMjesta
Primjer 4: Rukovanje podacima (ZIM).

FIND ALL Osoba Stanuje Mjesto FIND ALL Osoba (UNRELATED) Stanuje Mjesto FIND ALL Osoba Stanuje Mjesto (COMPLETE)
Primjer 5: Ekranski meni (Informix-4GL).

MENU Osoba" COMMAND "Dohvat" "Postavljanje uslova za dohvat zapisa" CALL dohvat() IF status != NOTFOUND THEN NEXT OPTION "Slijedeci" END IF COMMAND "Slijedeci" "Dohvatanje slijedeeg zapisa" CALL slijed() ... COMMAND "Unos" "Unos novog zapisa" CALL unos() .... COMMAND "Kraj" "Kraj rada" EXIT MENU END MENU
Primjer 6: Rukovanje podacima putem ekranske forme.

DEFINE rOsoba RECORD LIKE Osoba DEFINE rMjesto RECORD LIKE Mjesto ... DISPLAY BY NAME rOsoba.* ... INPUT BY NAME rOsoba.* BEFORE FIELD SifMjesta MESSAGE "Unijeti ifru mjesta" AFTER FIELD SifMjesta CALL Sel_Mjesto (rOsoba.SifMjesta) RETURNING rMjesto.* IF status = NOTFOUND THEN MESSAGE "Ne postoji mjesto" NEXT FIELD SifMjesta
Poliuk E. Jaroslav: Projektovanje informacionih sistema END IF ... END INPUT
231
Primjer 7: Izvjetaj (ZIM).

REPORT ALL FROM Osoba Stanuje Mjesto SORTED BY Osoba.Prezime, Osoba.Ime FORMAT ACROSS 2 PAGESIZE 23 PAUSE 1 PAGE HEADING "Stranica:" $PAGE : MASK 'ZZ9' : DETAIL LINE Osoba.Prezime : NEWLINE : Osoba.Ime Osoba.Adresa : NEWLINE : Mjesto.PostBr : NEWLINE : Mjesto.NazGrada ENDREPORT
Ford Alan Vancouver avenue 63 383260 New York
Slika 13.17. Primjer izvjetaja. Pojedina 4GL naredba zamjenjuje do nekoliko hiljada 3GL-a naredbi. Prave se krae programske liste, jezgrovitiji i itljiviji programski kod. Kodiranje je sa manje greaka, a ujedno je olakano otklanjanje greaka. Slinost programa strukturiranom govornom jeziku pojednostavnjenje izradu programske dokumentacije. Izradi programske opreme se pristupa u ranoj fazi razvoja, koristei prototipski razvoj. Bitno je ubrzana izrada programa sa neproceduralnom sintaksom i generatorima koda. Poveanje efikasnosti je od 6 do 60 puta (ne i skraenje vremena izrade!). Poveanje efikasnosti se postie smanjenjem broja naredbi i pomou interne optimizacije. Ista aplikacija napisana u jeziku SQL moe na istom raunaru biti od 5 do 20 puta bra od odgovarajue aplikacije napisane u nekom 3GL, kao to su COBOL ili FORTRAN. Prednost se gubi u sluajevima kada se radi o aplikacijama koje ukljuuju rjeenja proceduralnog tipa, odnosno rjeenja dobijena povezivanjem na 3GL, npr. C.
232
Prenosivost (portabilnost) programske opreme omoguavaju: oslonac na standardne OS (MS-DOS/WINDOWS, UNIX, ... ), koritenje vienivovskih prevodilaca (npr. 4GL-EC-C-O-4GE), upravljaki programi koji su nadgradnja OS (npr. SQLEXEC), kao i manje dijalekata (npr. ANSI SQL standard). Programska oprema razvijena pomou 4GL posjeduje jednostavnu i razumljivu sintaksu, slinu govornom jeziku, kvalitetniji razvojni i korisniki interfejs. Odlikuje se prikladnou za uenje i rukovanje jezikom i podacima. Moe se provjeriti tzv. dvodnevnim testom (TWO DAY TEST). Veina korisnika treba da moe nauiti osnove 4GL za 2 do 3 dana. Nakon toga korisnik bi morao biti u mogunosti samostalno da obavlja neke manje poslove. Poeljno je da korisnik nakon manjih prekida u radu (npr. 10 dana) bude u mogunosti nastaviti sa radom bez potekoa. Napred navedeno ne vrijedi jednako za sve 4GL!
233
14. Organizacija i upravljanje projektom

14.1. Generiki modeli organizacije
Generike modele organizacije sainjavaju: projektna, funkcionalna i matrina organizacija. Projektnu organizaciju predstavlja osoblje organizirano unutar/oko projekta. Prednosti ove organizacije su bre odluivanje, minimiziranje potreba susreta izmeu lanova, poticanje identifikacije osoblja sa projektom, dok su nedostaci u upotrebljivosti ove organizacije za male projekte i minimalna raspodjela ekspertize. Funkcionalna organizacija predstavlja organizaciju osoblja po funkcionalnim odgovornostima. Pojedine funkcije mogu podravati vei broj razliitih projekata. Prednosti su u potpomaganju specijalizacije (poveanju broja specijalista), a nedostaci su u smanjenju osjeaja pripadnosti projektu, tj. koheziji projekta. Matrina organizacija je u osnovi funkcionalna, osoblje izmijeano u razliitim projektima. Prednosti su u tome to projektna komponenta pogoduje uspjenosti projekta, a funkcionalna komponenta pogoduje poveanju specijalizacije. Nedostatak je mogui sukob interesa.
14.2. Organizacija i timski rad

Timski rad (teamwork). Ekipa je "samoupravljaka" jedinica, koja posluje u duhu saradnje svojih lanova, njihove koordinacije i njima unaprijed poznatih procedura. Prednosti timskog rada su kvalitetnije donoenje odluka, motivacija lanova, inovativnost, sinergija i slino. Uspjenost tima Formiranje Jurianje Normiranje Djelovanje
Energija tima Slika 14.1. Uticaj karakteristika tima na njegovu uspjenost.
234
Razvoj tima definiu slijedee karakteristike: formiranje (Forming), koje podrazumjeva ljubaznost, nesklonost iznoenju stavova, preputanje voenju, "jurianje" (Storming), koje se ogleda u neslozi, sukobu linosti, grupaenju /stranakoj pripadnosti, pomanjkanju kvalitetne komunikacije, neuspjenosti dogovaranja, normiranje (Norming), odnosno uvianje dobrih strana zajednikog rada, meusobno uvaavanje i predstavljanje (Performing), djelovanje, tj. povezivanje u efikasnu operativnu grupu. Uticaj karakteristika tima na njegovu uspjenost prikazan je slikom 14.1.
14.3. Modeli timova

Klasinu organizaciju tima (Chief Programmer Team) sainjavaju: glavni programer (chief programmer), rezervni programer (backup programmer), mlai (junior) programer i administrator. Glavni programer objedinjuje znanje i odluivanje ekipe. Mora istovremeno biti dobar (vrhunski) programer i rukovodilac. U poboljanoj (revidiranoj) organizaciji ima ulogu rukovodioca ekipe. Rezervni programer slui kao zamjena za nekog od mlaih programera. U poboljanoj (revidiranoj) organizaciji ima ulogu pomonika rukovodioca (slika 14.2). Glavni programmer (rukovodilac)
Administrator
Programer
O Rezervni programmer (pomonik)
Slika 14.2. Prikaz klasine organizacije tima. Modernu organizaciju tima (4GL tim) sainjavaju izvrioci slijedeih radnih zadataka: rukovodilac projekta, odnosno vii sistem analitiar, saradnju sa korisnikom ostvaruje poslovni analitiar, konceptualno i logiko oblikovanje obavlja sistem analitiar, a isporuku sistema/aplikacija vri poslovni analitiar. Nabavka i pogon opreme je radni zadatak sistem inenjera za raunare, mreni servisi su zaduenje sistem inenjera za komunikacije, programsko inenjerstvo obavlja programeranalitiar, dok izrada dokumentacije je posao razvojnog tima. Pomono osoblje se sastoji od administrativnog koordinatora, tehniara i inovnika. Neki stvarni poslovni sistemi koriste gornju podjelu za opis radnih mjesta.
235
Elastini model tima ima oblik: upravnik tima, koji upravlja osobljem (plate, reije, ... ), rukovodilac tima, upravlja razvojem (organizacija posla), projektant (analitiar - programer) je zaduen za analizu, oblikovanje i izvedbu, a programer (programer aplikacija) vri kodiranje i testiranje aplikacija. Administrator baze podataka je zaduen za BP, a sistem inenjer(i) obavlja(ju) odravanje mree i raunara. Sastav tima odgovara poslovima koje treba obaviti. Raspodjela uloga konkretnim lanovima, kao i broj lanova pojedine kategorije, zavisi o konkretnom projektu i raspoloivosti radnika. Primjer: Ulogu upravnika tima i rukovodioca tima moe imati ista osoba. Tim moe imati vie programera. Uloga administratora BP i sistem inenjera moe se dodijeliti istoj osobi. Ovakav model tima se moe primijeniti bez obzira na moguu razliitu sistematizaciju radnih mjesta u nekom poslovnom sistemu.
14.4. Organizacija velikih projekata

Upravnik ili rukovodilac projekta (project manager, project leader) upravlja projektom. Posao moe da obavlja vie ekipa. Upravnik je nadreen upravnicima/ rukovodiocima timova. Tim moe imati i dva rukovodioca i to: upravnika tima (team manager) i rukovodioca tima (team leader), slika 14.3. Upravnik tima obavlja poslove planiranja, upravljanja i nadzora, kao i rukovoenje ostalim lanovima tima, dok rukovodilac tima se bavi tehnikim aspektima aktivnosti koje se odnose na izradu i/ili uvoenje aplikacija/podsistema IS. Upravnik projekta Upravnik Rukovodilac tima tima lanovi tima
Slika 14.3. Grafiki prikaz organizacije velikih projekata.
236
14.5. Upravljanje projektom (Project management)

Upravljanje projektom predstavlja proces organizovanja, planiranja, upravljanja i nadzora razvoja sistema kojim e se postii prava funkcionalnost, na vrijeme i uz minimalne trokove. Ukljuuje razliite 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 izvoae (tim)? nadzor Potuje li se plan? Elementi plana su: veliina projekta, odnosno funkcionalne take (broj linija koda), napor izrade (odreivanje iznosa ovjek-mjeseci) i vrijeme izrade (u mjesecima). Izgradnja IS je posao koji se, unato posebnostima, obavlja kao neki drugi inenjerski poslovi, u planiranom vremenu i sa planiranim resursima. Planiranje projekta mora: odrediti doseg, vremenski raspored i finansijska sredstva, identifikovati pokroviteljstvo kao garanciju realizacije, izabrati upravnika /rukovodioca projekta, odabrati alate za upravljanje projektom i pokrenuti projekat. Planiranje vremena (izrada rasporeda) sainjavaju: odreivanje aktivnosti, procjena i dodjeljivanje sredstava potrebnih za pojedinu aktivnost, procjena trajanja pojedinih aktivnosti, odreivanje zavisnosti izmeu aktivnosti i izrada vremenskog rasporeda za projekat. Upravljanje (nadzor) sadri: odreivanje postupka izvjetavanja o napretku projekta, praenje napretka redovnim revizijama, preraspodjelu sredstava i aktivnosti u skladu sa dogaajima, kao i auriranje vremenskog rasporeda.
14.6. Planiranje projekata

Zato planirati? Duhoviti odgovor na ovo pitanje glasi: ako neto moe poi pogreno, poi e pogreno u najgore vrijeme i na najgorem mjestu (Murphyjev zakon). Murphy je bio optimista (Grimmov komentar). ta je plan (a ta nije)? Plan ne predstavlja izvjesnost ili neto to e se zaista dogoditi. Plan je najbolja procjena, zasnovana na pretpostavkama i iskustvu. Elementi plana su aktivnosti, kljuni dogaaji, resursi (sredstva), trokovi ... . Programerski paradoks [Brooks, 1982.]. Nakon to je odgovarajui broj osoba pridruen nekom zadatku, dodavanje osoblja usporava razvoj, umjesto da ga ubrza.
237
Sloeni projekti zahtijevaju velike ekipe. Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti. Izrada plana sadri slijedee aktivnosti: utvrivanje kljunih aktivnosti i dogaaja, odreivanje vremenskih redoslijeda aktivnosti i dogaaja, kao i utvrivanje potrebnih sredstva. Potrebno je racionalizovati pripadajue trokove, povezati pojedine podprojekte/poslove u glavni projekat, iterativno razraditi plan i revidirati plan u skladu sa postojeim iskustvom/saznanjima. Metode namijenjene za upravljanje projektima su mnogobrojne, a mogu se izdvojiti PRINCE (PRojects IN Controlled Environments) i COCOMO (COnstructive COst MOdel). Metoda PRINCE je strukturirana metoda za upravljanje projektom, za definisanje organizacione strukture projekta, definisanje strukture i sadraja plana projekta, definisanje skupa provjera i izvjetaja koji se koriste za nadzor realizacije.
14.7. Tehnike za vremensko planiranje

tapiasti/stupasti dijagrami - Gantogrami (Gantt Charts) omoguavaju prikaz aktivnosti linijama. Duina linije je srazmjerna vremenu obavljanja aktivnosti. Gantogram prikazuje predvieni poetak i kraj aktivnosi, njihovu meusobnu zavisnost te odgovornost za izvoenje aktivnosti. Naglaava vremensko preklapanje aktivnosti, slika 14.4.
May 1996
Slika 14.4. Primjer gantograma. Mreni plan - PERT/CPM (Program Evaluation Review Technique/Critical Path Method) prikazuje vremensku predstavu aktivnosti i njihovih uslovljenosti. Vidljivo je
238
koje aktivnosti se mogu vriti paralelno, a koje u nizu, ukoliko zavise o ranijim aktivnostima. Naglaava kritini put projekta, slika 14.5.
Slika 14.5. Primjer mrenog plana PERT/CPM. Upravljanje kljunim dogaajima se vri tabelarnim prikazima planiranih aktivnosti i trenutnog statusa njihovog izvrenja. U odreenim vremenskim trenutcima se razmatra stepen dovrenosti neke/nekih projektnih aktivnosti. Kljuni dogaaj je obino kraj neke faze ili aktivnosti, kao npr. oekuje se da faza ili aktivnost bude gotova, druge aktivnosti zapoinju nakon to se to ostvari ili pomak kljunog dogaaja ima za posljedicu vremenski preraspored.
14.8. Izrada plana

Definisanje zadataka i njihove meuzavisnosti bie objanjeni preko slijedeeg primjera (tabela 14.1). Zadatak T3 (npr. ugradnja komponenti) zavisi o zadatku T1 (npr. oblikovanje komponenti). Oblikovanje mora biti zavreno prije ugradnje. Tabela 14.1.
Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Trajanje (u danima) 8 15 15 10 10 5 20 25 15 15 7 10 Zavisnosti
T1(M1) T2,T4(M2) T1,T2(M3) T1(M1) T4(M5) T3,T6(M4) T5,T7(M7) T9(M6) T11(M8)
239
Pristupa se izradi mrenog plana na osnovu definisanih zadataka i zavisnosti (slika 14.6). Aktivna mrea se ita sa desna na lijevo. Sve aktivnosti moraju zavravati u kljunim takama (M1, M2, M3, M4, ... ). Tek kad se uspjeno pree kljuna taka moe se zapoeti sa slijedeom aktivnosti. Npr. zadatak T9, ne moe zapoeti sve dok zadaci T3 i T6 nisu zavreni. Dolazak na taku M4 pokazuje da su ti zadaci zavreni.
T12
Slika 14.6. Primjer dijagrama mrenog plana. Kritini put. Minimalno vrijeme potrebno za zavretak projekta se moe procjenjivati prema kritinom putu, odnosno najduem putu na aktivnoj mrei. U navedenom primjeru to je 11 sedmica ili 55 radnih dana. (T1-T3-T9-T11-T12, slika 14.6). Prekoraenje vremenskog roka najee je vezano uz kritini put. Aktivnosti koje kasne, a ne lee na kritinom putu ne bi trebale uzrokovati vremensko prekoraenje (npr. ako T8 kasni ne bi trebalo uticati na krajnji datum, jer T8 ne lei na kritinom putu).
14.9. Prikaz plana

Gantogram je alternativni nain prikaza vremenskog rasporeda (slika 14.7). Neke od aktivnosti su oznaene i zasjenjenim linijama, to pokazuje da postoji odreena fleksibilnost u datumu njihovog zavravanja. Ako se aktivnost ne zavri na vrijeme, kritini put nee biti ugroen sve do zavretka zasjenjene linije.
240
Slika 14.7. Primjer gantograma sa prikazom vremenskog rasporeda.
14.10. Raspodjela zadataka

tapiasti dijagram (gantogram), takoe, pokazuje razdoblje u kojima je osoblje angairano na projektu (slika 14.8). Angaovanje ne mora biti kontinuirano. Za razmatrani primjer prikazano je tabelom 14.2. Osobe mogu raditi na drugim projektima, ii na odmor ili obavljati neke druge aktivnosti. Tabela 14.2.
Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Inenjer Nada Ana Nada Pero Mile Ana Igor Pero Nada Ana Pero Pero
241
Pero Nada Ana Igor Iva
Slika 14.8. Primjer vremenskog angaovanja osoblja pomou gantograma.
14.11. Evidencija projekta

Za planiranje, upravljanje, praenje napretka, praenje istorije projekta mogu se koristiti razliiti programski proizvodi, npr. MS Project, CA Process Continuum, CASE alati za planiranje. Ekranske forme CASE alata za upravljanje projektima su prikazani na slikama 14.9 i 14.10.
Slika 14.9. Primjer ekranske forme CASE alata za upravljanje projektima.
242
Slika 14.10. Drugi primjer ekranske forme CASE alata za upravljanje projektima.
14.12. Praenje napretka (izvrenja) projekta

Upravljanje projektom podrazumjeva stalni nadzor napredovanja, ta se moe prikazati slijedeim programom, napisanom pomou pseudokoda. Postavljanje projektnih ogranienja Napraviti poetnu procjenu projektnih parametara Definisanje kljunih taaka i izvjetavanje while projekt nije zavren ili otkazan loop Nacrtaj vremenski raspored projekta Podijeli aktivnosti prema vremenskom rasporedu ekaj Provjeri napredak projekta Revizija procijenjenih projektnih parametara Auriranje vremenskog rasporeda projekta Provjeri projektna ogranienja i izvjetaje If (poveanje problema) then Ponovni tehniki pregled i mogua revizija end if end loop
243
Na slici 14.11 je prikazan primjer dijagrama za praenje napretka projekta, dok je na slici 14.12 prikazan primjer tabele za evidentiranje napretka.
P1
prilagoavanje plana
D1 plan
projekta
P2
praenje napretka
O rukovodilac projekta
lan ekipe
D2 radnih sati
evidencija
Slika 14.11. Primjer dijagrama za praenje napretka.

Zadatak Izvrioci Planirani poetak Planirani zavretak Prioritet Planirano trajanje Stvarno trajanje Status % ispunjenja Stvarni zavretak Kanjenje Komentar
Slika 14.12. Primjer tabele za evidentiranje napretka.
14.13. Preporuke za planiranje poslova

Planiranje poslova: Planovi moraju biti aurni, tj. prilagoeni stvarnom stanju. Izbjegavati detaljno planiranje poslova koji slijede u daljoj budunosti. Takve je dovoljno predvidjeti i najaviti, a panju usmjeriti na probleme koji se trenutno rjeavaju. Planovi trebaju biti to krai, kako se vrijeme ne bi troilo na detaljiziranje koje zbog mogue promjene stanja ionako nee biti istinito. Konkretno razdoblje za koje se radi plan moe varirati u zavisnosti o veliini projekta. Naelno je dovoljan jedan plan (i pregled realizacije) mjeseno, s tim da ukljuuje raspored nedjeljnih aktivnosti. Poslove i zadatke treba uravnoteeno raspodijeliti. Vie panje treba posvetiti lanovima koji zaostaju u izvrenju plana ili rjeavaju sloeniji problem u odnosu na ostale lanove. Po potrebi treba prerasporediti postojee poslove.
244
Komunikacija moe biti: verbalna (brzo sluaj i misli, sporo i jasno govori, biljei izreeno), pisana (sadraj, forma, uestalost), elektronska (E-mail, Chat, News), obavjetavanje (pismenim putem, elektronskom potom), uvanje informacija (mreni rjenik, FTP rjenik, web server) ili u obliku organizacije rjenika (Admin, Materijali, Projekt, Backup, Tmp, itd). Druenja moraju biti efikasna! Izbjegavati raspravu o optepoznatim ili nevanim stvarima. Rasprave treba prekinuti u trenutku kada se pretvore u razgovor o temama koje se ne odnose na posao. Sastanci moraju biti pripremljeni (mjesto, vrijeme, teme, uesnici)! Tehnike za poboljanje rada: Brainstorming (iznoenje ideja), izbjegavanje "jedinih" rjeenja (traenje alternativa), zapisivanje odluka (zapisivanje da bi se izbjegla pogrena tumaenja), konstruktivne povratne informacije (kritikovanje postupaka, a ne osoba), razumijevanje neuspjeha (analiza i poboljanje svega to nije dobro), raspodjela moi i odgovornosti (ravnopravnost, izbjegavanje hijerarhije).
245
15. Primjena i odravanje informacionog sistema

15.1. Uvoenje sistema u primjenu
Uvoenje u primjenu projektovanog informacionog sistema ukljuuje instalisanje opreme, zavrni prenos podataka, te prelazak na novi nain rada. Aktivnosti i preduslovi su: 1. Testiranje sistema, vidjeti taku 12.5; 2. Izrada plana konverzije (migracije) za uspjean prelazak na novi sistem. Definisati nain uvoenja, poslove, odgovornosti, resurse i redoslijed izvedbe, izradu plana testa prihvatljivosti ukoliko nije uraen ranije; 3. Instalacija opreme, aplikacija i baze (baza) podataka novog sistema, inicijalni unos podataka, prenos postojeih podataka uz konverziju, uspostava sistema zatite i odravanja; 4. Poduka tehnikog osoblja i krajnjih korisnika, koja moe biti verbalna ili putem raspodjele dokumentacije; 5. Konverzija sistema, prelazak na novi nain rada, evaluacija projekta i sistema. Uvoenje sistema moe biti neposredno i paralelno. Neposredno uvoenje podrazumjeva poetak rada novog sistema uz istovremeni prestanak rada starog sistema. Provodi se na odreeni dan, uobiajeno nakon zavretka poslovnog razdoblja, po mogunosti na kraju sedmice. Mogui problemi su pojava greaka koje nisu bile uoene tokom testiranja, nepredvieno preoptereenje opreme u punom pogonu. Nedostatak je neposredna izloenost korisnika grekama sistema. Paralelno uvoenje podrazumjeva istovremeni rad starog i novog sistema tako dugo dok se ne pokae da novi sistem ispravno radi i da su se korisnici navikli na novi nain rada. Bitno je manje rizian postupak u odnosu na neposredno uvoenje. Nedostatak je potreba za dvostrukom obradom istih podataka, u starom i u novom sistemu, to stvara otpor korisnika. Korisnici mogu biti rasporeeni na razliitim lokacijama. Probno uvoenje je neposredno/paralelno uvoenje sistema na jednoj lokaciji, a zatim i na ostalim lokacijama, nakon to se utvrdi da sistem ispravno radi. Postupno uvoenje je uvoenje grupa lokacija, dok istovremeno uvoenje predstavlja jednovremeno uvoenje na svim lokacijama. Modularno uvoenje je postupna zamjena starog sistema novim, uvoenjem po dijelovima. Izvodljivo je samo ako je mogu istovremeni rad oba (nekompletna) sistema. Mogui problemi su potreba za spojnim programima, tj programima za premoavanje.
246
Karakteristike razliitih naina uvoenja sistema u primjenu su prikazani u tabeli 15.1. Tabela 15.1.
Uvoenje Rizik Troak Trajanje
neposredno paralelno ostalo
visok nizak srednji
niski (ako uspije) visok srednji
kratko (ako uspije) dugo varijabilno
15.2. Obuka korisnika IS

Vri se obuka tehnikog osoblja korisnika i krajnjih korisnika sistema. Obuka krajnjih korisnika moe ukljuivati optu informatiku kulturu (npr. upotreba personalnih raunara), funkcije sistema i nain upotrebe sistema, to jest koritenje aplikacija, ili obuku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr. operaciona istraivanja, projektovanje primjenom raunara i sl.). Obuka tehnikog osoblja moe ukljuivati operativni sistem i uslune programe, administriranje baze podataka, programske jezike i CASE alate. Redoslijed obuke je slijedei. Prvo se obavlja obuka tehnikog osoblja koje e odravati sistem i pruati podrku krajnjim korisnicima, da bi se mogla pokrenuti primjena IS. Nakon toga treba obrazovati (nie) rukovodstvo, da bi se stekla njegova podrka pri obuci ostalih korisnika tokom primjene. Slijedi kolovanje (krajnjih) korisnika, koje treba prilagoditi funkcijama koje oni obavljaju u svakodnevnom radu. Postupci i tehnike obuke su kursevi, probni rad u fazi provjere rada sistema, kvalitetni sistem interaktivne pomoi, prikladna dokumentacija i podrka tokom primjene. Obuku mogu obaviti radnici naruioca (npr. odjel informatike ili grupa za to odabranih i osposobljenih radnika) ili vanjski izvoai obuke.
15.3. Odravanje informacionog sistema

15.3.1. Odravanje i nadgradnja
Odravanje je trajna aktivnost koja zapoinje odmah nakon uvoenja sistema u primjenu. Bez obzira kako je dobro sistem dizajniran, konstruisan i testiran, greke e se neizbjeno pojaviti! Ispravljanje greaka u primjeni se naziva odravanjem sistema ili odravanjem programa. Odravanje samo po sebi ne podrazumijeva ugradnju poboljanja ili novih mogunosti, ali se ona uobiajeno provode.
247
Tokom primjene i odravanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede, te tako zapoinje novi ciklus razvoja.
15.3.2. Odravanje - servisiranje sistema

Preventivno odravanje sistema podrazumijeva zatitu od moguih problema. Potrebno je vriti redovnu izradu sigurnosnih kopija (backup). Bekap se obavlja periodino (dnevno, sedmino, mjeseno). Pod korektivnim odravanjem se podrazumijeva popravka nakon to se problem pojavio. Vri se vraanje podataka iz sigurnosne kopije (restore) ili uklanjanje uzroka greke (ispravljanje programa). Adaptivno odravanje je prilagoavanje funkcionalnosti (naina posluivanja), prilagoavanja strukture (promjene strukture podataka) ili poboljanje performansi (optimizacija programa). Perfektivno odravanje je nadgradnja sistema da bi se rijeili novi problemi ili ugradnja novih mogunosti.
15.3.3. Uklanjanje greaka i izmjene programa

Definicija i validacija problema podrazumjeva uoavanje uzroka greaka u primjeni (bugova), odnosno problem reprodukcije greke, problem razliitog tumaenja greke koje nastaje uslijed nerazumijevanja ili pogrenog koritenja programa. Nepostojanje funkcije ija ugradnja nije bila planirana nije bug. Ocjenjivanje sposobnosti. Odravanje moe imati neeljene popratne uinke na funkcionalnost i performanse aplikacija. Prije izmjene programa, programi treba da budu izmjereni da bi se utvrdila osnovica prema kojoj e se ocijeniti izmijenjeni programi. Editovanje i testiranje. Potrebno je poznavanje programa, odnosno upravljanje verzijama, da bi se izbjegle razliite verzije u primjeni kod razliitih korisnika. Neophodna je mogunost povratka na prethodnu verziju, ako je ta bila bolja. Takoe je potrebno regresivno testiranje, tj. ponavljanje svih testova da bi se provjerilo da izmjene nisu uzrokovale nove greke, kao i auriranje dokumentacije.
15.4. Poboljanje sistema i reinenjerstvo

Poboljanje sistema je dorada i nadgradnja sistema prema novim zahtjevima, analiza novih zahtjeva i povratak u odgovarajuu fazu (analiza, dizajn, izrada). Veina
248
novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim informacijama ili novim idejama (eljama korisnika). Reinenjerstvo. Neke aplikacije je teko odravati (npr. uslijed zastarjelosti tehnologije), a troak odravanja pojedinih aplikacija moe dosei troak izrade novih. Reinenjerstvo je adaptacija sa ciljem smanjenja trokova odravanja, odnosno prilagoavanje veim promjenama tehnologije, ispravka sistema prije nego to doe do mogueg prekida u radu, kao i ispravka sistema koji e biti lake popraviti ako doe do prekida. Pisanje jednostavnih novih programa. Jednostavni program je onaj program koji koristi samo postojee podatke. Primjeri takvih programa su pretraivanje i pregledanje podataka, kao i generisanje izvjetaja. Ove promjene su najee i najsigurnije. Restukturiranje datoteka i baza podataka je promjena strukture u postojeoj bazi podataka. Prelazak na novu tehnologiju upravljanja podacima predstavlja veliki rizik. Reinenjerstvo programa je reorganizacija koda, odnosno restrukturiranje organizacije modula ili programske logike. Konverzija koda je prelazak na novi programski jezik. Rezanje koda ili odsjecanje koda je izdvajanje dijelova programa radi izrade odvojenog programa ili potprograma. Poboljanja i reinenjerstvo moraju biti planski provedeni.
15.5. Elementi konfiguracije

Element konfiguracije (prema IEEE) je agregacija hardvera i/ili softvera koja se tretira kao jedinka u procesu upravljanja konfiguracijom. Konfiguracija je imenovani skup konfiguracijskih elemenata u odreenoj taki ivotnog ciklusa, slika 15.1.
Slika 15.1. Konfiguracija elemenata u odreenoj taki ivotnog ciklusa.
249
Verzije konfiguracije su slijedee: verzija (version) odreeno izdanje (issue, release) proizvoda, objava, isporuka (release) originalna verzija u primjeni, npr. zadnja v2.0, revizija (revision) ona koja se koristi umjesto originalne, podrazumijeva izmjene u odreenim vremenskim intervalima, npr.v1.2, varijanta (variant) alternativa originalu (hardverska platforma, razliiti jezik), ivi paralelno sa njim, npr. v1.1.2.1. Na slici 15.2 shematski su prikazane navedene verzije konfiguracije.
V 1.0 V 1.1 V 1.2 V 2.0
V 1.1.2.1 V 1.1.4.1
V 1.1.2.2 V 1.1.4.2
Slika 15.2. Verzije konfiguracije.
250
251
Literatura
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Axosoft Company - http://www.axosoft.com/, 2005. Axtools - http://www.axtools.com/, 2006. Awad A.M.: System Analysis and Design, Irwin, 1985. Avison, D.E. & Fitzgerald, G.: Information Systems development: methodologies, techniques and tools, 2nd. ed. McGraw-Hill, 1998. Blum, B.I.: A taxonomy of software development methods, Comm. Of the ACM, vol. 37 (no. 11), 82-94, 1994. Boehm, B.W.: Seven Basic Principles of Software Engineering, Journal of Systems & Software, 3(1), March 1983, pp. 3-24, 1983. Brooks, F.P.: The Mythical Man Month, AddisonWesley, 1975. Brooks, F.P.: No silver bullet: essence and accidents of software engineering, Computer vol. 20 (no 4), pp. 10-19, 1987 Cameron, J.R., Campbell, A. & Ward, P.T.: Comparing software development methods: example, Information and Software Technology, Vol 33 (no. 6), pp. 386 402, 1991. Carnegie Mellon University, Software Engineering Institute - http://www.sei. cmu.edu/seihome, 2006. Cattel R. G. G.: Object Data Management, Object-Oriented and Extended Relational Database Systems, Addison - Wesley Publishing Company, 1991. CollabNet, Inc. - http://argouml.tigris.org/, 2006. Construx Software - http://www.construx.com/doc.htm, 2006. Enterprise IT Management (EITM) - http://www3.ca.com/Solutions/, 2006. ZPM & FER - http://www.zpm.fer.hr, 2005. Grady Booch, James Rumbaugh and Ivar Jacobson: The Unified Modeling Language (UML), User Guide, Rational Software Corporation, Original Copyright by Addison Wesley Longman, Inc., 1999. Harel, D.: Biting the Silver Bullet: Toward Brighter Future for System Development, Computer, vol. 25 (no.1), pp. 8-20, 1992. Hirscheim, R. and Klein, H.K.: Four paradigms of information systems development, Comm. of the ACM, Vol 32 (no. 10), pp. 1199 1216, 1989. Hoffer A. J., George F. J., Valacich S. J.: Modern Systems Analysis and Design, 3/e, Prentice Hall College Div., 2001. Hornby, P et all: Human and organisational issues in information systems development Behaviour and Information Technology, vol.11 (no. 3), pp. 160-174, 1992. IEEE Std 610.12-1990: "Standard Glossary of Software Engineering Terminology" in IEEE Software Engineering Standards Collection, New York, pp. 67, 1994. Institute of Electrical and Electronics Engineers, Inc. - http://www.swebok.org/, 2001.
252
23. Intelligentedu.com - http://www.intelinfo.com, 2006. 24. JYACC Company - http://www.prolifics.com/do/panther.html, 2005. 25. Kim Won: Introduction to Object-Oriented Databases, The MIT Press Cambridge, Massachusetts, London, 1992. 26. Lazarevi B., Jovanovi V., Vukovi M.: Projektovanje informacionih sistema, I deo, Nauna knjiga, Beograd, 1986. 27. Lazarevi B., Dizdarevi P., Jovanovi V.: Projektovanje informacionih sistema, II deo, Nauna knjiga, Beograd, 1986. 28. Maciaszek L: Requirements Analysis and System Design: Developing Information Systems with UML, 1/e, Addison Wesley Higher Education, 2002. 29. McConnell S.: Software Project Survival Guide Microsoft Press, ISBN: 1-57231621-7, 1998. 30. McLeod R., Jordan E.: Systems Development: A Project Management Approach, ISBN: 0-471-22089-2, Wiley Higher Education, 2002. 31. Mogin P., Lukovi I., Govedarica M.: Principi projektovanja baza podataka, STYLOS, Novi Sad, 2000. 32. Murch R.: Project Management: Best Practices for IT Professionals, 1/e, Prentice Hall PTR, ISBN 0-130-21914-2, 2000. 33. Object Management Group, Inc. - http://www.omg.org/uml/, 2006. 34. Objektno - orijentisani pristup razvoju informacionih sistema, Fakultet organizacionih nauka, Institut za organizacione sisteme, Beograd, 1998. 35. Original Copyright by IBM: The Business System Planning (BSP), 1991. 36. Poliuk E. J.: Software etvrte generacije ORACLE, NIP "Tehnika knjiga", Beograd, 1991. 37. Poliuk, E. J.: Baze podataka, Informatika literatura JEP (vlastito izdanje), Podgorica, 2003. 38. Poliuk, E. J.: Informacioni sistemi (skripta), Elektrotehniki fakultet, Podgorica, 2004. 39. Poliuk, E. J.: Ekspertni sistemi, Informatika literatura JEP (vlastito izdanje), Podgorica, 2004. 40. Poliuk, E. J.: Multiprocesorski i distribuirani raunarski sistemi (skripta), Elektrotehniki fakultet, Podgorica, 2004. 41. Poliuk, E. J.: Projektovanje informacionih sistema pomoci CASE alata (skripta), Elektrotehniki fakultet, Podgorica, 2004. 42. Poliuk, E. J.: Objektne baze podataka (skripta), Elektrotehniki fakultet, Podgorica, 2005. 43. Poliuk E. J.: Prilog metodologiji razvoja sistema za podrku odluivanju i ekspertnih sistema, (doktorska disertacija), Sveuilite u Zagrebu, 1992. 44. Poliuk E. Jaroslav: Neproceduralni razvoj informacionih sistema, (magistarski rad), Postdiplomske studije informatike na Univerzitetu u Banja Luci, 1990.
253
45. Poliuk E. J.: Projektovanje informacionih sistema (skripta), Elektrotehniki fakultet, Podgorica, 1998. 46. Poliuk E. J.: Savremeni pristup razvoju informacionih sistema, PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1991. 47. Poliuk E. J.: Informatika organizacija ili "organizacija budunosti", PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1992. 48. Poliuk E. J.: Novi pristup razvoju informacionih sistema, JISA INFO, asopis Jugoslovenskog informatikog saveza , Beograd, 1996. 49. Poliscuk E. J.: Some Features of Object Data Management Concepts, INFO SCIENCE, Journal of Information, Comunication and Computer Sciences, Beograd, 1998. 50. Poliuk E. J.: Neke osobine sistema za objektno upravljanje podacima, IV nauno - struni skup: Informacione tehnologije - sadanjost i budunost, Zbornik radova sa IV nauno strunog skupa IT '99, abljak, 1999. 51. Poliuk E. J.: Koncepti hijerarhija klasa i naslijeivanje u objektno orijentisanom modelu podataka, VI nauno - struni skup: Informacione tehnologije sadanjost i budunost, Zbornik radova sa VI nauno strunog skupa IT 01, abljak, 2001. 52. Poliuk E. J.: Neki aspekti razvoja sistema za podrku odluivanju, III meunarodni simpozij informacijske i komunikacijske tehnologije u uredskom poslovanju '92 "OFFICE AUTOMATION", Sveuilite u Zagrebu, Zbornik radova '92 OFFICE AUTOMATION, Varadin, 1992. 53. Poliuk E. J.: Informatiko obrazovanje "inenjera budunosti", V meunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova I, Novi Sad, 1995. 54. Poliuk E. J.: Neki problemi korienja informacione tehnologije, VI meunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova, Apatin, 1996. 55. Poliuk E. J.: Koncepti objektno orijentisanog modela podataka, IX meunarodna konferencija "Informatika u obrazovanju, kvalitet i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova, Zrenjanin, 2000. 56. Poliscuk, E. J.: The Analysis Of Experimental Results Of Machine Learning Approach, Journal of Information and Organizational Sciences, ISSN 0351-1804, vol. 27, No. 1, pp. 29-42, 2003. 57. Poliscuk, E. J. and Stojanovic, D. R.: The Intelligent Agent: An Analysis of the Experimental Results, WSEAS Transactions on Systems, ISSN 1109 - 2777, Issue 10, Vol. 3, pp. 3248 3253, 2004. 58. Poliscuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Journal of Quantitative Linguistics, Taylor & Francis Group, ISSN 0929 6174, Vol. 11, No.3, pp. 215-233, 2004.
254
59. Poliuk, E. J.: Automatic Programming Systems Dedicated for Proving of Theorems, WSEAS Transactions on Computers, ISSN 1109 - 2750, Issue 2, Vol. 5, pp. 261-266, 2006. 60. Poliscuk, E. J.: Intelligible Automated Reasoning: Systems with the Resolution, Induction and Symmetry, Journal of Applied Computer Science, ISSN 1507-0360, vol.13, No.2, pp. 7-28, 2005. 61. Poliuk, E. J.: Adaptive Machine Reinforcement Learning, Centrum ksiazki akademickiej i naukowe, Motto.Pl-Ksiegarnia Internetowa, http://www.motto.pl/, Krakow, 2005. 62. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Taylor & Francis Group, http://www.citeulike.org/article/84531/, London 2005. 63. Poliuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Universita di Milano, Biblioteca di informatica, http://fantomas.usr.dsi.unimi.it/, Milano, 2005. 64. Poliuk E. J.: Automatic Theorem Proving: Situation Management and Decision Making, Emerging Technologies, Robotics and Control System, International Society for Advanced Research, Vol. 2, pp. 154-167, 2007. 65. Popkin Software - http://www.popkin.com/, 2005. 66. Pressman R.S.: Software Engineering: A Practitioner's Approach, 5/e, McGrawHill, ISBN 0-07-249668-1, 2001. 67. ProxySource, Inc. - http://www.proxysource.com/, 2003. 68. Rational Software Corporation - http://www.rational.com, 2006. 69. R.S. Pressman & Associates, Inc. - http://www.rspa.com/docs/index.html, 2006. 70. R.S. Pressman & Associates, Inc. - http://www.rspa.com/apm/index.html, 2006. 71. School of Computing at Queen's University Canada - http://www.qucis.queensu.ca /Software-Engineering/ tools. html, 2006. 72. SOFTEAM - http://www.objecteering.com/, 2006. 73. Software Engineering Environments at Auburn University - http://www.pittarese. com/Auburn/cse625/case.htm, 1998. 74. Sommerville, I.: Software Engineering, Addison-Wesley Publishing Company, 2000. 75. Sparx Systems Pty Ltd. - http://www.sparxsystems.com.au/, 2006. 76. Standish Group International, Inc. - http://www.standishgroup.com, 2006. 77. Steve McConnell's: Software Project Survival Guide (Microsoft Press, 1998). 78. http://www.construx.com/survivalguide/, 2005. 79. Visible Systems Corporation - http://www.visible.com/, 2004. 80. Visual Paradigm International - http://www.visual-paradigm.com, 2006. 81. Whitten J. L., Bentley L. D., Dittman K. C.: Systems Analysis & Design Methods, McGraw-Hill/Irwin; ISBN 0-07-25523-60; 5th ed., 2001.

Informacioni Sistemi (Napredni Kurs)

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Informacioni Sistemi (Napredni Kurs)

Uploaded by

Copyright:

Available Formats

prof. dr ing poliuk e.

projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Prof. dr ing Poliuk E. Jaroslav PROJEKTOVANJE INFORMACIONIH SISTEMA

Kompjuterska obrada knjige: autor E-mail: jaroslav@cg.ac.yu

Sva prava zadrava autor.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

U Podgorici, septembar 2007. god.

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Literatura .......................................................................................................... 251

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1. Opte o informacionim sistemima

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Oekivani efekti ulaganja

Ulaganje u softver, hardver, ljudske resurse i razvoj programskog proizvoda

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.2. Pojam informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

OKOLINA O1 O2 (interfejs) IZLAZ

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.3. Elementi i osobine sistema i informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.4. Vrste informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.5. ivotni ciklus razvoja sistema (Systems Development Life-Cycle (SDLC))

1.5.2. ivotni ciklus i faze razvoja informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Slika 1.4. Prikaz faza ivotnog ciklusa razvoja softvera.

1.6. Kompleksnost razvoja informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.6.2. Neki primjeri neuspjenih projekata i sistema

1.6.3. Uzroci neuspjeha projekata informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

1.6.4. Poboljanje uspjenosti informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2. Planiranje razvoja informacionog sistema

2.1.2. Vanjski razvoj informacionog sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.1.3. Nabavka gotovih aplikacija

2.1.4. Nabavka poslovnih aplikacija

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.1.5. Kriterijumi za donoenje odluke o nabavci

2.1.6. Nabavka izvedbenog programskog koda

2.1.7. Nabavka izvornog programskog koda

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.1.8. Izbor modaliteta razvoja

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.1.9. Ocjenjivanje kriterijuma za izbor sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Na kraju se saberu dodjeljeni bodovi po svim kriterijumima za svaki sistem:

2.1.10. Izbor dobavljaa proizvoda ili usluga

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.2. Analiza izvodljivosti, trokova i koristi projekta

2.2.2. Izvjetaj o izvodljivosti projekta

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

Poliuk E. Jaroslav: Projektovanje informacionih sistema

2.3. Strategija i planiranje razvoja informacionog sistema