106870580645PANEVROPSKI UNIVERZITET APEIRON
FAKULTET POSLOVNE INFORMATIKE
Redovne studije
Smjer „Poslovna informatika”
Predmet
SOFTVERSKI INŽINJERING SA OBJEKTNIM PROGRAMIRANJEM
"CASE ALATI"
(seminarski rad)
Predmetni nastavnik
Prof. dr Zoran Ž. Avramovi?
Student
Marko Vuki?
Indeks br. 55-13/RPI
Banja Luka, Novembar 2016.

PANEVROPSKI UNIVERZITET APEIRON
FAKULTET POSLOVNE INFORMATIKE
Redovne studije
Smjer „Poslovna informatika”
Predmet
SOFTVERSKI INŽINJERING SA OBJEKTNIM PROGRAMIRANJEM
"CASE ALATI"
(seminarski rad)
Predmetni nastavnik
Prof. dr Zoran Ž. Avramovi?
Student
Marko Vuki?
Indeks br. 55-13/RPI
Banja Luka, Novembar 2016.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

TOC o "1-3" h z u

UVOD
CASE (Computer Aided Software Enginerring) mozemo prevesti kao razvijanje softvera pomo?u ra?unara. Ideja samog postojanja je da se razvijanje što više pojednostavi. Ukratko, za CASE se kaže da je to bilo koji softver koji je napravljen da bi se uz njegovu pomo? pojednostavila izrada drugog softvera.

CASE tehnologije upotrebljavaju se za rad sa zadacima u oblasti automatizacije i izrade pojedina?nog alata za odredjeni softver ili za kreiranje potpuno novih alata za automatizaciju, svrha je skratiti proces izrade softvera. Od izuzetnog zna?aja je re?i da CASE tehnologije nisu nikakva zamjena za metodu u razvijanju, samo dodatak tim istim metodama koje se upotrebljavaju da bi dobili softver koji je kvalitetan.
Korištenje grafi?kij elemenata predstavlja zna?ajan dio u CASE tehnologijama, te bi prilagodjavanje korisniku trebalo da bude najviše prisutno.
Osnova?i CASE tehnologija u suštini su programeri koji razvijaju softver. Cilj je da se produktivnost prilikom izrade softvera dovede na zavidan nivo. Ideja za CASE tehnologiju proizašla je iz toga da je potrebno da se ra?unar iskoristi u bitnije svrhe u odnosu na ono za šta je u to vrijeme korišten. Pove?anje produktivnosti nije bio jedino što se htjelo posti?i, ve? se generalno informacione tehnologije grade na upotrebi ra?unara. Bilo je isto tako važno da vrijeme utrošeno za kreiranje samog projekta skrati ali da se time ne izgubi kvalitet.
Kako bi se implementiralo sve gore navedeno klju?an faktor je da se tehnologije primjenjuje te da se realizuju svi potrebni koraci.

CASE TEHNOLOGIJA
CASE tehnologije se klasikuju na osnovu više kriterijuma, a to su:
Prema posjeduju?im funkcijama
Instrumentalnu ulogu koju imaju kada do?u do izvršioca ili upravlja?a aktivnostima
Zavisno od mogu?nosti primjene i to u raznim fazama razvijanja softvera
U zavisnosti od softvera i hardvera koji imaju na raspolaganju
Izvorno porijeklo
Cijena izrade
Još jedan od kreiterijuma na osnovu koga je mogu?e klasifikovati CASE tehnologije je kompletnost same CASE tehnoloigje. Njome definišemo koliko zadataka metodologije u svom životnom ciklusu automatizacije CASE tehnologija podržava i na taj na?in dobijamo slede?u podjelu:
Upper CASE
Middle CASE
Lower CASE
Upper CASE obuhvata sve one CASE tehnologije koje imaju namjenu da automatizuju faze upravljanja projektima i faze strateškog planiranja u samom sistemu.

Middle CASE se bave automatizacijom sistema u fazama dizajna i fazi analize.

Lower CASE automatizuju onaj dio alata u CASE tehnologijama koji je vezan za programiranje i tako?e fazu testiranja kao i uvo?enje samog informacionog sistema.

Naredna podjela bila bi prema integrisanosti CASE tehnologija:
CASE tool
CASE toolkit
CASE workbench
CASE tool predstavljaju alate koji neke aktivnosti CASE tehnologija automatizuju u kada je informacioni sistem u fazi razvoja. One koriste grafi?ku podršku koja danas predstavlja jako mo?an alat što zan?ajno olakšava dokumentovanje i opis sistema. Grafi?ki se tako?e što više nastoji približiti korisni?ki interfejs da bi bio što bliži korisniku i na taj na?in olakšao rad sa samim alatom.

CASE toolkit složi za to da bi se jedna kompleksnija faza ili funkcija podijelila na više faza a da ih ovaj alat sve ujedini. Dakle tu kre?emo od razvoja svake funkcije ili faze pojedina?no da bi na kraju dobili jedan složeniji projekat.

CASE workbench se koristi kada automatizujemo sve zadatke u procesu razvoja informacionog sistema po fazama i samim tim predstavljaju kolekciju CASE paketa koja je integrisana. Kada se kolekcije CASE paketa usklade sa odgovaraju?im hardverom dobije se radna stanica za razvoj softvera. Treba imati na umu kada se biraju CASE alati da vrste sistema i karakteristike kojima su oni prvenstveno namjenjeni budu uskla?eni sa potrebama korisnika i zahtjevima njegovog sistema u zavisnosti za šta želimo koristi neku od CASE tehnologija.

