Visoka tehnička škola strukovnih studija - specijalističke studije -
Programski alati za razvoj aplikacija
CASE alati kraći vodič kroz gradivo
Prof. dr Borivoje Milosevic U Nišu, 2013. godine
1
CASE alati Programski alati za razvoj aplikacija - softverski inženjering, je stroga primena inženjeringa, naučnih i matematičkih principa i metoda u ekonomi čnoj proizvodnji kvalitetnog softvera. Softverski inženjering, kao posebna disciplina, koja se bavi ekonomskotehnološkim aspektima izrade softvera, kao i svaka druga tehnologija, može se posmatrati sa dva dva aspekta: •
•
Konvencionalna (ručno programiranje, definisanje i dokumentovanje problema i održavanje održavanje sistema) Nekonvencionalna Nekonvencionalna (CASE)
Tehnike i koraci su sli čni a suštinske razlike ogledaju se u na činu kontrole, izrade i održavanja proizvoda (softvera). Kada govorimo o CASE tehnologijama ( ili programskim alatima za razvoj aplikacija , kako stoji u naslovu ), onda moramo naglasiti da prema zahtevima i potrebama, samo programiranje se vrši softverski. Sav postupak ćemo razložiti u grupe radi lakšeg pra ćenja i pojašnjenja.
Ideja CASE tehnologija: Povećanje produktivnosti u razvoju softvera pomoću softvera • •
Inženjersko projektovanje softvera pomoću računara Softverski proizvod namenjen automatizaciji izrade softvera
Ciljevi primene CASE tehnologije • • • •
Povećanje produktivnosti projektanata Skraćenje vremena izrade softvera Povećanje kvaliteta softvera Unapređenje performansi sistema
CASE tehnologija • • • •
CASE alati: hardver i softver CASE metodologija: procedure CASE enciklopedija: baza podataka Kadrovi: oni koji sve to koriste
Neki od poznatijih CASE proizvoda • • •
Cor-Vision, Cortex Corporation Promod PLUS, Promod INC Oracle CASE, Oracle Corporation 2
CASE alati Programski alati za razvoj aplikacija - softverski inženjering, je stroga primena inženjeringa, naučnih i matematičkih principa i metoda u ekonomi čnoj proizvodnji kvalitetnog softvera. Softverski inženjering, kao posebna disciplina, koja se bavi ekonomskotehnološkim aspektima izrade softvera, kao i svaka druga tehnologija, može se posmatrati sa dva dva aspekta: •
•
Konvencionalna (ručno programiranje, definisanje i dokumentovanje problema i održavanje održavanje sistema) Nekonvencionalna Nekonvencionalna (CASE)
Tehnike i koraci su sli čni a suštinske razlike ogledaju se u na činu kontrole, izrade i održavanja proizvoda (softvera). Kada govorimo o CASE tehnologijama ( ili programskim alatima za razvoj aplikacija , kako stoji u naslovu ), onda moramo naglasiti da prema zahtevima i potrebama, samo programiranje se vrši softverski. Sav postupak ćemo razložiti u grupe radi lakšeg pra ćenja i pojašnjenja.
Ideja CASE tehnologija: Povećanje produktivnosti u razvoju softvera pomoću softvera • •
Inženjersko projektovanje softvera pomoću računara Softverski proizvod namenjen automatizaciji izrade softvera
Ciljevi primene CASE tehnologije • • • •
Povećanje produktivnosti projektanata Skraćenje vremena izrade softvera Povećanje kvaliteta softvera Unapređenje performansi sistema
CASE tehnologija • • • •
CASE alati: hardver i softver CASE metodologija: procedure CASE enciklopedija: baza podataka Kadrovi: oni koji sve to koriste
Neki od poznatijih CASE proizvoda • • •
Cor-Vision, Cortex Corporation Promod PLUS, Promod INC Oracle CASE, Oracle Corporation 2
• • • • • • • • • •
Westmount I-CASE, Westmount Technology Excelerator, Intersolv INC CASE for Informix, Informix Softvare INC AD/Cycle, IBM BPWin ERWIN Rational rose MS Wisio Matlab CASE Oracle designer
Klasifikacija CASE tehnologije 1. U odnosu na: pokrivenost faza životnog ciklusa funkcija koje poseduju 2. Klasifikacija u odnosu na funkcije
Klasifikacija u odnosu na pokrivenost 1. 2. 3. 4. 5. 6.
Upper CASE – planiranje i upravljanje projektima Middle CASE – analiza i projektovanje Lower CASE – programiranje, testiranje i uvo đenje CASE tool – namenjeni pojedinim aktivnostima CASE toolkit – namenjeni pojedinim fazama ili aktivnostima u više faza CASE workbench – integrisana kolekcija CASE paketa kojom se pokrivaju sve faze
Klasifikacija u odnosu na funkcije 1. Alati za planiranje poslovnih sistema – prate informacione tokove izme đu OJ 2. Alati za upravljanje projektima – prate glavne upravlja čke aktivnosti, npr. planiranje, procena vrednosti, resurse, rizik, troškove, kvalitet, kvalitet, standarde, merenja... 3. Alati podrške – dokumentovanje, dokumentovanje, podrška sistemskom softveru, obezbje đenje kvaliteta, upravljanje bazama podataka... 4. Alati za analizu i dizajn – najvažniji alati, omogućavaju kreiranje sistema 5. Alati za programiranje – podržavaju kreiranje programskog koda 6. Alati integracije i testiranja – prikupljanje testnih podataka, analiza izvornog koda i pomoć u aktivnostima testiranja 7. Alati prototipskog razvoja – služe za izradu prototipa 8. Alati za podršku održavanju – koriste se za reverzibilni inženjering, rekonstrukciju koda i reinženjering
3
CASE Alati Od samog pocetka osnovni cilj firme bio je da se projektovanju i realizaciji poslovnih informacionih sistema priđe primenom najsavremenijih metodologija uz korišćenje CASE (Computer Aided Software Engineering) alata, u čijoj je osnovi naravno “rečnik podataka”.
Kao što i sam naziv preduze ća kazuje “metadata” tj. “podaci o podacima” u doslovnom prevodu, odnosno “recnik podataka”, “skladište podataka” u stru čnom smislu, ukazuje na to opredeljenje. U po četku izbor tih alata je bio skroman, jer su i resursi potrebni za njihov rad bili skromni. Kako se “snaga i brzina" ra čunara povećavala tako su CASE alati dobijali na svom zna čaju.
Mogućnosti CASE alata za modeliranje poslovnih podataka Modeliranje poslovnih podataka i generisanje baze podataka nekog poslovnog sistema, koja će sadržavati sve poslovne podatke važne za funkcionisanje poslovnog sistema mora biti integralan i celovit postupak. Na temelju podataka donose se odluke u poslovanju i zbog toga je važno da svi potrebni podaci budu obuhva ćeni u bazi podataka.. Modeliranje poslovnih podataka i generisanje baze podataka nekog poslovnog sistema, koja će sadržavati sve poslovne podatke važne za funkcioniranje poslovnog sistema mora biti integralan i celovit postupak. Na temelju podataka donose se odluke u poslovanju i zbog toga je važno da svi potrebni podaci budu obuhva ćeni u bazi podataka, a odnosi koji postoje u realnom svijetu moraju na isti na čin biti zabeleženi i u logici povezivanja njenih objekata. Izrada logi čkog relacionog modela podataka i automatsko generisanje relacione baze podataka sprovode se pomo ću savremenih CASE alata. Ti alati omogućavaju izdvajanje detaljnog logi čkog relacionog modela podataka kao nezavisnog «proizvoda», što poslovnom sistemu otvara mogu ćnost kontrole razvoja i implementacije poslovnih aplikacija. U tekstu je dat kratak pregled nekoliko CASE alata sa aspekta mogu ćnosti izrade logičkog i fizičkog modela podataka, i automatskog generisanja fizi čke baze podataka iz razvijenog modela.
4
i n g r t e r d a r e n e e u e m p A i d e o f t w n g o S E C
CASE
BpWin - Platinum ErWin - Platinum Oracle Designer Rational Rose - IBM Paradigm Plus Power Designer MS VISIO Adobe LiveCycle Designer COOL:Bizz
1. Uvod Razvoj informacionog sistema obuhvata celovitu i korektnu izradu rešenja za pomoć poslovanju uvođenjem informaciono-komunikacone tehnologije, koja će na najbolji mogući način podržati poslovne procese i omogu ćiti unapređenje poslovne tehnologije organizacije u kojoj se informacioni sistem razvija. Odgovornost za funkcioniranje razvijenog sistema ve ćinom pripada naručilacu, odnosno poslovnom sistemu koji finansira razvoj IS-a. Problem koji se pojavljuje kod razvoja IS-a je taj da poslovni sistem tek kad je informacioni sistem uveden može uo čiti eventualne greške i nedostatke, a to onda zna či, da sistem treba popravljati i prilagođavati. Faza prilagođenja povećava troškove uvođenja, i celokupan odnos troškova i prihoda može dobiti i negativan predznak. Kako bi se izbeglo pove ćanje troškova potrebno je razviti sistem kontrole koji će u fazama pre samog uvođenja informacionog sistema omogu ćiti naručilacu praćenje i nadzor nad postupkom. Logi čki model podataka, kako će biti prikazano u nastavku, može biti sredstvo kontrole razvoja i koriš ćenja informacionog sistema. Preduslov, koji pri tome mora biti ispunjen je da je logi čki model podataka izra đen kao posebni softverski proizvod u vlasništvu naru čilaca, inicijalno definisan u izradi SPIS dokumentacije ( Strategic Planning of Information Systems ), primenom CASE alata koji ima mogu ćnost ne samo automatskog generisanja baze podataka iz modela podataka, već i automatskog generisanja logi čkog modela iz objekata baze podataka. 2. Implementacija SPIS-a Unapređenje poslovne tehnologije organizacije je mogu će postići samo za sistem čiju poslovnu tehnologiju dobro poznajemo. Organizacioni sistemi uvek deluju radi ostvarenja unapred zadatog cilja, tako da pretvara ulazne u izlazne veli čine stvarajući pri tome dodanu vrednost. Izrađujući modele poslovnog sistema uvek možemo izraditi dva mogu ća stanja, sadašnje i budu će, unapređeno stanje.
5
U projektovanju i razvoju celovitog informacionog sistema neke organizacije možemo identifikovati tri globalne faze razvoja (slika 1). Prva faza obuhvata izradu Strateškog plana informacionog sistema [1]. Druga faza, koja podrazumeva modeliranje i generisanje baze podataka s razvojem poslovnih aplikacija i treća faza, koja podrazumeva implementaciju poslovnih aplikacija i stavljanje novog IS-a u funkciju zajedno čine sprovođenje projekta SPIS.
2.1. Realni sistem kao naru čilac IS-a Svaki realni poslovni sistem deluje na tržištu radi ostvarenja nekog unapred zadanog cilja. Savremeno orijentisane organizacije obavljanje svojih svakodnevnih poslova ne mogu zamisliti bez pomoći dobrog informacionog sistema, koji će omogućiti čuvanje potrebnih podataka i mogu ćnost njihovog korišćenja u bilo kom trenutku. Zahtevi poslovnih sistema, koji se postavljaju pred informacioni sistem sve su sofisticiraniji, detaljniji i opsežniji, a cilj je da informacioni sistem u svakom pogledu odgovara postavljenim zahtevima. Postoje dve opcije kod uvo đenja/poboljšanja informacijske tehnologije u organizaciji: kupovina gotovog rešenja ili razvoj vlastite posrške. Kriterijumi po kojima se donosi odluka o tome da li će se sistem razvijati ili kupiti vrlo su različiti. Nekad su to stvarne potrebe koje se definišu i analiziraju pa se prema tome određuju zahtevi koji se postavljaju na informacioni sistem. U tom slučaju informacioni sistem se razvija tako da bude u potpunosti prilago đen zahtevima. Nekad se odlu čuju na kupovinu gotovog sistema, naj češće nekog poznatog i već implementiranog u nekoj drugoj organizaciji, što često dovodi do prilago đavanja poslovnog sistema kupljenom proizvodu. U svakom slu čaju, realni poslovni sistem kao naručilac informacionog sistema mora se pobrinuti da zahtevi budu jasno definisani, da oni podupiru poslovanje na najbolji mogu ći način, da unaprede poslovne procese novim potencijalima i da im uvođenje ili poboljšanje informatičkih sistema pomogne u ostvarivanju ciljeva poslovanja. 2.2. Interesi i metodika rada proizvo đača softvera kao implementatora IS-a Proizvođači softvera žele prodati svoj proizvod. Njihov cilj je uvek uz što manje truda i uloženog rada prodati što više i na taj na čin ostvariti što veći profit. Većina proizvođača ima razvijenu metodiku rada i ona može biti vrlo razli čita za pojedine tipove poduzeća. Neki proizvođači imaju već razvijen velik broj različitih rešenja i u svakom novom poslu pokušavaju iskoristiti već postojeće programe. Zavisno od toga koliko su puta ista rešenja već implementirana, sam proizvod svojim imenom i referencama je više 6
ili manje prihvaćen u realnom sistemu koji proizvod naru čuje. Ako proizvod nije globalno poznat, proizvođači softvera ipak će morati prilagođavati svoj sistem definisanim zahtevima naručilaca. Međutim, i dalje stoji činjenica da će često bar deo već postojećih aplikacija kao proizvoda biti iskorišten. Takva parcijalna rešenja nadograđuju se, povezuju u ve će ili dele u manje programe.
2.3. Problemi povratne veze između naručilaca i izvođača tokom implementacije projekta SPIS-a i posledice Dva problema mogu nastati pri izvo đenju projekta SPIS. Prvi je pra ćenje proizvođača softvera, koji može na neki na čin pogrešiti u samom izvođenju baze koja u potpunosti neće odgovarati zahtevima sistema. Drugi problem nastaje zbog činjenice da je poslovanje obi čno dinamično, pod uticajem okoline, što zna či promenjivo, a prema tome mogu se menjati i potrebe za podacima. Oba navedena problema teško je uočiti pre nego što se stvarno dogode, pa se naj češće greške u sistemu primećuju tek pri implementaciji novog rešenja, odnosno u drugoj fazi izvođenja SPIS-a. Posledice koje nastaju zbog neodgovaraju će baze podataka i poslovnih aplikacija su pove ćani troškovi i otežano uvo đenje sistema. A kad se sistem jednom i uvede, on neće dati očekivana poboljšanja i rezultate. Novi ciklus poboljšanja informacionog sistema donosi i nove troškove, a na kraju sredstva koja su uložena najčešće premašuju dobitak. Poslovni sistem kao naru čilac ulaže dodatne napore i finansijska sredstva, napore koji odvla če pažnju od bitnih problema poslovanja, koje mora nesmetano raditi, iako se menja infrastruktura na kojoj radi, a to na kraju ne donosi rezultat koji je o čekivan. 3. Kontrola implementacije projekta SPIS-a Izvođenje projekta SPIS podrazumeva dve faze, kako je to ve ć navedeno na početku, a to su : modeliranje i generisanje baze podataka s razvojem poslovnih aplikacija, kao prva faza i implementacija poslovnih aplikacija i stavljanje novog IS-a u funkciju, kao druga faza. Razvoj i postojanje novijih alata za izradu logi čkog relacionog modela podataka i generisanje relacione baze podataka, omogu ćuju podelu druge globalne faze u dve relativno nezavisne podfaze projektovanja.
Prva podfaza je izrada detaljnog logi čkog relacionog modela podataka kao generatora fizičke baze podataka, a druga podfaza je izrada poslovnih aplikacija za upravljanje modeliranom bazom podataka.
Izdvajanje prve navedene podfaze projektovanja kao nezavisne faze, poslovnom sistemu otvara mogućnost kontrole razvoja i implementacije poslovnih aplikacija, čiju osnovu čini detaljni logički model baze podataka, skladno strateškom planu razvoja IS-a.[7] Smisao sistema kontrole projekta SPIS je da eventualne greške, nedostatke i dopune uočimo pre nego implementacija zapo čne. Iz tog razloga Sistem izvo đenja projekta SPIS nadograđujemo povratnom vezom unutar samog sistema i tako nastaje Sistem kontrole izvođenja projekta - SPIS. Ta povratna veza je automatski generisan novi logički model podataka direktno u elementu izrade baze podataka (prikazano na slici 2.). 7
Sistem kontrole izvođenja strateškog plana razvoja IS-a, utemeljen na generisanju i upravljanju objektom logi čkog modela baze podataka, od po četka razvoja poslovnih aplikacija do njihove kona čne implementacije ima funkciju osiguranja razvoja informacionog sistema tako da on bude nadziran, da generiše najmanje troškove i da rezultat bude informacijsko komunikacijska podrška koja će najbolje odgovarati zahtevima poslovnog sistema kao naru čilaca. Izdvajanjem logičkog modela podataka kao posebnog objekta IS-a koji se može u činiti dostupnim korisnicima IS-a, sa stajališta poslovnog sistema i njegovih korisnika može se ostvariti nekoliko važnih koristi: - stvaranje početne verzije baze podataka iz razvijenog logi čkog modela kao generatora baze podataka, koja postaje osnova za po četak razvoja aplikacija; - jačanje nezavisnosti baze poslovnih podataka od aktuelnih aplikacija; -jasnija povezanost procesa i njihovih prate ćih podataka; - mogućnost eksternog pristupa bazi podataka temeljem SQL upita izvan standardnih aplikacija; - stvaranje kreativnih ideja o potrebama dorade modela podataka i aplikacija; - manje upita korisnika usmerenih prema proizvođaču poslovnog softvera i dr. Kad se jednom izradi, model postaje jako sredstvo komunikacije izme đu poslovnog sistema kao naručilaca i proizvođača softvera kao izvo đača. Iz logičkog modela se primenom savremenih CASE (Computer Aided System Engineering) alata automatski generiše fizički model baze podataka, a na temelju njega i sama baza podataka. Neki CASE alati imaju i mogućnost ne samo automatskog generisanja baze podataka iz modela podataka, ve ć i automatsko generisanje logi čkog modela iz objekata baze podataka. Time se stvara novi nivo interaktivnog odnosa izme đu poslovnog sistema kao naručilaca i proizvođača poslovnog softvera, čiji je rezultat viši kvalitet softverskog proizvoda, kraće vreme razvoja aplikacija, kra će vreme implementacije, i niži troškovi razvoja i stavljanja u funkciju novog IS-a.[7]
8
4. CASE alati koji podržavaju SPIS i njihove osobine CASE je skraćenica punog naziva na engleskom jeziku Computer Aided Software Engineering što bi u slobodnom prevodu zna čilo računarski podržani softverski inženjering. CASE alati su programi koji omogu ćavaju automatizaciju pojedinih koraka razvoja modela informacionog sistema kroz životne faze njegovog razvoja. CASE alati obično su koncipirani tako da je u njima omogu ćena izrada različitih vrsta modela poslovnog i informacionog sistema. Snaga savremenih CASE nije u velikom broju razli čitih modela koje je mogu će izraditi, već u središnjoj riznici ili repozitoriju znanja u koji se unose opisi svih objekata korištenih u modeliranju. Osim opisa objekata ve ćina CASE alata sadrži i popis i opis svih veza izme đu različitih objekata, a te se veze održavaju u svim modelima, čime se osigurava konzistentnost i logička ispravnost modeliranog sistema. Me đutim, važno je napomenuti da kvalitet pojednog CASE alata ne zavisi od broja modela ili veli čine riznice koja modele podržava, ve ć isključivo o svrsi i na činu njegove primene. Dakle, odabrati pravi CASE alat ne zna či odabrati onaj koji ima najviše modela ili onaj koji je trenutno na tržištu najtraženiji, nego je potrebno dovoljno dobro poznavati poslovni sistem i zahteve na informacioni sistem, kako bi CASE alat na najbolji mogu ći na čin podržao njegov razvoj. U nastavku će biti dat kratak pregled tri CASE alata: Visio, COOL:bizz-a, te Erwina. Njihove osobine će biti sagledane sa aspekta koji je opisan u ovom radu, tj. sa aspekta mogu ćnosti izrade logičkog i fizičkog modela podataka, i automatskog generisanja fizi čke baze podataka iz modela i modela iz fizi čke baze podataka. Za svaki alat bi će dat kratki opis osobina samog alata i opis mogu ćnosti izrade modela podataka kroz tipi čan primer školovanja radnika nekog preduze ća. U primeru je definisano 6 objekata/entiteta i veze izme đu njih: DJELATNIK i TEČAJ vezani su ŠKOLOVANJEM, DJELATNIK je zaposlen u nekoj ORGanizacijskoj JEDnici, koja može biti deo druge, a TEČAJ organizuje neka INSTITUCIJA.
4.1. Osnovne osobine CASE alata Visio2003 Visio je CASE alat, u sklopu MS office paketa, koji u svojoj tipi čnoj instalaciji pruža mogućnosti izrade različitih modela. Svi dijagrami pripadaju jednoj od 16 kategorija, ili tipova modela. Korisnički orijentisani interfejs, jednostavno korišćenje simbola za crtanje i primeri različitih modela omogućavaju korišćenje alata i osobama koje poseduju manju koli činu znanja o projektovanju informacionih sistema. Na slici 3. prikazan je izgled po četnog interfejsa za izradu modela. Izrada modela podataka moguća je u kategoriji za izdradu dijagrama pod nazivom Database crtanjem Database Model Diagram-a. Dijagram sadrži standardne opcije za izradu entiteta, atributa
9
entiteta, ključnih atributa entiteta i različitih vrsta veza. Na slici 4. prikazan je primer Entity Relationship Model (ERA) modela izrađenog u Visio alatu.
Visio ne pruža mogu ćnost izrade repozitorija razli čitih modela, što znači da nema niti horizontalne niti vertikalne povezanosti modela. Prenos modela u druge programe omogućen je samo u svrhu prezentacije (word, excel, powerpoint) što zna či da pomoću ovog CASE alata nije mogu će niti automatsko generisanje baze podataka ni obrnuti postupak automatskog generisanja modela podataka iz baze podataka. Dakle nije moguće izdraditi model u navedenom alatu koji bi se koristio za primenu logičkog modela podataka kao sredstva za kontrolu proizvo đača softvera, kako je to opisano u ovom radu.
4.2. Osnovne osobine CASE alata COOL:Bizz COOL:Bizz CASE alat razvilo je poduzeće Sterling software 1994. godine. Mogućnosti izrade različitih modela potrebnih za oblikovanje prikaza poslovnog i informacionog sistema osobina je i ovog programa. Za razliku od Visio alata, COOL: Bizz nema toliko korisni čki orijentisan interfejs, budu ći da se dijagrami biraju sa liste i se unutar svakog dijagrama pojedini objekti tako đe biraju sa liste opcija. Iz tog razloga je ovaj alat namenjen stručnjacima koji poznaju metode i tehnike modeliranja poslovnih procesa te poslovnih podataka. Slika 5. prikazuje po četni interfejs za izradu dijagrama.
10
Snaga ovog alata odražava se kroz postojanje jednistvene riznice za sve modele jedne datoteke. Jedinstvena riznica sadrži popis i opis svih objekata koji su element bilo kog modela sadržanog u pojedinoj datoteci, ali ona tako đe sadrži i opis i popis svih veza među pojedinim objektima. Time je osigurana logi čka i formalna konzistentnost svih modela. Izrada logičkog modela podataka mogu ća je pomoću ERA (Entity - Relation Attributes) dijagrama. Dijagram sadrži standardne opcije za izradu entiteta i veza među entitetima, a za svaki izrađeni objekt postoji mogućnost unosa dodatnih svojstava kojima se oni definišu. Na slici 6. prikazan je primer ERA modela izra đenog u COOL:Bizz alatu .
Iz ERA modela moguće je automatski generisati fizi čki model podataka (DSD – Database Schema Diagram ), odnosno relacijski model koji u sebi sadrži sve potrebne elemente za generisanje fizi čke baze podataka, pokretanjem opcije «Populate from Entity Relationship Diagram».Relacijski model obuhvata i primarne i sekundarne ključeve i asocijativne tipove entiteta za rešavanje veze više-više u ERA modelu. Za svaki entitet mogu će je upisati i dodatna svojstva pa ga tako detaljnije definisati. Moguća je i povratna veza izme đu logičkog i fizičkog modela podataka. Unutar modula za izradu ERA modela potrebno je pokrenuti opciju «Populate from Database Schema Diagram». Na slici 7. prikazan je ekran iz DSD modula koji pokazuje opciju generisanja fizičkog modela podataka iz logi čkog modela.
11
Na temelju fizičkog modela podataka generiše se DDL – Data Definition Language kod, koji definiše strukturu baze podataka. Navedeni kod čita odabrani program za generisanje baze podataka i na temelju njega predefinira fizi čke relacione sheme baze podataka i veze me đu njima. Tako generisanu bazu podataka mogu će je puniti stvarnim podacima iz poslovnog sistema. Ako se tokom vremena promeni neka stavka ERA, odnosno DSD modela mogu će je sinhronizovati bazu podataka novim relacijsim shemama ili atributima. Zaključno, alat COOL:Bizz ima opciju generisanja fizičkog modela podataka iz logi čkog, i na temelju fizičkog modela generisanje baze podataka u odabranom programu, međutim opcija reverznog postupka nije mogu ća. Dakle niti COOL:Bizz, pored mnogih prednosti koje nudi kao CASE alat ne podržava koncept kontrole izvođenja SPIS projekta na temelju logi čkog modela podataka.
4.3. Temeljne značajke CASE alata Erwin ERwin alat, odnosno punim nazivom AllFusion ERwin Data Modeler razvilo je poduzeće Computer Associates International. Ovaj CASE alat služi za kreiranje i održavanje logičkog i fizičkog modela podataka te za generisanje njima pripadaju će fizičke baze podataka. Interfejs je korisn čki orijentisan, međutim rad sa ERwinom zahteva visoki nivo poznavanja postupaka modeliranja podataka. Na slici 8. prikazan je početni interfejs za izradu dijagrama.
U ERwin alatu moguće je izrađivati logički, fizički ili i logički i fizički model istovremeno. Logički model sadrži entitete, atribute koji opisuju entitete, veze me đu entitetima i primarne i sekundarne klju čeve. Fizički model sadrži informacije o fizičkoj bazi podtaka, kao što su tipovi atributa u relacijskim shemama, ograni čenja, indeksi kao veze na druge relacione sheme, denormalizirane tablice i sli čno. Logičko fizički model sadrži elemente i jednog i drugog modela. Na slici 9. prikazan je primer logičkog modela podataka izra đen u ERwin-u
12
Svaka datoteka sadrži riznicu u kojoj su zapam ćeni popis i opis svakog entiteta. Za svaki entitet postoji skup podataka o atributima koji ga opisuju (uključujući i primarni i sekundarni/e ključeve), o vezama prema drugim entitetima, o ugrađenim procedurama i okidačima za te procedure i sl. Na temelju fizi čkog modela podataka automatski je moguće generirati i fizičku bazu podataka u koju se posle toga upisuju poslovni podaci. CASE alat ERwin, za razliku od prva dva navedena alata podržava i obratnu proceduru, a to je generisanje fizi čkog, odnosno logi čko/fizičkog modela podataka automatski iz fizi čke baze podataka. Taj postupak naziva se reverzno inženjerstvo, a slika 10. pokazuje opciju u Erwinu koja to omogu ćava.
Reverzno inženjerstvo kao proces obuhvata informacije iz baze podataka o relacijskim shemama, njihovim atributima i strukturi odnosno vezama kojima su relacione sheme povezane. Posle prenosa informacija u ERwin nad nastalim modelom podataka moguće je raditi izmene koje će odgovarati promenama nastalim u poslovnim podacima ili njihovoj strukturi i ponovo sinhronizovati fizičku bazu podataka sa novim fizičkim ili logičko/fizičkim modelom podataka. Celi proces 13
moguće je i dokumentovati sistemom za izveštavanje u ERwin-u. ERwin je, dakle, CASE alat koji podupire sistem kontrole izvo đenja projekta Strateškog planiranja razvoja informacionog sistema u obliku koji je opisan u ovom radu.
5. Zaključak Strateško planiranje informacionog sistema obuhvata dugoro čno planiranje korisnog učinka IS-a i upotrebe IT u poslovanju, u sklopu strateškog planiranja razvoja poslovnog sistema kao celine, a uklju čuje rad internih stručnjaka poslovnog sistema u kojem se SPIS provodi i eksternih stru čnjaka koji poznaju metode i tehnike modeliranja poslovnih procesa i projektovanja informacionih sistema. Poslovni sistem kao naručilac i proizvođač softvera kao izvo đač imaju različite interese kod izvo đenja SPIS-a. Naručilac želi dobiti što bolji proizvod, izrađen na taj način da na najbolji mogući način i uz minimalne troškove podupire njegov rad. Proizvo đač softvera želi prodati svoj proizvod uz maksimalnu dobit i minimalne napore. Zbog toga što interesi nisu ujednačeni, često razvijeni informacioni sistem ne daje tražene rezultate. Greške i neujednačenost zaheva i rešenja koja bi trebala odgovarati na zahteve često se uoče prekasno, kad je sistem već uveden i ne podupire poslovanje na najbolji mogu ći način. Sistem kontrole izvođenja SPIS-a podrazumieva povratnu vezu unutar samog izvođenja projekta SPIS-a i time omogućava ranije otkrivanje nepodudaranja u zahevima i rešenju. Povratnu vezu čini logički, odnosno logičko/fizički model podataka, iz kojeg se automatski generiše baza podataka, ali je omogu ćen i reverzni inženjering, što znači da je moguće i iz baze podataka automatski generisati novi logičko/fizički model podataka. Neki CASE alati podržavaju opisani sistem kontrole, a u ovom radu je pokazan CASE alat ERwin kao najbolje rješenje za pra ćenje navedenog postupka. Literatura: 1. Brumec, J.: Strategic Planning of Information Systems, Zbornik radova Fakulteta organizacije i informatike, br. 2(23), Varaždin 1997, pp. 11-25. 2. Brumec, J., N.,Vr ček: Strategic planning of Information systems (SPIS), A Survey of Methodology, CIT, Vol. 10, No.3, September 2002, pp.225-232. 3. COOL:Bizz: Model manager help, Release 5.1, Sterling software, 1995-1999 4. Dobrović, Ž.: Strategijsko planiranje, poslovna i informacijska arhitektura, Zbornik radova konferencije CASE 12, Opatija 2000, pp. 60-72 5. Radošević, D.: Osnove teorije sistema, Nakladni zavod Matice hrvatske, Zagreb, 2001. 6. Uzelac, J.: Kibernetsko upravljanje poslovnim sistemima, Ekonomski fakultet Sveučilišta u Rijeci, Rijeka 2002. 7. Vidačić, S., Brumec, J., Tomičić, M.: Logical model of the database as means od informationa system usage and development control, Proceedings of the 18th International Conference on Information and Intelligent Systems IIS 2007, Varaždin, 2007. 8. www.ca.com (26.06.2007.)
14
Osiguranje kvaliteta softvera Osiguranje kvaliteta softvera obuhvata razli čite tehnike koje sve imaju za cilj da pomognu proizvodnji kvalitetnog softvera koji u isto vreme zadovoljava i polazne funkcionalne zahteve i organizacione zahteve kompanije. Ovde će biti reči o osiguranju kvaliteta softvera za vreme razvoja informacionog sistema.
Korišćenje jedne od strukturnih metoda za razvoj sistema uz podršku nekog od pogodnih alata za pisanje softvera (CASE) je od najveće važnosti za razvoj kvalitetnog softvera. Ove metode i alati omogu ćavaju rano otkrivanje grešaka što znatno pojeftinjuje postupak osiguranja kvaliteta softvera. Greške u softveru koje se ne otkriju odmah pošto se u čine kasnije je sve skuplje i skuplje otkrivati i korigovati. Na sl. 15.2 prikazana je zavisnost cene da se ispravi greška od trenutka kada je ona učinjena i ispravljena. Grafik pokazuje da će ispravljanje greške koja je u činjena u ranim fazama razvoja sistema, npr. za vreme analize specifikacija sistema, koštati sto puta više nego da je ona ispravljena u samoj fazi analize specifikacija. Ako su za vreme analize specifikacija u činjene krupnije greške softver koji se kasnije piše na osnovu takve pogrešne analize sistema je naj češće beskoristan. Možda on i funkcioniše ali ne i onako kao što je to bilo predvidjeno. Glavni metodi osiguranja kvaliteta softvera u ranim fazama njegovog razvoja su pregledi i inspekcije. Pregledi pojedinih manjih delova projektne dokumentacije koja može da sadrži rezultate analize, projektovanja i programiranja vrše periodi čno gropa sastavljena od manjeg broja ljudi (komisija) u prisustvu autora materijala. Pregledi obuhvataju: •
•
Preglede specifikacija, gde komisija traži i identifikuje greške, omaške i nejasnoće u dijagramima toka podataka, rečnicima podataka i drugim komponentama specifikacija. Preglede dizajna (projekta), pri čemu komisija studira strukturne mape i pseudokodove pojedinačnih modula 15
• •
Preglede programa, kada komisija pažljivo pregleda listinge programa. Preglede testova, kada se vrši provera testova kojima se testira softver.
Za poboljšanje efektivnost pregleda važno je da se oni zvani čno u kompaniji ustanove kao postupci za osiguranje kavaliteta softvera. Inspekcija je slična pregledima ali se oslanja na formalnije metode potrage za eventualnim greškama. Prilikom inspekcije komisija proverava dijagrame toka podataka ili samog programa služeći se pripremljenom listom na kojoj su navedene moguće greške i njeni uzroci. Obi čno jedan od inspektora izgovara na glas zna čenje pojedinih linija koda, a ostali gledaju da li ono što je napisano zaista to izvršava korektno. Testiranje je jedan od najvažnijih postupaka koji se moraju izvršiti pre puštanja novog sistema u rad. Testiranje podrazumeva da se ceo sistem ili samo neke od njegovih komponenti puste u probni rad i da se u procesu eksploatacije sistema otkriju eventualne greške. Ovaj postupak se obi čno temeljito priprema. Pre svega donosi se plan testiranja koji odredjuje redosled kodiranja i testiranja pojedinih modula sistema. Zatim se odredjuje procedura testiranja pri čemu se za svaku fazu odredjuju ulazni podaci i očekivani podaci na izlazu modula. Rezultati testiranja se pažljivo proučavaju i arhiviraju. Za potrebe testiranja softvera postoji niz kvalitetnih alata koji povečavaju efektivnost procesa. Kod testiranja softvera razlikuju se pet nivoa: •
•
•
•
•
Testiranje modula - pošto se moduo kodira, vrši se njegov pregled i testiranje sa unapred odredjenom procedurom Testiranje integracije – kada se svi moduli kodiraju i individualno testiraju integrišu se u program. Proces integracije se vrši tako što se u celinu uklju čuju jedan po jedan moduo i tako delimično formirani program sa ograničenom funkcionalnošću se testira. Postupak se nastavlja sve dok se ne integrišu svi moduli. Sistemsko testiranje – sistem se provera u odnosu na specifikacije koje definišu njegovu funkcionalnost i to u okruženju i pod uslovima koji odgovaraju onima koje će važiti u praksi. Vrše se provere na maksimalno opterećenje sistema kao i na kompatibilnost sistema u odnosu na sisteme u njegovom okruženju. Procedure za kontrolu i oporavak iz vanrednih situacija se takodje testiraju. Isto tako kao što se testira sistem tako se kontroliše i proverava njegova prateća tehnička dokumentacija. U sistemsko testiranje softvera spada i tzv. beta test koji se koristi da bi se otkrile greške u ranim izdanjima softvera. Takav još potpuno neprovereni softver daje se odredjenim korisnicima koji ga kroz praksu testiraju. Kompanija čiji je taj softver proizvod sakuplja primedbe i zamerke korisnika i tek nakon ispravke uočenih grešaka izdaje komercijalnu potpuno testiranu verziju softvera. Atestiranje – sistem se testira da se proveri da li su zahtevi svih korisnika zadovoljeni. Pri tome se promenjuje više testova od kojih svaki proverava odredjeni aspekt funkcionisanja sistema. Svi rezultati testiranja beleže se i arhiviraju. Instalaciono testiranje – ako je atest vršen pre nego što je sistem instaliran i pušten u rad potrebno je izvršiti završno atestiranje, ali ovog puta u realnom okruženju. Tek posle toga sistem je spreman za rad naravno ako je testiranje prošlo bez problema. 16
15.5 Prelazni režim Posle izvršenog atestiranja novog sistema mora se po četi planirani prelazak sa starog na novi sistem. To se može uraditi na četri načina koji su prikazani na sl. 15.3. Paralelna konverzija je najsigurniji prelazni postupak. Stari i novi sistem rade istovemeno sve dok se ne stekne dovoljno iskustva sa novim sistemom kada se stari gasi. Mana ovog postupka je što je obi čno skupo imati dva sistema u paralelnom radu. Direktna konverzija sa starog na novi je najrizi čnija i naravno zbog toga najskuplja. Ovaj postupak podrazumeva da se u jednom trenutku stari sistem potpuno zameni novim. Postepena konverzija zamenjuje stari sa novim sistemom po fazama koje su odredjene ili hardverom ili organizacionim i funkcionalnim podelama u kompaniji. Pilot konverzija isto tako postepeno zamenjuje sisteme pri čemu se na početku uvodi samo jedan deo novog sistema koji služi kao ogledni primer. Na osnovu po četnog iskustva dalja konverzija sistema se izvodi lakše. Završna faza razvoja sistema se obavlja za vreme njegove eksploatacije. Cilj ove faze koja se nazva postimplementaciona faza je da proceni kako karakteristike sistema u operativnom stanju tako i u celokupan postupak razvoja.
15.6 Održavanje Informacioni sistemi u eksploataciji se moraju održavati. Održavanje podrazumeva proces modifikovanja informacionog sistema da kontinualno zadovolji zahteve koje postavljaju kompanija i korisnici. Postoji velika razlika izmedju održavanja hardvera i softvera kako u ceni tako i u zadacima. Zadatak održavanja hardvera je da obezbedi punu funkcionalnost svim uredjajima u sistemu. Obično se ovaj deo održavanja poverava serviserima kompanije čija je oprema kupljena. Sistemsko održavanje 17
podrazumeva održavanje aplikativnog softvera. Održavanje aplikativnog softvera obuhvata svako modifikovanje softvera koje se radi posle njegove prvobitne instalacije. Cena ovih modifikacija obi čno dvostruko prelazi cenu razvoja te iste aplikacije (Na slici 15.4 to je simboli čno prikazano santom leda, gde se iznad vode vidi samo vrh sante koji je daleko manji od dela ispod vode).
Održavanje softvera zapravo se sastoji iz tri aktivnosti: •
•
•
Usavršavanje – poboljšavanje i modifikovanje sistema tako da zadovolji nove zahteve korisnika i nove potrebe kompanije. Adaptacija – promena aplikacija zato da bi se one prilagodile na nove hardverske i softverske platforme. Korekcija – ispravljanje gršaka koje su otkrivene prilikom eksploatacije sistema.
Postupak održavanja softvera ide u tri faze. Pre svega da bi se softver modifikovao njegova struktura se mora razumeti da bi se identifikovali moduli koje je potrebno menjati. Sama izmena koda modula mora se izvršiti tako da te promene ne utiču na ostatak sistema. Posle svake izmene svaki moduo se mora ponovo testirati i to prvo izdvojen iz sistema, a zatim i u okviru celog sistema. Održavanje softvera je skupo jer ga je teško razumeti naro čito ako je slabo dokumentovan ili je pak zastareo. Ovaj drugi problem se javlja naro čito ako je softver pisan na nekom od programskih jezika koji se više ne koriste u savremenoj praksi. U tom slučaju broj znalaca tih programskih jezika se drasti čno smanjuje. Drugi razlog skupoće održavanja softvera leži u potcenjivanju ljudi koji održavaju sistem i njihovog posla. Još uvek se smatra da je posao razvoja „plemenitiji“ od posla održavanja. I treći razlog je najčešće veliki broj promena koje je potrebno izvršiti u softveru da bi on bio ažuriran prema potrebama kompanije i korisnika.
18
15.7 Tehnologije koje pomažu razvoj informacionih sistema Dve relativno nove tehnologije obe ćavaju da poboljšaju produktivnost razvoja informacionih sistema i poboljšaju njihov kvalitet. To su: Alati za dizajn softvera pono ću računara - CASE (Computer-Aided Software Engineering). CASE alati automatizuju mnoge faze razvoja softvera Objektno-orijentisani dizajn (OOD – Object-Oriented Design). Njegova glavna karakteristika je da omogu ćavaju ponovno korištenje ve ć napisanog softvera (software reuse). Služeći se ovim postupkom inženjer softvera piše softver u vidu komponenti koje se arhiviraju u softverske biblioteke i koje se kasnije po potrebi mogu ponovo koristiti. CASE alati pomažu inženjerima softvera i programerima da planiraju, analiziraju, dizajniraju, programiraju i održavaju informacione sisteme. Glavna prednost ovih alata je što oni nude sveobuhvatnu pomo ć ljudima koji se bave razvojem softvera. Najbolji CASE alati pomažu korisnicima prilikom izrade kompletnog seta specifikacija zahteva, sa svim dijagramima toka podataka i definicijama svih entiteta koji se smeštaju u rečnik podataka. Neki od njih idu i dalje i pružaju mogu ćnost kreiranja strukturnih mapa sistema. CASE alati su bazirani na: poznatim metodologijama za razvoj softvera (strukturna metoda), programskim jezicima četvrte generacije tzv. neproceduralnom programiranju i grafi čkom korisničkom interfeisu (GUI). Važno je napomenuti da CASE alate ne čine samo alati koji pomažu u prvim fazama razvoja sistema kao što su analiza i projektovanje (sl. 15.5). U CASE alate ubrajaju se i generatori koda čiji je zadatak da popune i završe program koji je dat samo okvirno. Ovi alati su naro čito pogodni za brzi razvoj sistema metodom izrade prototipa. Pomoću njih se prvo brzo izradi korisnički interfeis i specificiraju se izgledi ekrana kao i format izveštaja koji su predvidjeni za štampanje i sve to u kooperaciji sa korisnicima sistema. Zatim generator koda, koji je deo CASE alata, automatski izradi potreban programski kod.
19
Glavni deo CASE lata predstavlja tzv. informatička arhiva. To je centralna baza podataka u kojoj se skladište re čnici podataka. Dakle, ona sadrži sve informacije o sistemu koji se razvija kao što su npr. po četni planovi, entiteti koji se pojavljuju u dijagramima protoka podataka, programe, pa čak i podatke o menadžmentu tog razvojnog projekta. CASE alati olakšavaju snalaženje u masi podataka tako što prate relacije izmedju pojedinih dokumenata. Na primer, oni su u stanju da odmah povežu programski kod sa onim delovima analize i projektovanja koji se odnosi baš na taj programski kod. Isto tako CASE alati automatski proveravaju kompletnost i konzistentnost svih proizvoda razvoja sistema. To omogućava da se sistem modifikuje u bilo kojoj fazi razvoja bez bojazni da će modifikacija uneti nekonzistentnost. Ovi alati značajno poboljšavaju održavanje sistema. Pre svega, oni pomažu pri dokumentovanju softvera i celokupnog procesa razvoja. Svaka naknadna promena u zahtevima korisnika može se propagirati sa nivoa specifikacija zahteva, preko DFD dijagrama do odgovarajučih programskih modula. Neki složeniji CASE alati podržavaju tzv. inverzno inženejerstvo. Po četni dokumenat kod inverznog inženejerstva je program pomo ću koga se može eventualno do ći do specifikacija sistema. Ovaj postupak je naro čito koristan onda kada se poseduje programski kod ali se nezna na šta se on odnosi. Zadatak inverznog inženjerstva je da otkrije specifikaciju početnih zahteva. CASE tehnologija je znatno doprinela ubrzanju proizvodnje softvera. Ipak to je složena tehnologija čija upotreba zahteva obrazovane korisnike. Ta složenost CASE alata doprinela je da oni još nisu toliko prihva ćeni u kompanijama koliko bi trebali sudeći samo po njihovim performansama. Objektno-orijentisani razvoj sistema (OOD) koristi model zasnovan na objektima koji odgovaraju entitetima realnog sveta. Svaki objekat modela nosi u sebi atribute i metode. Atributi su karakteristike objekata, a metodi su na čini kojima se mogu menjati vrednosti nekih od atributa. Svi objekti su samo instance klasa koje genaralno opisuju objekte. Dakle, pomo ću objektno-orijentisanog razvoja sistem se opisuje kao skup objekata koji medjusobno deluju. Pored toga što pri opisu sistema koristi analogiju realnog sveta prednost objektno-orijentisanog razvoja je i u tome što omogućava formiranje biblioteka kako softverskih komponenti tako i komponenti specifikacija. Pomoću ovih biblioteka projektanti mogu graditi nove sisteme koriste ći stare komponente. Sa OOD olakšan je prelaz izmedju faza razvoja sistema je re se i analiza i dizajn i programiranje koristi istom objektno-orijentisanom metodologijom. OOD je posebno pogodna za razvoj grafi čkih korisničkih interfeisa, kompleksnih aplikacija na bazi klijent server arhitekture gde se razli čiti objekti mogu dodeljivati ražličitim procesorima kao i multimedijskih aplikacija koje sadrže objekte razli čite prirode kao što su tekst, zvuk, slike i video.
15.8 Upravljanje IS projektima Upravljanje velikim softverskim projektima ima tri aspekta: procena napora i sredstava koje treba uložiti da bi se razvio sistem, planiranje projekta i organizovanje razvojnih timova. Generalno govoreći projekti se započinju sa relativno malim brojem ljudi u početnim fazama razvoja sistema. Za vreme faze programiranja i testiranja znatno se povećava broj učesnika u projektu. U kasnijim fazama opet dolazi do smanjivanja broja ljudi koji su na projektu. Za odredjivanje potrebnog vremena za razvoj sistema 20
kao i troškova postoji nekoliko metoda. Pre svega gruba procena se može izvršiti na osnovu uporedjivanja sa prethodnim ve ć završenim sličnim projektima. Kao alternativa može se prvo odrediti kriterijum ili mera za procenu veličine projekta pa sa njome izmeriti razvojni projekat. Jedna od mera koja se češće koristi je broj linija koda. Treći način procene koristi se tzv. funkcionalnim ta čkama u ranoj fazi razvoja sistema. Procena troškova i vremena se vrši na osnovu broja i složenosti ulaza u sistem, izlaza iz sistema, upita ka bazama podataka ili pak broju tabela ili fajlova u sistemu. Kada se procene potrebno vreme, trošak i resursi za razvoj sistema onda se pristupa izradi vremenskog plana ili rasporeda projekta. Projekat se podeli u faze koje se dalje mogu deliti na podfaze i pojedina čne aktivnosti. Glavne aktivnosti se završavaju kada su postignuti glavni ciljevi koji obi čno rezultuju u izradi nekog dokumenta bilo da su to specifikacije bilo programski moduli. Glavne tehnike koje se pri tome koriste su PERT metoda i gantogrami. PERT/CPM metoda koja svakoj aktivnosti dodeljuje odredjeno trajanje i redosled. Ceo projekat se može prikazati mrežom aktivnosti koje po činju i završavaju se sa nekim od glavnih dogadjaja. Ovi mrežni dijagrami nose informaciju o trajanju aktivnosti i njihovim relacijama. Na osnovu PERT metode može se proceniti ukupno vreme potrebno za završetak projekta i vremena po četka i završetka pojedinih aktivnosti. Isto tako PERT dijagram ukazuje koje su aktivnosti kriti čne (one koje se moraju završiti tačno u roku da ne bi ko čile ceo projekat) i koliko nekriti čne aktivnosti mogu kasniti. Gantogrami su grafički način prikazivanja rasporeda aktivnosti razvojnog projekta. Informacije koje se mogu dobiti pomo ću gantograma nisu toliko opsežne kao one koje nose PERT dijagrami. Ipak gantogrami koji aktivnosti prikazuju u vidu bar-grafika se često koriste, naročito kod jednostavnijih projekata sa manje aktivnosti, jer su lako razumljivi. Večina softverskih projektnih zadataka iz oblasti razvoja i održavanja izvode se pomoću projektnih timova. Sastav projektnih timova varira od faze projekta koji se izvršava kako u broju tako i po profesijama ljudi koji su zastupljeni. Na po četku razvoja tim čine uglavnom sistem analiti čari dok se pri kraju on sastoji pretežno od programera. Ustanovljeno je da timovi ne smeju biti brojniji od deset ljudi, zato što razvoj informacionog sistema kao vrlo složenog proizvoda zahteva izuzetnu komunikaciju i koordinaciju izmedju članova tima. Ovde će biti spomenute dve organizacione strukture projektnog tima koje pretstavljaju ekstremne krajnosti. Najčešće se u praksi organizacija timova vrši po nekom srednjem modelu, koji predstavlja kombinaciju dva osnovna modela.
Strogo hijerarhijski organizaovan tim •
•
•
Vodja projekta je obično izuzetan stručnjak u oblasi razvoja informacionih sistema, tzv. glavni programer, koji li čno definiše specifikacije po četnih zahteva i programira glavni deo softvera Njemu pomažu ostali članovi tima medju kojima su pomoćni programer, glavni administrator koji je odgovoran za menadžerski aspekt projekta, softverski bibliotekar koji je odgovoran za dokumentaciju i verzije softvera i drugi članovi tima, uglavnom programeri. Svi članovi tima odgovaraju neposredno glavnom programeru, vodji projektnog tima. 21
Ovakav način organizovanja je naročito pogodan za velike projekte koji koriste poznate tehnologije, dakle, za klasi čne razvojne projekte.
Demokratski tim •
•
• • •
•
Svi članovi tima imaju istu odgovornost za odvijanje projekta i odnosi izmedju njih su neformalni. Komunikacija izmedju članova ovakvog tima je mnogo ve ća nego izmedju članova hijerarhijskog tima. Članovi tima imaju zaduženja koja im se po potrebi mogu zameniti drugima. Često se odluke donose konsenzusom. Kako je vrsta posla jako dinamična važno je d a se sa čuva tzv. grupna memorija. Vrlo je važna uloga biblotekara projekta koji održava sve informacije o projektu.
Ovakav način organizovanja mnogo je bolji kod manjih projekata koji koriste nove tehnologije, dakle, kod istraživa čkih projekata.
22
SKLADIŠTENJE I ANALIZA INFORMACIJA U TELEKOMUNIKACIJSKOJ KOMPANIJI 1. BAZE PODATAKA Unaprijeđenje odnosa sa korisnicima ne može se zamisliti bez postojanja sveobuhvatnih baza podataka o korisnicima. Danas takve baze podataka o korisnicima predstavljaju marketinške investicije praktično u svim djelatnostima, što iz osnova mijenja do sada dominantne marketinške koncepte. Baza podataka korisnika postaje ključni i nezaobilazni faktor bez koga se ne može zamisliti moderni marketinški prilaz korisnicima. Pritom, ta baza predstavlja mnogo više od samog spiska imena korisnika i njihovih adresa. Moderna baza podataka je pravi rudnik dragocjenih i nezamjenjivih informacija o korisnicima. Cilj je da se uspostavi i održava stalna, obimna i veoma lična komunikacija sa korisnicima, a da se sve prethodno prikupljene informacije upotrijebe u svim kasnijim kontaktima, na obostranu korist. Ovakve baze podataka ne služe samo tome da se u njih sliva ogroman broj podataka i informacija, ve ć da se na osnovu njih vodi individualizirana komunikacija sa korisnicima koja će, u krajnjem slučaju, dovesti do pove ćanja prodaje. Postojanje baze podataka korisnika danas ne predstavlja konkurentsku prednost, ali je sigurno da njeno nepostojanje kompaniju nesumnjivo stavlja u inferioran položaj. Da bi se stekla takva vrsta znanja o korisnicima potrebno je da se razumiju potrebe individualnih korisnika, da se sa njima održava stalni dijalog, da se zapamti svaka njihova želja, ideja ili primjedba. Raznovrsnost informacija koje ulaze u bazu je ogromna. Baze podataka korisnika vode ka stvaranju i pove ćavanju onoga što se može nazvati dugoro čnom vrijednošcu korisnika (LTV - lifetime value), koja treba da bude strateško marketinško opredjeljenje modernih kompanija, jer je cilj da se uspostavljanjem dobrih odnosa sa korisnicima oni čvrsto vežu za kompaniju.
2. DATA WAREHOUSE Kao glavna osnova za sistem podrške odlu čivanju (DSS) koristi se analitička baza podataka, punjena iz mnogih operacionalnih sistema, poznata pod nazivom Data Warehouse, čija je jedna od primarnih funkcija da odražava procese i pravila poslovanja cjelovite kompanije. Jedan vid analitičke baze podataka jeste mart podataka. Za razliku od Data Warehouse čija je jedna od osnovnih funkcija da odražava procese i pravila poslovanja cjelovite kompanije –, mart podataka odražava pravila poslovanja unutar jedne funkcije, jednog poslovnog procesa ili jedne poslovne jedinice, pri čemu ta pravila treba da budu usaglašena sa pravilima poslovanja cjelokupne organizacije.
23
Slika 11. Data Warehouse okruženje Martovi ( trzište ) podataka mogu da budu upotrijebljeni za eksploraciju, data mining, upravljane upite ili online analitičku obradu podataka (OLAP) i predstavljaju direktni izvor podataka kojima krajnji korisnici pristupaju. Mart podataka koji se koristi za online analitičku obradu podataka zahtjeva lak i brz intuitivni pristup krajnjim korisnicima, a dimenzionalni model je najpodesniji za zadovoljavanje tog zahtjeva. Izrazom “On-Line Analytical Processing” (OLAP) ozna čena je kategorija softverske tehnologije koja omogu ćcava korisnicima (analitičarima, menadžerima) da steknu uvid u podatke kroz brz, konzistentan, interaktivan pristup razli čitim mogućim pogledima na informacije transformisane iz sirovih podataka da bi odrazile stvarnu dimenzionalnost poslovanja kako ga shvata korisnik.
Slika 12. Uloga OLAP-a Unaprijeđenju Data Warehouse i OLAP vodila je potreba za postavljanjem ad hoc, fleksibilnih, poslovno usmjerenih upita na koje raspoloživi podaci sadrže odgovore. OLAP sistemi su zasnovani upravo na multidimenzionalnom pogledu na podatke, posjeduju sposobnost da “svrdlaju” kroz podatke i omogu ćavaju analitičarima da iz raznih perspektiva gledaju podatke u bazi. Pošto je multidimenzionalni pogled hijerarhijski, analitičar može da gleda na informacije iz 24
hijerarhijske perspektive. Ova hijerarhijska struktura omogu ćava segmentaciju u bazi – određivanje podskupova (“dicing”) prema kriterijumu navedenom u upitu, rotaciju (“data slicing”), agregaciju ili disagregaciju multidimenzionalnih podataka radi predočavanja viših ili nižih nivoa u analiti čkoj hijerarhiji (“drill-up”, “drill-down”) i dr. Sistemi poslovne inteligencije omogućavaju multidimenzionalnu analizu, on line analitičku obradu podataka, kao i “rudarenje” podataka (data mining) kojima se menadžeri mogu koristiti da bi stekli odgovore na znacajna pitanja (pri cemu je od izuzetne važnosti postavljanje pravih pitanja) i doznali zna čajne trendove “skrivene” u velikim zbirkama podataka. Medu najvažnije ciljeve poslovne inteligencije (BI) spadaju identifikovanje i anticipacija stvarnih povoljnosti i nepovoljnosti u okruženju organizacije, što je naro čito značajno za strategijsko upravljanje. Primjetno je da sistemi poslovne inteligencije (BI) evoluiraju ka Web aplikacijama, što korisnicima omogućava istraživanja posredstvom Web pretraživa ča, kao i rad sa udaljenih lokacija. Da bi neka kompanija bila uspješna i dobro se razvijala, neophodno je valjano (u prvom redu strategijsko) upravljanje organizacijom i njenim procesima. Za valjano upravljanje organizacijom i procesima u njoj, neophodno je donošenje pravih odluka. Za donošenje pravih odluka neophodne su prave (relevantne, pouzdane, konzistentne) i pravovremene informacije. Za raspolaganje pravim i pravovremenim informacijama, neophodni su: kvalitetni, zna čajni, pouzdani, ta čni, konzistentni, analizi lako dostupni podaci (što se u znatnoj mjeri postiže posredstvom Data Warehouse), kao i kvalitetne analize kojima se crpe informacije iz tih podataka (posredstvom on line analiti čke obrade podataka - OLAP, data mining i dr.).
25
3. METODOLOŠKI OKVIRI PROJEKTOVANJA GRADNJE SISTEMA DATA WAREHOUSE I PODUHVATA DATA MINING U TELEKOMUNIKACIJSKOJ KOMPANIJI Gradnjom Data Warehouse razvijaju se takvi informacioni resursi organizacije koji obezbjeđuju integrisane, konzistentne podatke neophodne za efektivno i efikasno zadovoljavanje dinamičnih potreba za informacijama u upravljanju kompanijom i njenim procesima. Gradnjom DW kompanija sakuplja svoje podatke i smješta ih u jedno skladište na način koji omogućava laku i brzu dostupnost podataka, kao i njihovu podložnost odgovaraju ćem analiziranju s ciljem sticanja potrebnih relevantnih novih informacija.
Slika 13. Priprema podataka
Slika 14. Data Warehouse - tokovi podataka Pošto su veliki skupovi podataka, kao DW, nepodložni analizi tradicionalnim tehnikama, u tu se svrhu koriste novi metodi i sistemi za ekstrahovanje zna čajnih, vrijednih informacija iz velikih skupova podataka; za tu svrhu su podesni OLAP (On Line Analytical processing) i data mining. Posredstvom OLAP analiti čar ima mogucnost da postavlja upite i da na osnovu odgovora na njih izabira nove upite krećući se tako kroz veliku zbirku podataka DW i crpe ći informacije iz njih. U data mining se koriste tehnike iz oblasti statistike, baza podataka, vješta čke inteligencije, mašinskog učenja... Data mining je automatizovani analitički proces oblikovan za efektivnu i efikasnu eksploraciju u velikim zbirkama podataka sa ciljem doku ćivanja, validiranja i crpljenja vrijednih, informacija koje se ti ču novih, dotad neznanih cinjenica. Data warehouse, OLAP i data mining sa činjavaju trojstvo kojim se omogućavaju efektivnija i efikasnija rješenja problema - pored ostalih i strategijskog odlučivanja. Kompanije zavise i sve više će zavisiti od integriteta, pouzdanosti, bezbjednosti, primjenljivosti svojih informacionih sistema, procesa i podataka u kompaniji kao cjelini. Informacije dokučene iz raspoloživih podataka organizacije posredstvom data mining jesu i biće od neprocjenjive vrijednosti za usmjeravanje kako reaktivnog i aktivnog, tako i proaktivnog ponašanja kompanije. 26
4. ALATI ZA EKSTRAHIRANJE, TRANSFORMACIJU I PUNJENJE PODATAKA To su alati koji omogućavaju (kako im i samo ime kaže) da se podaci u čitaju u skladište. Funkcionalnost koju takvi alati naj češće podržavaju je transparentan dostup do svih relacijskih baza podataka bilo direktno ili putem ODBC-a, te mogu ćnost učitavanja i nerelacijski strukturiranih (legacy) podataka. Tako đe na vizualan na čin prikazuju procese koji se odvijaju prilikom učitavanja podataka u skladište, te pohranjuju te podatke u obliku metapodataka. Često
imaju i sučelje prema nekom od alata za dizajniranje baza podataka (ERwin, Oracle Designer), a omogu ćavaju i da se pojedini procesi u čitavanja podataka definiraju kao batch procedure i vrše u vrijeme kada sistem nije optere ćen upitima korisnika. Najčešće su vrlo usko integrirani s repozitorijem (Repository) u koje se podaci odlažu, te s alatima koji čine nivo administracije metapodataka (Metadata Administration Layer), tako da omogu ćavaju da se proces od izvornih podataka do kreiranja tablica za izvještavanje odvija u jednom slijedu bez upotrebe raznih sucelja.
5. KOPANJE PODATAKA -DATA MINING Kopanje podataka se može opisati kao netrivijalan proces identifikacije neospornih, novih, potencijalno korisnih i razumljivih uzoraka (eng. patterns) i odnosa (eng. relationships) među podacima u skladištu podataka. Ima više modela i algoritama koji se koriste, te se ovisno o primjeni odabire najpogodniji. Današnja tehnologija omogućava automatizaciju procesa kopanja podataka, njihovu integraciju u skladišta podataka i predstavljanje podataka. U okviru upravljanja odnosom s korisnicima kopanje podataka igra zna čajnu ulogu pri segmentaciji korisnika. Najpoznatije metode kopanja podataka su: klasifikacija i regresija (algoritmi neuralnih mreža i stabla odlučivanja), klasteriranje (identificiranje i grupisanje sličnih podataka), sažimanje i vizualizacija, modeliranje zavisnosti, asocijacije i sekvencijalna analiza (analiza potroša čke košarice) te analiza vremenskih serija. U literaturi se često koristi i sinonim Otkrivanje znanja u bazama podataka (Knowledge Discovery in Databases). Namjena kopanja podataka je kreiranje modela ponašanja korisnika na osnovu njihovih proteklih aktivnosti. Današnja tehnologija omogu ćava automatizaciju procesa kopanja podataka, njihovu integraciju u skladišta podataka i predstavljanje podataka. U okviru upravljanja odnosom s korisnicima kopanje podataka igra značajnu ulogu pri segmentaciji korisnika. Skladište podataka, ne samo da predstavlja veliki skup podataka i informacija, već mora omogućiti upotrebu analitičkih sredstava koji omogućavaju: • • •
otkrivanje uzoraka predviđanje ponašanja korisnika izradu analize tržišta
27
Slika 15. prikazuje kako se na osnovu prikupljenih podataka i pomo ću kopanja podataka oblikuje model ponašanja korisnika Podatke o korisnicima je potrebno stalno pre čišćavati, ažurirati, i analizirati. Za to je neophodno slijedeće: • • • •
posebna programska oprema i osposobljeni radnici prilagodljivo skladište podataka neophodna oprema za izvo đenje testiranja mjerenje učinkovitosti
Data mining analize se u biti baziraju na metodama raspoznavanja uzoraka i koriste se za rješavanje slijedećih zadataka: •
•
•
•
•
•
Razvrstavanje (engl. classification), npr. razvrstavanje korisnika u neki od unaprijed definisanih segmenata; Predviđanje (engl. prediction). Metoda vrlo sli čna razvrstavanju, ali za razliku od razvrstavanja, određujemo segment kojem će korisnik pripadati u budućnosti; Procjena vrijednosti (engl. estimation). Omogućuje procjenu vrijednosti neke kontinuirane varijable u nekom trenutku u budućnosti; Grupisanje (engl. clustering). Metoda kojom se analizira baza korisnika. Broj segmenata se određuje ručno ili automatski. U segmente se zatim automatski razvrstavaju korisnici; Metoda analize korpe se koristi za otkrivanje usluga koje se prodaju zajedno, Druga vrsta analize je analiza redoslijeda prodaje, Opisivanje i vizualizacija podataka. Ove metode omogu ćavaju učenje iz podataka, a ljudi lakše uče pomocu vizualizacije.
6. DATA MART Data Mart je podskup podataka iz korporativnog skladišta ili samostalan skup podataka koji zadovoljava izvještajne i analitičke potrebe pojedine poslovne funkcije u organizaciji (finansija, marketinga, prodaje, razvoja...). Naj češći oblik Data Marta je multi-dimenzionalan (neka od varijanti OLAP-a), što omogu ćava brzu i kvalitetnu analizu podataka. Problem koji se može pojaviti u organizaciji koja je implementirala nekoliko Data Martova prije implementacije centralnog skladišta podataka je integracija postojećih martova u cjelovit sistem. Vjerovatno najve ći zagovornik implementacije Data Martova i decentraliziranih sistema je Ralph Kimball, čija metodologija ima puno pristalica.
28
7. META PODACI Meta podaci su podaci o podacima (u DW metodologiji podaci o podacima u skladištu podataka). Podaci u skladištu mogu biti razlicito organizirani, ovisno o metodologiji koja se koristi, ali u svakom slu čaju svaka tablica s podacima se odnekud učitava, u nekom vremenu, doživljava odre đene transformacije, kombinira se s nekim drugim tablicama da bi na kraju dala tablicu optimiranu za izradu multidimenzionalne kocke i za izvještavanje. Svi podaci o tom procesu, transformacijama i podacima koji nastaju nazivaju se metapodacima i oni definišu strukturu i sadržaj skladišta. Standard za metapodatke nije još definisan (iako na tome radi Metagroup), tako da svaki proizvo đač ima svoj oblik čuvanja metapodataka. To se najbolje vidi u promotivnim materijalima pojedinih proizvoda u kojima se navodi da osim njegovih vlastitih "kocki" može koristiti i npr. Microsoft OLAP Cube, Cognos PowerCube i slicno, dakle meta podatke drugih proizvođača. Takođe u meta podatke spadaju i definicije ulaznih tablica iz raznih ERP sistema poput SAP R/3, Baan-a, PeopleSoft-a koje proizvodaci BI alata naj češće podržavaju. Takve definicije često mogu biti vrlo korisne jer omogućavaju brzo snalaženje u šumi od 20.000 i više tablica i brže postizanje kvalitetnih rezultata.
8. OLAP - ON-LINE ANALITI ČKO PROCESIRANJE OLAP je pojam koji izvorno poti če od E.F. Codda, a opisuje informacioni sistem za brz, konzistentan i interaktivan pristup i manipulaciju multidimenzionalnim podacima koji dolaze iz različitih izvora, a spremljeni su u skladištu podataka. OLAP je skraćenica za Analitycal On Line Processing. Funkcionalnost OLAP-a ostvarena je kroz mogućnost multi-dimenzionalnih analiza konsolidiranih korporativnih podataka koje uključuju: modeliranje korištenjem dimenzija i hijerarhija podataka, analize trendova kroz određena vremenska razdoblja, projekciju podataka kroz what-if scenarije, podskupove podataka, bušenje (drill down) do nižih nivoa detaljnosti podataka. OLAP je obično implementiran u klijent-server okruženju, a u novije vrijeme i u thin client sistemima. 1993. Codd je formulirao 12 pravila koje bi OLAP trebao podržavati. OLAP postoji u dva temeljna oblika s obzirom na formu u kojoj su podaci spremljeni: relacijski (ROLAP-Relational On Line Analitycal Processing) i multidimenzionalni (MOLAP- Multidimensional On Line Analitycal Processing), te u hibridnom obliku (HOLAP-Hybrid On Line Analitycal Processing) koji za više nivoe sumarizacije koristi multidimenzionalni oblik, ali omogućuje dril-down do nižih nivoa sumarizacije koji su smješteni u relacijskoj tablici. U posljednje vrijeme koristi se i izraz FASMI - Fast Analysis of Shared Multidimenzional Data.
29
Slika 16. Rolap, Molap
9. MIDDLEWARE Telekomunikacijske kompanije, tek se suo čavaju sa problemom velikog broja transakcija: dok je koli čina posla mala, može se koristiti prakti čno bilo koja softverska platforma, ali kada stignemo do nekoliko stotina hiljada ili čak miliona transakcija dnevno, stvari počinju da se komplikuju. Mnogi tradicionalni sistemi za obradu podataka tada pokazuju probleme ili gube na pouzdanosti, a prelazak na neki novi sistem zahtijeva džinovske troškove i opet ne garantuje uspjeh. Dodatni problem je postojanje raznih platformi i operativnih sistema koji treba paralelno da obra đuju transakcije. Posljednjih godina u svijetu se afirmiše novi sloj softvera, poznat pod imenom middleware. U pitanju je programski sistem koji se, logi čki gledano, smješta "izmedu" klijenta i servera, brinući o transakcijama i svim vrstama (ne)kompatibilnosti raznih platformi, dajući korisniku priliku da izabere bilo koju iz široke liste DBMS alata odnosno hardverskih platformi. Tržište softvera ove vrste bilježi posljednjih godina snažan rast.
Slika 17 Middleware
30
10. BUSINESS INTELLIGENCE Tipična kompanija analizira samo deset posto prikupljenih podataka. Business intelligence je način kako iskoristiti preostalih devedeset posto. BI je krovni naziv za skup metoda, alata i aplikacija koje omogu ćavaju prikupljanje, analizu, distribuciju i djelovanje na osnovu poslovnih informacija, sa ciljem donošenja boljih poslovnih odluka. BI daje pogled na cijelu kompaniju, pri čemu svako može dobiti upravo onu informaciju koja mu je potrebna. Ako pogled nije cjelovit, tada se analiza kompanije svodi na indijsku priču u kojoj desetak slijepih ljudi, odvojeno opipava neki dio slona – rep, trup, kljove, noge, uši, bokove. Svako misli da dodiruje razli čitu životinju i kad pričaju šta su osjetili, svaki od njih opisuje razli čitu životinju. Stvarni se slon u njihovoj analizi nikad ne pojavljuje. BI omogucava proaktivan na čin vođenja kompanije, što zna či da se može predviđati budućnost, izraditi nekoliko scenarija i biti pripremljen za svaku situaciju. Problem je kako pretvoriti informaciju u znanje. Danas se kompanije vode na osnovu znanja: o konkurenciji, korisnicima, dobavlja čima, procesima. BI je proizvodnja znanja koje je osnovna za donošenje poslovnih odluka. Tehnički gledano, BI je informatički sklop. Ne onaj sistem kakav smo navikli tj. transakcijski (glavna knjiga, prodaja, nabavka ), ve ć jedan potpuno drugačiji. U njega podaci dolaze iz kompanije, ali i iz okoline. Izvori podataka su heterogeni, a prikaz podataka agregatan. Ne zanimaju nas fakture i otpremnice, vec profiti po tržišnim segmentima, korisnicima, tržišni udjeli, trendovi. BI nam služi za aktivno upravljanje poslovnim rezultatom. Poznata je stvar da se poslovni rezultat ne o čekuje, vec se poslovnim rezultatom upravlja. Umjesto da 90% vremena trošimo na prikupljanje i izradu izveštaja, mi 90% vremena trošimo na analizu. BI sistem je izvorno bio namijenjen decision makerima, odnosno ljudima koji donose poslovne odluke. U savremenim kompanijama odluke donose svi. Ne moraju svi odlučivati, ali mogu svi predlagati. To nije povratak u samoupravljanje, vec pružanje prilike svima koji mogu dati doprinos očuvanju vitalnosti kompanije. Informacije i znanje potrebni su svima. Danas su organizacijske strukture puno “plice”, radi se puno projektnim načinom. Više je koordinacije a manje subordinacije. Danas je BI u donošenju poslovnih odluka nezamjenjiv koncept. Najveći doprinos uspjehu uvođenja BI-a 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 izveštaja”), laka čitljivost izvještaja, uvjeravanje “da je to prava stvar” ne mogu biti protiv tež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 proizvoditi je! Laka dostupnost informacija i (sa)znanja o korisnicima, dobavlja čima, procesima i njihovim međusobnim odnosima glavna je karakteristika BI-a. BI se pojavljuje kao moderan sistem komunikacije. Moderni sistemi komunikacija čine današnju korporaciju ostatkom prošlosti. Kako se najbolje može organizovati 31
