SADRŽAJ PREDGOVOR
3
1.
OPŠTA TEORIJA SISTEMA
2.
POJAM INFORMACIONIH SISTEMA
14
3.
RAZVOJ INFORMACIONIH SISTEMA
23
3.1. 3.2. 3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.2.5. 3.3. 3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. 3.3.6. 3.4. 3.4.1. 3.4.2. 3.4.3. 3.4.4. 3.4.5. 3.4.6. 3.4.7. 3.4.8. 3.5. 3.5.1. 3.5.2. 3.5.3. 3.5.4. 4. 4.1. 4.1.1. 4.1.2. 4.1.3. 4.1.4. 4.1.5. 4.1.6. 4.2. 4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.3. 4.3.1. 4.3.2. 4.3.3. 4.3.4. 4.3.5. 4.4. 4.5. 4.5.1. 4.5.2. 4.6. 4.6.1. 4.6.2. 4.7. 4.7.1. 4.7.2. 4.8. 4.8.1. 4.8.2.
ELEKTRONSKA OBRADA PODATAKA UPRAVLJAČKI INFORMACIONI SISTEMI UPRAVLJAČKI PODSISTEM PROIZVODNJE UPRAVLJAČKI PODSISTEM MARKETINGA UPRAVLJAČKI PODSISTEM FINANSIJA UPRAVLJAČKI PODSISTEM KADROVA UPRAVLJAČKI PODSISTEM ZA TOP MENADŽERE SISTEMI ZA PODRŠKU ODLUČIVANJA POJAM SPO STRUKTURA SPO VRSTE SPO GRUPNI SPO IZGRADNJA SPO PERSPEKTIVA SPO EKSPERTNI SISTEMI POJAM EKSPERTNIH SISTEMA RAZVOJ EKSPERTNIH SISTEMA STRUKTURA EKSPERTNIH SISTEMA IZGRADNJA EKSPERTNIH SISTEMA ALATI ZA IZRADU EKSPERTNIH SISTEMA PODRUČJA PRIMJENE EKSPERTNIH SISTEMA PREDNOSTI I NEDOSTACI EKSPERTNIH SISTEMA PERSPEKTIVA EKSPERTNIH SISTEMA HS –DW – BI – CRM HS DW BI CRM PROJEKTOVANJE INFORMACIONIH SISTEMA
4
25 28 30 32 33 34 35 36 36 39 46 52 54 58 61 61 66 71 87 97 99 104 107 109 109 111 115 127 135
BAZA PODATAKA 139 BAZA PODATAKA, DBMS 139 CILJEVI BAZA PODATAKA 141 ARHITEKTURA BAZE PODATAKA 144 JEZICI ZA RAD S BAZAMA PODATAKA 146 SOFTVERSKI PAKETI ZA RAD S BAZAMA PODATAKA148 RELACIONI MODEL BAZA PODATAKA 150 METODOLOGIJA PROJEKTOVANJA IS 154 METODE RAZVOJA IS 157 IZBOR METODE RAZVOJA IS 166 UČESNICI U RAZVOJU IS 168 FAZE RAZVOJA IS 170 USPJEŠNOST PRIMJENE RAZVOJA IS 178 KONVENCIONALNA METODOLOGIJA RAZVOJA IS 184 PLANIRANJE RAZVOJA IS 186 ANALIZA I DIZAJN IS 192 IMPLEMENTACIJA IS 195 FUNKCIONISANJE I ODRŽAVANJE IS 197 VREDNOVANJE I KONTROLA IS 199 BSP METODOLGIJA RAZVOJA IS 200 STRUKTURIRANA SISTEM ANALIZA 208 DIJAGRAM TOKA PODATAKA 212 RJEČNIK PODATAKA 223 OBJEKTNO ORIJENTISANO MODELOVANJE 238 MODELIRANJE PODATAKA 241 MODELIRANJE PROCESA 247 UML 272 OSNOVNI ELEMENTI JEZIKA UML 274 OPŠTI MEHANIZMI JEZIKA UML 280 ALATI ZA PROJEKTOVANJE IS 282 CASE ALATI 282 STRUKTURA CASE ALATA 287
LITERATURA
307
PREDGOVOR
Informacioni sistemi predstavljaju intenzivniji način upotrebe informacija, odnosno njene raspoloživosti kao važnog organizacionog faktora. Evolutivni put razvoja informacionih sistema na jedan način je tekao od od fragmentarnih dijelova sistema ili podsistema do integralnih oblika. Paralelno su nastali pored informacionih sistema baziranih isključivo na informacijama (Elektronska obrada podataka i Upravljački informacioni sistemi) i informacioni sistemi zasnovani na znanju (Sistemi za podršku odlučivanja i Ekspertni sistemi). Savremeni informacioni sistemi se razvijaju kroz aktivnosti vezane za njihovo kreiranje i proces realizacije. Projektovanje ovakvih sistema treba da definiše što objektivniju sliku realnog svijeta, njegovih prošlih i tekućih stanja, kao i percepciju budućeg ponašanja. Kao infrastruktura se koriste relacione baze podataka. Izvodi se informaciono modeliranje odnosno modeliranje podataka i izrada dijagrama klasa UML (Unified modeling Language) uz pomć CASE alata kao što je npr. ERWin (Entity Relationships for Windows koji deifniše logički i fizički model podataka. Pisanje ove knjige je moralo biti limitirano odreĎenim referencama zbog širine oblasti i izuzetne dinamike razvoja ove materije, tako bih bio zahvalan za eventualne sugestije i primjedbe. Autor
1.
OPŠTA TEORIJA SISTEMA
Generalno prihvaćena karakteristika ovog vremena je intenzivan razvoj nauke. Cjelokupno znanje akumulirano do 20. vijeka udvostručeno je za samo pedeset godina. Buduća dinamika dupliranja znanja tekla je u rasponu od deset do pet godina. Ovaj gotovo nevjerovatan tempo postignut je zahvaljujući izmeĎu ostalog razvoju i primjeni naučne discipline teorije sistema, odnosno sistemskog pristupa. Razvoj informatike tijesno je povezan s primjenom teorije sistema i sistemskog pristupa naučnog istraživanja. Zbog toga razloga ovo poglavlje posebno tretira pojam sistema, strukturu i vrste sistema kao i primjenu teorije sistema. Pojam "sistem" je izveden od grčke riječi "to systema" što označava "cijelinu sastavljenu od dijelova". Kada je u pitanju tehnički, pa prema tome i proizvodni sistem podrazumijeva se skup elemenata (dijelova) i relacija izmeĎu njih i njihovih karakteristika integrisanih u cilju ostvarivanja odreĎenog cilja. Sistem se ne sastoji samo od elemenata (dijelova) već on predstavlja integralnu cijelinu elemenata i veza odreĎenog stepena jačine izmeĎu elemenata i njihovih karakteristika. Iako možemo reći da je teorija sistema naučna disciplina koja proučava sistem i zakonitosti koje u njemu vladaju. Postoje mnoge različite definicije sistema , ali mi ćemo se bazirati na onu koja kaže da je: sistem organizovana cijelina koju čine njegovi elementi povezani na odreĎeni način, a njihovim meĎusobnim djelovanjem, odnosom interakcijom postižu se odreĎeni ciljevi funkcionisanja sistema. Sistem je skup objekata i njihovih veza (meĎusobno povezanih objekata). Objekti u sistemu se opisuju preko svojih osobina koje se nazivaju atributima. Slika šematski predstavlja i detaljnije obrazlaže ovu definiciju.
Slika 1. Opšta definicija sistema Granicesistema definišu skup objekata koji će se u tom sistemu posmatrati. Objekti nekog sistema su, naravno, povezani sa objektima van njegovih granica, a ovi sa nekim drugim "daljim" i tako dalje. Neophodno je zato 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. može predstavljati mrežu puteva ili ulica, sistem za prenos električne energije, cirkulaciju dokumenata unutar neke organizacije, kretanje materijala koji se obraĎuje itd. Objekti u sistemu mogu biti veoma različiti, a veze izmeĎu objekata u sistemu i dejstvo okoline na sistem se ostvaruje na tri načina: razmjenom materije, energije ili informacija. ("Klasična predstava o svemiru koji se sastoji od materije i energije, mora da ustupi mjesto predstavi o svijetu sastavljenomod tri komponente: energije, materije i informacija, jer bez informacijaorganizovani sistemi nisu mogući. Jedino moguće materijalističko tumačenje održavanja organizovanosti je neprekidno izvlačenje iz spoljneg svijeta (okoline) i iz samog sistema mase informacija o pojavama i procesima koji se tu odvijaju". Da bi potpuno objasnili neki konkretni sistem potrebno je pobliže opisati: elemente koji pripadaju sistemu veze koje postoje izmeĎu elemenata sistema (interne), te izmeĎu elemenata sistema i okoline (eksterne) funkcionisanje sistema Svaki sistem ima svoje okruženje, tj.svoju sredinu u kojoj djeluje i koja na njega vrši odreĎeni uticaj. Gotovo sve definicije sistema ukazuju na ono što je zajedničko svima njima, a to je da svi elementi imaju svoje porijeklo, odnosno da su svi kompozicija (skup) elemenata i da svi imaju svrhu odnosno cilj, tako da postojanje bilo koga od njih ima smisla samo dok ostvaruje svrhu, odnosno svoj cilj kao sistem. Elementi sistema predstavljaju dijelove sistema sa odreĎenim osobinama i funkcijama. Kriterijume pripadnosti odreĎenog elementa odreĎenom sistemu možemo uglavnom svesti na relevantnost konkretnog elementa za funkcionisanje sistema i kontrolisanje elementa od strane sistema. Ako je zadovoljen prvi kriterijum, ali ne i drugi, tada konstatujemo da se radi o elementu iz okruženja sistema. Neki elementi mogu biti relativno kompleksni odnosno mogu predstavljati skup meĎusobno povezanih elemenata. Takvi složeni elementi predstavljaju podsisteme odreĎenog sistema. Elementi sistema posjeduju odreĎene osobine i funkcije koje ih povezuju sa drugim elementima istog sistema ili sa elementima izvan sistema. Povezanost dva elementa predstavlja interaktivnost elemenata odnosno meĎusobno dejstvo jednog na drugi. Vezom se uspostavlja odreĎeni meĎusobni odnos elemenata, prenosi djelovanje s jednog elementa na drugi. Taj prenos ilustrativno predstavljamo strelicom. Kanal preko koga se prenosi djelovanje elementa naziva se izlaz iz tog elementa, a kanal preko koga element preuzima djelovanje naziva se
ulaz. Pojedini elementi mogu posjedovati više ulaza ili izlaza. Jasno utvrĎeni elementi sistema i njihova povezanost (interna i eksterna), odnosno njihovi ulazi i izlazi, predstavljaju strukturu sistema Veze meĎu elementima sistema mogu biti materijalne, energetske i informacione. Materijalne veze karakteriše promjena rasporeda, oblika i sastava materije, a energetske predaja i transformacija energije iz jednog oblika u drugi. Kada govorimo o informacionim vezama primaran je prenos informacija, odnosno poruka, podataka, signala i sl. o nekom stanju, dogaĎaju ili procesu, dok materijalni i energetski oblik kojima je interpretirana ta informacija imaju sporednu važnost. Osnovni tipovi veza meĎu elementima sistema su tzv. jednostrane i povratne veze. Jednostranom vezom izmeĎu dva elementa jedan element uzima kao svoje ulaze stanje ili uticaje drugoga elementa. Ovakva veza predstavlja jednostrani uticaj prvog elementa na drugi element, odnosno stanja prvog elementa uzrok su odreĎenom ponašanju drugoga elementa, koje je posljedica.Često se ovakav tip veze naziva i uzročno-posljedičnom vezom. Povratna veza za razliku od jednostrane predstavlja meĎusobni uticaj dva elementa (interaktivnost). Na primjeru, izlaz prvog elementa u isto vrijeme je i ulaz drugoga elementa, ali isto tako izlaz drugoga elementa predstavlja ulaz prvoga elementa. Osnovna funkcija povratne veze je kontrola izvršavanja odreĎenih aktivnosti. Komparacijom zadatog i izvršenog utvrĎuje se odstupanje, koje se u sljedećem ciklusu koriguje tj. smanjuje i tako se konačni rezultat djelovanja sistema dovodi na željeni oblik. Osnovni zadatak rada sistema je transformacija ulaza u izlaze. Uopšte možemo kazati da se sistem sastoji od četiri osnovne komponente: ulaza, procesa, izlaza i povratne veze. TakoĎe treba uzeti u obzir i granicu sistema, koja ga odvaja od okruženja. Kriterijumi za klasifikaciju sistema mogu biti različiti. Tako sisteme razlikujemo prema prirodi elemenata, prema vrstama ponašanja, prema odreĎenosti, prema stepenu složenosti, prema vezama sa okruženjem itd. Prema prirodi elemenata koji čine sistem postoje apstraktni i realni sistemi. Elementi apstraktnog sistema su pojmovi meĎusobno povezani definicijama i pravilima. To su npr. brojni sistemi, kompjuterski programi, ljudski govor. Realni sistemi su oni sistemi čiji su elementi dio konkretnog realnog objekta. U ove sisteme spadaju npr. mehanički, fizički, biološki i društveni sistemi. Prema načinu ponašanja razlikujemo statičke i dinamičke sisteme. Statički sistemi ne mijenjaju, dakle održavaju, svoju strukturu i funkcionisanje u vremenu, za razliku od dinamičkih sistema koji mijenjaju svoju strukturu i funkcionisanje u interakciji sa okruženjem. Naime u njima se izvršava upravljanje procesima. S obzirom na odreĎenost sistema postoje odreĎeni (deterministički) sistemi i neodreĎeni (stohastički) sistemi. OdreĎeni sistemi funkcionišu u skladu s poznatim pravilima i njihovo ponašanje možemo predvidjeti, ako poznamo njihovu strukturu i funkcionisanje. Primjer ovakvog sistema je kompjuterski program. NeodreĎeni sistemi imaju stohastički karakter. Naime, njihovo ponašanje nije lako predvidjeti i oni imaju obilježje veće ili manje vjerovatnoće i slučajnosti. Dakle, ponašanje ovih sistema možemo samo prognozirati s odreĎenim stepenom vjerovatnoće. Takav je npr. bilo koji društvni sistem. Prema stepenu složenosti, odnosno prema broju elemenata i njihove interakcije razlikujemo jednostavne, složene i vrlo složene sisteme. Tako npr. računarski sistem tretiramo kao relativno jednostavan sistem, preduzeće složenim sistemom, a državu vrlo složenim sistemom. Prema vezama sistema s okruženjem postoje otvoreni i zatvoreni sistemi. Otvoreni sistemi posjeduju i održavaju vezu za svojim okruženjem, odnosno sa drugim sistemima iz svog okruženja. Aktivnost ovih sistema odvija se s jedne strane preko svojih ulaza, a s druge strane preko svojih izlaza. Tipičan primjer otvorenog sistema je preduzeće. Zatvoreni sistemi za razliku od otvorenih nemaju ulaze ni
izlaze. Oni su izolovani od okruženja i nemaju s njim nikakvu komunikaciju. Primjer ovakvog sistema je tzv. autarhična privreda, koja ne održava odnose sa svojim okruženjem. Rekapitulaciju opšte teorije sistema možemo iskazati kroz sljedeće teze: Sistem je skup meĎusobno povezanih elemenata. Elementi sistema osposobljeni su za obavljanje različitih funkcija što je i pretpostavka njihovog udruživanja u cjelinu. Elementi sistema tretiraju se u okviru funkcionisanja cjeline, a ne izolovano ili samostalno. Ovakav pristup u posmatranju pojava, predmeta i problema naziva se holistički pristup. Zajedničkim djelovanjem elementi sistema ostvaruju svoje zajedničke ciljeve tj. cilj funkcionisanja sistema. To predstavlja svrhovitost sistema. Princip ekvifinaliteta. Isti cilj funkcionisanja sistema može se postići na različite načine. Sistem razmjenjuje materiju, energiju i informacije sa svojim okruženjem. Transformacija ulaznih oblika u izlazne oblike predstavlja funkcionisanje sistema. Svrha sistema postiže se procesom regulacije. Regulacija se obavlja povratnom spregom tj. komparacijom stvarnih veličina sistema s veličinom koja je postavljena kao cilj funkcionisanja sistema i uklanjanjem nastalih odstupanja. Svaki je sistem dio nekog većeg sistema, tj. podsistem većeg sistema. TakoĎe dotični sistem može sadržavati podsisteme kao svoje elemente. Ovakva struktura sistema naziva se hijerarhija sistema. Teorija sistema proučava zajedničke osobine različitih sistema. To je princip izomorfnosti. Osnovna karakteristika izomorfnih sistema je jednak skup ulaznih i izlaznih veličina. Sistemski pristup čine metodološke osnove svih sistemskih nauka. Sistemski pristup se ostvaruje uz pomoć primjene intelekta (mišljenja), tehnike i sredstava zasnovanih na sistemskom mišljenju i opštoj teoriji sistema.
Slika 2. Sistemski pristup
Slika 3. Dinamika provoĊenja sistemskog pristupa Razmišljamo o tome, šta su ulazi, procesi, izlazi i da li smo zadovoljni izlazom. Ako nismo vršimo korekciju ulaza i ponekad procesa. Naš cilj je izlaz i zbog njega sve radimo. Na osnovu sistema napravimo model, a na osnovu njega vršimo istraživanje i stičemo nova znanja. Izlazna transformacija definiše neki način mjerenja ili posmatranja dinamičkog ponašanja realnog sistema i daje, na osnovu trenutnog stanja i trenutnih ulaza sistema, njegove izlaze. Model je pojednostavljena predstava o relevantnim karakteristikama sistema. Model je reprezentacija nekih objekata, veza izmeĎu objekata obilježja (svojstva, osobine, atributi), objekata i veza. Direktno postoji samo sistem, a svaka naša predstava o sistemu je model. S obzirom da je informacioni sistem model realnog sistema u kome djeluje, postupak projektovanja informacionog sistema svodi se na neku vrstu modeliranja realnog sistema.
Slika 4. Sistem model Sa kriterijumom funkcionisanja tražimo optimalno, odnosno suboptimalno rješenje. Na sistemu modela se vrše eksperimenti i treba da sadrži ključne karakteristike originala. Kriterijum ocjenjivanja treba da“odluči” šta treba korigovati na prvobitnom objektu. Suština proučavanja je poboljšanje objekta proučavanja. U zavisnosti od pojave koju želimo proučavati postavljamo sebi neki cilj.
Slika 5.
2.
Poslovna firma kao sistem
POJAM INFORMACIONIH
SISTEMA
Kroz čitav razvoj ljudskog društva temeljno djeluju četiri izrazite epohe načina društvene komunikacije: govor, pismo, štampa i telekomunikacije. MeĎutim, danas se nalazimo u vremenu svakodnevnih novih komunikaciono - tehničkih i organizacionih pronalazaka, koja će kad se u potpunosti razviju i uzajamno povežu s računarima, stvarno i zaslužiti ime
"revolucije" zbog njihovog višestrukog uticaja na promjene u komunikacijama koje se ubrzano razvijaju. Komuniciranje postaje mnogo brže, ali se i istovremeno organizuje na potpuno drugi "novi" način. Komunikacije moraju odgovoriti na tri pitanja:
Kojom tačnošću mogu biti preneseni simboli od kojih je sačinjena poruka (SINTAKSA)? Koliko precizno preneseni simboli nose željeno značenje ili smisao poruke (SEMANTIKA)? S kakvim uspjehom prenesena poruka kroz svoje značenje usmjerava na neku željenu aktivnost onoga kome je bila namijenjena (PRAGMATIKA)?
Postoje pojmovi nove naučne discipline koje karakterišu odreĎene periode razvoja ljudskog društva. To što oni postaju dominantni u istraživačkim naporima, u teoretskim radovima, pa i u svakodnevnom govoru samo ukazuje na suštinske prodore ljudske misli i ljudske nauke, ljudskog saznanja u one prostore koji su do tada bili neotkriveni, često nadohvat ruke. Takav pojam je svakako informacija, kao i niz nauka koje su nastale ili su dobile znatnu pomoć u razvoju koncepta informacije. Značaj informacije ili moć podatka nije otkrice ni našeg vremena ni našeg vijeka. Mnostvo dokumeneta i iskustava pokazuju da su ljudi od pamtivijeka znali za uticaj i značaj informacije. Na primjer, jos u prvom pevanju Starog zavjeta stoji: “ I Bog reče”. MeĎutim tek razvojem niza savremenih nauka a naročito kibernetike, sredinom ovoga vjeka informacija dobiva svoj današnji značaj. Ona dobiva taj značaj prvenstveno zbog toga što se razvojem kibernetike i srodnih nauka ukazuje ne samo na značaj informacije nego i na njenu moguću primjenu u procesu odlučivanja i procesu upravljanja. Na taj način se informacija direktno povezuje ne samo sa čovjekovim saznanjem svijeta koji ga okružuje, što je vjerovatno daleko važnije, već i sa čovjekovom mogućnošću da utiče na svijet oko sebe. Kao mnogi pojmovi, i informacija kao pojam ima različita značenja. MeĎutim multiplikacija značenja informacije nije samo proizvod pomodnosti i značaja koji informacija ima danas u svijetu, nego prije svega činjenice da je informacija pojava koja presjeca ili se moze naći u skoro svim disciplinama kojima se čovjek danas naučno bavi, i zbog toga često izgleda da nadrasta te pojedinačne discipline, da je ono što je suštinsko, ono što je osnovno, bazično,što je iznad i izvan klasičnih naučnih disciplina. Informacija se proučava u teoretskoj misli, ona ima svoje mjesto u najnovijim ideološkim raspravama, proučava se u tako savremenim disciplinama kao što su biologija i biološki inženjering, pručava se i u tehničkim naukama, a savremena sociologija, ekonomija, politikologija ne mogu se zamisliti bez poznavanja i proučavanja informacionih procesa. Teorija informacija danas je razvijena u posebnu nauku čiji je teorijski i praktični značaj u savremenom svijetu veoma velik i svakim danim je sve veći. Teorija informacija dobiva sve veći značaj u vezi sa automatizacijom ljudske djelatnosti i sa razvojem kibernetike kao teorijske nauke i tehnike upravljanja složenim samoregulacionim dinamičkim sistemima. Danas se već teorija informacija uspješno primjenjuje u filozofiji i matematici, prirodnim i tehničkim naukama, socijalno- ekonomskim naukama, biologiji i medicini. Primjena elektronskih računara pomaže da se “prošire” intelektualne mogućnosti; pri ocjeni situacije, donošenju odluka, mjerenju, kontroli i upravljanju. Ovdje kao meĎufazu možemo uzeti proces pamćenja i čuvanja informacija u trajnoj ili operativnoj memoriji. Teorija informacija je u osnovi matematička disciplina koja koristi metode teorije vjerovatnoće, matematičke statistike, teoriju grupa, teoriju igara i druge oblasti matematike. Jedna od važnih komponenti objedinjavanja disciplina koje se ubrajaju u teoriju informacija je široka primjena statističkih metoda. Ovo se objašnjava time što je proces čuvanja i pronalaženja informacija povezan
sa problemom gubitka informacija o objektu, pri čemu je stvarana kvantitativna mjera neodreĎenosti izražena vjerovatnoćom nastanka odreĎenog dogaĎaja. Informatika je naučna disciplina koja se bavi izučavanjem nastanka, strukture i opštih osobina informacije, a takoĎe i zakonomjernostima svih procesa komunikacije: od neformalnih procesa razmjene informacija usmenim ili pismenim opštenjem naučnika i specijalista do formalnih procesa razmjene putem naučne literature. Tako se naučna informacija javlja kao rezultat prerade i uopštavanja informacija i podataka, dobivenih neposredno u procesu istraživanja. Naučna informacija nosi sobom realno prikazivanje, ukoliko objektivno odražava zakonomjernosti prirode, društva i mišljenja i podrazumijeva stepen tačnosti prikaza na datom nivou naučnih dostignuća. Informacija (lat. Informatio) označava pojmove kao što su: poučavanje, uputstvo, obavještavanje. NavoĎenjem odgovarajućih sinonima kojima zamjenjujemo pojam i značenje latinske riječi informatio na prvi pogled izgleda da nema ničeg nejasnog u pogledu shvatanja pojma informacije. Mi se svakodnevno služimo navedenim pojmovima – poučavanje, upućivanje, obavještenje, a da nam prije toga niko nije postavio pitanje značenja navedenih pojmova. Treba naglasiti da se većina naučnika, kao i autora stručne literature iz ove oblasti radije bavi tumačenjem značaja pojma informacije a ne pokušajima da se taj pojam teoretski definiše. Norbert Viner informacijom naziva sadržaj onoga što razmjenjujemo sa spoljnim svijetom dok mu se prilagoĎavamo i dok utičemo na njega svojim prilagoĎavanjem. Proces primanja i korišćenja informacija proces je našeg prilagoĎavanja slučajnostima spoljne okoline i našeg nastojanja da u toj okolini djelotvorno živimo. Prema Vitmanu informacija je namjenski upravljeno znanje sa ciljem da pripremi ponašanje. Ljudsko ponašanje koje treba da bude efikasno za postizanje ciljeva, po iskustvu traži znanje. Što su bolje poznate varijante i okolnosti, to se bolje mogu pripremiti aktivnosti i to će veći, po pravilu biti uspjeh. Tu se ne misli na znanje uopšte, nego na znanje sa namjerom da pripremi ponašanje (informacija). Informacija povećava znanje i produbljuje intelekt. Moglo bi se reći da je informacija osnova svih aktivnosti čovjeka zasnovanih na posjedovanju znanja, činjenica ili rezultata mjerenja, kao i odreĎenih procedura da bi se obavio koristan rad. Značaj informacije se ocjenjuje u odnosu na to koliko ona doprinosi rješavanju datog problema – problema kome je namijenjena ta informacija. Za pojam informacije se obično vezuju dva objekta: objekat koji stvara informacije – izvor informacija, i objekat kome su namjenjene informacije, adresant odnosno potrošač. S obzirom na objeka i način stvaranja informacije razlikujemo tri osnovne vrste informacija: 1. Informacije prve vrste – neposredne informacije, 2. Informacije druge vrste – posredne informacije, 3. Pragmatične informacije. Prvu vrstu informacija čine one informacije koje korisnik prima direktno iz okoline, odnosno direktno sa mjesta nastanka (izvora) informacije. Drugu vrstu informacija čine informacije koje primamo posredstvom drugih ljudi, knjige, radija, televizije itd. To su informacije koje je neko drugi sticao iz objektivne stvarnosti. Ako nam neko drugi saopštava informaciju o stvarnosti, onda je to njegov stav o toj stvarnosti, odnosno njegova idealizovana slika te stvarnosti. Pragmatičnom informacijom nazivamo one vrste informacija koje se grade na osnovu već stečenog iskustva i novoprimljenih informacija bilo posrednim ili neposrednim putem. Novoprimljene informacije se preraĎuju sa posjedovanim informacijama i na taj način se stvaraju nove izvedene tj.
pragmatične informacije. Značaj pragmatične informacije se ocjenjuje na osnovu efekta koga ona proizvodi na ponašanje primaoca – korisnika informacije. Mi danas živimo u epohi informacija i komunikacija tako da je važnost informacije danas enormna, jer se svakodnevni život bez informacija ne bi mogao djelotvorno odvijati. Savremene nauke koje se bave izučavanjem informacija kao što su informatika i kibernetika još uvijek nisu u potpunosti spoznale moćinformacije. U industriji se danas sve više uvodi automatizacija, što smanjuje djelovanje čovjeka u procesu rada što bi bez informatike bilo nemoguće. Sve to ukazuje na ogromnu važnost informacije i komunikacije i na to da je danas prava informacija neprocjenjiva. Sve u svemu značaj informatike i informacija u današnjem svijetu je nemjerljiv, a samim tim sva preduzeća koja ne posjeduju kvalitetan informacioni sistem neće moći adekvatno da planiraju i kontrolišu proizvodnju ili neku drugu djelatnost da bi ostvarili povoljniji položaj na tržištu odnosno da bi bili konkurentni.
Brojne su definicije informatike i još uvijek nema neke opšte priznate definicije koja bi obuhvatila sva područja koja informatika obuhvata, ali evo onih temeljnih: Francuska akademija nauka (1966) - Informatika je nauka o racionalnoj obradi informacija, prvenstveno pomoću automatskih mašina, ka nosiocu znanja i komunikacije u oblasti nauke, tehnike, ekonomije i drugim područjima ljudske djelatnosti.
Opšta enciklopedija (1966) - Informatika je naučna disciplina koja proučava strukturu i osobine, ali ne i sadržaj, informacija, te zakonitosti informatičke djelatnosti, njezinu teoriju, istoriju, metodologiju, organizaciju i samu djelotvornost.
Posmatrano sa informatičkog aspekta informacioni sistemi su skup metoda, postupaka i resursa dizajniranih tako da pomažu dolaženje do odreĎenog cilja. Definiciono, informacioni sistem se može predstaviti i kao integralni sistem koji obuhvata kadrove i opremu u funkciji stvaranja relevantnih informacija. Djelatnost svakog informacionog sistema može se dekomponovati na sljedeće osnovne aktivnosti: prikupljanje podataka, obrada podataka, memorisanje podataka i informacija i distribucija podataka i informacija korisnicima. Prikupljanje podataka predstavlja aktivnost obuhvata podataka na mjestima njihovog nastanka, zavisno od definisanih potreba konkretnog informacionog sistema. Tako obuhvaćeni podaci se zatim obraĎuju po odreĎenim procedurama i programima obrade podataka. Kada se podaci obrade onda dobivaju karakter informacija. Radi daljeg korišćenja memorišu se i arhiviraju. Na kraju se obraĎeni podaci u obliku informacija distribuiraju relevantnim korisnicima, kao podloga za donošenje odluka. Uopšte, funkcije informacionog sistema mogu se sintetizovati na dvije osnovne funkcije: funkciju informisanja i funkciju dokumentovanja. Funkcija informisanja ima cilj da upravljanje i poslovno odlučivanje učini što efikasnijim. Naime, informacioni sistem svojim funkcionisanjem osigurava relevantne informacije (tačne, pravovremene i na pravu adresu upućene) za operativno i razvojno upravljanje poslovnim sistemom i njegovim podsistemima. Funkcija dokumentovanja stvara mogućnost da se konstantno prati poslovanje i vrši razmjena informacija sa drugim privrednim i društvenim podsistemima (npr. banke, Zavod za statistiku, poslovni partneri itd.). Informacioni sistemi se klasifikuju prema različitim kriterijumima kao što su: primijenjena tehnologija, stepen složenosti, područje primjene, itd. Kada su informacioni sistemi zasnovani na ručnoj ili mehanografskoj obradi podataka, bez podrške kompjutera, onda govorimo o konvencionalnim informacionim sistemima. Ova vrsta informacionih sistema karakteristična je za
poslove koji ne zhtijevaju stalnu ažurnost i masovnu obradu podataka. Obično se primjenjuju u manjim organizacijama. Ipak, kako većina organizacija, odnosno poslovnih sistema djeluje u složenim i dinamičnim uslovima poslovanja, za njihovo upravljanje i poslovno odlučivanje potrebne su pravovremene, potpune i kvalitetno obraĎene informacije. Takve informacije mogu se dobiti jedino primjenom savremene informacione tehnologije. Za razliku od konvencionalnih, takve sisteme nazivamo kompjuterizovanim informacionim sistemima.
3.
RAZVOJ INFORMACIONIH
SISTEMA
Informacioni sistemi su u svojoj kratkoj istoriji prošli kroz nekoliko faza razvoja, koje danas uglavnom možemo sintetizovati na sljedeći način: elektronska obrada podataka (EOP), upravljački informacioni sistemi (UIS), sistemi za podršku odlučivanja (SPO) i ekspertni sistemi (ES). Ove faze ne treba miješati sa generacijama računara, jer su one prije svega vezane za organizaciona i softverska rješenja. Istovremeno, ovi informacioni sistemi su istorijski sukcesivne faze u razvoju informacionih sistema. Prve dvije faze (EOP i UIS) sučinjeničnog karaktera, što znači da obraĎuju podatke i daju izvještaje o fizičkim procesima nakon njihovog dešavanja. Za razliku od njih, sljedeće dvije faze (SPO i ES) posmatraju procese unaprijed tj. imaju prognostički karakter. Sa aspekta problema upravljanja, namjena ovih informacionih sistema se svodi na : analizu poslovanja, donošenje operativnih odluka, donošenje taktičkih odluka i donošenje strateških odluka. Osnovne karakteristike navedenih faza razvoja informacionih sitema vidimo u sljedećoj tabeli:
FAZA FOKUS
OPIS POSLOVA
INFORMACIJE (IZLAZ)
SOFTVER
SISTEMSKA ANALIZA
DIZAJN
EOP Podaci
Strukturiran
Izvještaji
Polustruktuiran
U mreži i hijerarhijska
Opis toka obrade
Proceduralni jezici
Opisana
Viši programski jezici
Tok podataka
Strukturna analiza
Generatori programa
Prototip
Prototip
Predstavljanje i zaključivanje
Izgradnja baze znanja
Prototip sa više interakcija
UIS Informacije
SPO Odluke
Polustrukturiran
Znanje
Nestrukturiran
Relacioni pregled
ES Činjenice, heuristike
Tabela 1. Faze razvoja informacionih sistema
3.1. ELEKTRONSKA OBRADA PODATAKA
Kada govorimo o elektronskoj obradi podataka (EOP/EDP - Electronic Data Processing), odnosno da bismo bolje shvatili savremene sisteme za obradu podataka, potrebno je u izvjesnoj mjeri razumjeti prethodne oblike obrade podataka. To su bili ručna i mehanička obrada podataka. Osnovna karakteristika ručne obrade podataka je da ulogu nosioca podatka preuzima sam čovjek, koji prema odreĎenim formalno - logičkim ili matematičkim pravilima obraĎuje prikupljene podatke u informacije. Informacije u daljem toku služe kao osnova za donošenje odluka. Pored čovjeka komponente ručne obrade podataka mogu biti papir, kalkulator, pisaća mašina i sl. Primjena konkretnih komponenti zavisi o zadatku obrade i funkcijama koje treba izvršiti u procesu obrade. OdreĎene funkcije čovjek može ponavljati ili prekinuti prema vlastitoj procjeni. Komparativno gledano ručna obrada traži relativno skromne resurse, male pripreme, omogućava brzu distribuciju rezultata i laku korekciju eventualno nastalih grešaka. Ova vrsta obrade podataka ima veliku komunikativnost s ostalim vrstama obrade podatka i vrlo je ekonomična kada se radi o manjem obimu podataka. Što se tiče negativne strane primjene ručne obrade podataka, evidentna je sporost obrade podataka, relativno veliki broj grešaka u procesu i neekonomičnost kod velikog broja podataka. Mehanička obrada podataka obavlja se pomoću mehaničkih i elektromehaničkih mašina. Kod ove vrste obrade podataka čovjek snabdijeva mašinu ulaznim podacima kao i instrukcijama koje kontrolišu proces obrade podataka. U ovu kategoriju sredstava ubrajamo računske mašine, mašine za knjiženje i saldiranje, zatim mašine za fakturisanje, pisaće mašine, obračunske automate i sl. Pozitivne strane primjene mehaničke obrade podataka su veća brzina rada u odnosu na ručnu obradu podataka, preciznost izvršavanja računskih operacija i konačno jasniji rezultati obrade. Nedostaci ove obrade podataka su sporost brzine ručnog unošenja podataka u mašinu, otkrivanje i korekcija grešaka su komplikovaniji nego kod ručne obrade podataka i čovjek mora konstantno kontrolisati obradu podataka. Elektronska obrada je najkompleksnija obrada podataka. Njena osnovna karakteristika je samostalno izvršavanje svih operacija prema unaprijed zadatom programu koji se sastoji od niza naredbi odnosno instrukcija na elektronskom računaru tj. kompjuteru. Istorijski gledano pionirske korake ove vrste obrade podataka postavio je Čarls Bebidž 1833. godine. MeĎutim, nepremostivu granicu za njegove ideje predstavljao je tadašnji limit tehnike. Razvoj elektronike u toku i poslije Drugog svjetskog rata našao je primjenu u konstrukciji elektronskih računara. Najpoznatiji računar iz tog vremena je tzv. ENIAC (Elektronic Numerical Integrator And Calculator), koji predstavlja prvi digitalni računar u savremenom smislu riječi. Tvorci ovog računara su Amerikanci Maučli i Ekert 1946. godine. Ovaj računar je izvršavao računske operacije pomoću elektronskih cijevi. Za ulaz i izlaz podataka koristili su se mehanički dijelovi, a memorisanje, operacije s brojevima i kontrolne operacije ostvarene su preko elektronskih komponenti. Za ulaz podataka koristile su se bušene kartice, a programiranje je bilo vrlo složeno. Memorija je bila relativno skromna. Računar je služio za različita izračunavanja, a brzina izvršavanja operacija bila je oko hiljadu puta veća od tadašnjih najbržih računskih mašina. Elektronska obrada podataka predstavlja pionirsku fazu u korišćenju računara za poslovne namjene. Nastala je pedesetih godina ovog vijeka i ponegdje još uvijek egzistira. Opravdanje za to su ograničeni računarski resursi i neadekvatni računarski kadrovi. Elektronska obrada podataka odlikuje se jednostavnom obradom podataka ili transakcija i relativno primitivnim izvještajima. Postiže se zavidna tačnost i brzina uz povećan kvalitet i kvantitet informacija. Osnovna uloga EOP-a je automatizacija masovne ručne obrade podataka i efikasno funkcionisanje organizacije uz što niže troškove. U osnovi ove koncepcije nalaze se podaci. Sistem je oblikovan na bazi opisa poslovnih tokova i obrade podataka. Softverska rješenja su opisna i zasnovana na klasičnim programskim jezicima (npr. COBOL).
Tipične aplikacije koje se mogu imlementirati na kompjuter su: knjiženje poslovnih promjena u glavnoj knjizi, evidencija kupaca i dobavljača, praćenje zaliha materijala, sirovina i gotovih proizvoda, obračun plata i kadrovska evidencija. Ovaj nivo obrade masovnih podataka predstavlja početak uvoĎenja kompjuterske ili elektronske obrade podataka u preduzeće. Informacioni sistem na ovom stepenu ne smatra se pravim informacionim sistemom. Nažalost, mnoga preduzeća ne prelaze na viši nivo i na taj način ne koriste efikasno mogućnosti kompjutera.
3.2. UPRAVLJAČKI INFORMACIONI SISTEMI
Upravljački informacioni sistemi (MIS - Management Information Systems) nastali su kao posljedica znatno povećanih kompjuterskih resursa, posebno u domenu: brzine kompjutera, kapacitativnosti glavne i sekundarne memorije, boljih komunikacija, većih performansi operativnih sistema i razvoja specijalizovanih softverskih paketa. Ova faza počinje polovinom šezdesetih godina i još uvijek je aktuelna. Zadržala je sve pozitivne karakteristike prethodne elektronske obrade podataka. Novi kvalitet postiže u: načinu obuhvatanja podataka (na mjestu nastanka). procesu izvještavanja (osim štampanog uvodi se i ekransko izvještavanje) i uvoĎenju automatizacije odreĎenih rutinskih poslova, obično na nižim nivoima upravljanja. U velikom broju definicija upravljačkog informacionog sistema izdvojićemo definiciju Stair-a, koji kaže da je MIS organizovani skup ljudi, procedura, baza podataka i sredstava koji snabdijevaju menadžere i donosioce odluka informacijama koje im pomažu da postignu organizacione ciljeve. Upravljački informacioni sistemi se odlikuju integracijama po funkcionalnim linijama, kaošto su proizvodnja, marketing, finansije, itd. Sve ove aktivnosti mogu se grupisati u tri kategorije:
odreĎivanje alternativa, priprema modela i obrada alternativa i procjena (komparacija) alternativa.
Sljedeći primjer daje pregled najvažnijih funkcionalnih podsistema MIS-a:
Podsistem Proizvodnja Marketing
Oblast primjene Planiranje i programiranje proizvodnje, kontrola i analiza troškova PredviĎanje, planiranje i analiza prodaje i nabavke, kontrola kvaliteta, problemi zaliha
Finansije
Finansijske analize, troškovi, investicije
Kadrovi
VoĎenje cjelokupne kadrovske politike, ergonomija
Top menadţeri
Alokacija resursa , strateško planiranje
Tabela 2. Funkcionalni podsistemi MIS-a
3.2.1. UPRAVLJAČKI PODSISTEM PROIZVODNJE Proces proizvodnje po tehnološkom karakteru, zahtjevima za visokom produktivnošću i kvalitetom proizvoda podrazumijeva kompjutersku podršku. Upravljački informacioni podsistem proizvodnje kao izvor podataka za transformaciju inputa u organizaciju koriste materijale, energiju, informacije, kadrove itd. To znači da ovaj podsistem sadrži odgovarajuće komponente koje omogućavaju kontrolu i usmjeravanje tokova vezanih za materijale, energiju, informacije i ljude, kao i efikasnu transformaciju toga inputa u kvalitetne proizvode. Najvažnije komponente ovog podsistema su: CAD sistemi, CAM sistemi, CIM sistemi i sistemi kontrole kvaliteta. Jedna od bitnih komponenti upravljačkog podsistema proizvodnje je komponenta za oblikovanje i inženjenjring koja rješava probleme odreĎivanja veličine i oblika dijelova proizvoda, redoslijeda njihovog sklapanja u finalni proizvod, kontrole kvaliteta itd. Za ovu svrhu se koriste CAD (Computer Aided Design) sistemi. CAD sistemi se koriste za projektovanje i pripremu proizvodnje. Danas se slobodno može reći da ovi sistemi imaju odlučujuću ulogu u razvoju novih proizvoda. CAM (Computer Aided Manufacturing)sistemi upravljau proizvodnjom pomoću kompjutera. Oni omogućuju da se pomoću kompjutera planira potreban materijal, mašinski i ručni rad i rokovi proizvodnje. Pored ovih aktivnosti, prate se utrošci materijala i obračunavaju radni nalozi. OdreĎeni CAM sistemi posjeduju mogućnost postavljanja dijagnoze prilikom nastanka teškoća u funkcionisanju proizvodnog procesa. CIM (Computer Integrated Manufacturing)sistemi predstavljaju komponentu upravljačkog podsistema proizvodnje čija je osnovna uloga povezivanje svih komponenti i aspekata proizvodnog procesa uključujući obradu narudžbi, oblikovanje proizvoda i kontrolu kvaliteta u harmoničnu i funkcionalnu cjelinu. Komponentakontrole kvaliteta uz pomoćodgovarajućih informacija olakšava otkrivanje i lokalizovanje problema u procesu proizvodnje. Sistemi kontrole kvaliteta učestvuju u eliminaciji greške na proizvodu i sugerišu drugačije oblikovanje proizvoda. U zavisnosti od toga da li je proizvodni proces kontinuiran ili diskretan primjenjuju se kontrolne karte za kontinuirani proces ili odgovarajući planovi uzorkovanja za diskretni proces, a sve u cilju minimalizovanja greške u proizvodnom procesu.
3.2.2. UPRAVLJAČKI PODSISTEM MARKETINGA Upravljački podsistem marketinga stvara informacije koje menadžeri koriste u procesu donošenja odluka o razvoju i cijeni proizvoda, kao i promotivnim aktivnostima, prognozi prodaje i distribuciji. Osnovne interne izvore podataka za ovaj podsistem predstavljaju strateški plan organizacije, gdje se specifikuju ciljevi vezani za prodaju, izvještaji o prodaji odgovarajućih proizvoda i usluga, podaci o kupcima i korisnicima usluga itd. Značajni eksterni izvori podataka su izvori podataka o konkurentskim organizacijama (novi proizvodi i sluge, cijene proizvoda i usluga, proizvodni potencijali itd.) i izvori podataka o tržištu, gdje se realizuju odgovarajući proizvodi i usluge. Upravljački informacioni podsistem marketinga sadrži različite komponente, a najznačajnije su: marketinška istraživanja, razvoj proizvoda, odreĎivanje cijena proizvoda i usluga i promotivne aktivnosti.
3.2.3. UPRAVLJAČKI PODSISTEM FINANSIJA Kvalitetan finansijski menadžment u organizaciji postiže se preko kvalitetnog upravljačkog informacionog podsistema finansija. To znači da ovaj podsistem analizom prošlih i tekućih finansijskih aktivnosti, kao i projektovanjem budućih finansijskih potreba generiše informacije koje su neophodne finansijskom menadžmentu organizacije za pravilno odlučivanje. Informacije relevantne za proces odlučivanja u podsistemu informacija potiču iz internih i eksternih izvora. Interni izvori su strateški plan gdje se specifikuju finansijski ciljevi, analiza investicionih transkacija, obim prodaje proizvoda i usluga, količina novca u opticaju itd. Eksterne izvore uglavnom čine izvještaji odgovarajućih državnih institucija, zakonski propisi, izvještaji konkurentskih organizacija itd. Upravljački informacioni podsistem za svoje pravilno funkcionisanje obuhvata sljedeće najvažnije komponente: finansijsko predviĎanje, analizu profita, analizu troškova, internu i eksternu finansijsku kontrolu i korišćenje i upravljanje fondovima.
3.2.4. UPRAVLJAČKI PODSISTEM KADROVA Kadrovski upravljački informacioni podsistem obezbjeĎuje informacije o opisima poslova, zahtjevima radnih mjesta, sadržajima obučavanja i usavršavanja, radnim karakteristikama i stepenu uspješnosti poslovnog personala (radno iskustvo, znanje, vještine i sl.). Ove informacije moraju biti u funkciji odlučivanja i, planiranja i upravljanja personalnog potencijala organizacije. Interni izvori podataka karakteristični za ovaj podsistem su strateški, taktički i operativni planovi, interni propisi i ostali dokumenti bitni za regrutovanje, selekciju, prijem, rasporeĎivanje, analizu poslova, mjerenje radne uspješnosti, usavršavanje, fluktuaciju, povredu radnih pravila, prestanak zaposlenja itd. Eksterni izvori podataka su zakonski propisi, stručni tekstovi, savjetovanja i dr. iz personalno poslovnog domena. Najvažnije komponente upravljačkog informacionog podsistema kadrova strukturirane su na sljedeći način: analiza poslova, selekcija i raspored poslova, stručno obrazovanje i usavršavanje, procjenjivanje i mjerenje radne uspješnosti i nagraĎivanje, apsentizam i interna i eksterna fluktuacija.
3.2.5. UPRAVLJAČKI PODSISTEM ZA TOP MENADŽERE Osnovni razlog za kasni razvoj upravljačkih informacionih podsistema za top menadžere teorija nalazi u relativno slaboj strukturiranosti aktivnosti top menadžera. To praktično znači da kompjuter lakše razumijeva i učestvuje u rješavanju problema i odlučivanju na nižim nivoima upravljanja u nekoj organizaciji. Kompjuterski programi koji se koriste za ovu oblast i koji obezbjeĎuju relevantne informacije uglavnom pripadaju: samoj organizaciji za koju se programi rade i koji su proizvod vlastitih informatičkih stručnjaka, aplikativno - razvojnim programima kao što su sistemi za upravljanje bazama podataka, elektronskim tabelama, grafičkim paketima i sl. i specijalnim programima koji su kreirani isključivo za ove upravljačke podsisteme.
3.3. SISTEMI ZA PODRŠKU ODLUČIVANJA
3.3.1. POJAM SISTEMA ZA PODRŠKU ODLUČIVANJA Informacioni SPO - Sistemi za podršku odlučivanja (DSS - Decision Support Systems) vezani su za nastanak i razvoj programskih jezika četvrte generacije i generatora aplikacija. Osnovna ideja ovih informacionih sistema je da korisnik u interakciji sa izlaznim informacijama iz informacionog sistema donosi odluke. DSS pomaže onima koji odlučuju, da koriste podatke i modele kako bi riješili nestrukturirane i slabostrukturirane probleme. Autor Tierauf, SPO definiše kao sistem koji donosiocu odluke omogućuje kombinaciju ličnog prosuĎivanja sa računarskim izlazima u aktivnom korisničkom interfejsu sa mašinom, pružajući korisne informacije za proces odlučivanja. Geriti koncept SPO tretira kao efikasnu mješavinu ljudske inteligencije, informacione tehnologije i softvera, koji su u bliskoj interakciji kako bi riješili kompleksne probleme. Značajnija istraživanja sistema za podršku odlučivanja vrše se sedamdesetih godina ovoga vijeka, kada se pojavljuje veliki broj radova iz ove oblasti. Prva meĎunarodna SPO konferencija održana je 1981. godine (Ostin, Teksas) i okupila je oko tri stotine proizvoĎača, istraživača i korisnika SPO. Sva istraživanja se uglavnom svode na to da je SPO interaktivni kompjuterski bazirani sistem koji pomaže donosiocima odluke da koriste podatke i modele (u posljednje vrijeme se sve više govori o znanjima) pri rješavanju nestrukturiranih (polustrukturiranih i slabostrukturiranih) problema. Svako odlučivanje počinje uočavanjem problema. Problemom se smatra svaka situacija u kojoj se neko sadašnje ili dato stanje treba promijeniti, jer onakvo kakvo jeste zbog nečeg ne zadovoljava. Odlučivanje predstavlja izbor jedne ili više alternativa koja će obezbjediti postizanje cilja. Potrebno je uočiti dvije kritične situacije koje prethode odlučivanju, a to su: nastajanje problema i uoĉavanje problema. Kvalitet i brzina reagovanja na nastali problem, kao i ostale faze procesa odlučivanja zavise od psiholoških karakteristika donosioca odluke, ali i od vrste problema, složenosti, strukturiranosti i dr. SPO treba da obezbijedi menadžeru vremenski odgovarajuću informaciju koja će biti tačna, relevantna i kompletna. SPO mora da prikaže informaciju u adekvatnoj formi, lakoj za razumijevanje i upravljanje. Ta informacija može biti rezultat ili može biti prikupljena sa spoljašnjih izvora. Menadžer želi pravu informaciju, u pravo vrijeme i u pravoj formi. SPO se koriste za slabo strukturirane probleme. Osnovni razlog zbog kojeg se oni pretežno koriste na višim nivoima odlučivanja, jeste taj, što su niži nivoi odlučivanja suočeni sa bolje strukturiranim problemima, pa su u prilici da koriste egzaktne, kvantitativne metode, koje su jednostavnije za primjenu i daju jednoznačne rezultate. Svrha SPO je da podrži a ne da zamijeni donosioca odluka. Kako je SPO namijenjen odlučivanju, on pokušava da integriše menadžment i tradicionalne funkcije obrade podataka. Znači, SPO sadrži algoritme logičkih i racionalnih procesa putem kojih klasifikuje, uporeĎuje i formira informacijeza odlučivanje. SPO se može definisati i kao informacioni sistem koji ispunjava potrebe strateškog odlučivanja. MeĎutim, on treba da podržava donošenje odluka na svim nivoima odlučivanja. Zbog toga je najcjelishodnija izgradnja distribuiranih SPO sa pristupom svim potrebnim informacionim resursima.
Ovakav pristup omogućava postepeno dodavanje novih komponenti SPO koje će se uklopiti u postojeće sisteme. U tom smislu osnovu SPO čine programi koji pristupaju analitičkim bazama podataka (skladišta podataka) i izvlače iz njih sintetičku informaciju u obliku i formatu kakav je potreban za dati nivo odlučivanja. Dio podataka za formiranje baze SPO može se koristiti iz spoljnih izvora ili specijalizovanih datoteka. Ovo je naročito karakteristično za najsloženije - startegijske informacije koje pruža SPO.
3.3.2. STRUKTURA SISTEMA ZA PODRŠKU ODLUČIVANJA Tipičan SPO se sastoji od sljedećih podsistema: DBMS -podsistem podataka i upravljanje podacima, MBMS -podsistem modela i upravljanje modelima i DGMS -podsistem dijaloga i upravljanje dijalogom. Pored ovih osnovnih komponenti i korisnici (menadžeri i drugi) se smatraju dijelom SPO. Tipičnu arhitekturu SPO simbolički interpretira :
Slika 6. Tipiĉna arhitektura SPO Dakle, osnovne komponente današnjih sistema za podršku odlučivanju su: podsistem za upravljanje podacima; podsistem za upravljanje modelima; podsistem za upravljanje znanjima; podsistem - korisnički interfejs; korisnik. Podsistem za upravljanje podacima je baza podataka koja predstavlja konstitutivni elemenat SPO. U tom smislu srećemo pristup inicijalnog projektovanja baze podataka SPO koji polazi od potreba rješavanja problema zbog kojeg se gradi SPO ili ekstrakcije podataka za potrebe baze podataka SPO iz realne baze podataka. Podsistem za upravljanje podacima se sastoji iz sljedećih elemenata: baza podataka sistema za podršku odlučivanju; sistemi za upravljanje podacima; direktorijum sa podacima; upit. Jedan SPO može koristiti više baza podataka u zavisnosti od mjesta skladištenja potrebnih informacija. Razlikujemo i podatke koji potiču iz unutrašnjih i spoljašnjih izvora. Pod unutrašnjim izvorima se smatraju baze podataka unutar organizacije. Pod spoljašnjim izvorima podrazumijevamo: baze podataka realnog sistema za koji se projektuje SPO (egzaktni podaci nastali u realnom sistemu, kroz procese i transakcije poslovanja) ostale izvore podataka od interesa za probleme koje SPO treba da rješava (baze podataka drugih institucija, granskih i državnih organizacija, informacionih servisa i sl.) Proces kreiranja baze podataka ili skladišta podataka preko spoljašnjih izvora naziva se ekstrakcija ili preslikavanje podataka. Pod ekstrakcijom podataka podrazumijeva se unošenje (importovanje, sumarizacija, filtracija i kondenzacija) podataka. Sistem za upravljanje bazom podataka omogućava nam upravljanje procesom ekstrakcije podataka, ažurira zapise u bazi podataka, povezuje podatke iz različitih izvora, upravlja podacima preko rječnika podataka. Reĉnik podataka predstavlja katalog sa svim podacima u bazi podataka i služi da bi odgovorio na pitanja o dostupnosti odreĎenom podatku, njegovom izvoru i njegovom tačnom značenju. Ovoj komponenti je moguće dodavati, brisati i ažurirati unose. Pošto se podaci ne ekstrahuju prosto, već trpe izvjesne formalne i suštinske promjene prije smještanja u bazu podataka SPO, termin "preslikavanje" je adekvatniji i precizniji za proces koji označava. Analiza ovog procesa preuzimanja podataka može se sprovesti u odnosu na različite kriterijume:
prema strukturi podataka; prema izvorima iz kojih potiču; prema semantičkoj vrijednosti za proces odlučivanja kojima je SPO namijenjen; prema njihovoj pouzdanosti za korišćenje u konkretnom SPO; prema načinu na koji se preslikavaju u bazu podataka SPO.
Zapravo, formiranje baze podataka SPO odvija se u dvije faze: selekcija podataka iz okruženja i preslikavanje tih podataka u bazu podataka SPO. Prva faza podrazumijeva aktivnosti čiji je osnovni kriterijum namjena SPO-a koji se projektuje. U zavisnosti od osnovnog cilja kojem SPO treba da udovolji, uspostavljaju se bliži kriterijumi selekcije, na osnovu kojih se vrši izbor kandidata za bazu SPO (npr. iz istog okruženja, selekcije podataka za SPO u marketingu i proizvodnji biće vrlo različite). Za drugu fazu - preslikavanje podataka, osnovni kriterijum je zadat u postavci problema koji predmetni SPO treba da rješava. Znači, u zavisnosti od svrhe i cilja koji je postavljen pred SPO, rezultat i kvalitet preslikavanja vrednuju se kroz sposobnost SPO da riješi problem radi kojeg je projektovan. Preslikavanje obuhvata podatke razlikujući ih po vrsti, kao: "tvrde" ekzaktne podatke, koji odražavaju stanje i promene u sistemu i okruženju; "meke" podatke sačuvane u iskustvu eksperata i/ili dobivene kao rezultat prognoza, predviĎanja, procjena, simulacija, heurističkih, intuitivnih ili nekih drugih modela. Podsistem za upravljanje modelima sastoji se iz sljedećih elemenata: baze modela; sistema za upravljanje bazom modela; jezika za modeliranje direktorijuma modela i komandnog procesora. Integracijom ovih elemenata dobiva se podsistem, koji je softverski paket i sadrži finansijske, statističke i druge kvantitativne modele preko kojih se obezbjeĎuju visoke analitičke sposobnosti sistema. Ovaj podsistem treba da omogući svakom SPO integraciju pristupa podacima i modelima odlučivanja. Taj posao je veoma složen, jer zbog uobičajene strukture modela podrazumijeva postojanje konkretnih ulaznih podataka i odgovarajuću "predaju" izlaznih rezultata korisniku. Kada se ima u vidu priroda procesa odlučivanja, jasno je što su i dan danas, komunikacija i upravljanje modelima praktično prepušteni donosiocima odluka, kao "ručni" i intelektualni proces. Tipični modeli koji se nalaze u bazi modela SPO spadaju u grupu strateških i taktičkih, sa mogućnošću uključivanja i vrlo specifičnih modela za pojedine aplikacije. Ključne osobine SPO u podsistemu modela uključuju sposobnosti: kreiranja novih modela brzo i jednostavno; pristupa integraciji "blokova modela"; katalogiziranja i održavanja širokog obima modela za različite korisnike; povezivanja ovih modela sa odgovarajućim vezama u bazi podataka i upravljanje bazom modela. Sistemi za podršku odlučivanju koji posjeduju sisteme za upravljanje znanjem nazivaju se inteligentni sistemi za podršku odlučivanju, sistemi zasnovani na znanju ili jednostavno kombinacija SPO/ES. Baza znanja je predstavljala sinonim za ekspertne sisteme.
Podsistem korisniĉkog interfejsa je softverski podsistem za artikulaciju zahtjeva korisnika i prezentaciju izlaza iz sistema za podršku odlučivanju. Ima složenu funkciju koju realizuje putem svoje četiri komponente: alati za izradu korisničkog interfejsa, generatori, upiti i alati za izvještavanje; jezik za pokretanje akcije: šta korisnik može da uradi u komunikaciji sa sistemom putem tastature, funkcijskih tipki, taktilnog panela, džojstika, upravljanje glasom i dr.; jezik za prikaz ili prezentaciju: šta korisnik može da vidi (aktivira: printer, ploter, ekran, audio izlaz i sl.); baza znanja: šta korisnik treba da zna: korisnički priručnik (on-line manuel, serije help funkcija i sl.). Ovaj sistem pokriva sve aspekte komunikacije izmeĎu korisnika i sistema za podršku menadžmentu. Od kvaliteta korisničkog interfejsa zavisi mogućnost upotrebe i prihvatljivosti sistema od strane korisnika. Novi sistem za podršku odlučivanju posjeduje takav korisnički interfejs koji im omogućava: grafičiki korisnički interfejs; prilagoĎava korisniku različite dolazne/izlazne ureĎaje; predstavlja podatke u različitim formatima ili na različitim ureĎajima; obezbeĎuje interakciju sa bazom podataka i sa bazom modela: obezbjeĎuje kolor grafiku, trodimenzoinalnu grafiku; dozvoljava da se kroz više prozora izvršava više funkcija istovremeno; obezbjeĎuje učenje kroz primjere i obezbeĎuje fleksibilnost i adaptivnost sistema za podršku menadžmentu prema prilagoĎavanju različitim problemima i tehnologijama.
3.3.3. VRSTE SISTEMA ZA PODRŠKU ODLUČIVANJA
Komunikacioni SPO Komunikacioni SPO je tip SPO koji ističe komunikacije, saradnju i zajedničko odlučivanje. Obična oglasna ploča ili e-mail je najelementarniji nivo funkcionalnosti. Groupware prema definiciji FAQ, jeste softver i hardver za podjelu interaktivnog okruženja, namijenjen da podrži i proširi grupnu aktivnost. Komunikacioni SPO omogućava dvjema ili više osoba da meĎusobno komuniciraju, razmenjuju informacije i koordiniraju aktivnosti. Grupni sistem za podršku odlučivanju (GSPO) je hibridni tip SPO koji omogućava većem broju korisnika da saraĎuju u zajedničkom poslu koristeći raznolike softverske alate. Primjeri alata za GSPO su: audio konferencija, oglasne table, web konferencija, elektronska pošta, interaktivni video i sl. Komunikacioni SPO imaju bar jednu od sljedećih karakteristika: omogućavaju komunikaciju izmeĎu grupa ljudi; olakšavaju razmjenu informacija; podržavaju saradnju i koordinaciju izmeĎu ljudi i podržavaju zadatke u vezi sa grupnim odlučivanjem. Ključna istraživanja o komunikacijskim SPO uključuju: uticaj na grupni način rada i značaj grupe, meĎuveza više korisnika, kontrolu konkurentnosti, komunikaciju i koordinaciju unutar grupe, prostor zajedničkih informacija i podršku raznorodnosti, otvoreno okruženje koje integriše postojeće aplikacije pojedinih učesnika. Komunikacioni SPO su obično kategorizovani prema matrici vrijeme/lokacija, koristeći odlike izmeĎu istog vremena (sinhronizovani) i različitog vremena (nesinhronizovani), i izmeĎu istog mjesta (oči u oči) i različitih mjesta (distributivni).
SPO orijantisan podacima (Data- driven DSS) SPO orijantisan podacima je tip SPO koji ističe pristup i manipulaciju vremenskim serijama internih podataka kompanije i ponekad eksternih podataka. Jednostavan sistem datoteka sa ulaznim upitom i alat za pretraživanje obezbeĎuju elementarni nivo funkcionalnosti. DW (Data Warehouse) sistem omogućava efikasan pristup ovim podacima pomoću kompjuterskih alata prilagoĎenih specifičnim zadacima, kao i pomoću opštih alata koji obezbjeĎuju dodatnu funkcionalnost. SPO orijentisani podacima, specijalne namjene su: Executive Information Systems (EIS) - kompjuterizovani sistemi namijenjeni da obezbjede tekuće i odgovarajuće informacije za podršku odlučivanju menadžerima koji rade na umreženim radnim mjestima. Akcenat je na grafičkom prikazu i interfejsu lakom za korišćenje, koji prezentuje informacije iz korporacijske baze podataka. Geographic Information Systems (GIS) - sistem podrške koji koristi mape za prezentovanje podataka. Koristi se u analizi podataka koji imaju geografsko značenje. Document – Driven DSS (Knowledge Management System) Document - Driven DSS je relativno novo polje u podršci odlučivanju. Orijentisan je na pretraživanje nestrukturiranih dokumenata i Web stranica velikih baza podataka dokumenata, baza podataka za hiper tekst, slike, zvuk i video. Primjeri za ovaj tip su policijske baze podataka, specifikacija proizvoda, katalozi. Efikasna pretraga je glavni zadatak ovih sistema.
Sugestivni SPO (Knowledge – Driven DSS) Sugestivni SPO može preporučiti ili sugerisati akcije menadžeru. Ovi SPO su sistemi personalnih računara sa specijalnim iskustvom za rješavanje problema. To "iskustvo" sadrži znanje o posebnoj oblasti, razumijevanje problema unutar te oblasti i sposobnost rješavanja nekih od ovih problema. Blizak koncept je DM (Data Mining). To je proces pretraživanja velike količine podataka radi pronalaženja kontekstnih veza meĎu tim podacima. Ovi sistemi koriste specifične modele za procesiranje pravila ili za identifikaciju veza izmeĎu podataka. Modeli odlučivanja (Model – Driven DSS) Donošenje odluke je jednostavno ako su razmotreni svi relevantni faktori koji se tiču odreĎivanja posljedica, što je uglavnom nemoguće, pa tako ni odgovarajući model ne može biti sveobuhvatan. U svakom slučaju, model koji predstavlja realni sistem može obezbijediti rezultate koji će biti osnova za donošenje odluke. Model- Driven DSS stavljaju akcenat na izgradnju i proučavanje modela (statističkih, finansijskih, simulacionih i sl.). Jednostavni statistički i analitički alati obezbeĎuju elementarni nivo funkcionalnosti. Web orijentisani SPO (Web – based DSS) Web orijentisani SPO predstavljaju sisteme koji su implementirani upotrebom Web tehnologija. Oni omogućavaju menadžerima i poslovnim analitičarima upotrebu SPO alata koristeći Web browser-e (Netscape Navigator, Internet explorer) na "tankom" klijentu. Server koji opslužuje SPO je povezan sa korisničkim kompjuterima mrežnim TCP/IP protokolom. Ovakvi SPO sistemi omogućavaju velikoj grupi menadžera da korišćenjem Web browser-a u mrežnom klijent - server okruženju, donose pojedinačne ili grupne odluke, kao i da pristupaju bazi podataka kao dijelu SPO arhitekture. Može se reći da Web tehnologije predstavljaju primarne alate za razvoj interorganizacionih SPO. Organizacioni model odlučivanja (InterOrganisational DSS) Organizacioni modeli odlučivanja su relativno nova kategorija SPO nastala sa pojavom interneta. Internet daje komunikacionu vezu sa više tipova interorganizacionih sistema, uključujući i SPO. Organizaciono donošenje odluke predstavlja posebnu klasu procesa odlučivanja u odnosu na individualno odlučivanje. Interorganizacioni sistemi omogućavaju udaljenim korisnicima da pristupe kompanijskom intranetu i, ukoliko imaju autorizovanu privilegiju, da koriste odreĎene SPO servise. Tako, npr., kompanija može učiniti dostupnim SPO zasnovan na podacima za svoje dobavljače ili SPO zasnovan na modelima za kupce, kako bi im se omogućilo da dizajniraju ili izaberu odgovarajući proizvod.
Funkcionalni SPO (Function – Specific DSS) Funkcionalno-specifični SPO predstavljaju sisteme koji su specijalno dizajnirani da podrže odreĎene poslovne funkcije ili tipove poslovanja. To mogu biti sistemi za podršku neke funkcionalne oblasti u poslovnom sistemu, kao što su marketing ili finansije. Ovi sistemi se obično dizajniraju za jedan
specifičan zadatak, kao što je, raspored letenja u avio kompaniji i sl. Sa druge strane, oni se po svojoj prirodi mogu svrstati u neku od glavnih kategorija SPO sistema, kao što su SPO zasnovani na podacima, modelima ili sugestivni SPO. SPO kao integrator informatičkih i upravljačkih procesa Jedan od pravaca razvoja SPO jeste i približavanje i integracija dva, doskora odvojena trenda - obrade podataka (Data Processing), koja je proizvela kritičnu masu znanja o upravljanju podacima, i upravljačke nauke (Management Science), koja je proizvela kritičnu masu znanja o upravljanju modeliranju. Spajanjem ta dva trenda nastaju dva osnovna resursa sa kojima donosilac odluke ostvaruje dijalog u procesu odlučivanja. Ovi elementi: podaci, modeliranje i interakcija (dijalog), čine zapravo paradigmu dijalog-podacimodel, koja je osnova SPO. Razvoj obrade podataka, posljednjih decenija, tekao je od bazičnih obrada do upitnih jezika. Manjim ili većim koracima, razvijalo se i modeliranje. Ono što je već sada vidljivo i izvjesno, to je konvergencija ovih evolucija. Ranije brojne diskusije o "podacima orijentisanim SPO" nasuprot "modelima orijentisanim SPO" postaće bespredmetne - SPO će predstavljati potreban balans izmeĎu ovih trendova. Na razvojnom putu oba trenda nalazi se vještačka inteligencija - korišćena kao sredstvo za organizaciju i upravljanje bazama podataka, ili kao sredstvo za generisanje modela, ali i kao sredstvo za razvoj dijaloga-uključivanjem tehnika prirodnog jezika i prepoznavanja glasa.
3.3.4. GSPO - GRUPNI SISTEM ZA PODRŠKU ODLUČIVANJA Kada govorimo o sistemu za podršku odlučivanja misli se uglavnom na personalnu podršku odlučivanja. Personalne ili lične sisteme za podršku odlučivanja, koji su na neki način sinonim za SPO, koriste pojedinci, tako da korisnik individualno može da donese odluku. MeĎutim, veoma važne organizacione odluke donose grupe ljudi i to naročito na strateškom nivou. Znači, kako organizacija postaje kompleksnija, tako sve manji broj odluka donose pojedinci. Odgovornost se distribuira na više učesnika i odlučivanje postaje posao grupe ljudi. Pojavom automatizacije kancelarijskog poslovanja (Office Automation) kreirani su alati tipa elektronske pošte i elektronske konferencije (sastanak uz pomoć kompjutera), koji zamjenjuju grupne sastanke na jednom mjestu. Pravi smisao upotrebe ovih alata postiže se integracijom u SPO koncept, odnosno uključivanjem SPO u kontekst automatizacije poslovanja. Rezultat te integracije je GDSS (Group Decision Support System), odnosno GSPO -grupni sistem za podršku odlučivanja. U analizi GSPO, pored dijaloga, modela i podataka, sreće se nova komponenta u obliku komunikacionih procedura. Ako je SPO interaktivni kompjuterski bazirani sistem, koji pomaže u rješavanju slabostrukturiranih problema, analogno tome GSPO je interaktivni kompjuterski bazirani sistem, koji pomaže u rješavanju nestrukturiranih problema skupa ljudi koji odlučuju radeći zajedno kao grupa. Po Spragu i Karlsonu, softverske komponente GSPO sadrže bazu podataka, bazu modela, specijalizovane aplikacione programe za grupno korišćenje i fleksibilne korisničke interfejse jednostavne za upotrebu. Kvalitetan GSPO pored baza podataka i baza modela sadrži i jezike visokog nivoa kao i interfejse sa standardnim softverom (npr. grafički i statistički za operaciona istraživanja). Članovi grupe zajedno sa tzv. grupnim posrednikom, odnosno mediatorom, predstavljaju grupnu komponentu GSPO pri čemu uloga posrednika dosta zavisi od specifičnosti odreĎenog softvera, problema ili korisnika. Procedure kao posljednja GSPO komponenta, omogućavaju efikasno korišćenje tehnologije od strane članova grupe. One se mogu odnositi samo na hardverske i softverske elemente, ali se mogu proširiti na pravila ponašanja koja važe u komunikaciji pojedinih korisnika. Ovaj model ilustruje :
Slika 7. Model GSPO po Spragu i Karlsonu 3.3.5. IZGRADNJA SISTEMA ZA PODRŠKU ODLUČIVANJA U principu SPO se može dizajnirati odnosno izgraĎivati uz korišćenje bilo koje raspoložive tehnologije. MeĎutim, tradicionalni pristupi analize i dizajna pokazali su se neadekvatni tako da savremeni dizajn SPO autori Sprag i Karlson baziraju na sljedećim principima: Sistemska analiza; iako računar zahtjeva dobro definisane procese, SPO mora biti nezavisan od unaprijed definisanih procedura odvijanja pojedinih aktivnosti, jer razni korisnici mogu pristupiti rješavanju problema na različite načine. ROMC (Representation, Operations, Memory Aids and Control) pristup sistemskoj analizi za SPO predstavlja paradigmu za odreĎivanje performansi sistema u najvećem broju poznatih istraživanja. Iterativni dizajn; tipični proces razvoja sistema (analiza, dizajn, konstrukcija -projektovanje, programiranje, implementacija) ovdje se kombinuje u jedan korak i iterativno ponavlja. Suština ovog pristupa je da se korisnik i projektant slože oko malih ali izraženih problema, a zatim izgrade inicijalni sistem za podršku potrebnom odlučivanju. Nakon izvjesnog vremena sistem evoluira, modifikuje se i proširuje. Ovaj ciklus se nekoliko puta ponavlja dok se ne dobije relativno stabilan sistem za odreĎenu grupu problema. Adaptivni sistem; SPO je adaptivni sistem koji se mijenja na tri vremenska horizonta tj. sistem istražuje i traži odgovore unutar relativno uskog intervala. U meĎuhorizontu sistem uči modifikujući svoje mogućnosti i aktivnosti i na kraju sistem evoluira da bi zadovoljio različite stilove i mogućnosti.
Kompleksni sistemi zasnovani na SPO konceptu mogu se modifikovati na bazi tehnika iz domena vještačke inteligencije, a posebno na funkcionalnim prototipovima ekspertnih sistema. Kod prototipova vještačke inteligencije težište je na unutrašnjoj logici sistema koji se želi razviti, za razliku od tradicionalnog razvoja prototipa gdje je težište na spoljnoj formi sistema (npr. izvještaji). U tom smislu mogu se koristiti sljedeće tehnike vještačke inteligencije: Shell - kostur programi tj. jezici visokog nivoa, čime se projektantu omogućava jezik za specificiranje samo logičkih pravila i u nekim slučajevima kontrolnih tokova. Oni dozvoljavaju projektantu da eksplicitno predstavi znanje o tome kako se rješava problem. Dakle, znanje i logika odlučivanja mogu se jednostavno predstaviti i modifikovati prema potrebi. Izrada prototipa bazirana je na rastu razvojnog procesa. Kako je znanje eksplicitno predstavljeno, jer shell softver garantuje ukupnu arhitekturu sistema, takvo programiranje zahtijeva znatno manje inicijalnog rada na dizajnu nego klasično programiranje. Svaki segment znanja može se posmatrati izolovano, tako da se lako može dodavati novi segment i na taj način povećavati domen SPO bez uticaja na integritet sistema. Koristi se razvojna metodologija orijentisana na konkretni slučaj. Naime, karakteristika kompleksnih logičkih aplikacija je da se one često odvijaju na osnovu znanja pojedinaca koji rade instinktivno, a ne na osnovu neke unaprijed propisane i formalizovane procedure. Dok transakcione aplikacije mogu relativno lako i dobro definisati oni koji ih izvršavaju, dotle kod SPO eksperti za odreĎeni problem najčešće znaju način kako se to radi, ali pod uslovom kada vide konkretnu situaciju. Razvojni proces funkcionalnog prototipa vještačke inteligencije od šest koraka, koji je inaugurisao Vajsman 1987. godine, jedna je od tehnika razvoja kompleksnih i modularnih projekata. TakoĎe je i dobra osnova za primjenu kod metodologija izgradnje SPO. Dakle funkcionalni prototip se razvija u sljedećih šest koraka: 1. Intervjui u kojima ekspert za funkcionisanje samog objektnog sistema diskutuje o budućem SPO sa projektnim timom tako što opisuje situacije u kojima će se koristiti SPO. 2. Inicijalna implementacija, eventualno uz korišćenje nekog kostura (shell) sistema baziranog na pravilima kako bi ekspert za funkcionisanje sistema mogao dalje da usavršava model. 3. Analiza slučaja treba da identifikuje izuzetke i ostale situacije za koje se SPO može proširiti. 4. Filtriranje znanja je faza u kojoj se prototip pročišćava nakon identifikovanja novih situacija. 5. Korisnička verifikacija i primjena SPO nakon što ekspert za funkcionisanje objektnog sistema izvrši recenziju pojedinih segmenata sa aspekta tačnosti. 6. Dokumentacija se pravi nakon što je ekspert izvršio evaluaciju modela, te njegove interne logike ili baze znanja. U odnosu na prethodne faze razvoja informacionih sistema, SPO zadržava sve njihove prednosti, ali se istovremeno nadgraĎuje u obliku: raznovrsnijeg i manje strukturiranog izvještavanja, kvalitetnijeg grafičkog dizajna izlaza, redukovanjuštampanih dokumenata na ulazu i uvoĎenja elektronske pošte i tele-konferisanja itd.
3.3.6. PERSPEKTIVA SISTEMA ZA PODRŠKU ODLUČIVANJA
Turban uporeĎuje Sistem za podršku odlučivanja (DSS) i Upravljački informacioni sistem (MIS) kroz pet osnovnih dimenzija: Dimenzije Upotreba
DSS Aktivna
MIS Pasivna
Korisnik
Menadžment organizacija
Službenici
Cilj
Efektivnost
Tehnička efikasnost
Vremenski horizont
Sadašnjost i budućnost
Prošlost
Osobenost
Fleksibilnost
Konzistentnost
Tabela 3. PoreĊenje DSS-a i MIS-a U bliskoj budućnosti SPO sistemi će doživjeti velike transformacije. Njihovo korišćenje biće mnogo značajnije nego danas. Koristiće se za donošenje ne samo minornih već i veoma važnih odluka u korisnikovo ime. Tačnost i tolerantnost te perspektive je drugi tip pitanja. Uloga čovjeka ostaće dominantna, samo je pitanje stepen pomoći SPO korisniku. Tehnički aspekt budućeg SPO uvažiće napredak hardvera u kompjuterskoj tehnologiji. Mikrokompjuteri i mreže, kao i multimedijalne strukture (audio i video) postaju njegovi bitni elementi. Pristupi do velikih i raspoloživih svjetskih banaka podataka, kao i korišćenje Interneta, u kontekstu su novih mogućnosti koje pružaju komunikacione mreže. Koncepcija jedan čip - jedan SPO stvara propulziju koju treba porediti sa pojavom kalkulatora početkom sedamdesetih godina. Softverski aspekt implicira korišćenje vještačke inteligencije, kao veoma važno odreĎenje perspektive SPO. TakoĎe, veliki napori se ulažu u procesore prirodnog ili skoro prirodnog jezika za korišćenje SPO. Suština je da korisnik sa SPO uspostavi što neposredniju komunikaciju odnosno dijalog na način sličan konverzaciji sa kolegom. Isto tako težište razvoja SPO je primjena ekspertnih sistema i njihova integracija u SPO. Tu je potrebno uspostaviti relacije i pravila povezivanja ekspertnih sistema u jedan integralan sistem koji ima karakteristike SPO. Budući dizajn SPO ilustruje:
Slika 8. Dizajn nove generacije SPO Budući tipični SPO biće povezan sa drugim informacionim sistemima. Njegove mogućnosti i velika upotreba učiniće ga prisutnim kako u čovjekovom radnom tako i u privatnom okruženju. Izgradnja SPO na principu prototipova relativno će mu smanjiti cijenu i učiniće mu upotrebu jednokratnom. Princip prototipova predstavlja jedan korak dalje od sistemskog pristupa i kao takav može se koristiti samo za jednostavnije aplikacije. Perspektiva GDSS-a leži u što većoj integraciji različitih SPO-a i njihovoj interaktivnosti kao skupa slobodnih entiteta.
3.4. EKSPERTNI SISTEMI
3.4.1. POJAM EKSPERTNIH SISTEMA
Razvoj računara i njegove mogućnosti dovode ga do oblasti u kojoj se na računaru pokušavaju modelirati procesi ljudskog mišljenja. Razvoj ove naučne discipline, koja se bavi metodama, tehnikama, alatima i arhitekturama za rješavanje logički komplikovanih problema odvija se u dva pravca. Prvi podrazumijeva postizanje inteligentnijeg ponašanja računara koji će biti što upotrebljiviji, a drugi modeliranje na računaru procesa ljudskog mišljenja i time doprinošenje razumijevanju čovjekovog inteligentnog ponašanja. Kao posljedica tog nastojanja došlo je do pojave ekspertnih sistema. To su računarski programi čiji algoritmi realizovani različitim metodama vjestačke inteligencije rješavaju probleme na osnovu znanja iz nekog uskog područja. Znanje koje takav sistem posjeduje formira se uz pomoć eksperta na bazi pravila zaključivanja i podataka neophodnih za rješavanje tih problema. Kasnije ekspert koristi taj računarski program da bi riješio neki jos složeniji problem iz te oblasti. Rješavanje takvog problema takoĎe se memoriše u bazu znanja, čime ekspertni sistem dinamički povećava svoje znanje i mogućnosti. Osnovna pretpostavka na kojoj se zasniva oblast ekspertnih sistema je ta da je znanje moguće predstaviti simboličkim izrazima i to preko simboličkih opisa, kojima se odlikuju definicioni i empirijski odnosi u posmatranom području i postupaka za manipulaciju tim odnosima. Terminološki gledano paralelno sa terminom ekspertni sistemi za isti pojam koriste se i sljedeći termini: sistem zasnovan na znanju, inteligentni informacioni sistem, inteligentni sistem zasnovan na znanju, te sistem znanja. Ekspertnost se može definisati kao znanje, razumijevanje i vještina rješavanja problema u odreĎenoj oblasti. Jednu od prvih definicija ekspertnih sistema dao je Fingenbaum i ona glasi: “Ekspertni sistem je inteligentni računarski program koji koristi znanje i mehanizme zaključivanja u rješavanju problema takve složenosti da je za njihovo rješavanje potreban čovjek ekspert”. Znanja u ekspertnim sistemima čine činjenice i heuristika (iskustvo i osjećaj).Činjenice su glavni dio informacija široko distribuiranih, javno raspoloživih i usaglašenih na nivou eksperata (stručnjaka) u oblasti. Heuristika su lična, malo distribuirana pravila prihvatljivog rasuĎivanja, koje karakteriše odlučivanje na nivou eksperta u oblasti. Performanse ekspertnih sistema su funkcija veličine i kvaliteta baze znanja, a ne odreĎenog formalizma i mehanizma zaključivanja. Buhman je definisao ekspertne sisteme preko sljedećih osobina: ekspertiza - cilj je da sistem dostigne visok stepen performansi koje postiže čovjek - ekspert u nekom zadatku; rezonovanje manipulacijom simbola; opšta sposobnost rješavanja problema u datom domenu; složenost i težina, jer problemi u datom domenu moraju da budu dovoljno složeni i teški da bi se zahtijevalo rješenje eksperata; reformulacija -preobražavanje prvobitne forme u kojoj je problem bio postavljen u formu podesnu za obradu prema ekspertskim pravilima; rezonovanje o sebi - skup zahtjevanih sposobnosti u sistemu koji omogućavaju da sistem rezonuje o sopstvenim procesima i vrsta zadatka začije se obavljanje sistem izgraĎuje. Na sličan način Hajes-Rot daje sljedeće karakteristike: sličnost koja je obezbijeĎena pravilima visokog nivoa, gdje se izbjegava slijepo pretraživanje,što rezultuje visokim performansama i robusnošću, rasuĎivanje koje je dato simboličkim predstavljanjem znanja i manipulisanjem simbolima, "pamet" kao osnovni principi oblasti i "slabi" (nealgoritamski) metodi rasuĎivanja,
mogućnost reformulacije simboličkog znanja, konverzije iz opisa u oblik pogodan za primjenu ekspertnih pravila, rasuĎivanje "o sebi", tj. ispitivanje sopstvenog rasuĎivanja i objašnjenje svog rada i tip zadatka. Najpotpuniju definiciju ekspertnih sistema dalo je Britansko društvo za računare koja glasi: "Pod ekspertnim sistemima podrazumijeva se realizacija računarski bazirane vještine nekog eksperta čija je osnova u znanju i u takvom obliku da sistem može da ponudi inteligentan savjet ili da preuzme inteligentnu odluku o funkciji koja je u postupku. Ekspertni sistem posjeduje i karakteristiku da na zahtjev verifikuje svoju liniju rezonovanja, tako da direktno obavještava korisnika koji postavlja pitanje". Sistemski posmatrano pod ekspertnim sistemom podrazumijeva se podsistem područja vještačke inteligencije. U ostale podsisteme spadaju još robotika, obrada prirodnim jezikom, igre i računarska grafika. Područje izgradnje ekspertnih sistema poznato je kao naučni inženjering (Knowledge Engineering). Ekspertni sistemi su dakle, skup kompjuterskih programa koji postižu visoki stepen rješavanja problema, a zahtijevaju dugogodišnje stručno obrazovanje pojedinaca. Paralelno sa razvojem tehnologije ova definicija ekspertnih sistema zahtijeva ne samo stručnu izgraĎenost, nego i dodatne stručne kvalitete pojedinca. U ekspertnom sistemu lično znanje stručnjaka uključujući činjenično, ocjenjivačko i proceduralno znanje razvijeno je u "bazu znanja" odreĎenog područja u kojem se čovjek smatra ekspertom i zbog toga je sistem baziran na znanju. Naučna osnova može sadržavati stručno znanje s područja organizacije, procesnog planiranja, dizajniranja sredstava itd. Naučna osnova se uopšte odvaja od kontrolnog mehanizma rješavanja problema koji predstavljaju mehanizam zaključivanja. Odvajanje logike i kontrole omogućava upotrebu mehanizma zaključivanja za veći broj naučnih osnova konstruisanih za različita područja primjene. Na primjer, isti opšti mehanizam zaključivanja upotrijebljen je za rješavanje problema dijagnostike krvnih infektivnih bolesti kao i strukturirana analiza mehaničkih komponenata u kombinaciji sa odgovarajućom naučnom osnovom za oba područja koja se meĎusobno potpuno razlikuju. Postojeći jednostavni softver bavi se kvantitativnim pitanjima te rukovodiocima predstavlja alat za baratanje podacima. Ekspertni sistem za razliku od konvencionalnih tehnika, predstavlja informacioni sistem koji koristi bazu znanja te služi kao konsultant rukovodiocu. Ekspertni sistemi predstavljaju pokušaj da se u kompjuterske programe ugrade procesi razmišljanja i odlučivanja koji se odvijaju kod ljudi eksperata, što znači da će se dobiti kompjuterski savjetnici. Prema aktivnostima ekspertnih sistema izgraĎena je jedna njihova klasifikacija u tabeli: Oblast primjene
Tipiĉan ES
Aktivnosti ES
Naznaka problema
Interpretacija
Sistemi tumače opažene podatke pripisuju im simbolična značenja i opisuju situacije i stanja
Hemija Geologija Medicina Armija
DENDRAL ELAS LIFHO PUFF
Dijagnostika
Sistemi za dijagnostiku na osnovu podataka o opservacijama definišu malfunkcije sistema
Računari Elektronika Geologija Medicina
BDS DART ACE MYCIN
PredviĊanje
Sistemi za predviĎanje posljedica (prognoza) iz modela i parametara
Računari Armija
PTRANS I&M
Oblikovanje
Sistemi za dizajn konfigurišuobjekate u zadatim ograničenjima
Računari Hemija Elektronika
XCON MOLGEN PALLADIO
Planiranje
Sistemi za planiranje oblikuju akcije i objekte
Hemija Računari
SPEX MOLGEN
kao modele ponašanja da u cilju efekata planiranja Kontrolisanje
Sistemi za kontrolisanje adaptivno upravljaju ponašanjem sistema na osnovu interpretacije, prognostike i dijagnostike
Elktronika
PTRANS TALIB PTRANS YES/MIN VM
Tabela 4. Klasifikacija ekspertnih sistema
3.4.2. RAZVOJ EKSPERTNIH SISTEMA U preko trideset godina istraživanja, vještačka inteligencija pomogla je računarima da imitiraju razne čovjekove aktivnosti, ali je tek minimalno napredovala u smjeru oponašanja pravog čovjekovog razmišljanja. Otkako postoji, istraživanje vještačke inteligencije bilo je periodičko tj. ulazilo i izlazilo iz mode. U toku 1972. godine u SAD-u je vještačka inteligencija bila tako sistematski suzbijana da je finansiranje iste gotovo prestalo. Velika Britanija još uvijek osjeća posljedice odluke u svojoj trci da se modernizuje robotikom tj. dijelom vještačke inteligencije. Sredinom sedamdesetih godina istraživači su suzili svoje radove i povećali praktična istraživanja vještačke inteligencije. Umjesto da stvore univerzalnog ljudskog klona, energiju su usmjerili prema odreĎenim zadacima. Stoga je pažnja bila premještena na kontekstno zavisno komuniciranje. Rezultat toga bio je razvoj nekoliko interaktivnih dijaloških jezika. U SAD su se pojavile dvije vrste razvijenih prirodnih jezika. Jedni su se zasnivali na "skriptovanom dijalogu", dok su drugi bili dizajnirani za pretraživanje informacija. Odnedavno sve veći broj eksperimenata i radnih sistema koji koriste ekspertne sisteme rezultat je razvoja kompjuterskih programskih jezika za specifičnu namjenu kao sto su LISP i PROLOG. Osim toga, upravo su radovi prvih specijalista za vještačku inteligenciju dali osnovu koja je bila potrebna za savladavanje sve većih zahtjeva za korisnika usmjerenim sistemima. LISP i PROLOG su nazivi dva jezika koji se uopšte povezuju s ekspertnim sistemima. Ovi jezici su bili korišćeni prilikom stvaranja raznovrsnog softvera ekspertnih sistema. Za razliku od većkonvencionalnih BASIC-a i FORTRAN-a, koji su dizajnirani prvenstveno za obraĎivanje brojeva, LISP je dizajniran za obradu simbola, specijalno engleskih riječi i fraza. TakoĎe LISP posjeduje mehanizme za povezivanje simbola u pojmove u obliku pravila "ako-onda" ("IF-THEN"). Razlika u LISP programskom softveru je u tome što tradicionalni kompjuterski softver dizajniran za obradu podataka i proračuna (tj. tabelarne izvještaje) predstavlja nešto sasvim drugo u odnosu na nove softverske alate ekspertnih sistema, koji obraĎuju deduktivnu logiku u obliku pravila i relacija izmeĎu znanja. Ekspertni sistemi su svoju evoluciju počeli na području medicinske dijagnostike, a aplikacije se nisu proširile na druge discipline. Jedan od prvih sistema bio je MYCIN. Razvili su ga istraživači na američkom univerzitetu Stanford kao pomoć ljekarima u dijagnosticiranju bakterijskih infekcija. Pored ovog područja primjene, ekspertni sistemi su svoju ulogu našli u zamjeni čovjekovog partnera u igri (šah, tenis itd.), zatim u domenu zamjene tehničara, gdje na osnovu dijaloga sa korisnikom i upamćenog znanja dijagnosticira grešku. Ovakav ekspertni sistem razvio je IBM. Naime, sistemu se prezentiraju indikacije kvara, a sistem na osnovu njih generiše preporuke za popravak. Sljedeće važno područje primjene ekspertnih sistema je u vojsci, odnosno u planiranju i donošenju odluka. TakoĎe oni u saradnji sa modernom računarskom tehnologijom uspješno rješavaju logističke probleme i predstavljaju veliku podršku u strateškom i taktičkom planiranju. Ne treba zanemariti ni pomoć ekspertnih sistema u lociranju ležišta rude, te voĎenju složenih proizvodnih pogona.
U novije vrijeme oni predstavljaju više od 50% aktivnosti komercijalne vještačke inteligencije i imaju trend porasta. Što se tiče područja primjene ekspertnih sistema u preduzeću, konkretno na polju upravljanja i računovodstva, postoji nekoliko važnih momenata, koji opravdavaju usvajanje ove nove tehnologije. Najvažnije je da tehnologija kompenzuje ljudski rad uz odgovarajući stepen troškova i dobiti. TakoĎe, tehnologija prepoznaje potencijalna područja problema te povećava vjerovatnoću donošenja ispravnih odluka, odnosno povećava efikasnost preduzeća. Uopšte sistemi koji racionališu broj raspoloživih opcija u odlučivanju, unapreĎuju kvalitet preko uniformnosti te olakšavaju ocjenu kontrole kvaliteta. Isto tako, programi koji smanjuju vrijeme potrebno za donošenje odluke, ako je vrijeme ograničeno, predstavljaju značajnu korist. Gledajući primjer moderne prakse računovodstva i njegovu relativnu složenost, koja vodi do koncentracije stručnosti u specijalizovanim područjima. Kada se takva znanja sublimiraju u ekspertni sistem tada su dostupna svakom u preduzeću. Ekspertni sistemi su najčešće potrebni onda kada stručnjak u preduzeću nije dovoljno efikasan na područjima koja troše velike količine vremena usljed rutinskog i ponavljanog odlučivanja. Iako ekspertni sistem možda nije "inteligentan", njegove velike mogućnosti se odnose na saopštavanje znanja, očuvanje rijetkih ili skupih vještina, davanje smjernica, pomaganje pri donošenju odluka i prilikom uspostavljanja kompleksnih sistema. Zbog toga ovu novu tehnologiju možemo koristiti na mnogo načina s ciljem da ublažimo postojeću neefikasnost u poslovanju, slabu efikasnost i kontrolu kvaliteta, te smanjimo vrijeme školovanja početnika. Što se tiče postojeće primjene ekspertnih sistema, oni na sebe ne preuzimaju donošenje odluka na nivou preduzeća. Ovi sistemi postaju sve popularniji jer su formalni procesi odlučivanja, koje su prije vodili rukovodioci, zamijenjeni softverom predprogramirane logike u kojoj su kriterijumi za odluke unaprijed utvrĎeni. Pretpostavka je da se odluke ovih sistema prihvataju i provode u organizaciji. U višim krugovima rukovodstva, meĎutim, zadatke idejne prirode i one koji traže neformalne reakcije, možda nikada neće preuzeti na sebe ekspertni sistemi. Odluke koje se ponavljaju najbolji su kandidati za ekspertne sisteme jer su znanje, ocjene i iskustvo, koji se koriste prilikom donošenja ovih odluka, već sakupljeni i lako se mogu specificirati. Mnoge funkcije rukovodilaca na nižem i srednjem nivou sastoje se od specijalizovanih aktivnosti, koje su već spremne za provoĎenje u ekspertni sistem. Današnji ekspertni sistemi imaju relativno prilagoĎenu primjenu ekspertize pa zato rukovodiocima pružaju savjetodavnu pomoć. Radi lakšeg korišćenja, postojeći ekspertni sistemi su dizajnirani sa osnovnim mogućnostima za komunikaciju na donekle prirodan način, odnosno u skladu sa stručnim područjima. Osim toga, važna osobina postojećih sistema je mogućnost da se unazad prati logika i odgovori sistema kako bi se vidjelo zašto je neki odgovor takav. Ekspertni sistemi postavljaju niz pitanja i primjenjuju praktična pravila da analiziraju odgovore i proizvedu preporuke, te takoĎe objašnjavaju logiku kojom su došli do zadnjeg reda. Za razliku od konvencionalnih kompjuterskih programa ekspertni sistemi koriste kvalitativne kao i kvantitativne podatke. TakoĎe, mogu izvoditi zaključke i iz nepotpunih i neodreĎenih podataka. Razliku u odnosu na konvencionalne aplikacije isto tako predstavlja korisnička povezanost s prirodnim dijalogom. Današnji kompjuterski sistemi dolaze do zaključaka sistematskim prolazom po detaljnoj listi koraka koji su napisani u programu. To je bitna razlika u odnosu na ljude, koji do zaključaka obično dolaze sekvencijalnim postupkom što praktično znači ne pomoću skupa arbitrarnih pravila i logike, ranijeg iskustva, induktivnog zaključivanja i intuicije. Ova metoda donošenja odluka obično se naziva heuristikom. Ako je zadatak strukturiran, nije matematički, a izvršava se heuristikom, ekspertni sistem bi trebao biti idealna pomoć pri odlučivanju. Ako je zadatak izrazito strukturiran matematički, efikasniji je proceduralni program npr. u COBOL-u.
3.4.3. STRUKTURA EKSPERTNIH SISTEMA Ekspertni sistemi kao metoda vještačke inteligencije i u funkciji kloniranja eksperta u usko specijalizovanom području moraju u principu posjedovati sljedeće komponente odnosno module: bazu znanja, mehanizam zaključivanja i interfejs prema korisniku. Grafička interpretacija strukture ekspertnih sistema izgledala bi ovako:
Slika 9. Struktura ekspertnih sistema
Baza znanja sadrži znanje o specifičnom problemskom području: pravila koja opisuju relacije i dogaĎaje, a ponekad i metode, heuristike i ideje za rješavanje problema na konkretnom području. Mehanizam zakljuĉivanja omogućava aktivnu upotrebu znanja o području za izvoĎenje zaključaka. Interfejs obezbjeĎuje komunikaciju izmeĎu čovjeka sa sistemom i treba da omogući relativno komfornu interakcijušto uključuje i mogućnost objašnjenja kako je sistem došao do odreĎenog zaključka. Ekspertni sistemi uglavnom su realizovani kao sistemi voĎeni uzorcima (pattern directed systems). Ovdje se radi o arhitekturi programskih sistema, koja se bitno razlikuje od konvencionalne strukture programskih sistema. U konvencionalnoj arhitekturi moduli su organizovani hijerarhijski, a tok izvoĎenja je u znatnoj mjeri determinisan, odnosno unaprijed poznat. Svaki tekući modul odreĎuje koji modul će se izvesti kao sljedeći. Kod sistema voĎenih uzorcima hijerarhija meĎu modulima ne postoji. Moduli se aktiviraju uzorcima iz "okruženja sistema", što ovdje predstavlja bazu podataka. Evidentno je da takva organizacija dozvoljava i istovremeno izvoĎenje više modula te na taj način služi kao model paralelnih, distribuiranih procesa. MeĎutim, za implementaciju na sekvencijalnom računaru potreban je kontrolni modul, koji u slučaju kad uzorak izabere više modula, odredi za izvoĎenje samo jednog izmeĎu njih. Kod tih sistema dakle imamo cikluse koji sadrže: pretraživanje baze podataka, da se naĎu uzorci koji predstavljaju uslov za aktiviranje nekog modula; time se dobija konfliktan skup potencijalno aktivnih modula,
razrješavanje konflikta, predstavlja odreĎivanje jednog od modula iz konfliktnog skupa i izvoĎenje izabranog modula. Prednosti takve arhitekture sistema su u visokom stepenu modularnosti, što se veoma povoljno odražava kod komplikovanih baza znanja gdje je teško unaprijed pretpostaviti sve interakcije meĎu pojedinim elementima. Zatim, oni omogućavaju da je algoritamski dio sistema (mehanizam zaključivanja) odvojen od baze znanja, čime je moguća upotreba istog mehanizma zaključivanja za različite baze znanja. Osim toga ima problema za čije rješavanje je takva organizacija sasvim prirodna, kao na primjer u slučaju kompleksnih procesnih sistema, gdje mjerene vrijednosti pojedinih parametara u nekim slučajevima treba da aktiviraju odreĎenu akciju. Zbog komparacije uzoraka (prva tačka u gore navedenom ciklusu) sistemi voĎeni uzorcima mogu biti veoma spori. Da bi se prevazišao taj problem, često uvodimo tzv. "meta-pravila" koja govore o tome kako upotrebljavati ostala pravila. Druga tehnika za poboljšanje efikasnosti je hijerarhijsko grupisanje kako pravila tako i baza podataka. U nekim oblastima, u prvom redu u onima gdje postoje dobra algoritamska rješenja, arhitektura sistema voĎenog uzorcima ponekad nije najprikladnija. Postoji više tipova sistema voĎenih uzorcima. U prvom redu razlikujemo sisteme koji se baziraju na pravilima (rule-based systems) i mrežne sisteme (network-based systems). Kod prvih moduli se sastoje iz pravila u obliku "antecedens - konsekvens" odnosno "lijeva strana - desna strana pravila". Obično lijeva strana odreĎuje uzorke - uslove, da se pravilo aktivira, a desna strana odreĎuje operacije koje se trebaju izvesti. Kod mrežnih sistema moduli su predstavljeni kaočvorovi u mreži. Čvorovi specificiraju akcije, a aktiviraju se pod uslovom da doĎe "poruka" (signal) preko jedne ili više ulaznih veza. Sistemi bazirani na pravilima dijele se na produkcione sisteme (production systems) i transformacione sisteme (transformation systems). Znanje u jednima i drugima predstavljeno je sa pravilima i podacima. Produkcioni sistemi imaju fiksnu kontrolnu strukturu za odreĎivanje izbora sljedećeg pravila za aktiviranje, a kod transformacionih sistema toga nema. Produkcioni sistemi se dijele na lijevo voĎene i desno voĎene sisteme. Kod prvih antecedens pravila vodi traženje pravila koje treba da se izvede sljedeće, a kod drugih tu ulogu ima konsekvens pravila.
Baza znanja Kvalitet ekspertnog sistema uglavnom je funkcija obima i kvaliteta njegove baze znanja. Ovu konstataciju apostrofiraju autori Harmon i King. Baza znanja sadrži znanje o specificnom problemskom području: pravila koja opisuju relacije i dogaĎaje, a ponekad metode, heuristike i ideje za rješavanje problema na konkretnom području. U bazi znači nalazimo dva tipa znanja: činjenice koje su javno dostupne i u struci opšteprihvaćene i heuristike, to su ekspertna pravila zaključivanja i odlučivanja, koja karakterišu stepen ekspertnosti. Ovdje je karakteristično pitanje, kako predstaviti bazu znanja u računaru. Postoje brojni formalizmi za predstavljanje znanja i u principu bi se mogao upotrebiti svaki konzistentan formalizam, u kojem je moguće izraziti znanje o problemskom domenu. Ipak se kod ekspertnih sistema odlučujemo za one, koji daju podršku modularnosti, inkrementalnosti i lakoj promjenljivosti baze znanja. Za tzv. "meka" područja, gdje zakonitosti važe samo do nekog stepena i ne apsolutno, formalizam treba da modeluje i tu vjerovatnu prirodu znanja. Evidentno je da se eksperti za rješavanje problema u velikoj mjeri služe svojim iskustvenim relativno skromnim znanjem. Takvo znanje je veoma operativno i može biti dovoljno za rješavanje problema u većini primjera. Tek kada doĎe do novog, težeg problema ili kada rješenje treba obrazložiti, ekspert
upotrebi svoje kvalitetnije znanje, to je razumijevanje strukture i dubljih principa problemskog domena. Hronološki gledano, baze znanja u "prvoj generaciji" ekspertnih sistema uglavnom se sastoje od ekspertnih pravila, koja odražavaju skromno znanje i veoma su efikasna. Do eventualnih problema može doći, kada su te baze glomazne, pa je osim problema sa prostorom i provjera njihove kozistentnosti i kompletnosti veoma teška. Zatim, ima primjera kada je potrebno što je moguće potpunije i temeljitije obrazloženje, npr. u sistemima za edukaciju ili kod sistema za dijagnostiku, gdje tek tako dobivenim povjerenjem od strane korisnika sistem može efikasno da obavi svoju funkciju. Kod sistema sa skromnom bazom znanja to nije uvijek moguće, mada oni mogu veoma dobro rješavati probleme. Zbog ovoga počelo se raditi na "drugoj generaciji" ekspertnih sistema, koji uvoĎenjem dubokog znanja rješavaju neke od tih problema. Takav razvoj doveo je do toga, da su postala veoma važna pitanja kako u računaru predstaviti tzv. duboko znanje i kako ga učiniti operativnim. Istraživanja na području kvalitativnog modeliranja i automatskog učenja su u funkciji rješavanja tih pitanja. Formalizam za predstavljanje znanja omogućuje zapis znanja o problemskom domenu što akceptira činjenice karakteristikama objekata, relacijama među njima, opštim pravilima domena i metodama rješavanja problema na tom području. Formalizam je svrsishodan u primjeni kod ekspertnih sistema, kada omogućuje efikasno rješavanje problema i kada je istovremeno u tom smislu transparentan, da omogući jednostavnu verifikaciju, modifikaciju i dopunu baze znanja. Pristup problematici formalizma za predstavljanje znanja još je veoma pragmatičan, jer je težište na performansama programa, a ne na teorijskim pitanjima, kao što su opisivanje pojedinog formalizma, ekvivalentnost, konverzija meĎu njima itd. Najpoznatiješeme za predstavljanje znanja su: produkciona pravila, mreže, okviri i predikatski račun. Produkciona pravila su najpopularniji metod za predstavljanje znanja. U konceptu problema logične relacije često opisujemo pravilima "Ako važi U onda Z" što znači u interpretaciji "Ako važi uslov U onda se može zaključiti Z" ili "Ako situacija U onda akcija Z". Znanje se u formalizmu produkcionih pravila (ako-onda) izražava na prirodan način. Pozitivne osobine produkcionih pravila su: svako pravilo predstavlja mali, relativno nezavisan dio znanja; dodavanje novih pravila može biti relativno nezavisno od ostalih pravila, što se odnosi i na modifikaciju postojećih pravila i ova pravila pomažu transparentnost sistema tako što mogu odgovoriti na pitanja tipa "kako" (Kako si došao do tog zaključka?) i "zašto" (Zašto ti je potrebna ova informacija?). Pravilo tipa "Ako važi uslov A onda se može zaključiti Z" predstavlja tzv. kategorično znanje, jer definiše logičku relaciju koja je istina. Predstavljanje znanja na mekim domenima preko ovih pravila gotovo je nemoguće. Tu relacije važe sa odreĎenim faktorom vjerovatnoće (npr. "Ako važi uslov U onda se može zaključiti Z sa faktorom vjerovatnoće P" ). Ovo nije matematička vjerovatnoća, već subjektivna ekspertova procjena za vjerovatnoću (obično broj nekog intervala, ne mora 0 - 1). Zbog njegovog karaktera, zaključivanje na bazi vjerovatnoće (probabilistic reasoning, plausible reasoning) treba uzimati veoma pažljivo. Mreţe kao formalizmi za predstavljanje znanja, sadržečvorove, koji označavaju objekte (fizičke objekte, situacije, skupove, relacije) i veze (binarne relacije izmeĎu objekata).
Iako se mreže razlikuju po izražavanju i tipovima procedura za manipulaciju, traženje meĎusobno povezanih elemenata znanja zasniva se na strukturi, koja kodira to znanje. Oznake elemenata mreže iz datog čvora omogućuju pozicioniranje na odgovarjuće čvorove tako što slijedimo odgovarajuće veze. Mreže su adekvatne za predstavljanje hijerarhijskih struktura, koje zajedno sa tehnikom nasljeĎivanja osobina olakšavaju opisivanje znanja. Tako npr. ako P predstavlja karakteristične osobine skupa S, onda P važi i za svaki podskup skupa S i za svaki elemenat skupa S odnosno odnosno njegov podskup. To praktično znači da karakteristike opisane na višem nivou vrijede za sve niže nivoe (ako treba nalazimo ih pomoću mreže). Koriste se za prirodno opisivanje jednostavnih relacija, a ne za kompleksne formule i veze. To se prije svega odnosi na sisteme za rad sa prirodnim jezikom (semantičke mreže) i za zaključivanje iz domena teorije skupova. Ponekad se i produkcioni sistemi predstavljaju u obliku mreže. Tada mreža modelira veze izmeĎu produkcionih pravila, a veze su relacije izmeĎu njih, obično sa faktorom vjerovatnoće. Ovu strukturu imaju npr. ekspertni sistemi Mycin i Prospector. Okviri su bazirani na ideji da se objekti, dogaĎaji i specifične situacije ili radnje mogu predstaviti jedinstvenom formom. Predstavljaju specifičan primjer mreža. Oni služe kao baza za razumijevanje vizuelne percepcije, dijaloga u prirodnom jeziku itd. Predložio ih je Minski kao metodu za organizovanje obimnog znanja potrebnog za rješavanje ovih zadataka. Ekspertni sistemi u okvirima skupljaju ove informacije u prepoznatljiv entitet. Kao kod mreža, meĎusobne veze izmeĎu tih entiteta mogu se izraziti veoma jednostavno, zahvaljujući nasljeĎivanju atributa. Ovaj oblik strukture omogućuje traženje elemenata koji se odnose na dati kontekst. Okvir je opis objekta i u njemu se nalazi otvor (slot) za svaku relevantnu informaciju tog objekta. Otvori memorišu vrijednosti tj. čuvaju znanje dostupno sistemu, čuvaju identitet entiteta i odgovarajuće akcije koje mogu biti preduzete. Sadrže default vrijednosti, pokazivače na druge okvire, kao i pravila odnosno procedure po kojima se dobijaju odreĎene vrijednosti za objekat. Dakle, svaki objekat je skup otvora. Kao kod mreža, okviri su u prednosti nad produkcionim pravilima, jer omogućuju implementaciju analize problema na dubljem nivou, npr. putem apstrakcije i analogije. Okviri predstavljaju bazu za jednu od najpopularnijih metoda predstavljanja znanja: objektno orijentisani okviri. U stari oni se približavaju objektno orijentisanim okruženjima. U standardnim implementacijama ekspertnih sistema, objektno orijentisani okviri se redovno kombinuju sa produkcionim pravilima, i tako nastaje jedan od najmoćnijih formalizama za predstavljanje znanja. Predikatski raĉun je najmoćni način predstavljanja znanja. Logika ili predikatski račun prvog reda kao podsistem formalne logike, u velikom broju slučajeva, može direktno da predstavi znanje napisano na prirodnom jeziku. Činjenice i pravila se zapišu u skladu sa sintaktičkim pravilima tog podsistema. Poznate činjenice i pravila tretiraju se kao aksiomi, a očekivani odgovor kao teorem koji važi u sistemu tih aksioma. Predikatski račun je performantan zato što za dokazivanje teorema u okviru tog formalizma postoje poznati i relativno brzi algoritmi, koji se baziraju na principu resolucije. Pored toga u ovom formalizmu veoma je jednostavno definisati relacije i strukturirati podatke. Programski jezik Prolog predstavlja formalizam ovoga tipa. Nastao je kao realizacija ideje, da je moguće matematičku logiku upotrijebiti kao programski jezik. Ima sintaksu formula predikatskog računa prvoga reda, zapisanih u klauzalnom obliku (kvantifikatori se ne navode eksplicitno), a ograničen je na Hornove klauzule. Hornove klauzule izražavaju uslovne tvrdnje tipa: Ako P1 i P2 i ... i Pn, onda P. Prolog je deklarativni odnosno neproceduralni jezik. Umjesto algoritama za rješavanje problema u njemu se zapisuju relacije meĎu podacima i rezultatima. Prologov interpreter onda sam nalazi redoslijed operacija, koje prevode podatke u rezultate koji odgovaraju zahtjevanim relacijama. Dakle,
u izvjesnom smislu podaci su istovremeno i program za rad sa njima. Prolog je dostigao veliku popularnost u Evropi i Japanu, gdje je proglašen za zvanični jezik 5. generacije računara. MeĎutim, kako je u opštem slučaju ograničeniji od produkcionih pravila, nema toliku popularnost u ekspertnim sistemima.
Mehanizam zaključivanja Mehanizam zaključivanja je ipak najvažniji dio ekspertnih sistema i on u principu kroz svoj interpreter sadrži elemente misaone aktivnosti čovjeka. On je u stvari modul ekspertnih sistema koji implementira algoritme za rješavanje problema. Od njega se traži da omogući odgovore na korisnikova pitanja i da se pri tom služi procesom zaključivanja, koji je moguće korisniku objasniti. Pored primarnog zadatka, pronalaženja pojedinih zaključaka on treba da realizuje i kontrolnu strategiju, po kojoj se odreĎuje redoslijed koraka relevantnih za rješavanje problema. Na primjer može se desiti, da odgovor na korisnikovo pitanje dobijemo samo na osnovu upotrebe jedne od "elementarnih" činjenica, registrovanih u bazi znanja. Recimo koristeći činjenice iz baze znanja "Galebovi su ptice" i "Sve ptice imaju krila" veoma se lako odgovara na pitanje da li su galebovi ptice. Naprotiv za odgovor na pitanje da li galebovi imaju krila, već je potrebno zaključivanje. U logici je ovo karakterističan odnos premisa i konkluzije. Sistem treba da je sposoban dedukovati i verifikovati činjenice, koje mu nisu eksplicitno zadate. Tada koristi poznate principe zaključivanja (kao npr. modes ponens ili princip resolucije), a moguće i zakonitosti, koje se isto tako nalaze u bazi znanja i služe kao pravila za dobivanje novih tj. izvedenih činjenica. Čitav proces rješavanja problema često se tretira kao dokazivanje teorema na osnovu aksioma. Rješenju problema odgovara dokaz teorema, a problem odgovara teoremu, koga nazivamo i ciljna hipoteza ili cilj. U tom slučaju moguća su dva načina zaključivanja: zaključivanje unaprijed (forward reasoning) i zaključivanje unazad (backward reasoning). Zakljuĉivanje unaprijed potiče u pravcu od datih elementarnih činjenica prema hipotezi. Iz poznatih činjenica generišemo nove, dok ne doĎemo do činjenice koja se poklapa sa ciljnom hipotezom. Zakljuĉivanje unazad vrši se u obrnutom smjeru, od ciljne hipoteze prema elementarnim činjenicama.Iz ciljne hipoteze generišemo nove hipoteze, dok ne doĎemo do hipoteza koje su jednake elementarnim činjenicama. Ukratkoćemo opisati osnovne principe zaključivanja: modus ponens, modus tollens i princip resolucije. Modus ponens je logično pravilo po kojem na osnovu činjenice "A je istinito" i pravila "ako važi A onda važi B" zaključimo istinitost za B. Taj princip veoma je jednostavan pa je zato i proces zaključivanja koji se bazira na njemu relativno lako razumljiv. Slaba strana mu je to što ne nalazi sve moguće zaključke. Na primjer iz "B nije istinito" i "ako važi A onda važi B" ne može se zaključiti "A nije istinito" na osnovu modes ponensa, već se radi o drugom pravilu zaključivanja poznatim kao modus tollens.Princip resolucije je poznat metod za automatsko dokazivanje teorema u formalizmu predikatnog računa prvog reda. Posebna vrsta ovog principa realizovana je u Prologu. Osnovna ideja je u tome da se skupu važećih aksioma doda negacija teorema kojeg želimo dokazati. Ako se sada otkrije kontradikcija, time je dokazano, da je originalni teorem istinit. Više o resoluciji kao metodi za automatsko dokazivanje teorema piše autor Nilson.
Osnova za rješavanje problema je njegovo adekvatno predstavljanje. U tom smislu razvijene su odreĎene sheme kao što su: prostor stanja (state space) i AND/OR grafovi. Prostor stanja predstavlja graf gdje su čvorovi ekvivalentni problemskim situacijama. Veze izmeĎu čvorova su legalne akcije koje transformišu jednu problemsku situaciju u drugu. Rješenje problema se postiže korišćenjem dvije osnovne strategije pretraživanja grafova: pretraživanje u dubinu (depth-first search) i pretraživanje u širinu (breadth-first search). Za razliku od algoritma pretraživanja u širinukoji nalazi najbrže odnosno najkraće rješenje, pretraţivanje u dubinu nosi odreĎeni rizik tj. opasnost da algoritam doĎe u bezizlaznu petlju. Pretraživanje u dubinu posjeduje dijalog sa korisnikom koji je mnogo prirodniji i veoma detaljno obraĎuje teme (jednu po jednu). Nasuprot njemu, algoritam pretraţivanja u širinu preskače sa teme na temu (random pretraživanje) i na taj način negativno utiče na koncentraciju korisnika. Na shemi ispod, predstavljen je sistem zaključivanja po širini, Pravila su u osnovi u istom nivou, sa velikom širinom i malom dubinom. Malo je propagacije uključeno u slučaju ovog mehanizma za zaključivanje. On veoma lako uporedi uzorke, izvrši i zaustavi se, pravila ovog tipa su dobra za reaktivne sisteme kod kojih je vrijeme odziva bitna stvar.
if zeleno svjetlo
if crveno svjetlo
if narandžasto svjetlo
then
then
then
U redu je preći ulicu
Nije u redu preći ulicu
pogledaj, provjeri and U redu je preći ulicu
Tabela 5. Sistem zakljuĉivanja po širini
Sljedeći prikaz opisuje zaključivanje po dubini sa predstavljanjem zaključivanja unaprijed i unazad. if zeleno svjetlo
Zakljuĉivanje unaprijed:
then
Dat je dio podataka,
Svjetlo je u redu
Zeleno svjetlo Mehanizam za zaključivanje će
if svjetlo u redu
zaključiti
then
Kupi cipele
Pređi ulicu if pređi ulicu then Zakljuĉivanje unazad:
Posjeti prodavnicu
Dati cilj, Kupi cipele Mehanizam za zaključivanje će
if Posjeti prodavnicu
pokušati zadovoljiti RHS,
then
Posjeti prodavnicu
Kupi cipele
Tabela 6. Sistem zakljuĉivanja po dubini Iz prikazanog vidimo da postoji dodatno znanje iličinjenice. Ovo dodatno znanje (činjenice), može biti uporeĎivano drugim pravilima kreirajući tako "efekat lanca". Zaključivanje unaprijed je voĎeno podacima. Dok sistem zaključivanja unazad pokušava da validira hipoteze.
Algoritam ulančavanja unaprijed (polazi od premisa), algoritam ulančavanja unazad polazi od zaključka, pa pronalazi pravila za koji dati zaključak važi. Za pretraživanje prostora karakterističan je problem kompleksnosti. Za netrivijalna područja broj alternativa može biti tako veliki da slijepo pretraživanje postaje apsurdno. Naime, ako se pretpostavi da nema bezizlaznih petlji i ako svaki čvor b ima nasljednika onda je broj puteva dužine l od početnog čvora bl. Dakle, broj kandidata se povećava eksponencijalno i dolazi se do tzv. kombinatoričke eksplozije. Problem se prevazilazi heurističkim pretraživanjem (heuristic search, best-first search), što znači da se algoritam pretraživanja koristi specifičnim znanjem o problemu koje eliminiše bezperspektivne alternative. Obično su to numeričke procjene, koje ocjenjuju perspektivnost svakog čvora u grafu. (npr. algoritam A). Problem se može predstaviti i sa AND/OR grafom. Ovaj graf je karakterističan za probleme koji se mogu dekomponovati na podprobleme. Ovdje su čvorovi ekvivalentni problemima. Početni čvor je originalni problem, dok su ciljničvorovi relativno jednostavni podproblemi. Veze meĎu čvorovima predstavljaju relacije meĎu problemima. Čvor može biti AND tipa (za rješenje potrebno je riješiti sve njegove nasljednike) i OR tipa (za rješenje je dovoljno riješiti jednog od nasljednika). Rješenje problema nije put već podgraf u originalnom AND/OR grafu. Za pretraživanje AND/OR grafova u Prologu može se iskoristiti sam interpreter za Prolog, čije je proceduralno značenje upravo pretraživanje takvih grafova. Naročito važna osobina mehanizma zaključivanja je da li on omogućava monotono ili nemonotono zaključivanje. U prvom slučaju sve što je bilo prepoznato kao istinito ostaje istinito tokom čitave konsultacije. Količina informacija u tom slučaju može samo monotono da se povećava. Nemonotono zaključivanje dozvoljava da se znanje tokom konsultacije mijenja. Na osnovu nove informacije neki ranije izvedeni zaključci mogu se eliminisati. Opšti uzorak kod tih sistema je tzv. "default" zaključivanje tipa "ako važi A i ako nije evidentno da ne važi B, onda važi B". Ostaje još veoma važno pitanje kako se vrši zaključivanje kada imamo nepotpune ili nepouzdane informacije i kada možda i sama pravila važe samo sa nekim odreĎenim faktorom povjerenja. Spomenuli smo već da su na tzv. mekim područjima, koja su glavna područja primjene ekspertnih sistema, takve situacije veoma česte. Zato ekspertni sistemi uglavnom omogućavaju zaključivanje na osnovu vjerovatnoće za razliku od kategoričkog zaključivanja gdje su stvari jednostavno istinite ili ne. Opšte prihvaćene teorije zaključivanja na osnovu vjerovatnoće još nema, mada su istraživanja na ovom području veoma intenzivna. U literaturi se uglavnom navodi kako je to pitanje riješeno kod pojedinih poznatih sistema (Prospector, Mycin ...).
3.4.4. IZGRADNJA EKSPERTNIH SISTEMA U slučaju ekspertnih sistema znanje je odvojeno od algoritama koji ga koriste. Baza znanja je zavisna od problemskog domena dok su mehanizam zaključivanja i interfejs često nezavisni. Ta dva nezavisna modula se zajedno nazivaju ljuska ekspertnog sistema. U principu imajući jednom ljusku, samim dodavanjem nove baze dobivamo novi ekspertni sistem. Naravno, baza treba da bude u takvom formalizmu, da je ljuska "razumije". Empirijski gledano, to ne ide uvijek sasvim jednostavno i u pojedinim primjerima treba i ljusku promijeniti u nekim detaljima. Ipak, glavni principi ostaju isti, pa je i u tom primjeru izrada ekspertnog sistema veoma ubrzana. Ljuske dakle spadaju u dobrodošle alate za izradu ekspertnih sistema, koji su na tržištu sve evidentniji. MeĎutim, broj ekspertnih sistema u svakodnevnoj upotrebi ne napreduje u skladu sa očekivanjima. Razlog je u teškoćama, koje su sastavni dio procesa izgradnje pojedinih baza znanja kao najsloženije faze izgradnje ekspertnih sistema. Taj fenomen tj. usko grlo u literaturi je poznato pod imenom
"Feigenbaum bottleneck" i posljednjih godina predstavlja povod za brojna istraživanja na području automatske sinteze znanja. U posljednje vrijeme dolazi do razvoja metoda i alata koji omogućavaju automatsko zahvatanje znanja, pa se može očekivati u skorom vremenu pozitivno rješenje ovoga problema. Ljuske ekspertnih sistema Osnovna pitanja kod izgradnje ekspertnog sistema već u fazi izrade ljuske su sljedeća: Riješiti u kojem formalizmu će biti predstavljeno znanje, da bi bilo pogodno za rješavanje problema. TakoĎe, paralelno s tim ono mora biti razumljivo korisniku i jednostavno za verifikaciju, modifikaciju i dopunu. Treba izabrati mehanizam zaključivanja, koji bi bio adekvatan za rješavanje problema tj. on treba da odgovara izabranom formalizmu za predstavljanje znanja. Zatim, on treba da prikladno obradi nepouzdane i nepotpune informacije i da omogući potrebno objašnjenje. Ukratko za kvalitetan razvoj ljuske treba: izabrati formalizam u kojem će biti predstavljeno znanje (obično pravila oblika "ako-onda"), razviti formalizam za predstavljanje znanja adekvatan mehanizamu zaključivanja, razviti interfejs pomoću kojeg će sistem objašnjavati svoje odluke i davati odgovor na pitanja tipa "Kako si došao do tog rješenja?" i "Zašto želiš ovu informaciju?" i razviti metod za rad sa nepouzdanim i nepotpunim informacijama.
Zahvatanje znanja Da bi se izgradila baza znanja treba prvo ekstrahovati ekspertno znanje, onda ga predstaviti u formalizmu, koji omogućava da se to znanje koristi pomoću računara. Proces zahvatanja znanja i njegove preformulacije u izabrani formalizam za predstavljanje znanja inženjering znanja (knowledge engineering). Karakteristika većine do sada izgraĎenih ekspertnih sistema je u korišćenju baze znanja koja je dobivena "ručno" tj. pomoću stručne literature i konsultovanja stručnjaka. Problem je što je to dugotrajan i skup proces, jer zahtijeva dosta dug angažman kako samog tehnologa znanja, tako i stručnjaka za konkretno problemsko područje. Razlog je u poznatom dejstvu čovjekovog "know-how", do koga je ekspert došao dugim isustvom i koga je teško formulisati u "say-how" toliko sistematično i detaljno koliko je to potrebno za računarsku aplikaciju, pa je zato došlo do razvoja alternativnih metoda za zahvatanje znanja, koje omogućavaju automatsku sintezu znanja, a imaju osnovu prije svega u metodama automatskog učenja i kvalitativnog modeliranja. Kada se od eksperta traži da prezentuje svoje znanje, on će to najlakše učiniti pomoću izabranih primjera. On je sposoban mnogo brže pretvoriti "know-how" u "show-how". Na ovaj način se eventualno prevazilazi tzv. Fajgenbaumovo usko grlo. Potrebno je iz skupa primjera induktivnim zaključivanjem izvesti pravila i tako iz njih rekonstruisati ekspertov "know-how", što se može postići metodama automatskog učenja. Struktura ekspertnih sistema, proširena modulom za zahvatanje znanja prikazana je na Slici 10.
Slika 10. Proširena struktura ekspertnih sistema U slučaju veoma obimnih baza znanja posebno je pogodna upotreba kvalitativnog modela. Model sadrži uzročno znanje o području, koje može biti predstavljjeno u relativno kompaktnom obliku. Osim toga lakše je provjeriti njegovu kompletnost i konzistentnost nego u slučaju kada je znanje u obliku velikog broja primjera. U mnogim domenima (npr. fiziologiji) priroda problema je kvalitativna, te zahtjeva takav jezik eksperta. MeĎutim konstrukcija kvalitativnog modela uglavnom je težak zadatak, pa se zato vrše istraživanja iz automatske izgradnje takvih modela. Rezultati utvrĎuju primjenljivost automatskog učenja i kvalitativnog modeliranja za automatsko generisanje ekspertnog znanja. Sintetizovano znanje je po suštini i tačnosti zanimljivo za stručnjaka ili praktika sa problemskog područja, a rezultati ekspertnih sistema koji se služe tim znanjem su u okviru tačnosti koju postižu eksperti tačnosti.
Automatsko učenje Svako inteligentno ponašanje povezano je sa sposobnošću učenja, pa je i ideja automatskog učenja odavno prisutna. Prva istraživanja bila su na području prepoznavanja uzoraka (pattern recognition) i grupisanja uzoraka (clustering). Nastao je niz tzv. statističkih metoda, koje su davale relativno dobre rezultate, ali su ipak ti rezultati bili dosta nejasni, jer su bazirani na načinu koji je drugačiji od čovjekovog načina mišljenja. Tako je nastala nova grana automatskog učenja tzv. strukturno automatsko učenje. Ono predstavlja automatski proces dobivanja znanja na osnovu informacija dobivenih od učitelja, od nekog spoljneg procesa ili samostalnim posmatranjem odnosno eksperimentisanjem. Rezultat tog učenja je formula, teorija, pravilo ili opis koncepta u kvalitativnom formalizmu koji je blizak čovjeku. Tako korisnik može da uoči relacije, zakonitosti i logiku zaključivanja, po kojoj sistem na osnovu pravila dolazi do odreĎenih zaključaka. Načini učenja se klasifikuju prema više kriterijuma. Navešćemo podjelu prema kriterijumu stepena učešća induktivnog zaključivanja kod učenika tokom procesa učenja:
Direktno ili rutinsko učenje (rote learning). U ovom slučaju zaključivanje nije potrebno i u ovu grupu spadaju direktno programiranje i čuvanje podataka. Učenje na osnovu kazanog (learning by being told). Kod ovog učenja učitelj posreduje znanje (daje pravila i činjenice), koje se pomoću predznanja i induktivnog zaključivanja organizuje u takav oblik, da ga je moguće koristiti bez eksplicitnih algoritama. Učenje na bazi objašnjenja (explanation-based learning) zasniva se na jednom primjeru rješenja problema, koje se pomoću znanja o problemskom području objašnjava, opravdava i uopštava, te tako rješava čitavu klasu problema. Učenje po analogiji (learning by analogy) bazira se na ideji da se postojeće znanje transformiše u takav oblik, koji je moguće upotrebiti za novi, sličan problem. Učenje na osnovu primjera (learning from examples). Ovo učenje je učenje na pozitivnim ili negativnim primjerima, gdje se na osnovu tih primjera induktivnim zaključivanjem dobivaju pravila odnosno opis koncepta koji treba da je kompletan (uključuje sve pozitivne primjere) i konzistentan (isključuje sve negativne primjere). Učenje samostalnim otkrivanjem (learning from observation and discovery) predstavlja najteži oblik učenja. Postavljanje i testiranje hipoteza kao i kreiranje novih teorija potpuno je samostalno bez učitelja.
Dosadašnja praksa je pokazala da je najefikasniji oblik automatskog učenja učenje na osnovu primjera. Ovo učenje značajno prevazilazi problem Feigenbaum-ovog uskog grla, jer se eksperimentima lakše daju primjeri (često su već arhivirani) nego pravila po kojima se rješavaju problemi. Automatsko učenje na osnovu primjera sadrži nekoliko poznatih opštih metoda kao što su: Metoda prostora verzija (version space) predstavlja koncept traženja u prostoru mogućih opisa u datom opisnom jeziku. Postojeće znanje koncepta odreĎuje podskup opisa iz prostora svih mogućih opisa. Taj podskup se zove prostor verzija i dopunom znanja se smanjuje. Ova metoda je primjenjena u sistemu kojim se uče pravila za simboličko integrisanje (LEX) i u pravilima za generisanje molekularnih struktura (META-DENDRAL).
Metoda gradnje drveta odlučivanja je veoma jednostavna i efikasna metoda. Implementirana je od strane Quinlana u sistemu ID3. Suština je da se na osnovu postojećih primjera izgradi klasifikacijsko pravilo u formi stabla odlučivanja koje se može upotrebiti za klasifikaciju novih objekata. Postoje mnogi sistemi zasnovani na ovoj metodi kao npr. ASISTENT 86. Metoda za konceptualno grupisanje uzoraka razvijena je kao alternativa klasičnim metodama za grupisanje uzoraka. Uspješno je implementirana u sistemu CLUSTER. Radi relativno sporije nego standardne metode, ali ima prednost u logičkim opisima grupa koje generiše. Kvalitativno modeliranje Kvalitativni modeli opisuju sistem na jednostavan simbolički način, koji je blizak ljudskom načinu mišljenja. Apstrahuju se egzaktne numeričke vrijednosti, jer sve parametarske vrijednosti sistema se integrišu u jedan simbolički opis tj. kvalitativnu vrijednost. Za razliku od klasičnih modela gdje su promjenljive veličine vezane jednačinama, kod ovih modela promjenljive su vezane relacijama koje mogu imati oblik jednačina, nejednačina ili logičkih izjava. Dakle, ovdje se umjesto rješavanja sistema jednačina, promjenljivim dodjeljuju vrijednosti relevantne za relacije u modelu. Kvalitativni modeli su bazirani na skupu relacija meĎu elementima sistema. Sistem se može opisati i sa apstraktnim pojmovima. S obzirom na to razlikuju se: komponentno orijentisan pristup gdje se ponašanje sistema izvodi iz ponašanja njegovih komponenti i procesno orijentisan pristup koji opisuje procese kao izvor svih promjena u sistemu. Oba pristupa su realizovana tako da opisuju fizikalne pojave ograničavajućim (ne)jednačinama. Simulacija se vrši kao širenje ograničenja (constraint propagation) po sistemu, a izvodi je zato kreiran jezik CONLAN. Formulacija pravila u KARDIU je drugačija. Umjesto ograničavajućih jednačina ovdje postoje formule predikatskog računa prvog reda tj. logičke izjave. Simulaciju izvršava interpreter pravila napisan u PROLOGU. Prednosti kvalitativnog modeliranja u odnosu na klasično modeliranje mogu se sintetizovati u sljedećem: Kvalitativni opisi su veoma pristupačni u odnosu na rješavanje klasičnih modela koji su kompleksni. Kvalitativni model je bliži čovjekovom načinu mišljenja. Kvalitativni model je primjenljiv i u slučaju kada nisu poznate tačne vrijednosti parametara, dok to ne važi za klasične modele. Kvalitativna simulacija jednostavno generiše objašnjenje i tako postiže transparentnost sistema. Ako su relacije u modelu kauzalnog karaktera (povezuju uzroke sa posljedicama), onda lanac zaključaka predstavlja kvalitativnu simulaciju modela. Sam model predstavlja duboko znanje jer odražava strukturu i i dublje principe problemskog domena. Ovakva duboka baza znanja je pozitivna, jer poboljšava semantiku i sposobnost objašnjavanja ekspertnog sistema. MeĎutim, negativna strana se ogleda npr. u dijagnostici i kontroli, kada treba zaključivati po lancu u smjeru nazad (od posljedica ka uzrocima). Rješenje problema je u procesu kvalitativne simulacije kada se automatski mogu dobiti plitka pravila koja direktno povezuju početne uzroke sa konačnim posljedicama, za sve moguće primjere. Ovakva baza je veoma operativna, ali i veoma obimna. U tom smislu komprimuje se metodama automatskog učenja.
3.4.5. ALATI ZA IZRADU EKSPERTNIH SISTEMA
U osnovi se razlikuju tri kategorije alata za izgradnju ekspertnih sistema: Alati koji se koriste na personalnim kompjuterima, i koji služe za izradu ekspertnih sistema do 400 pravila. Specijalizovani alati za izradu kompleksnih ekspertnih sistema, koji su ograničeni na rješavanje problema specijalizovanog tipa i koji sadrže više hiljada pravila. Ovi alati zahtjevaju veće kompjutere kao npr. Lisp Machine. Alati za izradu kompleksnih ekspertnih sistema, koji rješavaju probleme različitih tipova i koji sadrže više hiljada pravila. TakoĎe, zahtjevaju veće kompjutere kao npr. Lisp Machine. Najpoznatiji komercijalni alati za izradu ekspertnih sistema su: ART Automated Reasoning Tool - skup alata za izradu ekspertnih sistema koji uključuje jezik za opisivanje činjenica i relacija tzv. knowledge language, kojeg prevodi u Lisp, zatim mehanizam zaključivanja i specijalan alat za otkrivanje grešaka. ES/P ADVISORLjuska za razvoj jednostavnih ekspertnih sistema za područja gdje postoji tekstualan opis kao npr. uputstva i postupci. EXPERT-EASE Opštenamjenski sistem za izgradnju stabla odlučivanja. EXPERT Alat za izradu konsultacijskih sistema za područja medicinske dijagnostike, analiza traženja nalazišta nafte itd. INSIGHT Opštenamjenska ljuska za izradu sistema do 400 pravila tipa ako-onda. KEE Knowledge Engineering Environment - integrisani paket alata kojim se izgraĎuju kompleksne aplikacione analize i planiranje, prvenstveno za domen genetskog inženjeringa. OPS5 Sistem za produkciono programiranje, razvijen na Carnegie-Mellon University kao alat za istraživanje čovjekovog pamćenja i mišljenja. LOOPS Skup alata koji su uključeni u Interlisp okruženje i koji uključuju proceduralno i objektno orijentisano programiranje. TIMM The Intelligent Machine Model - dopunjena verzija EXPERT-EASE, kojom se izgraĎuje više meĎusobno povezanih pravila.
3.4.6. PODRUČJA PRIMJENE EKSPERTNIH SISTEMA Osnovna područja primjene ekspertnih sistema su ona za koja nisu u potpunosti poznati algoritmi rješavanja, niti je znanje dovoljno formalizovano. Takva područja su zahvalna za eksperta da rješava probleme na osnovu obimnog znanja služeći se pri tom svojim iskustvom i donekle intuicijom. Ekspertni sistemi su se u početku primjenjivali na različitim poljima. Prvi najjednostavniji ekspertni sistemi služili su kao supstitucija ljudskog partnera u igri kao što je npr. šah. Zatim, u sljedećoj grupi se nalaze ekspertni sistemi koji zamjenjuju profesionalca npr. ljekara. Dalja primjena ogleda se u podršci vojnim sistemima u planiranju, donošenju odluka i dijagnostici. TakoĎe, ekspertni sistemi imaju veoma važnu primjenu za projektovanje. Na primjer na bazi logičkih jednačina vrši se konstrukcija LSIčipova. Najpoznatiji komercijalni ekspertni sistemi su: DENDRAL (utvrĎuje hemijske strukturne formule na osnovu spektralnih osobina hemijskih jedinjenja); SHRDLU (sistem za razumijevanje prirodnog jezika); MYCIN (sistem za pomoć ljekarima kod dijagnosticiranja infektivnih oboljenja kod izbora terapije); ARCHES (program za automatsko učenje); AL/X (sistem za otkrivanje kvarova u kompleksnim proizvodnim procesima); PROSPECTOR(sistem za pomoć kod geoloških istraživanja). Noviji sistemi su se pokazali izuzetno korisnima u poslovnoj sredini. U nastavku ćemo navesti neke od dostupnih proizvoda: AUDITOR Softverski paket ekspertnog sistema, koji je razvijen s cilj em da pomogne u analizi dopuštenih spornih potraživanja, dugovanja i unutrašnjih kontrola u preduzeću. "Auditor" je danas jedan od najviše korišćenih ekspertnih sistema. Ovaj program bira kontrolne postupke na osnovu ulaza iz preduzeća. Razvijen je na Univerzitetu Ilinois. TAX ADVISOR Ekspertni sistem koji pruža poreske savjete za planiranje nasljedstva. Razvijen je kao dio doktorskog rada na Univerzitetu Ilinois. Svrha mu je da svojim poreskim savjetom pomogne klijentu u finansijskim poslovima tako da porez na prihod i porez na nasljeĎe budu minimalni, a da pri tom ne budu pogoĎene odluke o zdravom ulaganju i odgovarajućem pokriću osiguranja. TICOM U razvojnim fazama na Univerzitetu Minesota, ovo je metoda za modeliranje i ocjenjivanje sistema unutrašnje kontrole. "Ticom" može poboljšati tačnost i pouzdanost finansijskih podataka u preduzeću. EDP AUDITOR Još jedan kontrolni sistem, "Edp Auditor" je dizajniran s ciljem da pomogne kontrolorima ili kontroli modernog EOP-a, te da pomogne u izvoĎenju modernog verifikacionog postupka. TAXMAN Oporezivanje je područje za koje su od početka zainteresovani ekspertni sistemi. "Taxman" procjenjuje poreske posljedice predloženih reorganizacija u preduzeću. CORP-TAX Još jedan poreski sistem, "Corp-Tax" je napravljen s ciljem da pomogne računovoĎi u vezi s amortizacijom. FINANCIAL ADVISOR Razvijen na MIT Univerzitetu ovaj sistem može pružati savjete o projektu, proizvodima, udruživanjima, kupovini kada se razgovara sa visokim finansijskim savjetnikom.
PLAN POWER Novi ekspertni sistem za finansijsko planiranje, koji je razvijen kao rezultat sve veće složenosti zadataka za finansijskog planera zbog množenja investicionih sredstava. Razvio ga je Applied Expert Systems za korišćenje na Xerox 1186 radnoj stanici. Program uzima u obzir finansijsku situaciju, zatim usklaĎuje potrebe s najpovoljnijim finansijskim proizvodima i uslugama. Uz to sistem će proizvoditi tabelarne izvještaje za scenarije koji pokazuju stanje poreza na prihod, tokove novca, neto vrijednost i druge kritične faktore temeljene na alternativnim odlukama. CASH VALUE Dizajniran u "Plan Power-u", ovo je komercijalno pristupačan ekspertni sistem, koji pomaže u planiranju kapitalnih projekata. Pravila odlučivanja daju savjete o neto polaznoj vrijednosti, toku novca, isplativosti i analizi rizika.
AION DEVELOPMENT SYSTEM /MVS/PC Ljuska ekspertnog sistema namijenjena za velike IBM sisteme ili PC kompatibilne sisteme. Razvijen u AION Corp. ovaj program je namijenjen komercijalnim EOP sredinama. Sistem ima razvojne funkcije koje su potrebne za stvaranje, testiranje i izvoĎenje aplikacija baza znanja. TakoĎe uključuje editor, pomoć, skicu i povezne funkcije. GURU Spoj mogućnosti ekspertnog sistema i tradicionalnog komercijalnog računovodstva, ovaj program razvijen u Micro Data Base Systems, Inc., radi kao softver za tabelarne izvještaje (spreadsheet) i kao ljuska za ekspertni sistem. Uz ovakve jedinstvene mogućnosti, korisnik može u njega ugraditi, znanje na mikrokompjuteru, pa tako korisnik koji radi na tabelarnom izvještaju može "konsultovati" ekspertni sistem i brže donositi rutinske odluke. Pored standardnih funkcija generatora izvještaja, obrade teksta, statističke analize i upravljanja podacima, GURU ekspertne aplikacije mogu obuhvatiti administrativne savjete, finansijske analize i rutinsko odlučivanje. PLATINUM LABEL Opšti računovodstveni softver s korisničkim interfejsom u obliku prirodnog jezika, čiji je cilj brzo akceptiranje od strane korisnika. Platforma za izvoĎenje mu je običan personalni računar. Sadrži sedam ekspertnih paketa: potraživanja, dugovanja, glavnu knjigu, prodajne narudžbe, zalihe, analizu prodaje i osnovni pribor za voĎenje. Razvijen je u Intelli Source Inc., sadrži zaštitu u vidu lozinke, sredstva za periodične i godišnje obračune, te prenos bilansa s nekoliko prozora na ekranu. EURISKO Futuristički ekspertni sistem koji je nastao i još se razvija na Univerzitetu Stanford, a osnovna mu je ideja da kompjuter razvija svoje vlastite teorije i ideje na osnovu zadatih principa struke. EXPERT-EASE Ovaj sistem predstavlja jedan od najčešće korišćenih opštenamjenskih ekspertnih sistema. Razvijen je na Human Edge Software, Inc. Najprikladnije primjene za sisteme kao što je "Expert-Ease" su dobro definisane odluke od dvije do četiri opcije, a istovremeno se vodi računa o tri do šest relevantnih faktora. Sadrži samo okvir bez vlastitog domena znanja, dok domen treba dati korisnik/stručnjak.
3.4.7. PREDNOSTI I NEDOSTACI EKSPERTNIH SISTEMA Evidentan skok ulaganja u istraživanje ekspertnih sistema, prisustvo proizvoda na tržištu i pružena mogućnost primjene u preduzećima navodi na konstataciju konkretne koristi od strane ekspertnih sistema. Prije svega ekspertni sistemi osiguravaju univerzalnu i stalnu raspoloživost. Drugim riječima, ekspert je uvijek na raspolaganju. Prisutna je nepristrasnost, jer jednom organizovan ekspertni sistem je praktično dosljedan. Ekspertni sistem ima savršenu memoriju i uzima sve relevantne faktore u obzir. Kvalitetno vrijeme stručnjaka je osloboĎeno rutinskih poslova, jer ekspertni sistem obavlja postavljene zadatke i time dobija ekonomsko opravdanje. Ekspertni sistemi mogu biti i u edukativnoj poziciji, jer stručnost sintetišu u jasno definisana pravila. Ekspertni sistem sadrži činjenice koje stručnjak uzima u obzir i praktična pravila koja stručnjak primjenjuje prilikom rješavanja problema. Simulacijom situacija iz realnog žvota, neiskusan radnik se može podučiti tome koje su informacije bitne i koji je misaoni mehanizam upotrijebljen. U daljem kontekstu pozitivnih osobina, odnosno koristi od ekspertnih sistema, izdvaja se zajedničko korišćenje znanja. Znanje vrhunskih stručnjaka u preduzeću može postati pristupačno mnogim radnicima. Na ovaj način se povećavaju stručne ocjene. Ekspertni sistemi će biti na raspolaganju za iznošenje sekundarnih mišljenja na području, kao i za izradu "šta ako" analiza u kojima se traže rezultati u zavisnosti od različitih promjena. Sljedeća korist u primjeni ekspertnih sistema je kraće vrijeme odlučivanja. Naime, rutinske odluke, koje odnose dosta vremena, lagano donose ekspertni sistemi. Ljudi stručnjaci će zato imati više vremena na raspolaganju za kreativniji rad. Ekspertni sistemi su najefikasniji u kombinovanim problemima, gdje direktne metode nabrajanja vode do sve većeg broja mogućnosti, pa je potrebna intuicija, logika i razum za pronalaženje najbolje moguće odluke. Ekspertni sistemi su isto tako korisni kod problema u kojima se odluke zasnivaju na analizi i interpretaciji ogromne količine nekvantitativnih podataka. Nabrajanje koristi ekspertnih sistema završićemo sa očuvanjem i prenosom stručnosti na početnike i nasljednike u preduzeću. Osnovni nedostaci i odbrambeni stavovi, vezani za sadašnje stanje tehnologije ekspertnih sistema, zasnivaju se na dehumanističkim konotacijama koje prate ove programe vještačke inteligencije. Ovo se ogleda u potiskivanju, odnosno ograničavanju učešća rukovodnih kadrova u procesima u organizaciji. Bez obzira koliko bili pristalice ekspertnih sistema, ne možemo negirati značaj intuicije i neformalizma u rješavanju problema i inovacijama. Ekspertni sistemi imaju ograničenja u nekoliko područja problema. Prvo, za donošenje odluka u jednoj dinamičnoj sredini sa mnoštvom nestrukturiranih problema nije dovoljno samo iskustvo, dakle empirijski pristup. Shodno tome mehanizam zaključivanja će vjerovatno biti nedovoljan. Ekspertni sistem je ograničen na vrlo usko područje (domen), jer je izgradnja i održavanje velike baze znanja teška. Sistem ne daje kvalitetan odgovor ako problem nije u potpunosti ograničen na specifično područje. I tada se javlja problem sa odlukama vezanim za široko interdisciplinarno znanje. Prilikom prikupljanja i organizovanja baze znanja, odreĎene vrste znanja se ne mogu lako prevesti u pravilo ako–onda. TakoĎe, postoji teškoća oko specifikacije heurističkog znanja rukovodioca, koje je važno za pravilno odlučivanje. Korisnički interfejs sa sistemom treba biti ostvaren preko "prirodnog" dijaloga. MeĎutim, dijalog nije realno prirodni jezik. Korisnici moraju opisivati probleme u definisanom formalnom jeziku čije riječi i njihova kombinacija imaju veoma specifično značenje.
Ograničeni broj stručnjaka za ekspertne sisteme i inženjera za baze znanja, predstavljaju konstantnu opasnost da poslovne aplikacije mogu lako pasti na posljednje mjesto u razvoju ustupajući mjesto drugim dobro finansiranim područjima. TakoĎe, vrijeme odziva komercijalno dostupnih ekspertnih sistema relativno je sporo na većini personalnih računara. Ali to je vjerovatno prolazni problem s obzirom na dinamiku razvoja mikrokompjuterske tehnologije. Za kraj nabrajanja nedostataka ekspertnih sistema navešćemo da je indikativno relativno veliko ulaganje u instalacije i održavanje ekspertnih sistema kao i mogućnost da konkurencija kroz razvoj ili kupovinu sličnog sistema može ugroziti odreĎene poslovne pozicije.
3.4.8. PERSPEKTIVA EKSPERTNIH SISTEMA Realno gledano, budućnost ekspertnih sistema je zagarantovana. Sistemi koji podržavaju upravljanje postaće sve više normalna praksa, pogotovo ako se uzme u obzir sve veća pristupačnost i primjena sve moćnijih mikrokompjutera. Već su razvijeni silicijumski čipovi, koji omogućuju da mikrokompjuteri postanu sve više slični u pogledu snage dosadašnjim "velikim" kompjuterima. Na taj način rukovodilac, nezavisno od nivoa gdje se nalazi, može konsultovati svoj kompjuter na stolu za rješavenje vrlo važnih poslovnih problema. Mnoge upravljačke funkcije će izvršavati ekspertni sistemi. Pravi rukovodioci će se naučiti kako da saraĎuju sa vještačkim rukovodiocem, te će više vremena i energije posvetiti problemima koji se rjeĎe javljaju i koji su specifičniji ili neodreĎeniji. Ekspertni sistemi će pojednostaviti proces pripreme spoljnih i unutrašnjih finansijskih izvještaja. Finansijski ekspertni sistemi će biti prilagoĎeni specifičnim granama privrede tako da će finansijskim rukovodiocima pomoći u pripremi internih i eksternih finansijskih izvještaja. Područje knjigovodstva, koje će meĎu prvima iskoristiti aplikacije ekspertnih sistema, biće kontrola. Planiranje kontrole, proces analize rizika, biće u velikoj mjeri potpomognuto vještačkom inteligencijom. Ekspertni sistem će poboljšati školovanje kontrolora, jer će se u odnosu na njih testirati ocjene početnika. Izbor i primjena kontrolnih procedura biće pomognuti prilikom uzimanja uzoraka, provjere stvarnosti i potvrde podataka. TakoĎe će detalji, koji se odnose na opšteprihvaćene standarde kontrole, biti dostupni za savjet u složenim slučajevima izvještaja. Neki ekspertni sistemi će postati "kompjuterizovani predradnici" u industriji. To će biti sistemi za upravljanje zalihama koji će moći kreirati i mijenjati proizvodne planove. Na taj način u preduzeću će se smanjiti zalihe i povećati produktivnost. Za rukovodioce i stručnjake u prodaji ekspertni sistem će pružati pomoć u analizi rizika kod potencijalnih kupaca. Vrlo je značajno prisustvo aplikacija u domenu posuĎivanja i ulaganja finansijskih sredstava preduzeća. Postojaće interne veze izmeĎu ekspertnih sistema i postojeće EOP-a. Ekspertni sistemi će redovno dopunjavati tradicionalne metode školovanja u obrazovnim programima. Pored toga, ovi sistemi će biti na raspolaganju za operativno planiranje i kontrolu odnosno tamo gdje je analiza rizika dio odlučivanja. Ako pogledamo još dalje u budućnost, perspektiva ekspertnih sistema je meĎusobna povezanost analogna današnjoj većtradicionalnoj povezanosti mikrokompjutera uz pomoć lokalnih mreža. Povezanost nekoliko ekspertnih sistema u jedan sistem, koji je relevantan za niz srodnih područja odlučivanja, eksponencijalno će povećati vrijednost ekspertnih sistema. Ogromni pomaci očekuju se u razvoju hardvera i softvera za mnoga područja stručnosti.
3.5. HS– DW – BI – CRM
3.5.1. HS Hibridni sistemi (Hibrid Systems - HS) Hibridni sistemi nastaju integracijom dva ili više kompjuterskih informacionih sistema. Do danas razvijeno je više klasa hibridnih sistema, ali meĎu osnovne ubrajaju se: integracija sistema za podršku odlučivanju i ekspertnih sistema, ekspertnih sistema i neuronskih mreža, kao i aspekti globalne integracije više informacionih sistema. Oblici integracije dva ili više kompjuterska informaciona sistema me��usobno se razlikuju po arhitekturnim rješenjima spajanja sistema. Integracija ekspertnih sistema i sistema za podršku odlučivanju može se izvesti na dva osnovna načina i to: Ekspertni sistem integrisan kao SPO komponenta gdje je moguće identifikovati pet različitih slučajeva: 1. Ekspertni sistem kao inteligentna komponenta uz bazu podataka u SPO, 2. Ekspertni sistem kao inteligentna komponenta uz bazu modela u njeno upravljanje u SPO, 3. Ekspertni sistem kao komponenta u SPO a sa namjenom da poboljša karakteristike korisničkog interfejsa, 4. Ekspertni sistem kao komponenta za pomoć u izgradnji SPO i 5. Ekspertni sistem kao komponenta u SPO koja pruža korisniku razne konsultativne usluge. Ekspertni sistem kao posebna komponenta SPO - gdje je takoĎe moguće definisati podvarijante: 1. Ulaz u ekspertni sistem je izlaz iz SPO i 2. Ulaz u SPO je izlaz iz ES. Prema Stoiljkoviću i Milosavljeviću (1995) moguće su sljedeće varijante hibridnih ekspertnih sistema: Kompletno preklopljeni. Parcijalno preklopljeni. Paralelni. Sekvencijalni. Povezani ili ugraĎeni.
3.5.2. DW Skladište podataka (Data Warehouse - DW) je 1993. godine definisao Bill Inmon (kogačesto nazivaju "ocem skladišta podataka. Skladište podataka je subjektno orijentisana, integrisana, nevolatilna, vremenski promjenljiva kolekcija podataka za podršku menadžerskom procesu odlučivanja. Data warehouse, ili skladište podataka je baza podataka sa posebnom strukturom podataka projektovanom tako da se relativno brzo i jednostavno mogu izvoditi složeni upiti nad velikom količinom podataka. Osobina DW-a da pruža brz pregled i analizu velike količine poslovnih podataka koji se kasnije uglavnom koriste za ocjenu postignutih rezultata, pri planiranju i odlučivanju,čini ih pogodnim za integraciju u sistemima za podršku odlučivanju ili osnovom za izgradnju sistema poslovne inteligencije. Uobičajeno je da je skladište podataka smješteno na mainframe serverima u preduzeću. Skladište podataka obavlja najmanje tri različite aplikacije: 1. osnovne radne aplikacije, 2. aplikacije za upite i izveštaje i 3. aplikacije za analizu i planiranje. Osnovne radne aplikacije - odnose se na tabele i statističke pakete, grafičke alate koji su korisni za upravljanje i predstavljanje podataka na individualnom PC-ju. Aplikacije za upite i raporte - obraĎuju podatke pomoću jednostavnih radnih upita i generisanje osnovnih raporta. Aplikacije za analizu i planiranje - zadovoljavaju suštinske poslovne potrebe kao što su predviĎanje, analiza proizvodnih linija, finansijska konsolidacija, profitabilnost, proizvodne mix-analize - aplikacije koje koriste postojeće podatke, željene (projektovane - koriste se za uporeĎivanje odstupanja ostvarenog od željenog stanja) ili tačno izdvojene podatke neophodne za odreĎenu analizu. Fleksibilnost i sposobnost adaptacije promjenljivim poslovnim potrebama takoĎe su vrlo bitne osobine skladišta podataka. Skladište podataka vrši funkciju objedinjavanja podataka iz svih raspoloživih izvora i ovo je upravo jedan od najtežih zadataka prilikom izgradnje skladišta podataka. Direktan ručni unos podataka u skladište podataka nije dozvoljen, jer se podaci u skladište podataka unose preko proizvodno-informacionog sistema. Unos podataka u skladište podataka obavlja se automatski i periodično. Razlikujemo alate (programske pakete) za generisanje ad hoc izveštaja npr. ORACLE Discoverer, i alate za izradu sleženih korisničkih aplikacija npr. ORACLE Express. Ovi alati namjenjeni su za rad sa skladištima podataka, i pružaju podršku top menadžmentu u donošenju poslovnih, strategijskih odluka. Data Warehouse koncept se zasniva na odvajanju OLTP (On Line Transaction Processing) i OLAP (On Line Analytical Processing) procesa. OLTP predstavlja operativni proces obrade podataka u kome se vrijednosti podataka mijenjaju kontinualno u toku dana i u trenucima koji se ne mogu unaprijed specificirati. Nasuprot OLTP, analitička obrada podataka (OLAP) se obavlja uporeĎivanjem ili obradom izvornih podataka i analizom trendova. Ovde se podaci ne mijenjaju u proizvoljnim vremenskim intervalima, već u tačno odreĎenim intervalima u zavisnosti od prirode problema koji se analizira. ROLAP, MOLAP i HOLAP su specijalizovane OLAP aplikacije. ROLAP se odnosi na relacioni OLAP. U relacione baze podataka (Relational Database - RDBMS) smještaju se podaci, a ROLAP podsistem pruža potrebnu analitičku funkcionalnost. U ROLAP-u se mogu uskladištiti velike količine podataka nad kojima se mogu efikasno izvršavati jednostavni sumarni upiti. MOLAP označava multidimenzionalini OLAP. Multidimenzionalna baza je skladište podataka i analitički mehanizam. Korisnicičuvaju svoje podatke specijalizovanim kockama (Hybrid cube) podataka. HOLAP označava hibridni OLAP, tj. kombinaciju MOLAP-a i ROLAP-a. Seagat-ov softver Holos je primjer HOLAP
okruženja. HOLAP omogućava da veličina multidimenzionalne baze bude veća nego kod MOLAP-a, ali manja nego kod ROLAP-a. Kod složenih upita brzina odgovora kod HOLAP-a jednaka je brzini rada MOLAP-a. Neki od problema pri izgradnji DW su: Objedinjavanje raznovrsnih podataka iz više nivoa (više proizvodno - informacionih sistema) realizovanih na različitim platformama. Brzo otkrivanje nastalih promjena u izvornom sistemu. Iterativni karakter izgradnje modela skladišta podataka pa prema tome i iterativni karakter izgradnje programskog sistema za ekstrakciju. Pojam Datamart ili tržište podataka, definiše funkcionalnu cjelinu koja u sebi objedinjava podatke sličnog tipa koji su organizovani u dimenzionalnom modelu (HR). Datamart najčešće je vezan za jedan dio poslovanja preduzeća, a usmjeren je ka grupi korisnika.
3.5.3. BI
Pojam BI Poslovna inteligencija ili Business Intelligence -BI kao termin predstavlja sintezu nekoliko vrlo važnih metodologija, koncepata i relevantnih tehnologija putem kojih se proces odlučivanja može učiniti efikasnijim, koristeći pri tome sisteme za podršku odlučivanja zasnovane na poslovnim činjenicama i podacima. Prvenstveno se pri tome misli na metodologije Data Warehousing, Data Mining i OLAP. Sistem za poslovnu inteligenciju je sistem za podršku odlučivanju koji koristi informacije dobivene iz strukturiranih i nestrukturiranih podataka kako internih tako i eksternih izvora, koji se pomoću navedenih tehnologija transformišu u kvalitetne informacije primjenjive u procesu odlučivanja, te vizuelno prezentuju krajnjem korisniku. Pojam Business Intelligence postojao je i mnogo ranije – u obliku “poslovne špijunaže”. Sve je to počelo 1992. godine kad je “kum” skladištenja podataka Bill Innmon definisao skladište podataka kao skup subjektno orijentisanih, integrisanih, vremenski zavisnih i nepromjenljivih podataka za podršku poslovnom odlučivanju. Razlog zbog kojeg je cijeli koncept nastao je rasterećenje transakcionih sistema (čuvenih ERP-ova) od upita za koje oni nisu optimizovani poput onih koji sumiraju milione slogova iz više tabela s više uslova u nekoliko brojevainteresantnih rukovodiocima. Zbog toga se podaci iz transakcionih aplikacija u regularnim vremenskim intervalima prebacuju u drugi sistem koji je optimizovan za takve upite, a za potrebe izvještavanja i analize. Nakon toga je nastala prava revolucija – ljudi su shvatili da se u tim podacima krije pravo blago za analizu različitih uzoraka u podacima, koje je postalo pristupačno zahvaljujući performansama savremene kompjuterske tehnologije. Takvi rezultati, ako se pravilno analiziraju i protumače, mogu donijeti kompaniji veliku kompetitivnu prednost na tržištu i finansijsku korist. Poslije nekoliko godina, sve te tehnologije za analizu svih internih i eksternih informacija iz poslovnog okruženja su zajedništvo našle pod pojmom Poslovne inteligencije ili Busineness Intelligence, odnosno u zadnje vrijeme pod uticajem Internet revolucije e-Intelligence.
Primjena BI Tipično preduzeće analizira samo 10% prikupljenih podataka. Poslovna inteligencija je način kako iskoristiti preostalih 90%. Business Intelligence je sintetički naziv za za skup alata i aplikacija koji omogućavaju prikupljanje, analizu, distribuciju i djelovanje na osnovu poslovnih informacija, s ciljem donošenja boljih poslovnih odluka. BI opservira cijelo preduzeće pri čemu svako može dobiti upravo onu informaciju koja njemu treba. Ako opservacija nije cjelovita, tada se analiza preduzeća svodi na indijsku priču u kojoj desetak slijepih ljudi, svaki odvojeno opipava neki dio slona – rep, trup, kljove, noge, uši, kičmu, bokove. Svaki od njih misli da dodiruje različitu životinju i kad izvještavaju šta su osjetili, svaki od njih opisuje vrlo različitu životinju. Stvarni se slon u njihovoj analizi nikad ne pojavljuje. Business Intelligence omogućuje proaktivan način voĎenja preduzeća, što znači da se može predvidjeti budućnost, izraditi nekoliko scenarija i biti pripremljen za svaku situaciju. Problem je kako pretvoriti informaciju u znanje. Danas se savremeno preduzeće vodi na osnovu znanja o: konkurenciji, kupcima, dobavljačima, procesima. Poslovna inteligencija je proizvodnja znanja koje je pretpostavka za donošenje poslovnih odluka.
Business Inteligence je izvorno bio namijenjen tzv. decision makerima, odnosno ljudima koji donose poslovne odluke, upravljačkoj funkciji u preduzećima, odnosno menadžerima. MeĎutim u savremenim preduzećima, proces odlučivanja je vrlo raširen, praktično odlučuju svi u svom domenu. To znači da su informacija i znanje potrebne svima. Danas su organizacione strukture puno “pliće”, radi se puno projektnim načinom rada. Više je koordinacije a manje subordinacije. Danas je Poslovna inteligencija u donošenju poslovnih odluka nezamjenjiv koncept. Svako preduzeće mora znati svoje slabe i jake strane. Danas svako savremeno preduzeće mora znati gdje mu prodaja raste, pada, šta je s profitima po proizvodima, po kupcima. Mora isto tako da zna koji su kupci novi, koji su potencijalna meta konkurencije. To jednostavno znači da je mjerenje lojalnosti kupaca izuzetno značajna stvar. Preduzeće takoĎe mora znati šta je s konkurencijom, gdje je agresivna, gdje još nije došla. Preduzeće mora uvažavati ponašanje i želje okoline. Informacija pretvorena u (sa)znanje omogućuje donošenje odluka ili onemogućuje donošenje odluka na neosnovanim informacijama. Poslovna inteligencija se danas smatra posebnom disciplinom. Menadžer znanja kao zanimanje budućnosti, već postoji. Poslovno okruženje više nije statična kategorija, već podrazumijeva intenzivnu interakciju. Ponuda proizvoda i usluga je ogromna, konkurencija je jaka, kupci su razmaženi, a tržišta su zasićena. Nove okolnosti traže nova rješenja, novi izazovi nove napore. Prošla su vremena kada je bilo dovoljno proizvesti robu ili uslugu. Uvijek je bilo nekoga ko će to kupiti. Globalizacijom tržišta, razvojem distribucionih kanala, “uplitanjem” interneta u svaku poru privrede, odnos se drastično promijenio. Iz svega ovoga rezonski proizilazi cilj izrade sistema za podršku poslovnom odlučivanju koji će pokriti sve potrebe kompanije za izvještavanjem, analizom, predviĎanjima i planiranjem. Postoje tri najvažnije stvari koje moraju biti pravilno postavljene na svoje mjesto prije početka, odnosno svaki BI projekat mora zadovoljiti bar tri osnovna uslova kojiće mu obezbijediti uspješnost (naravno, ima ih još, ali ovo su ipak osnovni uslovi): 1. mora imati jasno definisane ciljeve – ako tonije slučaj, projekat će se jednostavno rasplinuti jer niko neće shvatati šta i zašto se radi, 2. mora biti prihvaćen od poslovne strane i imati podršku top rukovodstva – u suprotnom će biti smatran još jednim hirom IT-a i 3. mora imati osigurano odgovarajuće finansiranje – takvi projekti i njima pripadajuće tehnologije su još uvijek vrlo skupe. Projekat ima sljedeće ciljeve – omogućiti transparentno izvješavanje o prodaji u cijeloj organizaciji u skladu s ovlašćenjima, analizu podataka iz prodaje i o kupcima, predviĎanje prodaje u sljedećem poslovnom periodu i na osnovu predviĎanja planiranje, budžetiranje i praćenje izvršenja plana. Radi mira u kući analizu podataka s web-sitea ostavljamo za drugu fazu projekta i zanemarićemo dijelove projekta vezane uz definiciju izvještajnih potreba, te se koncentrisati na tehnologiju u pozadini. Ne treba zaboraviti još jedan bitan razlog za uspjeh BIprojekata. Sve je više podataka i informacija, a sve je manje vremena za donošenje poslovnih odluka. Danas su preduzeća pretrpana podacima, dok s druge strane, postoji nedostatak korisnih informacija. Da bi se smanjio raskorak izmeĎu količine raspoloživih podataka i informacija, potrebno je definisati procese prikupljanja podataka i njihovu“preradu” u informacije. Gartner grupa predviĎa da će do kraja 2004, samo 20 odsto preduzeća moći “preraĎivati” više od 50 odsto ukupnih podataka koje prikupi (vjerovatnoća je 70 odsto). Razumijevajući želje i navike kupaca bolje od konkurencije, preduzeće na ovaj način stiče konkurentsku prednost. Zbog nemogućnosti “prerade” svih raspoloživih podataka javlja se“raskorak u znanju o kupcima” (“customer knowledge gap”). “Raskorak izvršenja” (“execution gap”) javlja se zbog nedostatka informacija a prije svega zbog nedostatka vremena. Pri izvršenju se misli na donošenje i provoĎenje poslovnih odluka.
Slika 11. Raskorak u znanju o kupcima Realizacija BI Tehnički gledano, materijalizacija BI projekta je informacioni sistem. Ne onaj sistem kakav je uobičajen i na koji smo navikli tj. transakcioni (salda konti, glavna knjiga, prodaja, nabava ), već jedan potpuno drugačiji. U njega podaci dolaze iz preduzeća ali i iz okoline. Izvori podataka su heterogeni a prezentacija podataka agregatna. Ne zanimaju nas fakture i otpremnice, već profiti po tržišnim segmentima, kupcima, tržišni udjeli, trendovi. BI projekti nam služe za aktivno upravljanje poslovnim rezultatom. Poznata je stvar da se poslovni rezultat ne očekuje i ne dešava sam od sebe, već se poslovnim rezultatom upravlja. Umjesto da 90% vremena trošimo na prikupljanje i izradu izvještaja mi 90% vremena trošimo na analizu!
Slika 11. Hijerarhija informacionog sistema Jedan kvalitetan BI projekat nam suštinski mora odgovoriti na sljedeća pitanja: Kakva je moja realizacija u odnosu na plan na najvećem tržištu? Da li su odstupanja u prodanim količinama, cijenama ili proizvodnom miksu? Koje je tržište najviše poraslo, koje je najviše palo? Da li je sniženje cijena donijelo povećanu prodaju? Da li su marketinške aktivnosti povećale prodaju proizvoda? Koji je moj najprofitabilniji proizvod? Koje je moje najprofitabilnije tržište? Koji kupac plaća najurednije? Kakve su moje cjenovne pozicije na pojedinom tržištu? Kakve su cjenovne pozicije nakupaca (clustera) na nekom tržištu ili na svim tržištima zajedno? Kakva je profitablinost pojedinog distribucijskog kanala? Kakva je slika pojedinog kupca (profit, otprema, dani vezivanja, način plaćanja)? Kakvi su cjenovni trendovi na pojedinom tržištu? Kakva su očekivanja u pogledu novčanih tokova? Analiza prodaje i cijena u vremenu? Da li postoji veza izmeĎu količine prodate robe i profita po kupcu ?
Koja grupa kupaca “nosi” 80% ukupnog prihoda?
Ako bismo sva ova pitanja pokušali sažeti, onda bismo ukratko pitali: GDJE, na kojim trţištima nastaje poslovni rezultat? ĈIME, kojim proizvodima postižemo poslovni rezultat? Kod KOJIH kupaca nastaje koji poslovni rezultat? Gdje nastaje 80% troškova? Kakav je trend zaduženosti poduzeća u vremenu? Kako će povećanje nabavnih cijena uticati na poslovni rezultat ? Gdje je tačka pokrića našeg preduzeća? Ovakve analize omogućavaju razradu većeg broja poslovnih scenarija. Konkurencija je spustila cijenu na najvažnijem tržištu za 10%. Možemo li ući u cjenovni rat? Koliko će nam se smanjiti dobit ukoliko i mi smanjimo cijenu? Isplati li nam se smanjiti isporuku a zadržati cijenu? Cijena najvažnije ulazne komponente devizno je zavisna! Šta će biti ako američki dolar poskupi za 5%? Koliko smo izloženi toj promjeni? Kada će naš novčani tok iz poslovnih aktivnosti biti dovoljan da bismo započeli investiciju proširenja otpremnih kapaciteta? Na ta pitanja moramo biti spremni odgovoriti brzo! Ovdje dolazi do izražaja pravovremenost informacija a ne toliko njihova tačnost. Vrijedi princip: “bolje informacija 95% tačnosti u ruci nego ona od 100% na grani”. Povećavajući znanje i posjedujući bolje informacije, unapreĎujemo intuitivno - iskustveno poznavanje nekog problema. Uz primjereno iskustvo i obdarenost intuicijom, sposobni smo bolje iskoristiti informacije i znanja o svakoj pojavi. Američkižargon poznaje i upotrebljava riječ koja objašnjava meĎudjelovanje intuicije i razuma: Educated Guess (“obrazovno pogaĎanje”). To znaĉi da onaj ko više zna lakše i taĉnije moţe pogaĊati.Važnost pravovremene informacije za donošenje poslovnih odluka opravdava misao:Informacija je energija budućnosti. Da bismo uopšte podatke analizirali, potrebno je imati na jednom mjestu planirane, ostvarene veličine, te odstupanja, kako u apsolutnom tako i u relativnom iznosu. Najveća vrijednost analize je u efikasnom izvještavanju uprave o rezultatima i njenom pravovremenom reagovanju. Odstupanja se javljaju u prodaji, nabavi i proizvodnji. Ona skreću pažnju uprave na izuzetke poreĎenjem stvarnih rezultata sa standardima. UvoĎenje BI projekta predstavlja u preduzeću novost. Zaposleni se obično opiru promjenama. Stoga se logično postavlja sljedeće pitanje: Koji su ključni faktori uspjeha uvoĎenja, sistema za upravljanje informacijama i znanjem, u preduzeću? Najveći doprinos uspjehu uvoĎenja BI projekta u preduzeće daje želja menadžmenta da ima sistem upravljanja informacijama. Mora postojati potreba, odnosno mora postojati potražnja za informacijama. Tehnička superiornost ovakvih sistema: brzina pristupa, laka prilagodljivost korisniku (“ad-hoc izvještaji”), laka čitljivost izvještaja te uvjeravanje “da je to prava stvar” ne mogu biti protivteža otporu menadžmenta. Zašto? Menadžment je “potrošač robe” koju ti sistemi proizvode, odnosno menadžment je konzument informacija za donošenje strateških i taktičkih odluka. Poznata je stvar da ako nema potražnje za robom, nema potrebe ni proizvoditi je! Poslovna inteligencija koristi koncept skladišta podataka. Skladišta podataka su skup svih tipova podataka u službi procesa donošenja odluka na svim nivoima preduzeća. Izvori podataka za skladišta podataka su heterogeni: transakcione baze podataka (vlastite baze u preduzeću), internet, strukovna udruženja, saznanja komercijalista s terena, stručne publikacije. Skladište podataka ne postoji kao gotov proizvod. Nema rješenja s police. Razlog tome jest činjenica da su informacije potrebne za poslovno odlučivanje specifične za svako preduzeće.
Skladišta podataka sadrže podatke i informacije. Do tog skupa podataka dolazi se OLAP-om. OLAP (On-Line Analitycal Processing) metoda uvedena je od strane tvorca relacionih baza podataka (E.F.Codd). To je tehnologija koja nadopunjuje relacionu tehnologiju. Nastala je iz potrebe da se zadovolji analitička potreba korisnika. OLAP tehnologija je namijenjena krajnjem korisniku. Možda je Gartner Group dala najilustrativniji prikaz: Umjesto odreĎenog broja analitičara koji provode 100% svog radnog vremena analizirajući podatke, svi menadžeri i profesionalno osoblje provodiće mali procenat svog vremena analizirajući podatke sami. Postavlja se pitanje cijene ovakvih sistema i troškova informacija. U 21. vijeku, vijeku informacija i znanja, cijena informacije jednaka je cijeni opstanka na tržištu.Stoga je uvoĎenje sistema za upravljanje poslovnim informacijama isplativa investicija. Knjigovodstvo ne bilježi oportunitetne troškove loših poslovnih odluka na osnovu nedostajućih informacija. Takve promašaje bilježe berza i konkurencija. Ta dva “mjerna instrumenta” nepogrešivo znaju kazniti slabosti našeg poslovanja. Ovo je projekat kome nema kraja. Kako konkurencija postaje agresivnija, okolina nestabilnija i budućnost neizvjesnija, zahtjevi pred sistemima analize i prognoze postaju složeniji. Poslovna inteligencija je u funkciji planiranja (budgeting), tj. kratkoročnih poslovnih odluka ali i u funkciji strategije. Izvori podataka su heterogeni a prezentacija podataka agregatna. Informacija predstavlja moćno oružje u poslovnim pregovorima, argumentovanom nastupu i omogućuje kvalitetno operativno planiranje. Moguće je analizirati ponašanje kupaca, dobavljača, posmatrati pojedine tržišne segmente i predviĎati buduće pojave. Poslovna inteligencija omogućuje bolje razumijevanje vlastitih kupaca i spoznaju šta ih potiče na takvo ponašanje. Pri upotrebi računarske tehnologije i modela u poslovnom odlučivanju treba imati na umu: Modeli ne zamjenjuju kreativnost menadžera ni njihovu moć prosuĎivanja. Modeli u pravilu ne generišu rješenja poslovnog problema, već pružaju opcije za njihovo rješavanje. Modele nije nužno implementirati, odnosno provesti odluku prema njihovom rješenju. Odluke ne donose modeli već ljudi.
3.5.4. CRM
Pojam CRM CRM (Customer Relationship Management) se definiše kao strategija prikupljanja vrlo važnih podataka o korisnicima i djelovanja na osnovu tih podataka u svrhu izgradnje dugoročnih profitabilnih odnosa s klijentima. CRM, kao strategija naprednog upravljanja odnosima s korisnicima, sve je češće nešto o čemu se govori, nešto na čemu se radi i nešto o čemu se razmišlja. CRM kao pojam dobiva na svom značenju od sredine devedesetih godina prošlog vijeka, a danas se smatra neizbježnim faktorom uspjeha na tržištu. Postoje brojne dileme vezane za CRM, čak i kod osoba i organizacija koje su znatno uključene u njegov razvoj kao strategije ili tehnološke podrške. Koji je pristup rješavanju, odnosno razvoju CRM-a (postupno ili sve od jednom, unutrašnji razvoj ili kupovina "svjetskog" rješenja itd.); u kojoj mjeri kupovina tehnologije rješava implementaciju CRM strategije; koje podatke moramo znati i prikupiti o svojim korisnicima; koja znanja moramo razviti unutar organizacije; kako izmjeriti uspješnost implementacije; odakle krenuti - od korisničkih potreba, internih procesa ili tehnologije - sve su to pitanja koja se neprestano nameću svima koji se na bilo koji način bave CRMom. CRM strategija je nastala u ekonomijama zapadnog svijeta kod poslovnih sistema kojima je prioritet postalo zadržavanje postojeće velike baze korisnika zbog snažnog prodiranja proizvoda ili usluga na tržištu te jake konkurencije. Pojam CRM danas vrlo često podrazumijeva tehnologiju koja direktno upravlja odnosima s korisnikom, a obuhvata rješenja za upravljanje marketingom, prodajom i pružanjem usluge korisniku. Dok je devedesetih godina 20. vijeka svaki članak o CRM-u započinjao s polemikom: strategija ili tehnologija, danas je jasno da je CRM poslovna filozofija i pripadajuća strategija naprednog upravljanja odnosima s korisnicima prema principu poštovanja individualnosti svakog pojedinca. CRM je prirodan proces i prepoznajemo ga u svakodnevnom ponašanju. Strategije slične CRM-u prepoznajemo i u ekonomijama osvajanja u istoriji. Kada logistički ljudski resursi nisu dovoljni za nova osvajanja, slijedi utvrĎivanje i čuvanje postojećih posjeda.
CRM koncept CRM je strategija poslovanja i komunikacije s klijetima čiji je cilj prikupljanje informacija o klijentu koje se koriste za povećanje zadovoljstva i lojalnosti klijenata, kako bi odnos s njima bio bolji, duži i profitabilniji. U praksi se često koristi i sintagma da CRM objedinjava elemente pridobijanja klijenata (customer acquisition), zadržavanja klijenata (customer retention), kvalitete usluge (service quality) i profitabilnost klijenta (profitability). Isto tako CRM je ključna poluga u prefokusiranju poslovne organizacije iz organizacijsko-centrične u klijento-centričnu. U tom procesu najvažniji dio je organizacija i analiziranje podataka i informacija, jako je vezan na DW i DM tehnologije, te je jedan od glavnih pravaca današnjeg razvoja poslovne inteligencije. Sastoji se od tri ključna elementa: procesa, tehnologije i ljudi, a dijeli se u tri osnovne podkategorije: operativni CRM (prikupljanje podataka), analitički CRM (analiza podataka) i front-end aplikacije.
Slika 12. CRM koncept
Da bi preduzeće uopšte moglo započeti sa CRM-om, ono mora razvijati tzv. "klijentocentriĉnu" poslovnu filozofiju i kulturu. To znači da klijent mora biti polazna tačka svake akcije koja se namjerava preduzeti. Sve poslovne aktivnosti moraju biti povezane sa potrebama klijenata. Marketinška strategija mora biti "outside-in", što pretpostavlja orijentisanost na potrebe klijenta, a ne na karakteristike proizvoda i usluga. Preduzeće se mora posvetiti jedinstvenoj vrijednosti svojih prozvoda i usluga, ono po čemu je drugačije od ostalih koji nude isti proizvod i uslugu, jer upravo ta jedinstvenost stvara zadovoljstvo njihovih klijenata. Da li je to brzina usluge, tačnost isporuke ili nešto treće, preduzeće mora samo otkriti. Sva područja poslovanja potencijalne su poluge zadovoljstva klijenata, pa je i praćenje i upravljanje tim zadovoljstvom zadatak svih odjela u preduzeću, a ne ekskluzivno marketinga ili odjela podrške korisnicima. Svi u preduzeću moraju neprestano nuditi i komunicirati sa klijentima u cilju pomenute jedinstvene vrijednosti. CRM mora biti integrisan u cijeli proces iskustva klijenata, od inicijalnog kontakta do krajnje kupovine, a marketing, prodaja i odjel podrške korisnicima moraju biti integrisani putem informacione tehnologije. To je prvi nivo implementacije CRM-a, tzv. operativni CRM, a podrazumijeva automatizaciju i optimizaciju cijelokupnog prodajnog procesa (ugovaranja sastanaka, izrade ponuda i sl), zatim automatizaciju marketinga primjenom informacionih sistema namjenjenih dizajnu, izvršenju i mjerenju učinaka marketinških kampanja, praćenju kontakata sa klijentima, te na kraju automatizaciju podrške klijentima kroz call centre. Ali kao što ni piramida neće stajati naglavačke, tako niti nabavka odgovarajuće tehnologije nije garancija uspjeha. CRM mora biti poslovna strategija, sa jasno izraženim poslovnim ciljevima, a tehnologija je kritični i omogućavajući faktor kojim se strategija pretvara u poslovne rezultate. Kontinuirana inovacija te jedinstvene vrijednosti koja se pruža klijentima takoĎe je sastavni dio CRM-a. Proizvodi i usluge moraju se mijenjati i obogaćivati u skladu sa potrebama klijenata, a poduzeća moraju imati sposobnost prepoznavanja njihovih potreba i prije nego one budu jasno izražene. CRM nije jednokratan poduhvat, već proces koji se neprestano ponavlja i inovira. Svaki ciklus započinje sticanjem odgovarajućeg kritičnog znanja o klijentima, odnosno detaljnom analizom njihovog ponašanja, navika, želja i potreba. Klijenti se segmentiraju na osnovu odreĎenih zajedničkih osobina, i identifikuju se najprofitabilniji klijenti, klijenti koji imaju potencijal da postanu profitabilni ako se investira u odnose s njima, i klijenti u koje se više ne isplati ulagati. Ovo je tehnološki najzahtjevniji dio CRM-a, koji podrazumijeva integraciju svih relevantnih podataka o klijentima, kako iz transakcionih sistema, tako i iz eksternih izvora podataka u jedinstveno skladište podataka, a zatim i eksploataciju podataka skladišta različitim OLAP alatima, statističkim paketima, primjenom metoda kopanja podataka i sl. Ovo je ujedno i najkritičniji dio cijelog ciklusa CRM-a jer se bira onaj segment klijenata koji će se targetirati i analiziraju njihove potrebe, a predstavlja drugu fazu implementacije CRM-a, tzv. analitiĉki CRM. Znanje stečeno na ovakav način se zatim iskorištava kod osmišljavanja marketinških kampanja namjenjenih izabranom segmentu, tj. onim klijentima koji ostvaruju najveći profit. Koji je pristup za njih najbolji? Koje proizvode i usluge i kojim kanalima im nuditi? Zadnji korak u ciklusu je efikasna interakcija sa klijentima: ne samo da se realizuju marketinške kampanje, već i da se istovremeno prati odgovor klijenata, tj. prikupljaju se podaci o tome kako su klijenti reagovali na odreĎenu akciju. Tako prikupljeni podaci objedinjavaju se sa već postojećim u skladištu podataka, iznova se analiziraju i stiče se novo znanje, koje se iskorištava opet za izradu novih marketinških planova, ali i svaki sljedeći put kada preduzeće doĎe u interakciju sa klijentom.
CRM je dakle ciklus koji se sastoji od tri koraka koje se uvijek iznova ponavljaju: stekni znanje o klijentima –osmisli i preduzmi akcije na osnovu tog znanja – prikupi rezultate akcija i kombinuj ih sa već postojećim znanjem da bi stvorio novo. Koristi, koje očekujemo od uvoĎenja CRM koncepta i programske opreme u preduzeće su prije svega u porastu prihoda od prodaje proizvoda i usluga, konkurentnosti, većem zadovoljstvu klijenata i smanjenju troškova. Kompanije širom svijeta implementiraju procese i tehnologije koji im omogućavaju uočavanje razlike izmeĎu zadovoljnog, odanog i profitabilnog klijenta te djelovanje u skladu s tim saznanjima. Preduzeća koja strateški pristupaju CRM projektima s jasno definisanim pravilima i okvirima za procjenu, planiranje i unapreĎenje svojih CRM inicijativa imaju dvaput veće izglede za ostvarivanje planiranih ciljeva. Gartnerove Nagrade za kvalitet u upravljanju odnosima s klijentima se dodjeljuju u dvije kategorije: prva je LE (Large Enterprises) - za velike kompanije čiji prihod premašuje 250 miliona USD te zapošljavaju više od 500 ljudi; druga je SME (Small to Midsize Enterprise) -za male i srednje kompanije čiji prihod ne prelazi 250 milionaa USD te imaju manje od 500 zaposlenih. Nagrade za područje Amerike već se tradicionalno dodjeljuju na proljetnim i jesenjim Gartnerovim CRM samitima, dok je prošle godine ustanovljena i nagrada za CRM kvalitet zemalja EMEA-e, koja se dodjeljuje na ljetnom skupu. U Gartneru su analizirali inicijative 16 pobjednika i finalista Nagrada za kvalitet u upravljanju odnosima s kupcima iz perioda od 2001. do 2002. godine u Europi i Sjevernoj Americi, da bi izvukli znanja koja se mogu prikupiti od tih izvanrednih organizacija. U tim su primjerima predstavljeni najbolji postupci koji oslikavaju neke od osnovnih principa ključnih za uspjeh u CRM-u. Poznati proizvoĎač automobila Renault u Francuskoj je opremio svoje prodajne predstavnike laptop računarima i specijalizovanim programima koji omogućuju izradu personalizovanih ponuda u direktnoj interakciji sa klijentom u skladu sa njegovim stvarnim željama i potrebama. Takav pristup prodaji baziran je na njihovom stateškom opredjeljenju po kojem je klijent – partner, čime stvaraju dodanu vrijednost za klijente. U plate radnika informatičke firme Cysco Systems ugraĎen je varijabilni dio koji je onoliko velik koliko je veliko zadovoljstvo klijenata kojima odreĎena grupa radnika preduzeća pruža podršku, a to je bazirano na stateškom stavu firme da se jedino može unaprijeĎivati i poboljšavati ono što se mjeri. CRM je poslovna strategija, oblikovana tako da omogućava poduzeću da razumije i predviĎa potrebe sadašnjih i potencijalnih stranaka. Podaci o strankama prikupljaju se sa više područja u preduzeću, spremaju se u centralnoj bazi podataka i analiziraju se i distribuiraju na ključne tačke. CRM je prirodna i deterministička evolucija funkcija prodaje i trgovine. CRM je za većinu preduzeća nova strategija koja vodi do veće dobiti putem povjerenja stranaka (stranke su bogatsvo preduzeća). U slučaju da preduzeće ne brine za svoje stranke, postoji opasnost da će to učiniti konkurent. Poduzeće mora tretirati CRM koncept kao program projekata koji su oblikovani tako da omogućavaju izgradnju svih potrebnih CRM mogućnosti i veza s ostalim inicijativama u poduzeću (kao npr. elektronsko poslovanje). CRM na Internetu, ili eCRM, posebna je kategorija koja se može, obzirom na prirodu Interneta, još više automatizovati. Na Internetu je segmentaciju kupaca moguće provesti do nivoa pojedinačnog kupca kojem se, zavisno od sakupljenih informacija, može ponuditi prilagoĎena verzija usluge ili proizvoda koja će najbolje odgovarati njegovim potrebama. Jedini razlog protiv uvoĎenja CRM sistema je visoka cijena integracije CRM sistema sa postojećim sistemom poslovanja. Integrisati sve tzv. touchpointe (mjesta dodira sa kupcem) u jedinstven sistem skupo je rješenje, pogotovo u našim uslovima (mali broj preduzeća ima stalnu vezu na Internet, a o meĎusobnoj povezanosti prodajnih mjesta da ne govorimo). CRM nije pojedinačna aktivnost. U
pitanju je iterativni proces kada analiza kupaca dovodi do prilagoĎavanja kupcu, a odgovori kupaca na to prilagoĎavanje ulaze u analizu slijedećeg CRM ciklusa.
4.
PROJEKTOVANJE INFORMACIONIH SISTEMA
Potrebe za uvoĎenjem informacionog sistema su nastale iz potreba za savremenim protokom informacija. Očekivanja koja su postavljena pred uvoĎenje IS-a su sljedeća: Smanjenje broja radnih mjesta. Povećanje produktivnosti po zaposlenom. Automatizacija što većeg broja svih poslovnih funkcija. Uspostavljanje komunikaciono-informacionih mreža unutar preduzeća i okruženja. Implementacija informacionih sistema koji upotrebom informacionih tehnologija omogućuju: bolji tržišni nastup, kvalitetniju i bržu izradu projekata, efikasnije voĎenje poslova izvoĎenja i kvalitetniji informatički tretman pojedinih organizacionih dijelova. Organizovanje protoka informacija. Progres informaciono dokumentacionih poslova. Osnovnu filozofiju projektovanja informacionog sistema (IS) predstavlja stvaranje objektivnije slike realnog sistema. Proces projektovanja informacionog sistema intenzivnije se počeo razvijati sedamdesetih godina prošloga vijeka. Jednostavno se došlo do saznanja da postojeća sredstva za izgradnju informacionih sistema nisu zadovoljavajuća ni produktivna. Tako je inicirana potreba stvaranja velikog broja tehnika i metoda projektovanja informacionih sistema, koje u prvi plan stavljaju inženjerski karakter te aktivnosti. Individualna vještina i intuitivni pristup zamijenjeni su ili dopunjeni definisanim sredstvima za projektovanje i odgovarajućom metodologijom rada. Informacioni sistem postoji zbog korisnika, odnosno korisnik je najvažniji faktor u procesu projektovanja i evaluacije projekta informacionog sistema. Korisnik posjeduje informacije o realnom sistemu i definiše zahtjeve vezane za performanse ili operativne osobine budućeg sistema koji se projektuje. MeĎutim, kako je savremena informaciona tehnologija relativno komplikovana i složena za prosječnog korisnika, on realno ne može prihvatiti sve mogućnosti koje mu nudi ta tehnologija. Upravo iz tih razloga metodologija projektovanja informacionih sistema ima tendenciju da proces projektovanja predstavi na logičkom odnosno pojmovnom nivou. To znači da se u procesu projektovanja težište stavlja na logiĉko definisanje tokova podataka, procesa njihove obrade i strukture osnovnih podataka sistema, nezavisno od njihove fizičke realizacije. Proces razvoja informacionog sistema pretpostavlja i upoznavanje strukture organizacionog odnosno tehnološkog sistema za koji se razvija informacioni sistem. Znanja o realnom sistemu projektant stiče na osnovu postojeće dokumentacije i direktne komunikacije sa korisnicima sistema, Ova komunikacija sa korisnicima je posebno efikasna jer sistemi obično nastaju "prirodnom evolucijom", koju uvijek ne prati odgovarajuća odnosno ažurna dokumentacija, a i sam projektant se često teško snalazi u dokumentaciji. Elementarna pretpostavka za uspješnu komunikaciju izmeĎu projektanta i korisnika informacionog sistema je postojanje zajedničkog jezika učesnika komunikacije. U tom kontekstu razvijeno je više grafičkih sredstava odnosno jezika odgovarajućih za prikaz i opis raznih aspekata informacionog sistema. Ovi jezici sadrže relativno mali broj simbola i oni su jednostavi i jasni za razumijevanje.Upravo razvojem ovih sredstava za opisivane odnosno projektovanje omogućeno je aktivno učestvovanje korisnika sistema u procesu analize postojećeg i kreiranja i oblikovanja novog informacionog sistema, kao i evaluacije predloženog projekta informacionog sistema. Praksa pokazuje da najčešći problemi prilikom projektovanja sistema dolaze od konfuzije ili nepreciznosti zahtjeva koji se nalaze pred novim informacionim sistemom. Korisnik obično poznaje mali obim posla i funkcija, a informacioni sistem standardno zahtjeva veliki obim meĎusobno
povezanih tokova i procesa. Taj problem se prevazilazi od strane projektanta informacionog sistema na taj način da projektant "rekonstruiše" postojeći sistem i definiše novi informacioni sistem na bazi često divergentnih znanja i zahtjeva veće grupe korisnika. TakoĎe, projektant informacionog sistema mora voditi računa o modulima odnosno podsistemima informacionog sistema i njihovom spajanju u integralni informacioni sistem. Opis rada realnog sistema predstavlja veliki problem iz jednostavnog razloga što ne mogu da se koriste prirodni jezici zbog mnogih jezičkih dvosmislenosti. Isto tako precizan opis preko formalnih jezika obično je nerazumljiv i neprihvatljiv za većinu korisnika. Za tu svrhu uvodi se odgovarajuća tehnika koja organizuje prirodne prirodne jezike na taj način da eliminiše dvosmislenost i omogućuje efikasnu komunikaciju i razumijevanje.
4.1. BAZA PODATAKA 4.1.1. Baza podataka, DBMS Baza podataka predstavlja viši nivo rada s podacima u odnosu na klasične programske jezike. To je tehnologija koja je nastala s namjerom da se uklone slabosti tradicionalne “automatske obrade podataka” iz 60-tih i 70-tih godina 20. vijeka. Tehnologija je ostvarila veću produktivnost, kvalitet i pouzdanost u razvoju aplikacija koje se svode na pohranjivanje i pretraživanje podataka u kompjuterskom sistemu. Baza podataka je skup medusobno povezanih podataka, pohranjenih u spoljnoj memoriji računarskog sistema. Podaci su istovremeno dostupni raznim korisnicima i aplikacionim programima. Ubacivanje, promjena, brisanje i čitanje podataka obavlja se posredstvom zajedničkog softvera. Korisnici i aplikacije pritom ne moraju poznavati detalje fizičkog prikaza podataka, već se referenciraju na logičku strukturu baze. Sistem za upravljanje bazom podataka (Data Base Management System -DBMS) je poslužitelj (server) baze podataka. On oblikuje fizički prikaz baze u skladu s traženom logičkom strukturom. Istovremeno, on obavlja u ime klijenata sve operacije s podacima. Dalje, on je u stanju podržati razne baze, od kojih svaka može imati svoju logičku strukturu, ali u skladu s istim modelom. Isto tako, brine se za sigurnost podataka, te automatizuje administrativne poslove s bazom. Podaci u bazi su logički organizovani u skladu s nekim modelom podataka. Model podataka je skup pravila koja odreĎuju kako može izgledati logička struktura baze. Model čini osnovu za koncipiranje, projektovanje i implementaciju baze. Dosadašnji DBMS-i obično su podržavali neki od sljedećih modela: Hijerarhijski model. Baza je predstavljena jednim stablom ili skupom stabala. Čvorovi su tipovi zapisa, a hijerarhijski odnos “nadreĎeni-podreĎeni”izražava veze meĎu tipovima zapisa. Mreţni model. Baza je predstavljena usmjerenim grafom. Čvorovi su tipovi zapisa, a lukovi definišu veze meĎu tipovima zapisa. Relacioni model. Zasnovan na matematičkom pojmu relacije. I podaci i veze meĎu podacima prikazuju se “pravougaonim” dvodimenzionalnim tabelama. Objektni model. Inspirisan je objektno-orijentisanim programskim jezicima. Baza je skup trajno pohranjenih objekata koji se sastoje od svojih internih podataka i “metoda” (operacija) za rukovanje s tim podacima. Svaki objekat pripada nekoj klasi. IzmeĎu klasa se uspostavljaju veze nasljeĎivanja, agregacije, odnosno meĎusobnog korišćenja operacija. Hijerarhijski i mrežni model bili su u uptrebi u 60-tim i 70-tim godinama 20. vijeka. Od 80-tih godina pa sve do danas dominira relacioni model. Očekivani prielaz na objektni model za sada se nije desio, tako da današnje baze podataka uglavnom još uvijek možemo poistovjetiti s relacionim bazama podataka.
4.1.2. Ciljevi baza podataka Prihvatajući konstataciju da baze podataka predstavljaju viši nivo rada s podacima u odnosu na klasične programske jezike, zaključuje se da se taj viši nivo rada ogleda u tome što tehnologija baza podataka nastoji (i u velikoj mjeri uspijeva) ispuniti sljedeće ciljeve.
Fiziĉka nezavisnost podataka. Razdvaja se logička definicija baze od njene stvarne fizičke strukture. To znači, ako se fizička struktura promijeni (na primjer, podaci se prepišu u druge datoteke na drugim diskovima), to neće zahtijevati promjene u postojećim aplikacijama. Logiĉka nezavisnost podataka. Razdvaja se globalna logička definicija cijele baze podataka od lokalne logičke definicije za jednu aplikaciju. Drugim riječima, ako se logička definicija promijeni (npr. uvede se novi zapis ili veza), to neće zahtijevati promjene u postojećim aplikacijama. Lokalna logička definicija obično se svodi na izdvajanje samo nekih elemenata iz globalne definicije, uz neke jednostavne transformacije tih elemenata. Fleksibilnost pristupa podacima. U starijim hijerarhijskim i mrežnim bazama podataka, staze pristupanja podacima bile su unaprijed definisane, dakle korisnik je mogao pretraživati podatke jedino onim redoslijedom koji je bio predviĎen u vrijeme projektovanja i implementacije baze. Danas se zahtijeva da korisnik može slobodno pretraživati po podacima, te po svom nahoĎenju uspostavljati veze meĎu podacima. Ovom zahtjevu zaista zadovoljavaju jedino relacione baze podataka. Istovremeni pristup do podataka. Baza mora omogućiti da veći broj korisnika istovremeno koristi iste podatke. Pritom ti korisnici ne smiju ometati jedan drugoga, te svaki od njih treba imati utisak da sam radi s bazom. Ĉuvanje integriteta. Nastoji se automatski sačuvati korektnost i konzistencija podataka, i to u situaciji kad postoje greške u aplikacijama, te konfliktne istrovremene aktivnosti korisnika. Mogućnost oporavka nakon kvara. Mora postojati pouzdana zaštita baze u slučaju kvara hardvera ili grešaka u radu sistemskog softvera. Zaštita od neovlašćenog korišćenja. Mora postojati mogućnost da se korisnicima ograniče prava korišćenja baze, dakle da se svakom korisniku regulišu ovlašćenja šta on smije a šta ne smije raditi s podacima. Zadovoljavajuća brzina pristupa. Operacije s podacima moraju se odvijati dovoljno brzo, u skladu s potrebama odreĎene aplikacije. Na brzinu pristupa može se uticati odabirom pogodnih fizičkih struktura podataka, te izborom pogodnih algoritama za pretraživanje. Mogućnost podešavanja i kontrole. Velika baza zahtijeva stalnu brigu: praćenje performansi, mijenjanje parametara u fizičkoj strukturi, rutinsko pohranjivanje rezervnih kopija podataka, regulisanje ovlašćenja korisnika. Takode, svrha baze se vremenom mijenja, pa povremeno treba podesiti i logičku strukturu. Ovakvi poslovi moraju se obavljati centralizovano. Odgovorna osoba zove se administrator baze podataka, kome na raspolaganju stoje razni alati i pomagala.
4.1.3. Arhitektura baze podataka Arhitektura baze podataka strukturirana je od tri “sloja” i veza medu slojevima kako je predstavljeno na Slici 13. Radi se o tri nivoa apstrakcije. Fiziĉki nivo odnosi se na fizički prikaz i raspored podataka na jedinicama spoljne memorije. To je aspekt kojeg vide samo sistemski programeri (oni koji su razvili DBMS). Sam fizički nivo može se dalje podijeliti na više pod-nivoa apstrakcije, od sasvim konkretnih staza i cilindara na disku, do već donekle apstraktnih pojmova datoteke i zapisa kakve susrećemo u klasičnim programskim jezicima. Raspored pohranjivanja opisuje kako se elementi logičke definicije baze preslikavaju na fizičke ureĎaje. Globalni logiĉki nivo odnosi se na logičku strukturu cijele baze. To je aspekt kojeg vidi projektant baze odnosno njen administrator. Zapis logičke definicije naziva se shema (engleski takoĎe schema). Shema je tekst ili dijagram koji definiše logičku strukturu baze, i u skladu je sa zadatim modelom. Dakle imenuju se i definišu svi tipovi podataka i veze medu tim tipovima, u skladu s pravilima korišćenog modela. Takode, shema uvodi i ograničenja kojim se čuva integritet podataka. Lokalni logiĉki nivo odnosi se na logičku predstavu o dijelu baze kojeg koristi pojedina aplikacija. To je aspekt kojeg vidi korisnik ili aplikacioni programer. Zapis jedne lokalne logičke definicije zove se pogled (engleski view) ili pod-shema. To je tekst ili dijagram kojim se imenuju i definišu svi lokalni tipovi podataka i veze medu tim tipovima, opet u skladu s pravilima korišćenog modela. TakoĎe, pogled zadaje preslikavanje kojim se iz globalnih podataka i veza izvode lokalni.
Slika 13. Arhitektura baze podataka Za stvaranje baze podataka potrebno je zadati samo shemu i poglede. DBMS tada automatski generiše potrebni raspored pohranjivanja i fizičku bazu. Administrator može samo donekle uticati na fizičku strukturu baze, podešavanjem njemu dostupnih parametara. Programi i korisnici ne pristupaju direktno fizičkoj bazi, već dobivaju ili pohranjuju podatke posredstvom DBMS-a. Komunikacija programa odnosno korisnika s DBMS-om obavlja se na lokalnom logičkom nivou.
4.1.4. Jezici za rad s bazama podataka Komunikacija korisnika odnosno aplikacionog programa i DBMS-a odvija se pomoću posebnih jezika. Ti jezici tradicionalno se dijele na sljedeće kategorije. Jezik za opis podataka (Data Description Language - DDL). Služi projektantu baze ili administratoru u svrhu zapisivanja sheme ili pogleda. Tim jezikom definišemo podatke i veze medu podacima, i to na logičkom nivou. Ponekad postoji posebna varijanta jezika za shemu, a posebna za poglede. Naredbe DDL obično podsjećaju na naredbe za definisanje složenih tipova podataka u jezicima poput COBOL, PL/I, C, Pascal. Jezik za manipulisanje podacima (Data Manipulation Language - DML). Služi programeru za uspostavljanje veze izmeĎu aplikacionog programa i baze. Naredbe DML omogućuju “manevrisanje” po bazi, te jednostavne operacije kao što su upis, promjena, brisanje ili čitanje zapisa. U nekim softverskim paketima, DML je zapravo biblioteka potprograma: “naredba” u DML svodi se na poziv potprograma. U drugim paketima zaista se radi o posebnom jeziku: programer tada piše program u kojem su izmiješane naredbe dvaju jezika, pa takav program treba prevoditi s dva prevodioca (DMLprecompiler, obični compiler). Jezik za postavljanje upita (Query Language - QL). Služi neposrednom korisniku za interaktivno pretraživanje baze. To je jezik koji podsjeća na govorni (engleski) jezik Naredbe su neproceduralne, dakle takve da samo specificiraju rezultat kojeg želimo dobiti, a ne i postupak za dobivanje rezultata. Ovakva podjela na tri jezika danas je već prilično zastarjela. Naime, kod relacionih baza postoji tendencija da se sva tri jezika objedine u jedan sveobuhvatni. Primjer takvog integrisanogjezika za relacione baze je SQL: on služi za definisanje podataka, manipulisanje i pretraživanje. Integrisani jezik se može koristiti interaktivno (preko on-line interpretera) ili se on može pojavljivati uklopljen u aplikacione programe. Treba istaći da navedene vrste jezika nisu programski jezici. Dakle ti jezici su nam neophodni da bi se povezali s bazom, ali oni nam nisu dovoljni za razvoj aplikacija koje će nešto raditi s podacima iz baze. Tradicionalni način razvoja aplikacija koje rade s bazom je korišćenje klasičnih programskih jezika (COBOL, PL/I, C, Pascal itd.) s inkorporisanim DML-naredbama. U 80-tim godinama 20. vijeka bili su dosta popularni i tzv. jezici 4. generacije (4-th Generation Languages - 4GL): radi se o jezicima koji su bili namijenjeni isključivo za rad s bazama, te su zato u tom kontekstu bili produktivniji od klasičnih programskih jezika opšte namjene. Problem s jezicima 4. generacije je bio u njihovoj nestandardnosti: svaki od njih je u pravilu bio dio nekog odreĎenog softverskog paketa za baze podataka, te se nije mogao koristiti izvan tog paketa (baze). U savremenom dobu, aplikacije se najčešće razvijaju u standardnim objektno orijentisanim programskim jezicima (Java, C++, itd.). Za interakcije s bazom koriste se unaprijed pripremljene klase objekata. Ovakva tehnika je dovoljno produktivna zbog korišćenja gotovih klasa, a rezultujući program se lako dotjeruje, uklapa u veće sisteme ili prenosi s jedne baze na drugu.
4.1.5. Softverski paketi za rad s bazama podataka Baze podataka se u pravilu realizuju korišćenjem nekog od provjerenih softverskih paketa. Tabela 7. daje pregled softvera koji u ovom trenutku predstavljaju tehnološki vrh te imaju značajan udio na svjetskom tržištu. Gotovo svi današnji softverski paketi podržavaju relacioni model i SQL. Svaki od njih sadrži svoj DBMS, uobičajene klijente (na primjer interaktivni interpreter SQL), te biblioteke i alate za razvoj aplikacija. Svaki paket isporučuje se u verzijama za razne računarske platforme (operacione sisteme).
Konkurencija meĎu proizvodačima softvera za baze podataka je izuzetno velika, tako da je posljednjih godina često dolazilo do njihovog nestanka, spajanja ili preuzimanja. Lista relevantnih softverskih paketa zato je svake godine sve kraća. Jedino osvježenje predstavlja nedavna pojava public-domain sotvera poput MySQL.
ProizvoĊaĉ Produkt Operacioni sistem Jezik
Tabela 7. Softverski paketi za rad s bazama podataka
4.1.6. Relacioni model baza podataka Relacioni model teoretski je zasnovan krajem 60-tih godina 20. vijeka, u radovima E. F. Codd-a. Model se dugo pojavljivao samo u akademskim raspravama i knjigama. Prve realizacije na računarima bile su suviše spore i neefikasne. Zahvaljujući intenzivnom istraživanju, te napretku samih računara, efikasnost relacionih baza podataka postepeno se poboljšavala. Sredinom 80-tih godina 20. vijeka relacioni model je postao prevladavajući. I danas većina DBMS koristi taj model. Relaciona baza podataka se sastoji od serije dvodimenzionalnih tabela. Termin "relaciona baza podataka" dolazi od činjenice da ona koristi relaciju (odnos) umjesto datoteke. Relacija je tabela sastavljena od slogova. Unutar jedne tabele može postojati samo jedna vrsta slogova ili entiteta. Relacione tabele pokazuju logičke a ne fizičke odnose, a zanemaruje redoslijed podataka odnosno slogova uključenih u relaciju. Relacioni model odvaja bazu podataka od operativnog sistema kao i od aplikacije. Kada se da zahtjev za informacijama, sistem napravi tabelu koja sadrži te informacije. Standardni programski jezik za izražavanje pristupa podacima i manipulaciju sa tabelama u relacionoj bazi podataka se naziva SQL (Structured Query Language). U ovom jeziku, pitanja na jednostavnom engleskom jeziku se automatski prevode u SQL. U ovom slučaju softverski program, koji se zove Natural language (prirodni jezik) i koji dozvoljava upite u ograničenoj formi prirodnog jezika, analizira korisnikov upit, prevodi ga u upit na SQL, prenosi SQL zahtjev DBMS-u i daje na displeju podatke korisniku. Pravila dr. Codd-a za relacioni model baze podataka: 1. Relacioni DBMS mora biti u mogućnosti da manipuliše u potpunosti bazama podataka kroz svoje relacione mogućnosti. 2. Pravila o informacijama - sve informacije u relacionoj bazi podataka (uključujući imena tabele i kolona) predstavljaju se eksplicitno kao vrijednosti u tabeli. 3. ObezbjeĎivanje pristupa svakoj vrijednosti u relacionoj bazi podataka može se pristupiti upotrebom kombinacije imena tabele, vrijednosti primarnog ključa i imena kolone. 4. Sistemska podrška nedefinisanim vrijednostima - DBMS obezbjeĎuje sistemsku podršku u radu sa nedefinisanim veličinama (nepoznati ili nepromijenjivi tipovi podataka), koji se razlikuju od predefinisanih vrijednosti i nezavisni su od bilo kog domena. 5. Aktivan, uvijek dostupan relacioni katalog - opis baze podataka i njenog sadržaja je predstavljen na logičkom nivou u vidu tabela i može se pretraživati pomoću jezika baze. 6. Razumljiv podjezik podataka - bar jedan podržani jezik mora da ima dobro definisanu sintaksu i da bude razumljiv. Mora da podržava definiciju podataka, manipulisanje podacima, pravila integriteta, autorizaciju i transakcije. 7. Pravilo za ažuriranje pogleda - svi pogledi koji se teoretski mogu ažurirati, ažuriraju se kroz sistem. 8. Unošenje, ažuriranje i uklpapanje podataka na nivou skupova - DBMS za dobijanje podataka na nivou skupova i za unošenja, ažuriranje i uklanjanje. 9. Fizička nezavisnost podataka - mjenjanje fizičkog zapisa strukture ili metoda pristupa ne utiče na aplikacije i ad-hoc programe. 10. Logička nezavisnost podataka - koliko god je moguće, promjena strukture tabela ne utiče na aplikacije i ad-hoc programe. 11. Nezavisnost integriteta - jezik baze podataka mora da obezbjedi način za definisanje pravila integriteta. Ona moraju biti sačuvana u katalogu, koji je uvijek dostupan i ne mogu se predvidjeti. 12. Nezavisnost od distribucije - prva ili ponovna distribucija podataka ne utiče na zahtjeve aplikacija i ad-hoc programe. 13. Zaštita podataka - ne smije postojati mogućnost zaobilaženja pravila integriteta definisanih jezikom baza podataka upotrebom jezika koji rade na niskom nivou. Relacioni model zahtijeva da se baza podataka sastoji od skupa pravougaonih tabela - tzv. relacija. Svaka relacija ima svoje ime po kojem je razlikujemo od ostalih u istoj bazi. Jedna kolona relacije
obično sadrži vrijednost jednog atributa (za entitet ili vezu) - zato kolonu poistovjećujemo s atributom i obratno. Atribut ima svoje ime po kojem ga razlikujemo od ostalih u istoj relaciji. Vrijednosti jednog atributa su podaci istog tipa. Dakle, definisan je skup dozvoljenih vrijednosti za atribut, koji se zove domenaatributa. Vrijednost atributa mora biti jednostruka i jednostavna (ne može se rastaviti na dijelove). Pod nekim uslovima tolerišemo situaciju da vrijednost atributa nedostaje (nije upisana). Jedan red relacije obično predstavlja jedan primjerak entiteta, ili bilježi vezu izmeĎu dva ili više primjeraka. Red nazivamo n-torka. U jednoj relaciji ne smiju postojati dvije jednake n-torke. Broj atributa je stepen relacije, a broj n-torki je kardinalnost relacije.
Normalizacija relacione sheme Relaciona shema, dobivena iz ER-sheme na osnovu prethodnih uputstava, može sadržavati nedorečenosti koje treba otkloniti prije implementacije. Proces daljnjeg dotjerivanja sheme zove se normalizacija. Teorija normalizacije zasnovana je na pojmu normalnih formi. Relacije prvobitno dobivene morale bi u najmanju ruku biti u prvoj normalnoj formi (1NF). Naime, relacija je u 1NF ako je vrijednost svakog atributa jednostruka i nedjeljiva - to svojstvo već je uključeno u definiciju relacije. U svojim radovima (1970-1974. godina) E.F. Codd je najprije definisao drugu i treću normalnu formu (2NF, 3NF), a zatim i poboljšanu varijantu 3NF koja se zove Boyce-Coddova normalna forma (BCNF). R. Fagin je 1977. i 1979. uveo ĉetvrtu i petu normalnu formu (4NF, 5NF). U praksi je lako naići na relacije koje odstupaju od 2NF, 3NF, BCNF, no vrlo rijetko se susreću relacije u BCNF koje nisu u 4NF i 5NF. Zato su “više” normalne forme prvenstveno od teoretskog značaja. Teorija normalizacije je formalizacija nekih intuitivno prihvatljivih principa o “zdravom” oblikovanju sheme. Ukoliko već na početku dobro uočimo sve potrebne entitete, atribute i veze, tada nam nikakva daljnja normalizacija neće biti potrebna. MeĎutim, ako je polazna relaciona shema bila lošse oblikovana, tada će postupak normalizacije ispraviti te greške.
4.2. METODOLOGIJA PROJEKTOVANJA INFORMACIONOG SISTEMA
Razvoj informacionih sistema se intenzivnije istražuje od početka sedamdesetih godina prošlog vijeka. Od tada je razvijen veći broj tehnika i metoda razvoja informacionih sisema koje je pratila i odgovarajuća strulna i naučna literatura. Cilj svake metodologije i metode razvoja informacionog sistema je izgraditi i uvesti uspješan sistem u smislu izvršenja ciljeva sistema i produktivnosti, odnosno sistem treba zadovoljiti utvrĎene zahtjeve, biti razvijan na vrijeme i unutar planiranih finansijskih sredstava. Kroz korišćenje jasno definisane metodologije postiže se standardizacija faza i procedura razvoja i projektovanja programskih sistema i dobro dokumentovanje pojedinih faza. Usvajanje odgovarajuće metodologije i rad po njoj, osim što pojednostavljuje rad projektnog tima, omogućava, odnosno olakšava komunikaciju i razumjevanje sa korisnicima sistema. Treba istaći, da odabrani softverski alat za razvoj i projektovanje IS-a u velikoj mjeri definiše i metodologiju, najviše u dijelu koji se odnosi na dizajn i izradu sistema. Metodologija o projektovanju i izgradnji informacionih sistema je naučna disciplina o razvoju informacionih sistema, metodama i njihovoj primjeni.
Pod metodikom za projektovanje, izgradnju i održavanje podrazumijeva se sveukupnost principa, pravila, metoda i tehnika koje se koriste u postizanju cilja projektovanja, izgradnje i održavanja informacionog sistema. Metodika je skup svih načina kako se adekvatno može obavljati neki posao. Metoda je definisani postupak djelovanja za postizanje odreĎenog cilja na nekom praktičnom ili teorijskom području. Metoda je način istraživanja ili praktičnog postupanja duha kako bi se doprlo do spoznaje ili znanja ili da se dokaže istina Model je pojednostavljena reprezentacija o relevantnim svojstvima sistema. Modeliranje je proces razvoja modela. Model nastaje procesom apstrakcije u kojem se prvo biraju relevantni elementi koje reprezentacija treba sadržavati, a zatim se svakom elementu pridružuju relevantne osobine, koje se žele prikazati u okviru modela. Proces modeliranja je u tom smislu najefikasniji oblik i tehnika za razumijevanje i jednoznačnu komunikaciju izmeĎu učesnika odnosno izmeĎu projektanata i korisnika. Postupak modeliranja apstrahuje detalje i bitno smanjuje kompleksnost realnog sistema koji je predmet posmatranja i analize. Grafičke prezentacije, koje se uglavnom svode na linije i pravougaonike, pružaju mogućnost da većina korisnika razmišlja o procesu modeliranja kao o slikovitoj prezentaciji, a dobro je poznata efektnost vizuelizacije kod čovjeka. Paralelno sa grafičkom interpretacijom daju se i precizne definicije predmeta koji se nalaze u modelu, kao i odgovarajući prateći tekst sa kritičkim osvrtom prema modelu koji ima ulogu sredstva komunikacije. Modeliranje kao opšte prihvaćen oblik i osnova razvoja informacionog sistema nametnuo je apstrakciju kao postupak kojim se na izuzetno kontrolisan način isključuju detalji odnosno sintetišu se zajedničke karakteristike u opisivanju konkretnog sistema. Tako se na višem nivou apstrakcije dolazi do jasnije opisanog i predstavljenog realnog sistema. Proces modeliranja realnog sistema predstavlja postupak koji funkcionalno prvenstveno zavisi od sposobnosti, znanja i iskustva projektanata iz razloga nemogućnosti davanja strogih formalnih pravila modeliranja koja dovode do modela kvalitetnog realnog sistema.
4.2.1. METODE RAZVOJA INFORMACIONOG SISTEMA Proces nastajanja i djelovanja informacionog sistema nazivamo ţivotni ciklus informacionog sistema. Zavisno od metodologije razvoja IS-a u praksi se susreću različiti životni ciklusi sistema koje okvirno možemo podijeliti na dvije klase: linearne evolutivne Linearni pristup, koji se naziva i tradicionalnim pristupom zasniva se na ideji da se razvoj IS-a može izvršiti spovoĎenjem niza faza koje slijede jedna za druugom. Kada se završi jedna faza prelazi se na sljedeću fazu do konačnog cilja. U okviru linearnog pristupa postoje sljedeće faze: Planiranje Analiza i dizajn Implementacija Funkcionisanje i održavanje Vrednovanje i kontrola Nedostaci projektovanja informacionih sistema po linearnom pristupu su: Odložena implementacija Orijentisanost na procese Sporost projektovanja i izgradnje Nezadovoljstvo korisnika Visoka cijena razvoja Vraćanje na prethodne faze Teško održavanje Linearni pristup nije primjeren u složenim i nedovoljno definisanim sistemima. TakoĎe nije primjeren za nedovoljno iskusne projekatnte sistema. Pogodnije rješenje pri navedenim uslovima je metoda pokušaja i promašaja uz nastojanje da promašaja bude što manje. U praksi se ta metoda često naziva metodom prototipa. Evolutivni pristup se zasniva na radnoj pretpostavci da postoji mogućnost uspješnog razvoja IS-a putem upoznavanja i definisanja sistema samim radom na njegovorm razvoju. Prema ovom pristupu razvoj sistema se odvija po pojedinim funkcijama sistema. Rad se počinje na nekoj jednostavnoj i dobro poznatoj funkciji ili nekoj od funkcija za koju se smatra da bi mogla biti kritička u kontekstu razvoja cijelog sistema. Bitna karakteristika je da rad na razvoju pojedinačne funkcije sistema ujedno služi definianju samog problema. Projektant informacionog sistema i korisnik uče putem rada šta bi trebalo i kako bi bilo dobro uraditi. Realizacija informatizacije funkcije obuhvata izradu prijedloga rješenja i njegovo vrednovanje u praktičnoj (ili probnoj) primjeni. Prijedlog rješenja naziva se prototip. Izbor životnog ciklusa predstavlja, prije svega, izbor metode rada na razvoju IS-a. Prema linearnom pristupu pretpostavlja se izvršavanje pojedinih faza u projektovanju bez vraćanja nazad. Da bi se uspješno realizovao takav pristup potrebno je da korisnik tačno zna šta želi, te da to zna precizno izraziti i da projektant tačno zna na koji se način želje korisnika mogu realizovati. Projektanti informacionih sistema su suočeni sa stalnom pojavom novih tehnologija koje zahtjevaju eksperimentisanje i sticanje novih iskustava u radu. Česta pojava novih proizvoda ne daje mnogo prilika za sticanje bogatog iskustva u radu sa pojedinim od tih proizvoda. Iz navednih razloga i za korisnika i za projektanta, evolutivni pristup u razvoju IS-a izgleda prikladniji od linearnog pristupa. Jedan od zahtjeva koji mora da ispuni novi IS jesu zahtjevi korisnika (koji je obično i investitor). Ispunjenost korisnikovih zahtjeva smatra se najbitnijim kriterijumom uspješnosti rada na razvoju novog informacionog sistema.
U odnosu na linearni pristup u evolutivnom pristupu dolazi se brže do opipljivih rezultata rada. Evolutivni pristup jače i neposrednije animira korisnika u procesu definisanja i razvoja IS-a. Prethodno su navedene neke prednosti evolutivnog pristupa u odnosu na linearni pristup u razvoju ISa. MeĎutim, kod velikih informacionih sistema (npr. državna institucija, velika radna organizacija) primjena samo evolutivnog pristupa ne bi dala zadovoljavajuće rezultate. Kao zaključak možemo reći da se linearni i evolutivni pristup u razvoju informacionih sistema ne isključuju, već se meĎusobno kombinuju kako je opisano. Mogućnost primjene pojedinog od tih pristupa zavisi od više faktora: opsežnosti i složenosti sistema, tehnološke i organizacione razvijenosti. U okviru evolutivnog pristupa razvoja informacionih sistema važno mjesto ima primjena metode prototipa. Često se u praksi evolutivni pristup naziva ili izjednačava sa metodom prototipa. Prototipom se naziva prvi primjerak nekog proizvoda. Time se pokazuje mogućnost izrade novog proizvoda, daje osnova za utvrĎivanje operativnih karakteristika i cijena koštanja proizvoda. Po pravilu takav proizvod nije namijenjen upotrebi, već samo predstavlja pokušaj koji prethodi izradi upotrebljivog proizvoda. System development life cycle (SDLC) ili metodologijaživotnog ciklusa je konceptualni model koji se koristi u voĎenju projekta da opiše faze uključene u razvoj informativnog sistema. U okviru SDLC metodologije razvijene su razne metode za voĎenje uključenih procesa kao što je vodopadni (waterfall) model; brzi razvoj aplikacija (RAD); spiralni model; brzo prototipiranje; itd
Vodopadni model Vodopadni model podržava slijedno napredovanje iz faze u fazu, gdje izlazi iz jedne faze predstavljaju inicijalne ulaze u slijedeću fazu. Ovaj model je prikladan za poznato okruženje, gdje postoje razraĎene procedure ručne obrade ili informacioni sistem koji treba unaprijediti.
Slika 14. Vodopadni model
Dobre osobine ovog modela su da obezbjeĎuje: integrisanost informacionog sistema, dobru dokumentovanost, praktično istovremen završetak svih podsistema informacionog sistema, zahvaljujući dobroj dokumentovanosti, pojednostavljeno održavanje aplikacija informacionog sistema i solidne garancije da će se u konačnom vremenu doći do zadovoljavajućeg riješenja programskog proizvoda, čime se smanjuje rizik od neuspjeha pri njegovom razvoju. I pored svojih dobrih osobina, sekvencijalni pristup, na žalost, nije uvijek davao prave efekte, kada je u pitanju ostvarenje prethodno definisanog cilja. Postoji više nedostataka, koji su ovakvu pojavu uzrokovali. Neki od njih su sljedeci: Krajnji korisnik u ovom modelu primjene metodologije životnog ciklusa nije dovoljno uključen u proces razvoja programskog proizvoda. Vremenski interval koji protekne od početka projekta, do pojave prvih, operativno primjenjivih rezultata kod korisnika, je dosta dug. Česta je potreba da se precizni, metodološki kompleksni projektantski koraci izvode na osnovu nedovoljno precizno identifikovanih informacionih zahtejva. Postoji potreba da se u razvoj informacionog sistema ulože značajna finansijska sredstva odjednom, umjesto da to bude postupno. Prvi nedostatak je povezan s činjenicom da, nakon faze strategije i samog početka faze analize, korisnik se ponovo intenzivnije uključuje u razvoj informacionog sistema tek u fazi uvoĎenja proizvoda u upotrebu. Tokom najvećeg dijela faze analize i tokom faza projektovanja i programiranja, korisnici ostaju skoro potpuno po strani, a te faze najduže traju i u njima se donose vrlo bitne projektantske odluke. Moguće negativne posljedice se ogledaju u sljedećem: Privikavanje korisnika na rad s aplikacijama, pogotovo ako je on neiskusan u primjeni informacionih tehnologija, postaje dosta teško i s neizvjesnim ishodom.
Korisnici mogu imati utisak da im neko sa strane nameće postupke za izvršavanje radnih zadataka, što raĎa odbojnost i destruktivan stav prema informacionom sistemu.
Kombinacija prva tri nedostatka sekvencijalnog pristupa dovodi do posljedice da se skrivene mane programskog proizvoda i prethodno neidentifikovani korisnički zahtjevi, često, otkrivaju tek u fazi
uvoĎenja aplikacija u upotrebu, što je jako kasno, jer se korekcija grešaka i održavanje komplikuju, a produžava se vrijeme, potrebno za dobivanje konačnog rješenja aplikacija. U cilju izbjegavanja pojave navedenih negativnih efekata, javili su se prototipski pristup, kao i drugačiji modeli primjene metodologije životnog ciklusa. U neke od njih spadaju: evolutivni, zvjezdasti i inkrementalni model.
Spiralni model Spiralni model spada u klasu evolutivnih modela te je stoga iterativan. Počinje sa inicijalnim prolazom kroz faze kao u vodopadnom modelu, dakle svaka iteracija sadrži prikupljanja novih zahtjeva korisnika, razvoj prototipa, testiranje prototipa, isporuka korisniku, referenciranje na primjedbe i sugestije korisnika, ako ih ima, kako bi se moglo napraviti podešavanje prototipa. Nakon evaluacije, ciklus počinje iznova, dodaju se nove funkcionalnosti i izraĎuje novi prototip. Proces se nastavlja sa prototipom koji postaje sve veći i obuhvatniji sa novom iteracijom.
Slika 15. Spiralni model
Sam spiralni model je podijeljen u radne cikluse koji se nazivaju regioni zadataka. Svaki prolaz kroz regione zadataka rezultira proširenjem projektnog plana i dodavanjem novih mogućnosti sistema, pri čemu se mora uzeti u obzir povratna informacija od korisnika na osnovu koje se vrši rasporeĎivanje zadataka i projekcija mogućih troškova. Na kraju voĎa projekta vrši planiranje broja iteracija koje je potrebno proći kako bi se informacioni sistem razvio i implementirao u potpunosti. Ovaj model podržava praćenje potreba i zahtjeva korisnika koji se mijenjaju u vremenu efikasnije i fleksibilnije nego što je tomodel vodopada, te omogućuje korisniku stvaranje slike o izgledu sistema.
Brzi razvoj aplikacija- RAD Pod ovim naslovom (RAD - Rapid Application Development) koji je prvi upotrebio J. Martin krije se ustvari set metoda i alata četvrte generacije kojima krajnji korisnik nastoji obezbijediti brz razvoj aplikacija, kao dio razvoja čitavog IS-a. Upravo iz toga razloga neki autori ga nazivaju i metodom krajnjeg korisnika.
Brzi razvoj alikacija (RAD) je izrada programske opreme u relativno kratkom vremenu koja traži aktivno i djelotvorno učešće korisnika. Metod se koristi kod rada malih timova na sistemima manjeg obima. Cijena brzine može biti improvizacija i "prljavi" razvoj. Kako do toga ne bi došlo kod ove metode se naročito preporučuje upotreba CASE tehnologije. Uz pomoć ovih alata krajnji korisnik može mnogo brže razviti aplikaciju koju želi nego sa bilo kojom metodom ili metodologijom životnog ciklusa.
4.2.2. IZBOR METODE RAZVOJA INFORMACIONOG SISTEMA Izbor metode koja treba biti primijenjena na čitav projekat ili pojedine cjeline projekta se vrši u fazi Definicije i planiranja sistema. Izbor metode koja treba biti primjenjena na čitav projekat ili pojedine cjeline projekta može se temeljiti na značajnom broju faktora. Naredna tabela preporučuje neke od kriterijuma koji mogu biti od koristi prilikom izbora metode razvoja aplikativnih rješenja.
Klasiĉni model
Kriterijum
RAD model
Spiralni model
Trajanje projekta
3-36 mjeseci
0-4 mjeseca
0-9 mjeseci po iteraciji
Značaj projekta?
Od izuzetnog značaja za dugoročne poslovne ciljeve, misiju ili viziju korisnika
Svi
Svi
Definisanost i postojanost zahtjeva koji novi sistem treba podržati
Zahtjevi moraju biti definisani i stabilni nakon faze analize
Svi ključni zahtjevi koji se odnose na osnovne postavke dizajna moraju biti definisani i stabilni najdalje do polovine vremenskog trajanja projekta
Zahtjevi se mogu definisati tokom projekta u bilo kojoj od iteracija, ali moraju biti unutar prethodno utvrĎenog obima projekta
Da li su rokovi strogo definisani?
Poželjno je da rokovi nisu strogo definisani
Da
Da
Obim i kompleksnost projekta
Svi
Svi
Svi
Stepen poznavanja i iskustvo članova razvojnog tima sa alatima, tehnologijama, razvojnim okruženjem i odabranom metodom razvoja
Srednji ili visok stepen
Visok
Srednji ili visok stepen
Veličina razvojnog tima
Svi
2-? developer-a
2-6 developer-a po razvojnom timu
Udio poslova na realizaciji internih i eksternih interfejsa u odnosu na ukupne poslove na projektu
Svi
< 30%
< 30%
Da li je moguće prioritetizovati funkcionalnosti
Da
Da
Raspoloživost /očekivani angažman korisnika za potrebe projekta
IzmeĎu 50-100% zavisno od faze projekta
IzmeĎu 25-100% zavisno od faze projekta
Ključni korisnici ovlašćeni za gotovo sve odluke od značaja za projekat
Ključni korisnici moraju biti ovlašćeni za operativni i taktički nivo odluka od značaja za projekat
Ovlašćenja ključnih korisnika/ nadzornih tijela projekta
Ključni korisnici ne moraju imati posebna ovlašćenja ukoliko je na nivou projekta formirano kontrolno tijelo sa potrebnim ovlašćenjima.
Tabela 8. Kriterijumi za izbor metode razvoja IS
4.2.3. UČESNICI U RAZVOJU INFORMACIONOG SISTEMA Da bi se osiguralo pravovremeno i uspješno izvršavanje svih zadataka neophodno je definisanje učesnika i njihove uloge u procesu razvoja i održavanja softverskih rješenja. Učesnici su sljedeći:
Poslovodstvo-menadţment.
OdreĎuje smjernice projekta. Prati i preispituje napredovanja projekta. Osigurava da su poslovanje firme i strategija uvoĎenja informacionih tehnologija usklaĎeni za cijelo vrijeme trajanja projekta. Osigurava uslove za uspjeh projekta.
Korisnici Korisnici su najbolji poznavaoci postojećeg sistema, potreba i zahtjeva kod izgradnje novog sistem. Kod većih projekata postoji potreba za stvaranjem tima korisnika sa voĎom tima, gdje će postojati i osobe zadužene za pojedine podsisteme. VoĊa projekta je: odgovoran za aktivnosti uvoĎenja projekta kod korisnika, odgovoran za planiranje i rasporeĎivanje zadataka projekta, nadzor napretka prema planu i preporučivanje/poduzimanje korektivnih akcija u slučaju potrebe, odgovoran za dodjeljivanje poslova timovima tako da svaki član tima ima jasne odgovornosti, radna uputstva i definisano vrijeme za izvršenje svojih zadataka, odgovoran za preglede i izvještaje o napretku projekta, ovlašten je za prihvatanje planova i promjena u planovima, vodi brigu o zahtjevima za promjenama, zakazuje projektne sastanke, izraĎuje periodične izvještaje o napretku projekta za poslovodstvo, glavna je kontakt osoba s korisnikom po ključnim pitanjima vezanim za projekat i ovlašten je za potpisivanje izvještaja koja se odnose na izvršenje pojedinih koraka projekta. Razvojni tim čine voĎe timova, projektanti, analitičari, administratori i programeri. Projektantski tim analizira postojeći poslovni sistem u skladu sa postavljenim zahtjevima, oblikuju i projektuju novi informacioni sistem, uvodi u rad i održava IS. Tim za testiranje koji može biti jedan čovjek ili cijeli tim za testiranje na čelu sa voĎom tima kada su u pitanju veći projekti.Tim za testiranje definiše : Strategiju testiranja Faze testiranja Postupke za testiranje Postupke za prihvat rezultata testiranja.
4.2.4. FAZE RAZVOJA INFORMACIONOG SISTEMA
Prema SDLC metodologiji cjelokupni razvojni napor sastoji se od 6 faza. Kraj svake faze predstavlja završetak najvećeg dijela izlaznih rezultata koje korisnik može provjeriti i potvrditi ili ne njihovu ispravnost. Svaka od faza predstavlja i stratešku tačku projekta, dajući mogućnost provjere i potvrde poslovnih potreba korisnika.
Definicija i planiranje sistema Prva faza je faza u kojoj se snima stanje i izraĎuje inicijalna strategija, odreĎuju poslovni ciljevi, identifikuju kritični faktori uspjeha. U ovoj fazi se radi studija izvodljivosti kojom se analizira područje problema i odreĎuju granice projekta. IzraĎuje se plan projekta gdje se daje plan rada, resursi, upravljanje i nadzor projekta. U "definiciji i planu sistema" se definišu ciljevi, opisuje postojeće stanje, definiše funkcionalni obim, daje organizacioni obim. "Definicija i plan sistema" sadrži plan u kojem se globalno planiraju ključne tačke projekta sa rokovima izvršenja. Tu se definiše sastav i kompleksnost timova i uspostavlja radna okolina za tim. Ovdje se treba odlučiti o veličini i timovima potrebnim za projekat (tim za testiranje, tim za implementaciju…) Da bi testiranje bilo dobro uraĎeno mora se formirati testni tim, koji može imati samo jednog člana ili više timova sa voĎama timova kod složenijih sistema. Imenuje se voĎa testnog tima koji je zadužen da koordinira svim fazama testiranja i da izvještava voĎu projekta o trenutnom stanju testiranja. Testni tim, u zavisnosti od složenosti projekta, može još da uključuje osobu odgovornu za tehnički nivo testiranja i instaliranje rješenja. Posebnu ulogu u timu ima sadržajni voĎa testa, koji definiše kakvi će se podaci testirati i u kakvom okruženju. Na kraju testiranja u testni tim se uključuju krajnji korisnici, koji vrše testiranje. Planira se eventualna edukacija timova . U ovoj fazi se definiše, ukoliko je potrebna, i platforma za obuku korisnika i testiranje. Ovdje se vrši izbor alata koji će se primjenjivati, te metode koja treba biti primjenjena na čitav projekat ili pojedine cjeline projekta. U ovoj fazi se mora odlučiti za način uvoĎenja: 1. Ako se radi o sistemu koji kreće od samog početka, bez postojanja ikakvog sistema ranije i prebacivanja podataka. 2. Ako je postojao sistem koji treba raditi paralelno neko vrijeme (najteži za izvoĎenje). 3. Ako postoji sistem nakon čijeg gašenja počinje produkcija novog sistema. Ovdje treba voditi računa o "meĎuvremenu" kada ni jedan sistem ne radi, ili kada je to meĎuvrijeme = 0 (prelazak na novi sistem u "realnom vremenu"). Izlaz iz ove faze je "Definicija i plan sistema" koji potpisuje nalogodavac i voĎa projekta.
Analiza poslovnog sistema U ovoj fazi se vrši detaljna analiza sofverskih potreba. U toku analize se sagledavaju poslovi koji se obavljaju u poslovnom sistemu, intervjuišu korisnici i kompletira dokumentacija poslovnog sistema. Analiziranjem procesa, funkcija u procesima i podataka definišu se informacioni zahtjevi. Iz zahtjeva se dobiva uvid u onošto će novi sistem raditi. Za precizno definisanje informacionih zahtjeva odgovorni su korisnici jer oni najbolje znaju kako poslovni sistem funkcioniše. Na temelju njih analitičari izraĎuju specifikacije informacionih zahtjeva. Testiranje je proces koji traje kroz više faza razvoja projekta. Za fazu analize vezan je testni plan koji će biti uključen u specifikaciju zahtjeva kao izlazni dokument faze II, a koji predstavlja putokaz za sve faze testiranja. Testni plan je dokument koji odgovara na ključna pitanja vezana za testiranje. Testni plan može postojati na mnogo različitih nivoa. Može postojati samo jedan testni plan za cijeli projekat ili se kompletan testni plan dijeli na testne planove po modulima testiranja, testni plan za test prihvatanja, testni plan za testiranje integracije ...Svaki testni plan bez obzira koliko ih projekat ima mora sadržavati set aktivnosti koje definišu strategijske i planske komponente. Izlaz iz ove faze su zapisnici sa sastanaka, intervjua, specifikacije informacionih zahtjeva dati za svaki podsistem. Ova dokumentacija treba biti usvojena i potpisana od strane korisnika, odnosno voĎa tima korisnika za pojedine podsisteme, analitičara-projektanta zaduženog za odreĎeni podsistem i voĎe projekta. Dizajniranje – oblikovanje informacionog sistema U fazi oblikovanja informacionog sistema donosi se odluka kako će sistem raditi. Ovdje se daje detaljni dizajn razrade rješenja i izraĎuje model IS. U ovoj fazi se dizajnira arhitektura sistema, interfejs, pohranjivanje podataka i programa i daje tehnička specifikacija sistema. U fazi III se prvi put sprovodi testiranje tako da je potrebno definisati scenarij testiranja i potrebno je imati dokumenat "problem izvještaj". Pojedinačni scenariji testiranja i "problem raporti" kasnije ulaze u sumarne preglede scenarija testiranja i sumarne preglede "problem raporta". Testiranje se sprovodi po Testnom planu koji je napravljen u fazi analize, a prema scenariju testiranja. Scenarij testiranja piše analitičar ili član testnog tima zadužen za segment projekta koji se testira. Scenarij testiranja je skup ulaznih vrijednosti i akcija koje opisuju situaciju na koju sistem treba da reaguje na predvidiv način. Svaki scenario se dokumentuje, što omogućava da se ponavlja od strane bilo kojeg učesnika u procesu testiranja. Scenarij testiranja može kasnije poslužiti kod pisanja korisničke dokumentacije jer sadrži detaljan opis procesa i funkcija koje se odvijaju. Dokument, koji se kreira pri otkrivanju greške je "Problem Raport". "Problem Raport" prikazuje nesuglasice izmeĎu očekivanih i dobivenih rezultata, a potpisuje ga onaj ko je izvršio testiranje. U ovoj fazi se testiranje radi na razvojnoj platformi i najčešće ova prva testiranja rade sami programetri. Izlaz ove faze je tehnička specifikacija sistema sa dijagramima procesa, funkcija i podataka, kao i dokumenti vezani za testiranje: scenarij testiranja i "Problem Raport". Tehničku specifikaciju sistema potpisuje voĎa projekta, voĎa funkcijskog modula i voĎa tima za testiranje.
Izrada i implementacija sistema
U ovoj fazi se radi ugradnja oblikovanih rješenja, izrada baze podataka, kodiranje procesa (funkcija), tako da se dobije funkcionalni sistem koji se sastoji od objekata baze podataka i programskih modula. U ovoj fazi se radi testiranje odnosno provjera komponenti, a zatim integracija i provjera cjeline sistema da bi se dokazalo da sistem radi (da je ispravno napravljen), te da radi ono što je zahtjevano (da je napravljen pravi sistem, koji ispunjava zahtjeve). Pri tome treba napraviti detaljno testiranje novih procedura uz korišćenje realnih podataka i uz simuliranje normalnog rada novog informacionog sistema. Ukoliko se stari sistem zamjenjuje novim treba testirati i verifikovati podatke koji se prenose. Testiranje rade članovi testnog tima koji je odreĎen u I fazi razvoja, te krajnji korisnici koji moraju ovjeriti "Test prihvatanja" zajedno sa testnim timom. VoĎa testnog tima može imati pregled "Scenarija testiranja" kroz Sumarni pregled scenarija, a isto tako imati zbirni uvid u sve pronaĎene greške kroz "Sumarni problem report". Izlaz su funkcionalni sistem po kojim se podrazumjeva fizička baza podataka i programski moduli, te dokumenti: izvedbeni opis sistemakoji potpisuje voĎa projekta i voĎa funkcionalnog modula, korisničko uputstvo koji potpisuje voĎa funkcionalnog modula i voĎa tima korisnika, Scenarij testiranja, Problem Report, Sumarni scenarij testiranja, Sumarni problem report i Korisniĉki test prihvatanja koji potpisuje voĎa testnog tima i voĎa tima korisnika. UvoĎenje u rad –priprema i produkcija UvoĎenje novog informacionog sistema je faza u kojoj treba obaviti sljedeće zadatke: obrazovanje korisnika za rad sa novim informacionim sistemom, izrada projektne dokumentacije, prelaz sa starog na novi informacioni sistem (ako je postojao stari sistem) i stavljanje novog informacionog sistema u svakodnevnu upotrebu. U toku obrazovanja i pripreme za rad sa novim informacionim sistemom korisnici se moraju kvalitetno upoznati sa svrhom novog informacionog sistema, detaljno naučiti nove procedure obavljanja poslova i načine korišćenja računarske opreme na svojim radnim mjestima. Ovdje se treba voditi računa o uspostavljanju Help Deska koji bi bio aktivan nakon puštanja u produkciju. Autorizacijska shema sa svim detaljnim podacima (imena, prezimena, ovlašćenja) mora biti na raspolaganju prije puštanja sistema u rad. Način uvoĎenja je definisan u I fazi. Ova faza obuhvata, ukoliko se radi o prelazu sa starog na novi sistem, i unos novih podataka koji u starom sistemu nisu postojali ili konverziju formata postojećih podataka. Izlaz su Plan uvoĊenja u rad koji potpisuje voĎa projekta i voĎa tima korisnika, Zapisnik o implementaciji koji potpisuje voĎa projekta i nalogodavac, te Projektna dokumentacija koju izraĎuju projektanti za pojedine podsisteme, a koju objedinjava i potpisuje voĎa projekta i vodi računa o njenoj raspoloživosti. Projektnu dokumentaciju kod velikih sistema pišu voĎe timova podsistema, a voĎa projekta je objedinjava i verifikuje. U ovoj fazi se predaje prva verzija projektne dokumentacije, a zatim se svaki put prilikom bilo kakve promjene na sistemu i projektna dokumentacija mijenja tako da uvijek predstavlja najnovije stanje sistema. Održavanje informacionog sistema Održavanje je faza sastavljena od izvoĎenje ranijih aktivnosti iz svih potrebnih faza radi: uvoĎenje novih poslovnih procesa,
izmjene postojećih poslovnih procesa i otklanjanja grešaka.
Informacioni sistem se razvija i mijenja tokom vremena. Sva saznanja o promjeni moraju se ugraditi u programsku podršku ali i u dokumentaciju koja je nastala u ranijim fazama. U protivnom će dokumentacija opisivati prošlo stanje sistema i postati neupotrebljiva. Problem dokumentacije značajno olakšava korišćenje CASE alata. Izlaz: Scenarij testiranja, Problem Report i Korisnički test prihvatanja, Korisničko uputstvo vezano za izvršene izmjene, Projektna dokumentacija sa najnovijom slikom sistema, Izvještaj o izvršenim izmjenama.
4.2.5. USPJEŠNOST PRIMJENE RAZVOJA INFORMACIONOG SISTEMA Svaka metodologija može biti nefunkcionalna ako se dešava u neodgovarajućem kontekstu. Da bi se to izbjeglo treba voditi računa o pravilnom načinu uvoĎenje metodologije: Menadžerska obaveza (pristajanje) od samog vrha, voĎenje menadžmenta koji razumije koristi koje se mogu očekivati od metodologije, ali i ulaganje u vrijeme i novac koje je potrebno preduzeti da bi se ona sprovela. U početku projekta treba više vremena posvetiti ranim fazama projektovanja. Učenje i vježbanje je bitno na početku projekta, ali treba postojati stalna obaveza samoučenja. Korišćenje raznih drugih metoda za područja koja ne pokriva odabrana metodologija. Procjena produktivnosti i usporedba s drugim projektima (i prošlim i budućim). Informacija o tome treba biti sačuvana. Pretjerivanje s kvalitetom opasno je kao i prevelik brodski teret te može potopiti projekat. Odlučivanje i obavezivanje na nov način. Metodologija mijenja kulturu organizacije i ljude uključene na projektu. Razni su efekti koji mogu obuhvatati strah od promjena, nesigurnost, čak i neprijateljstvo. Ljudi moraju biti ohrabreni i usmjereni na to da probaju metode da lično iskuse beneficije. Poželjna je podrška dobrog CASE alata ili više njih. Postoji nekoliko aspekta projekta koji će imati koristi od podrške CASE alata. Crtanje modela i generisanje koda predstavljaju najvažnije beneficije. Upravljanje projektom, analiza rizika i kontrola konfiguracije je omogućena nekim CASE alatima i predstavlja napredne koristi. Bolje je ne koristiti CASE alat ako on nije stabilan proizvod. Korišćenjem CASE alata je poboljšan proces modeliranja, načinjena bolja povezanost meĎu metodama, poboljšana priprema za intervjuisanje, proširene metode za modeliranje podataka, pojednostavljen proces prevoĎenja u relacionu shemu baze podataka. Skraćeno je vrijeme rada projektanta, ali je povećan rad korisnika i članova projektnog tima koji poznaju sistem. Planiranje projekta treba biti jasno utemeljeno na fazama metodologije životnog ciklusa. Saradnja s korisnicima je važna i treba im objasniti faze metodologije. Analitičar treba uzeti vrijeme da korisnike stvarno uključi i osigura njihovo razumijevanje o tome što se dogaĎa. Metodologije i CASE alati napreduju. Nikako nije sigurno izabrati metodologiju i alat i onda se opustiti. Mogućnost pomoći projektantima u korišćenju metodologije. Potrebno je od iskusnih projektanata učiti te razviti dovoljno modela na "živim" projektima. Često se dobri CASE alati i programski jezici odbace, jer se pokušala izgradnja na nedovršenim i nepouzdanim modelima. Tada se CASE alat koristi na kraju projekta kao alat za dokumentaciju. Poduhvat uvoĎenja metodologije je dugoročan i složen projekat po novom pristupu. Metodologija se uvodi timskim radom, školovanjem, savjetovanjem i primjenom na odabranim projektima. Metodologija je intelektualni alat i ne kupuje se kao uobičajen materijalni proizvod. On se uči kao metoda i postaje sastavni dio ponašanja pri razvoju informacionih sistema. Školovanje informatičara za metodologiju je neophodno, odnosno uvoĎenje započinje školovanjem i mijenjanjem znanja i postupaka djelovanja. Metodologija je korisna onim sredinama koje žele i trebaju unaprijediti kreativnost članova razvojnog timaKoršćenjem CASE (Computer Aided Systems Engineering) alata je najefikasniji i najekonomičniji način razvijanja i integrisanja softverskog aspekta sistema. CASE predstavlja profesionalni pristup razvoju softvera sistema. Preporučuje se upotreba CASE alata iz sljedećih razloga: 1. CASE daje strukturiranu okolinu koja pokriva cijeli životni ciklus aplikacije. Tu je uključeno: analiza poslovnih potreba analiza IT potreba feasibility studija
dizajn sistema konstrukcija i implementacija integracija isporuka radećeg sistema daljnja evolucija periodični pregledi
2. CASE alati i tehnike ubrzavaju cijeli ciklus proizvodnje i održavanja kvalitetnih softverskih sistema. CASE alati dramatično smanjuju sveukupne troškove i znatno povećavaju predvidljivost kako će softver raditi kad bude gotov i isporučen. U današnjem, brzo promjenjivom poslovnom okruženju, od bitne je važnosti da se za razvoj novih sistema koriste standardne metode i CASE alati. Postoje i CASE tehnike za ažuriranje postojećih aplikacija, kako bi omogućile ispunjenje novonastalih zahtijeva. Moderne tehnike posvećuju znatno veću pažnju početnim fazama životnog ciklusa aplikacije: feasibility studiji, analizi potreba i definiciji problema. To su informacije na kojima je zasnovan cijeli sistem. Dalje je navedeno koje su prednosti korišćenja CASE alata prema fazama SDLC: Upravljanje projektima
Strukturirano upravljanje projektima daje veću kontrolu nad rokovima i troškovima i omogućava krajnjim korisnicima da utiču na one dijelove projekta koji ih se tiču.Povratna veza od rukovodstva i korisnika je važna i to se u potpunosti uzima u obzir. Plan projekta predviĎa konsultacije u toku cijelog životnog ciklusa aplikacije. Analiza i dizajn Analitičarski alati ubrzavaju proizvodnju dijagrama potrebnih za dokumentovanje poslovnih procesa i informacija. Na osnovu toga, razvijaju se specifikacije sistema, odreĎuju se logički koraci i rafiniraju se definicije baze podataka. Izgradnja Implementacija jednom projektovanog sistema je obično dugotrajan i radno intenzivan posao. Koristeći odgovarajuće alate, moguće je automatski razviti sistemske specifikacije. Nakon toga se mogu koristiti automatski generatori koda, koji se pobrinu za sve rutinske i one poslove koji se ponavljaju. Generatori napravljeni za korišćenje nekog odreĎenog kompjuterskog jezika, daju specijalizovane mogućnosti za ureĎivanje i testiranje programa u tim jezicima, a mogu i automatski generisati kod na osnovu opisa visokog nivoa. Kad rade u CASE okolini, softverski stručnjaci se mogu koncentrisati na posao koji stvarno zahtjeva njihova specijalistička znanja. Pošto se koriste zajedničke metode, mogu se lakše premještati iz jednog dijela projekta na drugi, kao i s jednog projekta na drugi. UvoĊenje u rad i integracija UvoĎenje u rad je ključna faza u životnom ciklusu softvera.CASE podržava integraciju novog softvera s postojećim sistemima, i kompjuterizovanim i ručnim. Razvoj i integracija sistema postaju sve složeniji, pa su sve više potrebne kompjuterizovane kontrolne tehnike. Pre-projektovanje i dizajn unazad CASE alati se mogu koristiti i da poboljšaju performanse postojećeg softvera, kao i za unos tog softvera u CASE okolinu. Pre-projektovanje povećava efikasnost softvera na taj način da se logički prestrukturira postojeći kod i uklone suvišni dijelovi. Nakon toga se dobije dijagram za dizajn sistema, kao i opširna dokumentacija, koja olakšava daljnje održavanje. Dizajn unazad je proces u toku kojega se identifikuju komponente i svrha neke postojeće aplikacije. Pri tome se koriste CASE alati, ali unazad: krene se od programa i fizičke baze i automatski se sve dokumentuje. Ovaj proces je iterativan i interaktivan. Tamo gdje proces dizajna unazad ukaže na neku
strukturu, lako je dodati detalje koji pokazuju kako se ta struktura odražava na poslovne potrebe. Čim se više aplikacija razvije u okviru CASE okoline, cijeli informacioni sistem postaje sve efikasniji, lakše se kontroliše i jeftinije se održava.
4.3. KONVENCIONALNA METODOLOGIJA RAZVOJA INFORMACIONOG SISTEMA
U teoriji razvoja informacionih sistema postoji više klasifikacija razvoja informacionih sistema. Konvencionalna metodologija predstavlja faznu podjelu u razvoju IS: 1. planiranje, 2. analiza i dizajn, 3. implementacija, 4. funkcionisanje i održavanje i 5. vrednovanje i kontrola. Informacioni sistemi koji u svom razvoju nisu imali sve navedene faze običnosu neadekvatni, nerazumljivi, nefunkcionalni i teško primjenjivi. Svakaоd faza u razvoju informacionog sistema sadrži niz aktivnosti kao što je to ilustrovano na sljedećoj tabeli. Za realizaciju svake aktivnosti u tabeli potrebno je odreĎeno vrijeme uz angažovanje odgovarajućihkadrova. Kadrovi mogu biti iz same organizacije čiji se informacioni sistem razvija ili seangažuju kadrovi specijalizovanih organizacija zа projektovanje informacionih sistema, koji projektuju sistem i osposobljavju kadrove za njegovu uspješnu primjenu.
FAZA RAZVOJA
AKTIVNOSTI
PLANIRANJE
ldentifikacija i definisanje PROBLEMA Analiza postojećeg IS Definisanje ciljeva i zadataka IS Identifikacija strukture IS Projektovanje logičke strukture baze pod. Definisanje koncepcije tehničke podrške Definisanje modela org.-kadrovske podrške Specifikacija potrebnih ulaganja Analiza izvodljivosti projekta Utvrdjivanje prioriteta i izbor projekata Planiranje realizacije projekta Prihvatanje ili odbijanje plana razvoja
ANALIZA I DIZAJN
Najava izrade projekta Formiranje projektantskih timova Definisanje informacionih potreba Definisanje prerformansi sistema Logičko projektovanje Fizičko projektovanje Priprema prijedloga implementacije projekta Formiranje sistemske dokumentacije
IMPLEMENTACIJA
Najava implementacije projekta Organizacija personala informacionog servisa lzbor i instalacija računarske орreme lzrada/nabavka softvera Formiranje baze podataka Obuka korisnika Zamjena sistema
FUNKCIONISANJE I ORDŢAVANJE
Korišćenje Održavanje
VREDNOVANJE I KONTROLA
Осјеnа kvaliteta poslije uvodjenja
Tabela 9. Faze razvoja IS-a
4.3.1. PLANIRANJE RAZVOJA INFORMACIONOG SISTEMA Prva faza u razvoju IS-a je planiranje kao dio strateškog planiranja i organizacije. Strateško planiranje jesveobuhvatno analiziranje posmatranog sistema primjenom empirijskih i deduktivnih metoda prije svega sa ciljem izrade plana razvoja IS. Strateškim planiranjem utvrdjujuse podsistemi, njihovi međusobni odnosi, prioriteti razvoja, potrebni resursi za razvoj. Vrlo važan faktor za uspjeh u razvoju IS-a je podrška cjelokupnog menadžmenta, а posebno onog na nајvišеm nivou. Komunikacija između menadžmenta i tima za razvoj se ostvaruje posredstvom plana. Menadžment za strateško upravljanje ocjenjuje prijedlog planarazvoja lS-a saaspekta ciljeva, prioriteta, ulaganja, koristi i dinamike realizacije i nа osnovu toga prihvata ili odbacuje predloženi plan.Planovi sezа velike organizacije sa složenim lS-om uobičajeno definišu nа trinivoa: strateški, taktički ioperativni. Strateški plan IS-a neposredno jepovezan idirektno izvire iz strateškog plana organizacijе. Postoji više metoda za planiranje razvoja informacionog sistema оd kojih se u praksi nајčеšćе primjenjuje IBM-ova BSP metoda. Taktički planovi lS sudetaljnijikonkretniji, oslanjaju se nа strateški plan,razvijaju seza srednji menadžerski nivo IS-a koji čine rukovodioci radnih jedinica zа razvoj iprogramiranje, održavanje, komunikacije i administraciju baze podataka. Identifikacija i definisanje рrоblema treba daukaže na potrebu inovacije IS-a, odnosno potrebe za izradu projekta IS-a. Potrebu zа razvojem IS-a mogu inicirati pojedinci i grupe iz okruženja (partneri poslovanja, vladine institucije, finaпsijske organizacije itd), menadžerii pojedinci organizacije. Zahtjevi zа projektom, razvoja novog iliinovacije postojećeg IS-apotiču iz sljedećih razloga: problemi sa postojećim lS, želja za iskorišćenjem novih šansi i povoljnosti, rastuća konkurencija, potreba i zahtjevi da se podaci i informacije efektivnije i efikasnije koriste, spajanje, razdvajanje i reorganizacija organizacije, rast organizacije i promjene na tržištu i okruženju. Analiza postojećeg informacionog sistema ima zа cilj tačan opis postojećeg stanja iutvrĎivanje razlika izmeĎu postojećeg i željenog stanja IS-a i obično podrazumijeva: 1. Snimanje i opisivanje; raspoloživog hardvera i ostaleinformatičke opreme, sistemskog softvera, aplikativnog softvera, lnformatičkih kadrova. 2. Procjenjivanja; troškova funkcionisanja, iskorišćenosti hardvera i druge opreme, korišćenja i vrijednostisoftvera, angažovanosti iinformatičkih kadrova. 3. Ocjenu efektivnosti i efikasnosti postojećeg IS-a obzirom na sljedeće elemente: relevantnost informacija zа uspješno obavljanje poslova i radnih zadataka, adekvatnost distribucije odgovarajućih informacija, pravovremenost dobivanja informacija, adekvatnost forme informacija, primjerenost količine informacija potrebama korisnika i dostupnost ad hoc potrebnih informacija. Poslije snimanja postojećeg stanja u IS-u vrši se рrосјеnаu kojoj je mjeri to stanje:
podržava strateško, taktičko i operativno upravljanje, unapreĎuje kritične faktore uspjeha organizacije i efektivnoi efikasno služi uspješnom funkcionisanju organizacije.
Definisanje ciljeva izadataka IS-a treba dapokaže šta se promjenama u postojećem IS-u želi postići. ldentifikovanje strukture novog ili modifikovanog IS-a obuhvata definisanje informacionih podsistema. Informacione podsistemečine evidencije koje oni stvaraju i koriste, procesi postupaka nad evidencijama (formiranje, ažuriranje, korišćenje). Strukturiranje IS-a zasniva sena sljedećim koracima: identifikacija funkcija i poslovnih procesa, identifikacija i konsolidacija klasa podataka, izrada matrice odnosa poslovnih procesa i klasa podataka i definisanje strukture IS-a. Projektovanje logiĉke strukture baze podataka obuhvata definisanje koncepcije baze podataka i utvrĎivanje njene logičke strukture. Ona sedefiniše na nivou strukture objekata i odnosa izmeĎu objekata. Odgovarajuća metoda za realizaciju ovog koraka je mоdеl objekti veze svojstva - MOV odnosno dijagrami objekti veze - DOV.
Definisanje koncepcije tehniĉke podrške lS-a obuhvata definisanje obima i strukture potrebnih računarskih resursa, komunikacione opreme, periferijske opreme, sistemskog softvera idruge opreme. Najznačajniji aspekti zа definisanje koncepcije tehničke podrške su:
utvrĎeni ciljevi i zadaci IS-a, identifikovane potrebe zа informacijama i projektovana struktura baze podataka, osobine i mogućnosti organizacije, raspoloživost i mogućnost obezbjeĎivanja potrebnih kadrova i strategija razvoja IS-a organizacije.
Prilikom definisanja tehničke podrške IS-a prije svega treba ispuniti sljedeće zahtjeve: Hardverska oprema; visok stepen integracije, modularna izgradnja, visok stepen pouzdanosti, sigurnosti i raspoloživosti, lako održavanje. Sistemska softverska podrška; mоdulаrnа, korisnički orijentisana, podržava jezike visokog nivoa, efikasna u smislu iskorišćavanja opreme, jednostavna zа održavanje. Definisanje modelaorganizaciono kadrovske podrške odnosi se prije svega na organizacioni status i strukturu organizacione jedinice zа izvršavanje poslova informacionog servisa. Osnovni zadaci informacionog centra su da unapreĎuje, podržava, nadzire i usmjerava korišćenje IS-a, unapreĎujući nа taj način efektivnost i efikasnost funkcionisanja korisnika informacionog sistema. Tipičпe usluge informacionog centra su: savjetovanje, obučavanje, pružanje tehničke i operacione podrške u primjeni proizvoda informacione tehnologije, usmjeravanje korisnika, upravljanje podacima i drugo. Као altemativne modеlе organizacije informatičke djelatnosti susrećemo: centralizovani - jedinstvena služba informacionog centra na jednom mjestu, decentralizovani - оsоblје rasporeĎeno po organizacionim cjelinama i kombinovani - zajedničko jezgro informacionog centra i djelimična decentralizacija оsоbljа po organizacionim jedinicama. Specifikacija potrebnih ulaganja u razvoj IS-a obuhvata sljedeće: ulaganja u nabavku računarske i komunikacione opreme, ulaganja u nabavku sistemskog softvera, softvera zа upravljanje bazama podataka, softverskih alata, ulaganja za nabavku softvera zа automatizaciju kancelarijskog poslovanja,
ulaganja u nabavku ili razvoj aplikativnog softvera, ulaganja u obezbjeĎenje i stručno osposobljavanje profesionalnih informatičkih kadrova i korisnika različitog profila. Analiza izvodljivosti projekta treba daodgovori na pitanje da li je projekat cjelishodan, opravdan i izvodljiv prema sljedećim faktorima analize: Tehnički; Ima li na raspolaganju ili semože nabaviti odgovarajući hardver i softver? Ekonomski; Može li predloženi sistem biti opravdan na ekonomskoj osnovi? Zakoпski; Ноćе li predloženi sistem funkcionisati u zakonskimi etičkim granicama? Operacionalni;Da li je dizajn sistema takav da ima podršku ljudi koji ga koriste? Planski;Ноćе libiti moguće realizovati sistem unutar planiranog vremena. Utvrđivanje prioriteta i izbor projekataobuhvata utvrđivanje prioriteta u razvoju podsistema na osnovu značajnosti, korisnosti, hitnosti, potrebnih ulaganja i na osnovu toga izbor projekata zа razvoj. Planiranje realizacije projekata obuhvata traženje adekvatnih odgovora na pitanja: Šta treba uraditi?,Ко ćeto uraditi? , Каdаće to biti urađeno? Odgovarajuće metode zа planiranje realizacije projekta su:gantogrami, СРМ dijagrami i PERT mreže. Prihvatanje ili odbijanje plana razvoja je odluka koja uzrokuje jednu оd sljedećih alternativnih akcija: 1. Ima li dovoljno informacija na osnovu kojih se može donijeti odluka? Ako nemamoraju se prikupiti dodatne informacije. 2. Ako postoje dovoljne relevantne informacije odluka može biti: projekat se nastavlja fazom analize i dizajna ili odustaje seоd projekta i isti se stavlја privremeno ili trajnoоd akta.
4.3.2. ANALIZA I DIZAJN INFORMACIONOG SISTEMA
Каdа je plan razvoja prihvaćen sljedeća faza u razvoju IS-a je analiza i dizajn IS-a.Analiza postojećeg informacionog sistema ili kako seobično naziva sistem analiza izvodi sedetaljno bez obzira da li su procesi automatizovani iline. Detaljna analiza sistema jeobično dugotrajan, zamoran i skup proces. Zbog toga se ovaj proces mora pažljivo planirati, metodološki analizirati i upravljati. Као metodološke osnove zа sistem analizu najčešće se koriste: strukturirana sistem analiza - SSA, intervjui, tabele odlučivanja, sistemski iprogramski dijagrami. Osnovni zadaci dizajna sistema suspecifikacija novog sistema koji ćena efektivan i efikasan način omogućiti postizanje ciljeva i zadataka organizacije, zadovoljiti informacione potrebe menadžmenta idrugog оsоbljа iizvršiti niz automatizovanih procesa obrade podataka. Dizajn sistema seobično dijeli na logički i fizički dizajn. Logički dizajn odnosi se na načine strukturiranja i integrisanje različitih komponenti informacionog sistema u jednu logičnu cjelinu. Detaljna specifikacija komponenata sistema odnosi sena dizajn: izlaza (outputa), ulаzа (inputa), procesa, baze podataka i datoteka, procedura, sistem kontrole i zaštite. Fizičkim projektovanjem sedefinišu karakteristike: hardvera, softvera, baza podataka, prenosa podataka, personala. Za dizajn sistema surelevantni sljedeći koraci: Logičko projektovanje, Fizičko projektovanje, Priprema prijedloga zа implementaciju projekta, Prihvatanje ili odbacivanje projekta, Formiranje sistemske dokumentacije. Utoku faze dizajna sistema moraju sepredložiti rješenja iz sljedećih pitanja: Prava pristupa ikorišćenja sistema, Režima interaktivne obrade, Elemenata dobrog korisničkog interfejsa, Otkrivanje i ispravke grešaka, Sigurnosti. Metode koje se koriste u fazi dizajna sistemasu: strukturirana sistem analiza, modеl podataka objekti -veze, sistemski iprogramski dijagrami i dr. Formalizovana procedura zа sistem analizu može biti: Najava izrade projekta, Formiranje tima za analizu i dizajn sistema, Definisanje informacionih potreba i Definisanje performansi sistema. Najava izrade projektaima zа cilј da se izbjegnu otpori i strahovaпja оd realizacije projekta tako da se zaposleni detaljno informišu о svim aspektima budućih promjena u IS-u. U mаlој organizaciji ovaj cilj se može postići kroz jedan ili više sastanaka. U velikim organizacijama informisanje zaposlenih je kroz više sastanaka za različite interesne grupe. Formiranje tima zа analizu i dizajn sistema je aktivnost formiranja projektantskog tima ili timova sastavljenih оd stručnjaka zа informacione tehnologije iz različitih profila korisnika sa zadatkom rada na projektnoj faziаnаlizе i dizајnа. Definisanje informacionih potreba korisnika je ključni korak sistemаnаlizе. Metoda intervjua je najčešći način istraživanja informacionih potreba korisnika.
Definisanje performansi sistema proizilazi iz informacionih potreba iobjašnjava šta i kako IS treba daizvršava. Logičko projektovanje obuhvata projektovanje podsistema nezavisno оd resursa za realizaciju u sljedećim detaljima: modeliranje procesa, modeliranje podataka. Modeliranje procesadаје model procesa budućeg stanja sistema saopisom željenog kretanja i obrade informacija u IS-u. Ovaj opis jehijerarhijski, оd opšteg ka detaljnom prikazu, opisujući sadržaj istrukturu tokova i skladišta podataka ilogiku odvijanja procesa. Modeliranje podataka treba da stvori konceptualni modelpodataka koji sadrži podatke injihovu interpretaciju i da se što jemoguće više relevantnog znanja iz realnog sistema ugradi u model. Fizičko projektovanje obuhvata projektovanje logičkog projekta nаkonkretnoj opremi, odnosno роmо��u zadatih i odabranih resursa. Fizičko projektovanje treba odlagati u što je moguće kasnije faze projektovanja. Sa aspekta standardizacije u projektovanju IS-a očigledno je da su standardi logičkog projektovanja postojaniji, jer zavise prvenstvenoоd sporijih рrоmјеnа u realnom sistemu,а ne оd eventualno brzih izmјеnа hardvera i softvera. Priprema prijedloga zа implementacijuprojektasadrži pregledurađenih poslova ipostignutih rezultata, očekivanu korisnost, troškove idetalјаn plan implementacije. Formiranje sistemske dokumentacijeje posljednji korak analize idizajna koji treba da osigura komunikacijusa fazom implementacije.
4.3.3. IMPLEMENTACIJA INFORMACIONOG SISTEMA Prethodnefaze u razvoju sistema svoje rezultate dајu samo na papiru ili eventualno nа magnetskom mediju ako sukorišćeni računarom podržani alati u projektovanju.Оd modela planiranog IS-apotrebno je preći u njegovu implementaciju. Implementacija obuhvata izgradnju, nabavku iintegraciju resursa radnog sistema kojiće funkcionisati u praksi. Najava implementacijeprojekta kao inajava izrade projekta ima zа cilj uklanjanje otpora istraha zaposlenih, odnosno njihovo pridobijanje za kooperativan rad. Organizacija personala iпformacionogservisa jeveoma značajna aktivnost za implementaciju, kasnije održavanje, vrednovanje ikontrolu sistema. Kjučni kadrovi informacionog centra suspecijalisti sistemskog softvera komunikacija administracije podataka i programeri. lzbor i instalacija računarske opreme obuhvata sljedeće aktivnosti:definisanje zahtjeva zа ponudu računarske isistemske opreme definisane u fazama planiranja, analize idizajna informacionog sistema, prikupljanje ponuda, izbor isporučiocai ugovaranje nabavke, instalacija opreme u radno okruženje korisnika. lzradaili nabavkasoftvera obuhvata realizaciju obezbjeđenja adekvatnog aplikativnog softvera obično na jedan оd sljedećih načina: Kupovina gotovog softverskog paketa, Razvoj softvera sasopstvenim kadrovima, Kombinovanje prethodna dva načiпa, Razvoj softvera pozahtjevima korisnika оd strane profesionalne softverske kuće i Razvoj softvera u saradnji profesionalne softverske kuće i sopstvenih kadrova. Formiranje baze podataka podrazumijeva obezbjeđenje računarske isistemske opreme, sistema zа upravljanje bazom podataka, aplikativnog softvera i drugih operativnih uslova zа formiranje baze podataka. Postojeći podaci seprenose i organizuju u bazu podataka novog IS-a.Ovaj zadatak je velik, složen iveoma često otežan iz sljedećih razloga: organizacija vršikonverziju manuelnog sistema па računarske medije, postojeće datoteke su velike, postojeće datoteke sadrže stare i neažurne podatke. Obuka korisnika jenužan uslov zа uspješan start sistema. Mora seizvršiti planiranje, realizacija iосјеnа obučenosti korisnika ito neposredno prije primjene stečenih znanja. Zamjena sistemamože biti: potpuna zаmјеnа starog sistema novim, fazna zamjena, paralelno funkcionisanje (neko vrijeme) starog inovog sistema. Po zamjeni sistema počinju faze fuпkcionisanja, održavanja, vrednovanja ikontrole informacionog sistema.
4.3.4. FUNKCIONISANJE I ODRŽAVANJE INFORMACIONOG SISTEMA Održavanje sistema obuhvata zamjenu i unapređivanje sistema dabi ostvario postavljene ciljeve, a može se posmatrati u odnosu nа instalirani hardver isoftver. Održavanje hardvera podrazumijeva: redovne preventivne aktivnosti provjera, čišćenja, podešavanja izamjena potrošnih dijelova, zamjene dijelova iiikompletnih uređaja, instalacija novih uređaja. Potrebe zаodržavanje softvera nastaju prije svega iz sljedećih razloga: novi zahtjevi korisnika, grešaka u izradi softvera, tehničke i hardverske promjene. Dobro dizajnirani, strukturirani, testirani i dokumentovani, programi su jeftiniji za održavanje. Neka istraživanja su pokazala da dodatna ulaganja od 10% vrijednosti programa u dizajn mogu dovesti i do 25% ušteda na troškovima održavanja. Obim promjena na pravcima:"Krpljenje" značajna promjena u promjena programa sa
programima obično se dešava u sljedećim je manja promjena, Nova verzija (release) je softveru (Nova verzija je obično cjelokupna mnogo novih karakteristika).
Načini rješavanja održavanja softvera usko su povezani sa odabranim načinom izrade i nabavke softvera. Proces održavanja se oslanja na iste metodološke aktivnosti koje se koriste u fazama analize i dizajna i implementacije sistema. Korisnici mogu do izvjesne mjere samostalno da prilagođavaju IS novonastalim potrebama prije svega zahvaljujući korisniku bliskim sredstvima kao što su: jezici četvrte generacije (4GL), jezici upita, generatori aplikacija i izvještaja. Kada se novi zahtjevi korisnika ne mogu sprovesti na radnom IS-u (postojeći model podataka, procesa, resursa) pristupa se modifikaciji postojećeg ISa izvođenjem svih koraka metodologije od sistema do radnog IS-a.
4.3.5. VREDNOVANJE I KONTROLA INFORMACIONOG SISTEMA Posljednja faza u razvoju informacionog sistema je vrednovanje i kontrola. Ovo je faza kada postoji i koristi se novi IS. Cilj ove faze je vrednovanje i kontrola sistema analizom sljedećih pitanja: Koliko je vrijeme odgovora na korisničke zahtjeve? Postoji li adekvatan program osposobljavanja korisnika IS-a? Da li je sistem pouzdan? Da li IS podržava posebne ciljeve i zadatke različitih oblasti i odjeljenja organizacije? Da li su procedure za očuvanje sistema, prevenciju kriminala, otuĎenje i narušavanje privatnosti adekvatne? Da li su komunikacije sistema adekvatne? Da li su hardver i softver ažurni i adekvatni za zadovoljavanje sadašnjih i budućih potreba korisnika? Da li postoje dovoljni i kvalitetni kadrovi za izvršavanja sadašnjih projektovanih zadataka obrade podataka? Da li je obezbjeĎen potreban budžet IS-u? Da li је sistem efikasan? Da li dokumentacija odražava trenutnu situaciju? Vrednovanje i kontrola se sprovode revizijom IS-a u cjelini i po ključnim komponentama: hardvera, softvera, baza podataka, telekomunikacija, personala i procedura.
4.4. BSP METODOLGIJA RAZVOJA INFORMACIONOG SISTEMA
Postoji više metoda za planiranje razvoja informacionog sistema od kojih se u praksi najčešće primjenjuje IBM-ova BSP metoda (Business Systems Planning). Za razliku od tradicionalnog razvoja informacionog sistema u kojem se odmah pristupalo projektovanju i uvoĎenju podsistema. Pristup od dna ka vrhu bez prethodnog projektovanja opšte strukture informacionog sistema. To je kasnije prouzrokovalo probleme u integraciji podsistema. Metod BSP se razvijao planiranjem i analizom odozgo na dolje, projektovanje i uvoĎenje od dna ka vrhu. BSP metoda posmatra poslovne procese kao najstabilnije dijelove realnog sistema i prema njima i kreira opštu arhitekturu informacionog sistema. Posebna pažnja je posvećena i podacima, koji se tretiraju kao posebni resursi u cjelokupnom sistemu. Kao ciljevi ove metode se mogu navesti težnje da se ciljevi informacionog sistema poklapaju sa ciljevima poslovanja, zatim da se olakša razumijevanje poslovanja od strane najvišeg rukovodstva, koje bi trebalo da bude uključeno u sam proces izrade informacionog sistema; da se kod planiranja informacionog sistema obavezno koristi pristup odozgo na dolje, a kod sprovoĎenja projekta obavezno odozdo na gore; da u informacioni sistem budu integrisani svi podsistemi ili baremšto više njih i sl. TakoĎe, ovom metodom je predložen plan aktivnosti, koje su opšte prihvaćene i koje se trebaju provesti kod primjene BSP metode : 1. Davanje saglasnosti 2. Priprema za studiju 3. Održavanje prvog radnog sastanka 4. Definisanje poslovnih procesa 5. Definisanje klasa podataka 6. Analiza postojećeg IS-a 7. Analiza rezultata problema i koristi 8. Definisanje arhitekture IS-a 9. OdreĎivanje prioriteta 10. Razrada plana realizacije. Navedene aktivnosti, u stvari, predstavljaju redoslijed aktivnosti prilikom provoĎenja BSP metode.
DAVANJE SAGLASNOSTI Da bi se u nekoj organizaciji pristupilo izradi plana razvoja informacionog sistema potrebno je upoznati najviše rukovostvo sa ciljem plana razvoja informacionog sistema, odabrati projektanta i potpisati ugovor o projektu, dobiti saglasnost najvišeg rukovostva da će dati na raspolaganje: dokumentaciju, izvršioce i dr.
PRIPREMA ZA STUDIJU Za pripremu studije potrebno je izvršiti sljedeće aktivnosti: detaljno definisanje aktivnosti za izradu cijele studije izrada vremenskog plana izvršavanja aktivnosti odreĎivnje članova tima i njihova zaduženja
upoznavanje realnog sistema odluka članova tima u BSP metodi odreĎivanje ljudi s kojim će biti obavljen intervju prikupljnje statuta, pravilnika, šifarnika i sl. priprema prvog radnog sastanka.
ODRŢAVANJE PRVOG RADNOG SASTANKA Prvom radnom sastanku prisustvuju: članovi tima iz spoljnih institucija članovi tima iz organizacije najviše rukovodstvo organizacije ljudi iz organizacije koji će biti intervjuisani admistator projekta iz organizacije. Najviši rukovodilac organizacije otvara sastanak i predlaže teme o: ciljevima studije, očekivanim razultatima, perspektive realizacije studije, karakteristike organizacije, perspektive organizacije, moguće teškoće u izradi studije i postojeći informacioni sistem. Sve se mora isplanirati, a zatim učesnici postavljaju pitanja.
DEFINISANJE POSLOVNIH PROCESA Ova aktivnost je jedna od najvažnijih aktivnosti u BSP metodi. Kao razultat treba da budu opisi svih procesa i identifikacija onih koji su ključni za uspjeh cijele organizacije. Poslovni proces je grupa logički povezanih odlučivanja i aktivnosti nepohodnih za upravljanje nekim resursom poslovnog sistema. Klasifikacija procesa prema BSP metodi: procesi planiranja i upravljanja procesi prizvodnje i usluga pomoćni procesi. Faza životnog ciklusa procesa proizvodnje, usluga i pomoćnog procesa: Planiranje; istraživanje tržišta, planiranje proizvodnje, kalkulacija cijena, plan nabavke s cijenom materijala, planiranje kapiciteta. Proizvodnja i tehnologija; (tehnološka priprema) konstrukcija, terminiranje, tehnično tehnološka dokumentacija, disponiranje materijala, upravljanje proizvodnjom, nabavka. Praćenje proizvodnje; upravljanje zalihama, kontrola kvaliteta, pakovanje i skladištenje, prijem robe. Zatvarnje ciklusa; prodaja, obrada narudžbi, otprema robe, transport do kupca. Pomoćni procesi su procesi upravljanja osnovnim resursima i to: novac, oprema, kadrovi, materijal. Kada se procesi sve tri grupe identifikuju, vrši se njihova analiza i konsolidacija. Eliminišu se nekonzistentnosti, kombinuju se slični procesi i grupišu u grupe procesa. Grupa procesa predstavlja agregaciju sličnih procesa. Da bi se provjerila identifikacija i opis procesa, odredili ljudi koji će još biti intervijuisani o odreĎenim procesima, otkrila evetualna preklapanja u zaduženjima i odlučivanju, formira se matrica odnosa poslovnih procesa i organizacija.
PLANIRANJE
PROIZVODNJA
DIREKTOR
X
/
/
ORG. JED 1
X
Z
ORG. JED. 2
X Z
ORG..... X-Glavni u procesu / -Uključen u proces Z- Dijelimično uključen u proces Tabela 10. Matrica odnosa poslovnih procesa i organizacije
DEFINISANJE KLASA PODATAKA Definisanje klasa podataka predstavlja jedan od ključnih koraka BSP metode. Postoje dva pristupa za indetifikovanje klasa podataka: 1. Veza podataka sa poslovnim elementima. 2. Na osnovu definisanih poslovnih procesa. Entitet (jedinica posmatranja) se definiše kao posebnost, neštošto se jasno razlikuje od drugih entiteta u sistemu. Pri identifikovanju entiteta u početnoj fazi pogodno je primjeniti postupak generalizacije, definušući opšte tipove entiteta dijeleći ih kasnije postepeno u posebne kategorije. Entiteti mogu biti: predmeti poslovanja, subjekti poslovanja, partneri u poslovanju, obaveze u poslovanju, transakcije za realizaciju poslovanja. Predmeti poslovanja dijele se na proizvode, opremu i usluge. Subjekti poslovanja su organizacione jedinice. Obavaze u poslovanju su ugovori i planovi, transakcije su trebovanja, narudžbe, fakture. Svaki ulaz i izlaz iz procesa može biti klasa podataka. S obzirom da ulazni i izlazni izvještaji ne predstavljaju klase podataka, potrebno ih je jasno identifikovati. ANALIZA POSTOJEĆEG IS-a U ovoj fazi BSP metode treba analizirati : Kako postojeći informacioni sistem podržava poslovanje? Koliko su pojedine organizacione jedinice podržane postojaćim aplikacijama? Kako postojeće aplikacije koriste podatke da bi se uočile redundanse?
ANALIZA REZULTATA, PROBLEMA I KORISTI U ovoj fazi se kroz niz intervjua provjeravaju razultati prethodnih faza, utvrĎuju osnovni poslovni problemi, način njihovog rješavanja, redoslijed uvoĎenja pojedinih modula, potencijalne koristi. Intervjue treba voditi sa unaprijed odabranim rukovodiocima i adekvatno pripremljenim pitanjima. Prilikom intervjua rukovodioce treba upoznati sa identifikovanim poslovnim procesima, organizacijom i klasama podataka. Po objavljivanju svih intervjua vrši se njihova analiza. Problemi se grupišu po kategorijama, procesu uzorka ili po nekom drugom kriterijumu. Problemi se dijele na one koji se mogu riješiti i one koji nisu rješivi podrškom informacionog sistema.
DEFINISANJE ARHITEKTURE IS-a Opšta arhiktetura informacionog sistema definiše se na osnovu odnosa procesa i klasa podataka.Matrica procesi/klase podataka se transformiše na sljedeći način: Vrste imenovane procesima ureĎuju se u skladu sa životnim ciklusom stavljajući na početak one procese koji pripadaju prvim fazama životnog ciklusa. Kolone imenovane klasama podataka ureĎuju se tako da prva kolona bude ona klasa podataka koju kreira prvi proces, sljedeća koju kreira drugi proces itd. Na ovakav način nastaje po pravilu matrica dijagonalna po blokovima u kojima se grupišu klase podataka i procesi koji ih kreiraju i koriste. Takvi blokovi predstavljaju podsisteme. ODREĐIVANJE PRIORITETA Prema unaprijed zadatim kriterijumima za svaki podsistem utvrĎuje se vrijednost njegove automatizacije i to: 1. 2. 3. 4.
potencijalna korist, uticaj na poslovanje (broj radnika, kvalitetni efekti, efekti na ostvarenju opštih ciljeva), procjena uspjeha realizacije (prihvatljivost, trajanje imlemetacije, raspoloživi resursi) i potražnja (vrijednost postojećeg sistema, veze sa drugim sistemima "politički" razlozi).
Za svaki podsistem i svaki kritrijum odreĎuje se ocjena od 1 do 10 i izračunava ukupna ocjena za podsistem. Na taj način podsistemi se ureĎuju po ukupnoj ocjeni na osnovu čega se može odlučiti o redoslijedu uvoĎenja podsistema.
RAZRADA PLANA REALIZACIJE Razrada plana realizacije predstavlja zadnju aktivnost. Plan predstavlja sintezu svih prethodnih istraživanja sa jasnim prijedlogom najvišem rukovodstvu kako upravljati razvojom informacionog sistema. Svakoj organizaciji je potreban dugoročni plan razvoja informacionog sistema, bez obzira na veličinu i poslovne ciljeve.
4.5. STRUKTURIRANA SISTEM ANALIZA
Strukturirana sistem analiza (SSA) je metoda za modeliranje procesa organizacionog ili tehničkog sistema. Koristi se u ranoj fazi razvoja informacionog sistema za izgradnju modela procesa i kao takva, predstavlja jedan od osnovnih elemenata u razvoju informacionog sistema. SSA je jedna potpuna metodologija za specifikaciju informacionog sistema. Ona se na različite načine može povezati sa metodama drugih faza u neku specifičnu metodologiju cjelokupnog razvoja IS-a. Tako na primjer, ona može biti polazna osnova za metodu Strukturnog projektovanja programa, ili projektovanja logičke strukture baze podataka metodom normalizacije, ili se može tretirati kao metodološki postupak dekompozicije nekog sistema na podsisteme sa ciljem da se nalaženjem modela podataka podsistema i njihovom integracijom, doĎe do potpunog modela podataka posmatranog sistema. Upravo zbog mogućnosti njene raznovrsne primjene, metoda SSA se ovdje tretira kao jedinstvena, samosvojna metoda, dok se u drugim materijalima pokazuje kako se ona koristi u pojedinim koracima Standardne metodologije razvoja informacionih sistema. Potpuna, tačna, formalna i jasna specifikacija IS-a, ili kako se to obično kaže, specifikacija zahtjeva korisnika, zahtjeva koje budući sistem treba da zadovolji, predstavlja bitan preduslov za uspješno dalje projektovanje i implementaciju sistema. Očigledno je zbog čega specifikacijaIS-a treba da bude potpuna i tačna. Zahtjev da specifikacijabude formalna iskazuje se zbog toga što je formalna specifikacijaosnov za "transformaciono" projektovanjei implementaciju, za atomatizovanogenerisanje baze podataka i programa iz nje, odnosno za korišćenje CASE tehnologija. Zahtjev da specifikacijabude jasna iskazuje se zbog toga što u specifikaciji IS-a u velikoj mjeri učestvuju korisnici sitema, neinformatičari, pa jezik specifikacijemora biti i njima prihvatljiv. Originalna SSA čiji su tvorci Yourdon i njegovi saradnici (DeMarco i drugi) posjeduje veoma jednostavne, grafičke, pa samim tim i jasne koncepte. Ovdje su svi ovi koncepti zadržani, a strožija formalizacija je dodata samo za opis strukture tokova i skladišta podataka, da bi se obezbijediospecifičan transformacioni razvoj IS-a koji Standardna metodologija zagovara. Specifikacija IS-a treba da prikaže (potpuno, tačno, formalno i jasno) šta budući informacioni sistem treba da radi. Veoma je bitno odmah istaći da specifikacijaIS-a prikazuje ŠTA IS treba da da, a ne i KAKO to treba da ostvari. Očigledno je da prerano definisanje "kako", odnosno davanje nekih projektantskih rješenja u okviru specifikacije, ograničava kasniji mogući izbor (optimizaciju) načina implementacijesistema. Odgovor na pitanje "kako" daje se za konkretno okruženje, za definisanu tehnologiju i organizaciju u kojoj se sistem implementira. Da specifikacijane bi sadržala tehnološki i organizaciono ograničena rješenja, obično se kaže da ona treba da opiše funkcionisanjeIS-a u "idealnoj tehnologiji", gdje praktično nikakva ograničenjane postoje. Ako je specifikacija ovako zadata, onda je, prije prelaska na dalje projektovanje, neophodno da se definišu sva ograničenjakoja nameće okolina u kojoj se sistem implementira.Zbog toga specifikacija IS-a treba da posjeduje sljedeća dva dijela: 1. funkcionalnu specifikaciju u kojoj se opisuje budućiIS u "idealnoj tehnologiji" i 2. nefunkcionalnu specifikaciju koja definiše sva ograničenja implementacione okoline. SSA u potunosti obuhvata samo funkcionalne specifikacije, dok nefunkcionalnesamo djelimično pokriva prikazujućitokove podataka u novoimplementiranom sistemu. Ostali dio nefunkcionalnih specifikacija obično predstavlja samo nabrajanje zahtjevanihperformansi budućeg IS-a i ograničenja implementacione okoline. SSA posmatra informacionisistem kao funkciju (proces obrade) koja, na bazi ulaznih, generiše izlazne podatke. Ulazni podaci se dovode u proces obrade, a izlazni iz njega odvode preko tokova podataka. Tok podataka se tretira kao vod ili kao pokretna traka kroz koji stalno teku ili koja stalno nosi podatke na najrazličitijim nosiocima - papirni dokumenti, niz poruka koje čovjek unosi preko tastature terminala, "paket" informacija dobiven preko neke telekomunikacione linije ili slično. Imajući u vidu
zahtjev da specifikacijatreba da se oslobodi svih implementacionih detalja od interesa su samo sadržaj i struktura ulaznog toka, a ne i medijum nosilac toka. Izvoriulaznih, odnosno ponori izlaznih tokova podataka mogu biti objekti van IS-a koji sa IS-om komuniciraju i koji se u SSA nazivaju interfejsi, drugi procesi u sistemu, ili tzv skladišta. Skladišta podataka se posmatraju kao "tokovi u mirovanju", odnosno odloženi, akumuliranitokovi, različite vrste evidencija, arhiva, kartoteka i datoteka. I za skladišta kao i za tokove od interesa su isključivo njihov sadržaj i struktura. Osnovna sredstva za sprovoĎenje strukturirane sistem analize su: Dijagram toka podataka i Rječnik podataka.
4.5.1. DIJAGRAM TOKA PODATAKA Grafički opis sistema koji zahtjeva dijagram konteksta i druge dijagrame dobivene dekompozicijom, podrazumijeva postojanje odgovarajucih sredstava, tj. grafičkih simbola koji će obezbijediti prikaz tokova i skladišta podataka, objekata i procesa sistema na svakom željenom nivou detaljizacije. Ovim komponentama ponekad se pridodaju i tzv. granični entiteti i uslovi pokretanja procesa. Svaki od ovih elemenata imaju svoje simbole kao sto je prikazano na Slici 15:
NAZI V Naziv toka
Ulaz / Izlaz podataka Tok podataka
Proces obrade podataka
P
Slika 16. Simboli dijagrama toka podataka
Dijagram toka podataka predstavlja, dakle, grafički opis, sistema na kome su sistem i njegove komponente prikazane kao mreža sastavljena od spoljnih objekata (institucije, organizacije, pojedinci i slično, izvan ili u okviru sistema), ulaznih i izlaznih tokova podataka (dokumenti, formulari, obrasci i slični nosioci), skladišta podataka (baze, datoteke, kartoteke i dr.) i procesa koji transformišu ulazne tokove u izlazne.
Tok podataka Tok podataka pokazuje “vod” kroz koji se prenose poznate strukture podataka. Grafički simbol toka podataka je prava orijentisana linija (ili orijentisani luk) kojom se oznacava smjer povezanosti elemenata. Na liniji koja predstavlja tok podataka, obavezno se upisuje jedinstveno ime toka koje treba da odražava semantički sadrzaj podataka koji se njime prenose (prvo pravilo u vezi sa tokovima podataka). OdreĎeni broj autora dozvoljava i jedini izuzetak od ovog pravila imenovanja tokova, i to u slučaju kada tok ide "U" ili "IZ" skladišta, prateći pri tom cjelokupnu strukturu podataka tog skladišta. To istovremeno znači da ukoliko se ne prenosi cjelokupna struktura podataka (već samo njen dio) mora se opet primjeniti pravilo imenovanja toka. Drugo bitno pravilo u vezi sa tokovima glasi: skladišta podataka su tzv. "pasivni" elementi sistema i ne mogu se meĎusobno (direktno) povezivati tokovima, bez procesa preko koga bi se taj prenos
izvodio. To implicitno znači da tok može postojati kao veza izmeĎu svih drugih nabrojanih komponenti DTP. Tokovi podataka koji idu od ulaza-izlaza podataka nazivaju se ulazni tokovi, oni koji iz sistema idu ka ulazu-izlazu podataka nazivaju se izlazni tokovi podataka, dok se svi ostali nazivaju internim tokovima podataka. U sistemu mozemo naći sljedece tokove podataka: tokovi podataka izmeĎu dva procesa, tokovi podataka od procesa ka skladištu podataka, tokovi podataka od skladišta podataka ka procesu, tokovi podataka od izvora podataka ka procesu i tokovi podataka od procesa ka izlazu podataka Skladište podataka Skladište podataka su one komponente dijagrama toka podataka (elementi sistema) u kojima se podaci čuvaju. To su, na primjer, kartoteke, evidencije, registri, datoteke itd.
Slika 17. Skladište podataka Pristup skladištima podataka obezbjeĎjuje se kroz procese, a realizuje putem tokova, koji (kao što je napomenuto) ne moraju biti imenovani. MeĎutim, ukoliko se procesom vrše neke izmjene (ažuriranje i sl.) nad podacima, tako da ulazni i izlazni tok podataka nisu identični, potrebno (obavezno) je da se tokovi imenuju. Na dijagramu podataka nije moguce imati skladiste podataka koje nema ulazni tok.
Procesi Proces obrade podataka je tzv. "aktivna" komponenta dijagrama toka podataka i predstavlja jednu ili više operacija kojima se na bazi ulaznih generišu izlazni tokovi podataka. Za proces možemo uopšteno reći da vrši transformaciju ulaza i izlaza prema nekim unaprijed utvrĎenim pravilima. Ta pravila u praksi mogu biti definisana na najrazličitije načine: od uputstava za rad odreĎenih izvršioca do kompjuterskih programa kojima se vrši obrada. Svaki proces mora imati svoje ime, koje (analogno pravilu imenovanja tokova) precizno označava funkciju tog procesa, što znači da prilikom izbora naziva procesa treba voditi računa da naziv opiše jedinstvenu aktivnost, da se po mogućnosti sastoji od jednog glagola i naziva jednog objekta i da se trebaju izbjegavati izrazi bez konkretnog značenja (npr. obraditi, procesirati…). Uz samo ime procesa se (veoma često) dodjeljuje i brojna oznaka koja služi kao referentni indeks prilikom pozivanja procesa; ona je neophodna takoĎe kod dekompozicije, tj kod raščlanjivanja procesa nad podprocese.
Efekat okruţenja – interfejs Ovim imenom se označava svaki objekat koji nije u potpunosti dio strukture posmatranog sistema, već se nalazi izvan konteksta konkretnog posmatranja. Bitno obilježje spoljnog objekta (koje ga identifikuje kao interfejs) je činjenica da mora predstavljati ulaz ili izlaz podataka. Svaki spoljasnji objekat takoĎe mora imati ime, a grafički simbol koji ga označava je pravougaonik. Tokovi podataka izmeĎu samih objekata se ne predstavljaju na DTP. OdreĎivanje spoljnih objekata u praksi zahtjeva preciznu identifikaciju granica posmatranog sistema. Npr. objekat kupac ili objekat dobavljač će biti spoljni objekat za IPS finansija u jednom preduzeću. MeĎutim, ako je kontekst posmatranja mnogo širi i ako se odnosi na čitavo preduzeće kao kompaniju i njen informacioni sistem (veći dio kupaca/dobavljača tada moze biti u okviru tog poslovnog sistema), kao spoljni objekti pojaviće se npr. poreska služba, statistika, druga preduzeća i sl. Graniĉni entiteti Čine ih ulazi i izlazi iz kojih potiču ili odlaze podaci, a koji se nalaze na granici posmatranog sistema. Treba naglasiti da su "ulaz" i "izlaz" samo oznake funkcija tih graničnih elemenata. Isti elemenat može u odreĎenim slučajevima imati funkciju ulaza i izlaza. Ime i oznaka graničnog elementa dodjeljuju se prema istim principima kao kod tokova i procesa.
Uslov procesa Kao komponenta posebno je značajna kod DTP detaljnijeg nivoa i predstavlja dogaĎaj ili uslov bez čijeg ispunjenja neće doći do izvršenja procesa. Npr. uslov za pokretanje procesa "isporuka robe" može biti uplata. To konkretno znači da ukoliko taj uslov nije ispunjen (kupac nije uplatio robu) neće ni doći do pokretanja tj. izvršenja procesa isporuke robe.
Formiranje dijagrama podataka Mnogičesto miješaju pojmove dijagrama toka podataka i dijagrama toka programa. Osnovna razlika izmeĎu ova dva pojma je što se dijagram toka programa predstavlja kao jedan sekvencijalan proces dok je dijagram toka podataka skup paralelnih procesa i veza, tokova i skladišta podataka. Spomenuta razlika se najbolje može opisati na sljedeci nacin: "Ako ikada naiĎete na organizaciju u kojoj jedan čovjek obraĎuje jedan dokument dok svi ostali spavaju, pa kad završi obradu dokumenta, taj čovjek probudi sljedeceg i preda mu dokument, a on sam zaspi – tada slobodno koristite dijagram toka programa za opis procesa u toj organizaciji". Važno je napomenuti da se za formiranje dijagrama toka podataka koristi "top-down"tj. "odozgonadolje"metoda. Samo formiranje dijagrama toka podataka se odvija kroz sljedece korake: Identifikacija ulaznih i izlaznih tokova podataka u procesu, njihovo imenovanje i upisivanje u rječnik podataka.
Imenovanje procesa transformacije ulaznih i izlanih podataka i davanje brojne oznake. Ako je moguće, proces treba dekomponovati i za svaki dobiveni podproces ponoviti prethodne korake. Ako dekompozicija nije moguća, proces je potrebno opisati prirodnim jezikom i opis unijeti u rječnik podataka. Dekompenzaciju vršiti do najprimitivnijih procesa, tj. onih koji se dalje ne mogu dekomponovati.
Dijagram konteksta Prije početka gradnje informacionog sistema potrebno je izvršiti odreĎene radnje kako bi se analizirala situacija i odlučilo o konkretnim zadacima i ciljevima projekta, a prvi korak analize je izrada dijagrama konteksta. Izrada dijagrama konteksta se izvodi u dvije faze gdje se u prvoj fazi prikupljaju podaci i dokumenta na osnovu kojih se vodi razgovor o tokovima podataka kako bi se shvatio njihov smisao, odnosno pojasnila funkcija sistema.
Dekompozicija sistema Druga faza je korak dalje i u njoj se vrši već pomenuta dekompozicija sistema, tj svoĎenje sistema na odreĎeni broj podsistema od kojih su oni posljednji u stvari jednostavni, primitivni podsistemi koji se dalje ne mogu dekomponovati. Prilikom dekompozicije analitičari moraju voditi računa da se ona bazira na kriterijumimasvrsishodnosti, čiji su argumenti poznavanje sistema i zdrav razum i koherentnosti, ciji su argumenti meĎusobna povezanost dijelova sistema. Koherentnost se opet dijeli na internu, koja predstavlja stepen unutrašnje povezanosti elemenata sistema i predstavlja razlog zbog kog su se pojedini dijelovi našli zajedno, eksternu, koja izražava stepen povezanosti jednog procesa sa ostalim procesima sistema preko tokova podataka i strukturnu, koja se može definisati kao preslikavanje strukture ulaznih tokova podataka u izlazne tokove podataka (ako su svi ulazi neophodni za formiranje izlaza i ako su svi izlazni tokovi dovoljni za postizanje cilja procesa). Strukturna koherentnost se mjeri kongruencijom (usklaĎenošću).
Slika 18. Kriterijumi dekompozicije IzmeĎu dijagrama konteksta i dijagrama toka podataka sa primitivnim procesima postoji odreĎen broj tzv. dijagrama srednjeg nivoa koji zavise od složenosti sistema koji se analizira i od načina dekompozicije. Prilikom dekompozicije mora se poštovati osnovno pravilo koje se naziva balansiranje dijagrama toka podataka, a glasi da je unija sadržaja ulaznih tokova podataka podreĎenog dijagrama toka podataka jednaka uniji sadržaja ulaznih tokova podataka procesa koji se dekomponuje. Isto važi i za izlazne tokove podataka. Na dijagramu toka podataka se mogu prikazivati i zavisnosti logike procesa od njegovih ulaznih i izlaznih tokova podataka, što generalno, treba izbjegavati i koristiti ih samo u slučaju ako njihovo prikazivanje doprinosi boljem razumijevanju dijagramu toka podataka.
UvoĊenje skladišta podataka Jošjedno važno pitanje kod dijagrama toka podataka je uvoĎenje skladišta podataka. Skladište podataka se uvodi u onaj dijagram podataka na kojem ga koriste dva ili više procesa. Ako ga koristi samo jedan od procesa, onda se skladište podataka navodi samo na onom dijagramu toka podataka na kojem se taj proces javlja. Tok podataka može biti direktan, što znači da su dva procesa dijelovi istog programa, ili indirektan, kada su dva procesa moduli sami za sebe. Odluka o uvoĎenju skladišta dijagrama podataka na dijagram toka podataka najviše zavisi od vještine i iskustva sistem analitičara uz sljedece preporuke: "skladište podataka se pojavljuje samo u sistemima gdje postoji datoteka, registar, katalog... ako se iz postojećeg modelira novi sistem, skladište podataka će postojati u novom ako je postojalo u postojećem sistemu na visokom nivou dijagrama toka podataka, komunikacija izmeĎu podsistema se obično obavlja putem skladišta podataka ako veći broj nivoa meĎusobno razmjenjuju iste podatke, ovi trebaju da sačinjavaju skladište podataka ako su neki podaci od vremenskog i/ili istorijskog značaja oni treba da sačinjavaju skladište podataka podaci od značaja koji pripadaju vremenski slabo promijenljivom skupu podataka treba da budu u skladištu podataka".
Rezime postupka dekompozicije Na kraju, slijedi rezime postupka dekompozicije jednog procesa "x"u podreĎeni dijagram: "ako je proces "x" primitivan ne dekomponuje se ako proces "x" nije primitivan dekomponuje se na tačno jedan podreĎeni dijagram podreĎeni dijagram se označava kao i njegov nadreĎeni proces "x", samo što podprocesi imaju upisane brojeve 1,2,3... stvarni brojevi procesa dobijaju se spajanjem oznake dijagrama i broja procesa (npr. proces 2, na dijagramu 3.1 ima broj 3.1.2) mora se ispoštovati pravilo balansa svi procesi, tokovi podataka i skladišta podataka na toku dijagrama podataka moraju biti imenovani skladište podataka navesti prvi i jedini put kada se javlja kao sprega dva ili više procesa ili kada ga koristi samo jedan proces na onom dijagramu toka podataka na kom se taj proces nalazi izbjegavati navoĎenje upravljačkih tokova informacija".
4.5.2. RJEČNIK PODATAKA Sistem: SSA:
Rječnik podataka daje opis strukture i sadržaja svih tokova i skladišta Naziv toka podataka. Bez obzira šta podataka:_________________________________________________________________________ Sinonimi:_________________________________________________________________________ tok ili skladište podataka Kompozicija:______________________________________________________________________ predstavljaju, papirni Napomena:________________________________________________________________________ dokument, niz karaktera kao ulaz sa terminala, "paket" informacija dobiven telekomunikacionom linijom, kartoteku ili datoteku, kao logička struktura podataka oni predstavljaju neku kompoziciju polja. Da bi precizno definisali logičku strukturu sladišta i tokova i definisali sintaksu rječnika neophodno je da uvedemo definicije svih koncepata rječnika. Analitičar: Datum:
Rječnik podataka predstavlja dokument kojim se vrši opis iz DTP, prema tome i njegovo nastajanje treba vezati za nastajanje DTP, tj. treba ga izraĎivati paralelno sa DTP. SSA dokumenti koji spadaju u rječnik podataka su: Tokovi podataka, Elementarni podaci, Skladišta i Primitivni procesi. Za izradu rječnika podataka preporučljivo je koristiti odgovarajuće obrasce koji, na veliku štetu, nisu standardizovani. Na slici je ilustrovan obrazac za izradu rječnika podataka. Predloženi obrasci koriste se kako bi opisali fizički i logički model sistema.
Tokovi podataka Tako na primjer, na fizičkom nivou opis podataka sadrži i opis sredstava uz čiju pomoć će se odvijati tokovi. Opis procesa fizičkog modela sistema sadrži, na primjer, trajanje, frekvenciju, način izvoĎenja i izvršioce procesa. Sistem: SSA: Analitičar: Datum: Naziv elementarnog podatka:__________________________________________________________________________ Sinonimi:_________________________________________________________________________ Vrijednosti i značenja:_________________________________________________________________________ Napomena:________________________________________________________________________
Sistem: SSA:
Elementarni podaci
Analitičar: Datum: Naziv skladišta:_________________________________________________________________________ Sinonimi:_________________________________________________________________________ Način pristupa:_____________________________________________________________________ Kompozicija:______________________________________________________________________ Napomena:________________________________________________________________________
Skladišta podataka
Primitivni procesi
Sistem: SSA: Analitičar: Datum: Naziv procesa:_________________________________________________________________________ Numerička oznaka:__________________________________________________________________________ Ulazni tokovi:_____________________________________________________________________ Opis:____________________________________________________________________________ Napomena:_______________________________________________________________________
Tokovi podataka Tačno jedna stavka u rječniku podataka odgovara svakom toku podataka sa DTP.
Taj tok podataka u rječniku podataka je opisan sljedećim karakteristikama: NAZIV TOKA – Direktno se preuzima sa DTP. SINONIMI – U toku izvoĎenja analize sistema moguće je da će se pojaviti različiti nazivi istog toka podataka. Kada doĎe do takvog slučaja, u rječniku podataka se navodi kompletan opis samo kod jednog toka dok se kod ostalih navodi spisak naziva tokova sinonima. KOMPOZICIJA – ili struktura toka podataka sadrži imena drugih tokova podataka sa DTP dobivenih njegovom dekompozicijom ili sadrži elementarne podatke ako tok nije dalje dekomponovan. NAPOMENE – Ovaj dio čine sve informacije koje nisu uključene u opis, a koje su relevantne. Na primjer: frekvencija korišćenja, veličina, korisnici, zaštita itd. Skup svih oznaka koje se koriste za kompoziciju tokova podataka je: 1. = ekvivalencija, 2. + konjukcija, 3. [ ] ekskluzivna disjunkcija (jedan ili drugi, ali ne oba), 4. { } ponavljanje, 5. *tekst* komentar. Relacija ekvivalencije ima uvijek naziv jednog toka sa lijeve strane, a kompoziciju tokova sa desne.
Konjukciju tokova T = T1 + T2 +…+Tn , označava da se tok podataka T sastoji od podataka koje sačinjavaju T1 i T2 I … Tn . Ekskluzivna disjunkcija T = [ T1 │ T2… │ Tn ]
označava da se u datom trenutku samo jedan od naznačenih tokova nalazi na kanalu. Operacija ponavljanja oblika {T} označava da se tok ili kompozicija T pojavljuje jedan ili više puta, pri čemu nije unaprijed zadat broj ponavljanja.
Elementarni podaci Elementarnim podatkom podrazumijevamo tok podataka koji se više ne može dekomponovati i kojem se može pridružiti vrijednost (numerička, logička, alfabetska). Elementarni podaci u SSA terminologiji odgovaraju obilježjima terminologije moderne civilizacije podataka, odnosno poljima u terminologiji klasične organizacije podataka Tokovi i elementarni podaci bi trebali da se odnose tako da tok podataka se ili može dekomponovati ili predstavlja elementarni podatak. Odluku o tome da li je neki tok elementarni podatak ili nije donosi sistem analitičar na osnovu iskustva i potreba informacionog sistema. Elementarni podaci su u rječniku predstavljeni sljedećim karakteristikama: 1. NAZIV ELEMENTARNOG PODATKA – koji se preuzima direktno iz rječnika podataka za tokove podataka, 2. SINONIMI – Spisak sinonima (kao i kod tokova podataka), 3. VRIJEDNOSTI I ZNAČENJA – Ako je broj vrijednosti od nekoliko podataka tada se navode sve vrijednosti dok se značenja navode kada iz vrijednosti nije jasno značenje. Sama vrijednost elementarnog podatka može da bude diskretna ili kontinualna. Ako je nemoguće navesti sve vrijednosti diskretnog podatka daje se način njegovog konstruisanja. Tako na primjer, za elementarni podatak PREZIME nije moguće navesti sve vrijednosti ali je sasvim dovoljno napisati "alfabetski podatak na latinici". Ako je podatak numerički sa mnogo mogućih vrijednosti, tada se navodi raspon vrijednosti. Na primjer, za elementarni podatak DNEVNA TEMPERATURA, može se dati raspon vrijednosti od -50o do +50oC. 4. NAPOMENA – Uz opis elementarnog podatka u ovom polju se može dati konkretan oblik vezan za kasniju fazu programiranja. Ovu vrstu informacija treba davati za sve elementarne podatke ili ih ne navoditi ni za jedan elementarni podatak. Skladišta podataka Skladišta podataka su pasivni elementi sistema u kojima se podaci trajno ili privremenočuvaju. Jedno skladište sadrži ureĎene skupove podataka istog tipa (pojave zapisa ako je skladište datoteka na računaru ili dokumenta ako je skladište skup dokumenata). Opis podataka u skladištu odgovara opisu toka podataka učijoj kompoziciji učestvuju isključivo elementarni podaci. Svakom skladištu podataka sa DTP odgovara tačno jedna stavka u rječniku podataka. Skladište podataka u rječniku podataka je opisano ovako: 1. NAZIV SKLADIŠTA – koji se direktno preuzima sa DTP.
2. SINONIMI – Spisak sinonima. 3. NAČIN PRISTUPA – Definiše način pristupa skladištu podataka koji može da bude: Sekvencijalan - pri obradi se pristupa redom svim pojavama zapisa ili dokumentima, Direktan – pristupa se jednom zapisu ili dokumentu zadavanjem vrijednosti ključa, Kombinovan. Ključ može da bude jedan element kompozicije ili konjukcija više elemenata i on jednoznačno identifikuje jednu pojavu tipa zapisa ili jedan dokument. U istom skladištu podataka ne mogu postojati dvije pojave tipa zapisa ili dva dokumenta sa istom vrijednošću ključa. 4. KOMPOZICIJA – ili struktura skladišta podataka sadrži imena elementarnih podataka koji opisuju tip zapisa ili dokument pri čemu vrijede iste oznake kao i za kompoziciju toka podataka. Zbog toga što skladištu odgovara skup od više pojava tipa zapisa ili dokumenata često unaprijed poznatog broja najčešći opis skladišta je {kompozicija zapisa ili dokumenta}. Elemente kompozicije koje pripadaju ključu treba u opisu kompozicije podvući. 5. NAPOMENA – sadrži druge bitne podatke o skladištu kao što su: broj zapisa ili dokumenata, način ureĎenosti zapisa ili dokumenata, broj novih zapisa ili dokumenata u periodu, nosioc podataka (papir, cd, i sl.), korišćenje podataka, čuvanje podataka i sl.
Procesi Opis procesa u rječniku podataka služi prvenstveno da opiše način transformacije ulaznih tokova podataka u izlazne tokove. U rječniku se opisuju samo primitivni procesi tj. procesi koji se u DTP dalje ne dekomponuju. Opis procesa moguće je dati različitim sredstvima kao što su: Tekstualni opis, Dijagrami toka programa, Stabla odlučivanja, Nassi-Shnaiderman-ovi dijagrami, Akcioni dijagrami, Tabele odlučivanja, Varnije-ovi dijagrami, Pseudokod (pseudo jezik). MeĎutim, navedena sredstva se koriste za grubi, "okvirni", opis procesa, koji prethodi njegovom mnogo preciznijem i detaljnijem opisu na programskom jeziku. S druge strane sredstva opisa procesa imaju za cilj uvoĎenje odreĎene discipline i preciznosti u izražavanju u komunikaciji izmeĎu korisnika i analitičara. Bez ulaženja u detaljniju analizu i ocjenu svih navedenih mogućnosti, a u skladu sa modernim pristupom u programiranju da se za opis algoritma koriste deskriptivne metode bitan je pseudokod kao ovdje prihvaćeno sredstvo za opis procesa. Ovaj kod je srodan sa višim programskim jezicima, ali on ne sadrži stroga pravila jezičke sintakse ni jednog od njih.
Kako bi definisali pseudokod treba da obuhvatimočetiri osnovne komponente: 1. Tipove i strukture podataka, 2. Osnovne kontrolne strukture, 3. Operacije ulaza i izlaza podataka i 4. Tehnike modularizacije. S obzirom da definisan pseudokod služi za opis procesa nezavisno od izvršioca (čovjek ili računar) te kao jezik za komunikaciju izmeĎu korisnika i analitičara posebno se ne definišu komponente pseudokoda za: tipove i strukture podataka i tehnike modularizacije programa. Aritmetički, skupovni, logički i relacioni operatori se u naredbama pseudokoda koriste na uobičajen način. Komentar u pseudokodu predstavlja niz alfanumeričkih znakova izmeĎu dva * znaka (*niz alfanumeričkih znakova*). Osnovni elementi strukturiranog načina pisanja algoritama, predstavljaju i osnovne kontrolne strukture pseudokoda. To su: Sekvenca, Selekcija i Ciklusi.
SEKVENCA Ova struktura je najjednostavnija od svih kontrolnih struktura. Ona opisuje niz aktivnosti, koje se bezuslovno odvijaju jedna za drugom. Redosljed izvršavanja aktivnosti odreĎen je redosljedom njihovog navoĎenja u pseudokodu.
Gore prikazana, je jedna sekvenca od tri aktivnosti pseudokodom i odgovarajućim blok dijagramom. Aktivnosti koje predstavljaju sastavne dijelove sekvence mogu u opštem slučaju da budu proizvoljne programske cjeline, a u najjednostavnijem i najčećem slučaju to su operacije postavljanja vrijednosti. Postavljanje vrijednosti definiše se oblikom: V←E gdje je V promjenljiva kojoj se postavlja vrijednost, a E neki izraz.
SELEKCIJA
Osnovna kontrolna struktura pod nazivom selekcija ilustrovana je na sljedećoj slici, i služi za prikaz izbora jedne od dvije mogućnosti. Semantika ove strukture se može opisati na sljedeći način: Ako je zadovoljen uslov P (proizvoljan logički izraz) tada se izvršava aktivnost A, a u protivnom se izvršava aktivnost B.
CIKLUSI Ciklusi (petlja, iteracija, engl. Loop) su interaktivne strukture koje imaju za cilj da omoguće kontrolisano višestruko izvršavanje proizvoljne grupe izvršnih operacija. Zbog izuzetne važnosti ciklusi se susreću u različitim specifičnim varijantama, dok će ovdje biti prikazane samo dvije.
Da bi se omogućila komunikacija izvršioca procesa sa skladištem podataka potrebne su aktivnosti za ulaz i izlaz podataka. U SSA kao što je već naprijed rečeno skladište može biti kartoteka, skup dokumenata, datoteka na računara i sl.
Osnovne aktivnosti procesa nad skladištem podataka su: ČITAJ – čitanje podataka iz skladišta, PIŠI – upis podataka u skladište, BRIŠI – brisanje podataka iz skladišta. Pored navoĎenja aktivnosti u ulaznim i izlaznim aktivnostima navode se i podaci o nazivu skladišta i podaci koji se čitaju ili upisuju. Fiziĉki i logiĉki model sistema Jedan od pristupa u SSA prije svega je da se snimi već postojeći sistem, tj. napravi skup DTP i rječnik podataka koji će opisivati postojeće procese, tokove i skladišta podataka. Skup takvih procesa, tokova i skladišta podataka može se podijeliti u dvije grupe. Jednu grupu čine oni elementi koji proizilaze iz suštinskih poslova i funkcija posmatrane organizacije. Drugu grupu čine procesi, tokovi i skladišta podataka koji su posljedica fizičkih ograničenja, odnosno postojeće organizacije rada i tehnologije u kojoj je IS implementiran. Skup DTP koji opisuju postojeće stanje predstavlja konkretnu implementaciju jednog sistema, a naziva se fiziĉki DTP postojećeg sistema. Zadatak koji ima sistem analitičar je da iz fizičkog DTP odvoji one elemente koji ne zavise od implementacije, znači one procese, tokove i skladišta podataka koji održavaju samo suštinske poslove organizacije. Skup DTP koji sadrži samo takve elemente naziva se logički DTP i predstavlja osnovu za specifikaciju zahtjeva korisnika. Opisana strategija SSA pikazana je DTP na Slici 19. Osnovni nedostaci ovog pristupa su ti što sa jedne strane kompletno i detaljno snimanje postojećeg stanja traži mnogo truda i vremena, a sa druge strane, što sam taj postupak izdvajanja logičkog od fizičkog modela sistema praktično najviše zavisi od sposobnosti i vještine analitičara. U praksi se dešava da se logički model postojećeg sistema uopšte ne izraĎuje, većse na onovu fizičkog modela i zahtjeva projektuje logički model novog informacionog sistema ili čak da se odmah izraĎuje logički model novog inormacionog sistema.
Slika 19. Logiĉki DTP
4.6. OBJEKTNO ORIJENTISANO MODELOVANJE Razvijanje softvera samo primjenom tehnika objektno orijentisanog programiranja (OOP) na nekom klasičnom, tekstualnom OO programskom jeziku (npr. C++ ili Java) pokazalo se kao nedovoljno efikasno iz sljedećih razloga:
Softverski sistemi su, po pravilu, jako složeni, a OOP ne pruža dovoljno efikasna sredstva za specifikaciju i dokumentovanje složenih softverskih sistema. Potrebna su efikasnija sredstva za hijerarhijsku dekompoziciju i organizaciju složenih softverskih sistema.
Koncepti koje nudi OOP su dobri, ali i dalje su nedovoljno apstraktni, tj. nedovoljno bliski visoko apstraktnom načinu razmišljanja neophodnom za rešavanje složenih problema. Na primer, pokazalo se da izmeĎu klasa, odnosno objekata, postoje i neke druge relacije osim onih koje direktno podržavaju OO programski jezici. Dalje, scenariji po kojima objekti meĎusobno saraĎuju da bi obezbijedili neko ponašanje sistema teško se uočavaju u tekstualnom programskom kodu jer su njihovi dijelovi rasuti po kodu mnogih klasa i njihovih operacija. Osim toga, izmišljeni su i mnogi koncepti pogodni za efikasan razvoj softvera koji su potpuno nepoznati nekim ili svim OO programskim jezicima.
Tekstualni način specifikacije manje je efikasan od vizuelnog, grafičkog načina (notacije).
OOP ne pruža dobru podršku za sve faze razvoja softvera (specifikacija zahtjeva, analiza, projektovanje, implementacija, testiranje) i ne omogućava lagan prelaz izmeĎu njih.
OOP ne pruža dovoljno efikasna sredstva za dobru dokumentaciju softvera bez previše dodatnih napora.
Zbog ovoga su formirane metode za objektno orijentisano modelovanje (engl. object-oriented modeling, OOM). Te metode podrazumijevaju:
razvoj modela softvera na višem nivou apstrakcije, korišćenjem apstraktnijih koncepata od onih koje nudi OOP (ali i nekih koje direktno podržava OOP);
specifikaciju modela pomoću vizuelnih, grafičkih notacija;
transformaciju takvih visoko apstraktnih, vizuelnih modela u implementacione forme; implementaciona forma je tipično programski kôd na nekom klasičnom, tekstualnom OO programskom jeziku (npr. C++ ili Java) koji se dobija iz OO modela softvera.
Poslije mnogih predloženih metoda modelovanja, usvojen je jedinstven, standardni jezik za OOM koji se naziva UML (The Unified Modeling Language). Prema tome, OOM je viši tehnološki nivo razvoja softvera od OOP-a, koji se oslanja na (nadograĎuje) OOP. To znači da svi principi OOP-a i dalje važe, ali se koriste na nižem nivou apstrakcije, prilikom same implementacije OO modela. Principi OOM-a se koriste u ranijim fazama razvoja softvera u cilju efikasnije specifikacije i analize zahtjeva i projektovanja rešenja. Principi OOP-a se koriste u fazi implementacije, tj. preslikavanja modela u izvršni oblik. UML je standardni jezik koji podržava OOM.
4.6.1. MODELIRANJE PODATAKA
Modeliranje podataka predstavlja apstraktno sagledavanje stanja realnog sistema tj. definisanje strukture podataka. Model podataka je pojednostavljeno predstavljanje realnog sistema preko skupa objekata (entiteta), veza izmedju objekata i atributa objekata. Za opis rada poslovnog sistema veliki je problem što ne mogu da se koriste prirodni jezici jer su dvosmisleni. S druge strane precizan opis preko formalnih jezika je nerazumljiv za većinu ljudi. Ono što nam je potrebno, jeste tehnika koja organizuje prirodne jezike na taj način da eliminiše dvosmislenost i omogući efikasnu komunikaciju i razumjevanje. Pokazalo se da je postupak modeliranja jedna od najefektivnijih tehnika za razumijevanje i jednoznačnu komunikaciju. U procesu modeliranja, eliminišu se detalji, čime se umanjuje vidljiva kompleksnost sistema koji se proučava. Preostali detalji se organizuju na takav način da bi eliminisali dvosmislenost i istakli bitne informacije. Grafičke prezentacije (uglavnom pravougaonici i linije), se koriste da bi obezbijedile da većina ljudi razmišlja o procesu modeliranja kao o slikovitoj prezentaciji (jedna slika zamjenjuje 1000 riječi). Pored grafičkog prikaza potrebno je dati i precizne definicije predmeta koji se pojavljuju u modelu, kao i propratni tekst, koji je kritičan prema modelu koji vrši svoju ulogu, kao sredstvo komunikacije. U inženjerstvu, model se konstruiše prije nego što se izgradi fizički sistem. U automobilskoj industriji, izraĎuju se modeli koji su namijenjeni ispitivanjima. Na ovaj način se obezbjedjuje vjerovatnoća uspješnosti fizičkog proizvoda. U arhitekturi arhitekte daju nacrte prije nego što pristupe izgradnji kuće. Nacrti predstavljanju logičku prezentaciju fizičke zgrade. Budući vlasnici kuće daju povratne informacije koje će biti prenesene na stvarni dizajn. Postupak modeliranja dozvoljava da sistem može biti analiziran, shvaćen išto je možda i najbitnije prenesen drugima. Model podataka (u literaturi definisan kao Model Objekti-Veze (MOV) ili E–R (Entity-Relatioship) model ili Entitetni dijagram), preko skupa podataka i njihovih meĎusobnih veza, predstavlja stanje sistema u jednom trenutku vremena i sadrži skup informacija o prošlosti i sadašnjosti sistema koja je potrebna da se pod dejstvom budućih poznatih ulaza mogu odrediti njegovi budući izlazi. Modeliranje podataka je svojevrstan grafički jezik za predstavljanje strukture podataka. CASE (Computer Aidid Software Engineering) alati kao softverska podrška modeliranju predstavlja samo alat za definisanje modela podataka realnog sistema, odnosno za opisivanje skupa povezanih objekata realnog sistema i dogaĎaja u njemu preko jednog složenog apstraktnog tipa podataka (strukture podataka, ograničenja i operacija). Izbor odgovarajućeg CASE alata sam po sebi je manje ili više formalan, dok postupak modeliranja realnog sistema, zavisi od sposobnosti, znanja i iskustva analitičara. Ne mogu se dati strogo formalna pravila modeliranja koja bi vodila do jedinstvenog modela složenog realnog sistema, bez obzira na to ko modeliranje vrši. Mogu se dati samo opšte metodološke preporuke, opšti metodološki pristupi, kao pomoć u ovom složenom poslu. Modeliranje podataka se oslanja na izvršeno modeliranje procesa gde je definisan odgovarajući rječnik podataka. Modeliranje podataka se praktično svodi na dva koraka: 1. modeliranje pogleda i 2. modeliranje zahtjeva.
Osnova za modeliranje pogleda su definisani dijagrami tokova podataka do kojih se došlo postupkom itervjua sa zaposlenima. Modelirani pogledi zahtjevaju integraciju u generalni model podataka tako da ovaj pristup predstavlja tzv. pristup odozgo na dolje (top-down). U modeliranju pogleda prvo je potrebno odrediti "oblasti" pogleda gdje treba da budu definisane jasne granice. Ove granice su definisane procesom u dijagramima tokova podataka (DTP) i one ne trebaju da bude isuviše male da bi imalo smisla obraĎjivati ih ali ni suviše kompleksne da se ne mogu sagledati u cjelosti. Dakle, modeliranje pogleda počinje sa formiranjem okvirnog modela podataka pa pristupom proširivanja generišemo model podataka pritom vodeći računa o sinonimima (različita imena za iste tipove entiteta), homonimima (ista imena označavaju različite tipove objekte) kao i o tome da isti entiteti na različitim pogledima budu iste vrste (slab, agregacija i dr.), da ista preslikavanja na različitim podmodelima imaju iste kardinalnosti, pritom treba otkriti da li veze izmeĎju istih tipova entiteta po različitim putanjama imaju istu semantiku pa neku od tih veza treba prekinuti. Na osnovu izmodeliranih pogleda i izvedene njihove integracije pristupa se modeliranju zahtjeva kojima se precizno definišu atributi na osnovu postojeće dokumentacije(obrasci, kartoteke, fascikle i dr.). Ovo je pristup odozdo na gore (bottum-up). Osnovni zaključak je je daširinu u pristupu nam daje modeliranje pogleda, a preciznost omogućuje modeliranje zahteva. Da bi se postupak modeliranja podataka uradio korektno korišćenje CASE alata omogućava: 1. Definisanje sistemske dokumentacije koja može biti korišćena od strane baze podataka i osoblja za razvoj aplikacija da definišu sistemske zahtjeve. 2. Bolju komuniciju meĎusobno i sa krajnjim korisnicima. 3. Jasnu sliku o ograničenjima referencijalnog integrita. Održavanje referencijanog integriteta je bitno u relacionom modelu jer su relacije kodirane implicitno. 4. Logičke sliku baze podataka koja može biti korišćena od strane automatskih alata za generisanje SUBP - specifičnih informacija. Model podataka je intelektualno sredstvo pomoću koga se prikazuje u kakvom su meĎusobnom odnosu podaci u nekom realnom sistemu. Neki model podataka je potpuno odreĎen ako su definisane sljedeće tri komponente: 1. STRUKTURE PODATAKA, kojima se definišu statičke karakteristike sistema (opis entiteta, atributi i veze) odnose se na kreiranje ER modela i Atributi ER modela. 2. OGRANIČENJA, logička ograničenja na podatke (pravila integriteta) koja se ne mogu definisati preko strukture modela podataka (strukturna i vrijednosna ograničenja) i odnosi se na definisanje poslovnih pravila. 3. SKUP OPERATORA (OPERACIJE), definiše dinamičku interpretaciju podataka kroz njihovu obradu (održavanje BP i pretraživanje) ima uticaja na definisanje fizičkog nivoa modela i verifikaciju finalnog dizajna. ER model definisan je entitetnim dijagramom kojim se definišu odgovarajući tipovi entiteta i uspostavljaju veze izmeĎu njih, kao i definisanje detalja vezanih za opis sadržaja entiteta (atributi i njihove karakteristike). Struktura podataka definisana je sa tri komponente: 1. Entitete koji se dijele u dvije grupe i to: Nezavisne entitete, to su entiteti koji imaju vlastitu identifikaciju, tj. nisu zavisni od drugog entiteta. Zavisni entiteti, to su entiteti čija je egzistencija i identifikacija zavisna od drugog ili drugih entiteta 2. Atribute koji se mogu nalaziti u: Oblasti kljuĉeva ili Oblasti podataka.
3. Veze koje se dijele na: Identifikujuće veze koje entitet dijete identifikuje kroz njegovu vezu sa entitetom roditelj. Neidentifikujuće veze koje ne identifikuju entitet dijete preko identifikatora entiteta roditelja. NeodreĊujuće veze koje se smatraju veze više prema više. Veza prema podtipovima uspostavlja vezu izmeĎu entiteta i njegovih zavisnih, klasnih entiteta. Entitetni dijagram definiše se entitetima (entities) i pritom svaki entitet ima svoje osobine tj. atribute (attributes) i sve je to povezano relacionim vezama (relationships). Entiteti se definišu i kao generalizovane hijerarhija. Atributi imaju domene (domain)koji predstavljaju skup vrijednosti ili interval vrednosti koje taj atribut može da primi.Na sljedećem nivou definišu se primjerci (instance)koje predstavljaju pojedinačne vrijednosti entiteta. Svaki entitet se identifikuje preko atributa koji se zove primarni ključ.Relaciona veza povezuje dva entiteta i ona ima svoje osobine koje se nazivaju kardinalnost, koja pokazuje "koliko nečega" od dva entiteta može biti uključeno (sadržano). Relaciona veza definisana je prenesenim ključem (foreign key) od roditelja ka djetetu. Preneseni ključ može imati i ime uloge (rolenames). Entitetni dijagram je svojevrsan grafički jezik gdje se "rečenica"sastoji od entiteta koji su imenice, atributa kao pridjeva i veza kao glagola. Entiteti i veze definišu se analizom strukture teksta gdje se mogu definisati analogije vezane za razlikovanje entiteta, atributa ili veza.
4.6.2. MODELIRANJE PROCESA Modeliranjem poslovnih procesa dobija se ureĎena struktura sa jasno definisanim pravilima po kojima se ti procesi odvijaju. Razlozi koji su motivisali nastanak modeliranja procesa su: Da služe kao dukumentacija i upustvo za opis kompleknih poslovnih procesa. Jedno od osnovnih pravila je da što je dokumentacija veća - manje se čita. Dokument od jedne ili dvije strane sa dijagramom, biće letimično pregledan i to onda kada se za to bude imalo vremena. Dukumentacija od 30 strana ima veliku šansu da mjesecima ne bude pročitana. Da omoguće brze organizacione promjene, jer model procesa dokumentuje važne aktivnosti i omogućava uvid u kritične aktivnosti koje treba izvesti sa odgovarajućim resusima. Najvažnija korist je prototipski pristup modeliranju gde se na brz i jednostavan način provjeravaju alternative ideja. Mnogo je jednostavnije i jeftinije nacrtati model i provjeriti ga na "papiru", nego razviti novi informacioni sistem ili izvršiti reorganizaciju sektora. Ovo je veoma bitna osobina jer brzi razvoj informacionih tehnologija i primjena INTERNET servisa, EDI i EDIFACT standarda uslovljava potrebu za reinženjeringom koja zahtjeva radikalni redizajn poslovnih procesa koje je potrebno opisati i prije sprovoĎenja prototipski provjeriti. Metode za modeliranje procesa koje će se ovdje predstaviti su IDEF0 i DFD i biće prezentovane kroz BPwin 1.8 CASE alat firme LogocWorks. U BPwin-u su objedinjeni alati za funkcionalno, dataflow i workflow modeliranje. Funkcionalno modeliranje (IDEF0) omogućuje sistematičnu analizu posla tj. za svaku poslovnu funkciju se obezbjeĎuje kontrola ispravnosti odvijanja, planiraju se potrebni resursi potrebni da se funkcija realizuje, ulazi u poslovnu funkciju, kao i izlazi koji se na oznovu ulaza generišu. Dataflow (DFD) modeliranje, koristi se pri dizajniranju softvera, fokusira problem tokova podataka izmeĎu procesa, kao i analizu skladišta podataka u cilju maksimalnog povećanja njihove raspoloživosti i smanjenja vremena pretraživanja.
FUNKCIONALNO MODELIRANJE (IDEF0) Tokom 60-tih i 70-tih godina Douglas T. Ross je razvio tehnike modeliranja poznate kao SADT (Structured Analysis & Design Technique). Prihvatajući SADT tehniku avijacija SAD su razvile SADT kao dio ICAM (Integrated Computer Aided Manufacturing) programa tokom kasnih 70-tih, koje su dobile naziv tehnike IDEF0 (Integrated Computer Automated Manufacturing Definition). Cilj ICAM programa je bio da se poboljša proizvodna produktivnost primjenjivanjem kompjuterske tehnologije. Učesnici u izgradnji ICAM programa su uvidjeli sve prednosti korišćenja IDEF0 tehnike jer tekstualni opis ne predstavlja efikasan način da se dokumentuje proces. Prema tome, jedan od nusprodukata ICAM programa je bilo stablo grafički zasnovanih opisa koji je korišćen za dokumentovanje procesa proizvodnje i prikazivanje koje informacije i izvori su potrebni u svakom koraku. U ranim 90-tim, IDEF Users Group, u kooperaciji sa National Institutes for Standards and Technology (NITS), je preduzela odreĎene napore za stvaranje standarda za IDEF0, publikujući ih 1993. godine (U.S. Government standards documents), poznatim kao FIPS. Ovi standardi su pod pokroviteljstvom Institute of Electrical and Electronics Engineers (IEEE) i prihvaćene su od strane International Organization of Standards (ISO). Ovaj standard opisuje jezik za modeliranje (sintaksu i semantiku) aktivnosti koji podržava IDEF0 tehniku za razvoj strukturiranih grafičkih prikaza odgovarajuće problemske oblasti. Aktivnosti koje se
razmatraju su imenovani proces, funkcija ili zadatak, koji se realizuje u odreĎenom periodu vremena i ima prepoznatljive rezultate. Dakle, IDEF0 je tehnika modeliranja aktivnosti bazirana na kombinaciji grafike i teksta koji su predstavljeni na organizovan i sistematičan način da bi se povećala razumljivost, koja podržava analizu, obezbeĎuje logiku za potencijalne izmene, specificira zahtjeve, ili rečeno na drugi način podržava analizu sistema po nivoima i integriše aktivnosti. IDEF0 model se sastoji od hijerarhijskog niza dijagrama koji postepeno prikazuju sve više detalja o funkcijama i njihovoj meĎuvezi (interface) sa ostalim dijelovima sistema. IDEF0 ili workflow modeliranje omogućuje analizu osobina odreĎenog poslovnog procesa sa ciljem njegovog maksimalnog unapreĎenja. Postoje tri vrste dijagrama: grafički, tekstualni i rječnik (glossary). Grafički dijagram definiše funkcije i veze funkcija preko pravougaonika i strelica i odgovarajuće sintakse i semantike. Tekst i rječnik pružaju dodatne informacije i podržavaju grafičke dijagrame. IDEF0 omogućuje: Izvršenje sistem analize i dizajna na svim nivoima, za sistem sastavljen od ljudi, mašina, materijala, računara i informacija; Stvaranje dokumantacije paralelno za razvojem sistema koja služi kao osnova za integraciju novih sistema ili za unapreĎenje postojećih sistema; Bolju komunikaciju izmeĎu analitičara, dizajnera, korisnika i menadžera; Omogućuje diskusiju u radnom timu da bi se postiglo meĎusobno razumijevanje; Omogućuje upravljanje velikim i složenim projektima; ObezbjeĎuje elemente potrebne za modeliranje podataka.
STRUKTURA JEZIKA Grafički jezik IDEF0 definisan je odgovarajućom sintaksom i semantikom. Sintaksa grafičkog jezika IDEF0 su pravougaonici i strelice (boxes and arrows) i pravila (rules).
Pravougaonik(box) Pravougaonici predstavljaju aktivnosti, definisane kao funkcije, procesi i transformacije. Tipičan pravougaonik je prilazan na Slici 20. Svaki od pravougaonika ima ime i broj unutar granica pravougaonika. Ime treba da je aktivan glagol ili glagolska fraza koja opisuje funkciju. Svaki pravougaonik na dijagramu treba da sadrži u svojoj unutrašnjosti broj u donjem desnom uglu. Broj pravougaonika se koristi da bi prepoznao predmet opis problema pravouganika u pridruženom tekstu.
Slika 20. Sintaksa pravougaonika (Box) Dakle, pravougaonikom se definišu sljedeće karakteristike aktivnosti: aktivnost mora biti imenovana, mora se dešavati u odreĎenom periodu vremena i mora imati prepoznatljive rezultate.
Prva karakteristika je da aktivnosti moraju biti imenovane tj. imena aktivnosti su obično formata \glagol\ \subjekt\. Definicije ne smiju biti duge, ali bi trebale u potpunosti da objasne svaku aktivnost. Glagol ili glagolska fraza u imenu definiše se kao akcioni glagol. Drugo, aktivnost ima vremensku dimenziju tj. odreĎeno vrijeme mora proći izmeĎu početka i kraja. Aktivnosti nisu jednostavno drugi način posmatranja postojeće informacije. Prije nego što se nešto definiše kao aktivnost, mora se imati u vidu da se troši energija u trenutku trajanja aktivnosti. Energija može biti fizička, mehanička ili električna. Treće, sve aktivnosti moraju dati rezultat svog rada. Aktivnosti koje ne proizvode odgovarajući rezultat mogu se definisati kao aktivnosti, ali samo iz razloga opisa onakvog kakav je on u stvarnosti. MeĎutim takve aktivnosti najprijeće biti eliminisane. Značajno je da sve aktivnosti moraju biti označene sa glagolskim frazama, a sve strelice moraju biti označene imenicama.
Strelice(Arrows) Sljedeći element sintakse je strelica koja se satoji od jedne ili više linija, sa vrhom strelice na jednom kraju. Strelice mogu biti pravolinijski ili savijene pod uglom od 90 stepeni, i mogu se račvati ili spajati. Strelice predstavljaju podatke ili objekte vezane za aktivnosti i ne predstavljaju samo tok ili sekvencu kao u tradicionalnom modelu dijagrama toka podataka već prenose podatke ili objekte vezane za posmatranu aktivnost. Svaka strelica ima i ime ali kao i kod imena aktivnosti ono je nedovoljno da bi se upotpunosti shvatilo značenje pa je potrebno i tekstalno opisati svaki naziv strelice.
Pravolinijska strelica Zakrivljeni segment strelice, zakrenut je pod 90 stepeni Račvanje strelica (forking) Udruživanje strelica (joining)
Slika 21. Sintaksa strelica Pravila (Rules) Pravilima se definiše način crtanja pravougaonika i strelica. Kada je u pitanju pravougaonik potrebno ga je iscrtavati punom linijom sa kvadratnim uglovima i proširiti dovoljno da bi mogao da se napiše naziv aktivnosti. Strelice je potrebno iscrtavati punom linijom, horizontalno i verikalno (zaokretati ih pod uglom od 90 stepeni, nikako dijagonalno), pritom da dodiruju spoljašnje strane pravougaonika (ne uglove) i ne treba da ulazi u njegovu unutrašnjost. Semantika grafiĉkog jezika IDEF0 ukazuje na značenje sintaksne komponente jezika i olakšava korektnost interpretacije. Interpretacija opisuje dijelove kao što su notacije za pravougaonike i strelice i meĎuveza funkcijskih odnosa.
Semantika pravougaonika i strelica Pošto IDEF0 podržava funkcionalno modeliranje, nazivi pravougaonika treba da su glagoli ili fraze, kao npr "Praćenje projekta", koja opisuje aktivnosti vezane za praćenje projekata. Pored opisa aktivnosti potrebno je definisati i njihov način nastajanja tj. koji izvori su potrebni i kakvi rezultati se dobivaju na osnovu izvedene aktivnosti. Ovo je zadatak strelica. Odnos izmedju Aktivnosti i Strelica je odreĎen pomoću strane pravougaonika (aktivnosti) na koji je Strelica naslonjena. Strelice sa lijeve strane pravougaonika definišu se kao ulazi (Input). Strelice koje ulaze u pravougaonik odozgo definišu se kao kontrole(Control).Strelice koje izlaze iz pravougaonika na desnoj strani predstavljaju izlaze (Output). Izlazi su podaci ili objekti proizvedeni od strane aktivnosti. Dakle, ulazi se preko aktivnosti transformišu u odgovarajući izlaz (Output) dok kontrole specificiraju uslove pod kojima aktivnost daje korektan izlaz. Strelice na donjoj strani pravougaonika predstavljaju mehanizme. Strelice okrenute prema gore identifikuju značenje koje podržavaju izvršenje aktivnosti. Strelice mehanizma koje su okrenute na dolje definišu se kao strelice poziva (Call arrows). Dakle, strelice na dijagramima se nazivaju ICOM jer su skraćeniva od: I Input, nešto što se upotrebljava u procesu C Control, kontrole ili uslovi na procesu, O Output, rezultat procesa i M Mechanizam, nešto što se koristi u procesu ali se samo ne uptrebljava Standardne pozicije strelica su prikazane na Slici 22.
Slika 22. Standardne pozicije strelica Vezano za pozicije strelica i uloge treba naglasiti da je potrebno da svi nazivi u pravougaoniku moraju biti označeni sa glagolskim frazama, a sve strelice moraju biti označene imenicama. Ulazna (Input) strelica predstavlja materijal ili informaciju koja se koristi ili transformiše s ciljem definisanja izlaza (output). Dozvoljava se mogućnost da odreĎene aktivnosti neće imati ulazne strelice. Kontrolne(Control) strelice regulišu odnosno odgovorne su za to kako, kada i daliće se aktivnost izvesti, odnosno kakvi će biti izlazi (output-i). Svaka aktivnost mora imati najmanje jednu kontrolnu strelicu. Kontrole su često u obliku pravila, regula, politika, procedura, ili standarda. One utiču na aktivnost bez obzira da li će biti transformisane ili upotrijebljene. Biće slučajeva kada je cilj aktivnosti da promijene pravilo, regulu, politiku, proceduru ili standard. U tom slučaju, za očekivati je da će strelice koje sadrže tu informaciju u stvari biti ulaz. Izlazne (Output)strelice su materijali ili informacije stvorene aktivnošću. Svaka aktivnost mora imati najmanje jednu izlaznu(output) strelicu. Aktivnost koja ne stvara izlaz, ne treba ni modelirati. Strelice mehanizama su oni izvori koji izvode aktivnosti a sami se ne "troše". Mehanizmi mogu biti ljudi, mašine, i/ili oprema tj. oni koja obezbjeĎuju energiju potrebnu za izvoĎenje aktivnosti. Po slobodnoj volji projektanta, strele mehanizama mogu biti i izostavljene iz aktivnosti. Strelica poziv (Call) je specifični slučaj strelice mehanizma i ona označava da pozivajući pravougaonik nema svoj vlastiti detaljniji dijagram, ali je detaljniji prikaz izveden na nekom drugom pravougaoniku u istom ili nekom drugom modelu. Više pozivajućih pravougaonika mogu pozivati isti pravougaonik na nekom drugom ili istom modelu. Imenuju se sa brojem dekompozicionog dijagrama koji sadrži pozvani pravougaonik zajedno sa brojem pozivnog pravougaonika.
KOMPONENTE MODELA AKTIVNOSTI Ka što smo prethodno rekli IDEF0 predstavlja grafički jezik za modeliranje procesa i kako možete napisati na istu temu više priča tako isto se može definisati i više modela procesa. Da bi se korektno izvršilo medeliranje izvršioce treba podijeliti u sljedeće kategorije: projektni tim koji utvrĎuje spisak osoba koje treba intervjuisati u detaljnom snimanju podsistema; radni tim za analizu procedura, upustava i dokumenata; korisnike koji daju informacije tokom detaljnog snimanja. TakoĎe, bitan element za modeliranje je i tehnika koja se koristi, a koja treba da omogući da: korisnik u potpunosti razumije "JEZIK" za komunikaciju izmeĎu korisnika i analitičara i treba da omoguće preciznu i formalizovanu SPECIFIKACIJU ZAHTJEVA tako da ih je moguće automatizovati.
MeĎutim, sa druge strane, definišu se tri ograniĉenja koja ograničavaju uspješnost modeliranja i to: stepen organizovanosti sistema koji se analizira zavisi od razraĊenosti standardnih dokumenata i procedura za njihovu obradu i distribuiranje, ograničenja vezana za korisnike su u vezi sa odbojnošću prema ideji uvoĊenja novog sistema ili mogu imati pretjerane zahtjeve i znanje sistem analitiĉara, njihova metodologija rada i iskustvo za slične sisteme. Prvo ograniĉenje vezano je za postojanje tehničko tehnološke kulture i organizovanosti analizirane firme što se ogleda u: postojanju službe koja izraĎuje organizacione propise, postojanju jedinstvenog sistema označavanja, postojanju službe za razvoj i praćenje internih standarda, poštovanju postavljenih normativa kao tehnoloških, a ne socijanih kategorija i stepenu primjene dokumenata obezbjeĎenja kvaliteta i dr. Drugo ograniĉenje vezano je za sposobnost najvišeg rukovodstva i njihovog autoriteta da se "čeličnom" disciplinom sprovedu zacrtani zahtjevi. Treće ograniĉenje želi da otkloni probleme na kojima se razmatraju praktični primjeri iz industrije. Svrha postavljenog modela Prije nego što se počne sa izradom modela potrebno je jasno definisati ciljeve koji moraju da sadrže sljedeće elemente: Zašto se proces modelira? Šta će proces da prikaže? Šta će korisnik modela napraviti sa njim? Čemu služi model korisniku? Odgovori na ova pitanja treba da pomognu fokusiranja postavljene problematike. Sljedeća pitanja za koja je potrebno dati odgovor su: Koji su zadaci na datom radnom mjestu? Koji je redoslijed izvoĎenja koraka? Kako se izvodi kontrola? Koji resursi se koriste? Dakle, potrebno je identifikovati zadatke svakog zaposlenog i shvatiti odnose izmeĎu zadataka koji treba da nam pomognu prilikom pisanja uputstava. Ugao posmatranja Prilikom modeliranja procesa mogu se razmatrati različita gledišta za rješavanje postavljenog problema i pritom se mora usvojiti jedno kompromisno rješenje kojeće se dalje koristiti. MeĎutim ta različita gledišta se mogu predstaviti korišćenjem takozvanih FEO (For Exposition Only) dijagrama samo za prikazivanje. FEO dijagrami se obično koriste za prezentaciju gdje se žele ukloniti neki detalji zbog lakšeg razumijevanja problema. Za razliku od IDEF0 grafičkog dijagrama FEO dijagram ne mora da poštuje IDEF0 pravila. Granice modela Granice modela postavljaju se prije svega da bi se znalo gdje stati sa modeliranjem. Ovaj problem se može posmatrati sa aspekta širine (definisanje elemenata koji se posmatraju) i dubine (definisanje nivoa detaljnosti). Širina modela vezana je za definisanje kontekstnog dijagrama koji se u IDEF0 notaciji označava sa A0 i prvog nivoa dekompozicije koji nosi oznaku A1. Mora se voditi računa da je potrebno definisati setove ulaza, kontrola i mehanizama koji proizvode set izlaza, odnosno potrebno je na ovom nivou uopštiti posmatranu problematiku za manje detalja.
Dubina modela definiše se niovima dekomponovanja gdje se definišu nivoi detaljnosti. Dekompozicija ide do mogućnosti definisanja programskih modula koji se mogu opisati dijagramom toka programa. Postoje tri komponente modeliranja procesa a to su: 1. dijagrami, 2. rječnik podataka i 3. tekstualni opis.
Dijagrami Dijagrami po IDEF0 metodologiji definišu se preko tri tipa: 1. kontekstni dijagrami, 2. dekompozicioni dijagrami i 3. stablo aktivnosti. Svaki prikazuje različite aspekte nivoa detaljisanosti opisa poslovnih procesa vezanih za dubinu i širinu meĎusobnih odnosa aktivnosti u modelu. Kao prvi korak koji se preporučuje u kreiranju IDEF0 modelu procesa je kontekstni dijagram. Na ovaj način definišu se okviri modela procesa. Sljedeći korak je definisanje dekompozicionih dijagrama kojima se detaljno definišu po nivoima odgovarajuće aktivnosti. Da bi se stekla slika postavljene dekompozicije kao i mogućnost sagledavanja hijerarhije akitivnosti definiše se stablo aktivnosti("node tree"). Kontekstni dijagram Kontekstni dijagram definisan je jednim pravougaonikom koji predstavlja granicu sistema koji se proučava. U i van ovog sistema teku informacije preko strelica. Kontekstni dijagram je najviši nivo apstrakcije koji se dekompozicionim dijagramima prevodi u niži nivo apstrakicije. Aktivnost A0 koja se pojavljuje u kontekstnom dijagramu opisuje okvire modela i mora biti odreĎena aktivnom glagolskom frazom kao npr. "Praćenje projekta". Preporučuje se se da se počne od definsanja izlaznih strelica pa se pomjera prema ulazima, mehanizmima i kontrolama. Polazi se od činjenice da svaka aktivnost posjeduje odgovarajuće izlaze koji se mogu identifikovati. Prilikom definisanja izlaza treba voditi računa i o negatvnim izlazima koji prouzrokuju tzv "feedback" strelice. Sljedeći elementi koji se definišu su: ulaz koji se na specifičan način transformiše (ili troši) u cilju stvaranja izlaza, mehanizam i na kraju kontrole. Na kraju je potrebno provjeriti : Da li kontekstni dijagram obuhvata aktivnosti koje se modeliraju? Da li je kontekstni dijagram konzistentan sa svrhom, uglom posmatranja i granicama? Da li strelice uspostavljaju odgovarajući nivo detalja (ne smije ih biti više od šest po tipu strelice)? Da li je model prihvaćen od svih članova grupe? Dekompozicini dijagram Dekompozicioni dijagram se sastoji od aktivnosti definisanih pravougaonicima i odgovarajućim strelicama. Aktivnosti su, kako je već rečeno, smještene u pravougaonicima koji se crtaju u dijagonalnom smjeru od gornjeg lijevog ugla strane ka donjem lijevom uglu. Svakoj aktivnosti mora se dodijeliti naziv glagolske fraze te mora imati najmanje jednu kontrolnu i jednu izlaznu strelicu. Jednistvena aktivnost na kontekstnom dijagramu na najvišem nivou može da se dekomponuje u svoje sitnije podaktivnosti kreiranjem child-dijagrama. TakoĎe, svaka od ovih podaktivnosti child-dijagrama može da se dekomponuje, svaka kreirajući svoj child-dijagram na nižem nivou. Svaki child-dijagram sadrži child pravougaonike i strelice koje pružaju dodatne detalje o roditeljskom pravougaoniku.
Child-dijagram koji je nastao kao rezultat dekompozicije pokriva isti obim kao i roditelj dijagram. Nadalje child dijagram može biti unutar roditeljskog pravougaonika. Ova struktura je ilustrovana na Slici 23. Roditeljski dijagram sadrži jedan ili više roditeljskih pravougaonika. Svaki običan (non-context) dijagram je takoĎer child-dijagarm pošto po definiciji on prikazuje detalje roditeljskog pravougaonika. Nadalje dijagram može biti i roditeljski dijagram (da sadrži roditeljske pravougaonike i child-dijagram (prikazuje detalje sopstvenih roditeljskih pravougaonika).
Slika 23. Dekompoziciona struktura
Strelice u dekompozicionom dijagramu su prenesene od roditelja koji je ovdje kontekstni dijagram i očekuju da budu povezane sa odgovarajućim aktivnostima u dekompozicionom dijagramu. Postoji vrše vrsta strelica. Strelice definisane u roditeljskoj aktivnosti (aktivnosti koja prethodi) pojavljuju se u dekompozicionom dijagramu djeteta kao graniĉne strelice (boundary arrows). Dakle, granične strelice su strelice koje se nastavljaju van okvira datog dijagrama. Ulazne granične strelice koje dolaze iz nadreĎenog dijagrama (roditeljskog) u podreĎeni (dječiji) dijagram dijele se u više specifičnih strelica i obrnuto, izlazne granične strelice iz podreĎenog dekompozicionog dijagrama se grupišu i izlaze u nadreĎeni dijagram. Unutar dekompozicionog dijagrama definišu se tzv. eksplicitne ili interne strelice koje povezuju aktivnosti. Dekompozicioni dijagram bez unutrašnjih strelica ukazuju na organizacioni pristup dekompoziciji a ne funkcionalni.
Slika 24. Organizacioni pristup dekompoziciji Strelice predstavljaju svojevrsan cjevovod koji se može granati u najmanje tri logička djeljenja. Prvo grananje može sadržati pune skupove informacija u svim granama. Druga vrsta grananja je podjela na pun skup u prvoj i poddskup informacija u drugoj grani. Treće grananje može sadržati različite podskupove informacija. Na osnovu ovoga se može zaključiti potreba definisanja naziva svake strelice da ne bi došlo do dvosmislenosti.Integracija strelica je po sličnom principu moguća i treba je obavezno koristiti.
Slika 25. Integracija strelica U prvom slučaju prikazanom na prethodnoj slici dolazi do grananja ulaza A u iste skupove informacija dok u drugom slučaju ova situacija se ponavlja za slučaj integracije strelica. U trećem slučaju B je dio od A a u četvrtom slučaju A i B se integrišu u A&B. Povratne (feedback) petlje su pojave kada izlaz iz ativnosti je ulaz, kontrola ili mehanizam neke ranije aktivnosti u dekompozicionom dijagramu. Obično ovakvi izlazi su neke negativne karakteristike.
Slika 26. Povratne petlje
Kontrola, povratna petlja i ulazna povratna petlja predstavljaju iteraciju ili rekurziju dok mehanizam povratna petlja ima ulogu podrške na nivou resursa za izvoĎenjem dotične aktivnosti. Na prethodnoj slici prikazani su načini prikazivanja povratnih petlji. Poseban tip strelica su tzv. skrivene (tunneled) strelice. Ove strelice nastaju ako se ne želi da se vide na nadreĎenom ili podreĎenom dekompozicionom dijagramu. Ovo je situacija kada je dijagram prenatrpan pa zbog jasnoće izbjegavamo njegovo prikazivanje. Druga situacija je ako se želi prikaz budućih dogaĎaja. Može biti i taj slučaj da strelica predstavlja kotrolu koja se primjenjuje na svakoj aktivnosti u dekompoziciji, te će biti propuštena radi jasnoće u nižim nivoima. Oznaka da je strelica sakrivena su zagrade. Ako je zagrada smještena na strelici odmah do pravougaonika, tada se strelica neće prikazati u dekompoziciji aktivnosti djeteta. Ako je zagrada smještena na kraju strelice, tada strelica neće biti prezentovana u roditeljskoj aktivnosti.
Slika 27. Skrivene strelice - zagrade Kao što se na slici vidi skrivene strelice se označavaju zagradama i ako su nacrtane kao u roditeljskom dijagramu (pozicija C2) onda se ne pojavljuju u dijagramu djeteta ili ako su nacrtane kao u dijagramu djeteta onda se ne vide u roditeljkom dijagramu. Postojeći (as-is) i budući (to-be) model Prilikom modeliranja procesa obično se definišu dva pristupa tj. jedan koji opisuje postojeće stanje i drugi kojim definišemo budući model procesa. Ako je velika razlika izmeĎu postojećeg i budućeg modela ponekad je potrebno napraviti treći model kojim se definišu dokumenta za potrebe prelaza sa postojećeg na budući model. Potrebno je izbjegavati prilikom definisanja postojećeg stanja zamku tipa "TREBALO BI DA" izgleda model ovako, jer se ne želi opis idelane situacije već onakve kakva stvarno jeste. Potrebno je posebno obratiti pažnju na dva aspekta prije negošto se počne sa izradom modela a to su svrha, ugao posmatranja (gledište) i okvir postavljenog modela.
Formiranje troškovnih centara Metoda IDEF0 omogućava formiranje troškovnih centara i vezu aktivnosti i troškovnog centra. Za svaku aktivnost definiše se frekvenca, dužina trajanja, i cijena te aktivnosti na najnižem nivou. Troškovi aktivnosti na višem nivou su agregirani od troškovi aktivnosti nižeg nivoa. Modelar poslovnih procasa BPwin podržava ABC (Activity Based Costing) sistem i ima intrefejs ka ABC alatima namijenjenim onima koji menadžment strategiju baziraju na aktivnostima. Stablo aktivnosti Stablo aktivnosti se definiše primjenom metode rješavanja problema odozgo na dolje (top-down). Top-down metodologijom se složena aktivnost rastavlja na više podaktivnosti, a zatim se pristupa rješavanju jednostavnih podaktivnosti. Drugim riječima, polazna složena aktivnost razvija se u hijerarhiju podaktivnosti čija je struktura tipa stabla. Korjen stabla (to je najviši čvor stabla) sadrži polaznu aktivnost, dok listovi tj. čvorovi koji nemaju potomaka, sadrže aktivnostit čije je rješavanje relativno jednostavno. Rješavanjem svih podaktivnosti iz listova riješena je i polazna složena aktivnost. Dakle, stablo aktivnosti predstavlja hijerarhiju definisanih aktivnosti očišćenu od strelica i omogućuje funkcionalnu dekompoziciju i uvid u dubinu odvijanja veza izmeĎu aktivnosti. Ovaj pristup je veoma važan kada se uspostavlja okvir poslovnih procesa koji mogu doći u razmatranje i kada se definiše njihova hijerarhijska veza. Razbijanje aktivnosti na svoju djecu mora da ima od 3 do 6 podaktivnosti. Ako se ima više od šest podaktivnosti to znači da se pokušava smjestiti previše detalja na jedan nivo. Aktivnost na vrhu ( root) je uvijek označena sa A0. Brojevi se koriste da bi prikazali koliko detalja aktivnost sadrži. Aktivnost A0 je dekompozovana - razdvojena - na A1, A2, A3, itd. A1 je dekompozovana u A11, A12, A13, itd. Integracija procesa i podataka preko rjeĉnika podataka Nakon izvršene i usaglašene dekompozicije od strane korisnika IDEF0 metod omogućuje prelaz na drugi dio razvoja vezan za definisanje entiteta i atributa kroz rječnik podataka. Rječnik sadrži definicije o svim aktivnostima i strelicama koje se u modelu pojaljuju kao i uspostavljanje veze sa izmeĎu IDEF0 (BPwin) metodologije za modeliranje procesa i IDEF1X (ERwin) metodologije za modeliranje procesa. Definicija bi trebala biti jasna pojedincu van poslovnog procesa koji je modelovan. Tokovi podataka prikazani putem strelica povezuju se sa entitetima i sa svim ili samo sa pojedinim atributima tih entiteta. Svakom entitetu se pridodaje način na koji strelica koristi taj entitet, odnosno šta radi sa pojedinim instancama tog entiteta preko tzv. CRUD matrice: C Create R Retrive U Update D Delete Svakom atributu entiteta koji je identifikovan da ga strelica koristi, odnosno, da ga upotrebljava ta aktivnost, pridodaju se tzv. IRON karakteristike: I Insert R Retrive U Update N Nullifield Na ovaj način moguće je kreirati dvije matrice: 1. CRUD matrica na kojoj bi sa jedne strane bili entiteti, a sa druge strane aktivnosti koje koriste te entitete i 2. IRON matrica sa definicijom korišćenja svakog atributa u odreĎenom enitetu i odereĎenoj aktivnosti.
Dakle, veza IDEF0 modela procesa i IDEF1X modela podataka je omogućena i vrši se preko rječnika podataka(data dictionary menagera). Na taj način (indirektnom sinhronizacijom) je dozvoljeno sinhronizovanje jednog modela podataka sa više modela procesa što se u praksi ne samo često dešava, već i preporučuje. CASE alat firme Logicworks omogućuje importovanja rječnika podataka iz ERWIN-ovog modela podataka u BPWIN-ovom modelu i obrnuto. Na taj način za model procesa postaju vidljivi podaci iz baza podataka. Prebacivanje rječnika podataka je omogućeno u oba smjera, tako da je sa stanovišta projektanta nebitno u kom trenutku je uočio potrebe za promjenama na datom modelu. U slučaju da se pojavi potreba da se definiše novi entitet ili atribut ili da se izmjeni postojeći to se može uraditi u BPWIN-u, a zatim nadograditi rječnik podataka kao vezu sa ERWIN-om. Moguće je u BPWIN-u definisati entitete ili atribute koji za model podataka ne treba da budu vidljivi. Entiteti i atributi iz rječnika podataka se pridružuju objektima koji opisuju kretanje podataka kroz procese, kao i način kreiranje, održavanja i upotrebe podataka. Cilj uzajamnog dopunjavanja modela procesa i modela podataka je provjera kvaliteta i konzistentnosti modela podataka kroz model procesa. Na taj način se uviĎa kada, gdje i na koji način se podaci iz modela podataka kreiraju, mijenjaju i koriste i da li je prava informacija na pravom mjestu u pravo vrijeme dostupna. Novidistribuirani i DataWarenhouse sistemi moraju biti podržani ovakvom biznis analizom. Tekstualni opis Tekstom se opisuje do detalja namjena i funkcionisanje svake aktivnosti u modelu. Izvještaji o modelima sečesto koriste da bi obezbijedili kompletan rezime poslovnog procesa. Izvještaji mogu opisati sve relevantne detalje do tančina, a često će razjasniti područje (obim) modela, perspektive i hijerarhiju.
4.7. UML
UML (The Unified Modeling Language) je standardni vizuelni jezik za modelovanje dominantno, ali ne isključivo, složenih softverskih sistema. Kratak istorijat jezika UML:
Od sredine sedamdesetih do kasnih osamdesetih pojavljuju se jezici za objektno orijentisano modelovanje. U to vrijeme istraživači počinju da eksperimentišu sa alternativnim načinima analize i projektovanja složenih sistema implementiranih na OO programskim jezicima.
Od 1989. do 1994. broj OO metoda raste od desetak do više od 50. Nijedna od njih ne zadovoljava uvijek sve potrebe korisnika. Pojavljuje se potreba za unifikacijom i standardizacijom.
Ističu se tri metode: OO Analysis and Design (autor je Booch), Object Modeling Technique (OMT, autor je Rumbaugh) i OO Software Engineering (OOSE, autor je Jacobson).
Sredinom devedesetih Booch, Rumbaugh i Jacobson razmjenjuju svoje ideje i počinju da razmišljaju o jedinstvenom metodu.
Oktobra 1994. Rumbaugh se pridružuje Boochu u korporaciji Rational. Tada zvanično počinje rad na jedinstvenoj metodologiji koju najprije nazivaju Unified Method i koja obuhvata koncepte metoda Booch i OMT.
Oktobra 1995. izlazi specifikacija UM, verzija 0.8.
Otprilike u isto vrijeme, korporaciji Rational pridružuje se i Jacobson i u jedinstveni pristup ugraĎuje principe iz metode OOSE.
Autori shvataju da ne treba da propisuju cijelu metodologiju, koja osim jezika (notacije i njene semantike) uključuje i proces razvoja softvera. Oni ostavljaju da svaka organizacija proces prilagodi sebi, a dalje rade samo na jedinstvenom jeziku koga nazivaju UML.
Juna 1996. izlazi specifikacija UML 0.8.
Tokom 1996. autori dobijaju komentare iz industrije na nacrt jezika UML. Organizuje se UML konzorcijum. U izgradnji UML 1.0 učestvuju mnoge značajne kompanije.
Januara 1997, predlaže se organizaciji OMG (Object Management Group) da usvoji UML 1.0 kao standard.
Jula 1997, organizaciji OMG podnosi se UML 1.1, kao dopuna prethodne verzije.
14. novembra 1997. OMG usvaja UML 1.1 kao standard.
Od tada se nadležnost nad definicijom UML-a ostavlja grupi za revizije RTF (Revision Task Force) organizacije OMG. U jesen 1998. RTF izdaje UML 1.3.
4.7.1. OSNOVNI ELEMENTI JEZIKA UML UML je jezik za OO modelovanje koji omogućuje: vizuelizaciju: UML je vizuelni, grafički jezik; specifikaciju: pomoću UML jezika formiraju se precizni, nedvosmisleni i potpuni modeli; konstrukciju: pomoću jezika UML konstruiše se softverski sistem koji se poslije može implementirati; dokumentovanje: pomoću jezika UML mogu se dokumentovati zahtjevi, arhitektura, projekat, izvorni kôd itd. Osnovni gradivni elementi jezika UML su: stvari (things), relacije (relationships) i dijagrami (diagrams). Ove elemente ćemo samo nabrojati i formalno kratko definisati, jer cilj ovog uvoda nije da se razumije značenje i način upotrebe ovih elemenata. Oni će biti detaljno objašnjeni kasnije, kako se bude ukazivala potreba za njima. Ovo je samo okvirni uvodni pregled elemenata jezika UML. Stvari Postoje sljedeće grupe stvari: strukturne stvari (structural things); stvari ponašanja (behavioral things); stvari grupisanja (grouping things); stvari označavanja (annotation things). Strukturne stvari su apstrakcije koje čine strukturni, uglavnom statički dio modela. To su:
Klasa (class) je opis skupa objekata koji imaju iste atribute, operacije, relacije i semantiku:
Interfejs (interface) je skup operacija koje definišu usluge klase ili komponente:
Kolaboracija (collaboration) je skup uloga i drugih elemenata koji saraĎuju da bi ispunili kooperativno ponašanje složenije od proste sume pojedinačnih ponašanja elemenata:
Slučaj upotrebe (use case) je opis skupa sekvenci akcija koje sistem izvršava da bi proizveo spolja uočljivo ponašanje bitno za nekog aktera:
Aktivna klasa (active class) je klasa čiji objekti posjeduju jedan ili više procesa ili niti toka kontrole:
Komponenta (component) je fizički i zamjenljiv dio sistema koji zadovoljava i realizuje skup interfejsa:
Čvor (node) je fizički element koji postoji u vrijeme izvršavanja i predstavlja računarski resurs koji, u principu, posjeduje memoriju i najčešće mogućnost obrade:
Stvari ponašanja opisuju ponašanje sistema, tj. čine dinamički dio modela: Interakcija (interaction) je ponašanje koje uključuje skup poruka koje se razmjenjuju izmeĎu objekata u odreĎenom kontekstu, da bi se ostvarila odreĎena svrha. Poruka:
Mašina stanja (state machine) je ponašanje koje definiše sekvencu stanja kroz koje objekat ili interakcija prolazi tokom svog života, kao posljedica dogaĎaja, zajedno sa reakcijama na te dogaĎaje. Stanje:
Stvari za grupisanje su organizacioni dijelovi jezika. Postoji samo jedna stvar za grupisanje - paket (package). Paket je čisto konceptualna stvar u koju se grupišu svi ostali elementi jezika. Paket:
Stvari označavanja predstavljaju komentare (note). Komentar:
Relacije Postoje četiri vrste relacija u jeziku UML: Zavisnost (dependency) je semantička relacija izmeĎu dvije stvari koja označava da se promjena jedne (nezavisne) stvari odslikava na drugu (zavisnu) stvar:
Asocijacija (association) je strukturna relacija koja opisuje skup veza, pri čemu veza povezuje instance:
Generalizacija (generalization) je relacija generalizacije/specijalizacije kod koje objekte generalizovanog elementa (roditelja) mogu zamijeniti objekti specijalizovanog elementa (potomka):
Realizacija (realization) je semantička veza u kojoj je jedan element ugovor koji drugi element ispunjava:
Dijagrami Dijagram (diagram) je grafička prezentacija skupa elemenata koji predstavlja samo jedan pogled na jedan dio modela. Dijagram ne nosi semantiku i ne sadrži elemente modela. Dijagram samo predstavlja prikaz nekih elemenata modela.
Elementi modela su, inače, grupisani u pakete. Paket sadrži elemente, od kojih neki mogu biti i drugi ugraĎeni paketi. Tako se model organizuje hijerarhijski. Paket može sadržati i dijagrame, koji samo prikazuju elemente tog, ali i drugih paketa. U jeziku UML postoje sljedeće osnovne vrste dijagrama: dijagram klasa (class diagram) dijagram objekata (object diagram) dijagram slučajeva upotrebe (use case diagram) dijagram sekvence (sequence diagram) dijagram kolaboracije (collaboration diagram) dijagram stanja (statechart diagram) dijagram aktivnosti (activity diagram) dijagram komponenata (component diagram) dijagram rasporeĎivanja (deployment diagram). UML dozvoljava pravljenje i ostalih vrsta dijagrama, prema potrebi korisnika.
4.7.2. OPŠTI MEHANIZMI JEZIKA UML Specifikacija (specification) je precizan opis sadržaja svakog elementa modela. U specifikaciji se nalazi potpuni opis elementa. Vizuelni prikaz elementa ne mora sadržati cijeli opis, već samo neke dijelove bitne za prikaz. Naprotiv, na različitim dijagramima se jedan isti element može prikazati na različite načine. Specifikacija jedina sadrži kompletan sadržaj elementa. Ukrasi (adornment) se mogu pridružiti elementima na vizuelnom prikazu da bi potpunije prikazali sadržaj elementa:
Mehanizmi proširivosti (extensibility mechanisms) jezika UML: Stereotip (stereotype) je proširenje rječnika jezika UML koji dozvoljava definisanje novih apstrakcija jezika. Element modela može se označiti stereotipom, koji kazuje da je taj element zapravo instanca specifične podvrste odgovarajuće apstrakcije definisane u osnovnom jeziku. Stereotip se označava sa riječi izmeĎu simbola << i >>.
Označena vrednost (tagged value) proširuje svojstva elemenata jezika UML i dozvoljava da se u specifikaciju elementa dodaju nove informacije. Označene vrijednosti se navode unutar vitičastih zagrada {} , kao lista specifikacija u formatu name=valuerazdvojenih zarezom. Ograničenje (constraint) proširuje semantiku elementa jezika UML i dozvoljava da se uvode nova semantička pravila ili mijenjaju postojeća. Ograničenja se zadaju izmeĎu vitičastih zagrada {} i pridružuju se nekom elementu modela.
4.8. ALATIZA PROJEKTOVANJE INFORMACIONIH SISTEMA
4.8.1. CASE ALATI
Razvojinformacione tehnologije karakteriše zaostajanje softvera u odnosu na hardver. Pomenuti nedostatak softvera, koji se često naziva softverska kriza, nastaje zbog niske produktivnosti i visokih proizvodnih troškova. Rješenje softverske krize je u iskorišćenju osobina inženjera provjerenih u praksi, i to, prije svega, metodičnosti i operativne discipline. Kao rezultat nastaje softverski inženjering koji u sebi sadrži sistematizovane i koordinirane aktivnosti potrebne pri projektovanju, implementaciji, eksploataciji i održavanju softverskih proizvoda. Daljirazvoj softverskih sistema na današnjem nivou mogućnosti računara i očekivanja korisnika, zahtjeva visokostručan rad i programiranje za svoju realizaciju. Pošto je ručno razvijanje softvera od najnižeg nivoa skupo i dugotrajno i sa ne uvijek predvidivim rezultatima, postoji potreba da se razvoj softvera olakša, zbog čega je, prije više od dvadeset godina, nastalo softversko inženjerstvo kao disciplina. Automatizacija softverskog inženjeringa na računaru se izvodi posebnim alatom, čiji je naziv CASE (Computer Aided Software Engineering). CASE alati služe za automatizaciju softverskog inženjerstva i samim tim predstavljaju osnovni alat kojim se služi projektant informacionog sistema. Prvedefinicije CASE alata su podrazumijevale da oni predstavljaju sisteme čiji su ciljevi da definišu, integrišu i automatizuju što je moguće više faza u razvoju softvera. CASE alati omogućavaju da razvijanje softvera postane više inženjerska djelatnost, a manje individualna umjetnost i umijeće. Zavisno od toga koje faze projektovanja i implementacije CASE alati pokrivaju, oni se dijele na CASE alate na višem i CASE alate na nižem nivou. CASE alati na višem nivou pokrivaju prve faze u proizvodnji softvera (analizu sistema i projektovanje), a CASE alati na nižem nivou pružaju pomoć u fazama programiranja. CASE sistem predstavlja alat koji služi kao pomoć projektantu informacionih sistema. Od efikasnosti ovog alata može da zavisi kvalitet gotovog proizvoda (informacionog sistema), tako da je projektantu veoma važno da odabere pravi alat koji će ga zamjenjivati u većini manuelnih poslova vezanih za projektovanje. Od efikasnosti CASE alata može zavisiti kvalitet gotovog softverskog proizvoda. Uspješnim korišćenjem pravilno odabranog CASE alata može se: minimizirati vrijeme i trud (koštanje) razvoja softvera, višestruko povećati produktivnost u pisanju softvera, podići nivo kvaliteta, povećati pouzdanost, standardizovati proizvedeni softver. Pored navedene podjele CASE alata na više (UPPER) i niže (LOWER), koja je ujedno i najšire prihvaćena, postoje i sljedeće dvije podjele: 1. horizontalna - vremenski: viši alati - za više faze životnog ciklusa (korisnički zahtjevi i dizajn), srednji alati - za srednje faze životnog ciklusa (implementacija - izrada) i niži alati - za niže faze životnog ciklusa (podrška eksploataciji);
2. vertikalna - po funkciji: alati za upravljanje, planiranje i procjene, tehnički alati (realizacija) i alati za podršku pojektu (skladišta, rječnici). Integrisani CASE alati (Integrated CASE ili I-CASE) čine alate koji pokrivaju više vremenskih faza i više funkcija. Primjer takvog alata je Oracle Designer/2000, koji u sebi sadržičitav niz alata baziranih na integrisanom rječniku i koji pokriva sve faze izrade jednog informacionog sistema. Alati mogu podržavati različite tehnike modeliranja poslovnih sistema, pa se i po tome mogu podijeliti. Najrasprostanjenije tehnike modeliranja su: 1. ER metodologija (ili proširena ER metodologija) po notaciji Chen-a, Bachman-a...; 2. SSA (sistemska strukturna analiza za modeliranje funkcionalnog aspekta posmatranog sistema) po notaciji Yourdon/de Marco, Gane/Sarson, Ward/Mellor; dijagrami toka programa (flow chart); funkcionalne hijerarhije (dekompozicije poslovnih funkcija); objektno-orijentisane metodologije, kao OMT i Grady Booch; dijagrami tranzicije stanja. Kvalitetu CASE alata doprinosi činjenica da mogu podržavati više tehnika modeliranja. Alati se mogu podijeliti i po filozofiji rada sa njima na: alate sa ograničavajućom (restriktivnom) filozofijom, koji najviše pomažu novim korisnicima, jer ih ograničavaju na stvari koje prvo moraju da urade; npr., da nacrtaju kontekstni dijagram u SSA metodologiji, što pruža osjećaj sigurnosti, mada, možda, malo guši kreativnost; alate sa voĎenom filozofijom, koji su pogodni za korisnike višeg nivoa predznanja i intelektualne zadatke višeg nivoa, jer sami vode korisnika i asistiraju mu u biranju operacija; alate sa fleksibilnom filozofijom koji dopuštaju potpunu slobodu korisniku, čak i da generiše nekorektan dizajn; pogodni su za korisnike koji su već u potpunosti ovladali metodologijom i hoće da alat prati njihov kreativni proces stvaranja koji ide malo metodom sa vrha - nadolje, a malo metodom sa dna - naviše. Ovakvi alati najviše vrše sintaksne provjere interno i odmah po unosu, a kasnije provjere ispravnosti (konzistentnosti) dizajna, i to isključivo na zahtjev korisnika.
Dalje gledano, CASE alati mogu biti: jednokorisnički - projekti se vode na jednom mjestu i samo jedan korisnik upotrebljava alat u jednom momentu; višekorisnički - omogućavaju komunkaciju i koordinaciju velikih timova za razvoj softvera; svima su dostupni planovi, statusni izvještaji, specifikacije, modifikacije, izvorni kod i testni podaci. Postoji još veliki broj načina na koje se CASE alati mogu klasifikovati (na primjer, po hardverskom okruženju i operativnom sistemu u kome rade, po jeziku na kome su razvijani ili po otvorenosti arhitekture), ali se ne odnose na funkcionalnost i mogućnosti nego prije na način razvoja samog alata.
4.8.2. STRUKTURA CASE ALATA Tipično CASE okruženje uključuje: repozitorijum, alate za grafičko predstavljanje, softver za definisanje teksta, softverski interfejs prema repozitorijumu, softver za procjenu i interfejs prema korisniku. Repozitorijumje aktivan rječnik podataka koji podržava definisanje različitih tipova objekata i njihovih veza. Alati za grafiĉku obradu omogućavaju razvijanje raznih tipova dijagrama, kao i ocjenu kompletnosti dijagrama na osnovu unaprijed definisanih pravila. Alat za obradu teksta omogućava definisanje naziva, sadržaja i detalja pojedinih stavki u repozitorijumu. Korisniĉki interfejs je interpreter koji odreĎuje formu podataka koju treba uzeti (grafika ili tekst). Analizator softvera je ekspertni deo CASE i on analizira ulaze kako u dijagram tako i u repozitorijum, utvrĎujući njihovu leksičku kompletnost, a i provjeravajući kompatibilnost sa ostalim objektima u aplikaciji. Korisnički interfejs obezbeĎuje interaktivnu i off-line obradu preko ekrana i izvještaja. Idealni CASE treba da omogući potpunu automatizaciju kompletnog životnog ciklusa projekta informacionog sistema, obuhvatajući početnu inicijativu, nivo analize, rad na održavanju softverskog proizvoda sve do njegovog povlačenja. Takav CASE postaje fokus za sve poslove softverskog inženjerstva, pa se rad na razvoju softvera koncentriše na logički aspekt projektovanja. Upravo zbog toga idealni CASE treba da omogući: izradu arhitekture procesa organizacije, planiranje i praćenje projekta, grupni rad na razvoju softvera, aplikativno i ručno definisanje procedura, normalizaciju podataka, generisanje sheme baze podataka, generisanje koda u korisnički odabranom programskom jeziku, automatsko testiranje generisanog koda prema specifikaciji aplikacije i ekspertnu procjenu savršenosti proizvoda, kao i način korekcije. Idealni CASE treba već u repozitorijumu da prepozna komponente koje su za ponovnu analizu, dizajn i kodiranje. Po pravilu 40-20-40, koje važi za razvoj programskog sistema, 40% projektnog vremena otpada na analizu i modelovanje, 20% je odvojeno za programiranje, a preostalih 40% za testiranje. Trend dobavljača je da se eliminiše kodiranje, što čini samo jednu petinu vremena potrebnu za razvoj softverskog proizvoda. Sadašnji trenutak zahtjeva postojanje CASE alata koji će pokriti proces testiranja, a samim tim i skratiti vrijeme izrade softverskog proizvoda. Budući CASE biće u mogućnosti da u ostatku 40% projektnog vremena identifikuje dijelove aplikacije koji mogu biti ponovo iskorišćeni. Iz navedenog se može pretpostaviti i put razvoja CASE alata, a to je efikasnije pokrivanje vremena za analizu i dizajn, kao i vremena potrebnog za testiranje.
ORACLE CASE Designer/2000 Odlika ORACLE CASE Designer/2000 alata je da su integrisani i da pokrivaju sve faze u razvoju sistema. Podržavaju koncept vodopada (Waterfall model), kao i "Spiral model" razvoja informacionog sistema. Svi alati za razvijanje dijagrama napisani su u C++ tako da je omogućeno korišćenje MSWindows biblioteka. Koncepcija ORACLE CASE okruženja se bazira na jakim radnim stanicama u Windows ambijentu i skupu alata (modelera, dijagramera, utility-ja itd.) preko kojih se pristupa zajedničkom rjeĉniku. Rječnik je baza podataka koja sadrži informacije potrebne u svim fazama razvoja sistema. Svaki podatak se u ovu bazu unosi samo jedanput, a onda se, po potrebi, referencira u svim slučajevima kada je to potrebno. Karakteristika rječnika je da je višekorisnički i da se njegova konzistentnost stalno prati procedurama za održavanje referencijalnog integriteta i alatima za konsolidaciju. Različite klase korisnika mu pristupaju kroz različite alate u pojedinim fazama razvoja sistema.
Entity Relationship Diagrammer (ERD) Dio Oracle paketa Designer/2000, koji služi za modeliranje podataka, podržava sljedeće koncepte: atribut, entitet, specijalizaciju i generalizaciju (podtipovi i nadtipovi), veze. Pri kreiranju entiteta ERD zahtjeva samo njegovo ime, a svi ostali detalji vezani za entitet, kao i definisanje njegovih atributa, mogu se kasnije obaviti kroz opciju editovanja entiteta. Poželji se atributi mogu prikazivati u okviru entiteta na dijagramu i tada postoji konvencija da se: ispred atributa koji ulaze u sastav primarnog ključa stavlja znak "#", ispred atributa koji su obavezni oznaka "*" i ispred opcionalnih atributa oznaka "o", što doprinosi preglednosti dijagrama.
Slika 28. ERD-Ekranska forma za definisanje entiteta Pri modeliranju veza meĎu entitetima zadaju se njihova opcionalnost (obaveznost veze se predstavlja punom linijom, a neobaveznost veze isprekidanom linijom (sa svake strane veze ponaosob) i njihova kardinalnost (veza sa gornjom granicom kardinalnosti 1 se predstavlja jednom tačkom dodira linije, koja predstavlja vezu i odgovarajućeg entiteta, dok se veza sa gornjom granicom kardinalnosti M predstavlja razgranatom linijom sa tri dodirne tačke).
Posebne vrste veza koje su podržane ovim CASE alatom su: prenosive i neprenosive veze (transferable i non-transferable), a odnose se na mogućnost prevezivanja jedne pojave entiteta sa drugom pojavom referentnog entiteta; spušteni ključevi, kada se kroz ovakvu vezu u ključ zavisnog entiteta uključuje kompletan ključ entiteta od koga egzistencijalno zavisi; rekurzivne veze, koje modeliraju vezu jedne pojave entiteta sa drugom pojavom istog entiteta; ekskluzivne veze, koje modeliraju situaciju u kojoj može u jednom trenutku postojati samo jedna od dvije ili više veza koje polaze od jednog entiteta.
Slika 29. ERD – primjer modela "objekti i veze” u grafiĉkom editoru Definisanje domena za ERD se vrši u Repository Object Navigator-u, alatu za direktan pristup rječniku podataka. Domeni definisani na taj način su dostupni i ostalim modulima ORACLE-ovog integrisanog CASE-a, a u ERD-u se koriste za definisanje atributa. Svaki objekat u ERD-u ima karakteristiku CREATE koju projektant mijenja u True u trenutku kada je završio dizajniranje tog objekata. Na taj način se razlikuju objekti koji ulaze u generisanje izlaza od objekata koji ne ulaze, odnosno od onih koji su još u fazi dizajniranja. Prilikom aktiviranja analizatora grešaka, objekti čiji je CREATE FLAG jednak False se ne razmatraju.
BPwin (Business Process Windows) BPwin alat za modeliranje i analizu složenih poslovnih procesa je zasnovan na konceptima standarda IDEF0. Zbog lakše identifikacije procesa i njihove optimizacije, kao i odbacivanja suvišnih procesa, nastala je metodologija modeliranja poslovnih procesa. Modeliranjem procesa se dobija ureĎena struktura sa jasno definisanim pravilima, koji se procesi odvijaju i na koji način. BPwin omogućava rigorozno testiranje konzistentnosti dijagrama. Dinamički objekti koji vode kroz model spriječavaju greške koje najčešće nastaju pri kreiranju modela. BPwin podržava ABC (Activity Based Costing) sistem i ima interfejs ka ABC alatima namenjenim kompanijama koje menaĎžment strategiju baziraju na aktivnostima. Kreiranje dokumentacije iz BPwin-ovih modela procesa je izvedeno na isti način kao i u svim alatima familije LogicWorks-a. Postoji potpuna sloboda u definisanju seta podataka iz modela aktivnosti, kao i u definisanju izgleda dokumentacije. BPwin omogućava rad u grafičkom okruženju, uz punu podršku rada mišem, tako da je editovanje modela podataka izuzetno lako; dijagrami koji se dobijaju daju potpuni prikaz modela. Dekompozicija procesa se vrši direktno na dijagramu, a kretanje po nivoima dekompozicije podrazumeva prebacivanje sa dijagrama na dijagram. Pri radu na jednom modelu otvoreni su svi dijagrami iz tog modela.
ERwin ERwin alat za modeliranje podataka je izgraĎen na konceptima koji su postavljeni IDEF1X standardom. ERwin/ERX je CASE alat namijenjen modeliranju podataka ER (Entity Relationship) metodom, koja je podržana IDEF1X (Integration DEFinition for information modeling) metoda, a korisnik može opciono koristiti i IE (Information Engineering) metodu. Modeliranje podataka obuhvata dva aspekta: logičko definisanje modela i fizički dizajn baze. Korišćenje ovog alata podrazumijeva istovremeni razvoj logičkog modela podataka i fizičko definisanje baze, što znači da nije potrebno nikakvo dodatno prebacivanje modela iz logičkog nivoa u fizički i obrnuto. U bilo kom trenutku definisanja logičkog nivoa baze, prije nego što se počne sa fizičkom definicijom baze podataka, potrebno je odabrati ciljni server. To je DBMS na kome će model biti realizovan. Izbor ciljnog servera nije definitivna stvar, što znači da se ciljni server može mijenjati. ERwin insistira na nezavisnosti modela od DBMS platforme. Server FRE (Forward and Reverse Engineering) omogućavaživu vezu ERwin-ovog modela i baze podataka. Konekcija se vrši preko ODBC drivera. Na osnovu definisanog fizičkog modela podataka može se kreirati baza na odabranoj DBMS platformi. ERwin posjeduje i modul za inverzni inženjering, koji čita sistemske kataloge postojeće baze podataka, pa na osnovu njih automatski kreira ER dijagram po metodologiji IDEF1X standarda. Oba smjera se svode na sinhronizaciju modela podataka sa bazom podataka i poreĎenje modela sa stanjem baze. Osim sa bazom podataka, ERwin može da poredi model sa SQL shemom ili drugim ERwin modelom. Model može selektivno da se sinhronizuje sa promjenama u bazi podataka u oba smjera. Omogućena je postepena nadogradnja baze podataka iz ERwin-ovog modela podataka, uz kontrolu fizičkih parametara baze podataka. Pri svakoj sinhronizaciji sa bazom, ERwin pruža detaljan izvještaj o svim promjenama nastalim sinhronizacijom. Isti model podataka se može koristiti za generisanje više baza podataka na različitim DBMS platformama, ili za konvertovanje aplikacija sa jedne DBMS platforme na drugu. ERwin/ModelMart (ili ERwin/AOS) proširen je na ERwin/ERX koji se standardno nalazi od ERwin ver, 2.6. i predstavlja prvi alat koji omogućava višekorisnički rad na modelima podataka (Workgroup). U tom slučaju je praćenje razvoja modela podataka znatno komplikovanije. Korisnici svoje promjene na modelu pohranjuju uSQL bazu podataka, smještenu na Microsoft SQL, Sybase ili ORACLEserver, gdje se vodi računa o zaključavanju modela, verzijama, ovlašćenjima korisnika i sl. ERwin je razvio set specijalizovanih verzija, kao što su: ERwin for Visual Basic, ERwin for Power Builder, ERwin for ORACLE, ERwinfor SYBASE i sl. U kreiranju specijalizovanih verzija ide se za tim da se pojača sprega sa proizvodom za koji je verzija specijalizovana. Tako, ERwin for ORACLE ima detaljniji rad sa ORACLE bazom, kao i interfejs ka ORACLE CASE-u.Rad sa ostalim DBMS platformama je na nivou ERX verzije. Verzije za Power Builder i Visual Basic imaju i proširenje koje gradi klijent-stranu aplikacije na navedenom alatu, bez obzira na DBMS u koji se baza pohranjuje. Verzija 2.6. ERwin-a obuhvata proširenje na ERwin/OPENi predstavlja generalizaciju specijalizovanih verzija ERwin-a koje tretiraju klijent-stranu aplikacije. Osim izbora servera, korisnik bira i stranu klijenta. PonuĎeni su mu Power Builder i Visual Basic. U zavisnosti od izbora klijenta, korisnik na modelu može definisati koncepte vezane za klijent-stranu aplikacije koja se oslanja na bazu podataka koju modelira. Izbor Target Client-a ne zavisi od izbora Target Servera. Logic works najavljuje i još neka proširenja kada je u pitanju klijent-strana, npr. interfejs ka Delphi-ju. ERwin/Navigator je jeftin alat koji pruža korisniku read-onlypristup modelima podataka razvijenim u Modelmart okruženju. Ovi dijagrami se mogu pretraživati i štampati i može se iz njih kreirati dokumentacija. Uz ista ograničenja je podržana i klijent-strana razvoja aplikacije. Promjene napravljene na modelu se ne mogu sačuvati.
DataBOT je proširenje za Visual Basic koje omogućava visok nivo rada sa Visual Basic-om. DataBOT je alat koji ne zavisi od ERwin-a, ali se može nadograditi na ERwin i pojačati spreguERwin-a i Visual Basic-a, bez obzira na to da li je u pitanju ERwin/ERX,ERwin for Visual Basic ili ERwin/Navigator. Da bi pokrio proces testiranja, Logic Works izbacuje novi proizvod TESTBytes koji omogućava brzo i lako kreiranje test-podataka, koji su refleksija stvarnih podataka. Na taj način je uveliko skraćeno vrijeme testiranja.
Artist Artist CASE alat je razvijan da bi se pokrio cjelokupan razvoj informacionog sistema. Alat omogućava automatizaciju prve faze u razvoju informacionih sistema, odnosno planiranje razvoja informacionih sistema, koje se zasniva na BSP (Business System Planning) metodi. Pored toga, posjeduje i model koji podržava modelovanje procesa (SSA). Modul koji omogućava modelovanje podataka podržava semantički veoma bogat model, tako da se može modelirati neki skup podataka na veoma efektan i brz način. Artist podržava sljedeće koncepte: jak entitet, slab entitet, agregaciju, specijalizaciju i generalizaciju (podtipove i nadtipove), vezu, identifikujuću vezu.
Slika 30. ERD – primjer modela "objekti i veze” u grafiĉkom editoru
Izgled atributa i opis entiteta kroz formu dati su, takoĎe, na Slici 30. Nema komandi za dodavanje, brisanje i ispravku atributa na samoj formi za opis entiteta, već se to realizuje na formi koja se aktivira komandom Attributes, nakon čega se pojavljuje forma za unos.
Slika 31. Artist CASE– ekranska forma za unos podataka o entitetu
MagiCASE MagiCASE je grafički orijentisan alat za modelovanje podataka. Zasnovan je na sljedećim konceptima: atribut, jak entitet, slab entitet, agregacija, specijalizacija i generalizacija (podtipovi i nadtipovi), veza, identifikujuća veza. U samom alatu može se mijenjati grafička prezentacija koncepata, čime je korisnik donekle osloboĎen krutih stega metodologije, što predstavlja veliki impuls u kreativnosti korisnika programa.
Slika 32. MagiCASE – primjer modela "objekti i veze" u grafiĉkom editoru
EasyCASE System Designer EasyCASE System Designer je grafički orijentisan alat za razvoj sistema koji radi samo u Microsoft Windows okruženju. Pomoću skupa modula mogu se modelirati procesi po metodologijama: Yourdan/DeMarco, Gane& Sarson, SSADM, a, isto tako, i modeliranje podataka po metodologijama: Chen, Martin Bachman, IDEF1X, Shlaer &Mellor.
Slika 33. EasyCASE – primjer modela "objekti i veze" u grafiĉkom editoru EasyCASE System Designerpodržava sljedeće koncepte: atributi (za koje se mora naglasiti da li je neki od njih običan atribut), primarni ključ, spoljni ključ, viševrijednosni ili izvedeni atribut, jak entitet, slab entitet. Dio koncepata dat je primjerom na gornjoj slici. Na sljedećoj slici data je forma za unos entiteta.
Slika 34. EasyCASE – ekranska forma za definisanje entiteta Atributi se u podmodelu moraju definisati odvojeno kao samostalan objekat, nezavisno od entiteta, nakon čega se atribut može povezati sa entitetom kome pripada. Definisanje spoljnog ključa kao tipa atributa predstavlja redundantni podatak, imajući u vidu da je pojavljivanje spoljnih ključeva definisano uspostavljenim vezama. Drugi način kreiranja atributa je preko definisanja child object-a. Aktiviranjem odreĎenog koncepta i definisanjem njegovog child object-a, kao record-a, ponuĎeno je da se definišu i njegove komponente, odnosno atributi koncepta.
Slika 35. EasyCASE – ekranska forma za definisanje atributa
Podržava generisanje šeme baze podataka za sljedeće server baze: ORACLE7,DB2, Rdb, Ingres, SQLServer, SQLBase, SYBASE,Progress, kao i sisteme za upravljanje bazama podataka na personalnim računarima: Clipper, FoxPro, dBASE, Paradox.
S-Designor S-Designor je alat za modeliranje podataka, grafički orijentisan, koji radi u okruženjuMicrosoft Windows. Osnovni elementi na kojima se zasniva su: atributi, entiteti, veze. Dio koncepata koje podržava S-Designor dat je na Slici 36.
Slika 36. S-Designor – primjer modela "objekti i veze" u grafiĉkom editoru Iako prividno siromašan (posjeduje samo jedan koncept od objekata), mogu se iskazati sve vrste koncepata koje se pojavljuju u modelu objekti-veze. Prilikom definisanja entiteta i njegovih osobina grafičke prezentacije, rad sa njim je identičan, nezavisno od toga koji se koncept predstavlja. Naziv, atributi i opisi unose se na identičan način kod svih objekata, a razlike izmeĎu njih postaju očigledne tek kada se opredijeli za vrste veza kojima se odreĎeni objekat povezuje sa ostatkom podmodela.
ADW (Application Development Workbench) ADW je KnowledgeWare-ov CASE alat sa integrisanim dijelovima koji omogućava automatizaciju životnog ciklusa razvoja informacionog sistema. Prvi dio Planing Workstation podržava definisanje objekata, kao i njihovo povezivanje preko asocijativnih matrica. Mogu se definisati organizaciona struktura i informacione potrebe, ciljevi, poslovne funkcije, kritični faktori uspjeha. Postoji mogućnost utvrĎivanja prioriteta projekata na osnovu postavljenih kritičnih faktora. Sve informacije se smještaju u centralnu enciklopediju kojoj mogu da pristupe svi dijelovi alata. Drugi dio Analisis Workstation, koji služi za modelovanje procesa i podataka, sadrži čitav niz modula za crtanje dijagrama: dijagram sastavnih dijelova, dijagram toka podataka, ER dijagram, dijagram tipova informacija, kao i akcioni dijagram. Dio RAD Workstation je alat za izradu prototipova i omogućava ispitivanje početnog dizajna aplikacija za krajnjeg korisnika. Dijelovi Design Workstation i Construction Workstation, na osnovu prethodnih informacija koje su smještene u enciklopediji, mogu izgenerisati generičke klijent/serveraplikacije relacionih i hijerarhijskih baza podataka (Oracle7,Sybase SQL Server, DB2, DB2\2, IMS, VSAM) i relacione baze koje podržavaju ANSI standard. Generatori na osnovu generičke aplikacije izraĎuju klijent/server-aplikaciju za ciljni operativni sistem (UNIX.Motif, OS/2 Presentation Manager, DOS/Windows3.x, AS/400 i MVS).
Platinum Platinum je integrisan skup alata sa mogućnošću da podrži proces razvoja informacionog sistema, prateći životni ciklus procesa. Pojedini dijelovi, odnosno moduli razvijeni su tako da podrže pojedine faze razvoja, a da, opet,čine jednu čvrstu cjelinu.
Platinum Proces Continuum pokriva aktivnosti upravljanja projektom razvoja informacionog sistema, što uključuje izbor metodologija, planiranje i praćenje projekta, kao i praćenje troškova uz mogućnost izvještavanja iz svih aktivnosti. Platinum Paradigm Plus je esencijalni dio koji podržava fazu analize i dizajna. Alat je izgraĎen tako da potpuno podrži objektnu analizu i objektno projektovanje. To je grafički orijentisan alat sa mogućnošću rada na raznim platformama i operativnim sistemima. Podržava identifikaciju poslovnih zahtjeva, izgradnju modela i komponenti aplikacije. Faza konstrukcije podržana je preko sledećih alata: Platinum AionDS Platinum ObjectPro Platinum RuleServer Platinum SQL-Station Tool Suite Veoma važna faza testiranja pokrivena je modulima: Platinum Final Exam Tool Suite Platinum Final Exam Internet Test
Slika 37. Ţivotni ciklus razvoja softverskog proizvoda Očekivani pravci razvoja CASE alata CASE tehnologija će početi da isporučuje potpuno integrisani ambijent sistema ili skup komponenti koje su integrisane sa ostalim razvijanim softverskim proizvodima. Centralna pozicija tehnologije repozitorijuma ostaće potcijenjena i uglavnom neprepoznatljiva van mjesta koji su već svjesni njenog značaja. Objektno orijentisane metode jednostavno će zauzeti mjesto postojećih metoda, jer su efikasnije; meĎutim, to će biti lagan proces. CASE tehnologija će zamijeniti 4GL tehnologiju. Konačno, očekuje se čvrsta veza izmeću CASE alata i proizvoda za razvoj desktop-aplikacija, kao što su: PowerBuilder, MS SQL SERVER, MS ACCESS, Visual Basic i drugi.
LITERATURA
1. Bošnjak K.; Latinović B., Informatika, Narodna i univerzitetska biblioteka RS, Banjaluka, 2004 2. Date C.J.: An Introduction to Database Systems, 7th Edition. Addison-Wesley, Reading MA, 1999. 3. ERwin, Methods Guide, 1995. 4. Fowler M.; UML, Mikr knjiga, Beograd, 2004. 5. Korth H.F., Silberschatz A.: Database System Concepts, 4th Edition. McGraw-Hill, New York, 2001. 6. Laudon K., Laudon J.; Management Information Systems, Pearson Education, New Jersey, 2004. 7. Lazarević B.; Projektovanje informacionih sistema, FON, Beograd, 1994. 8. Mihajlović D.; Informacioni sistemi i projektovanje baza podataka, Univerzitet u Novom Sadu, Novi Sad, 1998. 9. Radovan M.; Projektiranje informacionih sistema, Informator, Zagreb, 1989. 10. Sprague, R., H., Carlson, E., D.; Building effective decision support systems, Englewood Cliffs, Prentice-Hall, New York, 1982 11. Turban, E.; Decision support and expert systems: management support systems, Englewood Cliffs, N.J., Prentice Hall, 1995 12. Turban E., McLean E., Wetherbe J.; Informaciona tehnologija za menadžment, Zavod za udžbenike i nastavna sredstva, Beograd, 2003. 13. User Guide for BPwin. 14. User Guide for ERwin. 15. Van der Lans R.F: Introduction to SQL. Addison-Wesley, ReadingMA, 1999. 16. Varga M.: Baze podataka - konceptualno, logičko i fizičko modeliranje podataka. DRIP, Zagreb, 1994. 17. Veljović A., Menadžment informacioni sistemi, Kompjuter biblioteka, Čačak, 2002. 18. Veljović A., Projektovanje informacionih sistema, Kompjuter biblioteka, Čačak, 2003. 19. Widenius M., Axmark D.: MySQL Reference Manual. O’Reilly, SebastopolCA, 2002. 20. www.cet.co.yu 21. www.elitesecurity.org 22. www.fon.bg.ac.yu 23. www.microsoft.com
24. www.odlucivanje.fon 25. www.oracle.com 26. www.wikipedia.com 27. www.znanje.org