OSOBINE CASE TEHNOLOGIJA
Sveukupno, zahtjevi korisnika diktirani su razvojem CASE tehnologije i stoga što je potrebno u okruženju pa je kona?na ideja kako ?e tehnologija funkcionirati. Nema posebnih standarda kada je u pitanju CASE tehnologija. To su brojni, što je jasno na temelju svih navedenih grupa kao i opsežnih mogu?nosti primjene u mnogim fazama razvoja softvera. Dakle, jasno je da CASE tehnologija pokriva gotovo sve faze razvoja softvera.

Svaka nova tehnologija ima veliku prednost ako je prilago?ena korisniku, što olakšava korištenje prakti?no predstavlja u?inkovitost tehnologije koju je korisnik vidio. Bez obzira na složenost tehnologije i funkcionalnost CASE tehnologije, oni su stvoreni na takav na?in da jednostavno, lako i bez puno potrebe za razmišljanjem dovodi do rješavanja odre?enog zadatka. U suprotnom, ako korisnik treba napraviti dio tog posla i provesti svoje vrijeme rade?i na kraju tehnologije i da ga može iskoristiti, ve? je upitno koliko on ili ona ispunjava svoj zadatak i da li to zapravo pomaže , jer ako imamo takav slu?aj mogu?e je da onda samo predstavlja zapreku u radu.

Budu?i da se CASE tehnologija smatra naprednim, od njih se o?ekuje da riješe pogreške u samom procesu, pa ?ak i neki od njih samoreguliraju. Komunikacija bi tako?er trebala biti na vrlo visokoj razini interakcije i imati jasan i koncizan dijalog s korisnikom tijekom rada, vrlo je važno da sve bude predstavljeno na jednostavan i razumljiv na?in. Kako bi tehnologija mogla zadovoljiti zahtjeve korisnika, nužno je biti u mogu?nosti kombinirati s drugim tehnologijama, fleksibilnost u tom pogledu je vrlo važna jer su zahtjevi korisnika razli?iti. Neki neplanirani odgovori tehnologije ili sli?no uzrokuju najviše nezadovoljstva korisnika, stoga je potrebno smanjiti takve situacije i poželjno je imati isti i potpuno ukloniti. Stoga se smatra neprihvatljivim da zbog svoje izlazne tehnologije blokira korisnika i ne iznena?uje, korisnik je zbunjen rezultatom ili sli?no. Tako?er, od korisnika se o?ekuje da koriste naredbe koje su koncizne, jednostavne i jasne.

U smislu prihvatljivosti, tehnologija koja ima razinu prihvatljivosti koja, zahvaljuju?i svojoj izvedbi, može riješiti velik broj zadataka tijekom razvoja softvera, tada se takva tehnologija može smatrati kvalitetom. Recimo samo da je mogu?e izraziti kao jednostavnu naredbu može dovesti do jednog od glavnih u?inaka za koje je tehnologija razvijena. Osim toga, o?ekuje se da ?e CASE tehnologija predstaviti sve informacije o stanju CASE tehnologije, s ciljem da korisniku omogu?i da tehnologiju bude informativnija o njihovom stanju, pa ?ak i dobije dojam da je tehnologija još prikladnija od onoga što je stvarno jest.

Sposobnost alata za osloba?anje korisnika kada je u pitanju rizik da korisnik sam može stvoriti predstavlja njegovu pouzdanost, što je vrlo važno za korisnika. Smatra se da CASE tehnologija najprije otkrije mogu?e pogreške, a potom ih eliminira, a tako?er se sje?a posljedica pogreške. Ako je sama pogreška uklonjena i posljedice koje je prouzro?io, zna?ajno ugrožava pouement sustava. Samotestiranje je vrlo važno u tome, sama tehnologija mora biti potvr?ena i taj mehanizam je zadužen za omogu?avanje pravilnog funkcioniranja.

Potvrda mo?i i veli?ine mo?i tehnologije postiže se na temelju konzistentnosti aktivnosti, podrazumijeva semantiku i sintaksu koja mora biti dobro definirana. Istodobno, bitno je da se to-doologija razvije do te mjere da bez poteško?a podupire razlike izme?u pojedinih verzija i da su u potpunosti kompatibilne.

Funkcionalnost je zna?ajka koja se ne može definirati isklju?ivo na temelju zadatka za koje su neke od tehnologija dizajnirane, ali su vrlo važne i iste metode korištene za obavljanje zadataka. Postoji mnogo tehnologija kojima se podržavaju metodologije. ?iš?enje u?inkovitosti same stare tehnologije ogleda se kroz sposobnost podupiranja metode i njegovog doprinosa neposrednoj sposobnosti razumijevanja i definiranja tehnoloških zna?ajki. U?inkovitost se tako?er može promatrati kroz korisnost izlaza i njihovu kvalitetu sa stanovišta kupca.

Svrha CASE tehnologije je integrirati metode i povezati ih s metodologijom. Neke od tehnologija imaju mogu?nost podržati ?ak i sva podru?ja u metodologiji ili barem više, ako ne barem u najmanje jednom podru?ju metodologije, a rezultati izme?u faza mogu se samostalno prenijeti. Struktura i koncept CASE tehnologije odre?en je izravno odabranom metodologijom, kako pomo?u tehnika i metoda. Nužno je da tehnologija osigurava uporabu dosljedne metodologije, kao i metode na kojoj se temelji. To osigurava ispravno funkcioniranje i naglašava potrebu da se kontrolira je li metodologija u potpunosti provedena. Tako?er treba napomenuti da sama tehnologija ima zadatak generiranja ispravnih rezultata koji su strogo definirani metodologijom.

