Univerzitet za poslovne studije
UNIVERZITET ZA POSLOVNE STUDIJE BANJA LUKA FAKULET INFORMACIONE TEHNOLOGIJE I DIZAJN
CASE ALATI
SEMINARSKI RAD
PREDMET: Case alati PROFESOR: DOC. dr Mihajlo Travar Travar
STUDENT: BOJAN PEJAKOVIC INDEKS br. V-164/11 SEMESTAR: VI SMIJER STUDIJA: RACUNARSKE I INFORMACIONE TEHNOLOGIJE
BANJA LUKA, maj 2014. god.
[Type text]
Page 1
Univerzitet za poslovne studije SADRZAJ:
UVOD........................................................... UVOD............................. .............................................................. .............................................................. ............................................................. .............................................................. ....................................... ........4 CASE ALATI .......................................................... ......................................................................................... .............................................................. ............................................................. ........................................................... .............................4 Ideja CASE tehnologija:
....................................................................................................................................... 4
.....................................................4 POVEĆANJE PRODUKTIVNOSTI U RAZVOJU SOFTVERA POMOĆU SOFTVERA ..................................................... CILJEVI PRIMENE CASE TEHNOLOGIJE ................................................................................... .................................................................................................................. ............................................ .............4 CASE TEHNOLOGIJA.......................................................... ........................................................................................ ............................................................. .............................................................. ............................................ .............4 NEKI OD POZNATIJIH CASE PROIZVODA .......................................................................... ......................................................................................................... ................................................. ..................5 KLASIFIKACIJA CASE TEHNOLOGIJE .............................................................. ............................................................................................. .............................................................. ....................................... ........ 6 KLASIFIKACIJA U ODNOSU NA POKRIVENOST.................................. POKRIVENOST................................................................ ............................................................ ................................................. ...................6 KLASIFIKACIJA U ODNOSU NA FUNKCIJE ....................................... ..................................................................... ............................................................. ...................................................... .......................6 CASE ALATI .......................................................... ......................................................................................... .............................................................. ............................................................. ........................................................... .............................7 REALNI SISTEM KAO NARUČILAC IS-A.......................................................... ......................................................................................... .............................................................. ....................................... ........9 INTERESI I METODIKA RADA PROIZVOĐAČA SOFTVERA KAO IMPLEMENTATORA IS-A ................................ ................................9 KONTROLA IMPLEMENTACIJE PROJEKTA SPIS-A ............................................................................. ....................................................................................................... .......................... 10 CASE ALATI KOJI PODRŽAVAJU SPIS I NJIHOV E OSOBINE .............................................................. ........................................................................................ .......................... 12 OSNOVNE OSOBINE CASE ALATA VISIO2003 .................................................................. ................................................................................................. .............................................. ............... 13 OSNOVNE OSOBINE CASE ALATA COOL:BIZZ .................................................................. ................................................................................................. .............................................. ............... 14 .......................................................................................... ........................................................ .......................... 17 TEMELJNE ZNAČAJKE CASE ALATA ERWIN ............................................................
[Type text]
Page 2
Univerzitet za poslovne studije OSIGURANJE KVALITETA SOFTVERA ....................................................................... ...................................................................................................... ........................................................ ......................... 19 ........................................................................................ ............................................................. ............................................................. .............................................. ................ 21 PRELAZNI REŽIM .......................................................... .......................................................................................... ............................................................. ............................................................. ................................................... ..................... 22 ODRŽAVANJE ............................................................ TEHNOLOGIJE KOJE POM AŽU RAZVOJ INFORMACIONIH SISTEMA ....................................................... ....................................................................... ................ 23 UPRAVLJANJE IS PROJEKTIMA ......................................................... ........................................................................................ ............................................................. ................................................... ..................... 25 STROGO HIJERARHIJSKI ORGANIZAOVAN TIM ........................................................................ ....................................................................................................... .................................... ..... 26 ......................................................................................... .............................................................. ............................................................. ........................................................ .......................... 27 ZAKLJUČAK .......................................................... LITERATURA:............................................................ .......................................................................................... ............................................................. ............................................................. ................................................... ..................... 28
[Type text]
Page 3
Univerzitet za poslovne studije UVOD
CASE alati
softverski inženjering, je stroga primena inženjeringa, naučnih i matematičkih principa i metoda u ekonomičnoj proizvodnji kvalitetnog Programski alati za razvoj aplikacija -
softvera.
Softverski inženjering, kao posebna disciplina, koja se bavi ekonomsko-tehnološkim aspektima izrade softvera, kao i svaka druga tehnologija, može se posmatrati sa dva aspekta: Konvencionalna (ručno programiranje, definisanje i dokumentovanje problema i održavanje sistema) 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ži ti 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
[Type text]
Page 4
Univerzitet za poslovne studije Kadrovi: oni koji sve to koriste
Neki od poznatijih CASE proizvoda Cor-Vision, Cortex Corporation Promod PLUS, Promod INC Oracle CASE, Oracle Corporation
[Type text]
Page 5
Univerzitet za poslovne studije
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 planiranje i upravljanje projektima Middle CASE – analiza analiza i projektovanje Lower CASE – programiranje, programiranje, testiranje i uvoĎenje CASE tool – namenjeni namenjeni pojedinim aktivnostima CASE toolkit – namen namen jeni pojedinim fazama ili aktivnostima u više faza CASE workbench – integrisana integrisana kolekcija CASE paketa kojom se pokrivaju sve faze
Klasifikacija u odnosu na funkcije 1. Alati za planiranje poslovnih sistema – prate prate informacione tokove izmeĎu OJ 2. Alati za upravljanje projektima – prate prate glavne upravljačke aktivnosti, npr. planiranje, procena vrednosti, resurse, rizik, troškove, kvalitet, standarde, merenja... 3. Alati podrške – dokumentovanje, – dokumentovanje, podrška sistemskom softveru, obezbjeĎenje kvaliteta, 4. 5. 6.
upravljanje bazama podataka... Alati za analizu i dizajn – najvažniji – najvažniji alati, omogućavaju kreiranje sistema Alati za programiranje – podržavaju podržavaju kreiranje programskog koda Alati integracije i testiranja – prikupljanje prikupljanje testnih podataka, analiza izvornog koda i pomoć u aktivnostima testiranja Alati prototipskog razvoja – služe – služe za izradu prototipa
7. 8. Alati za podršku održavanju – koriste – koriste se za reverzibilni inženjering, rekonstrukciju koda i
reinženjering
[Type text]
Page 6
Univerzitet za poslovne studije CASE Alati
Od samog pocetka osnovni cilj c ilj 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. K ako ako se “snaga i brzina" računara povećavala tako su CASE alati dobijali na svom značaju.
[Type text]
Page 7
Univerzitet za poslovne studije 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 organizaci je je 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. Iplementacija 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.
[Type text]
Page 8
Univerzitet za poslovne studije 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.
Realni sistem kao naručilac IS -a Svaki realni poslovni sistem deluje na tržištu radi ostvarenja nekog neko g unapred zadanog cilja. Savremeno orijentisane organizacije obavljanje svojih svakodnevnih poslova ne mogu zamisliti bez pomoći dobrog informacionog sistema, koji će omogućiti čuvanje potr ebnih ebnih 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 k upovinu upovinu 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.
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 razvi jenu jenu 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 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 a plikacija kao proizvoda biti iskorišten. Takva parcijalna rešenja nadograĎuju se, povezuju u veće ili dele u manje programe.
[Type text]
Page 9
Univerzitet za poslovne studije 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. 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 pr e 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.).
[Type text]
Page 10
Univerzitet za poslovne studije
[Type text]
Page 11
Univerzitet za poslovne studije
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 .
[Type text]
Page 12
Univerzitet za poslovne studije
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
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.
[Type text]
Page 13
Univerzitet za poslovne studije 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 raz loga 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.
[Type text]
Page 14
Univerzitet za poslovne studije 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 o pis 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 .
[Type text]
Page 15
Univerzitet za poslovne studije 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
[Type text]
Page 16
Univerzitet za poslovne studije Na temelju fizičkog modela podataka generiše se DDL – Data 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 podatak a 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.
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.
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.
[Type text]
Page 17
Univerzitet za poslovne studije
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
[Type text]
Page 18
Univerzitet za poslovne studije
Osiguranje kvaliteta softvera
Osiguranje kvaliteta softvera obuhvata različite tehnike koje sve imaju za cilj da pomognu proizvodnji kvalitetnog softvera koji k oji 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 sastavl jena jena od manjeg broja ljudi (komisija) u prisustvu autora materijala. 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 pseudok odove pojedinačnih modula. 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 inspekci je je 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 n jegovih 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
[Type text]
Page 19
Univerzitet za poslovne studije se pažljivo proučavaju i arhiviraju. Za potrebe po trebe testiranja softvera postoji niz kvalitetnih alata koji povečavaju efektivnost procesa. Kod testiranja softvera r azlikuju azlikuju se pet nivoa: Testiranje modula - pošto se moduo kodira, vrši se njegov pregled i testiranje sa unapred odredjenom procedurom Testiranje integracije – kada – 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. mod uli. Sistemsko testiranje – sistem – 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 prov erava njegova prateća tehnička dokumentacija. U sistemsko testiranje softvera spada i tzv. beta b eta 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 sistem se testira da se proveri da li su zahtevi z ahtevi 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. – ako je atest vršen pre nego što je sistem instaliran i pušten u rad Instalaciono testiranje – ako 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.
[Type text]
Page 20
Univerzitet za poslovne studije
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 no vi je najrizičnija i naravno zbog toga najskuplja. Ovaj postupak podrazumeva da se u jednom trenutku stari sistem potpuno zameni novim. Postepena kon verzija zamenjuje stari sa novim sistemom po fazama koje su odredjene ili hardverom h ardverom ili organizacionim i funkcionalnim podelama u
kompaniji. Pilot konverzija isto tako postepeno zamenjuje zamen juje sisteme pri čemu se na početku uvodi uvod i 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.
[Type text]
Page 21
Univerzitet za poslovne studije
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 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.
Održavanje softvera zapravo se sastoji iz tri aktivnosti: poboljšavanje i modifikovanje sistema tako da zadovolji nove zahteve Usavršavanje – poboljšavanje korisnika i nove potrebe kompanije. promena aplikacija zato da bi se one prilagodile na nove hardverske i Adaptacija – promena softverske platforme. Korekcija – ispravljanje – ispravljanje gršaka koje su otkrivene prilikom eksploatacije sistema.
Postupak održavanja softvera ide u tri faze. Pre P re 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 u tič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 do kumentovan 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 po trebno izvršiti u softveru da bi on bio ažuriran prema potrebama kompanije i korisnika.
[Type text]
Page 22
Univerzitet za poslovne studije
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 ko mponenti 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). 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 Po moću njih se prvo brzo izradi korisnički k orisnič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.
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 ko mpletnost 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
[Type text]
Page 23
Univerzitet za poslovne studije 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.
[Type text]
Page 24
Univerzitet za poslovne studije 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
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 s pecifikacije 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 iz vršava kako u broju tako i po profesijama ljudi koji su zastupljeni. Na početku razvoja tim čine uglavnom sist em 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.
[Type text]
Page 25
Univerzitet za poslovne studije
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. 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 odvijan je 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.
[Type text]
Page 26
Univerzitet za poslovne studije
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 kontr ole, ole, a u ovom radu je pokazan CASE alat ERwin kao najbolje rješenje za praćenje navedenog postupka.
[Type text]
Page 27
Univerzitet za poslovne studije Literatura: Brumec, J.: Strategic Planning of Information Systems COOL:Bizz: Model manager help
Vidačić, S., Brumec, J., Tomičić, M.: Logical model of the database as means od informationa system usage and development control
[Type text]
Page 28