PROJEKTOVANJE_INFORMACIONIH

prof. dr ing poliščuk e. jaroslav

projektovanje informacionih sistema

2

Poliščuk E. Jaroslav: Projektovanje informacionih sistema

Prof. dr ing Poliščuk E. Jaroslav PROJEKTOVANJE INFORMACIONIH SISTEMA

Kompjuterska obrada knjige: autor E-mail: [email protected]

Sva prava zadržava autor.


3

PREDGOVOR "Klasična predstava o svemiru, koji se sastoji od materije i energije, mora da ustupi mjesto predstavi o svijetu sastavljenom od tri komponente: energije, materije i informacija, jer bez informacija organizovani sistemi nisu mogući. Jedino moguće materijalističko tumačenje održavanja organizovanosti je neprekidno izvlačenje iz spoljnjeg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju" [A. Lerner, 2003]. Predviđanje sa kraja 2005. godine, koje je objavila kompanija "Gartner" - USA, vodeća u svijetu u analizi kretanja u oblasti globalne industrije informatičke tehnologije, glasi: „Trend automatizacije informatičkih tehnologija će imati veliki uticaj na razvoj softvera, posebno softvera za nadzor sistema, testiranje aplikacija, tehničku podršku i umrežavanje. Neka informatička zaduženja će biti veća, neka će biti umanjena, neka prebačena u druge dijelove kompanije, a neka će biti ukinuta". Specijalizovani informatički radnici, koji se ističu samo svojim poznavanjem informatičkih tehnologija i vještinama vezanim za računare, bez posjedovanja drugih funkcionalnih znanja, biće manje potrebni, predviđaju „Gartner“-ovi analitičari. Prosječno informatičko odijeljenje u srednjim i velikim kompanijama će do 2010. godine biti za trideset procenata manje, tvrde analitičari tržišta kompanije „Gartner“, i zaključuju: „Informatički radnici budućnosti će biti zaposleni u jednom od četiri glavna područja: tehnološkoj infrastrukturi, projektovanju i upravljanju informatičkim sistemima, projektovanju i upravljanju procesima ili upravljanju odnosima“. Osim autorovog iskustva u projektovanju IS, knjiga je, uglavnom, rađena na osnovu dostupne literature i obrađuje savremeni pristup projektovanju IS. Izvori, na osnovu kojih je nastala ova knjiga, jednim dijelom su navedeni u samom tekstu knjige, dok je cjelovit pregled dan u okviru pregleda korištene literature. Zahvaljujem se autorima čiji su manji dijelovi radova, u djelimično izmijenjenom obliku, ušli u sastav ove knjige. Ukoliko njihovo autorstvo nije na svakom mjestu jasno naglašeno, taj propust će rado biti naknadno otklonjen. U pojedinim slučajevima bilo je nemoguće razgraničiti autorstvo pojedinih tekstova, jer se isti ili sličan tekst mogao naći u različitim izvorima. Knjiga je, prvenstveno, namjenjena studentima postdiplomskog specijalističkog studija Elektrotehničkog fakulteta u Podgorici i može poslužiti kao potrebna literatura.

4


Knjiga može korisno poslužiti projektantima IS, kao i svima koji se bave razvojem savremenih IS ili žele da se detaljnije upoznaju sa ovom oblasti.

U Podgorici, septembar 2007. god.

Autor


5

SADRŽAJ 1. Opšte o informacionim sistemima ........................................................... 1.1. Uvod ...................................................................................................... 1.2. Pojam informacionog sistema................................................................ 1.3. Elementi i osobine sistema i informacionih sistema .............................. 1.4. Vrste informacionih sistema .................................................................. 1.5. Životni ciklus razvoja sistema ................................................................ 1.6. Kompleksnost razvoja informacionog sistema ......................................

9 9 11 13 15 16 18

2. Planiranje razvoja informacionog sistema .............................................. 2.1. Modaliteti razvoja informacionog sistema ............................................. 2.2. Analiza izvodljivosti, troškova i koristi projekta ...................................... 2.3. Strategija i planiranje razvoja informacionog sistema ............................ 2.4. Modeli razvoja informacionih sistema .................................................... 2.5. Metodologija razvoja informacionih sistema .......................................... 2.6. Savremeni postupci razvoja informacionog sistema ..............................

21 21 27 30 38 48 51

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 ...................................

57 57 60

4. Analiza sistema ........................................................................................... 4.1. Uvod u analizu sistema .......................................................................... 4.2. Aktivnosti analize ................................................................................... 4.3. Definisanje zahtjeva koje sistem mora posjedovati ...............................

67 67 67 69

5. Modeliranje funkcija i procesa .................................................................. 77 5.1. Uvod u modeliranje funkcija i procesa ................................................... 77 5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnoloških procesa ................................................... 83 5.3. Modeliranje toka podataka ..................................................................... 89 5.4. Elementarni procesi ............................................................................... 98

6


6. Modeliranje podataka ............................................................................... 101 6.1. Osnovni pojmovi modela podataka ...................................................... 101 6.2. Razvoj modela podataka ..................................................................... 111 6.3. Logičko modeliranje podataka ............................................................. 116 7. Modeliranje događaja ................................................................................. 123 7.1. Modeliranje procesa vođeno događajima .............................................. 123 7.2. Matrica entiteti/događaji ......................................................................... 124 7.3. Model istorije života entiteta .................................................................. 128 7.4. Dijagram prelaza stanja ...........................................……………………. 129 7.5. Mape dijaloga ……………………………..………………………………… 130 8. Inženjerski pristup izgradnji IS ................................................................. 132 8.1. Uvod ...................................................................................................... 132 8.2. Programsko inženjerstvo ....................................................................... 133 8.3. Informaciono inženjerstvo ..................................................................... 134 8.4. Sistemsko inženjerstvo ......................................................................... 135 8.5. CASE proizvodi ..................................................................................... 136 8.6. Reverzno inženjerstvo ........................................................................... 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 očuvanje integriteta ............................................ 165 10.5. Podešavanje baze podataka .............................................................. 166 10.6. Trigeri u relacionim bazama podataka ............................................... 168 10.7. Implementaciono projektovanje, generisanje i programiranje BP pomoću CASE alata ............................................... 176 10.8. Šifarski sistem .................................................................................... 180 10.9. Rječnik podataka – katalog ................................................................ 181 11. Dizajn programske podrške ..................................................................... 11.1. Specifikacija i dizajn programske podrške ......................................... 11.2. Pristup oblikovanju programa ............................................................. 11.3. Strukturirani dizajn ............................................................................. 11.4. Dizajn interfejsa .................................................................................. 11.5. Ulančavanje procedura .................................................................... 11.6. Organizacija modula i aplikacija ........................................................ 11.7. Standardizacija i modularnost programske podrške .......................

186 186 186 187 191 194 195 196


7

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 .........................................................................

201 201 201 202 204 209 211

13. Logičko 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 odlučivanja .............................................................................. 13.5. Tabele odlučivanja .............................................................................. 13.6. Struktogram ........................................................................................ 13.7. Programski jezici ................................................................................

213 213 216 221 222 224 225 226

14. Organizacija i upravljanje projektom ....................................................... 14.1. Generički 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. Praćenje napretka (izvršenja) projekta ............................................ 14.13. Preporuke za planiranje poslova .....................................................

233 233 233 234 235 236 236 237 238 239 240 241 242 243

15. Primjena i održavanje informacionog sistema ....................................... 15.1. Uvođenje sistema u primjenu ............................................................. 15.2. Obuka korisnika IS ............................................................................. 15.3. Održavanje informacionog sistema .................................................... 15.4. Poboljšanje sistema i reinženjerstvo .................................................. 15.5. Elementi konfiguracije ........................................................................

245 245 246 246 247 248

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

8



9

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

10


tehnikom povezivanja programa, pisanih pomoću 3GL, sa asemblerskim programima, ili daljim povećanjem mogućnosti samih 3GL. Međutim, očekivanja da će programski proizvodi, koji su razvijeni upotrebom 3GL, pratiti potrebe krajnjih korisnika i mogućnosti 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 očekivani efekti od razvoja programskih proizvoda brzo izostaju, bez obzira na znatno povećanje ulaganja u ovu djelatnost, što je ilustrovano dijagramom na slici 1.1. Identifikovani su slijedeći problemi kroz koje se softverska kriza prelamala. Programiranje upotrebom 3GL je bilo neefikasno i dugotrajno. Najveći dio programerskog vremena je odlazio na održavanje postojećih programskih proizvoda, što je blokiralo dalji razvoj IS. Tvrdnja da je najveći dio programerskog vremena odlazio na održavanje postojećih programskih proizvoda se može potkrijepiti slijedećim statističkim podacima. Prema tim podacima 64% grešaka pri razvoju IS se pravilo u toku analize korisničkih zahtjeva i projektovanja IS, dok se preostalih 36% grešaka pojavljivalo tokom realizacije IS. Od pomenutih 64% „ranih“ grešaka, svega 30% je otklonjeno prije isporuke softvera. Pri tome, kasno otkrivanje i otklanjanje grešaka iz početnih faza razvoja programskih proizvoda dovodi do eksponencijalnog rasta troškova uvođenja u upotrebu i održavanje proizvoda. Tako, na primjer, otklanjanje strateške greške u fazi održavanja košta 100 puta više nego kad se greška otkrije na početku rada na projektu. Ovo je dovelo do jedne „neprirodne“ raspodjele finansijskih sredstava, uloženih u razvoj IS, prema kojoj preko 70% ukupnih sredstava uloženih u razvoj IS odlazi na njegovo održavanje [Mogin et al. 2000].

Očekivani efekti ulaganja

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

Slika 1.1. Grafički prikaz fenomena „softverska kriza“. Povećanje cijene održavanja i neefikasno programiranje su doveli do velikih zakašnjenja 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 slijedeći uzroci softverske krize: 1. Projektovanje IS bez primjene odgovarajuće metodologije dovodi do lošeg projekta, pojave velikog broja grešaka i prekoračenja zadanih vremenskih rokova završetka projekta; 2. Nedostatak softverskih alata, koji bi podržali projektovanje IS ili automatizovali postupke projektovanja sa dovoljnim nivoom ekspertskog znanja. Ovo, takođe, vodi ka nekvalitetnom projektu uslijed otežanog rukovođenja projektom, fragmentiranog i nekonzistentnog dokumentovanja i neusaglašenosti dijelova projekta IS; 3. Nedostatak odgovarajućih softverskih alata za razvoj aplikacija IS, što vodi ka neefikasnoj realizaciji i održavanju IS. Svi ovi uzroci su doveli do prethodno opisanih posljedica. Rješenje softverske krize je, prema tome, trebalo tražiti 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 podrške odgovarajućim tehnikama i metodologijama.

1.2. Pojam informacionog sistema Metodologija razvoja informacionih sistema (IS) treba da bude opšta, primjenljiva na sisteme bilo koje vrste, odnosno na neki "opšti sistem". Zahtjeva da se precizno definiše šta se pod pojmom IS podrazumjeva, koje su njegove funkcije i kakav je njegov položaj u sistemu u kome djeluje. Iz tih razloga je potrebno poći od slijedećih opštih 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 definišu 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 može predstavljati poslovni sistem, mrežu puteva ili ulica, sistem za prenos električne energije, cirkulaciju


12

dokumenata unutar nekog poslovnog sistema, kretanje materijala koji se obrađuje, itd. Objekti u sistemu mogu biti veoma različiti, a veze izmedju objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri načina: razmjenom materije, energije ili informacija.

OKOLINA

ULAZ

O1

O2

O3

On

(interfejs) IZLAZ

Slika 1.2. Opšti prikaz sistema. Riječ informacija, u svakodnevnom govoru, ima smisao obavještavanja, objašnjenja, prenošenja znanja. Za pojam informacije uobičajene su slijedeće definicije: "Informacija je kapacitet povećanja znanja" [I. Wilson, 1975]; "Informacija je nešto što ukida ili smanjuje neodređenost" [N. Winer, 1979]. Iz ugla upravljanja i donošenja odluka, informacija se može razmatrati kao svaka vrsta znanja ili poruka koja može da se upotrijebi za poboljšanje upravljanja u nekom sistemu. Ako se povežu definicije pojmova sistema i informacije, može se izvesti slijedeća opšta definicija informacionog sistema: Informacioni sistem (eng. Information System) je sistem u kome se veze izmedju objekata i veze sistema sa okolinom ostvaruju razmjenom informacija. Takođe, informacioni sistemi su sastavni deo upravljanja ("održanja željene organizovanosti") nekog sistema. Iz tog ugla posmatranja može im se pridodati atribut "upravljački" i definisati upravljački IS kao sistem koji prenosi, čuva i obrađuje podatke pretvarajući ih u informacije potrebne za upravljanje. Pojmovi podatak i informacija se, u svakodnevnom govoru, koriste kao sinonimi. Medjutim, za precizno razgraničenje koncepata o kojima se govori, neophodno je i ova dva pojma precizno definisati i razgraničiti.


13

Podatak je kodirana predstava o nekoj činjenici iz realnog svijeta, on je nosilac informacije i služi za tehničko uobličavanje informacija, kako bi se one mogle sačuvati ili prenijeti. Informacija je protumačeni podatak o pojavi koju podatak prikazuje. Krajnje tumačenje nekom podatku daje sam primalac (čovjek), uz pomoć različitih 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 postojeće znanje. Isti podaci mogu biti različito interpretirani od strane različitih ljudi u zavisnosti o njihovom znanju.

1.3. Elementi i osobine sistema i informacionih sistema Mogu se izdvojiti slijedeći elementi sistema i definisati njihove glavne osobine: 1. Podsistemi, odnosno komponente koje pripadaju sistemu; 2. Granice, definišu opseg i domašaj sistema; 3. Okolina je sve što je izvan granica sistema, ali se još uvijek tiče sistema; 4. Ulazi su elementi koji ulaze u sistem iz okoline; 5. Izlazi su elementi koji napuštaju sistem; 6. Interfejs je veze između sistema i njegove okoline; 7. Ograničenja, koja sačinjavaju unutrašnji i vanjski činioci koji određuju i ograničavaju funkcionisanje sistema; 8. Karakteristike, integrisanost.

koje

opisuju

organizaciju,

interakciju,

međuzavisnost

i

Organizacija je struktura i poredak, odnosno hijerarhijske veze koje određuju formalnu komunikaciju i upravljački lanac (npr. ustanova, preduzeće). Interakcija predstavlja način na koji pojedine komponente sarađuju sa drugim komponentama (npr. Nabavka sa Proizvodnjom, Proizvodnja sa Prodajom). Međuzavisnost 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 obavještavanje, odnosno informacioni sistemi; (2) sistemi za upravljanje informacijama važnim za organizaciju i društvo; (3) sistemi za upravljanje sadržajem ljudskih aktivnosti [Checkland, 1980]. Pojam informacionog sistema podrazumijeva sisteme koji su podržani računarom, tj. računarski (“kompjuterizovani”, “kompjuterski”) i sisteme koji se ne oslanjaju na računare, ali obrađuju informacije. Namjena IS je prikupljanje i pružanje informacija korisnicima u jednom ili više 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 sačinjavaju ga: prikupljanje podataka, zapisivanje i pamćenje podataka, obrada podataka, skladištenje i pronalaženje informacija, kao i prikaz informacija u odgovarajućem obliku. Informacioni sistem je podsistem poslovnog sistema. Sačinjavaju ga ulazni podaci i izlazne informacije, procesi (obrada podataka o stanjima stvarnog sistema) i izvršioci (osobe, programi, računari). Poslovne sisteme sačinjavaju 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 sadrže procese (npr. obrada, prerada, proizvodnja), povratne veze (npr. poređenje plana i realizacije), skladišta podataka (informacija), izvršioce (osobe, mašine, alati, sirovine), skladišta materijala, ... . Informacioni sistem određuju slijedeće karakteristike: složena okolina, koju je teško u potpunosti definisati, složeni interfejs prema okolini, koji uključuje različite ulaze i izlaze, složene veze između ulaza i izlaza (strukturno i algoritmički), kao i veliki obim i složenost podataka. Problemi projektovanja, izrade i održavanja IS se prevazilaze zbog važnosti IS za jedan poslovni sistem. Informacija je postala upravljački resurs jednake važnosti kao što su vlasništvo (osnovna sredstva), ljudski resursi ili kapital. Informacioni sistem sadrži/predstavlja znanje organizacije koju podržava. IS i aplikacije pokazuju se prijeko potrebnim za održavanje konkurentnosti ili postizanje kompetitivnog prestiža poslovnog sistema. Poslovni sistemi u kojima se IS primjenjuju visoko su zavisni o stalnoj raspoloživosti IS kroz duže vrijeme.


15

1.4. Vrste informacionih sistema Mogu se izdvojiti slijedeće vrste informacionih sistema: 1. Transakcioni informacioni sistemi (TIS) [Transaction Processing System (TPS), sinonim Data Processing System], čija je namjena da evidentiraju i obrađuju podatke o poslovnim transakcijama; 2. Upravljački informacioni sistemi (UIS) [Management Information System (MIS)], koji imaju zadatak da podržavaju upravljačku funkciju na osnovu dokazanih matematičkih/statističkih metoda; 3. Sistemi za podršku odlučivanju (SPO) [Decision Support System (DSS)], koji služe za odlučivanje na osnovu nestrukturiranih podataka iz različitih izvora; 4. Izvršni informacioni sistemi [Executive Information System (EIS)], koji predstavljaju podvarijantu IS za izvršne rukovodioce; 5. Ekspertni sistemi (ES) [Expert Systems (ES)], odnosno sistemi sa ugrađenim znanjem i simulacijom zaključivanja; 6. Sistemi za automatizaciju kancelarijskog poslovanja [Office Automation Systems (OAS)]; 7. Sistemi za grupnu podršku [Group Support System, Groupware (GSS)]. Upravljanje i nivoi IS su prikazani tabelom 1.1. Tabela 1.1. Informacioni sistem

Informacije, kada

Korisnici, ko

Upravljanje

Transakcioni

Niže poslovodstvo

Operativno

Upravljački

Obrada podataka, dnevno Zbirne, periodično

Taktičko (trendovi)

Za podršku odlučivanju

Sintetizovane, “ad hoc”

Srednje poslovodstvo Više poslovodstvo, uprava

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 slijedeći nazivi životnog ciklusa: životni ciklus razvoja IS, životni ciklus razvoja softvera i životni ciklus razvoja aplikacija. Praćenje životnog ciklusa obezbjeđuje konzistentan i standardizovan način razvoja IS. Svrha praćenja životnog ciklusa razvoja omogućava pravilno planiranje, izvršavanje i nadzor razvojnog projekta. Životni ciklus definiše faze i zadatke (aktivnosti), koje nužno treba obaviti tokom razvoja, bez obzira na veličinu sistema koji se gradi. Svaka pojedina aktivnost proizvodi skup rezultata. Ciklus osigurava “kontrolne točke” za praćenje napretka, procjenu postignutih rezultata i donošenje odluka o daljnjim koracima. Projekat prolazi kroz faze životnog ciklusa. Primjer: Za životni ciklus razvoja softvera mogu se definisati slijedeće 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); Pojedinačno 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 počinje snimanjem stanja (inicijalna strategija). Doprinosi određivanju poslovnih ciljeva, identifikovanju problema i ideja, određivanju načina njihovog rješavanja, te definisanju zahtjeva koji se postavljaju pred sistem. Sadrži studiju izvodljivosti, odnosno preglednu analizu problemskog područja i


17

određivanje (granica) projekata. Planiranje projekta se sastoji od izrade plana rada, određivanja 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. Vrši se detaljna analiza postojećeg sistema, problema i poslovnih zahtjeva. Specifikacija zahtjeva je detaljni opis zahtjeva za IS, oblikovan tako da ga razumiju dizajneri. Predstavlja model budućeg sistema. Oblikovanje sistema, odnosno dizajn (modeliranje) IS, predstavlja pogled projektanta na budući IS. Služi za donošenje odluke o tome kako graditi sistem. Sadrži dizajn potrebnih rješenja. Postoje rješenja koja ne treba dizajnirati. Detaljni dizajn predstavlja razradu rješenja, odnosno izradu tehnološkog modela IS (pogled izvođača). Potrebno je izvršiti dizajn arhitekture, interfejsa, pohranjivanja podataka i programa, drugim riječima izvršiti tehničku specifikaciju sistema. Izrada (implementacija) podrazumjeva ugradnju baze podataka (BP), kodiranje procesa (funkcija) novog IS, a vrši se nakon odabira računarske platforme. Testiranje je provjera ugrađenih komponenti. Integracija i provjera sistema je udruživanje 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


Uvođenje u primjenu sistema predstavlja prenošenje radnih aktivnosti i konverzija podataka sa starog na novi sistem. Održavanje se sastoji od izmjena sistema radi poboljšanja njegovih radnih karakteristika (performansi), poboljšanja ili prilagođavanja načina upotrebe. Održavanje podrazumjeva i podršku dobavljača opreme, pomoć tehničkog osoblja korisnicima informacionog sistema u toku njegove upotrebe, kao i izradu plana održavanja. Novi razvojni ciklus se provodi nakon preispitivanja čitavog sistema i konstatacije da su potrebne veće izmjene uslijed promjena u poslovanju ili promjena poslovnih ciljeva. Novi razvojni ciklus, najčešće, predstavlja novi projekat. Na slici 1.4 su navedene tipične faze životnog ciklusa razvoja softvera, bez naglašavanja 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: prekoračenje planiranog vremena i finansijskih sredstava, neispunjavanje zahtjeva, odnosno neodgovarajući sistem, nepouzdanost, nesigurnost, neelastičnost IS u primjeni, kao i teškoće u održavanju IS. Oko 70% informacionih sistema u svijetu se smatra neuspješnim. Prosječno koštanje 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 $. Prosječno prekoračenje troškova je 189%, a prosječno prekoračenje rokova 222%. Projekti završeni na vrijeme, u okviru predviđenih sredstava i sa predviđenim funkcijama, sačinjavaju 16,2%, a projekti završeni i u funkciji, ali uz veće troškove, duže trajanje i/ili reduciranu funkcionalnost 52,7%. Prekinutih projekata je 31,1%. Procenat uspješnih i neuspješnih projekata IS prema Standish Group, 2002. iznosi 34% uspješnih projekata i 17% potpunih neuspjeha.

1.6.2. Neki primjeri neuspješnih projekata i sistema London Ambulance System (1992): Nakon uvođenja u eksploataciju IS se dva puta "raspao" zbog niza grešaka, naročito zbog grešaka u upravljanju razvojem IS. Neposredni trošak 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 troška od 75 miliona £, te posljedični gubitak klijenata od 450 miliona £. Ukupni gubici smatra se da su neizračunljivi. Denver Airport (1994): Nepouzdanost softvera za upravljanje prtljagom uzrokovala je odlaganje otvaranja vazdušne luke u trajanju od 16 mjeseci, uz troškove od 1,1 miliona $/dan. Ariane 5 (1996): Raketa eksplodirala u lanseru radi niza softverskih grešaka.

1.6.3. Uzroci neuspjeha projekata informacionih sistema Razlozi neuspješnih projekata IS su različiti. Mogu se izdvojiti slijedeći razlozi: složenost aplikacija, nedostatak usmjerenosti korisniku, zanemarivanje okruženja

20


organizacije, pretjerani optimizam, izostanak praćenja napretka i nedostatak komunikacije između korisnika i izvođača. U našem okruženju uzroci neuspjeha se, uglavnom, ne istražuju, a informacije o neuspješnim projektima nerado se objavljuju. Među najčešćim uzrocima može se pretpostaviti da su: loša organizacija i vođenje projekata, oslonac na vanjske projektante i savjetnike, delegirano upravljanje projektima, nerealno planiranje, formalno izvještavanje o napretku, formalni nadzor nad projektom, kao i podcijenjena uloga vlastitih stručnjaka. Ne treba isključiti i slijedeće uzroke neuspjeha: loša izvedba projekata, neodgovarajuća analiza sistema, greške u dizajnu i kontroli kvaliteta, neodgovarajući CASE alati i krivo korištenje, pa čak i svojevrsna zloporaba CASE alata. Mnogi sistemi su propali, ili su bili odbačeni, jer su se izvođači trudili napraviti lijepa programska rješenja, a nisu razumjeli suštinu poslovnog sistema i poslovanja.

1.6.4. Poboljšanje uspješnosti informacionih sistema Da bi se poboljšala uspješnost IS potrebno je: • projektovanje IS, • planiranje, upravljanje izvedbom, praćenje napretka, • uključivanje korisnika. Korisnik poznaje(?) poslovni proces i zna(?) odrediti potrebe, a informatičar upoznaje(?) poslovanje i zna(?) kako izraditi IS. Važno je da u procesu izgradnje sudjeluje i poslovodstvo, da bi se upoznalo sa stvarnim mogućnostima i koristima uvođenja IS, naročito jer donosi konačne (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 različiti modaliteti razvoja informacionog sistema. U ovoj knjizi će biti razmatrani modaliteti razvoja koji se najčešće koriste. Razvoj vlastitim informatičkim snagama podrazumjeva osposobljavanje i angažiranje netehničkog osoblja, kao i povremeno ili dugoročno angažovanje spoljnih saradnika. Prednosti ovakvog pristupa su fleksibilnost, kreativnost i povećanje stručnosti vlastitog osoblja. Nedostaci su da ovaj pristup zahtijeva značajno vrijeme i napor, razvoj je skuplji i dugotrajniji i može povećati gomilanje zaostalog posla. Razvoj vlastitim snagama ima smisla kada se radi o programskoj podršci koja je posebnost organizacije, takva da ne postoje gotova rješenja na tržištu ili takva da organizacija pomoću nje postiže komparativnu prednost u odnosu na konkurenciju. Postoje dodatni ili posebni razlozi kao što su povećana tajnost podataka i poslovnih procesa ili povećana zaštita IS.

2.1.2. Vanjski razvoj informacionog sistema Angažovanje vanjskih saradnika za razvoj informacijskog sistema, ili njegovih dijelova, podrazumjeva pružanje pomoći u obrazovanju radnika informatičke struke, pomoć pri analizi poslovnog sistema i oblikovanju IS ili obavljanje analize i oblikovanja. Takođe se podrazumjeva kodiranje (generisanje) cjelovitog programskog sistema, upravljanje izvođenjem i/ili nadzor izvođenja, kao i konsultativna pomoć prilikom ugradnje složenih poslovnih funkcija. Varijante su slijedeće: ugovoreni razvoj, odnosno ugovara se isporuka gotovog proizvoda ili dugoročna saradnja sa isporučiocem, uz izdvajanje vlastitog informatičkog odjela u glavnog izvođača. Moguća varijanta je i nalaženje strateškog partnera na duži vremenski period, npr. softverske kuće. Prednosti su višestruke. IS ili njegovi dijelovi izrađuju se po mjeri naručioca, sistem je prilagođen organizaciji/poslovanju, a po mogućnosti treba istovremeno poboljšati organizaciju/poslovanje poslovnog sistema. Ovakav razvoj podrazumijeva dugotrajan postupak i odgovarajuću visoku cijenu.

22


Nedostaci i rizici su takođe prisutni. Dolazi do gubitka povjerljivih informacija, gubitka nadzora nad sadašnjim i/ili budućim razvojem (zavisnost o dobavljaču), kao i gubitak vlastite stručnosti. Nužno je da upravljanje projektom informatizacije na sebe preuzme vlastito kompetentno osoblje koje ima mogućnost odlučivanja.

2.1.3. Nabavka gotovih aplikacija Nabavka gotovih programskih proizvoda po pravilu ne ispunjava u potpunosti poslovne potrebe. Poželjno 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 specijalističke aplikacije za određene namjene. Mogu se nabaviti slijedeći sistemi za upravljanje poslovanjem, koji nose komercijalne nazive: Enterprise Resource Planning (ERP) systems, SAP, BAAN, J.D. Edvards, Peoplesoft. Cjeloviti sistemi za podršku poslovanju, uglavnom, podržavaju slijedeće 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 Slijedeći modalitet razvoja IS je nabavka i prilagođavanje postojećih domaćih poslovnih aplikacija. Prednost ovog pristupa je usklađenost važećim uslovima, npr. propisima, šta olakšava prilagođavanje aplikacija organizaciji/poslovanju. Nedostatci su nepostojanje ili manjkavost pojedinih komponenti, mjestimična tehnološka zastarjelost, prekapacitiranost dobavljača. Modaliteti ovakvog pristupa su slijedeći: otkup izvornog koda i samostalna dorada ili kompletno odsustvo izvornog koda uz samostalno održavanje. Nabavka “gotovih” stranih poslovnih aplikacija, takođe, ima svoje prednosti i nedostatke. Prednosti su raskošna funkcionalnost i kompatibilnost sa svjetskim poslovnim standardima, dok se nedostatci ogledaju u neprilagođenosti domaćim uslovima i konkretnoj organizaciji/poslovanju, šta zahtijeva istovremeno prilagođavanje programske opreme i promjenu organizacije/poslovanja. Prilagođavanje se obavlja slično razvoju, šta može uzrokovati da rješenja gube moguću komparativnu prednost (brzinu i lakoću primjene). Glomazni paketi mogu zahtijevati angažovanje velikog broja


23

konsultanata. Mogući modalitet nabavke je da se prilagođavanje vrši vlastitim snagama uz savjetovanje i pomoć dobavljača.

2.1.5. Kriterijumi za donošenje odluke o nabavci Opšti kriterijumi za donošenje odluke o razvoju IS su: • • • • • •

cijena, funkcionalnost, kapacitet, brzina, broj korisnika, mogućnost obuke i trajne podrške, kredibilitet i održivost dobavljača na tržištu, što se dokazuje referensama, elastičnost, tj. mogućnost prilagođavanja i prepravki, raspoloživost dokumentacije.

U dodatne kriterijume mogu se svrstati: otvorenost sistema (portabilnost, interoperabilnost), tehničke mogućnosti (Client-Server, OLTP, OLAP), referense dobavljača (prisutnost dobavljača na lokalnom tržištu) i podrška korisnicima. Pod podrškom korisnicima se podrazumjeva: školovanje, tehničke konsultacije, održavanje (dinamika razvoja i mogućnosti 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 kôd je jeftiniji, brigu i odgovornost o njegovom održavanju preuzima isporučilac, uz izuzetak nekih opšte primjenjivih komercijalnih programa. Prednost izvedbenog koda je i ta da se ne mora kupiti (skupi) razvojni programski alat u kojem je programski proizvod razvijan. Mane izvedbenog koda, obzirom na korisnika, su: izvedbeni kôd podrazumijeva potpunu zavisnost od isporučioca, ne postoji mogućnost prilagođavanja specifičnim vlastitim potrebama, osim putem posebnog dogovora sa isporučiocem. Dodatna prilagođavanja lako mogu postati predmetom ucjene. Takođe, ne postoji mogućnost razvoja programske opreme vlastitim snagama.

2.1.7. Nabavka izvornog programskog koda Prednosti nabavke izvornog programskog koda su znatne. Izvorni kôd omogućava stalni razvoj i praćenje vlastitih posebnosti, što se može pokazati kao prednost u odnosu na konkurenciju. Osim toga, pruža mogućnost prilagđavanja vlastitim

24


potrebama, šta daje elastičnost pri promjenama organizacije poslovanja. Nema bojazni da će nakon prve potrebne izmjene prestati upotreba IS zbog toga što isporučilac nije trenutno dostupan, postavlja nerazumne uslove ili je u međuvremenu nestao sa tržišta. Uvidom u kvalitetna gotova rješenja pomaže se razvoju vlastitih informatičkih radnika. Mane narudžbe izvornog koda su, takođe, prisutne. Izvorni kôd je višestruko skuplji od izvedbenog. Potrebna je razvojna varijanta programskog alata u kojem je IS razvijen. Naručilac se izlaže iskušenju da nekompetentno mijenja nabavljeni izvorni kôd, onesposobi aplikaciju za rad i izgubi pravo na održavanje. Održavanje je skuplje ukoliko se radi o programskoj opremi podložnoj promjenama. Sniženje cijene izvornog koda može se postići automatizacijom kodiranja, upotrebom generatora izvornog koda. Preporuke za izbor programskog koda su slijedeće. Izvedbeni kôd treba preporučiti u slijedećim slučajevima: • kada se radi o standardnim, masovno prodavanim aplikacijama, • kada korisnik nema vlastite informatičke stručnjake, • kada se radi o visokostručnim aplikacijama koje se neće mnogo mijenjati, a korisnik nema namjeru da se baviti detaljima te struke, • kada korisnik nema novaca ili želje za vlastiti informatički razvoj. Izvorni kôd treba preporučiti onda: • kada programska oprema predstavlja stratešku investiciju, • kada korisnik raspolaže kompetentnim informatičarima ili ima motiva razvijati vlastitu informatičku djelatnost, • kada isporučilac ne može preuzeti obavezu održavanja ili ne može garantovati da će ostati na tržištu, • kada na tržištu ne postoji IS koji odgovara potrebama, ne može se povoljno kupiti sličan, a korisnik raspolaže vlastitim informatičkim snagama dovoljnim za projektovanje novog.

2.1.8. Izbor modaliteta razvoja Određivanje mogućih rješenja podrazumjeva identifikaciju rješenja na osnovu poslovnih zahtjeva postavljenih tokom analize. Ulazi su specifikacija računarske opreme i programske podrške, te odabrana tehnološka arhitektura, dok su izlazi moguća rješenja novog sistema i njihove karakteristike. Analiza izvodljivosti alternativnih rješenja se sastoji od procjena alternativa obzirom na tehničku, operativnu, ekonomsku i vremensku izvodljivost. Ulazi su


25

karakteristike mogućih rješenja, karakteristike i cijene hardvera i softvera, referense i uslovi dobavljača, a izlazi analiza izvodljivosti za svako moguće rješenje. Prijedlog rješenja sistema koji će se oblikovati i ugraditi se donosi na osnovu izbora onog rješenja koje ima najbolju ukupnu kombinaciju izvodljivosti. Ulazi su napravljena analiza izvodljivosti, plan projekta, procjena veličine projekta, a izlazi prijedlog sistema sa usvojenim promjenama dizajna predloženog sistema.

2.1.9. Ocjenjivanje kriterijuma za izbor sistema Na osnovu opisa karakteristika ne može se sa sigurnošću procijeniti koji je sistem najbolji. Da bi se pravilno uporedio značaj različitih kriterijuma koristi se sistem bodovanja. Procedura bodovanja kriterijuma je slijedeća. Odredi se težinski faktor za svaki kriterijum (npr. od 1 do 4). Oni kriterijumi koji su značajniji u uporedbi sistema dobivaju veće težinske faktore. Sistemi se ocjenjuju za svaki kriterijum ocjenom iz dogovorenog raspona (npr. od 0 do 5). Dodjeljena ocjena se pomnoži težinskim faktorom kriterijuma za koji je donesena, te se dobije broj bodova [Fertalj & Kalpić, 2005]. Primjer: Analiza izvodljivosti za moguća rješenja. Tabela 2.1. Karakteristike: Operativni sistem Baza podataka Brzina pretraživanja i dohvat podataka Programski jezik Raspoloživ izvorni kod Korisnički interfejs Integrisani sistem pomoći (on-line help) Dokumentacija (na papiru) Mogućnosti aplikacije Integracija sa drugim aplikacijama Brzina ispisa računa Rad sa različitim štampačima Rad u mreži Vrijeme obuke korisnika Arhiviranje podataka Upotreba konfiguracije za druge poslove Broj instalisanih paketa Datum prve instalacije Cijena paketa Cijena računara i sistemskog softvera

Ukupno bodova:

Težinski Super Video Video Boss Video ZZ Video faktor Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi Ocjena Bodovi 2 1 4 1 1 2 2 2 4 3 4 3 1 1 2 3 1 1 2 3

4 4 5 4 0 5 5 4 5 4 2 5 5 3 5 5 3 3 2 3

8 4 20 4 0 10 10 8 20 12 8 15 5 3 10 15 3 3 4 9

171

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

124

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

97

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

124

26


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

Si = 3sij wj j =1

gdje su: Si = ukupna vrijednost i - tog rješenja, sij = vrijednost j - tog kriterijuma za i - to rješenje, wj = važnost ili težina j - tog kriterijuma. Najbolji je onaj sistem sa najvećim brojem bodova (npr. Super Video, tabela 2.1). Često se mogu javiti slijedeće nedoumice: • Šta učiniti kada su sistemi (pod)jednako bodovani? • Šta učiniti ako pojedino svojstvo ima više podsvojstava?

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


27

2.2. Analiza izvodljivosti, troškova i koristi projekta 2.2.1. Analiza izvodljivosti projekta Za pojedine projekte se vrši analiza njihove izvodljivosti, odnosno mjerenje korisnosti, praktičnosti i isplativosti projekta IS. Ove analize treba da se vrše tokom planiranja, ali i kasnije, npr. nakon faze sistemske analize. Nakon odluke o pokretanju projekta složenost i opseg projekta se mogu promijeniti, te početno izvodljiv projekat može postati neizvodljiv. Praktično gledano, točnost procjene izvodljivosti raste sa dubinom analize. Studija izvodljivosti (feasibility study) sadrži: (1) detaljnu provjeru projekta, koju provode sistem analitičari, (2) procjenu da li je projekat izvodljiv obzirom na raspoloživa sredstva, (3) procjenjuje se da li projekat omogućava poboljšanja, (4) radi se izvještaj o izvodljivosti i prezentira se relevantnim učesnicima radi komentara i mišljenja (može biti dio idejnog rješenja), (5) eventualni povratak u studiju izvodljivosti, odnosno revidirani izvještaj.

2.2.2. Izvještaj o izvodljivosti projekta Izvještaj o izvodljivosti projekta sačinjavaju slijedeće analize: • • • •

organizaciono - operativna izvodljivost, tehničko - tehnološka izvodljivost, vremenska izvodljivost, ekonomska izvodljivost.

Analiza organizaciono - operativne izvodljivosti projekta sadrži procjenu hitnosti rješavanja problema (planiranje), kao i procjenu prihvatljivosti rješenja (kasnije faze). Tu se neminovno nameću i slijedeća pitanja: Vrijedi li rješavati problem? i Da li predloženo rješenje rješava problem? Da bi se odgovorilo na ova pitanja potrebno je analizirati: performanse (odnosno protočnost i odziv sistema u odnosu na ulaze), informacije (da li su dovoljne, pravovremene, prikladne, ažurne, tačne, korisne), ekonomiske aspekte (gdje spadaju problemi troškova i mogućnosti ušteda), kontrolu (u prvom redu sigurnost i zaštitu podataka), efikasnost (odnosno poboljšavanje upotrebe raspoloživih resursa: ljudi, opreme, novca, itd.), kao i usluge (poželjni i pouzdani servisi, elastičnost i mogućnost prilagođavanja, zadovoljstvo). Ništa manje bitni nisu ni odgovori na slijedeća pitanja: Koji je stav korisnika prema rješenju? i Da li će se sistem koristiti? Neophodni su podrška uprave i prihvatanje sistema od krajnjih korisnika. Treba na vrijeme uočiti otpore ulozi ili tehničkim

28


rješenjima sistema i predložiti načine njihovog otklanjanja. Krajnjeg korisnika treba na vrijeme pripremiti za promjenu radnog okruženja i procedura. Procjena upotrebljivosti sistema se najlakše može izvršiti korištenjem prototipa. Potrebno je pravilno ocjeniti potrebno vrijeme osposobljavanja korisnika za postizanje pune primjene sistema. Namjeniti jednostavni interfejs za početnike i povremene korisnike, složenije operacije za iskusne korisnike. Obezbjediti da korisnik daje prednost ponuđenom rješenju u odnosu na postojeći način rada. Analiza tehničko - tehnološke izvodljivosti projekta sadrži procjenu mogućih rješenja i alternativa. U prvom redu potrebno je izvršiti procjenu stanja na tržištu opreme, procjenu postojećih rješenja u drugim organizacijama (tamo gdje je moguće), kao i procjenu primjenjivosti različitih tehnologija. Veoma bitna osobina je da se zastupljena tehnološka rješenja mogu jednostavno primijeniti. Raspoloživost tehnologije podrazumijeva da se primjenljiva tehnologija može nabaviti. Ako je riječ o gotovom rješenju, ima li to rješenje potrebne karakteristike, ili ga u nekoj mjeri treba prilagoditi ili doraditi. Ništa manje bitno nije ni činjenica da li postoje potrebni stručnjaci za primjenu nove tehnologije. Pri tome treba imati na umu da se i najnovija tehnologija može savladati. Analiza vremenske izvodljivosti projekta treba da dâ odgovor da li su predviđeni rokovi ostvarivi, obzirom na raspoloživu stručnost. Očekivano vrijeme završetka može biti poželjno ili obavezno. Bolje je isporučiti ispravan sistem dva mjeseca kasnije, nego neispravan ili beskoristan na vrijeme! Ekonomska izvodljivost projekta će biti objašnjena preko analiza i uporedbe ukupnih troškova - koristi (cost-benefit analysis (CBA)). Troškovi i korist mogu biti mjerljivi (npr. cijena opreme, iznos plata, prodaja, prihod, ...) i nemjerljivi (npr. zadovoljstvo korisnika, brzina odlučivanja, dobra referensa). Finansijski trošak i korist se mogu izraziti formulama: (1) razlika korist – trošak u nekom razdoblju (Net Present Value), (2) povrat investicije (korist – trošak)/trošak (Internal Rate of Return), (3) trenutak u kojem korist nadvlada trošak (Payback Point). CBA računa troškove i korist projekta kao trenutnu vrijednost (Present Value (PV)). Današnja vrijednost onoga što će postati $1,00 nakon ‘n’ godina u budućnosti, ako se uzmu u obzir kamate ‘I’ iznosi: PV = 1/(1 + I)n = (1 + I) – n Razlika predstavlja kamatu koja se može zaraditi tim novcem ($ označava novčanu jedinicu u bilo kojoj valuti). . Primjeri: • Troškovi 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 obično dijeli sa dužinom trajanja projekta kako bi se dobio godišnji ROI. Nizak ROI (~ manji od 10% godišnje) može pokazivati da je korist preniska da bi bila isplativa. Odnos trošak/korist je prikazan tabelom 2.2 i grafičkim prikazom tabele. Primjer: Analiza trošak – 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 definiše viziju i misiju poslovnog sistema, tj. strategijske ciljeve. Na osnovu strategijskih ciljeva se definišu poslovni ciljevi i određuju zadaci, kojima će poslovni sistem u nekom razdoblju ispuniti svoju misiju. Pri tome se dobijaju odgovori: šta se želi postići (prepoznatljivost, kvalitet, prihodi), kako željeno postići (promjenom organizacije, poboljšanjem sistema administracije), kako ostvariti povećanje proizvodnje ulaganjem u nove proizvodne tehnologije, uz istovremeno održavanje kvaliteta proizvoda, i kako osigurati zadovoljstva i radne sposobnosti zaposlenih doškolovavanjem i mogućnostima napredovanja. Činioci koji utječu na postavljanje ciljeva su slijedeći: ograničenja (organizaciona, finansijska, zakonska), potrebe i želje uprave, poslovodstva, zaposlenih (ugled, uticaj), vremenski okviri, gdje je kratkoročno razdoblje obično manje od 2 godine, srednjoročno 2 do 5 godina i dugoročno više od 5 godina [Awad, 1985].

2.3.2. Planiranje razvoja informacionog sistema Planiranje razvoja informacionog sistema treba da dâ odgovor na slijedeća pitanja: • • • • •

Čime se poslovni sistem bavi (grana, proizvodi, tržište, konkurencija)? Koji su problemi, zadaci i ciljevi poslovnog sistema? Koja je željena uloga IS u postizanju postavljenih ciljeva? Koje aplikacije postoje, čemu i kako služe, koje i kakve podatke sadrže? Postoje li aplikacije čiji je razvoj u toku? U kojem su stadijumu razvojni projekti? • Koje su potrebne aplikacije? • Koji su raspoloživi resursi (osoblje, tehnička sredstva, tehnologija)?

Razlozi zbog kojih treba planirati IS su višestruki. Na primjer, u Poslovnom sistemu koji se sastoji od više cjelina, kao što su Uprava, Finansije, Proizvodnja i Informatika često postoji više različitih tehničkih sistema ili aplikacija, takozvanih informatičkih ostrva. To ima za posljedicu umnožavanje informacija uz različito tumačenje u različitim dijelovima, nepotpunost informacija, naročito kada svaka cjelina prikuplja samo njoj važne informacije, problem povezivanja informacija pri pokušaju cjelovite interpretacije, kao i problem različitog posluživanja, razmjene podataka i održavanja.


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 teško izvodljivo u uslovima “preživljavanja”. Sastoji se od uspostave smjera i prioriteta usklađivanja informacionih servisa u skladu sa misijom, vizijom i ciljevima poslovnog sistema, planiranja IS u skladu sa strategijom razvoja poslovnog sistema, tako da informatizacija bude podrška promjeni poslovnog sistema i poslovnih procesa. Još se mogu navesti primjene metoda analize i dizajna za proučavanje poslovnog sistema, sa ciljem definisanja opšteg (sveobuhvatnog) plana i arhitekture IS čiji razvoj slijedi. U praksi situacija je slijedeća. Umjesto prema strategijskom planu, poslovni sistem se "dovodi u red" tokom informatizacije i pomoću informatizacije. Analizom sistema evidentiraju se problemi i slabosti poslovnih procesa, budući da se dizajnom sistema predlažu ili nameću poboljšanja.

2.3.3. Odabir i pokretanje projekta Prvenstveno pokretači promjena su korisnici, odnosno njihovo nezadovoljstvo aplikacijama i/ili podacima i/ili reorganizacijom. Nestabilnost aplikacija uzrokuje nedostatak podataka, što naglašava potrebu uvođenja 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). Pokretači promjena mogu biti i pokazatelji poslovanja (npr. pad prodaje, uska grla proizvodnje, neplanirano i nejasno povećanje troškova), kao i zastarila tehnologija (npr. zastario razvojni alat i prisutan problem njihovog održavanja, zastario interfejs Internet-a, zastarile BP). Odabir projekta se vrši na osnovu prijedloga projekta, koga sastavlja sponzor projekta (organizator, predlagač). Prijedlog projekta sadrži sažetak projekta (naziv, cilj, svrha), poslovne potrebe, očekivanu funkcionalnost, očekivanu korist, kao i posebnosti i ograničenja. Radna grupa za odabir projekta odobrava projekat. Prije pokretanja projekta potrebno je izvršiti snimak stanja, odnosno prethodno istraživanje, tj. istraživanje koje prethodi projektu, prepoznavanje problema i potreba, kao i traženje odgovora na pitanje "Da li je projekt vrijedan pažnje?". Slijedi faza proučavanja problema, produbljivanje snimka, postavljanje ciljeva, prijedlozi rješenja, procjena izvodljivosti, traženje odgovora na pitanja "Da li su problemi vrijedni rješavanja?“ i "Da li je gradnja isplativa?". Planiranje projekta, odnosno organizacija i upravljanje projektom, sastoji se od slijedećih aktivnosti: izrada plana rada, oformljenje projektantske ekipe (uključivanje

32


učesnika iz različitih djelatnosti, npr. radnici različitih poslovnih područja ili organizacijskih jedinica, uprava, vanjski konsultanti), pri čemu je važno osigurati predanost učesnika zajedničkom cilju, i, na kraju, uspostava upravljanja i nadzora projekta.

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

Hitnost

Vidljivost

Korist

Prioritet

HITNO

Visoka

175000

2

Predloženo rješenje Novi razvoj

6 mjeseci

Srednja

75000

2

Novi razvoj

6 mjeseci

Srednja

515000

2

Novi razvoj

12 mjeseci

Niska

15000

3

3 mjeseca

Visoka

35000

1

Nakon razvoja novog sistema, pružiti korisnicima lako savladive alate za pisanje izvještaja. Brza ispravka, a zatim novi razvoj.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema 6. Sistemi datoteka u Privatna predstava i Filmsko platno nisu kompatibilni sa onim u Zvučna pozornica. Problemi sa podacima obuhvataju nedoslijednosti u podacima i nedostatak upravljanja ulazom i izmjenama. 7. Postoji mogućnost uvođenja sistema naručivanja putem Interneta, ali su sigurnost i kontrola pristupa problematični. 8. Postojeći sistem unosa narudžbi nije kompatibilan sa planiranim sistemom za automatsku identifikaciju (štapićasti kod) koji se razvija za skladište.

33

6 mjeseci

Srednja

nepoznata

2

Novi razvoj, dodatna ocjena koristi može povećati ažurnost.

12 mjeseci

Niska

nepoznata

4

3 mjeseca

Visoka

65000

1

Buduće verzije tek razvijenog sistema. Brza ispravka, a zatim novi razvoj.

Vidljivost: U kojoj mjeri će rješenje ili novi sistem biti vidljivi korisnicima. Korist: Paušalna procjena koliko bi rješenje povećalo dobit ili smanjilo trošak u jednoj godini.

2.3.5. Planiranje projekta Planiranje projekta podrazumjeva određivanje namjene projekta i izdvajanje zadataka koji su saglasni poslovnim ciljevima, a mogu biti informatizovani. Domet i razgraničenje projekata ili podprojekata (System boundary, Constraints, Objectives, Permissions, End products (SCOPE)) daje odgovore na slijedeća pitanja: • • • • • • •

Koje su granice sistema? Koji će zahtjevi biti ispunjeni? Šta ne može biti napravljeno? Šta neće biti napravljeno? Ko će, kako i pod kojim uslovima moći koristiti rješenje? Kako se mjeri ili određuje uspjeh (neuspjeh)? Kako će se znati da je projekat gotov?

Vremensko planiranje obuhvata određivanje prioritetnih zadataka i vremenskih okvira prioriteta. Izrada početnog (preliminarnog) plana razvoja IS započinje podjelom projekta u manje cjeline i određivanje redoslijeda realizacije pojedinih podprojekata. Ovakvim pristupom se dobija okvirni vremenski plan rada po fazama, obavlja razrada i raspodjela poslova, kao i određivanje prioriteta. Nastoji se pronaći takva podjela posla na cjeline da cjelinu može obaviti jedna osoba ili ekipa, da se cjelina može obaviti jednom metodom i posao završi jednim “proizvodom” (dokumentom, aplikacijom ili podsistemom). Početni plan razvoja IS sadrži nazive podprojekata i omogućava doradu i ažuriranje u skladu sa napretkom projekta. Može se koristiti za prezentaciju projekta radi traženja saglasnosti o njegovom nastavku. Konsolidovani prijedlog projekta može poslužiti kao interni ugovor projekta (tabela 2.4).


34

Primjer: Početni (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 opšte informatičke pismenosti za rukovodioce odjeljenja; Obuka za programere u jeziku za upravljanje bazama podataka; Obuka za administratore baze podataka; Izrada prototipa programske podrške za i-tu fazu realizacije; Izrada α - verzije aplikacije; Testiranje α - verzije u informacionim sistemima; Uklanjanje uočenih nedostataka i izrada β - verzije programa; Obuka za odabrane korisnike na β - verziji; Testiranje kod korisnika u paralelnom radu sa dosadašnjim programom; Uklanjanje nedostataka i izrada stabilne verzije; Zamjena dotadašnjeg programa novim programom, uz preuzimanje podataka; Obuka za ostale korisnike; Uvođenje korištenja programa kod ostalih korisnika; Obuka za upoznavanje sa mogućnostima programa za odabrano poslovodstvo; Prikupljanje primjedbi korisnika i novih zahtjeva; Izrada slijedeće faze/verzije programa. Povratak na tačku 5).

2.3.6. Izvještaj o projektu Izvještaj o projektu obrađuje probleme i dostignuća projekta, a može imati oblik prikazan tabelom 2.5. Tabela 2.5. •

•

•

Sažetak - Sažetak prijedloga - Kratko obrazloženje očekivanih koristi - Kratko objašnjenje sadržaja izvještaja Prikupljene informacije - Kratak opis projektnog zadatka - Kratko objašnjenje provedenih aktivnosti Činjenice i zaključci (može se potkrijepiti matricom problema i mogućih rješenja)

-

Problemi i analiza problema Mogućnosti i analiza mogućnosti Direktive i implikacije

•

•

Detaljan prijedlog - Obrazloženje prijedloga * Hitne prepravke * Brze prepravke * Unapređenja * Novi razvoj Plan projekta * Početni ciljevi projekta * Početni glavni plan projekta (na nivou faza) * Detaljni plan za slijedeću fazu Prilozi - Zahtjev za uslugama sistema - Matrica obrazloženja problema - (ostala dokumentacija)


35

2.3.7. Određivanje poslovnih ciljeva Za projekte koji prođu početnu selekciju vrši se produbljivanje analize problema. Pri tome je potrebno odgovoriti na pitanja da li su problemi vrijedni rješavanja i da li je gradnja IS isplativa. Vrši se detaljnija analiza problema, njihovih uzroka i posljedica, imajući na umu misao: "Ne pokušavaj popraviti prije nego shvatiš kako radi!" Takođe je potrebno izvršiti analizu poslovnih procesa odgovarajući na pitanja: • Koji su najveći problemi? • Koja su moguća rješenja problema? • Kako informatizacija može pomoći? kao i grubo modeliranje postojećeg sistema. Mogu se koristiti različite formalne metode, od kojih su najznačajnije: 1. Analiza kritičnih faktora uspjeha (Critical Success Factors (CSF)), odnosno činilaca, kojima poslovodstvo posvećuje posebnu pažnju. 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 uočavanje podataka povezanih sa procesima; 3. Analiza izvodljivosti i procjena troškova - koristi.

2.3.8. Uzroci i posljedice problema, ciljevi i ograničenja Istraživanje uzroka problema, koji mogu biti raznovrsni, se mogu ilustrovati na slijedećem jednostavnom primjeru: Problem: Vidljivi znak: Razlog: Uzrok:

pad prodaje povećani opoziv (storno) narudžbi nezadovoljstvo kupaca spor sistem za naručivanje

Zadatak analitičara je da razdvoji uzroke i posljedice problema. Drugi primjer: Dug red u videoteci nije poseban problem, a može biti posljedica pomanjkanja osoblja, 'lijenosti' ili nezainteresovanosti osoblja za posao ili pak posljedica ručnog unosa podataka i izdavanja računa.


36

U razmatranom primjeru analitičar 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 mogućih ciljeva: pomoći reorganizaciju u tržišno orijentisanom poslovnom sistemu prema EU normama, osigurati informacije o izvorima, razlozima i mjestu nastanka svakog troška u sistemu, uskladiti hijerarhiju odlučivanja sa hijerarhijom u poslovnom sistemu ili racionalizovati utrošak novca za ... . Ograničenja mogu biti slijedeća: osoblje (npr. odjel informatike smije zaposliti najviše tri stalno zaposlena radnika), materijalni trošak (npr. nabavka kancelarijskog i potrošnog materijala ne smije premašiti XXX €), računarska oprema (npr. projekat se mora obaviti bez nabavke novog hardvera ili poželjno je da trošak opreme predstavlja najmanje 33% budžeta), finansijska sredstva (npr. ukupni budžet projekta je XXXXX €) ili naknade izvođačima ne smiju prekoračiti XX% ukupnog iznosa). Analiza uzroka i posljedice problema, njihovi ciljevi i ograničenja su prikazani u tabeli 2.6 [Fertalj & Kalpić, 2005]. Tabela 2.6. ANALIZA UZROKA I POSLJEDICA Problem ili mogućnost

Uzroci i posljedice

1. Vrijeme odgovora na narudžbu je neprihvatljivo dugo.

1. Promet je povećan, a broj službenika smanjen. Vrijeme obrade narudžbe je isto. 2. Sistem previše zavisi o ručnom unosu. Pojedine vrijednosti se unose više puta. Posljedica je da se narudžbe obrađuju duže nego je potrebno. 3. Središnji računar radi na maksimumu svoga kapaciteta, šta se ogleda u sporijem radu aplikacije za unos narudžbi. Budući da službenici pokušavaju brže raditi, povećao se broj grešaka pri unosu.

CILJEVI I OGRANIČENJA SISTEMA Ciljevi sistema

Ograničenja sistema

1. Smanjiti vrijeme unosa pojedine narudžbe za 30%.

1. Broj zaposlenih u obradi narudžbi se ne može povećati.

2. Ručni unos narudžbi svesti na 50% ukupnog broja.

2. Novi sistem mora biti kompatibilan sa postojećim Windows XX standardom.

3. Na ekranskoj formi računara za ručni unos smanjiti broj potrebnih pritisaka na tastaturu. 4. Prenijeti unos podataka sa središnjeg računara na PC. 5. Zamjeniti postojeće obrasce za prikupljanje narudžbi mrežnim sistemom između skladišta i prodaje, tako da se eliminiše upotreba

3. Novi sistem mora biti kompatibilan sa već odabranim sistemom za automatsku identifikaciju štapićastim kodom.


4. Obrasci za prikupljanje narudžbi iz skladišta nisu oblikovani za racionalno popunjavanje, što dodatno usporava unos narudžbi.

37

papirne dokumentacije.

2.3.9. Modeliranje postojećeg sistema Svrha modeliranja postojećeg sistema je preciziranje dometa projekta, kao i verifikacija razumijevanja problema i usaglašavanje percepcije sistema i stavova između učesnika (korisnici, informatičari). Pri tome primjeniti taktiku skrivanja zanemarivanja detalja i usredotočenje na ono što je zaista važno (npr. izbjegavanje proučavanja tehničkih 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 ključnih poslovnih procesa, kruženje 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 mogućih rješenja problema, definisanja ciljeva i zadataka informacionog sistema, kao i procjena ograničenja. Tu spada ponovna procjena i preciziranje opsega projekta, a po potrebi i revizija glavnog plana. Tokom izvođenja projekta često se događa polagano, ali značajno, povećanje obima uslijed pogrešne procjene ili različitog tumačenja ciljeva između korisnika i izvođača, tzv. puzeći domet projekta. Granice projekta moraju biti definisane što je moguće preciznije. Time se kasnije povećanje projekta, možda, neće ukloniti, ali će se barem moći kontrolisati. Prema potrebi se planira i provodi izrada prototipa ili oglednog (pilot) projekta i procjena njegove uspješnosti. Planira se prototip koji se može uspješno i “brzo” realizirati (npr. 3 do 9 mjeseci, u zavisnosti o veličini čitavog projekta). Poželjno je realizovati takav prototip koji će omogućiti procjenu mogućih tehničkih rješenja IS

38


(alternativa) i prijedlog najboljeg rješenja, a pored toga vratiti uloženu investiciju. Na kraju se (opet!) može očekivati pokretanje, odbacivanje, odgađanje ili prilagđavanje (ostalih, pojedinih) projekata. Tabela 2.7 prikazuje idejno rješenje plana razvoja IS. Tabela 2.7. •

•

•

Sažetak - Sažetak prijedloga - Sažetak problema, mogućnosti i direktiva - Kratki navod ciljeva unapređenja sistema - Kratki navod sadržaja izvještaja Poznate informacije - Popis održanih razgovora i kordinisanih grupnih sastanaka - Popis ostalih izvora informacija - Opis tehnika korištenih u analizi Pregled postojećeg sistema - Strategijske odrednice - Modeli postojećeg sistema * Model interfejsa (kontekst) * Model resursa (prostor) * Model procesa (funkcija) * Model podataka (kategorije)

•

Analiza postojećeg sistema * problemi, mogućnosti i analiza uzroka i posljedica za pojedine elemente

•

•

- Performanse - Informacije - Ekonomija - Kontrola - Djelotvornost - Usluge (servisi) Detaljni prijedlozi - Ciljevi i prioriteti unapređenja sistema - Preporuke unapređenja sistema - Plan projekta * Precizirati domet projekta * Revidirati glavni plan * Detaljni plan za slijedeći 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, takođe, projektuje i shema baze podataka IS. Realizacija naredne faze ne započinje dok se tekuća faza ne završi. Greške iz prethodnih faza, otkrivene u tekućoj, zahtjevaju da se one otklone i dokumentuju vraćanjem u prethodne i prolaskom kroz sve faze koje slijede iza faze


39

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


40

Pseudostrukturirani vodopadni model (slika 2.1(b)) sadrži povratnu vezu i mogućnost promjene rezultata prethodnih faza. Ovaj model razvoja IS omogućava primjenu tehnika strukturiranog programiranja.

Analiza

Analiza Oblikovanje

Oblikovanje

Izrada

Izrada

Evaluacija

Evaluacija

Primjena Primjena (a)

(b)

Slika 2. 1. Uporedni prikaz klasičnog razvoja (a), pseudostrukturiranog i radikalnog razvoja (b). Radikalni (strukturirani) razvoj (slika 2.1(b)) omogućava da se aktivnosti različitih faza mogu obavljati istovremeno. Dozvoljava korištenje rječnika podataka, programskih jezika četvrte generacije (4GL) i generatora aplikacija. Prikladan je kada se unaprijed ne zna konačni izgled sistema.

2.4.2. “V” model razvoja informacionog sistema “V” model razvoja IS (slika 2.2) omoguća definisanje rezultata (“proizvoda”) pojedinih faza koji se proslijeđuju u slijedeće faze. Tim rezultatima se testiraju elementi IS na različitim stepenima razvoja.


Analiza

41 Test prihvatljivosti

Scenariji aplikacije

Specifikacija zahtjeva

Testirani sistem

Strukturirano oblikovanje

Integracija sistema

Ogledni slučajevi

Testirani softver

Model sistema Detaljno oblikovanje

Ogledni slučajevi

Dizajn modula

Integracija modula Testirani moduli

Kodiranje i testiranje 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 može primjeniti u okviru metodologije životnog ciklusa. Prototipski pristup postaje u punoj mjeri praktično primjenljiv (iako je ideja o prototipskom pristupu u softverskom inženjerstvu bila prisutna dosta rano) tek pojavom sveobuhvatnih i kvalitetnih projektantskih i programerskih CASE (Computer Aided Software Engineering) proizvoda, koji su integrisani sa okruženjem četvrte generacije. U zavisnosti od njegove namjene, mogu se uočiti slijedeće tri vrste prototipskog modela. Model oponašanja (model u prirodnoj veličini), odnosno jednoekranski ili

42


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

Dizajn prototipa Izrada prototipa Razvoj prototipa

Radni sistem

Slika 2.3. Dijagram brzog razvoja prototipa.


43

Određivanje zahtjeva Dizajn prototipa Izrada prototipa Razvoj prototipa Radni sistem Prototip Specifikacije zahtjeva

Dokumentovanje zahtjeva Oblikovanje

Slika 2.4. Dijagram ograničenog/strukturiranog razvoja prototipa. Praktični aspekti primjene prototipskog pristupa su višestruki. Riječ je, uglavnom, o činjenicama proisteklim iz iskustva u praktičnoj primjeni prototipskog pristupa. Zbog toga, može se reći da su te činjenice prije savjetodavnog, nego formalno strogog karaktera. Opšte preporuke za primjenu prototipskog pristupa su slijedeće [Mogin et al. 2000]: 1. Potrebno je, prije početka primjene prototipskog pristupa, precizno definisati standarde za izgled korisničkog interfejsa, projektovanje i programiranje. Standarde treba usaglasiti sa mogućnostima odabranog CASE proizvoda, a generator programskog koda upotrebljenog CASE proizvoda treba prilagoditi za programiranje i izgled korisničkog interfejsa, a sve u cilju postizanja bolje podrške standarda; 2. Preporučuje se dekomponovanje cjeline IS na manje projekte, a zatim definisanje nižeg stepena međusobne integracije informacionih podsistema, u odnosu na klasičnu 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 konačno rješenje. Pri tome treba precizirati način upotrebe prototipa od strane korisnika;

44


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


45

preporukom 1. Usaglašavanje podataka, unesenih putem neodbacivog prototipa sa bitno prestrukturiranom shemom BP, je često vremenski zahtjevan i neizvjestan posao. U cilju izbjegavanja problema, posebno treba obratiti pažnju na preporuke 5 i 6. Intervencije na prototipu kod korisnika mogu stvoriti lažni utisak da je projektovanje IS trivijalan posao. Da bi se problem izbjegao, posebno treba obratiti pažnju na preporuku 3. Primjena preporuke 9, ako za nju postoje uslovi, može biti u funkciji ublažavanja ovog problema. Ako je riječ o manje iskusnim korisnicima ili projektantima, može se dogoditi da primjena prototipskog pristupa ne ostvari jadan od osnovnih ciljeva, odnosno pravovremeno identifikovanje informacionih zahtjeva, a da pri tome projektant ne uoči takav „propust“ na vrijeme. Primjena preporuka 8 i 9 može pozitivno uticati na ublažavanje ili izbjegavanje ovog problema. Primjena prototipskog pristupa IS je pokazala da on nije primjeren razvoju integrisanih IS, jer insistiranje na brzom uvođenju aplikacija u funkciju dovodi do parcijalizacije IS. Zbog toga je važno obratiti pažnju na preporuku 2. Aplikacije koje se razvijaju samo primjenom prototipskog pristupa mogu postati „izolovana ostrva“. Imajući u vidu tu činjenicu, direktna primjena isključivo prototipskog pristupa je moguća u slučaju da treba razvijati skoro izolovane podsisteme sa niskim stepenom međusobne integracije. Sa druge strane, očekuje se da prototipski pristup doživi svoju punu afirmaciju ukoliko se primjenjuje u kombinaciji sa nekim od modela primjene metodologije životnog ciklusa. U tom smislu, posebno značajnu 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. Može se zaključiti da IS raste sa poslovnim sistemom koga podržava. 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 započinje dok se tekuća faza ne završi. Uočava se da upravo primjena ovog principa, kod nekih projekata, može intenzivirati negativne efekte primjene metodologije životnog ciklusa. Evolutivni model primjene metodologije životnog ciklusa, nasuprot sekvencijalnom, predviđa da je za određene faze životnog ciklusa programskog proizvoda moguće da naredna faza započne prije nego što se prethodna završi, što dovodi do određenog stepena paralelizma u realizaciji tih faza. Prema tome, faze životnog ciklusa počinju da se sprovode iterativno. Do ove ideje se došlo na osnovu pretpostavke da ne treba odjednom realizovati kompletnu fazu i utrošiti za to veliku količinu vremena i novca, 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 uspješni završetak prethodne faze. Kako je jedan od bitnih motiva za nastanak evolutivnog pristupa problem nedovoljno precizno identifikovanih informacionih zahtjeva, smatra se da njegova praktična primjena ima smisla ukoliko se on kombinuje sa prototipskim pristupom, kao metodom za tačno utvrđivanje informacionih zahtjeva. Za utvrđivanje informacionih zahtjeva se pretežno primjenjuju odbacivi prototipovi. Primjenjuju se dvije varijante evolutivnog pristupa. Prema prvoj, nakon utvrđivanja preciznih informacionih zahtjeva, rezultati konceptualnog i implementacionog projektovanja BP se integrišu, a projekti podsistema se usaglašavaju sa shemom integrisane BP. Drugim riječima, potprojekti se ponovo posmatraju kao cjelina i na njih se primjenjuju, nešto 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 rješava probleme dugog vremenskog intervala od početka projekta do pojave prvih, operativno primjenljivih rezultata kod korisnika, i potrebe ulaganja finansijskih sredstava odjednom, a ne postupno. Prema drugoj varijanti, potprojekti se realizuju međusobno nezavisno i mogu biti fazno pomjereni u vremenu. Na taj način se rješavaju problemi dugog vremenskog intervala od početka projekta do pojave prvih rezultata i potrebe ulaganja odjednom finansijskih sredstava. Ovakav nezavisan rad, međutim, može dovesti do nižeg stepena integrisanosti IS. Analiza

Oblikovanje

Analiza

Izrada

Oblikovanje

Analiza

Analiza

Evaluacija

Izrada

Oblikovanje

Oblikovanje

Evaluacija

Izrada

Izrada

Evaluacija

Evaluacija

Slika 2.5. Mogući evolutivni model primjene metodologije životnog ciklusa.


47

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

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

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

PRIMJENA Analiza rizika IZRADA Testiranje Analiza rizika INTEGRACIJA Verifikacija

Slika 2.6. Dijagram procjene rizika.


48

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

Programiranje

Projektovanje

izrada oblikovanje

Upravljanje projektom

analiza

Uvođenje u upotrebu

1. 2. 3. 4.

Snimanje i analiza

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

(a)

(b)

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

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


49

Komponente metodologije se mogu razvrstati u slijedećih pet tačaka: 1. 2. 3. 4. 5.

Etape projekta; Zadaci za svaku pojedinu etapu; Izlazi (projektna dokumentacija); Preporuke (vodič) upotrebe odabranih tehnika i pomagala; Način upravljanja projektom i nadzorom projekta.

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

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

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


50

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

2.5.3. Komercijalne metodologije za razvoj informacionog sistema Nazivi nekih strukturiranih komercijalnih metodologija za razvoj informacionih sistema su navedeni u originalu: • AD/Cycle (Application Development Cycle), • BSP (Business System Planning), • CASE*Method, • IEM (Information Engineering Methodology, Martin), • JSD/JSP (Jackson System Development/ Jackson System Programming), • SA/SD (Structured Analysis / Structured Design), • SASS (Structured Analysis and System Specification), • SSM/M (Soft Systems Method / Multiview), • SSA (Structured System Analysis), • SSADM (Structured System Analysis and Design Method), • Yourdon (Yourdon Structured Method). Objektno usmjerene metodologije: • • • • •

Yourdon/OO (Yourdon / Object Oriented), OMT (Object Modelling Technique), BOOCH (Booch’93), Schlaer-Mellor, Unified Modelling Process (Rational).


51

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

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


52

3. JAD (Joint Application Design) – združeno oblikovanje aplikacija. Nastoji se oblikovati sistem tako da potpuno odgovara zahtjevima. Zahtijeva tijesnu saradnju korisnika, projektanta i menadžera; 4. Konstrukcija - iterativna izrada prototipa; 5. Završetak projekta - provjera rada, izrada dokumentacije, obuka korisnika. Primjer: RAD projekat. Sedmice 1-4 • pokretanje projekta, istraživanje, priprema JRP sjednice, obavljanje JRP sjednice, priprema JAD sjednice; Sedmice 5-9 • prva JAD sjednica, početak dizajna, konsolidacija JAD dizajna i prototipa, prototipovi za test uporabljivosti, druga JAD sjednica, završetak dizajna; Sedmice 10-14 • razvoj i testiranje, priprema konverzije, planiranje završetka; Sedmice 15-20 • izrada dokumentacije, priprema obuke, obuka, završno testiranje, završetak projekta.

2.6.2. Informaciono inženjerstvo (Information Engineering (IE)) Informaciono inženjerstvo (IE) se zasniva na analizi poslovnih zahtjeva iz koje se izdvajaju aplikacije IS i prioriteti tih aplikacija. Aplikacije postaju projekti u kojima se provode postupci analize i dizajna da bi se razvili produkcioni sistemi. Za razliku od klasične strukturirane analize, koja se odvija projekat-po-projekat, informaciono inženjerstvo je procesno osjetljiva tehnika usmjerena na podatke i primjenjuje se na organizaciju kao cjelinu ili na neki njen značajni dio. Osnovno načelo je da se IS moraju graditi kao što se grade drugi “unikatni” proizvodi, npr. u građevinarstvu ili brodogradnji. Faze informacionog inženjerstva su slijedeće: 1. Planiranje strategije IS - Information Strategy Planning (ISP), koje obuhvata posmatranje poslovanja kao cjeline sa ciljem definisanja opšteg,


53

sveobuhvatnog plana i arhitekture za redoslijedni razvoj informacionih (pod)sistema. Vrši se izdvajanje poslovnih područja i određivanje prioriteta. Pod poslovnim područjem se podrazumjeva skup poslovnih procesa koji se protežu organizacijom, a moraju biti visoko integrisani da bi se ostvarila strategija ili misija; 2. Analiza poslovnih područja - Business Area Analysis (BAA); 3. Proučavanje poslovnih područja i definisanje poslovnih zahtjeva za visoko organizirani i integrisani skup informacionih (pod)sistema i aplikacija podrške poslovnog područja; 4. Definisanje aplikacija, odnosno izdvajanje aplikacija i definisanje njihovih prioriteta na osnovu analize poslovnih područja. Aplikacije postaju projekti u kojima se primjenjuju drugi postupci analize i dizajna. Budući da je informacija proizašla iz podataka, podaci moraju biti prvi planirani. Modeliranje započinje modelima podataka. Nakon toga se rade modeli procesa, slično onima u strukturiranoj analizi. Napomena: O informacionom inženjerstvu biće još govora u poglavlju 8.

2.6.3. Ekstremno programiranje (eXtreme Programming (XP)) Načela ekstremnog programiranja nastala su prije desetak godina [Kent Beck, 1996]. XP zahtijeva komunikaciju u svim fazama projekta, među svim njegovim učesnicima. Ovdje se prvenstveno misli na komunikaciju među članovima razvojnog tima, zatim na međusobnu komunikaciju članova tima sa rukovodiocem projekta, te komunikaciju naručioca sa izvođačima (članovima razvojnog tima i njihovim rukovodiocima). Dijelovi softvera, kao i njegova cjelokupna arhitektura, moraju u svakoj fazi projekta biti jednostavni. Jednostavnost se ostvaruje kontinuiranim prilagođavanjem programskog kôda i svođenjem projektne dokumentacije na minimalno prihvatljivi nivo. XP nalaže kontinuirane povratne informacija od svih učesnika projekta, što značajno podiže kvalitet rada i ispunjenje rokova. Dobre povratne informacije onemogućavaju nerazumijevanje među učesnicima projekta, te drže projekt na "pravom putu". U XP hrabrost podrazumijeva sposobnost provođenja teških odluka (npr. odbacivanja dijelova koda kada je to neophodno ili nametanja velikih promjena u kasnoj fazi projekta) ili odluka koje u danom trenutku nisu pretjerano popularne. Takođe, hrabrost podrazumijeva međusobnu iskrenost svih članova projektantskog tima.

54


XP uvažava mogućnost promjene specifikacija koje definišu funkcionalnost sistema. Prihvati promjenu! je jedan od osnovnih XP postulata. Igra planiranja definiše funkcionalnosti slijedeće verzije, prije nego što njen razvoj stvarno i počne. U početku se kreira grubi plan koji se redefiniše kroz razgovore sa naručiocima i korisnicima. Korisnici se izražavaju "pričama", tako da svaka priča definiše jedan dio funkcionalnosti sistema. Pričama se dodjeljuju prioriteti i ciljano vrijeme implementacije (1 do 3 sedmice po zahtjevu). XP preporučuje relativno često izdavanje novih verzija sistema, obično u prvom trenutku u kojem to ima poslovnog smisla, tj. kada sistem zadovoljava funkcionalnost traženu od strane naručioca. Često izdavanje novih verzija pojačava komunikaciju, a time i dotok povratnih informacija i igru planiranja. Metafora sistema je analogna onome što većina drugih metodologija naziva arhitekturom sistema. Metafora mora biti jasno izražena te nedvosmisleno shvatljiva svim članovima projektantskog tima. XP ne definiše format ili tehniku u kojoj metafora mora biti izražena. Najčešći 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. Prilagođavanje programskog kôda (refactoring) je tehnika kojom se pojednostavljuje programski kod uklanjanjem ponavljanog koda i uklanjanjem (nepotrebnog) složenog koda. Programeri rade u parovima, na način da jedan piše kôd, a drugi prati pisanje i revidira kôd, pazeći da kôd bude jasan i razumljiv. Zajedničko vlasništvo se sastoji u tome da svi inženjeri koji učestvuju u razvoju projekta imaju pravo mijenjati bilo koji njegov dio u bilo kojem trenutku. XP nalaže izgradnju novih verzija nekoliko puta dnevno, tj. nakon svake implementirane funkcionalnosti. Zastupljeno je poštovanje 40-satne radne sedmice. Smatra se da umorni projektanti ne mogu postići maksimalnu efikasnost u radu, pa se zabranjuje prekovremeni rad dvije sedmice zaredom. Naručilac ili predstavnik naručioca mora biti prisutan prilikom razvoja sistema kako bi bio dostupan u slučaju potrebe za pojašnjenima, te kako bi pomogao u definisanju sistema i pisanju testova. Programeri moraju pisati kôd 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 slijedeći način:


55

1. Softver se razvija i objavljuje po dijelovima; 2. Glavne faze razvoja se obavljaju kroz niz iteracija; 3. Faza konstrukcije (izrade) slijedi nakon provođenja prethodnih faza. Svaka iteracija se obavlja standardnim životnim ciklusom koji uključuje analizu, oblikovanje, ugradnju i provjeru. Rezultat iteracije je proizvod završnog kvaliteta, provjeren i integrisan, koji zadovoljava podskup ukupnih zahtjeva. Isporuke mogu biti interne ili prema korisnicima. Mogu se izdvojiti slijedeće glavne faze razvoja (slika 2.9). Početak (Inception), koga sačinjavaju opravdanje razloga za pokretanje projekta, prikupljanje najvažnijih zahtjeva (10% detaljno) i određivanje dosega projekta.

Početak

Elaboracija

Gradnja

Prelaz

Zahtjevi Analiza

Oblikovanje Ugradnja

Provjera

iter. #1

iter. #2

iter. #n-1

iter. #n

Inkrementi

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) sačinjavaju beta testiranje, podešavanje performansi, obuka korisnika, provjera prihvatljivosti i zadovoljstva korisnika.

56


Post-implementacija (Post-deployment) očuvanje 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. Uobičajeno, iteracije imaju podjednako trajanje. Trajanje iteracije može varirati u zavisnosti od faze. U fazi konstrukcije to vrijeme je duže. Prva iteracija je najčešće i najteža. Zahtijeva pripremu okruženja, ekipe i posla. Opasna je zbog mogućeg pretjeranog optimizma. Ako se krivo procjeni može izazvati pomake i neželjene učinke. Smanjenje broja iteracija za posljedicu ima slabije rezultate razvoja.

2.6.5. Izbor pristupa razvoju informacionog sistema Izbor opšte metodologije po kojoj će programski proizvod biti razvijen vrši se tokom ustanovljavanja projekta razvoja programskog proizvoda. Ukoliko je izabrana metodologija životnog ciklusa, tada najkasnije do završetka faze strategije, rukovodeći tim projekta mora da se opredjeli za odgovarajući model primjene metodologije životnog ciklusa i izvrši dodatna prilagođavanja izabranog modela potrebama projekta. Ne postoje formalna pravila na osnovu kojih ovaj izbor treba napraviti, već se može govoriti samo o preporukama. Dosta preporuka za izbor odgovarajućeg modela primjene metodologije životnog ciklusa proizilazi iz razmatranja danih u okviru tačaka 2.4 i 2.5. Neki od parametara, koji se mogu navesti i koji utiču na izbor modela primjene metodologije, su slijedeći: koliko je poslovni sistem složen sa stanovišta funkcija koje se u njemu obavljaju, kakav je stepen uređenosti poslovanja u samom poslovnom sistemu, da li je opšta ekonomska i politička situacija u okruženju 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 raspolaže i kakva je dinamika obezbjeđenja tih sredstava. Ovom navođenju parametara može se dodati: kakve informacione tehnologije stoje na raspolaganju za realizaciju projekta, da li je rukovodeći i izvođački tim projekta iskusan u primjeni odgovarajućih informacionih tehnologija, da li je većina korisnika budućeg programskog proizvoda iskusna u upotrebi rješenja vezanih za informacione tehnologije ili ne, da li su rukovodeće strukture iz poslovnog sistema, a dijelom i budući korisnici, zainteresovani i stimulisani za uvođenje novog programskog proizvoda, da li su, u cjelini, otežane ili ne mogućnosti za obezbjeđivanje 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 fizičkog i logičkog modela Fizički i logički model postojećeg IS, a zatim logički i fizički model budućeg IS, izrađuje se na osnovu poslovnih zahtjeva i zahtjeva krajnjih korisnika. Fizički model (ugradni, implementacioni, tehnički) opisuje kako je sistem fizički i tehnički izgrađen, te ko, gdje i kada nešto radi. Logički model (esencijalni, konceptualni, poslovni) opisuje šta je sistem, šta radi, šta su podaci (slika 3.1). Operativni (budući fizički) sistem prikazuje šta, ko i kada, ali ne i gdje radi, a prema potrebi može se razmatrati organizacijski nivo, odnosno različito značenje podataka zavisno od područja unutar poslovnog sistema i okruženja. Budući fizički IS

Postojeći fizički IS Postojeći logički IS

Korisnički/poslovni zahtjev

Budući logički IS

Budući organizacijski IS

Slika 3.1. Prikaz redoslijeda izrade fizičkog i logičkog 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" postojećeg sistema po ugledu na istovjetne sisteme u


58

drugim poslovnim sistemima ili razvoj započeti sa izradom logičkog modela. Tehnika oblikovanja dijagramima odvija se na slijedeći način. Izradom modela nastoji se opisati situacija u kojoj događaj iz vanjskog svijeta pokreće (okida) process. Proces ima određeni učinak na podatke u nekom stanju. Obavljanjem procesa podaci prelaze u novo stanje (slika 3.2). Staro stanje podataka

Događaj

Sinhronizacija (koncept okidača)

Proces (naredbe i pravila)

učinak

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 između podataka. Najčešći konceptualni model je model entiteti-veze. Logički model opisuje strukturu podataka i logičkih datoteka, a najčešći logički model je relacioni model podataka. Model funkcija i procesa opisuje KAKO se prikupljaju, obrađuju 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. Najčešći model procesa je dijagram toka podataka. Model događaja opisuje KADA se podaci obrađuju, odnosno razmatra učinke koje događaji imaju na procese i podatke, te vrši opis stanja. Kao primjer se može navesti dijagram promjene stanja. Model resursa/sredstava opisuje izvršioce, odnosno KO obrađuje podatke, GDJE se podaci nalaze i GDJE se podaci obrađuju. Modeliranje programa podrazumjeva predstavljanje struktura (programskih) modula IS, npr. strukturnim kartama.


59

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

60


3.2. Definisanje zahtjeva za informacionim sistemom 3.2.1. Ključne aktivnosti Ključne 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 ključnim korisnicima i radne sjednice. Ako naručilac zapošljava informatičare svakako ih treba uključiti u analizu. Sučeljavanje korisnika i informatičara ubrzava rješavanje proturječnih 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 značajne za poslovanje, radi boljeg utvrđivanja pravila, poslovne politike, ciljeva poslovanja i strukture informacija. Nužna je ocjena postojećih aplikacija i/ili računarom podržanih podataka, radi analize podataka, ali i zbog njihove konverzije u novi sistem. Posmatranje, odnosno neposredni uvid u poslovne procese posmatranjem radnih sredina (način izrade i razmjene dokumenata, procesi osnovne djelatnosti), je značajan vid definisanja zahtjeva za IS. Postupak analize mora biti prilagođen korisniku. Evidentiranje rezultata analize poželjno je obaviti CASE alatima.

3.2.3. Postupak intervjuisanja Intervju mora biti neusiljen i elastičan razgovor sa ispitanikom u obliku niza pitanja i odgovora. Ispitanik se pojavljuje u ulozi pasivnog sagovornika (!?). Sagovornici su rukovodioci, krajnji korisnici i ostali učesnici iz poslovnog sistema. Standardno uključuje dva sagovornika, ali može i više, i to korisnika i ispitivača. Individualni intervju je kada učestvuje jedan korisnik, ili učesnici koji rade isti posao, dok je intervjuisanje grupe kada se razgovara sa više korisnika iz različitih područja. Informacije se prikupljaju nizom pojedinačnih 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 završetka analize i sinteze dobijenih informacija, neke razgovore (ponekad i čitavu seriju) treba ponoviti da bi se


61

upotpunile dobijene informacije ili uskladili proturječni iskazi. Ukupan broj razgovora ne može se unaprijed tačno odrediti i treba ga prilagoditi stvarnoj situaciji.

3.2.4. Tehnika intervjuisanja Priprema za razgovor treba da sadrži utvrđivanje informacija koje treba saznati, proučavanje postojeće dokumentacije i prethodnih nalaza, određivanje 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. Mogući plan i obavljanje razgovora može da se odvija na slijedeći način: 1. Trajanje prvog razgovora je 2 sata (okvirno 1,5 do 2,5 sata); 2. Početak razgovora, koji sadrži predstavljanje učesnika i upoznavanje sa svrhom razgovora (prikupljanje informacija o … ); 3. Vođenje razgovora, odnosno postavljanje pitanja i zapisivanje odgovora, prikupljanje dokumentacije, ... ; 4. Završetak razgovora je približno 5 do10 minuta prije isteka planiranog vremena. Prekida se redoslijed postavljanja pitanja, provjerava se da li postoji nešto što je sagovornik htjeo reći a nije bilo pitano, provjerava se da li treba proširiti krug sagovornika, dogovara se nastavak razgovora (dopunski razgovor) kada voditelj razgovora nije postavio sva planirana pitanja ili smatra da je razgovor nametnuo nova pitanja; 5. Zahvala na razgovoru. Preispitivanje i pojašnjenje sadržaja se sastoji od provjera zapisanih navoda radi upotpunjavanja bilješki: telefonom, elektronskom poštom ili novim sastankom. Dokumentovanje razgovora sačinjavaju: • Samostalno pisanje zapisnika (“Ko ne razumije, ne može zapisivati.”). Kada u razgovoru sudjeluje više analitičara, određuje se voditelj razgovora koji je ujedno i zapisničar, a ostali ulažu primjedbe; • Zapisnik treba da sadrži: naziv projekta, vrijeme i mjesto održavanja razgovora, spisak učesnika, sadržaj razgovora (tekst zapisnika), popis prikupljene dokumentacije i ime zapisničara; • Zapisnik mora sadržavati ono što je rečeno i slijediti tok razgovora; • Zapisnik ne smije nametati zaključke, jer su oni rezultat analize.

62


Autorizacija (ovjera) zapisnika se vrši tako da se zapisnik dostavlja na uvid sagovorniku, koji potvrđuje vjerodostojnost zapisnika. Po potrebi sagovornik može nadopuniti dijelove za koje smatra da nisu evidentirani ili pojasniti dijelove za koje misli da su pogrešno protumačeni.

3.2.5. Preporuke za vođenje intervjua Tokom provođenja intervjua treba pitati o svemu što se smatra važnim. Ništa nije samo po sebi razumljivo i svima jasno. Ne pretpostavljati da se unaprijed zna o čemu se radi. Repertoar i vrste pitanja može biti slijedeći: 1. Pitanja zatvorenog tipa: Koliko ... obrađujete (u nekom razdoblju)?, Na koji način obrađujete ... ?; 2. Pitanja otvorenog tipa: Što mislite o ... ?, Koji su najveći problemi ... ?; 3. “Probna” pitanja: Zašto?, Možete li navesti primjer za takvu situaciju?, Molim detaljnije objašnjenje za ... . Analizom odgovora se razdvajaju činjenice od mišljenja, utvrđuje se da li pojedine činjenice odgovaraju drugima, analiziraju činjenice koje se ne poklapaju i vrši provjera odgovora različitih sagovornika na isto pitanje. Preporučuje se slijedeće ponašanje: iskrenost i nepristranost (cilj je naći za korisnika najprikladnije rješenje, a ne naturati određeno programsko rješenje ili računarsku platformu), pažnja i jezgrovitost tj. “brzo misli, jasno govori”, izbjegavanje sugestivnih pitanja, nenametanje zaključaka i ležernost (plus praćenje reakcija sagovornika). Grupno intervjuiranje je potrebno izbjegavati i po potrebi nadoknaditi radnim sjednicama. Ovu vrstu intervjuisanja iznimno provesti kada se želi utvrditi zajednički interes ili protivrječnost.

3.2.6. Upitnici i ankete Upitnik je, u suštini, pismeni intervju. Sadrži pitanja koja se postavljaju tokom razgovora (okvirno 20 pitanja). Može se dostaviti korisniku prije ili nakon intervjua. Nedostaci upitnika su slijedeći: ispitanik može prilagoditi (kontrolisati) svoje odgovore, teško je procijeniti iskrenost (spontanost) odgovora, a može i obeshrabriti ispitanika. Anketa može da obuhvatiti više ispitanika. Pitanja su zatvorenog tipa, a odgovori i obrada odgovora mogu se standardizovati. Pogodna je za popis resursa.


Na osnovu navedenog, može se zaključiti da Pomoću intervjua se može više naučiti o stavovima, Tokom intervjua analitičar i ispitanik se nalaze jedan može posmatrati način na koji ispitanik odgovara i pitanja.

63

je intervjuisanje najelastičnije! osjećajima i motivaciji osoblja. nasuprot drugom, pa analitičar po potrebi proširiti ili usmjeriti

3.2.7. Proučavanje dokumenata Prikupljaju se svi dokumenti do kojih se može doći. U prvom redu treba prikupiti dokumente koji su nastali kao rezultat analize procesa, tipične dokumente (pravilnici, zakoni, obrasci, izvještaji) i dokumente nastale analizom podataka. Poželjno je da dokumenti budu reprezentativni, tj. popunjeni na tipičan način (tako se može ustanoviti koje informacije se unose i na koji način). Reprezentativni dokumenti najčešće ne ukazuju na izuzetke, to jest podatke koji se rjeđe bilježe, ali ipak trebaju. Stalno bilježenje nekih podataka ne mora značiti da su ti podaci stvarno potrebni. Treba prikupiti više uzoraka iste vrste dokumenta! Vrijednost informacija o analiziranoj organizaciji prikupljena (samo) preko dokumenata je niska. Praksa može odudarati od pravilnika i administrativnih obrazaca. Treba shvatiti zašto i kada dokumenti nastaju, kako se popunjavaju, koliko su potrebni, te šta treba promijeniti da bi se popravili (sadržaj, lakoća popunjavanja i čitanja). Nužno je modele (podataka), razmatrane analizom, provjeriti kod korisnika.

3.2.8. Evidencija i analiza postojećih aplikacija Budući da su nedostaci opreme, podrške i podataka najčešći razlozi za izgradnju novog IS, potrebno ih je evidentirati i analizirati. Vrši se procjena aplikacija i (baza) podataka u primjeni, i to: korišteni programski jezici i alati, uključujući programe za kancelarijsko poslovanje (npr. Excel), podržane funkcije i način posluživanja programa, međusobna povezanost različitih aplikacija i podataka, postojeće platforme (računari, operativni sistem, mreža, SUBP), kao i sastav i stepen informatičke obučenosti korisnika. Analiziraju se nedostaci sistemske opreme i programske podrške. U prvom redu se analizira nepovezanost aplikacija (tzv. informatička ostrva), loša programska rješenja (funkcionalnost, ergonomija), nepouzdanost, integritet, zaštita i sigurnost podataka. Takođe se analizira nepostojanje programske dokumentacije, tehnološka zastarjelost (programski jezici i alati, nemogućnost rada u višekorisničkom okruženju, grafički interfejs).

64


Nedostaci modela podataka mogu biti različiti. Najčešći nedostaci su različitost modela podataka postojećih aplikacija i nedostaci unutar pojedinih modela. Različitost modela podataka postojećih aplikacija se očituje u tome da entiteti iz stvarnog svijeta nisu jednako zastupljeni u postojećim modelima, isti entitet iz stvarnog svijeta pojavljuje se pod različitim nazivima, isti entitet iz stvarnog svijeta opisan je različitim atributima, dva ili više entiteta iz stvarnog svijeta su prikazani različitim brojem entiteta u modelu podataka. Nedostaci unutar pojedinih modela su, najčešće, nedefinisanost identifikatora (primarnih ključeva), nedefinisanost veza među podacima, najčešće kao posljedica nepostojanja primarnih ključeva, nedefinisanost veza i pored postojanja primarnih i drugih (stranih) ključeva. Navedene pojave su posljedica razvoja tokom upotrebe i nedoslijednosti tog razvoja, naglašenog ponavljanje uvedenog prilikom izrade zahtjevnih ili složenih programskih rješenja, kao i ukupne nenormalizovanosti modela.

3.2.9. Posmatranje poslovnog sistema Definisanje zahtjeva za IS se može dopuniti uvidom u poslovne procese, odnosno posmatranjem radnih sredina. Posmatra se lokacija i kretanje ljudi, tok izvršavanja poslova, fizički ulazi i izlazi sistema, zaprimanje, izrada i razmjena dokumenata, procesi osnovne djelatnosti, npr. proizvodnje. Prednost ovakvog pristupa je u tome što je analitičar u stanju da realno sagleda poslovni proces. Ovaj pristup je efikasan, ako se dobro provede, i obezbjeđuje pouzdanost prikupljenih informacija. Nedostaci posmatranja poslovnog sistema su neefikasnost, ako se dobro ne provede, znatan utrošak vremena, ometanje i nelagodnost posmatranih osoba, mogućnost manipulacije posmatrača, npr. prikrivanjem uobičajenog kršenja radnih procedura. Podaci dobijeni iz malog broja kratkotrajnih posmatranja mogu biti nepouzdani i netačni. Posmatranje na licu mjesta je najteža metoda za utvrđivanje činjenica.

3.2.10. Radni sastanci Radni sastanci (sjednice) se organizuju da analitičari i korisnici zajednički provode analizu i oblikovanje. Cilj sjednice je (zajedničko) pronalaženje najboljeg rješenja. 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 potiču na aktivno i kreativno sudjelovanje. Izvodi se tako da se od svakog ispitanika iz grupe traži da definiše svoj pogled na idealno rješenje. Svaki učesnik iznosi sve što mu pada na pamet u vezi sa problemom koji se rješava. Od predloženih rješenja odabira se najbolje prema realnoj izvodljivosti. Postupak je


65

koristan tamo gdje postoje korisnici koji dobro poznaju sistem, ali teško 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 rješavaju problemi važni za cijeli poslovni sistem ili veći dio poslovanja. Njihovim organizovanjem se izbjegavaju specifični (egzotični) i nejasni zahtjevi, preciznije se ustanovljava doseg projekta i bolje uočava protivrječnost zahtjeva. Nedostaci radnih sjednica su pasivnost učesnika, “usitnjavanje” razgovora i često udaljavanje od tema. Sjednice treba da traju više dana (5 do 10) u nekoliko sedmica. Ovom zahtjevu u praksi je vrlo teško udovoljiti zbog obaveza učesnika. Otpor sjednici je srazmjeran nivou položaja konkretnog učesnika. Otpor je naročito naglašen kada poslovni sistem zapošljava informatičare, jer se podrazumijeva da je informatizacija isključivo njihov posao.

3.2.11. Razvoj prototipa Razvoj prototipa se koristi kada korisnik ne može tačno da definiše svoje informacione potrebe prije nego što se izgradi informacioni sistem. Razlog tome može biti nedostatak postojećeg modela na kojem bi korisnik zasnivao svoje potrebe ili pak

66


teška vizuelizacija budućeg sistema. Da bi se olakšala vizuelizacija budućeg sistema izgrađuje 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 korištenje sistema i modifikovanje istog iterativno se ponavlja, a informacione potrebe korisnika otkrivaju korištenjem sistema. Izrada prototipa pogodna je u onim okruženjima gdje je teško definisati konkretni model sistema, te u okruženjima gdje se informacione potrebe korisnika mjenjaju ili razvijaju (prototipski model razvoja IS je obrađen u podtački 2.4.3).

3.2.12. Najčešći problemi pri prikupljanju informacija Ponašanja korisnika često može da uzrokuje niz problema pri definisanju zahtjeva za IS. Informatičkim žargonom su opisana ponašanja koja se mogu očekivati od korisnika. 1. Taktika “kuhinjskog sudopera”: korisnik navodi (preko)brojne potrebe, gomilu nepotrebnih izvještaja, ekranskih formi, sortiranja, izračunavanja i sl. Ovakav pristup obično 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 traži više mogućnosti, a zapravo mu je potrebna samo jedna ili dvije. Dodatni zahtjevi služe za postizanje bolje nagodbe sa analitičarom. Ova taktika obično 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 uspješno definisanje problema su male, jer samo korisnik može izraziti svoje potrebe i probleme. Korisnik je sklon prešutjeti izuzetke, koji su bitni (nužni!) za uspješnu realizaciju, a obično izuzeci zahtijevaju i najviše napora tokom ugradnje: "To je naša jedina procedura … (osim kada … )". Ne izjednačavati “tako se uvijek radi” sa “tako treba raditi”!


67

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

68


1. Detaljna analiza postojećeg sistema, te utvrđivanje potreba i zahtjeva: Kako radi postojeći sistem?, Na koji način korisnici koriste sistem da bi obavili svoj posao?, Koji su problemi pri korištenju 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 način 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 potčinjen, kako sarađuju različiti odjeli, itd. Za potrebe pozadinske analize može se izraditi shema organizacione strukture iz koje će biti vidljivo koja osoba ili grupa ljudi obavlja koji dio posla (modeliranje funkcija). Za ostale elemente, takođe, se rade odgovarajući 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 inženjerstvo je procesno osjetljiva tehnika, usmjerena podacima i proučavanju poslovnog sistema ili njegovih većih dijelova kao cjeline, a ne projekat po projekat. Brzi razvoj aplikacija (Rapid Application Development (RAD)) je razvoj djelomičnih verzija aplikacija, koje mogu evoluirati do konačnog rješenja. Združeni razvoj aplikacija (Joint Application Development (JAD)) je analiza zasnovana na intenzivnim radnim sjednicama na kojima vlasnici, korisnici, analitičari, dizajneri i projektanti zajednički definišu i oblikuju sistem. Objektno usmjerena analiza omogućava: modeliranje učaurivanjem podataka i procesa u objekte, proučavanje postojećih 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 postojećim objektima graditi novu aplikaciju. Navedeni postupci se mogu komplementarno primjenjivati i pored uvriježenog mišljenja da je riječ o međusobno isključivim metodama!


69

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

70


Za 40 do 60% grešaka u projektu uzrok leži u greškama napravljenim u fazi postavljanja zahtjeva. Tipična posljedica su "prazna očekivanja", razlika između onog što očekuje naručilac i onoga šta je izvršilac mislio da treba napraviti. Naknadne prepravke mogu predstavljati do 40% troškova razvoja, od čega je 70 do 85% pripisivo pogrešnim zahtjevima. Nepotpuno definisani zahtjevi čine nemogućim planiranje projekta i praćenje promjena [Leffingwell, 1997].

4.3.2. Vrste zahtjeva Zahtjevi mogu biti: poslovni zahtjevi (zašto), korisnički zahtjevi (zahtjevi krajnjih korisnika), funkcionalni zahtjevi (šta) ili nefunkcionalni zahtjevi (kako ili kako dobro). Poslovni zahtjevi definišu ciljeve organizacije (korisnički zahtjevi na višem nivou), odnosno daju opis problema koje treba riješiti (npr. poslovna potreba "Poboljšanje usluge postojećim klijentima i pridobijanje novih") ili sadržani u dokumentima u kojima se opisuje vizija i opseg projekta (npr. poslovni zahtjev "Omogućiti Internet prodaju"). Korisnički zahtjevi (zahtjevi krajnjih korisnika) opisuju zadatke koje korisnik mora moći obaviti služeći se aplikacijama ili koji su sadržani u opisima slučajeva korištenja, tj. opisima scenarija rada. Funkcionalni zahtjevi (šta) definišu softversku funkcionalnost (očekivano ponašanje i operacije koje sistem može izvoditi), koju treba ugraditi u proizvod da bi omogućio korisnicima obavljanje njihovih zadataka. U ovu grupu zahtjeva spadaju posebno zanimljive mogućnosti programa, odnosno skup logički povezanih funkcionalnih zahtjeva koje korisniku omogućavaju ispunjavanje poslovnih zahtjeva. Nefunkcionalni zahtjevi (kako ili kako dobro) su standardi, pravila i ugovori koje proizvod mora zadovoljiti, opisi vanjskih interfejsa, zahtjevi za performansama, ograničenja za dizajn i implementaciju, te osobine kvaliteta koje preciziraju opis proizvoda navodeći karakteristike proizvoda u različitim 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]. Očekivana novčana ušteda: Sistem mora biti tako koncipiran da prava na subvencioniranu prehranu može koristiti samo student koji ih je stekao i da ih može koristiti samo u svrhu prehrane. Sistem mora onemogućiti: korištenje subvencije od strane osoba koje nemaju na to pravo, zaradu ilegalnih posrednika, korištenje subvencije za druge svrhe osim prehrane, naplatu usluga koje nisu pružene.


71

U idealnom slučaju zahtjevi vlasnika podudaraju se sa poslovnim ciljevima! Primjer 2: Zahtjevi krajnjih korisnika. Prehrana kod bilo kojeg izvršioca usluga: Novi sistem mora omogućiti da student ostvaruje svoje pravo kod bilo kojeg izvršioca usluge subvencionirane prehrane. Dosadašnja praksa je bila da svaki izvršilac usluga izdaje svoje bonove koji se mogu koristiti samo u određenim restoranima. Ukinuti plaćanje unaprijed: Treba izbjeći bilo kakvo plaćanje od strane studenata za potrebe ostvarivanja prava, a naročito unaprijed. Ukloniti nepotrebne postupke za ostvarivanje prava: Sistem mora biti tako koncipiran da kad se studentu jednom zavedu prava na matičnoj ustanovi nisu potrebna nikakva daljnja dokazivanja za ostvarivanje prava kod izvršioca usluga. Smanjiti rizik gubitka ostvarenih prava: Sistem mora onemogućiti zloupotrebu stečenih prava. Lakše ostvarivanje ostalih prava iz studentskog standarda, npr. javni prijevoz po povlaštenoj cijeni, pozorišta, kina, smještaj 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" nameće slijedeća 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 određeni dio interfejsa. Poruka će se ažurirati svakih 60 s (±10 s) nakon što započne izvođenje pozadinskog zadatka i biće vidljiva cijelo vrijeme. 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 grešci ukoliko dođe do zastoja u izvođenju. Problem je rastavljen u više zahtjeva budući da će svaki zahtijevati posebno testiranje. Ukoliko je više zahtjeva grupisano u jedan lakše je previdjeti neki od njih tokom izrade ili testiranja. Primjećuje se da u zahtjevu nije detaljno opisano kako i gdje će se poruka ispisivati. To će biti odlučeno tokom dizajna. Primjer 4: Neostvariv zahtjev. Zahtjev "Softverski proizvod će se trenutno prebaciti između ispisivanja i skrivanja oznaka koji se ne mogu štampati" je neostvariv zahtjev iz slijedećih razloga: Računari ništa ne mogu napraviti trenutno! Da li programska podrška sama odlučuje kad će se prebaciti iz jednog stanja u drugo ili je to inicirano akcijom korisnika? Na koji dio teksta će se primijeniti promjena prikaza: da li samo označeni tekst, cijeli dokument ili nešto

72


treće?. Uočava se i nejednoznačnost: 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 moći da obavi nekakvu akciju, ali nije točno navedeno kakvu (npr. kombinacija tipki), šta se prepušta dizajnerima. Primjer 5: Neodređeni zahtjev. U zahtjevu "Parser će brzo generisati izvještaj o greškama HTML oznaka, koji omogućava brzu ispravku grešaka kada program koriste početnici u HTML-u" uočavaju se slijedeće neodređenosti: riječ "brzo" je neodređena, nije definisano šta predstavlja izvještaj i to čini zahtjev nekompletnim. Postavljaju se i slijedeća pitanja: Kako se ovjerava zahtjev?, Kako pronaći nekoga ko se smatra početnikom u HTML-u i zatim vidjeti kako brzo će, uz pomoć izvještaja, ispraviti greške?, Kada se generiše izvještaj? Bolje rješenje glasi: Nakon što je HTML analizator obradio datoteku, generisaće izvještaj koji sadrži broj linije i tekst pronađenih HTML grešaka, te opis svake greške. Ukoliko nema grešaka prilikom analize, neće se generisati izvještaj.

4.3.3. Određivanje zahtjeva Poslovni zahtjevi: Sve što opisuje finansijski, trgovački ili drugi poslovni prodor koji korisnici, ili organizacija koja razvija sistem, mogu dobiti je, najvjerovatnije, poslovni zahtjev. Slučajevi korištenja ili scenariji: Opšte izjave o korisničkim ciljevima ili poslovnim zadacima, koje korisnici moraju obavljati, najvjerojatnije su slučajevi korištenja, dok specifični opisi zadataka predstavljaju korisničke scenarije. Specifične zadatke treba generalisati u opšte slučajeve korištenja. Poslovna pravila: Kada korisnik izjavi da neku aktivnost mogu obavljati samo pojedine osobe ili uloge, pod određenim uslovima, on možda opisuje poslovno pravilo. Poslovna pravila su operativni principi poslovnih procesa. Ona nisu funkcionalni zahtjevi. Funkcionalni zahtjevi: Izjava koja počinje sa „Korisnik mora moći da obavi neku funkciju”, ili „Sistem treba moći da demonstrira određeno ponašanje” je najvjerovatnije funkcionalni zahtjev. Funkcionalni zahtjevi opisuju vidljivo ponašanje sistema i definišu šta će sistem raditi. Treba svima biti jasno zašto sistem „mora” biti u stanju da obavlja


73

određene funkcije. Predloženi funkcionalni zahtjevi ponekad predstavljaju zastarjele ili neefikasne poslovne procese koji ne trebaju biti uključeni u novi sistem. Atributi kvaliteta: Izjave koje opisuju kako dobro sistem obavlja funkciju su atributi kvaliteta, tj. jedna vrsta nefunkcionalnih zahtjeva. Zahtjeve koji opisuju poželjne 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 između sistema i vanjskog svijeta. Specifikacija sistemskih zahtjeva treba da uključuje odlomke za ove zahtjeve, uključujući i interfejse, te mehanizme komunikacije za korisnike, hardver i druge softverske sisteme. Ograničenja su uslovi koji ograničavanju izbor rješenja raspoloživih dizajneru ili programeru. Spadaju u nefunkcionalne zahtjeve i trebaju biti dokumentovani. Neopravdana ograničenja treba pokušati odbaciti jer onemogućavaju postizanje najboljeg rješenja. Takođe, mogu umanjiti primjenu komercijalnog softvera i komponenti u rješenju. Neka ograničenja mogu pomoći u zadovoljavaju atributa kvaliteta. Primjer je poboljšanje prenosivosti programa korištenjem samo standardnih naredbi nekog programskog jezika. Definicija podataka je bilo koji opis formata, dozvoljenih vrijednosti, pretpostavljenih vrijednosti ili kompozicija složenih struktura podataka. Sve definicije treba pohraniti u Rječnik podataka, kao glavni orjentir za učesnike na projektu. Ideje o rješenju: Ako korisnik opisuje specifičan način interakcije sa sistemom, kojom bi mogao obaviti neku akciju, npr. „Korisnik odabira podatak koji želi iz padajuće liste”, on predlaže rješenje, a ne zahtjev. Predloženo rješenje može odvući pažnju od pravih zahtjeva. Kod postavljanja zahtjeva treba se usmjeriti na ono što je potrebno obaviti, a ne na način realizacije. Treba istražiti zašto korisnik predlaže određenu ugradnju, jer to može pomoći u razumijevanju stvarne potrebe i korisnikovih očekivanja o načinu kako sistem treba da raditi.

4.3.4. Postavljanje prioriteta zahtjeva Nužno svojstvo sistema nameće pitanje: Da li vlasnik sistema nešto stvarno mora imati? Postoji tendencija da se previše zahtjeva proglasi nužnim! Po definiciji, ako sistem ne uključuje nužne zahtjeve, taj sistem ne može ispuniti svoju svrhu. Treba testirati svaki zahtjev koji se smatra nužnim i probati ga rangirati. Ako se zahtjev može rangirati onda nije obavezan. Potpuno obavezni zahtjevi se ne mogu rangirati, jer su nužni za prvu verziju sistema.

74


Poželjno svojstvo sistema su funkcije koje korisnik želi na kraju da ima. Ranije verzije sistema mogu pružiti (ne potpunu) funkcionalnost bez tih zahtjeva. Poželjni zahtjevi mogu i trebaju biti rangirani. Neobvezna svojstva sistema su proizvoljni zahtjevi, svojstva i mogućnosti bez kojih se može, iako bi lijepo bilo ih imati. To nisu pravi zahtjevi. Ovi zahtjevi, takođe, mogu biti rangirani.

4.3.5. Dokumentovanje analize zahtjeva Kratke definicije zahtjeva glase: (1) izjava o stanju, ograničenjima i potrebama sistema, (2) narativni dokument namijenjen korisniku, ili ga piše korisnik, a sačinjavaju ga poslovni i korisnički zahtjevi, kao i njihovi prioriteti, uočeni problemi, ključne pretpostavke i preporuke za njihovo rješavanje. Specifikacija zahtjeva, često nazvana i funkcionalnom specifikacijom, je strukturirani dokument sa detaljnim opisom očekivanog ponašanja sistema (tabela 4.1). Namijenjen je ugovaračima i izvršiocima razvoja. Predstavlja cjeloviti i nezavisan pogled na sistem. Sačinjavaju 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 Okruženje u kojem se izvodi proizvod 2.5 Ograničenja dizajna i ugradnje 2.6 Pretpostavke i zavisnosti 3. Zahtjevi za interfejsom 3.1 Korisnički 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 sigurnošću korisnika 5.3 Zahtjevi za sigurnošću podataka 5.4 Kvalitet programske podrške 5.5 Poslovna pravila 5.6 Korisnička dokumentacija 6. Ostali zahtjevi Dodatak A: Rječnik Dodatak B: Modeli i dijagrami Dodatak C: Lista nedovršenih/neodređenih 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 lošeg planiranja zahtjeva Nedovoljna uključenost korisnika: Bez korisnika se ne može točno znati šta korisnici žele. Takvi proizvodi su neprihvatljivi. Čudni korisnički zahtjevi: Neopravdana promjena mišljenja tokom izvedbe uzrokuje prekoračenje predviđenog roka za realizaciju, kao i degradaciju kvaliteta proizvoda. Nejasni (dvosmisleni) zahtjevi: Situacija u kojoj čitalac(i) zahtjeva taj zahtjev tumači(e) na više načina. To uzrokuje prepravljanje i gubljenje vremena. Pretjerano ukrašavanje: Želja izvođača da dodaju novu funkcionalnost "koja treba da se svidi korisnicima" i zahtjev korisnika za dodacima koji dobro izgledaju ali ne pridonose funkcionalnosti. Izrada takvih dodataka je nepotrebna i predstavlja gubljenje vremena. Minimalističke specifikacije: Tendencija postavljanja minimalnih zahtjeva ili skiciranja koncepata, uz želju da ih izvođači nadopune tokom izvedbe, izaziva frustracije izvođača i neispunjena očekivanja korisnika. Zanemarivanje potreba: Zanemarivanje potreba određenih (grupa) korisnika izaziva stvaranje „opozicije“ projektu.

4.3.7. Svojstva dobro postavljenih zahtjeva Svojstva dobro postavljenih korisničkih zahtjeva su definisana IEEE standardom [1998]. Ta svojstva su: potpunost (cjelovitost), tačnost, ostvarivost (izvodljivost), nužnost, poredak po prioritetima, nedvosmislenost i mogućnost provjere. Dobra specifikacija zahtjeva korisnika mora da sadrži slijedeća svojstva: potpunost, konzistentnost, mogućnost izmjene i mogućnost praćenja. Cilj je napisati dovoljno dobre zahtjeve, na osnovu kojih se može pristupiti dizajnu i ugradnji pojedinih komponenata sistema, uz prihvatljiv stepen rizika.


76

Primjer dobro postavljenih korisničkih zahtjeva: “Hemičar ili član osoblja hemijske laboratorije može podnijeti zahtjev za jednom ili više hemikalija. Zahtjev može biti udovoljen ili dostavom pakovanja hemikalije koja se već nalazila na zalihi hemijske laboratorije ili upućivanjem narudžbe za novim pakovanjem hemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kada je ispunjen do trenutka kada je udovoljen ili otkazan. Takođe, mora pratiti istoriju svakog pakovanja hemikalija od trenutka kada stigne u kompaniju do trenutka kad je potpuno upotrebljen ili odbačen.”

Na osnovu izjava korisnika i prikupljene dokumentacije modeliraju se pojedine komponente sistema (procesi, podaci, događaji). Mogu se definisati preslikavanja uočenih imenica i glagola u konkretne komponente analitičkog modela. Moguća preslikavanja su opisana u tabeli 4.2. Tabela 4.2. Tip riječi

Primjer

Komponente analitičkog modela

Imenica

- Ljudi, organizacije, softverski sistemi, jedinice podataka ili postojeći objekti

- Skladišta podataka (DFD – modeliranje toka podataka) - Entiteti ili njihovi atributi (ERD – dijagram entiteti - veze) - Klase ili njihovi atributi (dijagram klasa)

- Akcije, ono što korisnik može poduzeti ili događaji koji se mogu dogoditi

- Procesi (DFD) - Odnosi (ERD) - Prelazi (iz stanja u stanje) (STD – dijagram prelaza stanja) - Metode klasa (dijagram klasa)

Glagol


77

5. Modeliranje fukcija i procesa 5.1. Uvod u modeliranje funkcija i procesa Logički procesi (koje sačinjavaju funkcije, događaji i elementarni procesi) su akcije koji se obavljaju bez obzira na način ugradnje i raspoložive resurse sistema. Neke metode poistovjećuju funkcije i procese. Stvarni problemi su preveliki i presloženi da bi se riješili odjednom („u komadu”), te je potrebno njihovo strukturno raščlanjivanje (razlaganje). Načelo je poznato i glasi „podijeli pa s/vladaj” (lat. divide et impera, eng. divide and conquer). Sistem se razlaže i opisuje hijerarhijskim modelima. Modeli sistema se oblikuju iterativnim razlaganjem sa vrha prema dolje. Razlagati se mogu: funkcije i procesi, organizaciona struktura, struktura podataka i struktura programske opreme.

5.1.1. Logički procesi Funkcije su skup logički povezanih trajnih poslovnih aktivnosti i zadataka (npr. djelatnost, posao). Funkcije se obavljaju stalno (nemaju određeni početak i kraj). Funkcije obavljaju osobe, grupe radnika ili organizacione cjeline. Primjeri funkcija: Prodaja, proizvodnja, otprema, računovodstvo. Funkcija se može sastojati od desetina pa i stotina diskretnih procesa. Funkcije se mogu hijerarhijski razložiti do nivoa diskretnih procesa, koji obavljaju određeni zadatak kojim odgovaraju na poslovne događaje. Događaj je logički dio posla koji se obavlja kao nedjeljiva cjelina. Često je u upotrebi i naziv transakcija. Pokreće se diskretnim ulazom i završava nakon što proces odgovori odgovarajućim izlazom. Poslovni događaj može se predstaviti jednim procesom kojim sistem reaguje na taj događaj. Logički događaj dalje se razlaže do elementarnih procesa kojima se prikazuje reakcija sistema na taj događaj. Proces (elementarni, primitivni proces) je postupak, način rada, doslijedna izmjena stanja. Takođe, proces je diskretna odluka, aktivnost ili zadatak kojim se obavlja neki posao.

78


Proces se obavlja uvijek na isti način (za određeni ulaz se dobija isti izlaz). Trajanje procesa je konačno i odredivo (poznati: početak, završetak i ponavljanje). Za obavljanje procesa se koriste sredstva (npr. ljudska, materijalna, finansijska). Poslovna pravila su instrukcije i logika koji određuju proceduru obavljanja procesa. Ugrađuju se u računarski program (npr. preduslovi izlaska na ispit, broj polaganja ispita, uslovi upisa). Poslovna politika je skup poslovnih pravila. U većini poslovnih sistema predstavlja osnovu za donošenje odluka.

5.1.2. Modeliranje funkcija Funkcionalna dekompozicija (dekompozicija funkcija) se koristi za izradu opšteg modela funkcija (modela poslovnih funkcija) posmatranog sistema u fazi planiranja, što predstavlja strukturirano planiranje. Hijerarhija funkcija iterativno se razlaže do nivoa procesa, tj. do trenutka kada se počne opisivati šta se nekom funkcijom obavlja (slika 5.1).

Slika 5.1. Iterativno razlaganje hijerarhija funkcija do nivoa procesa. Dijagram funkcionalne dekompozicije (Functional Decomposition Diagram (FDD)) koristi istu notaciju za razlaganje bilo koje hijerarhijske strukture, pa se često zove samo Dijagram dekompozicije ili Mapa hijerarhije.


79

Elementi dijagrama dekompozicije su: funkcije, procesi, spojnice i vanjski spojevi. Funkcije se označavaju se (glagolskom) imenicom (npr. Prodaja, Proizvodnja), procesi glagolskim izrazom oblika infinitiv+objekat (ofarbati dio, osušiti dio), spojnice su spojevi između funkcija i procesa, a vanjski spojevi su spojevi sa dijelovima dijagrama na drugim stranicama (slika 5.2). Primjer dijagrama dekompozicije za jedan sistem /podsistem prikazan je na slici 5.3. Funkcija

Proces

Slika 5.2. Elementi dijagrama dekompozicije. MARKET

Knjigovodstvo

Nabava

Evidentiranje dobavljača

Naručivanje robe

Izrada narudžbi

Knjiženje

robe

Prodaja

Evidentiranje kupca

Fakturisanje robe

Prodaja robe

Izrada otpremnice

Zaprimanje robe

Dodavanje

Ažuriranje

Otprema robe

Brisanje

Slika 5.3. Primjer dijagrama dekompozicije za jedan sistem/podsistem.


80

Izrada globalnog modela funkcija može započeti izradom hijerarhijske liste funkcija po pojedinim organizacionim cjelinama. Primjer: •

•

NABAVA • Evidentiranje dobavljača • Nabavka robe - Izrada narudžbi - Zaprimanje robe UPRAVLJANJE OSOBLJEM • Evidentiranje službe - Prijem u službu - Praćenje službe » redovni rad » prekovremeni rad » bolovanje » godišnji odmori - Otpuštanje iz službe • Obračun plata

Izrada dijagrama dekompozicije odvija se po slijedećem postupku. Polazi se od korijena dijagrama, kome se dodjeljuje ime sistema. Slijedi razrada u podsisteme i poslovne funkcije. Daljnja razrada je do nivoa operacionalizacije. Pri izradi dijagrama dekompozicije potrebno je pridržavati se slijedećih pravila: svaki proces je roditelj ili dijete, roditelj mora imati barem dvoje djece, dok po većini standarda, dijete smije imati samo jednog roditelja. Preporuke: Izostaviti procese koji samo premještaju ili preusmjeravaju podatke, a pri tome ih ostavljaju nedirnute. Pažnju usmjeriti na procese koji: nešto računaju (npr. prosjek ocjena), donose ili potpomažu odluke (npr. određivanje raspoloživosti robe pri naručivanju), filtriraju ili sumiraju podatke (npr. računi kojima je istekao rok plaćanja), organizuju podatke u korisne informacije (npr. generisanje izvještaja), pokreću druge procese (npr. mijenjaju modalitet rada uređaja) ili rukuju podacima (npr. stvaranje, čitanje, ažuriranje, brisanje i slično). Pomoću hijerarhijskih dijagrama se može prikazati funkcionalna dekompozicija realnog sistema. Takav jedan dijagram, dobijen pomoću alata Function Hierarchy Diagramer (Designer 2000, ORACLE), je prikazan na slici 5.4. Svaka funkcija, koja se kreira putem navedenog alata istovremeno predstavlja i proces u budućim dijagramima toka podataka. Zato pojam procesa i funkcije, ili poslovne funkcije, predstavljaju sinonime u terminologiji mnogih CASE alata.


81

Slika 5.4. Primjer dijagrama dekompozicije funkcija (procesa). Pored osnovnih podataka za funkcije, za svaku funkciju se određuje da li je riječ o elementarnoj funkciji ili ne. Za funkciju se kaže da je elementarna ukoliko njeno započinjanje podrazumjeva da će se ona u cjelosti izvršiti, ili će efekti njenog izvršavanja u cjelosti biti poništeni. Elementarne funkcije se, u principu, ne moraju dalje dekomponovati i tada one predstavljaju listove u hijerarhijskoj strukturi funkcija. U cilju preciznijeg specificiranja, postoji mogućnost da se elementarna funkcija dalje dekomponuje na atomične funkcije, koje u tom slučaju predstavljaju listove u hijerarhijskoj strukturi funkcija.

5.1.3. Dijagram organizacije Dijagram organizacije (shema, mapa, karta organizacije) daje prikaz strukture organizacije hijerarhijom pravougaonika („kućica"). Svaki pravougaonik predstavlja određenu ulogu ili odgovornost u organizaciji (slika 5.5.). Osim dijagramsko orijentisanog alata, za definisanje organizacione strukture sistema, može se upotrijebiti alat za neposredni pristup rječniku podataka, pomoću 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. služba XXX

Sekretar XXX

Prodekan za naučni rad XXX Finansijska služba

Prodekan za finansije XXX

Biblioteka

Institut XXX

Računarska 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 rječnika. Elementi organizacione strukture se definišu kreiranjem pojava tipa objekta pod nazivom Business Units, odnosno poslovne (organizacione) cjeline. Navođenjem oznake neposredno nadređene organizacione cjeline, prilikom unošenja nove organizacione cjeline, uspostavlja se hijerarhijska struktura organizacionih cjelina (desna strana ekranske forme).

5.2. Metode strukturiranog modeliranja, analize i dokumentovanja tehnoloških procesa 5.2.1. Metodologija funkcionalnog modeliranja IDEF0 Za realizaciju programa integrisane kompjuterizacije proizvodnje razrađena 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 uspješno primjenjuje u najrazličitijim oblastima i pokazala kao efikasno sredstvo za analizu, projektovanje i predstavljanje (modeliranje) tehnoloških procesa. Metodologija funkcionalnog modeliranja IDEF0 je zamišljena kao inženjerska disciplina za razvoj složenih sistema, koja uključuje uređaje i ljude. Predstavlja metodu za modeliranje tehnoloških 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 odražava nekoliko poslovnih funkcija. Četiri strane bloka imaju slijedeće 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 između funkcija u IDEF0 se predstavlja u obliku duge, koja odražava 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 „upravljački“. Drugim rječima, poslovne funkcije se mogu prikazati ICOM konceptom (slika 5.7), koji se sastoji od: • • • •

ulaz (I = Input): nešto što se troši u procesu (nije obavezan), upravljanje (C = Control): ograničenje na izvršavanje procesa (obavezno), izlaz (O = Output): rezultat procesa (obavezan), mehanizam (M = Mechanism): koristi se u procesu, ali se ne troši (nije obavezan).

Principi modeliranja u IDEF0. U IDEF0 su realizovana tri osnovna principa modeliranja procesa: princip funkcionalne dekompozicije, princip ograničenja složenosti i princip konteksta. Princip funkcionalne dekompozicije se sastoji u predstavljanju složene poslovne funkcije skupom elementarnih funkcija, slika 5.8. Princip ograničenja složenosti 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 počinje sa crtanjem kontekstnog dijagrama. Na kontekstnom dijagramu se prikazuje samo jedan blok, odnosno samo glavna poslovna funkcija sistema koji se modelira. Pri određivanju glavne poslovne funkcije, neophodno je imati u vidu cilj modeliranja. Jedan poslovni sistem se može opisati na razne načine, u zavisnosti od toga sa kog stanovišta se posmatra.

Slika 5.8. Grafički prikaz funkcionalne dekompozicije.


85

Kontekstni dijagram ima još jednu ulogu u funkcionalnom modeliranju. On „određuje“ granice modeliranja poslovnog sistema, odnosno određuje uzajamnu vezu između sistema koji se modelira i njegovog okruženja. Nakon upoznavanja s osnovnim pojmovima funkcionalnog modeliranja poslovnih procesa, neminovno se postavlja pitanje kako ovo modeliranje pomaže povećanju efikasnosti i kvaliteta djelatnosti poslovnog sistema. Postojeći modeli KAKO JE. Razmatrani poslovni sistem je obavezno dio nekog projekta izgradnje ili razvoja korporativnog IS. Izgrađeni funkcionalni modeli KAKO JE omogućavaju jasno utvrđivanje koji poslovni procesi se ostvaruju u poslovnom sistemu, koji se informacioni objekti koriste pri izvršavanju poslovnih procesa i zasebnih operacija. Funkcionalni model KAKO JE je polazna tačka za analizu zahtjeva poslovnog sistema, pojave problema i „uskih grla“ u razradi projekta usavršavanja poslovnih procesa. Poslovna pravila. Model parcijalnih procesa omogućava uočavanje i tačno određivanje poslovnih pravila, koja se koriste u radu poslovnog sistema. Instrukcija Dokument za rukovodstvo

Sortirati dokumente

Neregistrovani dokumenti

Dokumenti za direktora podliježu registraciji

Registrovati dokumente

Registrovani dokumenti

Prijemno

Slika 5.9. Grafički 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 završetka korištenja ili odašiljanja). Pri izvršavanju operacije „sortirati dokumente“ koristi se poslovno pravilo: „ne podležu registraciji kopirani

86


dokumenti, telegrami i pisma“. Ovo pravilo je definisano u instrukciji o toku podataka. Funkcionalni model omogućava ne samo identifikaciju postojanja pravila, nego i na kom radnom mjestu poslovno pravilo se mora primjeniti. U okviru funkcionalnog modela poslovno pravilo ima slijedeći oblik: „ukoliko je u prijemno došao dokument namjenjen rukovodstvu, on podliježe sortiranju, a kao rezultat, na osnovu instrukcije, se određuje da li dokument podliježe registraciji ili ne“. Informacioni objekti. Funkcionalni model omogućava 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 određuje kako se koriste informacioni objekti u okvirima poslovnih procesa. Izgrađeni modeli KAKO ĆE BITI. Razvoj i implementacija korporativnog IS dovodi do promjena uslova izvršavanja pojedinih operacija, kao i strukture poslovnih procesa. To zahtjeva promjenu poslovnih pravila, promjena u poslovnom sistemu, modifikaciju važećih instrukcija zaposlenih. Funkcionalni model KAKO ĆE BITI omogućava već u fazi projektovanja budućeg IS predviđanje tih promjena. Primjena funkcionalnog modela KAKO ĆE BITI omogućava, ne samo skraćenje roka implementacije IS, nego i smanjenje mogućeg rizika uslijed neprilagođenosti korisnika informacionim tehnologijama. Raspodjela resursa. Funkcionalni model omogućava jasnu raspodjelu resursa između operacija poslovnog procesa, šta doprinosi efikasnosti korištenja resursa. Taj zadatak je naročito aktuelan pri uvođenju novih poslovnih procesa u poslovnom sistemu. Daljnja razrada metodologije funkcionalnog modeliranja IDEF0 je razvoj slijedeće dvije tehnike, i to: tehnike za dokumentovanje tehnoloških procesa (IDEF3) i tehnike za oblikovanje tokova podataka (DFD), koja prikazuje tok informacija.

5.2.2. Dokumentovanje tehnoloških procesa IDEF3 Metoda IDEF3 predstavlja standard za dokumentovanje tehnoloških procesa, koji se odvijaju u poslovnim sistemima, i predstavlja alat za vizuelno praćenje 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 završetka svake etape). Izvršavanje svakog scenarija prati odgovarajući tok dokumenata, koji je dvojak: tok dokumenata koji određuju strukturu i redoslijed procesa (npr. tehnološke napomene, opis standarda) i tok dokumenata koji odražavaju hod njegovog izvršenja (npr. rezultati testova, ekspertiza).


87

Postoje dva tipa dijagrama u standardu IDEF3, koji predstavljaju opise jednog te istog scenarija tehnološkog procesa iz različitih 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. Pomoću dijagrama PFDD dokumentuje se redoslijed i opis faza obrade dijela u okviru razmatranog tehnološkog 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 određuje da li je potrebno dio ponovo ofarbati (u slučaju odstupanja od standarda) ili ga poslati na dalju obradu.

OFARBATI PONOVO OFARBATI DIO

OSUŠITI DIO

TESTIRATI DIO POSLATI U SLIJEDEĆU RADIONICU

Slika 5.10. Primjer PFDD dijagrama. Na slici 5.10 je prikazan dijagram PFDD, koji predstavlja grafičku predstavu scenarija obrade dijela. Pravougaonici na dijagramu PFDD se zovu funkcionalni elementi ili elementi ponašanja (Unit of Behavior (UOB)) i označavaju aktivnosti, fazu procesa ili primljena rješenja. Svaki UOB se imenuje glagolskim izrazima oblika infinitiv + objekat i jedinstvenim brojem. Dijagrami PFDD služe za vizuelni prikaz scenarija odvijanja procesa u realnom sistemu. Na dijagramima za veze između funkcija se koriste slijedeći grafički simboli: - prethođenje (Precedence), prethodna aktivnost se mora završiti da bi slijedeća započela (crta se slijeva nadesno ili odozgo prema dole), - tok objekata (Object Flow), izlaz prethodne je ulaz u slijedeću aktivnost, - relacioni (Relational Link), povezivanje uz korisnički definisani uslov. Prelazi, veze (J - junction) su slijedeće: • & (logičko I) - svaka povezana aktivnost uvijek se obavlja/završava, • X (ekskluzivno ILI) - obavlja se samo jedna od povezanih aktivnosti, • O (ILI) - obavlja se jedna ili više povezanih aktivnosti.


88

Ako je dijagram PFDD tehnološki proces „sa stanovišta posmatrača“, onda dijagram OSTN omogućava posmatranje istog procesa „sa stanovišta objekta“, slika 5.11. Stanje objekta, dijela u razmatranom primjeru, i promjena tog stanja su ključni pojmovi OSTN dijagrama. Stanje objekta je prikazano krugovima, a promjene stanja usmjerenim linijama. Svaka linija je povezana sa odgovarajućim funkcionalnim blokom UOB, a kao rezultat je prikazana promjena stanja objekta. UOB/ Testirati sloj boje UOB/ Ofarbati dio

Rijetka boja

Novi sloj boje

Tvrda boja na dijelu

UOB/ Osušiti 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 slijedećim 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 podređeni procesi kontekstnom procesu, ali to može 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 omogućava 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 nadležnosti u


89

pogledu izvođenja pojedinih aktivnosti. Oblast nadležnosti je na dijagramu prikazana u obliku horizontalne trake, koja se proteže u visini odgovarajuće organizacione jedinice. To znači da je za sve procese u danoj oblasti zadužena nadležna organizaciona jedinica. Matrica „organizacione jedinice/procesi” se definiše pomoću 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 fizičkog i logičkog modela sistema, omogućava 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 može se koristiti za opis programske logike, opis promjene stanja, izradu upravljačkih specifikacija ili dizajn korisničkog interfejsa. D1

Spremište podataka

Tok podataka a

P1

Vanjski entitet

Tok materijala

Proces

5.13. Uprošteni dijagram toka podataka.

5.3.1. Elementi dijagrama toka podataka Tok podataka (data flow) predstavlja skupove podataka koji se kreću 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. Potvrđena prijavnica, Izlazni račun. 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 opšte nazive (npr. Obavljanje poslova nabavke). Opis procesa sadrži opis aktivnosti (algoritam) njegovog djelovanja. Spremište podataka (data store) predstavlja organizovani i trajni skup podataka. Označava mjesto pohrane podataka, npr. dokument, registrator, datoteka, relacija (tabela) u bazi podataka. Promjena sadržaja spremišta (punjenje, ažuriranje, pražnjenje) i korištenje (čitanje) obavlja se procesima. Spremište se označava imenicom (imenicom u množini), npr. Prijavnica (Prijavnice).


91

Vanjski entitet (external entity, external agent) je objekat vanjskog svijeta povezan sa posmatranim sistemom. Određuje granice posmatranog sistema. Vanjski entiteti predstavljaju izvorišta i odredišta podataka, to jest izvore i ponore podataka. Vanjski entiteti mogu biti osobe, orgazicione jedinice, ustanove, drugi sistemi. Za označavanje entiteta se koriste imenice, npr. Student, Kupac, Dobavljač.

5.3.2. Izrada dijagrama toka podataka Dekompozicija procesa se odvija na slijedeći način. Polazni dijagram ili dijagram konteksta hijerarhijski se razlaže na poddijagrame do nivoa osnovnih procesa. Proces na nekom nivou razrađuje se dijagramom na nižem nivou. Preporučuje se izrada dijagrama koji sadrže između 2 i 9 procesa, a poželjno je slijediti “pravilo 7±2” (slika 5.14)..

Slika 5.14. Primjer dijagrama toka podataka oblikovan pomoću alata Dataflow Diagramer (Designer 2000, ORACLE) .


92

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

0

Osoba

P0

Dobavljač

Videoteka

Članska karta

Novi video

Rezultat upita

Upit

0

Narudžba

Identifikacija

Zahtjev za rezervaciju Video

0

Članska karta i plaćanje

Član

Slika 5.15. Primjer dijagrama konteksta: Videoteka.


93

Primjer: Pregledni dijagram, određivanje granica sistema.

Rezervisati video

Slika 5.16. Određivanje 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: zatražiti lične podatke, evidentirati novog člana i izraditi člansku kartu (slika 5.17). Ponavljati postupak za svaki od procesa na poddijagramu. Uspostaviti nivo detalja slijedeći “pravilo 7±2”. Na kraju je potrebno provjeriti potpunost i ispravnost modela. Model obrazložiti korisniku, a zatim ga po potrebi ažurirati. Dubinu i uravnoteženost modela teško je odrediti. U praksi to može značiti doradu dijagrama u većem broju ponavljanja, čak i kada dijagrame rade iskusni analitičari.


94

Zahtjev za identifikaciju

Identifikacija

P1.1

Zatražiti lične podatke

Lični podaci P1.4 Evidentirati novog člana

P1.3

D1 Član

Član

Član

Izraditi člansku kartu

Članska karta

Slika 5.17. Određivanje dubine i uravnoteženosti modela podataka.

5.3.3. Pravila i ograničenja kod izrade DTP Pravilo balansa (očuvanja) tokova glasi: Količina tokova koji ulaze u proces i izlaze iz procesa mora odgovarati količini tokova podprocesa na nižem nivou hijerarhije. Nije dozvoljeno variranje tokova nekog nivoa na nižim nivoima (npr. tok T na nižim nivoima prikazivati kao T1, T2). Ograničenja i posebni slučajevi su slijedeći. 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 spremišta ili vanjskih entiteta. Ne dozvoljava se neposredna povezanost vanjskih entiteta, spremišta, spremišta i vanjskog entiteta. Nije dozvoljeno grananje toka u različite tokove, spajanje različitih tokova, kao i postojanje “rekurzivnih” procesa.

5.3.4. Preporuke za izradu DTP Prilikom izrade DTP treba voditi računa 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 spremišta ili odredišta. Obično imaju posebno značenje, a mogu se koristiti za prikaz posebnih stanja kao što je dojava poruke sistema (npr. dojava greške). Neposredno povezani procesi su kada jedan od procesa čeka na završetak prethodnog. Procesi koji ne obavljaju pretvaranje podataka su kada je izlazni tok jednak ulaznom. U tom slučaju treba preimenovati jedan od tokova ili treba obaviti prespajanje tokova, šta je učinjeno 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 različite notacije koje se koriste kod izrade DTP. Najčešće primjenjivane notacije su: 1. Gane/Sarson (korištena u primjerima), 2. Yourdon/DeMarco, 3. SSADM (korištena na slici 5.14), koje su navedenim redoslijedom prikazane na slici 5.19.


96 a

P1

Vanjski entitet

Proces

Ulazni tok

Izlazni tok

1

Vanjski entitet

Proces

Ulazni tok

Spremište podataka

Spremište podataka

Izlazni tok

1

a

Vanjski entitet

D1

Ulazni tok

Proces

D1

Izlazni tok

Spremište podataka

Slika 5.19. Notacije koje se koriste kod izrade DTP. Proširenja modela je izvršeno uvođenjem okidača (trigera), koji prikazuju učestalost 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. različite linije ili ikone).

5.3.6. Opisivanje podataka Rječnik podataka (Data Dictionary) je mjesto pohrane definicija elemenata podataka i struktura podataka. Predstavlja strukturirano spremište meta-podataka, tj. podataka o podacima. Prvobitno se pojavio kao proširenje dijagrama toka podataka, za pohranu opisa spremišta podataka i tokova podataka. Može se koristiti kao alternativna tehnika za prikaz modela podataka. Standardno se upotrebljava BNF notacija (Backus-Naur Form), koja se inače 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 (logičko I) Opcionalnost elemenata u zagradi (0 ili 1) Ponavljanje (iteracija) elemenata u zagradi, ni jednom do konačni broj puta Alternativa (selekcija) elemenata u zagradi Odvajanje alternativnih elemenata u [ ] izrazu


** @

97

Početna i završna vrijednost raspona definisanog [ ] izrazom Komentar Oznaka ključa

Primjer: Opis računa i stavki računa korištenjem BNF notacije. Racun = @BrRac + DatRac + BrKupca + { SifArt, NazArt, Cijena, Kol, Vrijednost } + (IznosRac)

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

Primjer: Opis podataka može započeti opisom najmanje logičke cjeline podataka, odnosno elementarnih podataka. Nakon toga se opisuju grupe sačinjene od elementarnih podataka, šta definiše strukturu podataka. Struktura podataka određuje sadržaj spremišta podataka, kao i tokove podataka (slika 5.20).

Elementarni podatak

Najmanja logička cjelina podataka

Struktura podataka

Grupe sačinjene od elementarnih podataka

Grupe sačinjene od struktura podataka

Tok podataka

Spremište 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 različite oblike, ali imaju nekoliko zajedničkih 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 sadrži algoritam zadatka koji se procesom obavlja, koji može poprimiti različite oblike (dizajn programa, odnosno opis programske logike). Na osnovu ovog algoritma može se, u zavisnosti od alata, generisati programski kôd (tabele 5.2 i 5.3). Mini-specifikacije kreira korisnik CASE alata. Budući 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 raspoloživosti filma Provjera da li u videoteci postoji kopija filma koja se može iznajmiti Upit (Film) Rezervacije Posuđivanje

Izlazni tokovi:

Rezultat upita (Raspoloživ | Nije raspoloživ | Ne postoji)

Logika procesa:

izračunaj broj kopija traženog filma u videoteci ako je broj kopija veći od nule tada ako je broj kopija veći od (broj posuđivanja + broj rezervacija) rezultat = „Raspoloživ” inače rezultat = „Nije raspoloživ” inače poruka „Ne postoji”


99

Primjer 2: Definisanje procesa (2). Tabela 5.3. Proces 1: Opis: Ulazni tokovi: Izlazni tokovi: Logika procesa:

Provjera raspoloživosti filma Provjera da li u videoteci postoji kopija filma koja se može iznajmiti Upit (Film) Rezervacije Posuđivanje Film nije raspoloživ, Film je raspoloživ, Ne postoji izračunaj broj kopija traženog filma u videoteci ako je broj kopija veći od nule tada ako je broj kopija veći od (broj posuđivanja + broj rezervacija) rezultat = Film je raspoloživ inače ako član želi rezervisati film tada upiši rezervaciju (izlazni tok Film nije raspoloživ) inače poruka „Ne postoji”

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


100

Tabela 5.4. Proces

Ulaz (od)

Izlaz (prema)

Vanjski entitet

Spremište

Komentar/Algoritam

Izraditi narudžbu

Podaci o dobavljaču, Artikli za naručivanje ... Zahtjev za prijem (osoba)

Ispisana narudžba (dobavljač)

Dobavljač

Struktura tokova ne mora u potpunosti odgovarati strukturi spremišta

... Rješenje zahtjeva (osoba, ... )

... Osoba

Narudžba, Dobavljač, Stavka, Artikl ... Osoba, Tok službe

... Prijem u službu

Provjeri zahtjev prema Pravilniku o zapošljavanju, pa napiši rješenje

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, budući da se podaci najčešće pohranjuju u BP. Prema mnogim autorima modeliranje podataka je najvažnija tehnika oblikovanja informacionog sistema. Podaci su resurs koji se dijeli između većeg broja procesa i zbog toga moraju biti organizirani na način koji je prilagodljiv poslovnim zahtjevima. Strukture podataka i njihova svojstva su trajniji i stabilniji od procesa. Modeliranje podataka se završava brže nego modeliranje procesa i modeli podataka se brže približavaju rezultatu nego modeli procesa. Pored toga, modeli podataka su bitno manji od modela procesa. Modeli podataka postojećeg i budućeg sistema međusobno su sličniji nego modeli procesa postojećeg i budućeg sistema, a i lakše ih je preoblikovati, pa se manje posla “baca”. Omogućavaju dobru komunikaciju sa korisnicima i lakše utvrđivanje naziva.

6.1.2. Dijagram entiteti-veze Dijagram entiteti-veze (Entity-Relationship Diagram (ERD)) se naziva još i dijagram objekti-veze, skraćeno DOV, (slika 6.1). Postoje različite notacije ovih dijagrama, npr. Chen, Martin. Osim osnovnih modela, koriste se i prošireni modeli, koji su i obrađeni u ovoj knjizi. Ne postoje jednoznačni standardi postupka njihove izrade.

Slika 6.1. Ilustracija dijagrama entiteti-veze.


102

6.1.3. Entiteti Entitet (entity) je nešto što postoji u stvarnom svijetu i posjeduje osobine koje ga opisuju i po kojima se razlikuje od svoje okoline. Definicije entiteta istaknutih autora su: (1) stvar koja se može zasebno identifikovati [Chen, 1976], (2) bilo koji objekat koji se može razlikovati i predstaviti u bazi podataka [Date, 1986], (3) logička reprezentacija podatka [Finkelstein, 1989], (4) bilo šta o čemu pohranjujemo informaciju [Martin, 1989]. Entitet može biti: • • • • • •

osoba, npr. Ivo Ban, objekat, npr. roman Zločin i kazna, apstraktni pojam, npr. engleski jezik ili iskustvo (poznavanje jezika), ustanova (ETF), poslovni sistem (Hotel Proljeće ili Elektroprivreda), događaj (situacija, stanje) - prošli, sadašnji ili budući, npr. rođenje, školovanje, zaposlenje, penzionisanje, • povezanost različitih objekata stvarnog svijeta, npr. srodstvo.

Pojedinačne pojave (instance), u zavisnosti o metodi, se grupišu u: skup entiteta (entity set), tip entiteta (entity type) i klasu entiteta (entity class). U praksi se može poistovjetiti pojam entitet sa skupom entiteta, ako se ne razmatraju konkretni podaci. Označava se imenicom (u jednini), npr. Osoba, Fakultet. Entiteti mogu poprimiti različite uloge u zavisnosti od konteksta, npr. Osoba je Kupac i/ili Dobavljač, Student ili Nastavnik.

6.1.4. Atributi i domeni Atribut predstavlja neko obilježje, odnosno značenje entiteta. Sinonimi za atribut su: svojstvo (property), polje (field). Pojedinačne vrijednosti atributa se pohranjuju u bazu podataka kao elementarni podaci. Po vrijednostima koje predstavljaju, atributi mogu biti: jednostavni atributi, kod kojih je vrijednost pojedinačni podatak: npr. Prezime, Ime, složeni (sastavljeni) atributi, gdje je vrijednost uređena torka ili logička grupa jednostavnih atributa: npr. datum = (dan, mjesec, godina), višeznačni atributi, odnosno atributi koji predstavljaju ponavljajuće grupe podataka, tj. atributi sa više istovrsnih vrijednosti: npr. Osoba.Telefon = (TelefonNaPoslu, TelefonKodKuce, MobilniTelefon).


103

Obzirom na uskladištenu vrijednosti, atributi mogu biti atributi za uskladištenje i izvedeni atributi, gdje im se vrijednost može odrediti na osnovu vrijednosti drugih atributa: starost = (DanašnjiDatum−DatumRođenja). Vrijednosti atributa definišu tip podatka (domen) i pretpostavljena ili standardna vrijednost (default). Tipovi podataka mogu biti netehnički (logički) ili tehnički. Netehnički tipovi podataka su opšti tipovi koji se koriste u sistem analizi i pri prikupljanju zahtjeva (npr. broj, datum-vrijeme, znakovni niz, tekst, BLOB (Binary Large OBject)), dok su tehnički tipovi podataka generički 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. Uopšteno rečeno, većina atributa treba da ima standardnu vrijednost. Domeni su skup mogućih vrijednosti koje, nad njima definisani atributi, mogu poprimiti. Domeni mogu biti jednostavni i složeni, isto kao i atributi. Nad svakim domenom se može definisati po volji mnogo atributa. Skup vrijednosti (domen) se može 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 ...

Identifikator Osobe (IdOsobe)

8746 37528 1164 765

Ford Karson Rock ...

Prezime (Prezime)

Karson Ford Rock Ford

Melrose place xx Sunset boulevard 2958 Vancouver avenue 63 …

Alan Bob Kit ···

Ime (Ime)

Kit Alan Bob Kit

Adresa (Adresa)

Melrose place 666 Vancouver avenue 63 Sunset boulevard 2958

Slika 6.2. Ilustracija atributa i domena.

Šifra mjesta (SifMjesta)

... ... ... ...

038 001 282


104

6.1.5. Ključevi Ključ (key) ili identifikator (Id, @) je atribut ili skup atributa koji (svojim vrijednostima) jednoznačno 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 može se sastojati od više atributa (složeni, sastavljeni, ulančani ključ): npr. MJESTO = @ŠifraDržave +@ŠifraMjesta. Ključ mora zadovoljavati uslove jednoznačnosti i minimalnosti. Jednoznačnost se definiše na slijedeći način: u skupu entiteta ne smiju postojati dvije pojave sa istim vrijednostima svih ključnih atributa (npr. ne smiju postojati 2 osobe sa JMBG=2209964100028), dok minimalnost znači da ne postoji podskup atributa ključa koji je, takođe, jednoznačan (npr. loš primjer: OSOBA = @JMBG + @Prezime + ... , dobar primjer: KURS = @OznakaValute + @DatumKursa + ... ). Osim navedenih uslova, ključ mora zadovoljiti i slijedeće uslove: određenost (postojanje vrijednosti u trenutku stvaranja instance), stabilnost (otpornost na promjene tokom vremena), raspoloživost (dostupnost svim korisnicima), neutralnost (obzirom na značenje vrijednosti ključa). Identifikator Osobe (IdOsobe)

8746 37528 1164 765

Prezime (Prezime)

Karson Ford Rock Ford

Ime (Ime)

Kit Alan Bob Kit

Šifra mjesta (SifMjesta) 038

001 282

Adresa (Adresa)

Šifra mjesta (SifMjesta)

Melrose place 666 Vancouver avenue 63 Sunset boulevard 2958

Poštanski broj (PostBr)

10000 20000 30000

... ... ... ...

038 001 282

Naziv mjesta (NazMjesta)

Roma New York Los Angeles

Slika 6.3. Povezivanje entiteta ili skupova entiteta stranim ključem. Entitet može imati jedan ili više ključeva. Entitet mora imati barem jedan ključ. Entitet može imati više mogućih ključeva, tj. kandidata za primarni ključ, koji ne moraju


105

biti međusobno disjunktivni, tj. mogu imati atribute presjeka. Jedan od ključeva se odabira za primarni ključ (primary key): npr. Osoba.IdOsobe, Mjesto.SifMjesta. Nakon odabira primarnog ključa, ostali mogući ključevi postaju alternativni ključevi (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 ključa drugog entiteta (Osoba.SifMjesta odnosi se na Mjesto.SifMjesta). Strani ključ ukazuje na povezanost između entiteta, odnosno skupova entiteta (slika 6.3.). Može poprimiti vrijednost primarnog ključa 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 označava nepoznatu vrijednost atributa ili neodređenu vrijednost atributa, tj. nadomješta vrijednost atributa koji se ne koristi. Nula-vrijednost nije 0 (nula) niti “” (prazan znakovni niz). Primjer: Moguće nula-vrijednosti: • •

Osoba (IdOsobe=37528) boravi u nepoznatom mjestu, pa joj je SifMjesta neodređena (nepoznata) vrijednost; Vozilo (tipa putnički automobil) nepoznatog registarskog broja, nasuptot vozila (tipa buldožer) koje se ne registruje na isti način (neprimjenljiva vrijednost).

6.1.6. Veze Veza (relationship) pokazuje odnos između entiteta. Analogno entitetima, pojedinačna veza uspostavlja se na nivou instanci entiteta, a veze se grupišu u skupove veza (relationship sets). Kada se ne razmatraju instance, pojam veza podrazumijeva skup veza. Veza može izražavati 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

Osoba

Stanuje Stanovnik

MjestoStan

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

Mjesto

1,1

Stanuje

0,N

Osoba


107

Primjer: Binarna veza M:N. OrgJed

0,M

0,N

Proizvodi

Proizvod

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.

NadJed

0,1 Pripada

OrgJed PodJed

Cjelina

0,M Sastav

Proizvod Dio

0,N

0,N

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 slučajeve u nekom skupu entiteta, to jest odnos nekog entiteta (nadtip) i njegovih posebnosti (podtip). Podređeni entiteti stvaraju se na osnovu njima nadređenog entiteta sa kojim dijele zajedničke atribute:


108

• nadtip (supertype) - sadrži zajedničke atribute i predstavlja generalizaciju podređenih entiteta, • podtip (subtype) - sadrži samo njemu svojstvene atribute i predstavlja specijalizaciju nadređenog 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 može biti neekskluzivna (npr. Osoba je Radnik ili Saradnik, ali u isto vrijeme može biti i Radnik i Saradnik) ili ekskluzivna (Proizvod je Igla ili Avion, ali ne može 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/podređen entitet. Egzistencijalno slabi entitet je entitet koji ne postoji samostalno, entitet sa stranim ključem (npr. Osoba). Identifikaciono slabi entitet je entitet koji se ne identifikuje samostalno, entitet koji nema vlastiti ključ nego se njegov ključ sastoji od ključa 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. 1,1

Mjesto

0,1

Stanuje

Osoba

Primjer: Identifikaciona veza i identifikacioni slab entitet. 1,1

Racun

1,N

RacStRac

StavkaRacuna

Slika 6.8. Primjeri slabih entiteta.

6.1.9. ERD notacije Najviše je u upotrebi Chen-ova i Martin-ova notacija dijagrama entitet–veze (ERD), slike 6.9 i 6.10. 1. Chen-ova notacija: Mjesto

0,1

Zanimanje

Pripada

NadJed 1,1

Stanuj

1,N 0,N

Osoba

1,N

Zaposlen

0,N

PodJed 1,N

OrgJed

Proizvodi

0,M

1,1 0,N 1,1

0,N Cjelina

Račun

1,1

NS

RačStRač

0,1

Radnik

0,N

1,N

Saradnik

StavkaRačuna

1,1

OdnosiSeNa

0,1 0,N

Sastav

Proizvod

1,1

Igla

ES

0,M

Dio 0,N 0,1

Avion

Slika 6.9. Primjer dijagrama entitet–veze jednog preduzeća (prema Chen-u).


110 2. Martin-ova notacija.

Zanimanje

Mjesto

Pripada Stanuje

Osoba

Zaposlen

OrgJed Sastav

Proizvod Račun

Radnik

Saradnik

Stavka računa

Igla

Avion

Slika 6.10. Primjer dijagrama entitet–veze jednog preduzeća (prema Martin-u).

6.1.10. Izrada ERD analizom izjava korisnika Dijagrama entitet–veze (ERD) može biti izrađen na osnovu izjava korisnika. Tekst izjave korisnika za izradu dijagrama entiteti–veze za hemijsku laboratoriju može da glasi: "Hemičar ili član osoblja hemijske laboratorije može podnijeti zahtjev za jednom ili više hemikalija. Zahtjev može biti udovoljen ili dostavom pakovanja hemikalije koja se već nalazila na zalihi hemijske laboratorije ili upućivanjem narudžbe za novim pakovanjem hemikalije od vanjskog dobavljača. Osoba koja upućuje zahtjev mora imati mogućnost pretraživanja kataloga hemikalija vanjskog dobavljača dok sastavlja narudžbu. Sistem mora pratiti status svakog zahtjeva za hemikalijama od trenutka kad je ispunjen do trenutka kad je udovoljen ili otkazan. Takođe, mora pratiti istorijat svakog pakovanja hemikalija od trenutka kad stigne u kompaniju do trenutka kad je potpuno upotrijebljen ili odbačen".


Inventar hemijske laboratorije

Zahtjev za hemikalijom 1

1 ispunjava

pohranjuje

111 M

zahtjeva

1

M

popisuje

Zahtjevač

M M

M M

Pakovanje hemikalija

sadrži

1

Hemikalija

M

opisuje M

1 prati

1

Istorija pakovanja hemikalija

Dobavljačev katalog

Slika 6.11. Primjer dijagrama entiteti–veze za hemijsku laboratoriju [Fertalj & Kalpić, 2005].

6.2. Razvoj modela podataka 6.2.1. Uvod u razvoj modela podataka Može da se razvija jedan od slijedećih modela podataka: globalni model podataka (enterprise data model), model konteksta podataka (context data model), model podataka sa definisanim ključevima (key-based data model), model podataka sa

112


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

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


113

Slika 6.12. Ekranska forma, sa izvodom iz jednog dijagrama ERD, CASE alata Entity Relationship Diagramer (Designer 2000, ORACLE). Notacija za prikaz ERD-a u Entity Relationship Diagramer-u se razlikuje od prethodno navedene notacije. Najbitnija razlika je u tome da se tipovi veze ovdje ne prikazuju simbolima za romb i linijama, već samo pomoću jedne linije koja povezuje dva tipa entiteta. Ta linija može biti puna, isprekidana ili djelimično isprekidana i na sebi imati dodatne oznake u zavisnosti od parametara tipa veze. Pored opštih pravila za tumačenje prikazanog ERD-a, koja se mogu naći u literaturi o BP, potrebno je naglasiti da simbol: • • •

"#" uz atribut (obilježje) označava da je riječ o atributu koje je u sastavu primarnog ključa tipa entiteta, "*" uz atribut označava da je riječ o atributu koji je obavezan za unos, odnosno korespondira ograničenju Null(N, A) = ⊥, "o" uz atribut označava da je riječ o atributu koji nije obavezan za unos, odnosno korespondira ograničenju Null(N, A) = T,


114 •

•

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

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


115

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

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

116


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

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


117

Atributi mogu imati slijedeće kardinalnosti preslikavanja: kardinalnost 0 - opciona vrijednost (null), kardinalnost 1 - zahtijevana vrijednost (not null) i kardinalnost N višeznačni 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 složeni 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. Višeznačni atribut je skup odgovarajućih 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 VrstaTelefona BrojTelefona

Slika 6.15. Primjeri višeznačnih atributa.

Telefon

118


Ključevi mogu biti primarni, npr. Osoba.IdOsobe, Mjesto.SifMjesta ili alternativni (AK), koga sačinjava 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 NazMjesta

Slika 6.16. Primjeri primarnog i alternativnog ključa . Veza može biti binarna veza 1:N sa stranim ključem. Na slici 6.17 su prikazane binarne veze egzistencijalno slabog entiteta sa običnim stranim ključem i to: Stanuje (Osoba.SifMjesta) , Pripada (OrgJed.SifNadJed) i RacunOsoba (Racun.IdOsobe) .

Mjesto SifMjesta PostBr NazMjesta

Osoba IdOsobe Prezime Ime SifMjesta Adresa DatRodj Staz

OrgJed SifOrgJed NazOrgJed SifNadJed

Osoba IdOsobe Prezime Ime SifMjesta Adresa DatRodj Staz

Slika 6.17. Primjeri stranog ključa .

Racun BrRac DatRac IdOsobe IznosRac


119

Identifikaciono slabi entitet naslijeđuje ključ jakog entiteta. Taj ključ može 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 IznosRac

StavkaRacuna BrRacuna SifProizvoda JedCijena Kolicina

Proizvod SifProizvoda NazProizvoda JedCijena TipProizvoda

StavkaRacuna BrRacuna RbrStRac SifProizvoda JedCijena Kolicina

Slika 6.18. Primjeri složenog ključa. Binarna veza 1,1:0,1 sa stranim ključem transformiše se u identifikaciono slabi entitet bez deskriptora: npr. Osoba (IdOsobe, Prezime, … , Staz), SlikaOsobe (IdOsobe, Slika). Po potrebi se može razmotriti udruživanje 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).

OrgJed

0,M

0,N

Proizvodi

Proizvod

Zanimanje 1,N Osoba

1,N

Zaposlen

DatPoc

1,N

OrgJed

0,M Sastav

Osoba IdOsobe Prezime SifMjesta Adresa DatRodj Staz

Sastav SifProizvod SifDjela BrDjelova

DatZav

Cjelina

Proizvod

Zanimanje SifZan NazZan

BrDjelova

Zaposlen IdOsobe SifOrgJed SifZanim DatPoc DatZav KoefPlate

OrgJed SifOrgJed NazOrgJed SifNadJed

Proizvod SifProizvoda NazProizvoda JedCjena TipProizvoda

Proizvodi SifOrgJed SifProizvod

Dio

Slika 6.19. Primjer ključeva asocijativnog entiteta.


120

Nespecifične veze se sastoje od asocijativnog entiteta + n binarnih veza 1:N. Ključ asocijativnog entiteta je unija ključeva entiteta spojenih vezom (slika 6.19). Primjer: Proizvodi, Zaposlen, Sastav. Specijalizacija nadtipa u n podtipova (n binarnih veza) u kojoj je nadtip (jaki) entitet, kome se po potrebi određuje 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

Igla

ES

0,1

Avion

Igla SifProizvoda Duzina Promjer

Avion SifProizvoda BrSjedista DoletKM

Slika 6.20. Primjer specijalizacije nadtipa u n podtipova.

6.3.2. Implementaciono projektovanje sheme BP pomoću CASE alata Implementaciono projektovanje sheme baze podataka započinje prevođenjem ERD konceptualne sheme BP u relacioni model. Nakon postupka prevođenja konceptualne sheme BP, sa slike 6.13, u relacioni model podataka i izvršene normalizacije, dobija se implementaciona shema BP, slika 6.21. Svaki pravougaonik na shemi predstavlja jednu relaciju (tabelu) BP, dok linije predstavljaju puteve prostiranja primarnog ključa, odnosno ograničenja stranog ključa. Za ovo prevođenje se može koristiti odgovarajući CASE alat, npr. Database Design Transformer (Designer 2000, ORACLE). Ovaj alat na osnovu konceptualne sheme BP, opisane u rječniku podataka, generiše prvu verziju relacione sheme BP, čiji opis će se, takođe, nalaziti u rječniku. Tako integrisana relaciona shema se dorađuje odgovarajućim editorom, npr. Design Editor (Designer 2000, ORACLE). Izgled korisničkog 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 generiše ORACLE/SQL (ili ANSI/SQL) opis sheme BP, koji treba implementirati na odgovarajućem serveru BP. Implementaciona shema služi, takođe, kao osnova za modeliranje programske specifikacije modula i samo generisanje programskih modula, šta je detaljnije opisano u tački 10.7. Programska specifikacija modula za interaktivni rad sa bazom podataka, kreiranje izvještaja, grafikonski prikaz podataka ili bibliotečkog modula, se mogu oblikovati odgovarajućim CASE alatom, npr. Design Editor/Modules (Designer 2000, ORACLE), slika 6.23. Pomoću istog alata se formira struktura ekranskih formi aplikacije i obezbjeđuje međusobno povezivanje programskih modula, sa mogućnošću prenosa podataka između 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 događaja 7.1. Modeliranje procesa vođeno događajima Događaj je zgoda ili zbivanje u sistemu koja vodi ili pokreće procese sistema. Sâm događaj nije proces, nego okidač procesa koji se njime pokreće. Primjer: Kupac dostavom narudžbe pokreće proces provjere da li se radi o narudžbi postojećeg ili novog kupca, proces stvaranja podataka o narudžbi i stavkama narudžbe, provjeru prethodnih zaduženja kupca, provjeru stanja skladišta, itd. Događaj može biti vanjski, vremenski i unutrašnji. Vanjski događaji se pokreću od strane vanjskih entiteta, koji zahtijevaju informaciju ili ažuriranje podataka (ulazni tokovi podataka). Imenuje se tako da naziv sadrži naziv vanjskog entiteta, npr. zahtjev za upis studenta ili zaprimanje narudžbe kupca. Vremenski događaji su vremenski uslovljeni, npr. rok, učestalost (ulazni upravljački tokovi). Imenuju se tako da naziv sadrži vremensku oznaku, npr. istek roka plaćanja računa, mjesečni obračun plata, zaključivanje ispitnog roka i slično. Unutrašnji događaji su događaji stanja, odnosno posljedica prelaza sistema iz jednog stanja u drugo na takav način da to zahtjeva obradu (ulazni upravljački tokovi), npr. isporuka robe sa skladišta zahtijeva naručivanje nove robe. Raspodjela događaja vezanih za projektovanje IS: 1. Izrada dijagrama konteksta sistema, postavljanje početnog dometa projekta; 2. Izrada dijagrama funkcionalne dekompozicije, podjela sistema u logičke podsisteme i/ili funkcije; 3. Izrada popisa događaja i odziva, utvrđivanje poslovnih događaja na koje sistem mora odgovoriti. Elementi popisa su događaj, ulaz i izlaz; 4. Izrada dijagrama dekompozicije događaja, dodavanje procesa za rukovanje događajima. Dodaje se po jedan proces za svaki utvrđeni događaj; 5. Izrada dijagrama događaja, odnosno razrada procesa za obradu događaja. Izrađuje se po jedan dijagram za svaki događaj; 6. Izrada dijagrama sistema, odnosno udruživanjem dijagrama događaja; 7. Izrada primitivnih dijagrama. Razrada dijagramom toka podataka koji sadrži osnovne procese, spremišta i tokove za svaki pojedini događaj. Opšti prikaz dijagrama sistema izrađen modeliranjem procesa vođenim događajima prikazan je na slici 7.1.


124

Sistem

Sistem Funkcija 1

Događaj 1

Događaj 1

Događaj 2

Funkcija n

Funkcija 2

Događaj 3

Događaj 4

Događaj 5

Događaj n-2

Događaj 5

Događaj n-1

Događaj n

Događaj n

Slika 7.1. Primjer modeliranja procesa vođeno događajima.

7.2. Matrica entiteti/događaji (Entity/Event Matrix) Matrica entiteti/događaji omogućava pogled na sistem usmjeren događajima. Matrica sadrži događaje (redovi) i entitete (stupci). Elementi koji prikazuju učinak događaja na entitete su: • • • •

stvaranje – C (reate), čitanje - R (read) (u nekim metodama se ne bilježi), ažuriranje - U (update) ili M (odify), brisanje - D (elete).

Završetak je kada se ostvari da svaki događaj ima učinak na barem jedan entitet, a svaki entitet mora imati događaj koji ga stvara i briše.


125

Pojednostavnjeni primjer matrice događaj/entitet za rezervaciju sobe u hotelu Proljeće, prikazan je na slici 7.2.

Slika 7.2. Primjer matrice događaj/entitet.

7.2.1. Generisanje matrica CASE alatima Generisanje matrica CASE alatima biće ilustrovano kreiranjem matrica Funkcije/Tipovi entiteta i Funkcije/ Atributi pomoću Matrix Diagrammer-a iz sastava Designer-a 2000, ORACLE. 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. Načini upotrebe tipa entiteta u zavisnosti od funkcije, kod matrice Funkcije/Tipovi entiteta, mogu biti: • • • • • •

Create (C), sa značenjem da je zadatak funkcije formiranje nove pojave posmatranog tipa entiteta, Retrieve (R), sa značenjem da je zadatak funkcije preuzimanje podataka o postojećim pojavama tipa entiteta, Update (U), sa značenjem da je zadatak funkcije modifikacija podataka o postojećim pojavama tipa entiteta, Delete (D), sa značenjem da je zadatak funkcije brisanje pojave tipa entiteta, Archive (A), sa značenjem da je zadatak funkcije da posebnim postupcima arhivira pojave tipa entiteta, i Other (O), sa značenjem da funkcija ima zadatke koji prethodnim načinima 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. Načini upotrebe atributa tipova entiteta u zavisnosti od funkcije, kod matrice Funkcije /Atributi, mogu biti: • •

Insert (I), sa značenjem da je zadatak funkcije da prvi put zadaje vrijednost atributa tipa entiteta, Retrieve (R), sa značenjem da je zadatak funkcije preuzimanje postojeće vrijednost atributa tipa entiteta,


128 • • • •

Update (U),sa značenjem da je zadatak funkcije modifikovanje prethodno zadane vrijednosti atributa tipa entiteta, Nullify (N), sa značenjem da je zadatak funkcije omogućavanje zadavanja nula vrijednosti za atribut tipa entiteta, koji prethodno nije imao nula vrijednost, Archive (A), sa značenjem da je zadatak funkcije da posebnim postupcima arhivira vrijednosti atributa tipa entiteta, i Other (O), sa značenjem da funkcija ima, u odnosu na vrijednosti atributa tipa entiteta, zadatke koji prethodnim načinima upotrebe nisu pokriveni.

7.3. Model istorije života entiteta (Entity Life History) Istorijat života entiteta je pogled na sistem usmjeren učincima događaja koji uzrokuju promjene stanja. Opisuje vremenski zavisno ponašanje (jednog) entiteta, odnosno prati promjene ponašanja entiteta koji prolazi kroz sistem. Dijagram podudarnosti učinka (Effect Correspondence Diagram – ECD), za opšti slučaj je prikazan na slici 7.7, a za rezervaciju sobe u hotelu Proljeće na slici 7.8. entitet, blok

Ο

redoslijedni redoslijedni događaj događaj (sekvenca) (sekvenca)

alternativni događaj (selekcija)

m

operacije

ponovljeni događaj (iteracija) n

∗

o

Slika 7.7. Dijagram podudarnosti učinka za opšti slučaj.


129

rezervacija sobe

rezervacija, nenajavljen dolazak

najavljeni dolazak

opoziv rezervacije ili nedolazak

potvrda rezervacije 3

2

stvaranje troška

plaćanje usluga

3

7 3 5

Ο

privremena rezervacija 1

Ο

dolazak gosta

1

2

Ο

arhiviranje rezervacije

6

∗

opoziv rezervacije

nedolazak gosta

povećanje troška

3

3

4

1. Kreirati rezervaciju 2. Zauzeti sobu 3. Ažurirati status rezervacije 4. Kreirati zaduženje 5. Poništiti zaduženje 6. Osloboditi sobu 7. Obrisati podatke o rezervaciji

Slika 7.8. Dijagram podudarnosti učinka za rezervaciju sobe u hotelu Proljeće.

7.4. Dijagram prelaza stanja (State Transition Diagram (STD)) Dijagram prelaza stanja se zasniva na ideji mašine sa konačnim brojem stanja, hipotetičkom mehanizmu koji u nekom trenutku može biti u jednom od konačno mnogo diskretnih stanja. Predstavljaju grafički prikaz promjena stanja, tj vremenski zavisnog ponašanja sistema. Elementi prikaza su: stanje, kumulativni rezultat ponašanja nekog objekta (pravougaonik, krug ili elipsa), prelaz, promjena stanja uzrokovana nekim događajem (usmjerena linija od jednog stanja prema drugom) i događaj, uslov promjene stanja i akcija koja se obavlja (opis linije prelaza oblika događaj/akcija). Dijagram prelaza stanja najčešće opisuje vremenski zavisno ponašanje čitavog sistema. Manji sistemi se mogu prikazati jednim dijagramom, dok veći sistemi se razlažu slično dijagramima toka podataka, pri čemu stanje na nekom nivou postaje početno stanje dijagrama na nižom nivou. Primjenjuju se kod razvoja sistema za rad u stvarnom vremenu (real-time system), jezičke analize (parsing) i dizajna korisničkog interfejsa. Dijagrami prelaza stanja sistema za rad u stvarnom vremenu se razlikuju po tome što sadrže posebno stanje


130

"besposlen". Na slici 7.9 je prikazan Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro, na kome su naglašena stanja „čekanje”.

prazni hod (idle)

ispravna kartica/ „Izaberite“

kartica izvađena/ “Umetnite“ neispravna kartica/ „Neispravna“

čekanje na vađenje kartice izabran „Kraj“/ „Hvala, doviđenja“

čekanje na izbor obavljen odabir/ „Pokupite“

izvađeno/ „Još nešto?“

natočeno (izbrojano) Slika 7.9. Dijagram prelaza stanja Sokomata hotela Proljeće ili Bankomata banke Montenegro.

7.5. Mape dijaloga Korisnički interfejs u mnogim aplikacijama se može promatrati kao konačni automat. Jedan element interfejsa (odabirač, radna površina, komandna linija ili dijalog prozor) može biti aktivan u određenom trenutku. Korisnik može doći do ograničenog broja drugih elemenata u zavisnosti o akcijama koje preduzima. Broj putanji kojima korisnik može mijenjati dijaloge je obično vrlo velik, ali je konačan, i mogućnosti su, najčešće, poznate. Mape dijaloga prikazuju sistem na visokom nivou apstrakcije. Prikazuju elemente dijaloga u sistemu i mogućnost navigacije između njih, ali ništa ne govore o dizajnu ekranske forme. Korisnici i razvojni tim mogu zajednički razmatrati dijalog mape kako bi postigli zajednički stav o tome kakva treba biti korisnikova interakcija sa sistemom kako bi se izvršio određeni zadatak.


131

Dijalog mape su, takođe, korisne kod modeliranja vizuelne arhitekture web sjedišta, pa se ponekad tako i nazivaju (eng. site maps). Navigacioni linkovi u sjedištu pojavljuju se kao tranzicije na dijalog mapi. Koristi se notacija dijagrama prijelaza stanja. Uslov koji pokreće korisničku navigaciju prikazan je kao tekst na strelicama. Postoji nekoliko vrsta pokretačkih uslova: korisnička akcija, kao što je pritisak tastera ili klik na link ili dugme dijalog prozora, vrijednost podataka, kao što je pogrešan unos koji pokreće pojavljivanje poruke o grešci, 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 opšte 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 uobičajenog puta, npr. uobičajeni put bi bio naručiti hemikaliju od vanjskog dobavljača, a alternativno se hemikalija može dobiti iz zaliha hemijske laboratorije. Prilikom analize zahtjeva, dijalog mapa predstavlja interakciju korisnika i sistema na konceptualnom nivou. Konkretna ugradnja može biti drugačija. Primjer: Korisnik inicira model korištenja odabirom opcije "zatraži hemikaliju" iz glavnog odabirača. Polazna tačka za ovaj model korištenja je popis traženih hemikalija koji se naziva "Trenutna lista zahtjeva".

132


8. Inženjerski pristup izgradnji IS 8.1. Uvod Razlog za uvođenje posebne discipline u računarstvu sa nazivom softversko inženjerstvo je prvi uzrok pojave softverska krize, odnosno projektovanje IS bez primjene odgovarajuće metodologije. Pojam softverskog inženjerstva se javlja početkom 70-ih godina, prije pojave pojma CASE proizvoda. Ideja softverskog inženjerstva je bila uvođenje metodološkog, inženjerskog pristupa pri razvoju programskih proizvoda sa ciljem da se u zadanim vremenskim rokovima, preciznom primjenom odgovarajućih tehnika, dođe 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 znači da i razvoj programskog proizvoda treba da prati faznu logiku životnog ciklusa. Faze životnog ciklusa programskog proizvoda su: strategija (strateško planiranje razvoja programskog proizvoda), snimanje i analiza (detaljna analiza ponašanja realnog sistema, korisničkih zahtjeva i konceptualno projektovanje programskog proizvoda), projektovanje (oblikovanje izvođačkog – implementacionog projekta programskog proizvoda), programiranje (realizacija programskog proizvoda), uvođenje u upotrebu i eksploatacija sa održavanjem. Bitno je da sve nabrojane faze prati aktivnost izrade odgovarajuće projektne, odnosno izvođačke dokumentacije, dok se u fazi programiranja izrađuju 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 opštu tehniku koja se zasniva na slijedećim principima: postepeno dekomponovanje složenog sistema na podsisteme manje složenosti, nezavisnu izgradnju podsistema, integraciju nezavisno izgrađenih komponenti u jedinstvenu cjelinu (programski proizvod, informacioni sistem) i odvajanje pojma projekta programskog proizvoda od pojma njegove realizacije.


133

8.2. Programsko inženjerstvo (Software Engineering) Programski proizvodi (software) se sastoji od: programske podrške, dijela računarskog sistema koji nema fizičkih dimenzija, svih vrsta programa i programskih jezika, preporuka, itd. Računarski programi, podaci i dokumentacija imaju slijedeća svojstva: složenost, podložnost greškama, ne troše se, teško se mjere, stare, dugo se koriste i lako se kopiraju (zajedno sa greškama). Računarska aplikacija je namjenski program, primjenjeni programski proizvod (oprema), odnosno računarom podržano rješenje jednog ili više poslovnih problema ili potreba. Informacioni sistem uobičajeno sadrži jednu ili više računarskih aplikacija. Informaciona tehnologija (IT) je bilo koji oblik tehnologije, tj. oprema ili tehnika, koju ljudi koriste za upravljanje informacijama (obavještenjima). U današnje vrijeme obuhvata računarsku tehnologiju (hardver i softver) i telekomunikacionu tehnologiju (mreže za prenos podataka, slika i zvuka). Programsko inženjerstvo (softverski inženjering) ima više definicija. Biće navedene neke od njih: 1. Programsko inženjerstvo je inženjerska disciplina koja obuhvata sve aspekte izrade programske opreme [Sommerville, 2000]; 2. Programsko inženjerstvo je inženjerska disciplina koja se bavi praktičnim problemima razvoja velikih programskih sistema [Sommerville, 1992]; 3. „Programsko inženjerstvo ... ima za cilj ekonomičan razvoj visoko- kvalitetne programske opreme“ [Pagel & Six, 1994]. Područje programskog inženjerstva 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 bližeg opisivanja (specifikacije) postupaka koje treba programirati, izrade programa, tehnika testiranja (provjere valjanosti), pisanja dokumentacije, probnih izvedbi programa, analize vremenskog izvođenja, itd. Razvoj postupaka (metoda) programskog inženjerstva se može hronološki prikazati: • godina 1968: Prva NATO konferencija o programskom inženjerstvu, posvećena problemima razvoja programske podrške (“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, računarom podržana dokumentacija,

134


• kasne ’70-te, rane '80-te: strukturirana analiza - odvajanje logičkog opisa od fizičkog opisa (informacionog) sistema, oblikovanje podataka, • rane '80-te: CASE alati; izrada prototipova, • sredinom '80-ih: informaciono inženjerstvo, združeni 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 informatičkih tehnologija, ... . Računarsku osnovu (Computing Fundamentals) softverskog inženjeringa sačinjavaju: algoritmi i strukture podataka (Algorithms and Data Structures), arhitektura računara (Computer Architecture), matematička podrška (Mathematical Foundations), operativni sistemi (Operating Systems) i programski jezici (Programming Languages). Proizvodi softverskog inženjeringa (Software Product Engineering) su: zahtjevi softverskog inženjeringa (Software Requirements Engineering), softverski dizajn (Software Design), kodiranje softvera (Software Coding), testiranje softvera (Software Testing), rad softvera i održavanje (Software Operation and Maintenance). Upravljanje softverom (Software Management) u slijedećim segmentima: softversko upravljanje projektom (Software Project Management), softversko upravljanje odlučivanjem (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 inženjerstvo (Information Engineering) Informaciono inženjerstvo se bavi inženjerskim 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 podržanom računarom. U procesu razvoja IS mora biti zastupljena sistemska primjena prikladnog skupa metoda, tehnika i alata. Metoda je smišljen i organizovan skup procedura izrade (modela, softvera), uz korištenje dobro definisane notacije. Sugeriše proces obavljanja i način dokumentovanja, a, takođe, definiše primjenu tehnika i njihovo povezivanje (npr. ERD, IDEF, DFD). Tehnika je način provođenja metode. Definiše način provođenja određenog postupka i dokumentovanja rezultata tog postupka, odnosno način na koji se provodi određena aktivnost razvojnog procesa.


135

Softverski alati (tool) je instrument, sredstvo koje se koristi u razvoju IS. Informacionu tehnologiju (Information Technology) sačinjavaju: arhitektura kompjutera (Computer Architectures), algoritmi i strukture podataka (Algorithms and Data Structures), programski jezici (Programming Languages)), operativni sistemi (Operating Systems), telekomunikacije (Telecommunications), baze podataka (Database) i vještačka inteligencija (Artificial Intelligence). Organizacioni i upravljački koncepti (Organizational and Management Concepts) informacione tehnologije su: opšta teorija organizacije (General Organization Theory), upravljački informacioni sistemi (Information Systems Management), teorija odlučivanja (Decision Theory), organizacioni postupci (Organizational Behavior), upravljanje procesima za promjene (Managing the Process of Change), pravni i etički aspekti IS (Legal and Ethical Aspects of IS), profesionalizam (Professionalism) i interdisciplinarno znanje (Interpersonal Skills). Teoriju i razvoj sistema (Theory and Development of Systems) sačinjavaju: 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 odlučivanjem (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 održavanje (Systems Operation and Maintenance) i razvoj posebnih vrsta informacionih sistema (Systems Development for Specific Types of Information Systems).

8.4. Sistemsko inženjerstvo (System Engineering) Nema opšte prihvaćene definicije sistemskog inženjerstva. Ipak, za sistemsko inženjerstvo se može reći da: 1. Sagledava sistem kao cjelinu pristupom sa vrha prema dolje (top-down); 2. Upravlja ciklusom koji sadrži sve faze od dizajna do odumiranja; 3. Osigurava djelotvornost i (dovoljno) rano donošenje odluka definisanjem zahtjeva i njihovim povezivanjem sa odgovarajućim oblikovanjem; 4. Predstavlja interdisciplinarni i/ili timski pristup oblikovanju i razvoju, kojim se osigurava njihova djelotvornost i funkcionalnost.

136


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


137

U skladu sa navedenim razlozima, od CASE proizvoda se očekuje da obezbjede što viši stepen automatizacije kada se obavljaju slijedeći 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 Rječnik podataka CASE proizvoda. Rječnik sadrži podatke o svim konceptima (objektima, vezama, dijagramima, matricama, dokumentaciji, itd.), definisanim u okviru jednog, ili više projekata, koji se smještaju u rječnik. Svi pojedinačni alati jednog CASE proizvoda koriste i smještaju podatke u isti rječnik podataka, šta je prikazano na slici 8.1. Alat za modeliranje dijagrama toka podataka

Alat za modeliranje ER dijagrama

Alat za modeliranje programskih specifikacija

Rječnik podataka

Alat za modeliranje matrica

Generatori koda

Slika 8.1. Međusobni odnos različitih CASE alata i jedinstvenog rječnika podataka. Mogu se sresti različite klasifikacije CASE proizvoda. Jedna, uobičajena i ne suviše selektivna, je izvršena prema fazama životnog ciklusa koje CASE proizvod pokriva. Prema toj klasifikaciji, razlikuju se:

138


1. Projektantski CASE proizvodi, koji su namjenjeni za podršku prve („gornje“) tri faze životnog ciklusa, odnosno za podršku projektovanju programskog proizvoda (strategija, snimanje i analiza, projektovanje); 2. Programerski CASE proizvodi, namjenjeni za podršku posljednje („donje“) tri faze životnog ciklusa, odnosno za podršku realizacije programskog proizvoda (programiranje, uvođenje u upotrebu, eksploatacija i održavanje); 3. Integrisani CASE proizvodi, tj. integrisani projektantski i programerski CASE proizvodi, namjenjeni da podrže svih šest faza životnog ciklusa, odnosno kompletan život programskog proizvoda.

8.5.1. Projektantski CASE proizvodi (Upper CASE, Front-End CASE) Za podršku prve tri faze životnog ciklusa koriste se projektantski CASE proizvodi. Kod projektovanja IS, CASE proizvod koji podržava fazu strategije, treba da sadrži alate za podršku: planiranja projekta (izbora metodologije i tehnika razvoja IS, načina 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), praćenja realizacije projekta i sprovođenje postupaka kontrole kvaliteta. Da bi podržao faze snimanja i analize, CASE proizvod treba da sadrži 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 međuzavisnosti između elemenata konceptualne sheme BP, kao i funkcionalne, organizacione i prostorne strukture sistema. Kada je u pitanju faza projektovanja, CASE proizvod može da sadrži alate za: prevođenje 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 ažuriranje BP) i implementaciono projektovanje programskih specifikacija aplikacija. Implementaciono projektovanje sheme BP se može sprovoditi neposredno, bez prethodne izrade i prevođenja konceptualne sheme, ili putem modifikacija prevedene konceptualne sheme. Implementaciono projektovanje programskih specifikacija aplikacija se može sprovoditi neposredno, bez prethodnog generisanja programskih specifikacija, ili putem modifikacija prethodno generisanih programskih specifikacija. Pri razvoju savremenih projektantskih CASE proizvoda, sve je naglašeniji zahtjev da CASE sadrži „inteligentne“ alate i alate koji u sebi uključuju elemente ekspertnog znanja. To znači da alati treba da primoravaju projektanta na poštovanje formalnih


139

pravila upotrebe odgovarajuće tehnike, koji dani alat podržava. Na taj način projektant dobija tehničku pomoć u radu. Pored toga, na višem nivou, očekuje se da alat „pruži“ projektantu i ekspertnu, tj. intelektualnu, pomoć u primjeni odgovarajuće tehnike. Takva pomoć se ogleda u mogućnosti da sam alat pruža odgovarajuća projektantska rješenja ili da je u stanju da analizira, vrednuje i ocjenjuje rješenja, koja je napravio projektant softverskog proizvoda.

8.5.2. Programerski CASE proizvodi (Lower CASE, Back-End CASE) U programerske CASE proizvode se najčešće svrstavaju generatori koda. Generatori koda su u mogućnosti da, na osnovu opisa implementacione sheme BP, generišu DDL opis sheme BP za konkretni sistem za upravljanje BP, ili na osnovu programskih specifikacija generišu 4GL programe aplikacija IS. U smislu povećanja nivoa deklarativnosti, preglednosti i lakoće programiranja jezici 4. generacije (4GL) predstavljaju dalju nadogradnju jezika 3. generacije. Teško je dati preciznu definiciju jezika 4. generacije, jer on podrazumjeva široki spektar programerskih ili korisničkih alata, različitih namjena i mogućnosti, od jednostavnih alata do razvijenih jezika. Zbog toga se često govori o pojmu okruženja 4. generacije. Na slici 8.2 su prikazani mogući elementi jednog 4GL okruženja. Treba uočiti da u takvo okruženje ulaze i jezici 3. generacije, što znači 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 izvještaja

Programski jezici 3. generacije

Generatori i editori upita Rječnik podataka

Slika 8.2. Mogući elementi jednog 4GL okruženja.


140

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

Složenost aplikacije

Slika 8.3. Problematika funkcionalnosti generatora koda, 4GL okruženja i jezika 3. generacije [Mogin et al. 2000].


141

Problematika funkcionalnosti generatora koda, 4GL okruženja i jezika 3. generacije ilustrovana je dijagramom na slici 8.3. Uočava se da se manje složene aplikacije mogu neposredno dobiti upotrebom generatora koda. Za složenije aplikacije je, nakon generisanja koda potrebno izvršiti dodatna prilagođavanja, upotrebom alata 4. generacije, dok se vrlo složeni i dominantno proceduralni dijelovi aplikacija mogu uspješno realizovati samo upotrebom jezika 3. generacije. Iz navedenih razloga je prethodno i naglašena potreba kombinovane upotrebe alata 4. generacije i jezika 3. generacije. Upotreba generatora koda ima još jedan nedostatak. Ponovno generisanje aplikacije, nakon već izvršenog prilagođavanja generisanog koda pomoću alata 4. generacije, može značiti „uništavanje“ prethodno izvršenih prilagođavanja. Savremeni trendovi razvoja generatora koda idu ka tome da se ovaj nedostatak ublaži na dva načina. Prvi način predviđa pomjeranje granice upotrebljivosti generatora koda, tako da se pomoću generatora koda mogu izgraditi i složenije aplikacije. Cilj je da se pređe granica od 80% ukupno generisanog koda, koji bi bez daljih dorada bio spreman za upotrebu. Drugi način se zasniva na sistematičnom evidentiranju dorađenih dijelova generisanog koda u okviru rječnika podataka, tako da svako slijedeće regenerisanje uzme u obzir i postojeća prilagođenja koda.

8.5.3. Integrisani CASE proizvodi (Integrated CASE (ICASE)) Integrisani CASE proizvodi pokrivaju sve faze razvoja, a sadrže i dodatne module za povratno (reverzno) inženjerstvo, nadzor i upravljanje izvedbom, te osiguranje kvaliteta IS. Potpuno integrirano CASE okruženje automatizuje izradu modela poslovnog sistema, planiranje razvoja IS, kao i izgradnju i primjenu IS. Integracija programskih proizvoda se ostvaruje usvajanjem pravila određene metode razvoja, upotrebom zajedničkog rječnika podataka i zajedničkog interfejsa, te automatizovanim proslijeđivanjem 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 pomoću CASE proizvoda Za projektovanje shema baza podataka postoje samostalni CASE proizvodi. Takvi proizvodi, uglavnom, pripadaju klasi projektantskih CASE proizvoda. Ukoliko sadrže i generatore opisa sheme BP, prilagođene konkretnim SUBP, tada pripadaju i klasi programerskih CASE proizvoda. Integrisani CASE proizvodi, koji su nomjenjeni za razvoj IS, obavezno sadrže alate za projektovanje konceptualne, implementacione i interne sheme BP.

142


Savremeni CASE proizvodi za projektovanje konceptualne, implementacione i interne sheme najčešće omogućavaju projektovanje konceptualne sheme u modelu entiteti – veze (ER model) i automatsko prevođenje ER konceptualne u implementacionu shemu, zasnovanu na relacionom modelu podataka. Pojedini CASE proizvodi omogućavaju i projektovanje fizičke 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 grafičkog editora za poluautomatsko crtanje ER dijagrama i analizatora konzistentnosti nacrtanih shema. Grafički editor sadrži 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 usaglašenosti nacrtanog ER dijagrama sa pravilima strukturiranja, kao i pronalaženje potencijalnih sinonima i homonima. Mogućnost definisanja funkcionalnih zavisnosti posjeduju samo pojedini CASE proizvodi, najčešće u skupu tipa entiteta ili tipa veze. Nakon definisanja skupa funkcionalnih zavisnosti, CASE proizvod vrši normalizaciju relacija. Ukoliko rezultat normalizacije pokaže da posmatrani tip entiteta ili tip veze treba dekomponovati, CASE proizvod tu izmjenu u ER dijagramu vrši automatski. Međutim, u praksi se često dešava da ovako nacrtan ER dijagram ne predstavlja lako razumljivu osnovu za komunikaciju između projektanta i korisnika. Krajnji korisnik je, prvenstveno, zainteresovan da pomoću računara olakša, ubrza i poveća kvalitet obavljanja svojih radnih zadataka i nije spreman da se udubljuje u analizu kvaliteta konceptualne sheme, koja je predstavljena, za njega, apstraktnom i stranom notacijom. Tek kada dobije gotove programe, ili njihove prototipove, korisnik može da ocjeni da li mu rješenje odgovara. Sa druge strane, programere interesuje podshema u implementacionom modelu podataka. Prema tome, crtanje ER dijagrama se može posmatrati samo kao usputan, i ne baš jednostavan, korak u projektovanju implementacione sheme i, u suštini, predstavlja heuristički postupak. Nema dokaza da „pažljivo“ projektovanje ER dijagrama, nakon prevođenja u relacioni model podataka, uvjek rezultuje u skup relacija, koje su bar u trećem 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 podržava više metodologija projektovanja IS (SSAD, OOAD), reverzno inženjerstvo 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 reinžnjerstvo BP, podržavajući različite notacije projektovanja (IDEF1X, IE, DM). Na slici 8.6 je prikazana ekranska forma alata za projektovanje objektno orijentisanog softvera Rational ROSE, koji podržava OO metode (UML, OMT, Booch, … ).


Slika 8.4. Ekranska forma integrisanog CASE alata (ICASE).

Slika 8.5. Ekranska forma CASE alata za oblikovanje baza podataka.

143

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 podršku slijedećih faza životnog ciklusa: • snimanje i analiza poslovnog sistema, • projektovanje IS, • programiranje korisničkih aplikacija, • uvođenje u upotrebu i eksploatacija IS, • održavanje IS. i predstavlja sveobuhvatni programski proizvod, sa značajnom prisutnošću na tržištu informacione tehnologije u vrijeme pisanja ove knjige. Designer 2000 radi sa jedinstvenim rječnikom podataka (rječnik podataka programskog proizvoda Designer 2000 se na engleskom jeziku zove Repository), implementiranom u okviru ORACLE baze podataka. Projektantsko-programerske aktivnosti u okviru Designer-a 2000 se obavljaju u cjelinama, koje se nazivaju aplikativni sistemi. Aplikativni sistem može predstavljati zaokruženu cjelinu, podsistem ili IS. Ovakvim pristupom projektovanju, IS se istovremeno razvija radom na više aplikativnih sistema. Razvoj IS pomoću više aplikativnih sistema omogućava veću fleksibilnost u radu, prvenstveno u pogledu lakšeg traženja podataka i sprovođenja


145

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


146 •

Process Modeller, koji je namjenjen za dijagramski prikaz procesa i tokova u realnom sistemu i podršku njihovog eventualnog reverznog inženjeringa, • Function Hierarchy Diagramer - alat za modeliranje funkcionalne dekompozicije realnog sistema i strukture programske podrške 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 prevođenje 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 ažuriranje baze podataka, generisanje izvještaja, grafički 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 fizičke organizacije podataka), i • Design Editor / Distribution, za projektovanje distribuirane sheme baze podataka. Kada su u pitanju faze: programiranja, uvođenja u upotrebu i eksploataciju i održavanje informacionog sistema, Designer 2000 je opremljen slijedećim 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 izvještaja, zasnovanih na jeziku IV generacije Developer 2000 / Reports,


•

147

Generate Module / Graphics, za generisanje programskih modula za grafički 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 korisničkom interfejsu. Može se konstatovati da je Designer 2000, u dijelu koji se odnosi na generatore koda, dosta čvrsto povezan i sa ORACLE-ovim okruženjem č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 izvještavanje (koji se nazivaju i "izvještaji") i Graphics Builder, za kreiranje programskih modula za grafički prikaz podataka ("grafikona"). Pored nabrojanih, Designer 2000 posjeduje i slijedeće programe, koji se svrstavaju u oblast reverznog inženjerstva: • Capture Design of Database, namjenjen za reverzni inženjering implementacione ili interne sheme baze podataka, na osnovu stanja rječnika ORACLE baze podataka, kao i utvrđivanje i eliminisanje razlika između stanja rječnika ciljne baze podataka i rječnika Designer-a 2000, • Table To Entity Retrofit, namjenjen za prevođenje implementacione sheme baze podataka u konceptualnu shemu baze podataka, prikazanu putem dijagrama tipova entiteta i veza, • Capture Design of Form, namjenjen za reverzni inženjering interaktivnih programskih modula, kreiranih u okviru alata Developer 2000/Forms, • Capture Design of Report, namjenjen za reverzni inženjering programskih modula za izvještaje, kreiranih u okviru alata Developer 2000/Reports, • Capture Design of Library, namjenjen za reverzni inženjering bibliotečkih modula, kreiranih u okviru paketa Developer 2000, • Capture Design of Visual Basic, namjenjen za reverzni inženjering interaktivnih programskih modula, kreiranih pomoću alata Visual Basic, i • Capture Applicatoin Logic, namjenjen za usaglašavanje implementacione specifikacije Forms modula iz Designer-a 2000 i postojećeg Forms modula iz Developer-a 2000. U skupu alata opšte namjene, Designer 2000 posjeduje slijedeće:


148 •

Repository Object Navigator, namjenjen za direktni pristup objektima u rječniku podataka Designer-a 2000, putem hijerarhijski organizovanog navigatora objekata, • Matrix Diagramer, namjenjen za izgradnju različitih tipova matričnih dijagrama, • Repository Reports, za generisanje velikog broja različitih tipova izvještaja, na osnovu stanja rječnika podataka Designer-a 2000, pri čemu ti izvještaji služe za sprovođenje određenih kontrola i analiza kvaliteta projekta, ili samo kao "papirna" projektna dokumentacija, • Repository Administration Utility, pomoću kojeg se obavljaju administrativni zadaci nad Designer-om 2000, kao što su: instalacija i deinstalacija rječnika podataka, dodjela prava pristupa korisnicima, arhiviranje i dearhiviranje rječnika podataka, obavljanje određenih formalnih kontrola, itd, • Online Help, kao alat za prezentiranje uputstava za korištenje Designer-a 2000, i • SQL Plus, za interaktivno izvršavanje 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, prevođenje dijagrama klasa objekata u implementacionu shemu baze podataka i implementaciono i fizičko projektovanje sheme baze podataka.

8.6. Reverzno inženjerstvo Nastanak pojma i tehnika reverznog inženjerstva je motivisan slijedećom situacijom. U mnogim organizacijama uložena je velika količina 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 kreće iz početka. Nastoji se da se sav uloženi napor, iskustvo, postojeća rješenja i resursi što bolje iskoriste, jer je to daleko ekonomičnije od ponovnog projektovanja IS. Početak reverznog inženjerstva u razvoju programskih proizvoda se vezuje za postupak ručnog, ili automatizovanog generisanja projektnih i programskih specifikacija, na osnovu prethodno realizovanog programskog proizvoda. Tehnike reverznog inženjerstva se koriste za ostvarivanje slijedeća dva osnovna cilja. Prvi cilj je generisanje projektne i programerske dokumentacije za aktuelnu verziju programskog proizvoda, za koju prethodno takva dokumentacija nije urađena, u cilju stvaranja osnova za održavanje tekuće verzije tog programskog proizvoda. Drugi cilj je


149

generisanje projektnih i programskih specifikacija programskog proizvoda u formatu "razumljivom" CASE proizvodu, pomoću kojeg se želi razviti nova verzija tog programskog proizvoda. Na slici 8.8 je prikazana ekranska forma alata za reverzno inženjerstvo.

Slika 8.8. Ekranska forma CASE alata za reverzno inženjerstvo. Tehnike reverznog inženjerstva, u domenu IS, se primjenjuju za ostvarenje slijedećih zadataka: 1. Generisanje implementacionog opisa sheme BP, na osnovu nekih od slijedećih parametara: realnih podataka koji postoje u BP, stanja rječnika podataka konkretnog sistema za upravljanje bazama podataka (SUBP) pod kojim je posmatrana BP realizovana ili opisa datoteka i formata slogova u programskom kodu aplikacija tekuće verzije IS (npr. u okviru SUBP ORACLE/Designer 2000 reverzni inženjering implementacione sheme BP, na osnovu stanja rječnika ORACLE baze podataka i eliminisanja razlika između rječnika ciljne BP i rječnika 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 prevođenje implementacione sheme BP u konceptualnu shemu BP obavlja program Table To Entity Retrofit); 3. Generisanje programskih specifikacija (struktura menia, ekranskih formi ili formi za izvještaje, podshema i proceduralne logike) na osnovu programskih kodova aplikacija tekuće verzije IS (npr. u okviru SUBP ORACLE /Designer

150


2000 za reverzni inženjering ekranskih formi, izvještaja i bibliotečkih modula, namjenjeni su programi Capture Design of Form, Capture Design of Report i Capture Design of Library). Izbor tehnike reverznog inženjerstva i njena automatizovana primjena u velikoj mjeri zavisi, kako od prirode konkretnog zadataka koji se rješava, tako i od kvaliteta, tj. "informativnosti" ulazne specifikacije, na koju se tehnika reverznog inženjerstva primjenjuje. Samim tim je i kvalitet generisanog rezultata u reverznom inženjerstvu bitno određen kvalitetom ulazne specifikacije. Ukoliko se, na primjer, tehnika reverznog inženjerstva primjenjuje za generisanje implementacione sheme BP, najbolji rezultat se, u opštom slučaju, može očekivati ukoliko se kao ulazna specifikacija koriste podaci iz rječnika podataka sistema za upravljanje bazama podataka, a najlošiji ako se kao ulazna specifikacija koriste samo realni podaci iz BP. Ova konstatacija, medjutim, ne mora biti uvijek tačna. Ukoliko rječnik podataka konkretnog sistema za upravljanje bazama podataka sam po sebi nije dovoljno informativan, ili se u tom rječniku, iz nekog razloga, ne nalaze svi potrebni podaci, tada ni izlazni rezultat reverznog inženjerstva ne može 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 računarom podržanog rješenja, odnosno tehničku specifikaciju sistema. Omogućava izradu modela za ugradnju, kojim se opisuje kako sistem radi, šta predstavlja fizički dizajn. Moderni strukturirani dizajn je procesno usmjerena tehnika razrade velikog programa u hijerarhiju modula sa ciljem izrade programa koje je lakše napraviti i održavati. Starije varijante su oblikovanje programa sa vrha nadolje (top-down program design) i strukturirano programiranje. Alternative i/ili nadopune su informaciono inženjerstvo, izrada prototipa, zajednički dizajn aplikacija (JAD), brzi razvoj aplikacija (RAD) i objektno usmjereni dizajn.

9.1.1. Opšti dizajn sistema Opšti (konceptualni) dizajn daje funkcionalne specifikacije i omogućava odabir tehničke arhitekture sistema. Daje odgovor da li je centralizirana ili distribuirana obrada i skladištenje podataka, način izvršenja i koje se tehnologije koriste. Takođe, određuje da li je softver nabavljen, napravljen prema zahtjevima korisnika ili mješavina. Određuju se i razvojni alati. Mogu se izdvojiti slijedeće faze definisanja opštog dizajna: Analiza i distribucija podataka, koju sačinjavaju: 1. Pretvaranje konceptualnog modela podataka u logički model (relacioni, postrelacioni, objektno-relacioni, objektni), ako pretvaranje nije ranije učinjeno; 2. Izrada dobrog modela podataka, koji mora biti jednostavan, neredundantan, elastičan i prilagodljiv, kao i analiza podataka i normalizacija modela; 3. Analiza događaja, odnosno analiza entiteta normaliziranog modela i uočavanje događaja i uslova koji uzrokuju stvaranje, izmjenu i brisanje podataka i po potrebi ažuriranje modela procesa. Analiza i distribucija procesa sadrži: 1. Pretvaranje logičkog modela procesa u fizički model za odabranu arhitekturu, odnosno izrada sheme aplikacije. Fizički procesi su: serveri, radne stanice, rad

152


koji treba obaviti, dok su fizička skladišta: baze podataka, tabele (relacije) i datoteke; 2. Grupisanje i distribucija obrade na različite lokacije; 3. Dizajn računarske mreže, povezivanje sa drugim, postojećim, sistemima; 4. Definisanje prava pristupa logičkih grupa korisnika. Opšti dizajn interfejsa se odnosi na poboljšanje izgleda (ergonomija). Izrada planova konverzije i instalacije predstavlja posljednju fazu definisanja opštog dizajna.

9.1.2. Detaljni dizajn sistema Detaljni dizajn su tehničke specifikacije sistema. Sadrži izradu fizičkog modela podataka, odnosno pretvaranje logičkog modela podataka u fizički model podataka za odabrani SUBP, odnosno izradu sheme baze podataka. Izrada sheme BP podrazumjeva prilagođavanje modela podataka mogućnostima i ograničenjima SUBP, određivanje fizičkih parametara (volumetrija), ugađanje baze podataka i oblikovanje fizičkih datoteka. Dizajn programa je utvrđivanje strukture programa na osnovu modela procesa. Proces (logički) ili skup procesa može da se nalazi u jednom ili više programskih modula, te je potrebno određivanje veza između modula (standardno strukturnim kartama). U dizajn programa ulazi i preciziranje programske logike. Dizajn interfejsa sadrži dizajn interfejsa sistema (protokoli pristupa i razmjene podataka), kao i oblikovanje ekranskih formi i izvještaja. 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 može biti cjelovit, istovremeni (tzv. “frontalni”) razvoj cijelog IS. Ovakav pristup postavlja velike zahtjeve za ljudskim resursima, a sadrži problem koordinacije izvođača. 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 rješenje je izrada jedinstvenog modela podataka, na početku 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 definišu pojedine komponente sistema, u prvom redu računarsku opremu, programsku podršku, komunikacije, sistem zaštite i globalnu podršku aplikacija. Specifikacija hardvera i softvera je podloga za nabavku opreme. Distribuirana prezentacija

mreža Svi podaci na mainframe serveru

Podaci i procesi BP na serveru

Logika i korisnički interfejs na PC

Distribuirani podaci i logika (3-slojna) mreža

mreža

Korisnički interfejs na PC klijentu

Poslovna logika na aplikativnom serveru Internet i Intranet

Podaci i procesi BP na serveru

mreža Podaci na serveru BP

Korisnički interfejs na PC klijentu

Sva poslovna logika na mainframe serveru Distribuirani podaci (2-slojna) mreža

Sigurni Intranet provajder za pristup podacima, logici i Dio logike na Intranet serveru interfejsu

Sigurna konekcija na server BP

Siguran ulaz za zaštitu aplikacija i podataka

Dio logike na Internet serveru

Unutrašnji korisnički interfejs na PC

Konekcija na spoljnji svijet

Internet provajder konekcija za pristup interfejsu i dijelu logike

Slika 9.1. Primjeri arhitekture sistema.

Vanjski korisnik PC klijent

154


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

Slika 9.2. Primjer centralizovane obrade.

Server Host (mainframe računar)

Prezentaciona logika Aplikaciona logika Logika pristupa podacima Skladištenje podataka


155

9.2.3. Dvoslojna arhitektura klijent-server Klijent je jednokorisnički računar. Sadrži interfejs, a omogućava obradu i skladištenje podataka. Posjeduje mogućnost povezivanja na servere (prema potrebi i na druge klijente). Klijent (mikroračunar)

Server (mikroračunar)

Prezentaciona logika Aplikaciona logika Logika pristupa podacima

Skladištenje podataka

Klijent (mikroračunar)

Prezentaciona logika Aplikaciona logika

Server (mikroračunar, mali računar ili veliki računar)

Logika skladištenja podataka Skladištenje podataka

Slika 9.3. Dvoslojna arhitektura klijent-server. Server je višekorisnički računar. Omogućava rad sa dijeljenom bazom podataka, obradu podataka i servisiranje interfejsa. Posjeduje mogućnost povezivanja sa klijentima i drugim serverima. Korisnicima izgleda kao da jedan računar obavlja cijeli posao. Prednosti dvoslojne arhitekture klijent-server (slika 9.3) su u izolaciji promjena u pojedinom sloju, kvalitetnijoj (lakšoj) obradi i središnjem upravljanju integritetom podataka na serveru. Nedostak ove arhitekture je u otežanom održavanju aplikacione logike (programa) na svim klijentima i pojava „debelog klijenta”. Debeli klijent je onaj klijent kod koga je integrisana logika podataka. Nema obrade podataka na serveru ili je obrada minimalna. Posjeduje minimalnu ili nikakvu elastičnost na promjenu poslovne politike. Prednosti debelog klijenta su: brzi početni razvoj aplikacije, veća samostalnost klijenta i rasterećenje glavnog računara (servera). Može imati lokalnu bazu podataka. Kao debeli klijenti mogu se koristiti jeftini računari sa snažnim procesorima. Nedostatak je da je poslovna logika integrisana na klijentu. Promjena poslovne logike znači

156


instalisanje nove verzije aplikacije na svim klijentima. Velika je mogućnost rada sa zastarjelim podacima. Ako sa vremenom aplikacija postane spora (zbog količine 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. Većinom se koriste u poslovnim sistemima, a tipični primjer tankog klijenta je web pretraživač. Prednosti tankog klijenta su: promjena poslovne logike ne znači obavezno i promjenu u klijentskom dijelu aplikacije, promjena poslovne logike može se obaviti centralizovano, računari ne moraju imati veliku procesorsku snagu, ukoliko sa vremenom obrada postane spora (zbog količine podataka) može se jednostavno povećati snaga središnjeg računara. Kao tanki klijent može se koristiti npr. web pretraživač (dobro definisano i svima dostupno). Smanjena je mogućnost 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 opterećenje glavnog računara, a to znači skupi glavni računar. Ukoliko se kao klijent koristi web pretraživač moraju se poštivati njegova ograničenja.

9.2.4. Troslojna i višeslojna arhitektura klijent-server Kod troslojne arhitekture klijent-server (slika 9.4) distribucija baza podataka i poslovne logike je izvršena na zasebne servere, čime je dobijena arhitektura: server aplikacija + server baza podataka + klijent. Namjena pojedinog sloja je slijedeća: 1. Server aplikacija obavlja upravljanje transakcijama "preuzetih" sa servera podataka. Dio ili čitava poslovna logika je "preuzeta" sa klijenta; 2. Server baza podataka vrši upravljanje podacima; 3. Klijent sadrži korisnički interfejs. Takođe sadrži dio poslovne logike, i to onaj dio koji se ne mijenja, ili logiku ličnog karaktera. Prednosti troslojne arhitekture su: bolja raspodjela opterećenja, veća skalabilnost, odnosno mogućnost ekspanzije (npr. povećanja broja korisnika, bez preopterećenja ili potrebe za promjenom procedura). Nedostaci su: složeni (komplikovani) dizajn i razvoj, problem raspodjele podataka, procesa, interfejsa, kao i veće opterećenje mreže. Višeslojna arhitektura se koristi za razvoj složenih aplikacija. Programski kod se može podijeliti u više 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 vrši podjela u tri nivoa, i to: klijent - GUI (u web aplikaciji to je web pretraživač), server aplikacija odnosno BLL (npr. web servis) i baza podataka (npr. SQL Server). Klijent (mikroračunar)

Server aplikacija (mikroračunar)

Prezentaciona logika

Aplikaciona logika

Klijent (mikroračunar)

Prezentaciona logika Server aplikacija (mikroračunar)

Aplikaciona logika

Server BP (mikroračunar, mali računar ili veliki računar)

Logika pristupa podacima Skladištenje podataka Web server (mikroračunar)

Aplikaciona logika Server BP (mikroračunar, mali računar ili veliki računar)

Logika pristupa podacima Skladištenje podataka

Slika 9.4. Troslojna arhitektura klijent-server.

9.2.5. Izbor arhitekture klijent-server Izbor arhitekture može zavisiti o raspoloživim računarima i mrežnoj infrastrukturi. Općenito, mogu se primijeniti sljedeći kriterijumi (tabela 9.1): Tabela 9.1. Arhitekture

Aplikacije

Dvoslojne K/S arhitekture sa tankim klijentima

Naslijeđeni aplikativni sistemi gdje je nepraktično i neisplativo odvojiti aplikativne obrade i upravljanje podacima. Računarsko-zahtjevne aplikacije sa vrlo malo ili bez obrade podataka. Podacima bogate aplikacije (pretraživanje 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 podrškom. Aplikacije koje zahtjevaju računarsko zahtjevne obrade podataka (npr. vizualizacija podataka – interaktivno ili u izvještajima). Aplikacije sa relativno čvrstom krajnje - korisničkom funkcionalno-šću, korištene u okolini gdje je dobro uspostavljeno upravljanje sistemom.

Troslojne ili višeslojne K/S arhitekture

Aplikacije velikog opsega sa stotinama ili hiljadama klijenata. Sistemi u kojima su i podaci i aplikacije promjenljivi. Aplikacije u kojima se integrišu podaci iz višestrukih izvora.

Primjer 1: Sa arhitekturom klijent-server potrebno je napraviti aplikaciju koja će prikazivati [Fertalj & Kalpić, 2005]: • kupce, prodavače i datume narudžbi, • nazive artikala, jediničnu cijenu i količinu za pojedinu narudžbu, • ukupnu količinu i ukupnu vrijednost narudžbe, • treba prikazivati zadnjih 20 narudžbi. Rješenje sa debelim klijentom glasi: na klijentu napraviti SQL upit kojim se obuhvataju podaci o zadnjih 20 narudžbi, na klijentu napraviti SQL upit kojim se obuhvataju detalji za zadnjih 20 narudžbi, kad se promjeni narudžba proći kroz sve detalje i ispisati one koje pripadaju trenutnoj narudžbi. Usput računati zbirne vrijednosti. Rješenje sa tankim klijentom je: na klijentu pozvati stored proceduru koja vraća podatke o zadnjih 20 narudžbi, kad se promjeni trenutna narudžba pozvati stored proceduru koja vraća detalje trenutne narudžbe 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 narudžbi. Ispunjenje promjene zahtjeva se sastoji u slijedećem. Na debelom klijentu treba promijeniti SQL upite u izvornom kodu, prevesti ga u novu izvršnu opciju te dostaviti aplikaciju korisnicima (sporo i skupo). Na tankom klijentu treba na serveru promijeniti samo pohranjenu proceduru za dohvat narudžbi (brzo, manje od pet minuta, i jeftino). Primjer 3: Rješenje razmatranog primjera u višeslojnoj arhitekturi sadrži slijedeće nivoe, slika 9.5: 1. Prezentacioni sloj GUI, koji služi za prikupljanje informacija od korisnika, vršenje 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 sačinjavaju HTML, DHTML, Win32 aplikacije, klijent-server skriptovanje, Java apleti, ActiveX kontrole, itd. Prezentacioni sloj se može 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 obrađenih informacija prezentacionom sloju. Ovaj sloj obezbjeđuje poslovna pravila i servise koji pomažu 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 može generisati generatorom koda npr. Visual Studio.NET 2003, u programskom jeziku C#; 3. Sloj pristupa podacima DAL, koji direktno ostvaruje interakciju sa podacima koji, obično, egzistiraju u BP kao što su SQL Server ili ORACLE. Ovaj sloj služi za smještanje, pronalaženje i održavanje 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 može generisati generatorom koda npr. LLBLGen, u programskom jeziku C#. COM+

Sistemski servisi Administracija

Prezentacioni sloj

Mrežni servisi

DHTML, Forme

Sloj poslovne logike

Alati

Zaštita Web server IIS Transakcije MTS

Sloj pristupa podacima

Osnovni servisi

DBMS, File system, mail, txt

Slika 9.5. Arhitektura Windows DNA (Distributed interNet Aplication architecture). Tok izrade aplikacije u višeslojnoj arhitekturi je slijedeći. 1.

Prezentacioni sloj GUI (generator koda Visual Studio.NET 2003 u programskom jeziku C#). Prema pravilima višeslojnog 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 učitavaju podaci o narudžbama. Nakon toga se okine event, na kojem se prikazuju podatci o detaljima narudžbi. Programski kod glasi: private void FormLastOrders_Load(object sender, System.EventArgs e){ // Konstruisi bklasu _bLastOrders = new BLastOrders(_connectionString); // Postavi DataSource na oba grida

160


dataGridOrders.DataSource = _bLastOrders.OrdersEntityCollection; dataGridOrderDetalis.DataSource = bLastOrders.OrderDetailsEntityCollection; // Ispiši detalje trenutno selektirane narudžbe dataGridOrders_CurrentCellChanged(sender, e); } Kod promjene selektirane narudžbe treba osvježiti podatke o detaljima. To se radi tako da se pozove pripadajuća metoda u b-klasi (SelectOrderDetails). Ta metoda dohvata detalje neke narudžbe, a usput računa 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 narudžbi _bLastOrders.SelectOrderDetails(Convert.ToInt32(dataGridOrde rs[ dataGridOrders.CurrentRowIndex, 0])); // Ispiši 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#). Biće naveden primjer konstruktora u b-klasi (sloju poslovne logike). Sloj poslovne logike treba pažljivo definisati, tako da GUI služi samo za prikazivanje podataka, a sve veće 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 priloženog 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 narudžbe _ordersEntityCollection = new EntityCollection(new OrdersEntityFactory()); SelectLastOrders(); // Definiranje EntityCollection-a za detalje narudžbe


161

_orderDetailsEntityCollection = new EntityCollection(new OrderDetailsEntityFactory()); }

Navedeni primjer sa dohvatom zadnjih 20 narudžbi u b-klasi se može promjeniti da se dohvati zadnjih 50 narudžbi. 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 mogućnost greške, kao i preglednost koda. Na sličan način bi se riješio i dohvat detalja pojedine narudžbe. Programski kod glasi: public EntityCollection SelectLastOrders() { // Isprazni trenutni sadržaj _ordersEntityCollection.Clear(); // Narudžbe 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 korištenje sortera i dodatnih staza za dohvat) _dataAccessAdapter.FetchEntityCollection(_ordersEntityCollec tion, null, 20, sorter, path); // Vrati podatke dohvaćene iz baze return _ordersEntityCollection; } 3. Sloj pristupa podacima DAL (generator koda LLBLGen u programskom jeziku C#). • Ovaj sloj služi za pristup bazi podataka (DAL); • Programski kod se generiše pomoću 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 specifični za pojedine baze podataka; Prednosti rješenja upotrebom generatora programskog koda: mogućnost pristupa bazi podataka preko objekta (nije potrebno znanje SQL-a), mogućnost promjene baze podataka, nema velikog gubljenja vremena na pisanje koda za pristup bazi podataka, manja mogućnost greške, itd.


162

10. Dizajn baza podataka 10.1. Uvod u dizajn baza podataka Dizajn baza podataka, u prvom redu, obuhvata izradu sheme baze podataka (fizički model, tehnički nacrt), kao i prevođenje modela podataka u strukture podržane odabranom tehnologijom (SUBP). Takođe, obuhvata određivanje primarnog ključa, sekundarnog ključa, stranog ključa i opisnih polja. Relacione BP, koje su nezamjenljive kod obrade poslovnih podataka, karakterišu slijedeći koncepti: strukturirani upitni jezik (SQL), okidači - trigeri (triggers), pohranjene procedure (stored procedures), dinamički skupovi podataka (cursor), korisnički 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 sačinjavaju priprema modela podataka za ugradnju, normalizacija, odnosno tehnika organizovanosti atributa, dovođenje modela u određeni normalizovani oblik (NO), 3NO ili viši NO. O zastupljenosti pojedinih tipova baza podataka za komercijalnu upotrebu, najbolje govori tabela 10.1. [Internet, 2006]. Tabela 10.1.

Product

Developer

License

DB Type

Access 2002

Microsoft

Commercial Relational

Cache

InterSystems Corp.

Commercial Post-relational

DB2

IBM


eXtremeDB

McObject

Commercial Navigational

FileMaker

FileMaker

Commercial FileMaker

FoxPro

Microsoft


Informix

IBM


Matisse

Matisse Software

Commercial Object-oriented

Objectivity/DB

Objectivity


OpenInsight

Revelation Software

Commercial Multi-valued

Oracle 8i, 9i

Oracle



SQL Server 2000

Microsoft


Sybase ASE 12.5

Sybase


UniData

IBM

Commercial Nested relational

UniVerse

IBM

Commercial Nested relational

Versant enJin

Versant Corp.


163

10.2. Normalizacija Normalizacija, odnosno tehnika organizovanosti atributa, je postupak strukturiranja sheme relacione baze podataka tako da se ukloni što više neodređenosti (nekonzistentnosti). Stepen normalizacije (normalizovani oblici) se povećava od 1NO do 5NO. Većina 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 može opisivati entitete ili veze u sistemu koji imaju višeznačne atribute, ne može za atribut imati neku drugu relaciju. b) Relacija R je u prvom normalizovanom obliku ako je bilo koji podskup neprimarnih atributa funkcionalno zavisan od ključa. c) Relacija R je u prvom normalizovanom obliku ako između kandidata za ključ i ostalih neprimarnih atributa postoje slijedeći tipovi preslikavanja: 1:1, 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 ključeve. Relacija R je u trećem normalizovanom obliku, ako je u drugom, i ako ne sadrži 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 složen, od koga neki drugi atribut potpuno funkcionalno zavisi. Relacija R (X, Y, Z) je u četvrtom normalizovanom obliku ako postojanje netrivijalne višeznačne zavisnosti X →→ Y uslovljava postojanje funkcionalne zavisnosti X → A za svaki atribut A relacije R.

Relacija R je u petom normalizovanom obliku ako i samo ako se svaka zavisnost spajanja u relaciji R može pripisati kandidatu za ključ. Informatičkim žargonom rečeno, normalizacija se svodi na ispunjenje tzv. "relacione zakletve" [Finkelstein, 1989]:


164

• ključ - 1NO: nema ponavljajućih grupa, definisan primarni ključ, • cijeli ključ - 2NO: svi neključni atributi u potpunosti zavisni o čitavom PK, • ništa drugo nego ključ - 3NF: svaki neključni atribut je neposredno zavisan samo o PK, • BCNO: svi atributi koji određuju druge atribute čine moguće ključeve. Prevođenje modela i normalizacija uporabom CASE alata se odvija slijedećim redoslijedom: 1. Automatizovano dodjeljivanje stvarnih tipova podataka konkretnog SUBP; 2. Stvaranje relacija (tabela) za entitete nadtipa i podtipa; 3. Automatizovana migracija ključa i prepoznavanje tzv. visećih veza (dangling relationships), odnosno veza na tabele koje nisu uključene u generisanje modela; 4. Većina CASE alata normalizira u 1NO: zamjena veza više-prema-više asocijativnim entitetima i zamjena višeznačnih atributa entitetima; 5. Viši normalizovani oblici: problem prepoznavanja djelomičnih i tranzitivnih zavisnosti; 6. Generisanje programskog koda okidača (trigera). Prije početka kodiranja obavlja se ograničeno uvođenje konzistentnosti i ugađanje baze podataka, zbog poboljšanja elastičnosti i poboljšanja performansi, gdje zahvat može rezultirati u logički model određenim brojem intervencija. Denormalizacija se svodi na ograničeno i kontrolisano narušavanje NO.

10.3. Denormalizacija Zamjenici (surogati) ključeva su ključevi sa samopovećavajućim vrijednostima (serial), koji se umeću ispred ključa sastavljenog od većeg broja atributa (npr. ≥ 3). Na originalni ključ postavlja se jednoznačan (unique) kompozitni indeks. Teorijski se ne preporučuje za asocijativne entitete, koji naslijeđuju ključeve svojih roditelja, jer se time gubi smisao identifikacione veze. Praktično, zamjenika ključa treba ugraditi kada je relacija (tabela) u koju se ugrađuje referensirana iz drugih relacija, a to nije u suprotnosti sa poželjnim 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 ključa sa samopovećavajućim vrijednostima u sve tabele (relacije) baze podataka, čime se pojednostavljuje ugradnja. Dolazi do umnožavanja ključeva, zamjenik postaje primarni a originalni postaje alternativni ključ, i dolazi do gubitka izvorne vrijednosti stranog ključa. Dijeljenje relacija je smještanje rijetko korištenih atributa u posebnu relaciju. Udruživanje relacija je uklanjanje pojedinih relacija stapanjem atributa obične veze 1:1 ili udruživanje nadtipa sa podtipovima kardinalnosti 1:1, pod uslovom da su slične strukture i sadržaja. Uvođenje konzistentnosti je dodavanje atributa za čuvanje izvedenih vrijednosti. To mogu biti atributi čuvanja za izvedenu vrijednost koja se može izračunati agregiranom funkcijom (npr. iznos računa kao suma iznosa stavki) ili oznake zadnje vrijednosti nekog stanja kada se vrijednosti pojedinih stanja nalaze u relaciji sa velikim brojem zapisa (torki), npr. stanje skladišta. Dodavanje atributa čuvanja može biti za redundantne vrijednosti koje se inače dobijaju složenim i/ili sporim upitima (zadnje zaposlenje + zadnji izbor u zvanje + zadnje školovanje) ili dodavanje atributa kao što su zastavice za "trajno" označavanje zapisa. Podrazumijeva se da se denormalizacija obavlja samo na mjestima gdje je to stvarno nužno i na takav način da ne ugrožava integritet podataka, odnosno aplikativno upravljanje integritetom.

10.4. Ugradnja pravila za očuvanje integriteta Očuvanje integriteta, stvaranjem objekata u rječniku BP, obuhvata entitetski integritet i referencijalni integritet. Entitetski integritet se ostvaruje postavljanjem primarnog ključa, dok se referencijalni integritet ostvaruje postavljanjem stranog ključa i ograničenja na unos. Kod referencijalnog integriteta mora postojati vrijednost stranog ključa (mandatory - not null), strani ključ se smije postaviti na nul-vrijednost (optional null), domenski integritet se ostvaruje postavljanjem ograničenja na skup vrijednosti, a alternativni ključevi su sa obaveznim atributima i jedinstvenim indeksima. Pravila referencijalnog integriteta, za opšti slučaj, su postupci prilikom unosa, ažuriranja i brisanja roditelja ili djeteta i odnose se na: zabranu (restrict), brisanje torki koje imaju odgovarajuću vrijednost stranog ključa (cascade), ažuriranje odgovarajućih vrijednosti stranih ključeva (set null) i postavljanje na standardnu vrijednost (set default). Ugradnja referencijalnog integriteta može biti različita. Neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI - Direct Referential Integrity), a svodi se na restrikciju pri unosu, tj. obavezni unos (not null) stranog ključa i provjeru postojanja referensirane torke pri unosu, postojanje opcionog, tj. nedefinisanog stranog ključa (null), ili kaskadnu obradu torki koje referensiraju roditelja koji se ažurira ili briše, npr:

166


[ ON DELETE { CASCADE | NO ACTION } ] [ ON UPDATE { CASCADE | NO ACTION } ]. Upravljanje referensijalnim integritetom okidačima (triggers) je elastičniji pristup, koji omogućava ugradnju i ostalih postupaka prilikom unosa/izmjene/ brisanja torki (vidjeti tačku 10.6). Aplikaciono upravljanje integritetom su postupci unosa/izmjene/brisanja podržani programskim kodom. Javlja se problem umnožavanja programskog koda, naročito kod hibridnih sistema (4GL + GUI). Mješovito upravljanje referencijalnim integritetom je kombinacija navedenih mogućnosti, sa tim da neposredno upravljanje referencijalnim integritetom od strane SUBP (DRI) ima prednost. Mogući problemi su višestruki. Neki atribut stranog ključa može biti primarni atribut. Pokušaj ažuriranja na nul-vrijednost stranog ključa koji je dio primarnog ključa u suprotnosti je sa pravilom entitetskog integriteta. Prilikom ažuriranja stranog atributa koji je ujedno i primarni atribut ne smije se narušiti jedinstvena vrijednost ključa. Postupak kaskadnog ažuriranja ili brisanja torki treba provesti rekurzivno, da bi se referencijalni integritet očuvao u svim dijelovima baze podataka, a ne samo na mjestu obrade.

10.5. Podešavanje baze podataka Postavljanje indeksa se vrši radi osiguranja integriteta podataka i ubrzanja dobijanja podataka. Koriste se slijedeće preporuke za postavljanje indeksa. Indeksi treba da su: 1. Jedinstveni indeksi nad primarnim i alternativnim ključevima (integritet); 2. Indeksi nad stranim ključem (ubrzanje provjere integriteta i spojnih upita); 3. Indeksi nad najčešće korištenim poljima, tj poljima koja se koriste za grupisanje, sortiranje ili selekciju uz uslov (ubrzanje pretraživanja); 4. Neki sistemi implicitno kreiraju indekse za primarne i strane ključeve. Uopšteno, u tom slučaju ne treba posebno kreirati indekse. Ako su ključevi složeni, pretraživanje ć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 ažuriranje indeksa. Izbjegavati nepotrebne i indekse koji su sastavni dio drugih indeksa! Potrebno je ukloniti indekse prilikom masovnih obrada podataka. Preporučuje se koristiti naredbe i opcije za uvoz podataka (BULK INSERT ... CHECK_CONSTR). Postavlja se pitanje da li treba kreirati indekse u relacijama sa malim brojem podataka.


167

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

168


Smještaj fizičkih datoteka obezbjeđuje povećanje sigurnosti i brzine pristupa odvajanjem SUBP, prostora za podatke, prostora za vođenje evidencije i rezervnih kopija na različite fizičke uređaje. Primjer: Dvije fizičke jedinice, četiri logičke 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 očuvanja uslova integriteta, definišu se automatski postupci koji se izvršavaju nakon obavljanja radnji unošenja, brisanja i ažuriranja podataka u relacijama. U relacionom upitnom jeziku SQL (PL/SQL) takvi postupci se zovu trigeri (okidači). U sastavu savremenih SUBP, kakav je ORACLE/Designer-a 2000, nalaze se generatori aplikacija (Generate Module/Forms), koji omogućavaju brzi razvoj aplikacija za unošenje, pretraživanje, ažuriranje i brisanje podataka. Umjesto da se pišu programi, dovoljno je naznačiti željenu aplikaciju upotrebom jednostavnih ekranskih formi. Na ovaj način zadane instrukcije se kombinuju sa mogućnostima SUBP, a kao rezultat se dobije prototip aplikacije. Ekranska forma, koja se dizajnira pomoću 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, unošenje i uređivanje podataka. Svako polje ima određenu veličinu, poziciju i tip podatka, koji se u njega unosi. Korisnik određuje složenost dizajnirane forme i ima potpunu slobodu da izabere blokove, postavlja polja i vrši provjere učinjenog. Generator aplikacija sadrži tri nivoa dizajniranja ekranske forme: • Prvi nivo predstavlja kreiranje blokova i polja. Najjednostavnija forma predstavlja prozore na osnovne relacije. Svako polje se može postaviti pojedinačno ili se može pozvati automatski uslovni blok generatora aplikacija; • Drugi nivo predstavlja definisanje blokova i polja. Na formi se mogu dodavati osnovne provjere ili uputstva za pružanje pomoći. Na primjer, mogu se definisati veličine polja, uslovne vrijednosti ili pomoćne poruke; • Treći nivo predstavlja definisanje trigera (okidača). Ovo je najnapredniji nivo i mogu se napraviti složene provjere i asistencije pisanjem kratkih SQL programa, najčešće u cilju očuvanja uslova integriteta.


169

10.6.2. Razvrstavanje naredbi u trigerima Trigeri se mogu definisati kao skup naredbi koje počinju da se izvršavaju u nekom trenutku rada forme generatora aplikacija. Svaki triger može biti sastavljen od jednog ili više koraka, od kojih svaki korak sadrži 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 korisničke izlazne naredbe. 1. SQL naredbe rade sa podacima iz relacija BP ili iz ekranske forme. Triger može pretraživati ili modifikovati bilo koju relaciju za koju korisnik ima pravo pretraživanja ili modifikovanja. SQL sintaksa dozvoljava trigerima da prenose vrijednosti između relacija i formi. Na primjer, slijedeći 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 izvršava naredbu uvijek kada korisnik javlja, unosi ili mijenja broj kupca u formi NARUČIVANJE. 2. SQL naredbe generatora aplikacija simuliraju akcije funkcionalnih tastera i drugih operacija, koje korisnik može izvršavati. Na primjer, slijedeći makrotriger pomiče kursor na blok ARTIKAL i izvršava pretraživanje: #EXEMACRO GOBLK ARTIKAL; EXEQRY; Makrotriger može biti vezan za funkcionalni taster, tako da korisnik može dobiti slog stavki pritiskom samo na jedan taster. Ovaj makrotriger se može izvršavati svaki put kada korisnik pregleda blok NARUDŽBA. 3. Korisničke izlazne naredbe pozivaju korisnikove programe napisane problemski orijentisanim programskim jezicima, kao što su: C, Pascal, COBOL i drugi. Korisničkim izlaznim naredbama se mogu vršiti računske radnje na poljima formi, pristupi poljima u relacijama i drugo.

10.6.3. Načini udruživanja trigera Trigeri se mogu udruživati za obavljanje različitih funkcija. Udruživanje trigera se može razvrstati u slijedećih pet grupa: 1. Unos, pri pokretanju forme ili ulaska kursora u novi blok, slog ili polje; 2. Pretraživanje, prije i nakon dobijanja sloga; 3. Promjena, nakon promjene vrijednosti i prije ili poslije prihvatanja unosa, ažuriranja ili brisanja u BP;


170

4. Izlaz, pri napuštanju forme ili kada kursor napusti blok, slog ili polje; 5. Pritisak na taster, kada korisnik pritisne funkcionalni taster. Može se izdvojiti još jedna grupa trigera, koja se ne odnosi na naprijed navedene slučajeve: 6. Trigeri imenovani od korisnika, obični 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 udruženi sa određenim poljem, trigeri na nivou bloka, kada su udruženi sa određenim blokom i trigeri na nivou forme, kada su udruženi sa cijelom formom. Na svakom nivou postoje određeni trigeri koji se mogu primjeniti. Na nivou polja se mogu primjeniti slijedeći trigeri: prije polja, poslije promjene, poslije polja, trigeri za tastere i trigeri imenovani od korisnika. Na nivou bloka se mogu primjeniti slijedeći trigeri: prije bloka, prije pretraživanja bloka, poslije bloka, prije sloga, poslije pretraživanja sloga, trigeri prihvatanja, prije brisanja, poslije brisanja, prije unosa, prije ažuriranja, poslije ažuriranja, poslije sloga, trigeri za tastere i trigeri imenovani od korisnika. Na nivou forme se mogu primjeniti slijedeći trigeri: prije forme, poslije forme, trigeri za tastere i trigeri imenovani od korisnika. Svaki tip trigera se može definisati na njegovom nivou ili bilo kojem višem nivou. Na primjer, triger "poslije promjene" se može definisati na nivou polja, bloka ili forme. Područje rada trigera je određeno nivoom na kojem je definisan. Na primjer, triger "poslije promjene" definisan na nivou bloka će se primjenjivati na svako polje bloka, odnosno izvršavaće se odmah nakon što korisnik promjeni vrijednost u bilo kojem polju bloka, a ne samo kada korisnik napušta 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 vlasništva, uključujući: koji je tip trigera, odnosno kada će se izvršavati, koje naredbe će se izvršavati 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 važi na nivou u kojem se definiše. U slučaju potrebe dati naredbe TYPES ili KEYS, da se dobiju LIST TYPES ili LIST KEYS prozori, koji sadrže listu mogućih trigera na tekućem nivou ili listu mogućih trigera za tastere na bilo kojem nivou.


171

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


172

Određivanje uspjeha i neuspjeha trigera je prilično složeno i zbog ograničenog prostora neće se dalje razmatrati u ovoj knjizi.

10.6.5. Objašnjenje pojmova iz sintakse trigera Određeni pojmovi iz sintakse trigera biće objašnjeni u skladu sa izvršenim razvrstavanjem naredbi u trigerima na: SQL naredbe, SQL naredbe generatora aplikacija i korisničke 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 omogućavaju da se: postave podaci u polja forme, vrši računanje 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 + pomoćni iskaz) je uključen u jedan korak trigera. SQL naredbe imaju dva proširenja, koja omogućavaju vezu sa poljem forme: 1. Može se upotrijebiti sintaksa :(BLOK.)POLJE da se izvrši obraćanje polju u formi. Dvotačka (:) označava upućivanje polju forme, umjesto atributu relacije; 2. U SELECT iskazu se može uključiti izraz INTO da se postave javljene vrijednosti u polja forme. Prema tome, postavljanje dvotačke (:) u INTO izrazu je nepotrebno, ali se može upotrijebiti radi pojašnjenja. Proširena 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 može biti polje koje odgovara osnovnoj relaciji za blok (polje BP), ili ono koje ne odgovara. Takođe, to može biti polje koje je vidljivo, ili ono koje nije vidljivo. Ako je vidljivo, to može biti polje koje korisnik može da modifikuje (dozvoljen unos i/ili dozvoljeno ažuriranje) ili ne, itd. SQL naredbe generatora aplikacija, za razliku od SQL naredbi koje imaju višestruku upotrebu, se mogu koristiti samo u koracima trigera i to za: • • • •

predefinisanje funkcionalnih tastera, izvođenja serije akcija na formi bez pritiskanja tastera, izvršenje trigera imenovanih od korisnika, pozivanje druge forme,


173

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

174


Korisničke izlazne naredbe su mnogo komplikovanije za pisanje i izvođenje od SQL naredbi i SQL naredbi generatora aplikacija, pa se koriste samo za one radnje koje ove triger naredbe ne mogu izvršiti, kao npr.: izvođenje složenih provjera polja, izvođenje složenih računa, izvođenje ažuriranja koja iniciraju vrijednosti u formi i optimiziranje izvođenja aplikacija. Korisnički izlazi se mogu pisati u bilo kojem od nekoliko programskih jezika, uključujući C, COBOL, FORTRAN, PL/1, Pascal, Ada, a kod najnovije verzije SUBP ORACLE 9i i u programskoim jezicima Java, XML i HTML. Kada se napiše program korisničkog 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, pomoću alata softverskog inženjeringa 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 podređen 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, pridruženog trigeru.

Slika 10.2. Postupak implementacionog projektovanja jednog trigera baze podataka u okviru Designer-a 2000. Slijedeća ekranska forma, prikazana na slici 10.3, omogućava definisanje: događaja koji pokreće izvršenje trigera, trenutka okidanja trigera, kao i to da li je riječ o trigeru koji se pokreće 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 obilježja tabele (relacije), čija modifikacija dovodi do pokretanja trigera. Ukoliko triger treba da sadrži logički (WHEN) uslov, ekranska forma "When" omogućava zadavanje takvog uslova.

10.7. Implementaciono projektovanje, generisanje i programiranje BP pomoću CASE alata 10.7.1. Opis implementacione sheme BP Na osnovu specifikacije implementacionog projekta sheme BP za aplikaciju Komercijalni poslovi, šta je razmatrano u podtački 6.3.2, vrši se opis sheme BP pomoću jezika SQL. Riječ je o automatski generisanom kodu, produkovanom pomoću generatora SQL koda Designer-a 2000, ORACLE. Na slici 10.4 je prikazan izvod iz datoteke koja sadrzi SQL naredbe za kreiranje odgovarajućih relacija (tabela). Osim SQL naredbi za kreiranje relacija BP, kreiraju se ograničenja primarnog ključa, ograničenja torki, ograničenja stranog ključa 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,


177

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);

Slika 10.4. Izvod iz datoteke koja sadrži SQL naredbe za kreiranje odgovarajućih 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 obično iterativne prirode, vrše se dodatne modifikacije implementacione specifikacije modula u cilju otklanjanja eventualno uočenih nedostaka ili poboljšanja 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 može da zada dodatne kriterijume za prikaz izvoda iz cjelokupne evidencije (u ovom slučaju 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 naći samo podaci o robi koja je evidentirana na zalihama onog skladišta, ciji je identifikacioni broj naveden u zaglavlju naloga. U ovom primjeru, riječ je o skladištu sa identifikacionim brojem 10.


179

Slika 10.7. Prikaz ekranske forme za formiranje naloga za otpremu. Logika izvršavanja interaktivnog modula naloga za otpremu jeste da korisnik, nakon pokretanja programa i prijavljivanja na server BP, može da selektira, zadaje, modifikuje ili briše podatke o nalogu za otpremu, putem prikazane ekranske forme. Ti podaci se smještaju u radnu zonu programa. U slučaju da je putem ekranske forme izvršeno ažuriranje podataka u radnoj zoni programa, korisnik je obavezan da pokrene postupak ažuriranja podataka u BP, izborom funkcije Save (Sačuvaj), npr. pokretanjem opcije menija Action/Save ili aktiviranjem odgovarajuće ikone. U suprotnom treba da odustane od izmjena podataka. Postupak ažuriranja se sprovodi automatski, putem jedne transakcije, a korisnik će, na kraju izvođenja transakcije, biti obavješten o efektima njenog sprovođenja. 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 sadržavati jednu UPDATE naredbu, dok će za svaku torku u radnoj zoni programa, koja je označena kao izbrisana, transakcija sadržavati 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 ograničenja, npr. SQL Server IDENTITY [( seed , increment )]. Blok šifre su sličane serijskim šiframa, s tim da su serijski brojevi grupisani prema značenju, npr. satelitski TV kanali: 100-199 PAY PER VIEW, 200-299 CABLE CHANNELS, 300-399 SPORT, 400-499 ADULT, 500-599 MUSIC-ONLY, ... . Alfanumeričke oznake su ograničeni skup znakovnih oznaka, često kombinovanih sa brojevima, npr. oznake država: MNE, DE, IT, SLO. Samogovoreće šifre (significant position codes) su svaki broj ili grupa brojeva koji opisuju neko svojstvo instance, npr. JMBG, a često se koriste i u skladišnoj evidenciji (dimenzije automobilskih guma, električne sijalice). Hijerarhijski kodovi predstavljaju podjelu u grupe, podgrupe itd. Kao primjeri hijerarhijskih kodova mogu se navesti: šifra predmeta MAT03A3, sa značenjem MAT 3 obavezni predmet u 3. semestru, ili hijerarhija vojnih sredstava n*m cifara. Izrada šifarskog sistema je neophodna tamo gdje je nemoguće preuzeti postojeće šifarnike od drugih ustanova ili iz postojećih sistema. Oznake definisane zakonom, standardom ili drugim propisima treba preuzeti i prilagoditi. Ostale šifarnike definisati tako da se naknadno mogu nadograđivati. Preporuke za izradu šifarnika su slijedeće. Šifre moraju biti dovoljno velike da opišu željene karakteristike, ali dovoljno male da se mogu interpretirati bez računara. Sistem šifriranja treba biti smislen i prikladan, kako bi dodavanje novih šifara bilo jednostavno. Izbjegavati samogovoreće š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 tekuću akademsku godinu na redovnom studiju. Posebno se evidentira način 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 lične potrebe

DA NE NE NE DA DA

Primjer jedinstvene šifre: Jedinstveni matični broj akademskog građanina (JMBAG) je jedinstveni broj u sistemu koga student dobija prilikom upisa na studije i zadržava sve do kraja svog studija. Ako se isti student upiše na dvije ili više ustanova


181

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

182


Slika 10.8. Primjer strukture rječnika podataka. Na slici 10.9 je prikazana praktična realizacija relacija iz sastava Rječnika podataka. Meta modeliranje može korisno poslužiti 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 Narudžba, 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 praktične realizacije rječnika podataka. Org cjelina Hijerar. (rad.mj)

Propis

Opis procesa

Vrsta dokumenta Osoba

Pravna osoba

Osoba na dok.

Organiz. Pravni Inform. Finans. Materij.

Plan

Dokument

Događ. na dok.

Stavka sruktuir. dokum.

Fizička osoba

Vrsta događaja

Zakon

Događaj

Osnovno Potrošno Tehničko

***

Vrsta sredstva Sastavnica sredstva

Sredstvo

Svojstvo

Svojstvo sredstva

Slika 10.10. Strukturirani prikaz (meta model) jednog poslovnog sistema.


184

Primjer: Narudžba. Narudžba MBB-Nabava za osnovno tehničko sredstvo prema preduzeću IMB Br. xxxx od xx.xx.200x. Veza: Ponuda preduzeća IMB br. xxxx od xx.xx.200x. Narudžbu izradio: Pero Odobrio njegov šef: Ivo Stavke: Računar 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 naručiv.

Narudžbenica

Šef

MBB, Ivo, Pero

Osoba

Pravna osoba

Zakon

Plan

Broj, Datum, Ponuda

Narudžba

Šestium Monitor Štampač Skener

Fizička osoba

Sredstvo

Pravni Finansij. Menadž.

Naručivanje

Osnovno Tehničko Vrsta sredstva

MBO,CPU, RAM,HDD, CRD,FDD

Vrsta događaja

Svojstvo

Svojstvo sredstva

Slika 10.11. Strukturirani prikaz (meta model) za primjer Narudžba.

Poliščuk E. Jaroslav: Projektovanje informacionih sistema Korisnik SifMje

Zaglavlje SifZag

VrstaDok VrDok StandSifPlac StandSifOtpr StandSifZag StandSifNap Napomena SifNap

Mjesto SifMje

185 Otprema SifOtp

NacinPlac SifPlac

Dokument IdDok Partner SifPart SifMje

Uplata IdUplate IdDok

VrDok IdPrethDok SifPart SifOtpr SifPlac SifZag SifNap

Parametar SkracParam

Tarifa TarBroj

Artikl SifArt TarBroj StavkaDok IdDok SifArt

Slika 10.12. Strukturirani prikaz (meta model) aplikacije Prodaja.

Slika 10.13. Primjer ekranske forme aplikacije nad meta modelom.

186


11. Dizajn programske podrške 11.1. Specifikacija i dizajn programske podrške Specifikacija programske podrške, odnosno specifikacija programa, obuhvata navođenje svih zadataka koje program treba obaviti, međusobne povezanosti različitih dijelova programa i podataka, opis vrste podataka, opis ulaznih i izlaznih podataka, kao i specifikaciju prikaza podataka. Dizajn programske podrške, odnosno dizajn programa, sadrži proces pretvaranja zahtjeva za programsku podršku u oblik koji omogućava programiranje, opis jezikom za oblikovanje programa (PDL - Progam Design Language (pseudokod)), pri čemu program napisan pomoću PDL nema oblik izvedbenog programa.

11.2. Pristup oblikovanju programa Pristup oblikovanju programa može biti različit. Tako npr. funkcionalni pristup oblikovanju programa (Yourdon & Constantine, 1979) sačinjavaju slijedeće faze. 1. Strukturirani dizajn programske podrške, koji savladavanje veličine i složenosti 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, omogućava veliko unutrašnje prijanjanje modula (koheziju). Moduli moraju biti interno visoko povezani, svaki modul treba obavljati jednu i samo jednu funkciju, kao i postizanje ponovne upotrebljivosti u budućim programima. Mora biti ostvarena mala vanjska zavisnost modula (skopčanost). Moduli trebaju biti minimalno međusobno 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 određuje strukturu programa. Objektno usmjereni pristup se zasniva na podjeli na klase, koje istovremeno sadrže strukture podataka i procedure (metode). Procedure se obavljaju nad objektima (instancama) klasa. Kohezija i povezivanje se, takođe, primjenjuju, a provode kontrolisanim naslijeđivanjem, interfejsom i sličnostima između klasa i komponenti.


187

11.3. Strukturirani dizajn Strukturirani dizajn omogućava oblikovanje programa na osnovu dijagrama toka podataka korištenjem strukturnih karti, transformacione i transakcione analize, kao i plošnim razlaganjem glavnog procesa u sastavne procese (slika 11.1).

Grafički prikaz sistema

Dijagram toka podataka sa određenim granicama

Dijagram toka podataka

Strukturna karta

Pseudokod

Slika 11.1. Grafički prikaz strukturiranog dizajna.

Strukturna karta (Structure Chart) prikazuje modeliranje programske podrške na osnovu dijagrama toka podataka. Dijagram toka podataka prikazuje ŠTA treba postići, a strukturnom kartom se izražava KAKO ostvariti te zahtjeve, slika 11.2. podatak (data couple)

funkcija niz

indikator (control couple)

poziv ugrađena funkcija (modul)

iteracija

selekcija

Slika 11.2. Elementi prikaza strukturne karte.


188

Prikaz hijerarhije programskih modula uključuje prenos podataka i upravljanja između različitih nivoa obrade, kao i prikaz naredne, ponavljajuće i uslovne obrade. Primjer: Izvještaj o poslovanju kompanije Gazda & ortaci, slika 11.3. Sistem izvještaja o prodaji datum

zbir datum

zbir

Zapiši izvještaj

Uzmi datum datum

zbir

vrijednost

datum

Ispiši zbir

zbir

Uspjeh

zbir

Katastrofa

EOF

Zapiši zaglavlje

Zapiši red datum

Čitaj podatak

vrijednost

Računaj zbir podatak

EOF

podatak

Piši podatak

Slika 11.3. Strukturna karta za DTP izvještaja o poslovanju kompanije. Transformaciona analiza (transform analysis) je analiza promjene/ pretvaranja podataka. Primjenljiva je na sisteme koji imaju strukturu oblika “ulaz–središte-izlaz”, tj. aplikacije sa jasno raspoznatljivim ulazima, središnjom obradom i izlazima, koji se mogu prikazati linearnim tokom podataka, slika 11.4. Struktura dizajna, prikladna za ovakve sisteme, se sastoji od tri odgovarajuća 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 izvršenja/obavljanja obrade. Primjenjuje se na sisteme sa jasno raspoznatljivim središtima izvršenja, 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: • središte zaprima ulaz B, koji se usmjerava (kao B1, B2 ili B3) u odgovarajući proces (3, 4 ili 5), • rezultirajući 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 obrađuju na poseban način. Najčešće se oblikuju plošnim razlaganjem glavnog procesa u sastavne procese. Nadređeni proces mora pribaviti sve ulaze potrebne za obavljanje pojedinih podređenih procesa, te prikupiti i čuvati proizvedene rezultate obrade, slika 11.6. Primjer:

Slika 11.6. Strukturna karta za DTP razložen plošnom dekompozicijom. Stvarni sistemi su, obično, složeni sistemi. Za oblikovanje programa se, najčešće, primjenjuje kombinacija osnovnih postupaka, slika 11.7.

Slika 11.7. Prikaz složenog sistema dobijenog kombinacijom osnovnih postupaka.


191

11.4. Dizajn interfejsa 11.4.1. Interfejsi Korisnički interfejsi su, najčešće, tekstualni ili grafički. Unos podataka može biti periodični za masovni unos (batch input) ili interaktivni unos (on-line), koji se obavlja na mjestu nastanka podataka. Automatizovani unos može biti raznolik: biometrijski uređaji (otisci prstiju, uzorci glasa), elektromagnetski uređaji (identifikacija objekata pomoću radio talasa), magnetski uređaji (magnetske kartice i drugo), optički čitači (optički čitači oznaka, optički čitači teksta), pametne kartice (mikroprocesor, memorija), uređaji osjetljivi na dodir (touch screen, touch-pad, pen-based), ... . Izlazi (izvještaji) mogu biti: dokumenti (prijavnice, računi), detaljni izvještaji (dokumentovanje obrade, istorija i stanja evidencije), zbirni izvještaji (grupisanje, sortiranje, iznimke), grafički izvještaji (tačkasti, štapićasti, linijski), ... .

11.4.2. Elementi grafičkog interfejsa za unos podataka Elementi grafičkog interfejsa za unos podataka su: Text Box (i varijante) služi za unos podataka u obliku slobodnog teksta. Radio Button služi za unos vrijednosti iz konačnog malog skupa unaprijed poznatih, međusobno isključivih vrijednosti (2 do 3). Check Box omogućava unos binarnih vrijednosti, opciona vrijednost je "nepoznato". Drop-Down ili Combination (Combo) Box omogućava unos umjereno velikog broja (?) poznatih (?), međusobno isključivih vrijednosti. List Box namjenjen je za unos umjereno velikog broja (?) poznatih, ne nužno isključivih vrijednosti. Spin (Spinner), DomainUpDown, NumericUpDown namjenjen je za unos nevelikog niza diskretnih vrijednosti. Grid (mreža, 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, količini podataka te mogućim akcijama. Mora postojati područje za navigaciju (ekranska forma za izbor ili pregled podataka), područje za prikaz statusa obrade i radno područje za rad sa podacima.

192


Interfejsom moraju biti podržane različite vrste ekranskih formi za izbor (npr. vertikalne i kružne), uz mogućnost brzog odabira (funkcionalnom tipkom ili slovom opcije). Horizontalna ekranska forma za izbor (menu bar) je uvijek vidljiva i lako dohvatljiva. Padajuće (pull-down) i kaskadne ekranske forme su "nevidljive", ali se opcije daju grupisati. Skočne forme (pop-up) nisu očigledne, skaču na različitim 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 pažljivo i jednoznačno, a unaprijed treba predvidjeti i one za aktiviranje dodatnih funkcija. Doslijednost interfejsa nužan 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 logički grupisana. Unos se mora obavljati u redoslijedu kojim su polja fizički poredana. Treba ustrajati na preglednosti podataka i minimizirati prekrivanje informacija (npr. u slučaju više istovremeno prikazanih "prozora"). Interfejs mora imati ujednačene standardne poruke, zvučne signale i upozorenja, kojima se pruža dovoljna informacija, a korisnik nepotrebno ne opterećuje. Poruke moraju biti jednostavne, precizne te zavisne o kontekstu. Izbjegavati računarski žargon


193

i skraćenice. Mora biti ugrađena interaktivna pomoć zavisna o kontekstu. Prilikom izgradnje interfejsa treba ukloniti ili prevesti poruke na stranom jeziku (npr. one koje javlja SUBP) i izbjegavati stručne izraze. Na slici 11.9 je prikazana ekranska forma jednog grafičkog interfejsa.

Slika 11.9. Primjer grafičkog interfejsa. Funkcionalnost interfejsa. Poželjno je da se traženje, unos i izmjena podataka obavljaju na istoj ekranskoj formi i na isti način. Treba omogućiti prekid akcija koje predugo traju, pod uslovom da se tim prekidom ne narušava integritet podataka (npr. prekid selekcija velikog broja zapisa, prekid transakcija). U svakom dijelu obrade treba omogućiti odustajanje uz potvrdu korisnika da to stvarno želi (npr. brisanje). Upozorenja i potvrde prekida pohrane podataka treba provoditi samo ukoliko je stvarno došlo do promjene. Unesene podatke treba provjeravati što ranije, po mogućnosti neposredno nakon promjene sadržaja polja ekranske forme. Na polju za unos šifri treba omogućiti odabir iz suženog skupa podataka smještenih u šifarnik. Suženje skupa treba da se može obaviti na osnovu dijela tekstualnog opisa šifre, uz mogućnost upotrebe meta znakova. Korisniku treba omogućiti pregled teksta koji će biti napisan u izvještaj. Pregled na ekranskoj formi uklanja potrebu za ispisom na papiru i olakšava prilagođavanje 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. Ulančavanje procedura Često se događa da dio rada treba poništiti zbog toga što u sistemu ne postoji šifra koja se želi upotrijebiti, a nemoguće ju je pohraniti. Problem je u tome što je korisnik, prisiljen da poništiti do tog trenutka unesene podatke, prođe kroz nekoliko ekranskih formi za izbor do šifarnika, pohrani novu šifru, vratiti se na mjesto gdje je ona bila potrebna, ponovi unos prije poništenih podataka i tek tada ih pohrani.

Slika 11.10. Primjer ulančavanja procedura. Rješenje je da se na polju za unos vrijednosti stranog ključa omogući otvaranje “prozora”, sa listom za pregled i odabir zahtijevanog podatka, uz prikaz svih zapisa u odgovarajućoj relaciji. Takođe, treba omogućiti otvaranje liste za pregled (uz prikaz ograničenog 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 moguće, treba smanjiti broj postupaka za jedan poslovni proces da korisnici ne bi ponavljali iste akcije. Primjer ulančavanja 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 pažljivo grupisati poslovne procese u sisteme procedura, dati prednost učestalijim poslovnim procesima i paziti da se grupisanje obavi po funkcionalnim cjelinama. Postupak je slijedeći. Početni sistem je skup modula za obradu podataka u jednoj relaciji, pri čemu svaki od njih podržava standardne funkcije i poziva druge module. Nakon toga se vrši postupno udruživanje i reorganizacija modula, uz naknadno razdvajanje sistemskih od korisničkih promjenjivih elemenata. Ovakav način izrade programske opreme zahtijeva veći početni rad, ali dugoročno donosi prednosti. Početni sistem (moduli pune i reducirane funkcionalnosti) se sastoji od početne ekranske forme za izbor i izvedbenih programa Pi, (i = 1, … , n), koji sadrže glavni program Mi za poziv ekranske forme za izbor standardnog modula, skup standardnih funkcija {F}i te pridruženi reducirani skup funkcija {R}i (slika 11.11). x xxxxxxx x xxxxxxx x xxxxxxx

x xxxxxxx x xxxxxxx x xxxxxxx



Pokretački meni

P1

P2

Pi

Pn

M1

M2

Mi

Mn

F1

R1

F1

R1

Fi

Ri

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 sadrže udruženi glavni program M’j, µ(j) skupova standardnih funkcija, π(j) reduciranih skupova funkcija te ρ(j) skupova ručno ugrađenih funkcija, (j = 1, … , ν).


196



Hijerarhijski meni



P’1 M’1 F’11

R’11

H11

P’v M’v F’1μ(j)

R’1π(j) H1ρ(j)

F’v1

R’v1

Hv1

F’vμ(j)

R’vπ(j)

Hvρ(j)

Slika 11.12. Primjer sistema nakon reorganizacije i kodiranja modula.

11.7. Standardizacija i modularnost programske podrške 11.7.1. Standardizacija i modularnost Standardne funkcije modula aplikacije za rad sa bazom podataka su slijedeće: 1. Ulaz u modul, koji ostvaruje automatski prikaz podataka na osnovu uslova/parametera. Može biti prikazan niti jedan zapis, svi zapisi ili odabrani zapisi (primarni ključ je uslov za selekciju zapisa); 2. Traženje (selekcija) podataka: mora podržavati traženje 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 odgovarajuću provjeru domenskog, entitetskog i referencijalnog integriteta. Treba omogućiti odabir, i po potrebi unos, podataka koji se nalaze u drugim relacijama, a povezani su preko stranog ključa; 4. Izmjena postojećeg zapisa: omogućava se promjena vrijednosti prethodno učitanog, a trenutno na ekranskoj formi prikazanog zapisa. Načelno se zabranjuje izmjena vrijednosti identifikatora zapisa. Odabir referenciranih podataka obavlja se kao kod unosa;


197

5. Brisanje učitanog i prikazanog zapisa uz odgovarajuće integritetske provjere i poruke. Brisanje se obavlja uz dodatnu potvrdu; 6. Pregledanje (eng. browsing) prethodno učitanih podataka: grupni pregled većeg broja učitanih zapisa u “prozoru” po redovima, po stranicama, skok na prvi/zadnji/n-ti zapis, pretraživanje liste podataka po dijelu naziva (filter) ili po želji koji može odabrati jedan ili više zapisa ili onemogućiti odabir. Standardno se prikazuju samo osnovni elementi zapisa (primarni ključ i relevantni zavisni atributi); 7. Poredak (sort) zapisa koji se prikazuju: određivanje poretka prije selekcije ili naknadni preraspored već učitanih zapisa; 8. Ispisivanje izvještaja (report): sadržaj ispisa, trenutno prikazani zapis, svi učitani zapisi, format ispisa, odnosno osnovni podatci (šifra i naziv) ili svi podaci, odredište ispisa, npr. štampač, ekranska forma, datoteka (nova datoteka, dodavanje na kraj postojeće datoteke); 9. Izlaz iz modula: sa prenosom informacija o odabranom zapisu (primarni ključ ili cijeli zapis). Primjer: Učitavanje 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 opštih programskih rješenja Standardni modul. Za većinu relacija u bazi podataka dovoljno je napraviti modul sa ugrađenim standardnim funkcijama. Standardne funkcije se ugrađuju tako da se, osim sa ekranskih formi unutar vlastitog modula, mogu aktivirati i iz bilo kojeg drugog modula (slika 11.13). Poželjno je unaprijed oblikovati standardne module i to: modul za obradu pojedinačnih zapisa, modul za tabelarnu obradu i modul tipa glava-stavke (tzv. Masterdetail). Univerzalni modul. Alternativno, preporučuje se ugraditi univerzalni modul sa standardnim funkcijama, koji se može dinamički prilagoditi tako da obrađuje podatke u različitim relacijama. Univerzalni modul treba realizovati tako da u pogonu može istovremeno postojati više instanci istog modula prilagođenih pojedinim relacijama. U zavisnosti od projekta, univerzalni modul se može zamijeniti i pomoću polovine standardnih modula.

Slika 11.13. Primjer osnovnog standardnog modula. Primjer: Udruživanje standardnih modula. Forma je kreirana kao kombinacija kopija osnovnih formi, dok se sofisticirane funkcije nadograđuju ručno (slika 11.14).


199

Slika 11.14. Primjer udruživanja standardnih modula. Primjer: Univerzalni modul za tabelarnu obradu. Sadrži samo osnovne objekte i pozive na standardne procedure (metode) za obradu događaja vezanih uz te objekte. U trenutku aktiviranja obavlja se prilagođavanje relacije za obradu podataka strukturi relacije podataka (slika 11.15).

Slika 11.15. Primjer univerzalnog modula za tabelarnu obradu.

200


Primjer: Univerzalni modul za pojedinačnu obradu sadrži objekte za posluživanje standardnih funkcija, te po jednu instancu objekata za prikaz/obradu podataka, koji se prilikom aktiviranja modula dinamički umnožavaju u skladu sa strukturom relacije. Unaprijed se ugrađuju pozivi standardnih procedura vezanih uz standardne funkcije, te objekte za prikaz/obradu podataka (slika 11.16).

Slika 11.16. Primjer univerzalnog modula za pojedinačnu obradu.


201

12. Implementacija informacionog sistema 12.1. Izrada sistema Implementacija informacionog sistema podrazumjeva ugradnju novog, računarom podržanog, sistema u poslovni sistem. Drugim riječima, predstavlja izradu novog sistema i isporuku tog sistema u eksploataciju, tj. svakodnevnu upotrebu. Izrada IS, ukratko, se obavlja kroz slijedeće faze: formiranje razvojnog tima i dodjeljivanje odgovornosti članovima tima, izgradnja i testiranje mreža (po potrebi), izrada i provjera baze podataka, kreiranje baze podataka, odnosno transfer probnih podataka i testiranje operacija nad podacima. Nakon kreiranja baze podataka vrši 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, najčešće primjenom nekog formalnog programskog jezika. Ručno kodiranje je neizbježno zbog veličine stvarnih problema i složenosti 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). Poželjno je da konkretni jezik uz prevodilac (compiler) uključuje interpretator (interpreter), te alat za otkrivanje pogrešaka (debugger). Automatsko kodiranje se koristi za generisanje programskog koda, generisanje interfejsa, kao i generisanje sheme baze podataka. Istovremeno korištenje različitih programskih jezika, odnosno jezika različitih 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 početku, sa uslovom na kraju, sa unaprijed poznatim brojem koraka). Kod strukturiranog programiranja treba izbjegavati bezuslovne skokove (GOTO naredbe).


202

Proceduralno programiranje je način programiranja koji omogućava da se program definiše kao skup programskih cjelina, poželjno takvih da se mogu ponovo koristiti. 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 logički povezanih programskih cjelina. Uvođenje programskog modula uslovljava pojavu modularnog programiranja. Komponenta je bilo koji sastavni dio softvera. Uobičajeno se podrazumijevaju fizičke cjeline.

12.3. Pristup programiranju Monolitni pristup (build and fix) je dugotrajno kodiranje, a zatim niz ponavljanja oblika provjera+ispravka. Odgađa otkrivanje problema (grešaka u kodu i dizajnu). Proslijeđuje probleme u primjenu i održavanje. Inkrementalni pristup (stupnjevito, postupno programiranje) je niz ponavljanja oblika kodiranje+provjera+ispravka. Omogućava raniju provjeru i izdvajanje grešaka, raniju raspoloživost djelomičnih (nedovršenih) verzija programa, kao i ravnomjerniju podjelu posla. Omogućava pristup odozgo prema dolje, odozdo prema gore, kao i mješoviti pristup. Primjer: Inkrementalni pristup. 1. Izrađuje se program čija je struktura prikazana slikom 12.1; a b

c

d

e

f

h

i

g k

j l

m

Slika 12.1. Inkrementalni pristup: struktura programa. 2. Prvo se kodiraju sve funkcije, a zatim se udružuju; 3. Pokretanje programa završava fatalnom greškom; 4. Problem: kako ustanoviti u kojoj funkciji se nalazi greška; 5. Rješenje je u postupnom kodiranju i udruživanju 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 sadrži poruku (“Tu sam B”): Funkcija A () poziv B() Funkcija B() ispis "Tu sam B" Prilikom izrade funkcije koja će biti pozvana iz neke druge, još neugrađene funkcije, izrađuje 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 integriše prije fDonja. Mogući 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 izrađuje beh, a drugi istovremeno radi cdfi. Nakon što su završeni d i odrezak f, treći programer započinje gjklm (slika 12.2). Prednost ovog pristupa programiranju je bolja provjera logičkih funkcija (na višem nivou hijerarhije, u kojima se donose odluke), odnosno brže otkrivanje logičkih grešaka i manji utrošak odrezaka. Nedostatak je nedovoljna provjera operativnih funkcija (na nižim nivoima obavljaju stvarni posao). a b

c

d

e

f

h

i

g k

j l

m

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 izrađuje prije fGornja. Redoslijed kodiranja je lmhijkefgbcda (slika 12.3): prvi programer radi heb, drugi programer radi ifc i treći programer radi lmjkgd. Nakon što su završene b, c i d, pristupa se konačnom udruživanju.


204

Prednost ovog pristupa programiranju je bolja provjera operativnih funkcija i manji utrošak pogonskog koda. Nedostatak je kasno otkrivanje logičkih grešaka. a b

c

d

e

f

h

i

g k

j m

l

Slika 12.3. Programiranje od dna prema gore. Mješoviti (sandwich) pristup. Prvo se od vrha prema dolje izrađuju logičke funkcije, npr. abcdgj. Zatim se od dna prema gore rade operativne funkcije, npr. efhiklm (slika 12.4). Prednost ovog pristupa programiranju je rano otkrivanje logičkih grešaka uz bolju provjeru operativnih funkcija. a b

d

c

e

f

h

i

g j l

k m

Slika 12.4. Mješoviti pristup.

12.4. Programski standardi i preporuke Povećanje čitljivosti programa se ostvaruje: standardizacijom naziva, programskim komentarima, tehnikom i stilom programiranja, različitim označavanjem pojedinih elemenata jezika, kao što su rezervisane riječi, identifikatori, komentari, opcije prevodilaca (različita boja ili "veličina" znakova), korištenjem predefinisanih simboličkih oznaka i konstanti. Takođe je potrebno izbjegavanje programskih redova


205

koji dužinom prelaze širinu ekranske forme, pisanje jedne programske naredbe u redu, podjela nizova naredbi na odsječke koji su u cjelini vidljivi na ekranskoj formi, formatiranje izvornog koda, odnosno pomicanje u desnu stranu naredbi unutar programskih struktura, tzv. "uvlačenje".

12.4.1. Smjernice za nazive Nazivi struktura podataka treba da budu pisani u skladu sa slijedećim 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 označavanju identifikatora, npr. operatori i znakovi kao što su: Dat-Rođ; 3. Izbjegavati prekratke nazive koji, osim u nečitkost, vode u nedoslijednost već pri prvoj pojavi iste skraćenice za različiti pojam, npr. SifMje za Mjeru i Mjesto; 4. Izbjegavati preduge nazive, npr. Redni_broj_stavke_kalkulacije, zbog smanjenja čitljivosti, produktivnosti ručnog kodiranja (pojava sintaksnih grešaka izazvanih greškama u pisanju produžava vrijeme ispravljanja i prevođenja) i mogućih ograničenja jezika. Dužina 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 slijedećim 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 značenjem sadržaja, npr. max za najveću vrijednost ili len za varijablu koja određuje dužinu; 3. Koristiti standardne prefikse/sufikse za srodne elemente/objekte, npr. frmOsoba ili fOsoba za ekransku formu, repOsoba, rOsoba za izvještaje…; 4. Koristiti skraćenice opštih pojmova kao što su: broj, redni broj, šifra, skraćenica, 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 olakšava snalaženje u programskom kodu i uklanja moguća "neodređenost" sadržaja, npr. gCount, sCount, lCount, aCount. Standardizacija naziva. Dodjeljivanje naziva objektima modela podataka odražava se na nazive programskih varijabli. O tome treba voditi računa već prilikom oblikovanja baze podataka. Poželjno je oblikovanje obaviti takvim alatom za modeliranje, koji osim stvarnih naziva ima mogućnost evidentiranja kodova koji će se koristiti prilikom stvaranja objekata BP. Preporučuje se upotreba različitih notacija, kao što su: korištenje velikih i malih slova (BrojCipela), umetanje podcrte između dijelova od kojih je sastavljen pojam (broj_cipela) ili kombinovanje spomenutih notacija. Primjeri: PascalCase, koji se koristi kod imenovanja prostora: imena, klasa, interfejsa, pobrojanih tipova, postupaka i svojstava, static, public ili protected atributa, zahtjeva da početno slovo svake riječi u imenu bude veliko slovo, npr. BackColor. Identifikator klase može započeti znakom @. Dok, sa druge strane, camelCase, koji se koristi kod zaštićenih atributa i lokalnih varijabli postupaka, zahtjeva da početno slovo prve riječi u imenu bude malo slovo, početna slova ostalih riječi u imenu su velika slova, npr. backColor. Preporuke, kojih se treba pridržavati: imena interfejsa uobičajeno započinju slovom I, koristiti imenice za imena klasa i koristiti glagole za imena postupaka.

12.4.2. Smjernice za komentare Programski komentari treba da budu ažurni, tj. da odgovaraju stvarnom stanju. Ne pretjerivati u pisanju komentara. Loš kôd je bolje ponovo napisati, nego (bezuspješno) pojašnjavati. Komentarisati smisao naredbi (izbjegavati prepričavanje"). 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


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

207

208


12.4.3. Programske preporuke Na početku izrade treba uspostaviti standarde kodiranja, a zatim odabrani stil doslijedno primjenjivati! Tehnika i stil programiranja zahtjevaju: • eksplicitno deklarisati programske varijable, • izbjegavati programske varijable opšteg tipa, • postaviti početne vrijednosti varijabli prije upotrebe, • ugraditi podrazumijevane vrijednosti ulaznih podataka, • provjeravati zahtijeve za ulaznim podacima i valjanost ulaznih podataka, • doslijedno formatirati podatke, • olakšati ispravljanje neispravnih ulaznih podataka, • pripaziti na granične vrijednosti podataka, naročito indeksiranih varijabli ... , • provjeriti moguće numeričke greške (10.0 * 0.1 nije uvijek 1.0), • izbjegavati poređenje na jednakost brojeva sa pomičnim zarezom, • koristiti zagrade radi naglašavanja redoslijeda izračunavanja izraza, • presložiti i pojednostaviti nerazumljive izraze, • izbjegavati nepotrebna grananja, • izbjegavati trikove (ne žrtvovati jasnoću radi "efikasnosti"), • ponavljajuće blokove i izraze zamijeniti potprogramima, • rekurziju koristiti samo za rekurzivne strukture podataka, • prvo napraviti jasno i ispravno rješenje, a zatim brzo rješenje, • neefikasan kôd ne usavršavati, nego naći bolji algoritam, • rutinski posao i jednostavnu optimizaciju prepustiti prevodiocu, • nakon pronađene i ispravljene greške provjeriti imali ih još, • loš kôd bolje je napisati ponovno, nego ga popravljati ("krpiti"), • nedovoljno opšta rješenja bolje je reorganizovati, nego ih prilagođavati radi višekratnog korištenja, • kodirati sa osloncem na programske priručnike. Programski priručnici. Prije početka kodiranja treba pripremiti programske priručnike sa funkcijama grupisanim po namjeni. Tu spadaju funkcije za rad sa opštim 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 pomoći), funkcije za održavanje baze podataka (npr. provjera konzistentnosti podataka i izrada rezervnih kopija), funkcije za administriranje vanjskih uređaja (npr. terminali i pisači), kao i programski dio sistema zaštite (npr. definiranje programskih modula, funkcija i korisnika, te rukovanje pravima pristupa programima i podacima). Grupisanje funkcija interfejsa, te poruka i tekstova pomoći, pomaže kod promjene kodne stranice ili u slučaju 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 greške i ispitivanja programa, su uspješni kada se dokaže postojanje grešaka. Testiranje programa (provjera, ispitivanje programa). Provjera programa se vrši izvođenjem, uz uporabu ispitnih podataka, te analizom rezultata obrade. Testiranje i ispravljanje grešaka se mora obavljati redoslijedom kojim su moduli kodirani, uobičajeno sa vrha prema dolje. Cilj testiranja na greške je utvrđivanje grešaka, odnosno nedostataka unutar programa. Način provjere može biti strukturalni i funkcionalni. Kod strukturalnog načina provjere se provjerava kako cjelina radi. Probni slučajevi se izvode uvidom u programski kôd (inspekcija koda). Ovu provjeru provode programeri. Funkcionalni način provjere provjerava što cjelina radi, to jest da li zadovoljava postavljene zahtjeve. Probni slučajevi se izvode iz specifikacija funkcija. Ovu provjeru provodi osoblje proizvođača 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 utvrđuje da je napravljen pravi proizvod, koji odgovara korisniku i namjeni.

12.5.2. Vrste testiranja sistema Testiranje ostataka je testiranje upravljačkih struktura i vrijednosti sadržanih u kodu. Vrši se ispitivanje pojedinačnih cjelina (proceduralno programiranje). Nedovršeni elementi mogu se simulirati (ostaci i pogonski moduli). Testiranje komponenti je ispitivanje pojedinih programskih komponenti. Ispitivanje provodi programer komponente (postoje iznimke za kritične sisteme). Testovi proizilaze iz iskustva te osobe. Integraciona provjera je ispitivanje grupa komponenti koje integrisane čine cijeli sistem ili neki njegov dio. Vrše se slijedeće provjere: test korisničkog interfejsa (provjera svake funkcije interfejsa), test slučajeva korištenja (provjera svakog pojedinačnog slučaja), test toka podataka (provjera procesa korak-po-korak) i test interfejsa sistema (provjera prenosa podataka između 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. Vrše se slijedeće provjere: funkcionalno testiranje (gdje se vrši


210

provjera funkcionalnosti prema zahtjevima korisnika), testiranje performansi i testiranje dokumentacije (tj. provjera korisničke dokumentacije i primjera). Testiranje performansi (odnosno provjeru nefunkcionalnih zahtjeva) sačinjavaju: • • • • •

stress - verifikacija velikog broja simultanih pristupa, volume - test na količinu podataka, složenost algoritama, fragmentaciju, ..., security - provjera prava pristupa, timing - brzina odziva, recovery - mogućnost oporavka pri “forsiranom” padu sistema.

Test prihvatljivosti je test sistema kojim se dokazuje da proizvod zadovoljava korisničke zahtjeve i potrebe organizacije, te uslove pod kojima ga je naručilac spreman preuzeti. To je sveobuhvatni i konačni test sa stvarnim podacima. Alfa-testiranje je verifikaciono testiranje. Sastoji se od probne upotrebe sistema, a provode ga korisnici kod izvođača. Vrši se simulacija stvarnog okruženja, traženje grešaka i propusta. Beta-testiranje je validaciono testiranje. Testiranje provode korisnici kod sebe, bez prisustva izvođača. Provjera se vrši u stvarnim uslovima. Provjeravaju se performanse sistema, vršna opterećenja, upotrebljivost i lakoća 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 sadrži: 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, ponašanje programa (npr. neregularni završetak rada, neispravni podaci, pogrešan prikaz podataka), a po potrebi i očekivani rezultat. Preporuke za provjeru, u kojoj učestvuju poznati korisnici, su slijedeće. Provjeru obavlja ogledna skupina krajnjih korisnika koja, koristeći napravljena rješenja, nastoji obaviti svoje svakodnevne poslove. Po želji krajnji korisnik dodatno iznosi svoja zapažanja ili prijedloge. Primjedbe se prikupljaju dnevno, a greške uklanjaju po mogućnosti istog dana. Prikupljeni dodatni zahtjevi se procjenjuju, te se izrađuje 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 sačinjavaju: 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. Korisničko uputstvo (User's manual). Korisnička dokumentacija mora pružiti pomoć korisnicima pri upotrebi sistema i mora biti prilagođena korisnicima različitog iskustva. Tu spadaju: upute za upotrebu (user manual), instalacioni priručnik (installations manual), detaljni priručnik (reference manual), upute za vježbu (training guide, tutorial), podsjetnici ili kratke upute (quick reference guide, pocket guide, cue cards). Broj, vrsta i obim dokumenata zavisi o aplikaciji. Tehnička dokumentacija je namijenjena tehničkom osoblju. Potrebna je za razumijevanje, izradu i održavanje sistema. Omogućava upravljanje projektom i konfiguracijom sistema, budući da sadrži plan razvoja, specifikaciju dizajna, opis arhitekture sistema i specifikaciju interfejsa prema drugim sistemima. Pored navedenog, tehničku dokumentaciju sačinjavaju: programska dokumentacija (izvorni kôd, opis baze podataka, probni podaci i rezultati provjere, dnevnik promjena i programski priručnici), instalacioni priručnik (odnosno opis instalacione procedure) i upute za rukovanje i održavanje (opis procedura za pokretanje/zaustavljanje - startup/shutdown, opis izrade rezervnih kopija i vraćanja podataka - backup, restore, opis postupka ponovnog pokretanja i oporavka - restart, recovery).

212


12.6.2. Preporuke za izradu dokumentacije Izrada dokumentacije zahtijeva angažovanje i do nekoliko sati (3) po stranici. Mora biti planirana i započeti izradu dovoljno rano, prije završetka kodiranja i testiranja. Prije objavljivanja dokumentacije treba provjeriti/dokazati da odgovara namjeni. Prilikom izrade treba izbjegavati ponavljanja i neodređenosti i koristiti standardizovane dokumente. Između ostalog, dobra dokumentacija mora biti napisana sa gledišta č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 sadržaj ekranske forme (npr. redoslijed popunjavanja šifarnika, određivanje lozinki i prava pristupa, radne procedure). Takođe, mora bilježiti načela (argumente odluka), odražavati stvarno stanje opreme u primjeni (tj. biti ažurna) i uključivati rječnik korištenih izraza. Nepostojanje dokumentacije može biti razlog za prestanak korištenja aplikacija, naročito kada autor ili autori prestanu biti raspoloživi. Preporučuje se odvojeno čuvati odgovarajuću varijantu programske opreme (alata) kojom je proizvod napravljen.


213

13. Logičko projektovanje programa i programski jezici 13.1. Dijagram toka (blok dijagram, algoritam) Dijagrami toka (Flowcharts) omogućavaju grafički prikaz sistema (system flowchart) i predstavljaju zamjenu za fizičke DTP, kao i grafički prikaz programa (program flowchart). Osim toga, dijagrami toka su usredotočeni na akcije koje sistem/program mora obaviti. Specifikaciju predstavlja skup simbola koji opisuju upravljački tok. Za opis akcije ili odluke unutar simbola može se primijeniti bilo koja notacija, npr. pseudokod ili prirodni jezik. Nedostaci dijagrama toka su veliki skup simbola, veliki i neprikladni dijagrami, nedostatak formalizma, nemogućnost 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:

POČETAK Pripremne radnje Spojište tokova

Učitav.podat. Obrada podat.

Izlaz podat. NE

Kontrola izlaza iz petlje

Kraj obrade DA Završne radnje KRAJ

Slika 13.2. Primjer opšteg oblika dijagrama toka. Primjer 3: Prodaja

Slika 13.3. Dijagram toka Prodaja (generator dijagrama toka Visio).


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).

215


216

13.2. Strukturirani prirodni jezik (pseudokod) Pseudokod je srodan višim programskim jezicima, ali ne sadrži formalna pravila jezičke sintakse ni jednog od njih. Predstavlja način opisa logičkog toka algoritma programa. Pseudokod je prilagođen strukturiranom načinu programiranja i otuda potiču njegova osnovna sintaksna pravila. Za potrebe ovog teksta, prilagođen je našem govornom području. Pri definisanju sintakse i semantike ovog pseudokoda, pošlo se od slijedećih zahtjeva: • svaki element pseudokoda mora biti jednoznačno definisan, • elementi pseudokoda moraju biti razumljivi čitaocu, koji poznaje osnovna pravila pisanja algoritma, • elementi algoritma ne smiju posjedovati specifičnosti nekog programskog jezika, koji se ne mogu lako izraziti putem naredbi nekog drugog programskog jezika opšte namjene, • elementi pseudokoda moraju biti tako definisani da se mogu lako prevesti na većinu programskih jezika opšte namjene, • pseudokod mora posjedovati naredbe za rad sa datotekama na eksternom memorijskom uređaju. Sintaksa i semantika osnovnih elemenata i osnovnih struktura pseudokoda, kao i pravila za konstruisanje procesa i naredbe pseudokoda, specifične za rad sa datotekama, su opisani u nastavku teksta..

13.2.1. Osnovni elementi pseudokoda Osnovne elemente pseudokoda sačinjavaju: • • • • •

promjenljive, glagoli, operator dodjele, aritmetički i algebarski operatori, komentari.

Promjenljive i njihovi tipovi se u pseudokodu posebno ne deklarišu. Ako to ne proizilazi iz njihovog naziva, opisuju se u okviru komentara. Pišu se „italic“ slovima, nisu ograničene dužinom, a ako se sastoji od više riječi povezuju se podcrtom („_“), npr. p. Glagoli: Svaka imperativna naredba pseudokoda počinje glagolom. Taj glagol se piše 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. Aritmetički i algebarski operatori: Aritmetički, skupovni, logički i relacioni operatori se, u naredbama pseudokoda, koriste na uobičajen način. Komentar u pseudokodu ima slijedeću sintaksu: ( * tekst komentara * ), gdje „( *“ označava početak, a „ *)“ kraj komentara. Sam tekst komentara je niz alfanumeričkih znakova, koji ne smije sadržavati oznake za početak 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 načina pisanja algoritma, predstavljaju i osnovne strukture pseudokoda. To su sekvenca (linijska struktura), selekcija (razgranata struktura) i iteracija (ciklična 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 piše u novom redu i počinje od iste kolone. Sekvencom se opisuje niz aktivnosti, koje se bezuslovno odvijaju jedna za drugom. Redoslijed izvršavanja aktivnosti je određen redoslijedom njihovog navođenja u pseudokodu. Na slici 13.6 je prikazana sekvenca, od tri aktivnosti u pseudokodu, i odgovarajući blok dijagram. Svaka aktivnost počinje glagolom u imperativnom obliku (IZVRŠI), mada aktivnost može predstavljati i svaku od osnovnih struktura pseudokoda ili pak strukturu nad skupom osnovnih struktura. U svakom slučaju, izvršenju aktivnosti C mora prethoditi izvršenje aktivnosti B, a izvršenju aktivnosti B mora prethoditi izvršenje aktivnosti A.


218

PSEUDOKOD:

BLOK DIJAGRAM A

IZVRŠI A IZVRŠI B IZVRŠI C

B C

Slika 13.6. Pseudokod i blok dijagram sekvence. Selekcija je osnovna struktura koja služi za prikaz uslovnog grananja u algoritmima. Semantika ove strukture se može opisati na slijedeći način. Ako je zadovoljen uslov P, tada se izvršava aktivnost A, inače se izvršava aktivnost B. Na slici 13.7 je prikazana sintaksa pseudokoda i blok dijagram selekcije. U sintaksi selekcije se za svako AKO JE uslov TADA, piše INAČE i jedno KRAJ AKO, počevši od iste kolone kao AKO . PSEUDOKOD:

BLOK DIJAGRAM

AKO JE P TADA IZVRŠI A INAČE IZVRŠI B KRAJ AKO

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 izvršenja selekcije: AKO JE a ≤ 0 TADA POSTAVI a ← a+1 INAČE POSTAVI a ← a-1 KRAJ AKO


219

Da je inicijalna vrijednost promjenljive a bila 1, nakon izvršenja selekcije bi imala vrijednost a = 0. Iteracija – RADI DOK JE je algoritamska struktura u kojoj se aktivnost A ponovljeno izvršava tako dugo dok je postavljeni uslov P zadovoljen. Svaka iteracija ima svoje ime. Počinje glagolom RADI, a završava se frazom KRAJ RADI, koja se piše od iste kolone kao i RADI. Kada je riječ o iteraciji tipa RADI DOK JE, za nju je specifično da ukoliko uslov P nije zadovoljen kod prvog ispitivanja, aktivnost A se uopšte ne izvodi. Na slici 13.8 je prikazana sintaksa pseudokoda i blok dijagram iteracije tipa RADI DOK JE.

PSEUDOKOD:

BLOK DIJAGRAM

RADI naziv_radi DOK JE P IZVRŠI A KRAJ RADI naziv_radi

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 izvršava 9 puta. Da je, inicijalno , bilo n ≤ 1, tada se oduzimanje ni jedan put ne bi izvršilo. Iteracija – RADI DOK NE BUDE je iteracija kod koje se, za razliku od iteracije tipa RADI DOK JE, aktivnost A izvršava prije ispitivanja postavljenog uslova P. Aktivnost A će se sigurno izvršiti bar jedan put, bez obzira na ispunjenje uslova P. Aktivnost A se izvršava 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:

RADI naziv_radi DOK NE BUDE P IZVRŠI A KRAJ RADI naziv_radi

BLOK DIJAGRAM

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 izvršava 9 puta. Da je, inicijalno bilo n ≤ 1, tada uslov za izlazak iz iteracije ne bi nikada bio zadovoljen. Moguće oznake za pisanje pseudokoda: Abc abc Abc := # " s v M IvI & Si I&I

naziv algoritma rezervisana riječ pseudokoda za opis algoritama ugrađena ili trivijalna funkcija (procedura) pridruživanje zamjena vrijednosti komentar konstanta ili parametar skalar vektor matrica nula-vektor modul (dužina) vektora skup element skupa kardinalni broj skupa prazan skup


221

13.3. Akcioni dijagram Akcioni dijagram (Action Diagram) je formalizovana mješavina strukturiranog prirodnog jezika i pseudokoda. Na slici 13.10 je prikazan primjer prikazivanja procesa pomoću 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 odlučivanja Stablo odlučivanja (Decision Tree) je binarno stablo u kojem svaki nezavršni č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 odlučivanja je prikladno za opis složenih grananja u postupku odlučivanja. Lako je razumljivo i predstavlja dobro sredstvo za komunikaciju sa korisnicima. Primjer: Posjeta zoološkom vrtu Životinje. • • • •

ulaz za djecu do 3 godine je besplatan, omladina do 18 godina plaća polovinu pune cijene ulaznice, djeca ispod 12 godina u pratnji odrase osobe plaćaju četvrtinu cijene, osobe iznad 18 godina plaćaju punu cijenu, osim ako su studenti ili penzioneri, koji plaćaju polovinu cijene, • posjetioci u grupi imaju 10% popusta na punu cijenu, • studentski popust ne vrijedi vikendom.

Stablo odlučivanja za navedeni primjer izgleda kao na slici 13.12.

Slika 13.12. Primjer stabla odlučivanja za zoološki vrt Životinje. Može se uspostaviti veza između stabla odlučivanja i pseudokoda. Na slici 13.13 je prikazano stablo odlučivanja za Videoteku i na slici 13.14 pripadajući pseudokod.


Kategorija filma:

Ukupni broj filmova koje član želi iznajmiti:

Hit film

bilo koliko

Politika iznajmljivanja filmova: Običan film

223

Rok za vraćanje posuđenog filma:

1 dan

manje od 3

1 dan

3-6

3 dana

više od 6

3 dana

Slika 13.13. Primjer stabla odlučivanja 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) inače ⏐ ako je ukupni broj filmova manji od 3 tada ⏐ ⏐ rok iznajmljivanja = 1 dan ⏐ ⏐ cijena = cijena + osnovna cijena filma ⏐ inače ⏐ ⏐ ako je ukupni broj filmova manji od 7 ⏐ ⏐ ⏐ rok iznajmljivanja = 3 dana ⏐ ⏐ inače ⏐ ⏐ ⏐ rok iznajmljivanja = 7 dana ⏐ ⏐ ako film nije treći po redu (svaki treći obični film je besplatan) tada ⏐ ⏐ ⏐ cijena = cijena + osnovna cijena filma

Slika 13.14. Primjer pseudokoda za Videoteku.


224

13.5. Tabele odlučivanja Tabele odlučivanja (Decision Tables) predstavljaju tabelarni prikaz preslikavanja skupa ulaznih uslova u skup izlaznih akcija. Posjeduju relativno jednostavne uslove, kao i ograničene skupove mogućih odgovora, npr. da/ne ili nisko/srednje/visoko. Neki CASE alati, koji podržavaju ovaj način izrade specifikacija, generišu programski kôd različitih jezika (npr. C, Pascal, Fortran i Basic). Predstavljaju dobro sredstvo za opis poslovnog odlučivanja. Primjer: Proširena tabela odlučivanja za zoološki vrt Životinje. Tabela 13.1. Uslovi (condition stub) Dob Pratnja Student Vikend Grupa

Ispunjenost uslova (condition entries) <3

3-12 D

3-12 N

Akcije (action stub) Slobodan ulaz Četvrtina cijene Polovina cijene 90% cijene Puna cijena

12-18

>18

>18

>18

>18

>18

D N

D D D

D D N

N

N

D

N

PEN

Izbor akcije (action entries) X X X

X

X

X X

X X

X

13.5.1. Pravila izrade tabela odlučivanja Prilikom izrade tabela odlučivanja preporučuje se koristiti slijedeća pravila: 1. Logika odlučivanja treba da bude nezavisna o tome kojim redoslijedom su uslovi napisani; 2. Međutim, nije uvijek svejedno kojim su redoslijedom napisane akcije; 3. Potrebno je izbjegavati eventualno dupliranje izraza i značenja; 4. U gornjem dijelu tabele treba pokušati rasporediti redove tako da oni redovi koji sadrže više potvrda uslova (znak Y) budu što više, dok oni koji sadrže oznake "-" budu niže; 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: Proširena tabela odlučivanja za Videoteku. Tabela 13.2. Politika iznajmljivanja filmova hit film

Y

N

N

Y

N

N

Y

N

ukupni broj filmova veći od 6

Y

Y

Y

N

N

N

N

N

ukupni broj filmova 3 - 6

-

-

-

Y

Y

Y

N

N

ukupni broj filmova manji od 3

-

-

-

-

-

-

Y

Y

film je treći po redu

-

Y

N

-

Y

N

-

-

X

X X

X X

X

Akcije rok iznajmljivanja je 7 dana rok iznajmljivanja je 3 dana rok iznajmljivanja je 1 dan

X

cijena = cijena + (osn. cijena filma x 1,5)

X

cijena = cijena + osnovna cijena filma

X X X

X X

X

13.6. Struktogram Struktogram (Nassi-Shneiderman Chart) je grafički prikaz programskih struktura. Znatno je prikladniji od dijagrama toka. Neprikladan je za ručnu izradu, naročito 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 inženjering programa pisanih u C programskom jeziku i za generisanje koda. Na slici 13.16 je prikazan Nassi-Shneiderman dijagram urađen pomoću 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 treće generacije Jezici treće generacije (eng. 3rd generation languages - 3GL) su jezici visokog nivoa (HLL - High Level Languages), odnosno proceduralno usmjereni programski jezici. Može se izvršiti podjela programskih jezika po namjeni. Jezici za numeričke i naučne probleme: • FORTRAN (FORmula TRANslator), prvi rašireniji jezik za rješavanje numeričkih problema, • ALGOL (ALGOrithmic Language), jezik pogodan za rješavanje numeričkih i logičkih problema, • BASIC (Beginner's All-Purpose Symbolic Instruction Code), prvobitno jednostavan interpretator za interaktivno rješavanje numeričkih 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 područja vještačke inteligencije. Jezik vještačke inteligencije: • PROLOG (PROgramming in LOGic), namjenjen logičkom programiranju. Višenamjenski jezici: • PL/I, pogodan za numeričko-inženjerske 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 može efikasno ugraditi na većinu računara, a koji će biti pogodan za učenje programiranja kao logičke i sistematske discipline, • ADA, pokušaj postavljanja standarda za jezik integrisanih računarskih sistema (kontrola industrijskih pogona, vazduhoplova ili bolničkih sistema), • Modula-2 i Oberon, proširenje Pascal-a podrškom sistemskom programiranju, konceptom procesa i modula koji međusobno komuniciraju. Većina današnjih 3GL su višenamjenski jezici.

13.7.2. Programski jezici četvrte generacije Jezici četvrte generacije (eng. 4th generation languages - 4GL) su nastali krajem '70-ih i početkom '80-ih godina. Neki 4GL čini skup raznorodnih pomagala povezanih u cjelinu sa okruženjem 4. generacije (4th Generation Environment). 4GL naredbe integrišu naredbe jezika visokog nivoa, te predstavljaju jezike vrlo visokog nivoa (Very High Level Languages). Programski jezici četvrte generacije predstavljaju jezike posebne namjene, specijalizovane za određene 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. Najčešće 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 rječniku 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 slijedećim relacionim bazama podataka: DB2, Oracle, Informix, MS SQL Server, MS Access i drugim. Matrični kalkulatori (Spreadsheet) su tabele organizovane kao mreža redova i kolona. Elementi tabele su: konstante, izrazi (formule), grafički znakovi i objekti. Elementi jezika su aritmetičke i agregatne funkcije: SUM, COUNT, AVERAGE, MIN, MAX … , logički izrazi: OR, IF, AND, NOT, matematičke funkcije: SIN, COS, TAN, ASIN, EXP, SQRT, LN, LOG, statističke funkcije (npr. očekivanje) i finansijske funkcije (npr. kamatni račun). Nakon izračunavanja vrijednosti formula automatski slijedi promjena podataka, npr. D31=ROUND(SUM(D1:D30) * 0.65;-1). Integrisana programska podrška (Integrated Software) objedinjuje matrični kalkulator, obradu teksta i grafički 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 donošenju odluka (problemi tipa "šta ako"). Grafički orijentisani jezici (računarska grafika) služe za sintezu slika pomoću računara (dijagrami, animacija, digitalizacija). CAD/CAM (Computer Aided Design/Computer Aided Manufacturing) su računarom podržano projektovanje i računarom podržana proizvodnja. Ovdje se još mogu svrstati simulatori, programski paketi za prenos slika, … . Geografski IS (GIS - Geographic Information System) uključuju podatke o geometriji, koncept više slojeva, kao i koncept objekata. Programi i jezici za prenos podataka se sreću u komunikacionim sistemima (modem, telefax, elektronska pošta ... ), kao i kod rada u mreži računara (emulatori terminala, programi za prenos podataka, ... ). Programska proširenja operativnih sistema (skeleti, ljuske) predstavljaju najrašireniji pristup nadogradnje OS (npr. Unix-a). Nad istim jezgrom (kernel), mogu se


229

koristiti različiti 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 izvršene naredbe (if test prog then ... ), • redoslijedno izvođenje više programa (cd dir, ls, cd, ... ), • obrada u pozadini (background processing) (prog &, jobs, fg), • usmjeravanje ulaza i izlaza (prog > output.dat, prog < input.dat), • ulančavanje 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 proširenja OS se zasnivaju na primjeni računarske grafike, podržavanju 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 određuje KAKO se određena akcija obavlja, npr. "otvori datoteku, ako nije EOF pomakni se, ... , zatvori datoteku" i sl. Neproceduralni jezici sadrže niz naredbi koji određuje ŠTA treba učiniti, npr. "dohvati podatke … koji zadovoljavaju uslov … ". Tipične 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 izvještaje (selekcija, grupisanje, sortiranje, agregatne funkcije, ... ). Uz neproceduralne, mnogi 4GL raspolažu proceduralnim naredbama da bi se omogućila ugradnja proceduralnih rješenja. 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 rječniku 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 slijedećeg 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


231

END IF ... END INPUT

Primjer 7: Izvještaj (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 izvještaja. Pojedina 4GL naredba zamjenjuje do nekoliko hiljada 3GL-a naredbi. Prave se kraće programske liste, jezgrovitiji i čitljiviji programski kod. Kodiranje je sa manje grešaka, a ujedno je olakšano otklanjanje grešaka. Sličnost programa strukturiranom govornom jeziku pojednostavnjenje izradu programske dokumentacije. Izradi programske opreme se pristupa u ranoj fazi razvoja, koristeći prototipski razvoj. Bitno je ubrzana izrada programa sa neproceduralnom sintaksom i generatorima koda. Povećanje efikasnosti je od 6 do 60 puta (ne i skraćenje vremena izrade!). Povećanje efikasnosti se postiže smanjenjem broja naredbi i pomoću interne optimizacije. Ista aplikacija napisana u jeziku SQL može na istom računaru biti od 5 do 20 puta brža od odgovarajuće aplikacije napisane u nekom 3GL, kao što su COBOL ili FORTRAN. Prednost se gubi u slučajevima kada se radi o aplikacijama koje uključuju rješenja proceduralnog tipa, odnosno rješenja dobijena povezivanjem na 3GL, npr. C.

232


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


233

14. Organizacija i upravljanje projektom 14.1. Generički modeli organizacije Generičke modele organizacije sačinjavaju: projektna, funkcionalna i matrična organizacija. Projektnu organizaciju predstavlja osoblje organizirano unutar/oko projekta. Prednosti ove organizacije su brže odlučivanje, minimiziranje potreba susreta između č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 podržavati veći broj različitih projekata. Prednosti su u potpomaganju specijalizacije (povećanju broja specijalista), a nedostaci su u smanjenju osjećaja pripadnosti projektu, tj. koheziji projekta. Matrična organizacija je u osnovi funkcionalna, osoblje izmiješano u različitim projektima. Prednosti su u tome što projektna komponenta pogoduje uspješnosti projekta, a funkcionalna komponenta pogoduje povećanju specijalizacije. Nedostatak je mogući sukob interesa.

14.2. Organizacija i timski rad Timski rad (teamwork). Ekipa je "samoupravljačka" jedinica, koja posluje u duhu saradnje svojih članova, njihove koordinacije i njima unaprijed poznatih procedura. Prednosti timskog rada su kvalitetnije donošenje odluka, motivacija članova, inovativnost, sinergija i slično. Djelovanje

Uspješnost tima Formiranje „Jurišanje“

Normiranje

Energija tima Slika 14.1. Uticaj karakteristika tima na njegovu uspješnost.


234

Razvoj tima definišu slijedeće karakteristike: formiranje (Forming), koje podrazumjeva ljubaznost, nesklonost iznošenju stavova, prepuštanje vođenju, "jurišanje" (Storming), koje se ogleda u neslozi, sukobu ličnosti, grupašenju /stranačkoj pripadnosti, pomanjkanju kvalitetne komunikacije, neuspješnosti dogovaranja, normiranje (Norming), odnosno uviđanje dobrih strana zajedničkog rada, međusobno uvažavanje i predstavljanje (Performing), djelovanje, tj. povezivanje u efikasnu operativnu grupu. Uticaj karakteristika tima na njegovu uspješnost prikazan je slikom 14.1.

14.3. Modeli timova Klasičnu organizaciju tima (Chief Programmer Team) sačinjavaju: glavni programer (chief programmer), rezervni programer (backup programmer), mlađi (junior) programer i administrator. Glavni programer objedinjuje znanje i odlučivanje ekipe. Mora istovremeno biti dobar (vrhunski) programer i rukovodilac. U poboljšanoj (revidiranoj) organizaciji ima ulogu rukovodioca ekipe. Rezervni programer služi kao zamjena za nekog od mlađih programera. U poboljšanoj (revidiranoj) organizaciji ima ulogu pomoćnika rukovodioca (slika 14.2).

Administrator

Glavni programmer (rukovodilac)

*

O Rezervni programmer (pomoćnik)

Programer

Slika 14.2. Prikaz klasične organizacije tima. Modernu organizaciju tima (4GL tim) sačinjavaju izvršioci slijedećih radnih zadataka: rukovodilac projekta, odnosno viši sistem analitičar, saradnju sa korisnikom ostvaruje poslovni analitičar, konceptualno i logičko oblikovanje obavlja sistem analitičar, a isporuku sistema/aplikacija vrši poslovni analitičar. Nabavka i pogon opreme je radni zadatak sistem inženjera za računare, mrežni servisi su zaduženje sistem inženjera za komunikacije, programsko inženjerstvo obavlja programeranalitičar, dok izrada dokumentacije je posao razvojnog tima. Pomoćno osoblje se sastoji od administrativnog koordinatora, tehničara i činovnika. Neki stvarni poslovni sistemi koriste gornju podjelu za opis radnih mjesta.


235

Elastični model tima ima oblik: upravnik tima, koji upravlja osobljem (plate, režije, ... ), rukovodilac tima, upravlja razvojem (organizacija posla), projektant (analitičar - programer) je zadužen za analizu, oblikovanje i izvedbu, a programer (programer aplikacija) vrši kodiranje i testiranje aplikacija. Administrator baze podataka je zadužen za BP, a sistem inženjer(i) obavlja(ju) održavanje mreže i računara. Sastav tima odgovara poslovima koje treba obaviti. Raspodjela uloga konkretnim članovima, kao i broj članova pojedine kategorije, zavisi o konkretnom projektu i raspoloživosti radnika. Primjer: Ulogu upravnika tima i rukovodioca tima može imati ista osoba. Tim može imati više programera. Uloga administratora BP i sistem inženjera može se dodijeliti istoj osobi. Ovakav model tima se može primijeniti bez obzira na moguću različitu sistematizaciju radnih mjesta u nekom poslovnom sistemu.

14.4. Organizacija velikih projekata Upravnik ili rukovodilac projekta (project manager, project leader) upravlja projektom. Posao može da obavlja više ekipa. Upravnik je nadređen upravnicima/ rukovodiocima timova. Tim može 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 rukovođenje ostalim članovima tima, dok rukovodilac tima se bavi tehničkim aspektima aktivnosti koje se odnose na izradu i/ili uvođenje aplikacija/podsistema IS. Upravnik projekta Upravnik Rukovodilac tima tima Članovi tima

Slika 14.3. Grafički 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 postići prava funkcionalnost, na vrijeme i uz minimalne troškove. Uključuje različite aspekte: • plan – Koje aktivnosti i u kojem vremenskom razdoblju treba obaviti? • sredstva/resursi – Koji su kadrovi (osoblje) i oprema potrebni? • organizacija – Koji je odnos pojedinih resursa? • raspored – Koji je redoslijed aktivnosti? • upravljanje – Kako usmjeriti i motivisati izvođače (tim)? • nadzor – Poštuje li se plan? Elementi plana su: veličina projekta, odnosno funkcionalne tačke (broj linija koda), napor izrade (određivanje iznosa čovjek-mjeseci) i vrijeme izrade (u mjesecima). Izgradnja IS je posao koji se, unatoč posebnostima, obavlja kao neki drugi inženjerski 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) sačinjavaju: određivanje aktivnosti, procjena i dodjeljivanje sredstava potrebnih za pojedinu aktivnost, procjena trajanja pojedinih aktivnosti, određivanje zavisnosti između aktivnosti i izrada vremenskog rasporeda za projekat. Upravljanje (nadzor) sadrži: određivanje postupka izvještavanja o napretku projekta, praćenje napretka redovnim revizijama, preraspodjelu sredstava i aktivnosti u skladu sa događajima, kao i ažuriranje vremenskog rasporeda.

14.6. Planiranje projekata Zašto planirati? Duhoviti odgovor na ovo pitanje glasi: ako nešto može poći pogrešno, poći će pogrešno 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 nešto što će se zaista dogoditi. Plan je najbolja procjena, zasnovana na pretpostavkama i iskustvu. Elementi plana su aktivnosti, ključni događaji, resursi (sredstva), troškovi ... . Programerski paradoks [Brooks, 1982.]. Nakon što je odgovarajući broj osoba pridružen nekom zadatku, dodavanje osoblja usporava razvoj, umjesto da ga ubrza.


237

Složeni projekti zahtijevaju velike ekipe. Najbolja strategija je podijeliti projekt u niz manjih projekata (podprojekata) koji se mogu nezavisno obaviti. Izrada plana sadrži slijedeće aktivnosti: utvrđivanje ključnih aktivnosti i događaja, određivanje vremenskih redoslijeda aktivnosti i događaja, kao i utvrđivanje potrebnih sredstva. Potrebno je racionalizovati pripadajuće troškove, povezati pojedine podprojekte/poslove u glavni projekat, iterativno razraditi plan i revidirati plan u skladu sa postojećim 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 sadržaja plana projekta, definisanje skupa provjera i izvještaja koji se koriste za nadzor realizacije.

14.7. Tehnike za vremensko planiranje Štapićasti/stupčasti dijagrami - Gantogrami (Gantt Charts) omogućavaju prikaz aktivnosti linijama. Dužina linije je srazmjerna vremenu obavljanja aktivnosti. Gantogram prikazuje predviđeni početak i kraj aktivnosi, njihovu međusobnu zavisnost te odgovornost za izvođenje aktivnosti. Naglašava vremensko preklapanje aktivnosti, slika 14.4. May 1996

Slika 14.4. Primjer gantograma. Mrežni plan - PERT/CPM (Program Evaluation Review Technique/Critical Path Method) prikazuje vremensku predstavu aktivnosti i njihovih uslovljenosti. Vidljivo je


238

koje aktivnosti se mogu vršiti paralelno, a koje u nizu, ukoliko zavise o ranijim aktivnostima. Naglašava kritični put projekta, slika 14.5.

Slika 14.5. Primjer mrežnog plana – PERT/CPM. Upravljanje ključnim događajima se vrši tabelarnim prikazima planiranih aktivnosti i trenutnog statusa njihovog izvršenja. U određenim vremenskim trenutcima se razmatra stepen dovršenosti neke/nekih projektnih aktivnosti. Ključni događaj je obično kraj neke faze ili aktivnosti, kao npr. očekuje se da faza ili aktivnost bude gotova, druge aktivnosti započinju nakon što se to ostvari ili pomak ključnog događaja ima za posljedicu vremenski preraspored.

14.8. Izrada plana Definisanje zadataka i njihove međuzavisnosti biće objašnjeni preko slijedećeg primjera (tabela 14.1). Zadatak T3 (npr. ugradnja komponenti) zavisi o zadatku T1 (npr. oblikovanje komponenti). Oblikovanje mora biti završeno 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 mrežnog plana na osnovu definisanih zadataka i zavisnosti (slika 14.6). Aktivna mreža se čita sa desna na lijevo. Sve aktivnosti moraju završavati u ključnim tačkama (M1, M2, M3, M4, ... ). Tek kad se uspješno pređe ključna tačka može se započeti sa slijedećom aktivnosti. Npr. zadatak T9, ne može započeti sve dok zadaci T3 i T6 nisu završeni. Dolazak na tačku M4 pokazuje da su ti zadaci završeni.

T12

Slika 14.6. Primjer dijagrama mrežnog plana. Kritični put. Minimalno vrijeme potrebno za završetak projekta se može procjenjivati prema kritičnom putu, odnosno najdužem putu na aktivnoj mreži. U navedenom primjeru to je 11 sedmica ili 55 radnih dana. (T1-T3-T9-T11-T12, slika 14.6). Prekoračenje vremenskog roka najčešće je vezano uz kritični put. Aktivnosti koje kasne, a ne leže na kritičnom putu ne bi trebale uzrokovati vremensko prekoračenje (npr. ako T8 kasni ne bi trebalo uticati na krajnji datum, jer T8 ne leži na kritičnom putu).

14.9. Prikaz plana Gantogram je alternativni način prikaza vremenskog rasporeda (slika 14.7). Neke od aktivnosti su označene i zasjenjenim linijama, što pokazuje da postoji određena fleksibilnost u datumu njihovog završavanja. Ako se aktivnost ne završi na vrijeme, kritični put neće biti ugrožen sve do završetka zasjenjene linije.


240

Slika 14.7. Primjer gantograma sa prikazom vremenskog rasporeda.

14.10. Raspodjela zadataka Štapićasti dijagram (gantogram), takođe, pokazuje razdoblje u kojima je osoblje angažirano na projektu (slika 14.8). Angažovanje ne mora biti kontinuirano. Za razmatrani primjer prikazano je tabelom 14.2. Osobe mogu raditi na drugim projektima, ići na odmor ili obavljati neke druge aktivnosti. Tabela 14.2. Zadaci T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12

Inženjer Nada Ana Nada Pero Mile Ana Igor Pero Nada Ana Pero Pero


241

Pero Nada Ana Igor Iva

Slika 14.8. Primjer vremenskog angažovanja osoblja pomoću gantograma.

14.11. Evidencija projekta Za planiranje, upravljanje, praćenje napretka, praćenje istorije projekta mogu se koristiti različiti 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. Praćenje napretka (izvršenja) projekta Upravljanje projektom podrazumjeva stalni nadzor napredovanja, šta se može prikazati slijedećim programom, napisanom pomoću pseudokoda. Postavljanje projektnih ograničenja Napraviti početnu procjenu projektnih parametara Definisanje ključnih tačaka i izvještavanje while projekt nije završen ili otkazan loop Nacrtaj vremenski raspored projekta Podijeli aktivnosti prema vremenskom rasporedu Čekaj Provjeri napredak projekta Revizija procijenjenih projektnih parametara Ažuriranje vremenskog rasporeda projekta Provjeri projektna ograničenja i izvještaje If (povećanje problema) then Ponovni tehnički pregled i moguća revizija end if end loop


243

Na slici 14.11 je prikazan primjer dijagrama za praćenje napretka projekta, dok je na slici 14.12 prikazan primjer tabele za evidentiranje napretka. P1

prilagođavanje plana D1 plan

projekta

P2

O rukovodilac projekta

praćenje napretka

a

evidencija

član ekipe

D2 radnih sati

Slika 14.11. Primjer dijagrama za praćenje napretka. Zadatak

Izvršioci

Planirani početak

Planirani završetak

Prioritet

Planirano trajanje

Stvarno trajanje

Status

% ispunjenja

Stvarni završetak

Kašnjenje

Komentar

Slika 14.12. Primjer tabele za evidentiranje napretka.

14.13. Preporuke za planiranje poslova Planiranje poslova: Planovi moraju biti ažurni, tj. prilagođeni stvarnom stanju. Izbjegavati detaljno planiranje poslova koji slijede u daljoj budućnosti. Takve je dovoljno predvidjeti i najaviti, a pažnju usmjeriti na probleme koji se trenutno rješavaju. Planovi trebaju biti što kraći, kako se vrijeme ne bi trošilo na detaljiziranje koje zbog moguće promjene stanja ionako neće biti istinito. Konkretno razdoblje za koje se radi plan može varirati u zavisnosti o veličini projekta. Načelno je dovoljan jedan plan (i pregled realizacije) mjesečno, s tim da uključuje raspored nedjeljnih aktivnosti. Poslove i zadatke treba uravnoteženo raspodijeliti. Više pažnje treba posvetiti članovima koji zaostaju u izvršenju plana ili rješavaju složeniji problem u odnosu na ostale članove. Po potrebi treba prerasporediti postojeće poslove.

244


Komunikacija može biti: verbalna (brzo slušaj i misli, sporo i jasno govori, bilježi izrečeno), pisana (sadržaj, forma, učestalost), elektronska (E-mail, Chat, News), obavještavanje (pismenim putem, elektronskom poštom), čuvanje informacija (mrežni rječnik, FTP rječnik, web server) ili u obliku organizacije rječnika (Admin, Materijali, Projekt, Backup, Tmp, itd). Druženja moraju biti efikasna! Izbjegavati raspravu o opštepoznatim ili nevažnim 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, učesnici)! Tehnike za poboljšanje rada: Brainstorming (iznošenje ideja), izbjegavanje "jedinih" rješenja (traženje alternativa), zapisivanje odluka (zapisivanje da bi se izbjegla pogrešna tumačenja), konstruktivne povratne informacije (kritikovanje postupaka, a ne osoba), razumijevanje neuspjeha (analiza i poboljšanje svega što nije dobro), raspodjela moći i odgovornosti (ravnopravnost, izbjegavanje hijerarhije).


245

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


246

Karakteristike različitih načina uvođenja sistema u primjenu su prikazani u tabeli 15.1. Tabela 15.1. Uvođenje

Rizik

Trošak

Trajanje

neposredno paralelno ostalo

visok nizak srednji

niski (ako uspije) visok srednji

kratko (ako uspije) dugo varijabilno

15.2. Obuka korisnika IS Vrši se obuka tehničkog osoblja korisnika i krajnjih korisnika sistema. Obuka krajnjih korisnika može uključivati opštu informatičku kulturu (npr. upotreba personalnih računara), funkcije sistema i način upotrebe sistema, to jest korištenje aplikacija, ili obuku iz posebnih znanja potrebnih za obavljanje osnovne djelatnosti (npr. operaciona istraživanja, projektovanje primjenom računara i sl.). Obuka tehničkog osoblja može uključivati operativni sistem i uslužne programe, administriranje baze podataka, programske jezike i CASE alate. Redoslijed obuke je slijedeći. Prvo se obavlja obuka tehničkog osoblja koje će održavati sistem i pružati podršku krajnjim korisnicima, da bi se mogla pokrenuti primjena IS. Nakon toga treba obrazovati (niže) rukovodstvo, da bi se stekla njegova podrška 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 pomoći, prikladna dokumentacija i podrška tokom primjene. Obuku mogu obaviti radnici naručioca (npr. odjel informatike ili grupa za to odabranih i osposobljenih radnika) ili vanjski izvođači obuke.

15.3. Održavanje informacionog sistema 15.3.1. Održavanje i nadgradnja Održavanje je trajna aktivnost koja započinje odmah nakon uvođenja sistema u primjenu. Bez obzira kako je dobro sistem dizajniran, konstruisan i testiran, greške će se neizbježno pojaviti! Ispravljanje grešaka u primjeni se naziva održavanjem sistema ili održavanjem programa. Održavanje samo po sebi ne podrazumijeva ugradnju poboljšanja ili novih mogućnosti, ali se ona uobičajeno provode.


247

Tokom primjene i održavanja obavlja se analiza dodatnih zahtjeva, planiranje i priprema aktivnosti koje slijede, te tako započinje novi ciklus razvoja.

15.3.2. Održavanje - servisiranje sistema Preventivno održavanje sistema podrazumijeva zaštitu od mogućih problema. Potrebno je vršiti redovnu izradu sigurnosnih kopija (backup). Bekap se obavlja periodično (dnevno, sedmično, mjesečno). Pod korektivnim održavanjem se podrazumijeva popravka nakon što se problem pojavio. Vrši se vraćanje podataka iz sigurnosne kopije (restore) ili uklanjanje uzroka greške (ispravljanje programa). Adaptivno održavanje je prilagođavanje funkcionalnosti (načina posluživanja), prilagođavanja strukture (promjene strukture podataka) ili poboljšanje performansi (optimizacija programa). Perfektivno održavanje je nadgradnja sistema da bi se riješili novi problemi ili ugradnja novih mogućnosti.

15.3.3. Uklanjanje grešaka i izmjene programa Definicija i validacija problema podrazumjeva uočavanje uzroka grešaka u primjeni (bugova), odnosno problem reprodukcije greške, problem različitog tumačenja greške koje nastaje uslijed nerazumijevanja ili pogrešnog korištenja programa. Nepostojanje funkcije čija ugradnja nije bila planirana nije bug. Ocjenjivanje sposobnosti. Održavanje može imati neželjene popratne učinke 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 različite verzije u primjeni kod različitih korisnika. Neophodna je mogućnost povratka na prethodnu verziju, ako je ta bila bolja. Takođe je potrebno regresivno testiranje, tj. ponavljanje svih testova da bi se provjerilo da izmjene nisu uzrokovale nove greške, kao i ažuriranje dokumentacije.

15.4. Poboljšanje sistema i reinženjerstvo Poboljšanje sistema je dorada i nadgradnja sistema prema novim zahtjevima, analiza novih zahtjeva i povratak u odgovarajuću fazu (analiza, dizajn, izrada). Većina

248


novih zahtjeva uzrokovana je promjenama u poslovanju, potrebama za dodatnim informacijama ili novim idejama (željama korisnika). Reinženjerstvo. Neke aplikacije je teško održavati (npr. uslijed zastarjelosti tehnologije), a trošak održavanja pojedinih aplikacija može doseći trošak izrade novih. Reinženjerstvo je adaptacija sa ciljem smanjenja troškova održavanja, odnosno prilagođavanje većim promjenama tehnologije, ispravka sistema prije nego što dođe do mogućeg prekida u radu, kao i ispravka sistema koji će biti lakše popraviti ako dođe do prekida. Pisanje jednostavnih novih programa. Jednostavni program je onaj program koji koristi samo postojeće podatke. Primjeri takvih programa su pretraživanje i pregledanje podataka, kao i generisanje izvještaja. Ove promjene su najčešće i najsigurnije. Restukturiranje datoteka i baza podataka je promjena strukture u postojećoj bazi podataka. Prelazak na novu tehnologiju upravljanja podacima predstavlja veliki rizik. Reinženjerstvo 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. Poboljšanja i reinženjerstvo 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 određenoj tački životnog ciklusa, slika 15.1.

Slika 15.1. Konfiguracija elemenata u određenoj tački životnog ciklusa.


249

Verzije konfiguracije su slijedeće: • verzija (version) – određeno 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 određenim vremenskim intervalima, npr.v1.2, • varijanta (variant) – alternativa originalu (hardverska platforma, različiti 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.2.2

V 1.1.4.1

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., Vučković M.: Projektovanje informacionih sistema, I deo, Naučna knjiga, Beograd, 1986. 27. Lazarević B., Dizdarević P., Jovanović V.: Projektovanje informacionih sistema, II deo, Naučna 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. Poliščuk E. J.: Software četvrte generacije ORACLE, NIP "Tehnička knjiga", Beograd, 1991. 37. Poliščuk, E. J.: Baze podataka, Informatička literatura JEP (vlastito izdanje), Podgorica, 2003. 38. Poliščuk, E. J.: Informacioni sistemi (skripta), Elektrotehnički fakultet, Podgorica, 2004. 39. Poliščuk, E. J.: Ekspertni sistemi, Informatička literatura JEP (vlastito izdanje), Podgorica, 2004. 40. Poliščuk, E. J.: Multiprocesorski i distribuirani računarski sistemi (skripta), Elektrotehnički fakultet, Podgorica, 2004. 41. Poliščuk, E. J.: Projektovanje informacionih sistema pomoci CASE alata (skripta), Elektrotehnički fakultet, Podgorica, 2004. 42. Poliščuk, E. J.: Objektne baze podataka (skripta), Elektrotehnički fakultet, Podgorica, 2005. 43. Poliščuk E. J.: Prilog metodologiji razvoja sistema za podršku odlučivanju i ekspertnih sistema, (doktorska disertacija), Sveučilište u Zagrebu, 1992. 44. Poliščuk E. Jaroslav: Neproceduralni razvoj informacionih sistema, (magistarski rad), Postdiplomske studije informatike na Univerzitetu u Banja Luci, 1990.


253

45. Poliščuk E. J.: Projektovanje informacionih sistema (skripta), Elektrotehnički fakultet, Podgorica, 1998. 46. Poliščuk E. J.: Savremeni pristup razvoju informacionih sistema, PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1991. 47. Poliščuk E. J.: Informatička organizacija ili "organizacija budućnosti", PRAKSA: Jugoslovenska revija za informatiku i automatsku obradu podataka, Beograd, 1992. 48. Poliščuk E. J.: Novi pristup razvoju informacionih sistema, JISA INFO, časopis Jugoslovenskog informatičkog 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. Poliščuk E. J.: Neke osobine sistema za objektno upravljanje podacima, IV naučno - stručni skup: Informacione tehnologije - sadašnjost i budućnost, Zbornik radova sa IV naučno – stručnog skupa IT '99, Žabljak, 1999. 51. Poliščuk E. J.: Koncepti hijerarhija klasa i naslijeđivanje u objektno orijentisanom modelu podataka, VI naučno - stručni skup: Informacione tehnologije – sadašnjost i budućnost, Zbornik radova sa VI naučno – stručnog skupa IT ‘01, Žabljak, 2001. 52. Poliščuk E. J.: Neki aspekti razvoja sistema za podršku odlučivanju, III međunarodni simpozij informacijske i komunikacijske tehnologije u uredskom poslovanju '92 "OFFICE AUTOMATION", Sveučilište u Zagrebu, Zbornik radova '92 “OFFICE AUTOMATION”, Varaždin, 1992. 53. Poliščuk E. J.: Informatičko obrazovanje "inženjera budućnosti", V međunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova I, Novi Sad, 1995. 54. Poliščuk E. J.: Neki problemi korišćenja informacione tehnologije, VI međunarodna konferencija "Informatika u obrazovanju i nove informacione tehnologije", Univerzitet u Novom Sadu, Zbornik radova, Apatin, 1996. 55. Poliščuk E. J.: Koncepti objektno orijentisanog modela podataka, IX međunarodna 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. Poliščuk, 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. Poliščuk, E. J.: Adaptive Machine Reinforcement Learning, Centrum ksiazki akademickiej i naukowe, Motto.Pl-Ksiegarnia Internetowa, http://www.motto.pl/, Krakow, 2005. 62. Poliščuk, E. J.: The Machine Learning Method: Analysis of Experimental Results, Taylor & Francis Group, http://www.citeulike.org/article/84531/, London 2005. 63. Poliščuk, 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. Poliščuk 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.

PROJEKTOVANJE_INFORMACIONIH

Recommend Documents