Postoje?i sustav je obi?no osnova za razvoj CASE tehnologije. Slijedom toga, od velike je važnosti da je CASE tehnologija ugra?ena u postoje?i sustav i prakti?ki nadogra?ena na njega. Jednostavna veza s postoje?im informati?kim sustavom je od velike važnosti. Cilj je jednostavno instalirati instalaciju, a postoje?e strukture i datoteke baze podataka koriste se nenametljivo, kao što je prije korištena CASE tehnologija. Ako je organizacija, što je uobi?ajeni slu?aj, koristi više od jedne tehnologije ove vrste, neophodno je omogu?iti prijenos podataka i njihovu razmjenu izme?u raznih tehnologija CASE koje se koriste u istoj organizaciji.

MODELIRANJE KORIŠTENJEM CASE ALATA
CASE alati su tako?e primjenu našli u velikoj mjeri u poslovnom svijetu. Cilj preduze?a je od starta bio da se realizaciji i projektovanju svojih informacionih sistema koji su korišteni za poslovne svrhe pristupe korištenjem CASE metodologija koje su bile najsavremenije, ti najnoviji alati su u svojoj osnovi imali rije?nik podatka. Na po?etku razvoja zbog malih resursa koji su bili potrebni za rad sam izbor alata bio je skroman. CASE alat su dobili na zna?aju vremenom kako se brzina i snaga ra?unara pove?avala.

Generisanje baze podataka i modeliranje poslovnih podataka u jednom poslovnom sistemu, koji bi se kao takav morao sastojati od poslovnih podataka koji su neophodni da bi taj isti sistem funkcionisao. Funkcionisanje nekog posovnog informacionog sistema je zamišljeno kao jedan cjelovit i integralan postupak. Baza podataka je veoma bitan dio sistema i njen zna?aj se jasno ogleda u tome što svi podaci moraju da budu obuhva?ani u njoj jer se na temelju njih donose odluke u poslovanju.

U bazi podataka svi odnosi kako postoje u realnom svijetu tako moraju biti i zabilježeni, logika povezivanja u bazi podataka je organizovana na taj na?in. Korištenjem savremenih CASE alata izra?uje se logi?ki relacioni model podataka i generišu se relacione baze podataka korištenjem automatike. Korištenjem ovih alata omogu?eno je izdvajanje logi?kog relacionog modela koji je veoma detaljan i u ovom slu?aju on se tretira kao proizvod koji je nezavistan. Ovaj model je realizovan na ovakav na?in jer tako nudi mogu?nost u poslovnom sistemu da se vrši nezavisna implementacija aplikacija kao i kontrola razvoja u poslovnim procesmia. Postoji nekoliko važnih CASE alata koji se u svakom slu?aju moraju pomenuti sa aspekta mogu?e izrade fizi?kog ili logi?kog modela podatka kao i kada se radi generisanje fizi?ke baze podataka iz nekog modela koji je razvijen, naravno podrazumjeva se da je proces automacki.

Pod razvojem informacionog sistema smatramo proces koji obuhvata korektnu i cjelovitu izradu rešenja, ona bi služala kao pomo? poslovanju tako što bi se njome odmah uvela i komunikaciono-informaciona tehnologija. Ona omogu?uje unapre?enje poslovne tehnoloigije u toj organizaciji za koju se sam sistem razvija tako što podrži sve poslovne procese na najbolji mogu?i na?in. Naru?ilac je taj koji je odgovoran u najve?oj mjeri za funkcionisanj tog razvijenog sistema, što se ne odnosi nužno na osobu nego u dosta slu?ajeva na samu organizaciju koja naru?uje neki sistem. Potencijalni problem je to što se neke greške i nedostaci uo?avaju tek kada je sistem razvijen i kada je taj informacioni sistem ve? uveden. Ukoliko se uo?i neki problem to zna?i da se mora prilagoditi ili popraviti.
Kada do?e do toga da je potrebno prilago?avanje, najve?i problem je što sve to košta i direktno uti?e na cijenu uvo?enja, što uti?e na kompletan projekat, ?ak može do?i i do toga da odnos troškova i prihoda u cjelini dobije negativan predzank. Da bi se sve ovo izbjeglo, prvenstveno zbog rizika od mogu?ih nepredvi?enih troškova prvenstveno razvija se sistem za kontrolu koji bi naru?iocu direktno omogu?io uvid i kontrolu tako da on u toku postupka prati i nadrire postupak dok je isti još u toku. Sredstvo korištenja sistema i za kontrolisanje razvoja je naj?eš?e logi?ki model podatka. Za ovakvo funkcionisanje potrebno je da prethnodno bude ispunjen uslov da sam logi?ki model podatka bude izra?en kao zaseban softver te da je isti vlasništvo naru?ioca. Da bi ovo bilo izvodivo neophodno je da se koriste CASE alati koji automacki da generišu iz objekta baze podataka logi?ki model podatka pored toga što može da automacki generiše model podatka iz modela podataka.

ImplementacijaDa bi se neke poslovna tehnologija odre?enje organizacije mogla unaprediti nužno je dobro poznavati sistem poslovne tehnologije koja treba unapre?enje. Prethodno zadani cilj je to što uvijek vodi sam organizacioni sistem, te pri tome kreira dodatnu vrijenost tako što pretvara izlazne i ulazne vještine. Razlikujemo dva mogu?a stanja prilikom izra?ivanja modela, to je neko trenutno ili sadašnje stanje i stanje kojem se teži, a to je unapre?eno ili budu?e stanje.

Gneneralno, sve faze razvoja se mogu svrstati u tri cjeline, na taj na?in dijelimo projektovanje i razvoj cjelovitog ingormaconog sistema, to su:
Kreiranje plana strategije informacionog sistema
Generisanje baze podataka i njeno modeliranje, razvoj aplikacija
Stavljanje sistema u funkciju
Sistem kao naru?ilacOstvarivanje nekog prethodno zamišljenog cilja je svrha svakog realnog poslovnog sistema koji se nalazi na tržištu. Za nesmetan rad i obavljanje ?ak i nekih svakodnvnih poslova organizacije koje su savremeno orjentisane ne mogu bez da im neki sistem koji je dobro informati?ki razvijen pomogne, poenta je da se podaci mogu po potrebi koristiti u bilo kojem trenutku i da se svi podaci koji su potrebni ?uvaju.

Pred svaki informacioni sistem se postavljaju odre?eni poslovni zahtjevi za taj sistem, vremenom ti zahtjevi postaju sve opsežniji, detaljniji i sofisticiraniji. Cilj svih informacionih sistema je da u što ve?oj mjeri i u svakom pogledu odgovore na zahtjeva koji su postavljeni. Kada je rije? o informacionim tehnologijama kao takvim uvijek se nude u praksi dvije opcije za poboljšanje ili uvo?enje nanovo informacionog sistema. Ukoliko je potrebno razvijaju se tehnologije vlastite podrške ali tako?e je mogu?a i kupovina gotovog rešenja. Na izbor izme?u ove dve opcije da li da se razvija novi softver ili kupuje neki postoje?i uti?e jako puno kriterijuma. Nekada se pred informacioni sistem predstavljaju neki zahtjevi koji su zaprvo potrebe koje su stvarne dobijene prethodnom analizom, te se u ovom slu?aju sistem koji je prilago?en svim tim zahtjevima pravi posebno za tog kupca po kriterijumima koje diktiraju isti ti zahtjevi.

Postoji i druga varijanta, a to je kupovina nekog gotovog sistema. Za ovu opciju se naj?eš?e odlu?uje ako je sistem ve? u upotrebi u nekoj sli?noj organizaciji pa je on prakti?no ve? prilago?en svim njihovim zahtjevima ili se poslovni sistem, ukoliko je to potrebno prilagodi samom softveru. Najvažnije je da zahtjevi na samom po?etku pudu precizno i jasno definisani za šta je prvenstveno odgovoran sam naru?ilac. Ukolio se odabere pravi poslovni sistem onda on poduprire poslovanje na najbolji na?in, te nekim novim potencijalima unapre?uje poslovne procese te da bi na koncu uvo?enjem informacinog sistema cjelokupno poslovanje bilo unapre?eno i olakšan dolazak do tražanog cilja.

Metodika proizvo?a?a softvera kao implementatoraCilj ovog posla, kao i svakog drugog, je naravno ostvarivanje profita. Dakle, softver koji proizvo?a? napravi je za prodaju. Da bi profit ostvaren prodajom bio što ve?i cilj je da se sa što manje radih sati te uloženog truda proda ?im više i na taj na?in izvu?e traženi maksimum. U zavisnosti od tipa preduze?a jer su uglavnom razli?ita tako su razli?ite i same metode rada. Kako vremenom neke firme imaju jako puno razvijenih programa iza sebe nije rijedak slu?aj da nešto od tih postoje?ih softvera pokušaju implementirati u neki novi softver. U zavisnosti od samog naru?ioca nekog sistema se dobija kona?ni rezultat ovakvog poslovanja, nekad se ista rešenja implementiraju jako puno puta i svojim imenom su prakti?no referenca kvaliteta i garancija sigurnosti kupcu. Suprotno tome postoji i slu?aj kada se radi o proizvodima koji nisu globalno poznati pa tako proivo?a?i su prinu?eni da sam softver prilago?avaju zahtjevima kupca. Ali ?ak i u ovom drugom slu?aju, gdje se generalno rade novi softveri uglavnom postoje dijelovi softvera ili aplikacije za koje se mogu iskoristiti neki postoje?i programi. Ovo je prakti?no neka vrsta parcijalnog rešenja jer se postoje?i programi povezuju u neke ve?e programe ili se nadogra?uju po potrebi, mada ima varijanti u praksi kada se ?ak dijele na više manjih programa.

Mogu?i problemi izme?u izvo?a?a i naru?iocaGeneralno gledano, postoje dva potencijalna problema. Pra?enje proizvo?a?a softvera, kao prvi, ukoliko reimo on pogriješi pri izvo?enju same baze i zbog toga ona na kraju ne odgovara traženim zahtjevima sistema. Drugi problem je to što je u ve?ini slu?ajeva poslovanje u toku izgradnje softvera dinammi?no te se mnogi faktori mjenjaju u svakom trenutku pod uticajem takve radne sredine. Ovaj problem je jako bitan jer samim tim što se promjene kostano dešavaju tako dolazi i do promjene i u samim podacima sa kojima se radi.

Ovi problemi su specifi?ni i zvog toga jer ih je jako teško uo?iti do samog kraja procesa. Predvidjeti ih je gotovo pa nemogu?e. Greške se uglavnom pokažu pri samoj implemantaciji novog rešenja, a to je ve? u praksi druga faza izvo?enja. Naravno, sve ovo se odražava na financijsku stranu pri?e što problem odmah ?ini još ve?im a pored toga i sistem je u tom slu?aju mnogo teže uvesti. ?esto za posledicu imaju i to, da na kraju, kada se sistem uvede on ne funkcioniše kako je o?ekivano te ne daje tražene rezultate i adekvatna poboljšanja. Ukoliko se stvar ne može ispraviti druga?ije, izvo?a?i su prisiljeni da odrade navnovo ciklus poboljšanja, to na kraju jako puno košta u odnosu na planirani budžet pa ?esto može dovesti i do toga da troškovi premaše ostvarenu dobit. Na kraju, važno je napomenuti da ovakvi problemi zanju odvu?i pažnju od stvarnih ciljeva a kako su sistemi na kojima se radi, kako je ve? re?eno, uglavnom dinami?ni to može odvesti izvo?a?a u nepovrat jer se infrastruktura konstantnu mijenja i jako je teško na kraju dobiti traženi rezultat.

Kontrola implementacijeKako je ve? re?eno, dvije faze se podrazumjevaju pri izvo?enjju projekta, to su:
Generisanje baze podataka i njeno modeliranje
Stavljanje informacionog sistema u funkciju
Kako je druga faza prili?no kompleksna, mogu?e ju je podijeliti na divije cjeline jer kako danas postoje i razvijaju se neki novi alati pomo?u kojiih se logi?ki relacioni model izra?uje mnogo je lakše raditi ukoliko se ovaj korak podijeli na slede?e dvije podfaze:
Detaljan logi?ki relacioni model se izra?uje i koristi kao generator za samu fizi?ku bazu podataka
Da bi se upravljalo modeliranom bazom podataka izra?uju se poslovne aplikaije
Prednost kada se ovako dobijena podfaza definiše kao nezavisna faza je ta što se na taj na?in poslovnom sistemu daje mogu?nost da kontroliše razvoj i implementacija samih poslovnih aplikacija, njegova osnova je sa?injena od logi?kog modela same baze podataka koji je detaljan. Logi?ki model mora biti u skaldu sa stratiškim planom informacionog sistema i njegovog razvoja.

Cilj ovoga jeste prvenstveno da se svi problemi, nedostaci ili eventualne greške uo?e prije po?etka implementacije, to se radi na takav na?in da se postoje?i sistem nadogradi unutar samog sistema povratnom vezom te tako da prakti?no na neki na?in kontroliše sam sebe. Baza podataka vidi ovaj element povratne veze u praksi kao novi logi?ki model. Ovakav vid kontrole u informacionom sistemu predstavlja prakti?no u strateškom planu razvoja sistem kontrole koji se izvodi a da se pri tome temelji na generisanju i upravljanju modela baze podataka koji sadrži logi?ki objekat. On ima funkciju da osigura od samog po?etka kada se neka poslovna aplikacija po?ne razvijati pa sve do implementacije koja je kona?ni korak te ima zadatak da osigura minimane troškove te da na kraju se dobije takva komunikacijsko-informaciona podrška koja ?e naru?iocu najbolje odgovarati te mu ponuditi poslovni sistem koji udovoljava svim njegovim zahtjevima.

Kada se logi?ki model podatka izdvoji kao poseban objekat informacionog sistema i kao takav je dostuan korisnicima tog istog informacionog sistema on tada ima više pozitivnih faktora kada gledamo sa gledišta korisnika prvenstveno i poslovnog sitema, te prednosti su slede?e:
– Baza podataka koja je stvorena kao po?etna verzija logi?kog modela koji je razvijen i on je generator te baze, ona je tada za razvoj nekih novih aplikacija jako dobra kao osnova
– Oslanjaju?i se na aktualne aplikacije ja?a se baza poslovnih podataka i njena nezavisnost
– Prate?i podaci se mnogo jasnije povezuju sa pocesima
– Bazi podataka se može pristupati eksterno korištenjem nekih od SQL upita koji su van standarnih aplikacija
– Kada je potrebna neka dorada odre?ene aplikacije ili modela na taj na?in se podsti?e stvaranje kreativnih ideja
– Samom proizvo?a?u poslovnog softvera je upu?en znatnio manji broj upita od strane korisnika
Jednom kada se izradi, poslovni model je zna?ajno kompunikaciono sredstvo izme?u proizvo?a?a softvera kao izvo?a?a sa naru?iocem tj. nekim poslovnim sistemom. Korištenjem modernih CASE alata koji su danas dostupni na tržištu iz logi?kog modela se fizi?ki model baze podataka automacki generiše te za sobom odmah povla?i i samu bazu podataka. Postoje CASE alati koji pored svojstva da generišu automacki iz modela podataka bazu podataka ve? da i iz objekra baze podataka generišu logi?ki model. Na ovaj na?in interaktivni odnos se diže na jedan novi nivo, misli se na komunikaciju proizvo?a?a softvera sa poslovnim sistemom odnosno naru?iocem. Pozitivna strana svega je što se to pozitivno odražava na bolji kvalitet softvera, te se napredkom aplikacije brže razvijaju, implementiraju brže što na kraju zna?i niže troškove i financijsku dobit kada se novi informacioni sistem stavi u funkciju.

TIPOVI CASE ALATA
Koncepcija CASE alata je takva da se pomo?u njih mogu izra?ivati razli?iti modeli informacionih i poslovnih sistema. Današnji CASE alati mogu izraditi mnogo razli?itih modela ali zapravo snaga same tehnologije nije u tome, ona se zapravo nalazi u repoziroriju znanja tj. središnjoj riznici, svi objekti koji su korišteni u modeliranju se unose u nju odnosno njihovi opisi. Pored objekata ve?i dio CASE alata posjeduje opis i popis veza me?u objektima koji su razli?iti. Veze takvoga tipa se u vim modelima odražavaju, tako se za modelirani sistem osigurava logi?ka ispravnost i konzistentnost. Sam kvalitet nekog CASE alata, što je bitno re?i, ne zavisi od veli?ine riznice koju taj model podržava ili samog broja modela ve? je bitan na?in njegove primjene i te svrha kojoj je namjenjen. Kao što se vidi iz prethodnog da bi se odabrao dobar CASE alat nije dovoljno da bude najtraženiji na tržištu ili da ima najviše modela ve? on mora odgovarati potrebama poslovnog sistema za koji ?e biti korišten. Zbog toga je važno da se kod odabira dobro poznaju potrebe informacionog sistema da bi CASE alat nio u mogu?nosti na najbolji na?in njegoc daljnji razvoj da podrži.

Kao primjer u ovom slu?aju navode se tri alata, a to su: Visio, COOL:bizz i Erwin. Osobine ovih softvera važno je sagledati iz više aspekata da bi se stekla jasna slika o ?emu se radi, po?evši od fizi?kog modela podataka, mogu?nosti izrade logi?kog modela te generisanja automacki iz fizi?ke baze podataka iz modela i obrnuto.

VisioOvaj alat je dio MS office paketa, on pruža mogu?nost da se pomo?u njega izrade razli?iti modeli i to ve? sa verzijom koja se dobija tipi?nom instalacijom. Kod ovog softvera dijagrami pripadju jednom od 16 tipova modela tj. kategorija. Interfejs je orjentisan korisni?ki te su simboli za crtanje veoma jednostavni za korištenje, pored toga dosta je primjera razli?itih modela te oni omogu?uju da alate koriste ?ak i osobe koje ne posjeduju mnogo zannja o samom projektovanju softvera. Dijagrami se sastoje od opcija koje su standardne a to su one za izra?ivanje intiteta, zatim atributa entiteta, veza razli?itih vrsta i stributa entiteta koji su klju?ni.

Razli?ite modele repozitorija nije mogu?e izraditi pomo?u ovog programa, to je zato što on nema ni vertikalne ni horizontalne povezanosti modela. Modeli se mogu prenositi u druge programe ali samo u svrhu prezentovanja. Dakle, ovaj CASE alat ne posjeduje mogu?nost da generiše automacki bazu podataka niti obratno da iz baze podataka izvrši automacki postupak generisanja modela. Iz prethodno navedenog može se zaklju?iti da model koji je izra?en u ovom alatu ne može biti korišten u svrhu primjene logi?kog modela podatka gdje bi on bio proizvo?a?u nekog softvera kontrolno sredstvo na na?in na koji je to prethodno opisano.

COOL:BizzKompanija Sterking software 1994. godine razvija CASE alat pod imenom COOL:Bizz. Kao i prethnodi, ovaj softver tako?e koristima za izradu raznih modela koji su potrebni da bi se prikaz informaciong i poslovnog sistema oblikovo. Kada je rije? o korisni?ki orjentisanom interfejsu tome se ovde nije posvetilo toliko pažnje kao u prethodnom slu?aju. Ovde se sa liste odabiu dijagrami, te se liste opcija nalaze u svakom od ovih dijagrama i sa njih možemo odabrati neki od ponu?enih objekata. Zbog svega navedenog može se zaklju?iti da je program namjenjen stru?njacima koji su ve? upoznati sa metodama kao i tehnikama modeliranja poslovnih podataka te poslovnih procesa.

Za sve modele jedne datoteke koji se nalaze u riznici koja je jedinstvena ogleda se snaga ovog alata jer postoji takva forma jedinstvene riznice u njemu. Ovakava riznica, koja je jedinsvena sastoji se iz liste i opisa svih objekata, isti mogu biti element svakoga modela koji je u pojedinoj datoteci sadržan. Pored toga ova datoteka sadži listu svih veza me?u pojedinim objektima kao i njihov popis i opis. Na ovaj na?in je formalna i logi?ka konzistentnost osigurana svim modelima.

Dijagramom koji sadrži poveznicu izme?u atributa, entiteta i relacija je omogu?ena izrada logi?kog modela podatka. Ovakav dijagram sadrži opcije za izradu veza izme?u entiteta kao i izradu samih entiteta, ovo su zapravo standardne opcije ali pored toga mogu?e je unijeti i dodatna svojstva kojima se objekti zapravo definišu, to je primjenljivo za svaki objekat koji je izgra?en. Dodatna pogodnost ovog modela je što je mogu?e fizi?ki model podatka generisati automacki tj. relacijski model koji sve elemente potrebne za generisanje fizi?ke baze podataka sadrži u sebi. Primatni klju?evi kao i sekundarni su tako?e sadržani u relaciskom modelu i pored toga sadrži i ripove entiteta za rješavanje veza koji su asocijativni. Svaki entitet mogu?e je detaljnije definisat tako što upišemo njegova dodatna svojstva. Izme?u fizi?kog i logi?kog modela podataka mogu?a je i povratna veza.

Kod koji strukturu baze podataka definiše generiše se na osnovu fizi?kog modela podataka. Ovaj kod u?itava program za generisanje baze podataka koji je odabran, te se na osnovu njega definišu fizi?ke šeme baze podataka koje su relacione kao i veze koje postoje izme?u njih. Bazu podataka koja je generisana na ovakav na?in može se popunjavati podacima nekog poslovnog sistema koji su stvarni. Bazu podataka je mogu?e sinhronizovati novim relacijskim atributama ili šemama ukoliko se vremenom neka stavka promjeni. Tako?e, iz logi?kog modela podatka može se generisati fizi?ki pomo?u ovog alata, kao i generisanje baze podataka na osnovu fizi?kog modela ali obrnuta varijanta ovog postupka nije izvodiva pomo?u ovog alata.

ErwinPomo?u ovog alata može se kreirati te održavati fizi?ki i logi?ki model podatka kao i generisanje fizi?ke baze podataka koja njima odgovara. Za rad sa ovim programom potrebno je imati mnogo znanja o samom postupku modeliranja podataka iako je interfejs orjentisan korisni?ki. Ovim alatom može se vršiti izrada fizi?kog ili logi?kog modela kao i istovremeno i fizi?kog modela i logi?kog.

Logi?ki model sadži:
Entitete
Veze izme?u entiteta
Atribute entiteta
Primarne te sekundarne klju?eve
Sadržaj fizi?kog moela:
Tip atributa u relaciskim šemama
Indekse veza na druge šeme
Denormalizovane tablice
Informacije o bazi podataka
Ograni?enja
U logi?ko-fizi?kom modelu sadržani su elementi oba zasebna modela.

Opis i popis svakog od entiteta dio su same datoteke koja posjeduje riznicu zaduženu za pam?enje ovih podataka. Skup podataka koji ga opisuju odnosno atributa postoji za svaki entitet. Ovde se nalaze svi podaci o njima, kao što su primarni i sekundarni klju?evi, zatim podaci o vezama sa drugim entitetima, informacije o procedurama koje su ugra?ene kao i okida?ima za njih itd. Fizi?ku bazu podataka automacki je mogu?e generisati na osnovu fizi?kog modela podatka. U ovu bazu se kasnije upisuju poslovni podaci. Razlika u odnosu na prethodne alate je ta što ovaj podržava i obrnutu varijantu tj. da se fizi?ki model podatka dobije iz baze podataka automacki.
Reverzno inžinjerstvo je stru?ni naziv za ovakav postupak. Kao proces reverzno inžinjerstvo iz baze podataka obuhvata informacije o relacijskim šemama, kao i njihovoj strukturi i atributima. Struktua zapravo predstavlja veze kojima su povezane relacione šeme. Nad nastalim modelom nakon što se u program prenesu informacije mogu?e je praviti odgovaraju?e izmejene u skaldu sa promjenama koje se dešavaju u poslovnim podacima kao i u strukturi istih. Nakon odre?enih promjena baza podataka se nanovo sinhronizuje sa novim modelom podataka. Ovaj alat posjeduje i sistem za izvještavanje pomo?u koga je mogu?e dokumentovati cijeli proces.

Kratka istorija CASE alataNa po?etku se razvoj programskih proizvoda oslanjao na razne alate ra proramiranje.

Bilo je tu nekoliko faza:
Mašinski jezici su bili prvi koji su se upotrebljavali ali se tražila bolje solucija jer su bila drasti?no zavisni od hardvera i jako teško ?itljivi
Naredni su bili asembleri koji su bili neznatno napredniji ali još se zna?ajno izraženim manama svog prethodnika
Posle na red dolaze jezivi tre?e generacije koji su orjentisani proceduralno. Veliki napredak je napravljen zato jer oni nisu bili u tolikoj mjeri zavisni od hardvera te struktuirano programiranje ulazi u upotrebu.

Nakon što su uvedeni jezici tre?e generacije produktivnost programirana se pove?ala tj. programski proizvodi su bili kvalitetniji a izrada mnogo brža. Na po?etku je bilo i nekih od nuz pojava jer se zbog naglog pove?anja profuktivnosti izgubilo na brzini kao i širini primjene. Dakle, došlo je do toga da je bio potreban novi hardver i pored toga neki asemblerski programi su unapre?eni na jezike tre?e generacije da bi mogli ostati u upotrebi.

Tada na scenu nastupa softverska kriza zato jer se o?ekivalo da odmah softver koji je napisan u jeziku tre?e generacije zadovolji odmah potrebe krajnjeg korisnika. Najve?i porblem je bio jer je ulaganje bilo drasti?no pove?ano a nisu dobijeni željeni rezultati. Jedan od najve?ih problema je bio taj što je usljed održavanja nekog programa programer gubio jako puno vremena te na taj na?in prakti?no je bio blokiran daljni razvoj i pored toga se przo uvidjelo da je programiranjem na ovaj na?in gubljeno puno vremena i da je bilo neefikasno.

Dolazi se do toga da je najviše vremena bilo potrebno da bi se održali proizvodi koji su ve? na tržištu. Israživanja tako?e pokazuju da se ve?i dio grešaka pravio prilikom samog razvoje tokom projektovanja te analiziranja zahtjeva, a manji dio se javljao pri realizaciji. Još jedan veliki problem je bio to što se tek možda polovnia grešaka otklonila prije nego je softver isporu?en, ovo je bilo posebno problemati?no jer svaka greška koja se kasnije otklanjala je pla?ena mnogo više nego da se sanirala prije isporuke. Sve to dovodi do podjele finansija koja je bila krajnje neprirodna, odnosno ve?inski dio sredstava je trošen na održavanje dok je znatno manji dio odlazio na sam razvoj. Pored finsncijske štete koja je nastala još jedan veliki problem je predstavljalo vremensko kašnjenje.

Softversko inžinjerstvo je bila disciplina u ra?unarstvu koja je predstavljena kao rešenje softverske krize, a on je prethodio i samom razvijanju CASE tehnologija. Softversko inžinjerstvo se baziralo na ideji da pristup razvoju programa bude inžinjerski i metodološki te da se poštuju dati rokovi te da se kvalitetan softver primjenom odgovaraju?e tehnike plasira a tržište.

Pojava CASE alata je zapravo uslijedila nekon što je zaklju?eno da je drugi i tre?i uzrok softverske krize zapravo bio jer za razvoj programskih proizvoda nije bilo dostupno dovoljno softverskih alata. Ideja CASE proizvoda zasnivala se na automatizaciji zadataka te da se na takav na?in otklone problemi koji su prethodili.

Primjenjivana je tako?e metodologija pristupa koji je bio struktuiran te su na razli?itim nivoima detaljnosti crtani dijagrami upotrebom više ili manje formalnih tehnika. Pored toga kako je sve bilo povezano ukoliko se nivo detaljnosti mjenjao na jednom dijagramu ?esto je to povla?ilo potrebu da se isto uradi i na ostalim, kao i sa samim izmejnama na dijagramu, ako se jedan izmjeni ?esto su te izmjene direktno uslovlajvale promjene na ostalim dijagramima. Problem je bio tako?e to što ukoliko se radilo o ve?em projektu jako teško je bilo sve to efikasno obaviti ru?no.

Još jedan novost koju CASE tahnologije uvode na polju same organizacije ticala se podataka jer CASE alati su koristili jedinstven rije?nik podataka koji je predstavljao bazu podataka u koju je sve smiještano. CASE alati su bili u mogu?nosti da opis šeme za neki konkretan sistem baze podataka izgenerišu koriste?i implementacionu šemu baze podataka, te da programske aplikacije informacionog sistema izgenerišu korištenjem programskih specifiakcija. Sve ovo omogu?uju generatori koda.

Dolazi se do jezika ?etvrte generacije koji su tre?u generaciju jezika nadogradili jer su bili znatno pregledniji, lakše je bilo programirati sa njima te su bili na velikom nivou deklarativnosti. Ta?nu definiciju je zapravo teško dati jer su ovi jezici pedstavljali jako širok pojam, po?evši od alata koji su jednostavni pa sve do jezika koji su bili veoma razvijeni. Kako je jako teško bilo ta?no definisati šta su to zašravao jezici ?etvrte genracije usvojio se neki pojam koji je bio nešto opširniji a to je okruženje ?etvrte generacije.

Sve se zasnivalo na jednom jedinstvenom rije?niku podataka što je kod jezika ?etvrte generacije posebno izraženo jer je ideja bila da geeralno svi alari budu integrisani kao dio CASE okruženja koje bi bukvlno predstavljalo jedno široko okruženje za razvoj programskih proizvoda. Još jedna poteško?a koju se nastojala prevazi?i je dugotrajno i neproduktivno programiranje. Unapre?ene CASE thnologije su imale znatne prednosti ali i neke nedostatke, i jedni i drugi su navedeni u nastavku.

Prednosti:
Proces izrade programskog proizvoda znatno je olakšan i ubrzan
Kako je olakšano pronalazenje grešaka znatno su smanjeni troškovi održavanja aplikacija
Nedostaci:
Znatno kompleksnije aplikacije su tražile bolji hardver što je dovodilo do toga da lošije rade sa istim hardverom u odnosu na svoje prethodike
Širina primjene manja
Pored toga bilo je mogu?e prototipski pristupati razvoju softvera što se može posmatrati kao dodatna prednost. Kada je rije? o nedostacima može se slobono re?i da su prakti?no o?ekivani jer je prvenstveno potreba za boljim hardverom sasvim o?ekivana iako je u po?etku sam razvoj hardvera bio zna?ajno kompleksniji i sporiji nego danas.

Brzo se došlo do zaklju?ka da se ulaganjem u hardver može sna?ajno isplatiti jer na samom razvoju aplikacija se mnogo uštedi kao i održavanju programa posle. Neduko nakon po?etka primjene jezika ?etvrte genracije došlo se na ideju da se oni kombinuju sa svojim prethodnicima tj.jezicima tre?e generacije. Tako je recimo za neke složenije aplikacije kada se kod generiše uo?eno da u jeziku ?etvrte generacije su potrebna mnoga prilago?avanja dok su uspješno realizovani bez greške upotrebom jezika tre?e genracije.

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.

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.

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.

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 sreman za rad naravno ako je testiranje prošlo bez problema.
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 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.

Zaklju?akJasno je da su CASE alati jedan veoma zna?ajan dio programiranja. Doveli su do mnogih unapre?enja u izgradnji softvera ali isto tako u zna?ajnoj mjeri olakšali život samim programerima. Jasno je da kada neko naru?i odre?en softver želi dobiti što bolji proizvod a da cijena koju pla?a bude što manja. Zbog toga su CASE alati jako zna?ajni jer ne samo da olakšavaju programiranje nego na osnuvu njih se dobije mnogo na ušteti vremena a samim tim se štede sredstva za razvoj što na kraju dovodi do ve?eg profita. Sva ova pri?a je išla tim tokom jer se na drugoj strani nalazi kompanija ili pojedinac koji te iste proizvode izra?uju te naravno da ?e oni htjeti da uz minimalne troškove te uloženi rad i vrijeme ostvare što ve?u zaradu. Pored samog profita zan?aj CASE alata je bio i u tome što su softver zna?ajno približili široj grupi korisnika tj. smanjena je potreba za velikim predznanjem da bi se neki softver koristio jer je okruženje bilo sve više korisni?ki orjentisano.

Još jedna velika prednost kod CASE alata je što imaju sistem unutrašnje kontrole koji prakti?no re?eno provjerava sam sebe te se ne taj na?in veliki broj grešaka otkloni što predstavlja veliki plus jer se dobija softver koji funkcioniše bez problema a pored toga se ne troše sredstva na popravljanje grešaka koja su bila zna?ajna ukoliko se greške servisiraju nakon što sam program dospije na tržište. Važno je napomenuti da se CASE alati konstantno usavršavaju te se samim tim širina njihove primjene pove?ava. Pored svega toga, iako je tehnologija danas na jako visokom nivou razvijenosti nekada ni jedan sofrver ili mašina ne mogu zamjeniti iskusno mišljenje nekog programera za odre?en problem jer oni svoja rešenja temelje na iskustvu i na intuiciji kakvu ima samo ?ovjek i koja je ponekad jedino mogu?e rješenje.

LiteraturaAlempije, V., Zahorjanski, M.: Modeliranje informacionih sistema, Beograd 2016.

Dobrovi?, Ž.: Strategijsko planiranje, Zbornik radova konferencije CASE 12, Opatija 2000
Uzelac, J.: Kibernetsko upravljanje poslovnim sistemima, Ekonomski fakultet Sveu?ilišta u Rijeci, Rijeka 2002.