1. Informacioni sistem

1.1 Informacioni sistem: koncepti i definicije Informatičku eru karakteriše nov i bitno različit pristup upravljanju organizacijom i njenim poslovnim procesima. Potpuno je izmenjen značaj i vrednost materijalne i intelektualne svojine organizacije. Akcenat je u informatičkoj eri na intelektualnoj svojini i posebno informacijama i znanju. Funkcionisanje organizacije i upravljanje organizacijom i njenim procesima je postalo nezamislivo bez odgovarajućih podataka, informacija i znanja. Tako oni postaju jednako značajan resurs organizacije kakvi su sirovine, energija, radna snaga, finansije i dr. Podaci se registruju, pripremaju, unose, organizuju, čuvaju u bazama podataka informacionog sistema. Informacioni sistem organizacije iste obrađuje i obezbeđuje informacije i znanje za realizaciju poslovnih operacija i rešavanje poslovnih problema organizacije. Informacioni sistemi imaju primarni cilj da podatke na ekonomičan način obrade i transformišu u informaciju ili znanje. Stoga je potrebno u smislu njihovog razumevanja definisati ove osnovne pojmove. Podaci, elementarno opisuju stvari, događaje, aktivnosti i transakcije koji su zabeleženi, klasifikovani i uskladišteni, ali nisu organizovani da prenesu neko konkretno značenje. Oni mogu biti različitih oblika: numerički, alfanumerički, zvuci, slike i dr. i skladište se u bazu podataka, organizuju na način da se lako pronalaze. Informacije, su organizovani podaci na način da imaju značenje i vrednost za primaoca. Najčešće se podaci obrađuju aplikativnim programima, kako bi se proizvela veća njihova korisnost od one koja se postiže u slučaju direktnog i jednostavnog pozivanja iz baze podataka. Znanje, čine podaci ili informacije koji se organizuju i obrađuju da prenesu razumevanje, iskustvo, akumulirano učenje i stručnost u primeni na određeni aktuelni problem ili aktivnost. Podaci se posebno obrađuju na način da reflektuju iskustvo i ekspertizu, pruže primaocu organizaciono znanje visoke potencijalne vrednosti. Podaci, informacije i znanje su potencijalni ulazi ali istovremeno mogu biti i izlazi informacionog sistema. Postoje tri osnovna razloga za primenu informacionih tehnologija u poslovanju, koji su u neposrednoj (direktnoj) vezi sa tri vitalne uloge informacionog sistema, koje on može imati za poslovnu organizaciju. To su: podrška poslovnih procesa i aktivnosti (operativnih aktivnosti, operations) organizacije, podrška donošenju odluka od strane zaposlenih i menadžera (rukovodilaca) i podrška strategiji u realizaciji konkurentskih prednosti.

Tekst preuzet iz udžbenika Balaban N. i dr: Informacione tehnologije i informacioni sistemi, 2007., Ekonomski fakultet Subotica.

1.1. Definicije informacionog sistema

Upravljanje ma kojom organizacijom uključuje donošenje odluka i rešavanje problema, a u tu svrhu su neophodne informacije i znanja. Informacioni sistemi obezbeđuju informacije neophodne za svrhe donošenja odluka i rešavanja problema. Kao što je već rečeno, informacije potiču iz izvora unutar organizacije i izvora izvan organizacije. I jedne i druge mogu da budu obrađivane kako formalnim informacionim sistemom date organizacije, tako i njenim neformalnim sistemom. Prvobitno su računari bili upotrebljavani za "elektronsku obradu podataka" (EOP), a kada je shvaćeno da mogućnosti računara daleko prevazilaze puku obradu podataka, iskrsle su nove svrhe i novi vidovi informacionih sistema. Tako se, istorijski posmatrano, prvo javljaju upravljački informacioni sistemi (Management Information Systems - MIS), a potom sistemi za podršku odlučivanju (Decision Support Systems - DSS). Pored toga, u području veštačke inteligencije razvijani su ekspertni sistemi - ES. Potom je usledio razvoj automatizovane kancelarije (Office Automation - OA). Prema nekim shvatanjima (McLeod, 1990) svih pet navedenih osnovnih oblasti primene predstavljaju jedan celoviti sistem - informacioni sistem zasnovan na računaru (Computer-Based Information System - CBIS).

Slika 1. Istorijski pregled razvoja kompjuterizovanih poslovnih informacionih sistema

1.2. Komponente i aktivnosti informacionih sistema

Svaki informacioni sistem je sistemska celina i sklad između njegovih ključnih komponenti koje izvršavaju određene aktivnosti. Slika 2. je model informacionog sistema, koji sistemskim prilazom pokazuje koncepcijski okvir, najvažnije komponente i aktivnosti sistema. Sistem skuplja, sređuje, obuhvata i unosi podatke u proces obrade, organizuje, skladišti i održava podatke u bazi podataka i, iz organizovanih i uskladištenih podataka, derivira informacije za krajnje korisnike sistema.

Slika 2.

Model, takođe, ukazuje na relevantne odnose i objašnjava ključne veze između osnovnih komponenti i aktivnosti informacionog sistema. Može se reći da su četiri ključna koncepta implicitna u svim vrstama informacionih sistema (O’Brian, 1999 s.43):

• Ljudi, hardver, softver, podaci i računarske mreže čine pet osnovnih grupa resursa svakog informacionog sistema;

• Ljudski resurs uključuje specijaliste i korisnike IT (Information Technology), hardverski resurs obuhvata računarske uređaje i medije, softverski resurs programe i procedure, resurs podataka baze podataka i znanja i resurs mreže komunikacione medije i računarske mreže;

• Resurs podataka se transformiše aktivnostima procesiranja u različite informacione proizvode za različite krajnje korisnike i;

• Procesiranje informacija obuhvata aktivnosti: ulaz, obradu, izlaz, memorisanje i kontrolu.

Ulaz kao resurs podataka je aktivnost koja podatke o nastalim poslovnim transakcijama zahvata, priprema i unosi u sistem, odnosno, bazu podataka. Krajnji korisnici informacionog sistema nastale podatke obuhvataju, uređuju i zapisuju na medije kao što su izvorna dokumenta ili upisuju direktno na elektromagnetne medije računarskog sistema. Uneti podaci se transferišu

na mašinski čitljive medije kao što su magnetni diskovi, upisuju u bazu, čuvaju, održavaju i koriste u procesu obrade. Obrada podataka u informacije je aktivnost procesiranja: izračunavanja, upoređivanja, sortiranja, sumacije, klasifikacije i mnogih drugih operacija. U okviru ove aktivnosti podaci se čitaju sa elektromagnetnih medija, organizuju, analiziraju i manipuliše se njima, da bi se konvertovali u informacije potrebne korisnicima. Podaci u bazi podataka, u cilju njihovog kvaliteta, podležu, takođe, kontinuiranom održavanju, odnosno ažuriranju i dodavanju novih podataka, brisanju i menjanju postojećih. Izlaz informacionih proizvoda u različitim oblicima i različitog sadržaja je aktivnost čiji je cilj da zadovolji informacione potrebe korisnika različitih profila: menadžera, eksperata, tehničkog osoblja. Najčešće su informacioni proizvodi poruke, izveštaji, dokumenta, grafičke vizualizacije, koji mogu biti prezentirani korisnicima putem različitih izlaznih uređaja. Korisnici žele informacione proizvode koji poseduju odgovarajući kvalitet. Informacije koje su neaktuelne, nisu prispele na vreme, teško su razumljive i slično, nisu od velike vrednosti i upotrebljivosti za korisnike. Korisnici žele informacije višeg kvaliteta, to jest, informacione proizvode čije ih karakteristike, atributi i kvalitet čine poželjnim, korisnim i odgovarajućim za zadovoljenje informacionih zahteva korisnika. Memorisanje podataka je ključna komponenta i aktivnost informacionog sistema. Podaci i informacije stalno ostaju organizovani na određeni način, poželjnog kvaliteta i zapisani na elektromagnetnim medijima za kasnije korišćenje. Podaci i informacije su u savremenim informacionim sistemima organizovani kao baze podataka. Kontrola performansi sistema je, takođe, veoma važna aktivnost informacionih sistema. Kontrola ulaza, obrade, izlaza i memorisanja podataka, odnosno informacija, se obezbeđuje odgovarajućom povratnom spregom o stanju, procesima i kvalitetu ovih aktivnosti. Povratnom spregom mora se kontrolisati i ocenjivati sistem sa stanovišta uspostavljenih standarda performansi uz stalno poravnavanje da bi kvalitet informacionih proizvoda bio zadovoljavajući i prihvatljiv za korisnike. 1.3. Resursi informacionih sistema

Informacioni sistem je sociotehnički sistem koji upotrebljava, organizuje i efektivno i efikasno koristi određene resurse. Resursi informacionog sistema su: ljudski resursi, hardverski resursi, softverski resursi, resursi podataka i resursi računarskih mreža. Ljudski resursi su neophodni za funkcionisanje informacionih sistema. IT specijalisti i krajnji korisnici IS čine ljudske resurse. IT specijalisti su ljudi koji razvijaju, implementiraju, ocenjuju i održavaju IS. Ljudski resursi su organizovani u IC (Informacionom centru) i zavisno od dimenzija organizacione strukture IC, a pre svega od podele rada, mogu biti: projektanti informacionih sistema, sistem analitičari, programeri, administratori baza podataka, softver inženjeri, specijalisti za hardver i mreže, operateri i drugi. Stručnjaci ovih profila vrše određene poslove, izvršavaju konkretne radne zadatke. Krajnji korisnici su ljudi koji koriste informacioni sistem i

njegove informacione produkte u svakidašnjem radu. To mogu biti menadžeri, analitičari, inženjeri, istraživači, komercijalisti, računovođe, tehničko osoblje i drugi. Većina zaposlenih u organizaciji su krajnji korisnici informacionog sistema. U hardverske resurse spadaju celokupni računarski resursi koji tehnički podržavaju rad informacionog sistema. Računarski sistemi: serveri baza podataka (veliki i računari opšte namene), serveri aplikacija (mini računari), radne stanice (mikro računari), periferne jedinice (štampači, tastature, monitori, magnetni i optički čitači i drugi), elektromagnetni mediji za smeštaj podataka (diskovi, diskete, optički diskovi, magnetne trake), zajedno čine integralnu tehničku podršku i hardverski resurs informacionih sistema. Softverski resursi uključuju sve vrste programskih instrukcija i procedura. Operativni sistemi, programi prevodioci, sistemi za upravljanje bazama podataka, statistički paketi, OLAP softver i mnogi korisnički programi (aplikativni softver) predstavljaju resurs informacionih sistema od ogromnog značaja i značajnu intelektualnu investiciju organizacije. Niz procedura koje upućuju korisnika kako da koristi svoj IS, su takođe značajan softverski resurs. Podaci, informacije i znanje su resurs ne samo IS, nego i organizacije, podjednako važan kao i drugi resursi. Ovaj resurs se često organizuje u bazama podataka (podaci i informacije), dimenzionalnim bazama podataka u Data Warehouse (ekstrahirani i agregirani podaci i informacije), bazama znanja, Knowledge Warehouse i dr. Resursi računarskih mreža, lokalnih i globalnih, sa aktivnom i pasivnom mrežnom opremom, uređajima i instalacijama, su okosnica telekomunikacionog podsistema informacionog sistema. Telekomunikacione mreže, kao što su intranet, ekstranet i Internet, su postale neminovnost uspešnog funkcionisanja organizacije i integralnih informacionih sistema. Ovi resursi uključuju: a) komunikacione medije, kao što su koaksijalni kablovi, fiber-optički kablovi, mikrotalasni sistemi, satelitski komunikacioni sistemi i drugi, b) mrežnu opremu: ruteri, svičevi, modemi, habovi, razne vrste priključaka i druga mrežna oprema, i c) komunikacioni kontrolni softver.

1.4. Vrste informacionih sistema

Razvijeno je mnoštvo različitih informacionih sistema zasnovanih na računarima - computer- based information systems (CBIS) s različitim funkcionalnim svojstvima: a) upravljački informacioni sistemi - management information systems (MIS); b) informacioni sistemi za izvršno rukovodstvo - executive information systems (EIS); c) sistemi za podršku odlučivanju izvršnog rukovodstva - executive support systems (ESS); d) sistemi za podršku odlučivanju - decision support systems (DSS); e) sistemi za podršku grupnom odlučivanju group decision support systems (GDSS); f) elektronski sistemi za održavanje sastanaka - electronic meeting systems (EMS); g) sistemi za podršku odlučivanju organizacije - organizational decision support systems (ODSS);

h) ekspertni sistemi - expert systems (ES); i) informacioni sistemi kancelarije - office information systems (0IS); j) inteligentni informacioni sistemi organizacije - intelligent organizational information systems (I0IS) i dr. G. Mentzas (Mentzas, 1994) je s ciljem uvećanja preciznosti klasifikovanja informacionih sistema zasnovanih na računarima preduzeo domišljat pokušaj da razvije osnovni okvir za njihovu funkcionalnu taksonomiju. On je ispitao i klasifikovao deset informacionih sistema zasnovanih na računarima u trodimenzionalnom prostoru s obzirom na veličinu podrške koju pružaju trima vrstama procesa: informacionim procesima, procesima odlučivanja i komunikacionim procesima. Pored ostalog, Mentzas je klasifikovao informacione sisteme zasnovane na računarima prema stepenu podrške koju pružaju na nivou individue, nivou grupe i nivou organizacije, što je prikazano u Tabeli 2-4:

Prema jednom stanovištu savremeni informacioni sistemi organizacije bazirani na i podržavani informatičkim tehnologijama mogu se podeliti na: operativne informacione sisteme i sisteme za podršku menadžmenta/menadžerski IS. 1.4.1. Operativni informacioni sistemi

Informacioni sistemi koji su namenjeni za obradu podataka nastalih u poslovnim i tehnološkim procesima i koji obezbeđuju podatke i informacije za poslovne operacije, nazivaju se operativnim informacionim sistemima. Uloga ovih sistema je podrška unapređenju i efikasnom izvršavanju poslovnih transakcija, kontrola tehnoloških procesa, automatizacija poslova u kancelarijama, podrška u kreiranju, distribuciji i korišćenju znanja, podrška komunikaciji i saradnji u organizaciji, formiranje i održavanje integralne baze podataka organizacije.

OLTP sistemi (On Line Transaction Procesing System) su sistemi koji trenutno obrađuju podatke nastale u poslovnim transakcijama. U toku dana se obrade milioni različitih poslovnih transakcija i automatski izvrši ažuriranje velikih baza podataka. Ovi sistemi su bazirani na relacionoj tehnologiji i koriste najsavremenije tehnike računarstva. Tipični poslovni procesi su, na primer, ovi: obrada porudžbenica, fakturisanje, kontrola zaliha, obrada zarada, prodaja robe u trgovinskim objektima, obrada transakcija u bankarskom poslovanju i slično. Dakle, OLTP omogućavaju automatizaciju odvijanja poslovnih procesa, aktivnosti, poslova, radnih zadataka i operacija. Oni su, takođe, osnova i sredstvo za razvoj sistema koji podržavaju odlučivanje u menadžmentu. Teško je, zapravo, pretpostaviti i praktično je neostvariva zamisao razvoja

upravljačkih informacionih sistema, Data Warehouse-a, sistema poslovne inteligencije i drugih, a da organizacija nije prethodno razvila i implementirala OLTP. 1.4.2. Menadžerski informacioni sistemi

Menadžerski informacioni sistemi su sistemi podrške odlučivanju u menadžmentu. Oni mogu biti: MIS (Management Information Systems), DSS (Decision Support Systems) i EIS (Executive Support Systems).

MIS - MIS je klasični upravljački informacioni sistem, koji pripada drugoj razvojnoj fazi informacionih sistema. Javlja se kao odraz potrebe da se menadžmentu na adekvatan način obezbede neophodne informacije za odlučivanje i upravljanje; pre svega, za donošenje operativnih i taktičkih odluka. Oni obezbeđuju menadžere i druge korisnike informacijama, koje su im neophodne u svakodnevnom donošenju menadžerskih odluka. Proizvode veoma mnogo različitih izveštaja koje su menadžeri na osnovu istraživanja njihovih informacionih potreba unapred definisali. Ovi sistemi pretražuju informacije o internim operacijama iz baza podataka i kontinuirano ih ažuriraju OLTP sistemima. Oni, takođe, obezbeđuju mnogo korisnih podataka i informacija o relevantnom okruženju organizacije, koji dolaze iz eksternih izvora. Na primer, menadžer prodaje može: a) koristiti web brauser da bi primio neposredno i u realnom vremenu vizuelne prikaze, na svojoj radnoj stanici, informacije o prodaji pojedinih proizvoda, različitim kupcima, b) pristupiti nedeljnim, mesečnim, kvartalnim ili drugim analitičkim izveštajima koji omogućavaju ocenjivanje rezultata prodaje, odnosno, postignuća njegovog odeljenja u domenu prodaje različitih proizvoda, različitim kupcima, na različitim tržišnim segmentima.

DSS - Pod sistemima podrške odlučivanju (DSS) se podrazumevaju interaktivni, na računarima zasnovani, informacioni sistemi koji se koriste sofisticiranim modelima anlalize podataka, modelima odlučivanja i specijalizovanim bazama podataka sa svrhom podržavanja procesa polustrukturisanog i nestrukturisanog menadžerskog odlučivanja (O’Brian, 1999, s.61) (Laudon & Laudon, 2000 s.44). DSS se, s jedne strane, razlikuju od sistema transakcione obrade podataka, koji su usredsređeni na obradu podataka generisanih poslovnim transakcijama i operacijama, a s druge strane, od MIS, koji su usredsređeni na obezbeđivanje unapred specifikovanih informacija – izveštaja za menadžere, koji bi trebalo da pomognu u procesu pretežno strukturisanog donošenja efektivnih upravljačkih odluka, dok DSS omogućavaju menadžerima analitičko modelovanje, simulacije, eksploracije mogućih alternativa i dr. (O’Brian, 1999, s.61-62). Sistemi podrške odlučivanju imaju veću analitičku moć od drugih sistema, jer se koriste mnoštvom sofisticiranih modela analize i mogu sažimati ogromne količine podataka u formu koju donosioci odluka mogu lako tumačiti i razumeti. Ovi sistemi su tako oblikovani da se donosioci odluka njima mogu neposredno koristiti, a softver je izrazito "userfriendly". Sistemi podrške odlučivanju se koriste u interaktivnom načinu i na ad hoc osnovi – korisnik može menjati pretpostavke, postavljati nova pitanja, uključivati nove podatake (Laudon & Laudon, 2000 s.44-45). EIS - EIS su kategorija informacionih sistema, namenjeni za podršku odlučivanju izvršnim menadžerima, odnosno, vrhovnom menadžmentu organizacije, mahom da bi zadovoljavali

strategijske informacione potrebe. Uzimaju podatke iz mnogih izvora, agregiraju ih, kompariraju, analiziraju raznovrsnim analitičkim postupcima i vrše njihovu vizualizaciju prema zahtevima menadžera. Obezbeđuju selektivno, brzo i lako razumljive informacije o ključnim faktorima koji su kritični za postizanje strategijskih ciljeva organizacije. Mnogi ih smatraju podskupom DSS. Ovi glavni tipovi informacionih sistema na različitim organizacionim nivoima međusobno razmenjuju podatke a pri tom je sistem transakcione obrade podataka osnovni izvor za ostale informacione sisteme. Sve je izrazitija potreba za odjedinjavanjem, integrisanjem različitih tipova informacionih sistema u organizaciji i sve je uočljiviji holistički pristup organizaciji I njenim informacionim sistemima. 1.5 Integracija informacionih sistema

Informacioni sistem organizacije treba da je integralan, da integriše sve funkcije, procese i sve vrste informacionih sistema. Integracija se postiže, pre svega, kroz kompozitni ili cross/function sistem, koji daje potporu svim poslovnim funkcijama, procesima, aktivnostima, operacijama i podržava odlučivanje svih nivoa menadžmenta i koji ima integrisane informacione resurse koje koriste sve aplikacije i korisnici. Mnogi autori smatraju da MIS uključuje sve navedene vrste informacionih sistema. Međutim, prema nekim shvatanjima (McLeod, 1990; Laudon & Laudon, 2000), sve navedene osnovne vrste IS i oblasti primene IT predstavljaju doista jedan celoviti sistem - informacioni sistem zasnovan na računaru (Computer-Based Information System - CBIS). CBIS se u tom kontekstu koristi kao "kišobran" za sve vrste informacionih sistema podržavanih informatičkim tehnologijama.

1.2 Informacioni sistem: klasifikacija

Tekst dat u posebnom fajlu (Turban_IS.pdf)

1.3 Način obezbeđenja informacionog sistema Razvoj informacionog sistema u organizaciji sa sopstvenim resursima odnosno zaposlenim

specijalistima za informacione sisteme, je najčešće korišćena strategija u razvoju informacionog sistema. I pored toga, ona se mora prilikom svakog opredeljenja detaljno razmotriti iz različitih uglova i aspekata, kao jedna od mogućih alternativa, jer je veoma često neizvodiva. Razlozi zbog kojih se i druge strategije obezbeđenja informacionog sistema moraju uzeti u razmatranje su sledeći:

a. Broj specijalista za informacione sisteme u organizaciji, koji se može angažovati u razvoju informacionog sistema, je uobičajeno nedovoljan da bi im se poverio celovit proces razvoja. Čak i kada je njihov broj dovoljan, većina je previše uposlena na održavanju postojećeg sistema ili pružanju pomoći korisnicima u rešavanju njihovih svakodnevnih problema. Stoga se u razvoju informacionog sistema sopstvenim resursima angažuje i veći broj specijalista iz okruženja, međutim oni značajno poskupljuju proces razvoja.

b. Specijalisti za informacione sisteme u organizaciji veoma često ne poseduju neophodna znanja i veštine potrebne za razvoj određenog tipa informacionog sistema. Naravno da se u okruženju mogu

pronaći specijalisti sa odgovarajućim u organizaciji nedostajućim znanjima i veštinama, ali ovo rešenje takođe značajno povećava troškove razvoja.

c. Specijalisti za informacione sisteme u organizaciji su prezaposleni i nemaju dovoljno vremena da razviju sve komponente sistema koji se u organizaciji zahtevaju. Stoga se komponente rangiraju i utvrđuje im se prioritet jer uobičajeno nisu sve od strateškog značaja sa efektima na celu organizaciju, već mogu biti od minorne koristi i sa efektima na organizacioni deo ili samo deo zaposlenih u organizacionom delu. Rešenje u ovakvim kompleksnim situacijama bi morao dati rukovodilac organizacione jedinice za informacione sisteme, vodeći pri tome računa da se svi korisnici informacionog sistema podjednako podrže, čak i kada se većina specijalista angažuje na komponentama sistema sa najvišim prioritetom.

d. Razvoj informacionog sistema je proces veoma visokog stepena rizika. Promenljivi korisnički zahtevi, razvoj i uvođenje novih tehnologija, ograničenja budžeta i fluktuacija zaposlenih su samo neki od razloga mogućeg neuspeha. Istovremeno, veoma je teško predvideti bližu ili dalju budućnost procesa i njegovih rezultata, odnosno kako će sistem izgledati ili bi mogao da izgleda na završetku procesa.

Alternative razvoju informacionog sistema sopstvenim resursima mogu biti: obezbeđenje gotovog rešenja informacionog sistema izvan organizacije, "outsourcing" i razvoj informacionog sistema od strane korisnika (korisnički razvoj). Kupovina gotovog postojećeg rešenja informacionog sistema od dobavljača predstavlja alternativu obezbeđenja rešenja informacionog sistema izvan organizacije. Realizacija ove alternative podrazumeva prethodnu analizu finansijskih sredstava koja će se za ovu namenu utrošiti i zahteva koji će se kupovinom zadovoljiti. Ukoliko je prethodna analiza detaljnija i sadržajnija, ona značajno pomaže u smanjivanju potencijalnog broja mogućih opcija za nabavku, a time i skraćenju vremena potrebnog za izbor. Naime, upoređenjem ponuđenih rešenja informacionog sistema na tržištu sa identifikovanim zahtevima organizacije, omogućuje se izbor onog rešenja koje od svih mogućih najviše i najbolje zadovoljava potrebe. Sigurno je veliki broj postojećih rešenja koja mogu kvalitetno zadovoljiti identifikovane zahteve organizacije, pa je evaluacija neophodna. Veoma često se koriste i test mogućnosti da bi se informacioni sistem proverio u neposrednom okruženju organizacije, kao i da bi se videla reakcija potencijalnih korisnika na budući sistem. Tako se na najbolji način ocenjuje obim zadovoljenja zahteva organizacije i smanjuje rizik uvođenja odabranog sistema. Postupak u obezbeđenju gotovog rešenja informacionog sistema izvan organizacije se realizuje putem nekoliko koraka. Najčešće, to su sledeći koraci koji se izvode kako bi organizacija obezbedila najbolje rešenje po najnižoj ceni: � Identifikacija, selekcija i planiranje sistema � Analiza sistema � Razvoj "request for proposal" (zahtev za ponudom) � Vrednovanje ponuda � Izbor dobavljača Prva dva koraka su identična i nezavisna od toga da li se informacioni sistem razvija sopstvenim resursima ili se obezbeđuje kao gotovo rešenje izvan organizacija. Tek u trećem koraku se dve strategije odnosno alternative razlikuju. Razvoj zahteva za ponudom ili predlogom je izveštaj kojim se dobavljaču od strane organizacije saopštavaju zahtevi i traže od njega informacije na koji način će postavljene zahteve zadovoljiti. Zahtev

se dostavlja svim potencijalnim dobavljačima koji bi mogli biti isporučioci informacionog sistema. Sadržaj zahteva za ponudom čine: pregled i opšti prikaz postojećeg sistema i aplikacija; zahtevi u pogledu pouzdanosti, zaštite i servisa; zahtevi u pogledu performansi i karakteristika sistema; pregled kriterijuma na osnovu kojih će se izvršiti vrednovanje ponuda; vremenska ograničenja budžeta. Nakon što se zahtev prosledi, povratno može uslediti veliki broj ponuda dobavljača koje treba evaluirati ili mali broj ponuda pa je potrebno ponovno analizirati zahteve. Uobičajeno su zahtevi mnogo veći nego što su raspoloživa sredstva (budžeta) za njihovo zadovoljenje ili su vremenski rokovi jako ograničeni (kratki) pa ih je potrebno revidirati. Vrednovanje (Ocena) ponuda je četvrti korak u kojem se detaljno analiziraju elementi ponude svakog dobavljača. Ocena može uključivati prikaz (demonstraciju) sistema, ocenu njegovih performansi, ispitivanje kriterijuma značajnih za organizaciju i odlučivanje (prosuđivanje) koliko ponuđeni sistem zadovoljava kriterijume. Prikaz sistema je pogodan način da se osete pogodnosti koje pojedini sistemi pružaju. Članovi tima dobavljača, prikazuju osobine sistema, troškove i način njegovog funkcionisanja. Prezentacija se može odvijati u organizaciji ili kod dobavljača odnosno neposredno nekog od korisnika njegovog sistema. Prezentacija je korisna i pomaže da se razumeju karakteristike različitih sistema, ali je nedovoljna da bi se izvršilo konačno opredeljenje. Tako se najčešće izvodi benchmarking-a, koji predstavlja upotrebu standardizovanog testa performansi u komparaciji sistema. Komparira se brzina izračunavanja, brzina pristupa podacima u bazi podataka unapred definisanog broja korisnika, vreme sortiranja, vreme pretraživanja, vreme izrade datog izveštaja, vreme čitanja seta podataka i dr. Ovi podaci se mogu pronaći i u popularnim časopisima iz ove oblasti kao i web stranama udruženja. Konačno u upotrebi su i prethodno pominjani i posebno definisani kriterijumi koji se odnose na hardver, softver i ostalo. Izbor dobavljača je poslednji korak u procesu obezbeđenja gotovog rešenja informacionog sistema izvan organizacije. Uobičajeno, više informacionih sistema zadovoljava postavljene zahteve, stim da neki to čine bolje, dok drugi slabije. Upravo zbog toga se definiše način njihovog rangiranja. Najčešći oblik je putem unapred definisanih kriterijuma, kojima se veličinom njihove apsolutne vrednosti daje odgovarajući značaj u rangiranju. U prikazanom primeru na slici 9.25 iz 70572 se vidi da je najbolji informacioni sistem za organizaciju onaj koji ima najveću sumu dobijenih vrednosti po pojedinim kriterijumima. Prikazani proces izbora dobavljača je potpuno formalizovani proces, mada se u praksi primenjuju i manje formalizovani (kontrolni popis ili checklist) čak i potpuno subjektivni procesi izbora. "Outsourcing" – je druga alternativa obezbeđenja gotovog rešenja informacionog sistema izvan organizacije. Prethodno opisanom alternativom, organizacija se opredeljuje i kupuje jedan sistem od dobavljača. Međutim, "outsourcing" je praksa kojom se prenosi odgovornost za razvoj celog sistema ili samo njegovih komponenti na spoljnu organizaciju. To je način korišćenja usluga spoljne organizacije u razvoju informacionog sistema umesto angažovanja sopstvenih resursa. Spoljna organizacija može razviti ceo ili komponente informacionog sistema i instalirati ih na svoj računar ili na računar organizacije naručioca. Danas je ovaj vid obezbeđenja informacionog sistema veoma popularan, a zasniva se na ugovornom odnosu kojim se preciziraju svi neophodni detalji ugovorenih usluga. Za ovo rešenje se organizacije opredeljuju jer im je nepraktično i neekonomično da se u razvoju informacionog sistema oslonjaju uglavnom na sopstvene resurse, obzirom na teškoće koje se učestalo javljuju kod zapošljavanja većeg broja angažovanih na projektu nakon implementacije informacionog sistema. Alternativa “outsourcing”-u je zajedničko izvršenje aktivnosti razvoja u kojem učestvuju pored zaposlenih iz spoljne organizacije i zaposleni specijalisti za informacione sisteme iz organizacije naručioca odnosno interno osoblje.

"Outsourcing" se koristi iz sledećih razloga: � Spoljna organizacija je specijalizovana da pruži odabrane usluge višeg nivoa kvaliteta uz niže troškove

od internog osoblja. � Spoljne organizacije su uobičajeno veoma moćne organizacije koje lako pridobijaju rukovodioca

organizacione jedinice za informacione sisteme da im prepusti razvoj pojedinih ili svih funkcionalnosti informacionog sistema.

� Interno osoblje ne poseduje fleksibilnost i stručnost kako bi pratilo učestale promene na tržištu i implementiralo rešenja koja zahtevaju nove i još nedovoljno ispitane tehnologije;

� Spoljna organizacija može da zadovolji potrebe organizacije naručioca na vreme i na zahtevani način; � Spoljna organizacija može obezbediti usluge konzistentne sa zahtevima organizacije naručioca; � Politički i organizacioni problemi, koji su teški za premošćavanje od specijalista za informacione

sisteme u organizaciji, se lako rešavaju u "outsourcing"-u. � Tenzije između krajnjih korisnika i specijalista za informacione sisteme se značajno smanjuju ili čak

eliminišu, prebacujući razvoj na spoljnu organizaciju, ali se javlja novi antagonizam krajnjih korisnika i isporučilaca usluga razvoja informacionog sistema.

� Orijentacija na "outsourcing" usluge omogućuje organizacijama naručiocima da se fokusiraju samo na osnovnu delatnost u poslovanju.

Postoji više potencijalnih područja za “outsourcing” usluga u razvoju informacionog sistema. Njihov obim se kreće od kompletnog “outsourcing”-a razvoja svih funkcionalnosti sistema do “outsourcing”-a komponenti sistema, što zavisi od zahteva organizacije naručioca. U nastavku se navode funkcije koje mogu biti realizovane sa internim osobljem u odnosu na one koje mogu biti realizovane putem “outsourcing”-a.

a) Funkcije koje se realizuju putem internog osoblja:

� Koordinacija projekta između naručioca i “outsourcing” isporučioca; � Obezbeđenje kvaliteta kroz životni ciklus razvoja sistema; � Definisanje funkcionalnih zahteva; � Razvoj logičkog dizajna za aplikacije; � Upravljanje “outsourcing” isporučiocima.

b) Funkcije koje se realizuju putem “outsourcing” isporučioca:

� Izgradnja sistema; � Implementacija sistema; � Testiranje aplikacija; � Obuka za korišćenje aplikacija; � Izrada sistemske i korisničke dokumentacije; � Održavanje i unapređenje sistema; � Integracija sistema. Ako se ispravno planira i upravlja uslugama, “outsourcing” nudi brojne prednosti naručiocu: � Troškovi usluga mogu biti predviđeni i fiksni tokom određenog vremenskog perioda. “Outsourcing”

usluge mogu biti unapred precizno definisane i merene. � Naručilac usluga ima mogućnost da se fokusira samo na osnovnu delatnost poslovanja. Za potrebe

upravljanja zahtevima informacionih sistema se posebno angažuje isporučilac usluga, koji treba da omogući da se performanse i nivoi usluga obezbede pravovremeno i na troškovno efektivan način.

� Nivoi usluga se mogu kontrolisati na regularnim osnovama.

� Ako se radno opterećenje povećava nije neophodno povećanje broja zaposlenih. Spoljna organizacija obezbeđuje fleksibilnost organizaciji naručiocu da izvede dodatni rad ako postoji povećana poslovna aktivnost. Partnerski pristup sa isporučiocem “outsourcing”-a obezbeđuje mogućnost prenošenja viška radnog opterećenja, ako postoji prihvatljiv nivo usluga po konkurentnoj ceni.

� Ugovorene usluge mogu se često proveravati, npr. svake ili svake druge godine. Po isteku ugovora sa spoljnom organizacijom vrši se analiza dobijenih usluga. Trajanje ugovora zavisi od više faktora (tip usluge, troškovi i rizik koji su povezani sa promenom spoljne organizacije, pouzdanost spoljne organizacije u pogledu ispunjenja obaveza).

� Obračun usluga može biti direktno povezan sa njihovim performansama i nivoima. Neprihvatljive performanse trebale bi biti predmet novčanog kažnjavanja. Spoljna organizacija treba da obezbedi usluge po tržišnoj ceni. Kako su usluge određene i merljive, važno je da se njihovi nivoi prate i da se o njima dobija izveštaj. Tipične mere nivoa usluge su: blagovremenost, dostupnost, vreme odziva i kvalitet.

(1) Blagovremenost - Ako se ugovorom o održavanju zahteva da se usluga izvrši u roku od četiri sata od momenta prijavljivanja, onda ova aktivnost može biti merena i o njoj izrađen izveštaj. Ukoliko nivo usluge nije zadovoljen, mogu biti određene novčane kazne.

(2) Dostupnost – Ako se ugovorom zahteva da usluge isporučioca budu raspoložive 24 časa na dan, 7 dana u sedmici onda dostupnost može biti merena i praćena. U slučaju neispunjenja usluge aktiviraju se novčane kazne.

(3) Vreme odziva - Ovo je takođe značajna mera za određivanje efikasnosti usluga i treba biti sastavni deo ugovora. Moguće ju je izmeriti i pratiti.

(4) Kvalitet - Mada je teško izmeriti nivo kvaliteta usluge, on se određuje na osnovu iskustva korisnika. Kvalitet uključuje: odgovornost i obim ispunjenja zahteva, sposobnost ispunjenja dogovorenih vremenskih rokova, pripremljenost korisnika za promene pre nego što se softversko rešenje implementira, nivo iztestiranosti proizvoda pre uvođenja, obezbeđenost podrške putem servisa za rešavanje problema itd. Kvalitet usluge se može izmeriti anketiranjem, npr. jednom godišnje treba odrediti neko područje problema i omogućiti da se o njemu vodi rasprava.

Nedostaci "outsourcing"-a se sistematizuju na sledeći način: � Troškovi “outsourcing”-a se povećavaju kroz duži vremenski period ako spoljna organizacija u

određenom momentu potraži dodatne prihode. � Spoljna organizacija može zahtevati dodatna sredstva za ispunjenje zahteva koji nisu predviđeni

ugovorom. � Može se stvoriti problem prilikom prenošenja znanja sa spoljne organizacije na korisnika, a to se

najčešće dešava kada spoljna organizacija nije kooperativna. � Mogu nastati teškoće u merenju i upravljanju kvalitetom. � Sa većim obimom posla koji se prenosi na spoljnu organizaciju povećava se mogućnost da neki od

interesantnijih poslova bude otuđen, a to može uticati na pad morala zaposlenih u organizaciji naručiocu.

� Spoljna organizacija može zadržati kontrolu iznad određenog nivoa i kvaliteta usluga. � Pojavljuje se veći rizik u realizaciji, ukoliko dođe do promena u spoljnoj organizaciji. � Kada organizacija naručilac odluči da promeni spoljnu organizaciju tada ista podiže cene svojih usluga

(cena konverzije i migracije, cena obuke, cena koordinacije i dr.). Treća alternativa obezbeđenja informacionog sistema je razvoj informacionog sistema od strane

korisnika (korisnički razvoj). To je poslednja alternativa, u kojoj korisnici samostalno razvijaju aplikacije

koje će sami koristiti. Pri ovoj alternativi, specijalisti za informacione sisteme u organizaciji, pomažu i ubrzavaju takav razvoj. Ovakav razvoj, poseduje prednosti ali i nedostatke. Prednosti korisničkog razvoja su: � Troškovi radne snage se snižavaju, ukoliko se korisnicima pruže sredstva koja su im potrebna i sa

kojima oni samostalno obavljaju aktivnosti razvoja, uz eventualna uputstva i usluge organizacionog dela za informacione sisteme.

� Vremenski period razvoja se skraćuje, posebno zbog toga što se uočeni problemi tokom razvoja rešavaju mnogo brže jer ih uočava i otklanja ista osoba – korisnik.

� Održavanje postojećeg sistema je pojednostavljeno i brže. Naime, razvoj uvek ima prioritet u odnosu na održavanje, tako da se često sistem koristi na takav način da ne zadovoljava korisničke potrebe. Prepuštanjem održavanja korisniku, on je više zainteresovan i prioritet su mu aplikacije koje neposredno upotrebljava da održava u stanju potrebnom za poslovanje.

� Povećava se broj onih koji učestvuju u razvoju informacionog sistema, a na taj način smanjuje njihov obim angažovanja. Ova konstatacija se posebno odnosi i na zauzetost specijalista za razvoj informacionog sistema.

Sigurno da je ova alternativa razvoja sistema posebno dobila na značaju od pojave jezika četvrte generacije. Ipak, uz brojne prednosti, treba naznačiti i neke nedostatke. Među prvima je problem primene standarda u razvoju, koje specijalisti nalažu, a koje većina krajnjih korisnika zanemaruje ili o njima ne vodi brigu. Odsustvo standarda samo po sebi nije problem dok se pojedine aplikacije ne pokažu nesigurne sa aspekta podataka, kada se ispoljava problem. Takođe, nedostatak kontinuiteta u razvoju, može predstavljati nedostatak ove alternative razvoja. U različitim delovima organizacije, mogu biti razvijene slične ili iste aplikacije, različitog nivoa složenosti za obavljanje istih ili sličnih poslova. Da bi se ovaj problem sveo na najnižu moguću meru, u organizacijama se formiraju informacioni centri koji koordiniraju ovakav korisnički razvoj informacionog sistema.

2. Proces razvoja informacionih sistema

Proces razvoja informacionih sistema čini uređeni skup zadataka odnosno niz koraka koji uključuju aktivnosti, ograničenja i resurse u razvoju informacionih sistema. To je kompleksan i kreativan proces koji je zasnovan na razvojnim principima, a uobičajeno uključuje metode, tehnike i sredstva. Takođe, proces poseduje određene karakteristike, od kojih je bitno istaći sledeće:

� proces propisuje sve glavne aktivnosti razvoja,

� proces koristi resurse koji su uvek na određeni način ograničeni i rezultira međuproizvodima i gotovim proizvodima,

� proces može da se sastoji od međusobno povezanih potprocesa, koji mogu biti u hijerarhiji,

� aktivnosti procesa poseduju uslove za pokretanje i terminiranje, kao i uputstva koja objašnjavaju ciljeve i način njihovog izvršavanja,

� aktivnosti su organizovane u sekvence, tako da je jasno kada se jedna aktivnost izvršava u odnosu na drugu,

� procesi poseduju ograničenja i kontrole koje se primenjuju na aktivnosti, resurse ili proizvod.

Procesi omogućavaju strukturisanje i konzistentno predstavljanje aktivnosti. Njihovo postojanje je višestruko značajno, jer omogućuje da se jednom dobro izvršene aktivnosti u razvoju ponove neograničeni broj puta, kao i da se pozitivna i negativna iskustva u izvršenju aktivnosti evidentiraju radi izmene već primenjenih procesa u budućnosti. Proces je složeniji pojam od procedure, koja je ustvari recept ili uređeni način kombinovanja metoda, tehnika i alata u cilju izrade proizvoda. Proces je uređeni skup procedura, organizovanih da bi se njihovom realizacijom dobio proizvod unapred postavljenih ciljeva i standarda. Proces može sugerisati izbor između više različitih procedura, sve dok se njihovom realizacijom može ostvariti postavljeni cilj.

Koristeći se analogijom sa živim organizmima smatra se da informacioni sistemi nastaju, rastu, sazrevaju i nestaju, pa se taj proces naziva izrazom "životni ciklus sistema", koji u pojedinim slučajevima može trajati samo nekoliko meseci, a u drugim nekoliko godina.

Procesi izrade nekog proizvoda, pa i softvera kao jedne od komponenti strukture informacionog sistema, se nazivaju životni ciklus razvoja softvera jer opisuje njegov "život" od planiranja, analize, projektovanja (dizajna), implementacije do održavanja.

Proces razvoja informacionih sistema mogao bi se uopšteno opisati putem sledećih faza odnosno aktivnosti:

� Identifikacija i izbor projekata

� Inicijalizacija i planiranje projekta

� Analiza sistema

� Projektovanje / Dizajn sistema

� Implementacija sistema

� Održavanje sistema

� Identifikacija i izbor potencijalnih projekata – Izvor potencijalnih projekata su: pojedinci koji upravljaju poslovnim područjima ili organizacionim delovima, pojedinci specijalisti i grupe za planiranje. Putem različitih metoda i tehnika se pokušavaju identifikovati potencijalni projekti značajni za razvoj u organizaciji. Pri tome, nekonzistentni projekti sa opštim organizacionim ciljevima i projekti redundantni po funkcionalnosti se odmah odbacuju. Sigurno da se na ovaj način identifikuje veliki broj potencijalnih projekata, od kojih bi trebalo odabrati one koji će se realizovati. Da bi izbor bio kvalitetan, neophodno je projekte klasifikovati i rangirati. Prilikom klasifikacije i rangiranja upotrebljavaju se brojni kriterijumi: potencijalna korist, raspoloživost resursa, veličina i vreme trajanja projekta, potencijalni rizik, strateška usklađenost, organizaciono okruženje i dr. Po obavljenoj aktivnosti projekti se prihvataju, odbacuju ili uslovno prihvataju sa obavezom da se dorade.

� Inicijalizacija i planiranje projekta – Najznačajnije aktivnosti inicijalizacije su: izgradnja projektnog tima, izgradnja plana projekta, izgradnja upravljačkih procedura, izgradnja okruženja za upravljanje projektom. Planiranje projekta pak podrazumeva: opis područja projekta, alternativa, izvodljivosti, strukturiranje na zadatke koji se mogu izvesti, procena potrebnih resursa, razvoj programa, razvoj plana komunikacija, identifikovanje i procena rizika, postavljanje osnovnog plana projekta i dr. U ovoj fazi razvoja se generiše najopštiji pogled na osnovnu strukturu željenog projekta razvoja softvera i određuju njegovi najopštiji ciljevi, koji će poslužiti za definisanje informacionih zahteva u narednoj fazi. Ocenjuje se izvodljivost i rizici na projektu. Studija izvodljivosti služi da se projekat

prezentira top menadžmentu, kako bi se pridobila njihova naklonost u realizaciji odnosno finansiranju. Projekti se tipično ocenjuju sa aspekta ekonomske, operativne i tehničke izvodljivosti. Planiranje projekta razvoja takođe služi da bi se lakše pratila njegova realizacija i ocenila uspešnost izvršenja pojedinih aktivnosti projektantskog tima. Rezultati faze su: plan upravljanja konfiguracijom softvera, plan obezbeđenja kvaliteta softvera i plan projekta sa detaljnim spiskom aktivnosti (programom).

� Analiza sistema: Ovom fazom se u planu definisani ciljevi razvoja prevode u jedan ili više korisničkih zahteva. Na taj način se definišu glavne funkcije budućih softverskih aplikacija, operativna područja podataka i inicijalni entiteti podataka. Glavne funkcije uključuju kritične procese poslovnog sistema, kritične inpute, outpute i izveštaje koje je neophodno obezbediti. Pre svega se raznim dijagramima analizira postojeće stanje po delovima (segmentima) sistema. Analiza i definisanje zahteva je faza u kojoj se identifikuju problemi koje je potrebno rešiti novim softverskim proizvodom. Aktivnosti u ovoj fazi su: identifikacija zahteva, analiza i predstavljanje zahteva i razvoj kriterijuma i procedura za prihvatanje novog softverskog proizvoda. Posebno je bitno istaći neophodnost učešća budućih korisnika u konačnom definisanju zahteva. Rezultati ove faze su: dokumenat (specifikacija) zahteva koji sadrži kompletne i detaljne opise svih zahteva softveru, matrica povezanosti dokumenata koja prethode i koja slede u realizaciji zahteva Requirements Traceability matrix (RTM) i ažuriran plan projekta.

� Dizajn sistema: U ovoj fazi se na osnovu identifikovanih zahteva i specifikacije funkcija struktuira softverski proizvod na takve delove kojima se može upravljati, a koji predstavljaju logičke celine. Za svaki identifikovani zahtev u dokumentu (specifikaciji) zahteva se projektuje niz elemenata dizajna. Oni detaljno opisuju osobine budućeg informacionog sistema: funkcije, operacije, ulazne ekranske forme, bazu podataka, izlaze, procesna pravila ili procedure putem kojih se potrebni ulazi podataka transformišu u zahtevane izlaze i dr. Tako se dobija detaljan opis softvera za novi informacioni sistem, kao kolekcija podsistema i modula. Takođe, definišu se međusobne veze između delova strukture i resursi interfejsa između modula sistema na način koristan za njihov detaljni dizajn i upravljanje celokupnom konfiguracijom. Elementi dizajna imaju za cilj da opišu softver dovoljno detaljno da bi se isti mogao razviti bez posebnih napora u narednim fazama razvoja. Rezultati ove faze su: dokumenat dizajna (specifikacija dizajna) koji sačinjavaju prikaz arhitekture sistema, specifikacija softvera, specifikacija interfejsa, specifikacija komponenti, specifikacija strukture podataka, specifikacija programskih procedura ili algoritama, ažurirana matrica povezanosti dokumenata koja prethode i koja slede u realizaciji zahteva Requirements Traceability matrix (RTM) i ažuriran plan projekta.

� Implementacija sistema: U ovoj fazi se na osnovu definisanog dokumenta dizajna u kojem su detaljno opisani elementi dizajna, izgrađuju (proizvode, razvijaju) za svaki od elemenata, niz od jednog ili više artifakata budućeg softvera. Drugim rečima programiraju se dizajnirane programske procedure obrade. Takođe, za svaki niz funkcionalnosti budućeg softvera se razvijaju test slučajevi i odgovarajući sistem pomoći (help system) korisnicima u njihovoj interakciji sa sistemom. Svaki razvijeni artifact je povezan sa određenim elementom dizajna i svaki od njih ima jedan ili više korespondentnih test slučajeva. Rezultati ovih aktivnosti faze su: potpuno funkcionalan softverski proizvod, koji zadovoljava korisničke zahteve i dokumentom definisane elemente dizajna. Pored toga, rezultat predstavlja i online sistem pomoći korisnicima, sa detaljnim opisom svih operacija u softverskom proizvodu; implementaciona mapa koja identifikuje primary code entry points for all major system functions, plan testiranja koji opisuje sve test slučajeve koje je neophodno koristiti da bi se ocenila korektnost i kompletnost proizvoda; ažurirana matrica povezanosti dokumenata

koja prethode i koja slede u realizaciji zahteva Requirements Traceability matrix (RTM) i ažuriran plan projekta.

� Tokom faze implementacije, obavlja se testiranje i integracija, kao drugi niz aktivnosti ove faze. Artifakti softvera, online sistem pomoći korisnicima i test podaci se iz razvojnog okruženja prenose u test okruženje. Svi test slučajevi se aktiviraju da bi se proverila korektnost i kompletnost softverskog proizvoda. Testiraju se pojedinačno razvijeni segmenti i njihove logičke celine, kao i prihvatljivost softvera od strane korisnika. Uspešno izvršenje testa potvrđuje robustnost i mogućnost potpune migracije na novi softverski proizvod. U ovoj fazi se afirmiše i održava celokupna integralnost komponenti softvera putem verifikacije konzistentnosti i kompletnosti uvedenih podsistema i modula, verifikuje se interfejs i veza razvijenih segmenata informacionog sistema sa specifikacijama, upoređuju performanse sistema, podsistema i modula sa zahtevima. Vrši se obuka korisnika koja će uz pripremljena uputstva odnosno sistem pomoći obezbediti korisnicima razumevanje mogućnosti i ograničenja u cilju efektivne upotrebe sistema. Rezultati ovih aktivnosti faze implementacije su: integrisani softverski proizvod, online sistem pomoći korisnicima, implementaciona mapa, plan uvođenja u proizvodnju (produkciju) koji referencira izvorni kod, opisuje standarde i konvencije kodiranja, kao i izvršne procese, bazu podataka i njene tabele, plan prihvatanja koji sadrži konačan skup test slučajeva i ažuriran plan projekta.

� Poslednja grupa aktivnosti faze implementacije je instalisanje i prihvatanje. Ovo je finalna grupa aktivnosti faze razvoja inicijalnog softverskog proizvoda, u kojoj se isti stavlja u produkciju i počinje koristiti u aktuelnom poslovanju. Svi proizvodi dobijeni (proizvedeni) u procesu razvoja softvera - artifakti, online sistem pomoći korisnicima, inicijalni podaci za obradu (produkciju) se postavljaju na produkcioni server. Takođe se svim test slučajevima još jednom proverava korektnost i kompletnost proizvoda. Uspešan završetak provere je pretpostavka prihvatljivosti proizvoda od strane korisnika. Nakon što se korisnik uveri da su rezultati obrade (produkcije) korektni i da su svi testovi sa zadovoljavajućim rezultatima, on formalno prihvata isporuku softvera. Naravno, u ovom poslednjem delu faze se proverava sistemska dokumentacija i uputstva za korisnika, obzirom da su ona po formi pogodna za proveru i kao podrška sistema. Proizvodi ovih aktivnosti faze su: softver spreman za produkciju, kompletiran test prihvatanja i memorandum o prihvatanju softvera od strane korisnika. Konačno, projekat se zaključuje, arhiviraju se svi proizvodi dobijeni u procesu razvoja softverskog proizvoda, implementaciona mapa, izvorni kod i dokumentacija koja je pratila razvoj proizvoda.

� Održavanje sistema: Ova faza u razvoju softvera podržava operacije sistema u ciljnom okruženju obezbeđujući potrebna unapređenja, proširenja, popravke, zamene i dr. Održavanje je stalni proces koji se realizuje putem iteracija aktivnosti koje mu prethode.

3. Principi i modeli razvoja informacionih sistema Razvojni principi ili drugim rečima paradigme, predstavljaju opšte prihvaćene načine obavljanja aktivnosti u razvoju informacionih sistema, koji omogućuju uopštavanje osobina i zakonitosti objektivne stvarnosti. Osnovni razvojni principi su: princip modelovanja, princip iteracija, princip simulacije, princip dokumentovanja i dr. To su opšte poznati i prihvaćeni principi u različitim područjima rada, koji se samo i u razvoju softvera primenjuju.

� Modelovanje - koje podrazumeva izbor modela, rukovanje različitim nivoima detaljnosti modela, vezu modela prema stvarnosti, nezavisnost pogleda na celoviti sistem.

� Apstrakcija - kao rezultat modelovanjem stečenih rezultata, daje specifikaciju modela koja je nedvosmislena, razumljiva, jedinstvena, nezavisna od sistema i lako izmenljiva.

� Iteracija - ponovljiv ciklus aktivnosti koji je uzrokovan različitim razlozima: nemogućnost definisanja informacionih zahteva u jednom prolazu usled nepoznavanja ili stalnog usavršavanja zahteva od korisnika, veliki broj neočekivanih situacija, dužina perioda razvoja, potreba za finim usaglašavanjem, doterivanjem i preciziranjem, podizanje nivoa kvaliteta proizvoda, ....

� Arhitektura - dekomponovanje složene strukture proizvoda na njegove segmente odnosno arhitekturu bilo u analizi i dizajnu, bilo u održavanju. Razlozi za strukturiranje su: lakša razumljivost složenih sistema, jednostavnije organizovanje razvojnog procesa, lakša ugradnja elemenata u celinu sistema, upravljivost kompleksnih i složenih sistema. Arhitektura izražava: elemente sistema, njihovu organizaciju, ponašanje strukturnih elemenata, zajedničko ponašanje, način međusobne povezanosti, organizovanje u složenije celine i dr.

� Dokumentovanje - podrazumeva neophodnost istovremene izrade dokumentacije u toku realizacije pojedinih aktivnosti razvoja. Na taj način dokumentacija obezbeđuje njihovo nesmetano odvijanje. Dokumentacija doprinosi kvalitetnijoj komunikaciji i razmeni informacija između svih učesnika razvoja, kao i njihovoj međusobnoj usaglašenosti. Takođe, ona pruža osnovu za kontrolu procesa razvoja. Dokumentacija je jednako potrebna ekspertima u procesu razvoja informacionog sistema, kao i krajnjim korisnicima budućeg sistema. Upravo zbog toga se proces izrade dokumentacije, sadržaj dokumentacije, način izrade, upravljanja i čuvanja dokumentacije uređuju međunarodnim standardima.

Kao što je već istaknuto u kratkom opisu životnog ciklusa, razvoj informacionih sistema podrazumeva veliki broj aktivnosti, koje se fazno realizuju. Tokom višefaznog razvoja informacionih sistema, pojedine aktivnosti se izvršavaju na različite načine u zavisnosti od načina razmišljanja onih koji ih sprovode i osobina objektnog sistema za koji se informacioni sistem razvija. Posebna se pažnja posvećuje logičkom redosledu realizacije pojedinih faza i aktivnosti, obzirom da se u određenom toku pojedine aktivnosti međusobno uslovljavaju, upotrebljavaju rezultate aktivnosti koje im prethode, i semantički se jedna na drugu oslanjaju.

Model razvoja je apstraktna (teorijska) predstava procesa razvoja. Svaki model predstavlja proces na poseban i jedinstven način, te tako obezbeđuje samo delimične informacije o njemu. Modeli razvoja se međusobno razlikuju po tome koliki značaj pridaju pojedinim fazama i aktivnostima u razvoju informacionih sistema, koliko ih detaljno posmatraju i u kojem redosledu ih izvršavaju.

Model razvoja se bira u zavisnosti od prirode zadatka odnosno projekta, tehničke orijentacije osoba koje učestvuju u razvoju, metoda i alata koji se upotrebljavaju pri razvoju, načina kontrole i prirode samog proizvoda koji se zahteva.

Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki sistemi. Oni pružaju različite poglede na proces razvoja informacionih sistema. Osnovni razlog njihove pojave je bila želja da se obezbedi uopštena šema razvoja informacionih sistema, koja bi služila kao osnova u planiranju, organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju aktivnostima razvoja informacionih sistema. Najčešće, modeli se strukturiraju na sledeći način:

� Model vodopada,

� Modifikovani model vodopada,

� Inkrementalni model,

� RAD model.

� Model prototipskog razvoja,

� Spiralni model,

� Model zasnovan na komponentama,

� Model unificiranog procesa razvoja (Unified Process)

� Modeli agilnog razvoja (Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, Feature Driven Development (FDD), Agile Modeling (AM),

� Kombinovani modeli.

3.1 Model vodopada (Waterfall)

Model vodopada je uveo W. Royce 1970. godine, a naziv je dobio obzirom na tok izvođenja aktivnosti i način prenosa rezultata iz jedne faze u drugu, koji podseća na vodopad. Ovaj model razvoja, zahteva sistematičan pristup aktivnostima razvoja koje se realizuju po strogo definisanom sekvencijalnom redosledu, postepenim prevođenjem rezultata od prve do poslednje faze razvoja. Svaka faza poseduje tačku početka i tačku završetka, sa poznatim rezultatima za narednu fazu. Veoma često se naziva i modelom životnog ciklusa razvoja softvera.

Razvoj se odvija putem sledećih faza:

� Analiza i specifikacija zahteva - Obzirom da softver predstavlja samo deo nekog sistema, rad na razvoju proizvoda započinje definisanjem zahteva prema svim elementima sistema i alociranjem jednog dela adekvatnih i određenih zahteva prema softveru. U ovoj fazi identifikuju se problem i ciljevi koji se žele postići razvojem proizvoda, zahtevane funkcije, performanse i njihove međusobne veze. Takođe, identifikuju se potencijalna ograničenja u razvoju. Zahtevi se analiziraju i pregledaju sa korisnicima i na kraju dokumentuju. Specifikacija zahteva jednoznačno i jasno definiše funkcije budućeg proizvoda.

� Projektovanje – Projektovanje ili dizajn proizvoda je faza razvoja, kojom se definiše celokupna arhitektura sistema. Nju čini više aktivnosti, a koje se fokusiraju na nekoliko aspekata razvoja softvera: korisnički interfejs, ulazne ekranske forme, izlaze, bazu podataka, procedure obrade i sistemsku kontrolu. Ova faza prevodi zahteve korisnika definisane u specifikaciji zahteva u određeni softverski proizvod koji se može oceniti sa aspekta kvaliteta pre nego što započne implementacija. Kao i u prethodnoj fazi analize i specifikacije zahteva, rezultati projektovanja se detaljno dokumentuju.

� Implementacija – Ovom fazom se izvršava zadatak prevođenja rezultata projektovanja u mašinski prepoznatljivu formu. Nju čine aktivnosti programiranja, testiranja, konverzije i obuke korisnika. Ukoliko je projektovanje urađeno dovoljno detaljno, tada se programiranje obavlja relativno mehanički. Testiranjem se proveravaju sve programske jedinice i identifikuju semantičke, sintaksičke i algoritamske greške. Istovremeno, utvrđuje se da li svaka programska jedinica tj. program zadovoljava specifikovane zahteve.

� Integracija - Kada se jednom izgenerišu pojedini programi, oni se moraju integrisati i testirati da bi se utvrdilo da li sistem kao celina zadovoljava specifikaciju zahteva. Nakon toga, proizvod je spreman za predaju korisniku na upotrebu.

� Funkcionisanje i održavanje – Ovo je najduža faza razvoja, tokom koje se proizvod stalno inovira. Potrebe za izmenama se javljaju iz više razloga, a najčešće zbog proširenja funkcija ili performansi

koje zahteva korisnik, zbog potreba da se proizvod prilagođava promenama koje uzrokuje promenjeno okruženje, zbog razvoja tehnologija koje se upotrebljavaju, zbog ispravki grešaka koje nisu uočene tokom testiranja i zbog unapređenja njegove efikasnost.

Svaka od navedenih faza u modelu poseduje specifičnosti, rezultira izvesnim proizvodom i omogućuje reviziju postignutih rezultata. Aktivnosti faze se izražavaju neophodnim ulazom, procesom i realizovanim izlazom. Razvoj softverskog proizvoda tako prolazi kroz niz koraka koje su sukcesivne odnosno povezane kao susedne. Rezultat realizacije svake faze razvoja su njeni konkretni proizvodi i određena dokumentacija – koji se verifikuju i koji se koriste kao ulazi u sledeću fazu. Prema tome, naredna faza razvoja uvek može započeti, samo kada je prethodna faza u celosti završena i svi njeni proizvodi i dokumentacija raspoloživi.

U stvarnosti, razvoj nikad nije tako eksplicitno i linearno određen. Zbog toga razvijeni proizvodi u svakoj fazi zahtevaju proveru i reviziju pre prihvatanja, kao i određenu vrstu zamrzavanja rezultata pre prelaska u narednu fazu, jer naknadne promene rezultata prethodnih faza nisu dopuštene.

Model vodopada je najstariji model razvoja koji je najviše i najšire primenjivan do danas. Uspešno se kombinuje sa drugim modelima razvoja. Veoma je mnogo kritikovan, ali se ipak zadržao na visokim pozicijama sa stanovišta primene. Model je posebno efikasan u struktuiranju i upravljanju malim projektima razvoja softvera u organizacijama, kada korisnik jednoznačno može definisati svoje zamisli i zahteve u odnosu na proizvod i kada se isti tokom razvoja radikalno ne menjaju. Takođe, preporučuje se prilikom razvoja proizvoda koji je po osnovnim karakteristikama jedinstven i ima zadatak da zadovolji

posebne zahteve korisnika, koji još do tada nisu realizovani u sistemima drugih organizacija i ne mogu se šire upotrebiti.

Prednosti modela vodopada su:

� strogo definisani i kontrolisani proces, kojeg karakterišu standardizovane i detaljno opisane aktivnosti u svim fazama razvoja,

� uključeno testiranje odnosno verifikacija izvršenih aktivnosti i dobijenih rezultata na kraju svake faze razvoja,

� detaljna i kvalitetna dokumentacija, koja se generiše u svim fazama razvoja, istovremeno kada se izvršavaju pojedine aktivnosti i

� relativno laka zamena pojedinih učesnika u procesu razvoja.

Nedostaci modela vodopada su:

� nefleksibilna podela aktivnosti razvoja u posebne faze i nedostatak povratne sprege između faza,

� greške koje se ne otklone u pojedinim fazama razvoja kada se vrši testiranje ili verifikacija proizvoda, mogu imati stravično distorziono dejstvo na razvoj u celini,

� nemogućnost obavljanja iteracija tokom realizacije razvoja jer iste izazivaju ozbiljne probleme i konfuziju u primeni modela,

� teška prilagodljivost neizvesnosti koja uglavnom egzistira na startu projekta, kada je korisniku veoma teško da eksplicitno navede sve svoje zahteve prema softveru,

� dugotrajan proces razvoja te korisnik mora biti veoma strpljiv i istrajan jer su mu radne verzije softvera dostupne tek na kraju aktivnosti razvoja, a do tada postoji samo pisana specifikacija funkcionalnosti budućeg softvera,

� samo potpuno gotov proizvod je upotrebljiv od korisnika,

� visoki razvojni troškovi.

3.2 Modifikovani model vodopada

Modifikovani model vodopada je razvijen da bi se otklonila dva najveća nedostatka klasičnog linearnog modela vodopada. To je mogućnost preklapanja aktivnosti razvoja i realizacija povratne sprege između faza razvoja. Uvođenjem iteracija, posebno je istaknut značaj aktivnosti verifikacije i validacije (vrednovanja) rezultata na završetku svake od njih. Verifikacijom se proverava da li se razvoj odvija na pravi način, dok se vrednovanjem proverava da li je razvoj u skladu sa zahtevima korisnika.

Ovako modifikovani model vodopada, pruža mogućnost povratka iz bilo koje faze razvoja na bilo koju od ranije realizovanih faza, i tako onemogućuje prenošenje u bilo kojoj fazi uočenih ozbiljnijih grešaka kroz sve faze razvoja do samog kraja. Greške se permanentno otklanjaju i samo se u retkim slučajevima prenose.

3.3 Inkrementalni model

Inkrementalni model je nastao kao evolucija modela vodopada i predstavlja kombinaciju klasičnog modela vodopada sa iterativnim mogućnostima razvoja. U ovom modelu se prvobitno potpuno razvija inicijalni podskup funkcija proizvoda, a zatim se sukcesivnim koracima razvijaju, stalno novije i komplikovanije verzije. Definisanje osnovnih funkcionalnosti proizvoda je potrebno veoma rano i po mogućnosti celovito, dok se njihova realizacija odvija odloženo, putem inkremenata. Analiza proizvoda i projektovanje njegove opšte arhitekture se izvodi u prvom koraku, a detaljno projektovanje, implementacija, integracija i testiranje softvera se odvijaju sukcesivnom razradom inicijalnog podskupa. Svakim inkrementom se razvijaju nove funkcionalnosti koje se dodaju već razvijenom proizvodu, pri čemu se postojeće funkcionalnosti zadržavaju. Proizvod je razvijen kada zadovolji sve identifikovane korisničke zahteve odnosno sve funkcionalnosti. Međutim, on je upotrebljiv i nakon razvijenog prvog inkrementa i bez razvijenih svih ostalih funkcionalnosti. Razvoj se može prekinuti pri razvoju bilo kojeg inkrementa bez rizika za njegovu trenutnu upotrebljivost. Inkrementalni model razvoja je posebno popularan i koristi se u softverskim kućama.

Prednosti inkrementalnog modela su:

� obezbeđuje transparentan razvoj proizvoda, sa stalno vidljivim razultatima,

� uvek raspoloživ funkcionalno upotrebljiv proizvod, koji zadovoljava određeni podskup korisničkih zahteva,

� lako razumevanje i testiranje novorazvijenih inkremenata proizvoda jer oni samo dodaju nove funkcionalnosti postojećem upotrebljavanom softveru i na taj način premošćavanje traumatskih efekata uvođenja kompletno novog proizvoda odjednom,

� postojanje povratne sprege i permanentne mogućnosti ugradnje bogatog korisničkog iskustva u redefinisani proizvod na manje skup način, putem novih inkremenata odnosno novih funkcionalnosti proizvoda,

� umanjeni rizik od neuspeha razvoja celine, jer se problemi uglavnom uočavaju u pojedinim inkrementima,

� skromniji obim kapitalnih ulaganja u razvoj proizvoda i brži povrat investicija,

� manji broj angažovanih osoba u procesu razvoja.

Nedostaci inkrementalnog modela su:

� dekompozicija proizvoda na inkremente, da bi se oni mogli integrisati, nije trivijalan zadatak, kao ni sam proces integracije, a da se pri tome ne ugrozi kvalitet već postojećeg proizvoda,

� specifikacija detaljnih korisničkih zahteva se kod svakog inkrementa izrađuje neposredno pre nego što se on razvija,

� integracija može uvek doneti neočekivane probleme i potrebe za reorganizacijom, koja može imati posledice po efikasnost i održavanje,

� korisnici imaju stalnu želju da menjaju svoje zahteve.

Slika : Inkrementalni model

3.4 RAD model

RAD je inkrementalni model procesa razvoja, koji omogućuje da se upotrebljivi proizvod izgradi u kratkim razvojnim ciklusima, koji traju od 60 do 90 dana. Rezultat svakog ciklusa, odnosno iteracije, je proizvod određene funkcionalnosti. RAD modelom se proizvod razvija sa malim i integrisanim timovima u kojima se pored onih koji neposredno razvijaju proizvod nalaze i korisnici. Mali timovi, kombinovani sa kratkim iterativnim razvojnim ciklusima, efektivne neformalne komunikacije, jedinstvo vizije i ciljeva, primarne su karakteristike ovog modela razvoja.

RAD je model u kojem su faze analize, projektovanja odnosno dizajna, implementacije i testiranja komprimovane (stisnute, sažete) u nizove kratkih iterativnih razvojnih ciklusa. Iteracije omogućuju efektivnost i samokorekciju procesa razvoja. Studije pokazuju da čovek skoro nikad složene zadatke ne

Software

concept

Requirements

Analysis

Architectural

Design

Stage 1: Detailed design, code, debug, test

and delivery

Stage 2: Detailed design, code, debug, test

and delivery

Stage n: Detailed design, code, debug, test

and delivery

izvede perfektno u prvom pokušaju. Čak naprotiv, nakon solidnog početka, veoma uspešno izvodi mala i učestala unapređenja. Što znači da je bolje prihvatiti takva iskustva nego se protiv istih boriti.

Razvoj se odvija putem realizacije sledećih koraka:

� Modelovanje organizacije – faza u kojoj se istražuju ciljevi organizacije, problemi organizacije, kritični faktori uspešnosti i strateške mogućnosti. Razmatraju se na zajedničkim sednicama rukovodstva organizacije i projektanata načini usmeravanja organizacije kako bi ona postala kompetitivnija.

� Planiranje zahteva – faza u kojoj se analiziraju zahtevi sa obzirom na poslovni sistem. Proučavaju se funkcije sistema, identifikuju upotrebljive i uklanjaju nekorisne. Takođe, istražuju se i definišu informacione potrebe, obim u kojem će se one zadovoljiti i vrši analiza opravdanosti razvoja novog proizvoda.

� Dizajn aplikacija – faza u kojoj se vrši detaljna analiza funkcionalnosti predloženog sistema i oblikuje sistem koji će potpuno odgovoriti zahtevima. Ključni korisnici na radnim sastancima, vrše dekompoziciju poslovnih funkcija i definišu tipove entiteta, da bi procese povezali sa podacima. Nakon toga vrši se dizajn kritičnih procedura, dizajn preliminarnog izgleda ekranskih formi i priprema plan implementacije sistema.

� Konstrukcija – faza u kojoj mali razvojni timovi rade neposredno sa korisnicima na finaliziranju dizajna i izgradnji proizvoda. Ovu fazu čini serija koraka tokom kojih korisnici imaju prilike da koriguju svoje zahteve i ispitaju razvijeni proizvod. Proizvod se razvija iterativno i prototipski. Nakon izgradnje, proizvod se testira, generišu se dokumentacija i uputstva za korišćenje novog proizvoda kao i rutine i procedure za stavljanje proizvoda u funkciju.

� Implementacija – je faza tokom koje se implementira novi proizvod i upravlja prelaskom sa starog na novi. Uspostavljaju se relacije između starog i novog proizvoda, vrši konverzija podataka i obavlja trening korisnika.

Prednosti RAD modela su:

� povećana brzina razvoja proizvoda putem primenjenih metoda prototipskog razvoja,

� umanjena funkcionalnost proizvoda za krajnjeg korisnika (proistekla iz suženog fokusa dizajna) i kao posledica njegova umanjena kompleksnost (složenost),

� veći naglasak na jednostavnost i upotrebljivost dizajna korisničkog interfejsa.

Nedostaci RAD modela su:

� umanjena skalabilnost i umanjene karakteristike, kada ovim modelom razvijene softverske aplikacije startuju kao prototipovi i razvijaju se u gotove aplikacije,

� skromnije karakteristike proizvoda, koje su posledica skraćenja vremena razvoja, jer se zbog kratkog vremenskog okvira izrade mnoge karakteristike potiskuju u kasnije verzije,

� cena postignutog ubrzanja procesa razvoja, veoma često je gubitak pregleda nad celinom sistema,

� brzina razvoja može postati svrha sama sebi, pa tada vodi improvizaciji razvoja i izradi samo priručnih i privremenih rešenja,

� kod velikih projekata, model zahteva dovoljno resursa za formiranje pravog broja razvojnih timova,

� projekti su bezuspešni, ukoliko ne postoji obaveza razvojnog tima ili korisnika da aktivnosti, neophodne za kompletiranje sistema, ne realizuju u mnogo kraćim vremenskim intervalima,

� ukoliko se proizvod nemože adekvatno modularizovati, izgrađene komponente su problematične u smislu povezivanja.

3.5 Model prototipskog razvoja

Model prototipskog razvoja je iterativan model, u kojem se pored projektanata u razvojnom timu pojavljuju i korisnici. Upotrebljava se da bi se za potrebe korisnika razvio inicijalni model budućeg proizvoda, koji simulira njegove stvarne funkcije, a sa ciljem da korisnik da svoje mišljenje i odluči koji i kakvi su njegovi zahtevi. Kod razvoja proizvoda po ovom modelu korisnik već u najranijem periodu može videti na koji će se način zadovoljiti njegovi zahtevi. Najčešće se razvija samo korisnički interfejs, čija implementacija obezbeđuje povratnu spregu od korisnika.

Ovaj razvojni model obično prihvata neku vrstu funkcionalne specifikacije proizvoda kao ulaz, koja omogućuje da se aktivnosti dizajna proizvoda inicijalno preskoče. Takođe, omogućuje da se brzo izgrade njegove primitivne verzije, koje korisnik može i sam kasnije razvijati. Učešće korisnika se ostvaruje putem povratne sprege u redefinisanju specifikacije zahteva i dizajna.

Model prototipskog razvoja je onaj model razvoja u kojem se prototip inicijalno razvija, testira i kasnije po potrebi dorađuje, dok se ne dobije konačno njegova prihvatljiva verzija kao podloga za razvoj celine proizvoda.

Ovaj model je pogodan kao model razvoja kada se na početku razvojnog ciklusa ne poznaju potpuno i svi zahtevi korisnika, već ih je potrebno sukcesivno saznati. Zatim, kada je moguće izvesti simulaciju rada proizvoda, kako bi korisnik mogao videti na koji način će budući proizvod funkcionisati. I kada razvojni timovi žele proveriti efikasnost ugrađenih algoritama ili adaptibilnost proizvoda.

Prikupljanje i

selektiranje

zahteva

Brzi

dizajn

Redefinisanje

prototipa

Evaluacija

prototipa od

korisnika

Inžinjerski

proizvod

Izgradnja

prototipa

START

STOP

Slika : Model prototipskog razvoja

Model prototipskog razvoja započinje prikupljanjem osnovnih zahteva korisnika. Razvojni tim i korisnici, zajednički definišu opšte ciljeve razvoja proizvoda, identifikuju sve njima poznate zahteve i određuju područja na kojima su obavezne dalje aktivnosti preciznijeg definisanja. Sledi "brzi" dizajn u kojem se fokusira na realizaciju onih aspekata proizvoda koji će biti vidljivi za korisnika (ulazni i izlazni formati i dr.). Nakon takvog dizajna, razvija se prototip. On služi da bi se prečistili zahtevi prema proizvodu koji se razvija. Prečišćavanje je iterativno i odvija se dok prototip ne zadovolji zahteve korisnika i istovremeno omogući projektantu potpuno razumevanje potreba koje mora zadovoljiti. Idealno, prototipski razvoj i služi kao mehanizam za identifikovanje korisničkih zahteva. Ukoliko prototip u korisničkoj evaluaciju zadovolji, prelazi se u završnu fazu razvoja konačnog proizvoda za upotrebu.

Prednosti primene modela prototipskog razvoja su:

� povećana brzina i kreativnost u razvoju,

� stalno obezbeđene radne verzije proizvoda, koje mogu poslužiti za analizu funkcionalnosti, performantnosti, adaptibilnosti i troškova razvoja,

� korisnik je maksimalno angažovan na razvoju, može permanentno menjati svoje zahteve, što unapređuje kvalitet celokupnog procesa.

Ovaj model ima i svoje nedostatke odnosno primena modela prototipskog razvoja može biti diskutabilna iz više razloga:

� nemogućnost kvalitetne i tačne procene i planiranja resursa,

� korisnik uočava radnu verziju proizvoda neznajući na koji su način delovi proizvoda međusobno povezani, neznajući da u brzini realizacije nisu razmatrani aspekti kvaliteta ili održavanja u dužem vremenskom periodu. Kada dođe do informacija da je potrebno izvršiti "remont" ili dalju dogradnju još ne uvedenog proizvoda, korisnik se oseća prevarenim i insistira da se putem izvesnih intervencija brzo realizuje njemu potreban proizvod. Upravljanje razvojem softvera u ovakvim situacijama postaje nekontrolisano,

� projektant često čini kompromise u implementaciji sa ciljem da izgrađeni prototip što pre stavi u funkciju. Neadekvatan operativni sistem ili programski jezik se jednostavno upotrebljavaju samo zato što su raspoloživi ili poznati; neefikasan algoritam se primenjuje pak da bi se demonstrirale pojedine funkcionalnosti proizvoda. Nakon izvesnog vremena, zaboravlja se na način odabira i njihove uzroke, te ovako manje idealna rešenja ili bolje rečeno manje kvalitetna rešenja ostaju integralni deo konačnog proizvoda,

� velika verovatnoća da se zamena prototipa sa pravim sistemom završi neuspešno,

� dokumentacija, koja nastaje procesom izrade pravog proizvoda, uglavnom retko bude napravljena.

Zbog toga, značajno je da se projektant i korisnik, u cilju efikasne primene ovog modela, dogovore i definišu "pravila igre" na početku procesa razvoja proizvoda. Drugim rečima, oni se moraju složiti da se prototip razvija kao sredstvo za definisanje zahteva, za prikaz izgleda budućeg proizvoda, a nakon toga se prekida njegov razvoj i razvija pravi proizvod u cilju zadovoljenja kriterijuma kvaliteta i mogućnosti održavanja.

3.6 Spiralni model

Spiralni model je razvijen od. B Boehma 1988. godine, da bi se objedinile dobre osobine modela vodopada i modela prototipskog razvoja uz istovremeno uključivanje aktivnosti analize rizika. Inicijalno namenjen razvoju velikih, skupih i složenih projekata.

Model se predstavlja spiralom na kojoj su definisane četiri faze razvoja:

� planiranje – faza koju čine aktivnosti uspostavljanja efektivne komunikacije projektanata i korisnika i aktivnosti određivanja ciljeva, projektnih alternativa i ograničenja u razvoju,

� razvoj alternativa i analiza rizika – faza koju čine aktivnosti analize alternativa i identifikovanja tehničkog i menadžerskog rizika,

� inženjering – faza razvoja novih nivoa proizvoda, testiranja i instaliranja uz podršku korisnicima putem izrade dokumentacije i treninga,

� procene korisnika – faza procene realizovanih rezultata razvoja i instalacije proizvoda.

Posmatranjem spirale, svakom iteracijom se progresivno razvijaju kompletnije i složenije verzije proizvoda. Tokom prvog ciklusa kretanja spiralom, prikupljaju se zahtevi i planira projekat razvoja, da bi se izvršila analiza rizika inicijalnih zahteva. Ukoliko analiza rizika indicira neizvesnosti u zahtevima, tada se može upotrebiti prototipski razvoj da bi se zahtevi detaljnije spoznali. U iste svrhe, mogu se koristiti simulacija ili druge vrste modela.

Nakon što se donese odluka o daljem razvoju, obavlja se inžinjering u svakom ciklusu spirale i to odabranim modelom razvoja softvera (model vodopada i-ili model prototipskog razvoja). Broj aktivnosti u inženjeringu raste, ukoliko se ciklusi udaljuju od centra spirale. Istovremeno, aktivnosti su složenije i uvek sa mnogo više detalja i manje apstrakcije.

Analiza rizika

inicijalnih zahteva

Analiza rizika na

korisničkim reakcijama

Donošenje odluke DA - NE !

Inicijalni prototip

Naredni nivo

Razvijeni sistem

Inžinjering

(razvoj narednog nivoa proizvoda)

Razvoj alternativa i analiza rizika

Kumulativni troškovi

Planiranje

Prikupljanje zahteva

i planiranje projekta

Planiranje na korisničkim

komentarima

Procene korisnika

Procene korisnika

Slika : Spiralni model

Po završetku svakog ciklusa razvoja, korisnik ocenjuje proizvod i daje sugestije za njegovu modifikaciju. Zasnovana na korisničkom inputu, inicijalizuje se faza planiranja novog ciklusa razvoja i analiza rizika. Svaki ciklus razvoja na spirali, zahteva analizu rizika i donošenje odluke "nastaviti" ili "ne nastaviti" sa daljim razvojem. Ukoliko je rizik isuviše visok i ulaganja nesrazmerno velika u odnosu na efekte koji se očekuju, terminira se dalji rad i zadržava u upotrebi proizvod nastao u prethodnom ciklusu ili prethodnim ciklusima. Svaki novozapočeti ciklus spirale donosi kompletniji proizvod, ali i značajno više troškove.

Rezimirajući izloženo treba podvući da model uključuje multiplikovane iteracije kroz cikluse, koji analiziraju rezultate prethodnih faza određujući procenu rizika za buduće faze. U svakoj od faza, razvijaju se alternative u skladu sa ciljevima i potrebama, koje zajedno čine bazu za sledeći ciklus u spirali. Svaki ciklus se završava ocenom. Model podrazumeva da se svaki deo proizvoda ili svaki nivo proizvoda na istovetan način provlači kroz ovu spiralu odnosno ocenu.

Osnovna premisa modela je da se određeni redosled koraka ponavlja u razvoju i održavanju proizvoda. Koraci se prvo izvršavaju sa visokim stepenom apstrakcije, da bi se postepeno prešlo na detalje.

Prednosti primene spiralnog modela su:

� u kratkom vremenskom intervalu realizacija funkcionalnog proizvoda,

� fleksibilnost u upravljanju fazom inžinjeringa i mogućnost kombinovanja različitih pristupa u razvoju proizvoda,

� mogućnost izvođenja procene rizika u svakom trenutku i nivou apstrakcije, što obezbeđuje pravovremenu reakciju na uočene rizike i primenom prototipskog modela razvoja pruža mehanizam za njihovo smanjenje. Primenom ovog modela rizici se mogu smanjiti pre nego što izazovu veće probleme i velike troškove.

� model podržava sistematski pristup preuzet iz modela vodopada uz mogućnost izvođenja iteracija.

Nedostaci primene spiralnog modela su:

� odsustvo veze prema postojećim standardima, odnosno ne postojanje standarda za ovaj model razvoja softverskog proizvoda,

� model zahteva više uniformnosti i konzistentnosti u razvoju,

� relativno skup model za primenu u razvoju malih projekata, jer analize rizika zahtevaju specifične ekspertize,

� velike probleme stvara situacija kada se na vreme ili uopšte ne otkriju rizici, koji onda proizvode multiplikativno dejstvo u razvoju,

� relativno kratko vreme njegove primene, pa će trebati još dosta vremena da se sa više sigurnosti i verovatnoće priđe njegovoj ozbiljnijoj primeni.

Analiza odnosno procena rizika, kao ključna razlika ovog modela razvoja u odnosu na ostale, je veoma pozitivna i korisna u procesu razvoja, ali samo kod izgradnje velikih informacionih sistema jer se za njih vezuju veliki troškovi i kada njeno izvođenje ne predstavlja preveliki relativni trošak u odnosu na ukupne troškove razvoja.

3.7 Model zasnovan na komponentama

Osnovni pristup u ovom modelu je konfigurisati i specijalizirati već postojeće komponente proizvoda u novi proizvod. Međutim, osobine komponenti zavise od njihove veličine, kompleksnosti i funkcionalnih mogućnosti. Većina pristupa pokušava da iskoristi slične komponente obzirom na zajedničke strukture podataka sa algoritmima za njihovu manipulaciju. Drugi pristupi pokušavaju da iskoriste komponente funkcionalno sličnih kompletnih sistema ili podsistema kao što su korisnički interfejs. Postoje i brojni načini iskorišćavanja softverskih komponenti za razvoj softverskih sistema. Svi ovi pokušaji i nastojanja zagovaraju inicijalnu upotrebu već urađenih komponenti u specificiranju strukture ili detaljnom dizajnu komponenti radi ubrzavanja postupka implementacije. Ove komponente se mogu upotrebiti i pri prototipskom razvoju proizvoda ukoliko je raspoloživa takva tehnologija.

"A" "B"

"C"

Model softver

komponenti

Model softver

komponenti

Model softver

komponenti

Komponente softvera

za ponovnu upotrebu

Komponente softvera

za ponovnu upotrebu

Višestruko korišćenje proizvoda je proces kojim se u novi proizvod uključuju pojedine komponente:

� prethodno testiranog koda,

� prethodno proverenog dizajna,

� pretnodno razvijene i korišćene specifikacije zahteva i

� prethodno korišćenih procedura za testiranje.

Koristi koje sobom donosi ponovno korišćenje komponenti razvijenog softvera su sledeće:

� podiže robustnost proizvoda,

� povećava produktivnost izrade proizvoda i smanjuje troškove razvoja,

� podiže kvalitet proizvoda jer su mu komponente višestruko proverene i u više navrata unapređene,

� štedi odnosno skraćuje vreme izrade,

� obezbeđuje adekvatnu dokumentaciju i lakše razumevanje proizvoda,

� olakšava održavanje proizvoda.

3.8 Model unificiranog procesa razvoja

Model unificiranog procesa (UP) razvoja je u upotrebi od 1999 godine, a njegovi autori su: Ivar Jacobson, Grady Booch i James Rumbaugh. Ovaj model opisuje razvoj putem upotrebe UML - objedinjenog jezika za modelovanje, a zasnovan je na iterativnom i inkrementalnom procesu. Model ne predstavlja samo običan proces, već promenljivi i prilagodljivi okvir razvoja softvera u različitim organizacijama i u raznim projektima.

Model je inicijalno zamišljen za razvoj velikih softverskih projekata, ali je svoju primenu našao i u srednjim i malim softverskim projektima. Softverski timovi, naročito veliki, znatno unapređuju svoju produktivnost korišćenjem ovog modela. UP omogućuje svakom članu razvojnog tima lak uvid u bazu

znanja, zasnovanu na uputstvima, templejtima i uputstvima za korišćenje alata, što predstavlja značajnu podršku u svim kritičnim razvojnim aktivnostima. Istovremeno, omogućuje da svi članovi razvojnog tima, bez obzira na aktivnosti koje obavljaju, imaju zajedničku metodologiju, jezik i pogled na proces razvoja.

Ovaj model proces razvoja softvera postavlja između dve dimenzije, vremenske i sadržajne. Vremensku dimenziju čine četiri faze: inception, elaboration, construction i transition, dok je sadržajna dimenzija podeljena u šest osnovnih i tri pomoćne discipline. Osnovne discipline su: disciplina poslovnog modelovanja, disciplina zahteva, disciplina analize i dizajna, disciplina implementacije, disciplina testiranja i disciplina raspoređivanja. Pomoćne discipline su: disciplina konfigurisanje i upravljanje promenama, disciplina upravljanje projektom i disciplina okruženje.

Navedene dve dimenzije se mogu posmatrati i kao: dinamička dimenzija u kojoj se proces opisuje kroz životni ciklus razvoja proizvoda i statička dimenzija u kojoj se opisuju aktivnosti i rezultati aktivnosti podeljeni na uloge.

Ukoliko se model posmatra putem dinamičke strukture, razvoj softvera čine četiri napred navedene faze. Faze u procesu razvoja se ne izvršavaju u jednom prolazu, već se svaka od njih izvršava u nekoliko iteracija. Model ne predviđa tačan broj iteracija. Do tačnog broja iteracija po fazama se dolazi prilikom prilagođavanja modela sopstvenim potrebama, tj. prilikom definisanja konkretnog procesa razvoja. Svaka iteracija se obavlja modelom životnog ciklusa koji uključuje faze analize, dizajna, implementacije i testiranja. Rezultat iteracije je inkrement konačnih osobina kvaliteta, proveren i integrisan, kojim se uvećava funkcionalnost softverskog proizvoda, a koji zadovoljava podskup ukupnih zahteva korisnika. Završetak svake faze su ključne tačke u procesu razvoja. Ključne tačke predviđaju, na osnovu izvršene integracije inkremenata realizovanih u posmatranoj fazi, njene krajnje rezultate.

Faza inception predstavlja prvu i najkraću fazu razvoja. Njen primarni cilj je definisanje obima i granica projekta, odnosno opravdanje razloga zbog kojih se pokreće projekat. Tokom ove faze se definiše vizija sistema, opisuje sistem i prikupljaju najvažni zahtevi. Nakon toga se identifikuju ključne funkcionalnosti

Disciplines

sistema i daje predlog najmanje jednog mogućeg rešenja arhitekture proizvoda. Procenjuju se troškovi, utvrđuje preliminarni plan realizacije projekta i identifikuju mogući rizici. Na kraju, razrađuje se proces razvoja i određuju alati koji će se upotrebljavati u razvoju softverskog proizvoda.

Faza elaboration predstavlja drugu fazu u životnom ciklusu razvoja proizvoda. Osnovni zadatak ove faze jeste uspostavljanje takve arhitekture sistema koja obezbeđuje čvrste osnove za većinu aktivnosti dizajna i implementacije koje će biti realizovane u fazi konstrukcije. Takođe, zadatak ove faze je i identifikovanje ključnih rizika. Identifikuju se rizici vezani za zahteve, rizici vezani za arhitekturu, rizici vezani za troškove i rizici vezani za sam postupak izvršenja procesa razvoja i za primenu izabranih alata. Aktivnosti koje se obavljaju u fazi elaboration su: prikupljanje detaljnih korisničkih zahteva; globalna analiza i dizajn, ustanovljavanje osnovne arhitekture sistema i njena ocena; planiranje konstrukcije sa izradom detaljnog plana projekta i proračuna troškova; usavršavanje razvojnog procesa i razvojnog okruženja

Fazu construction, kao treću fazu životnog ciklusa, čine detaljni dizajn, implementacija i testiranje sistema. Faza konstrukcije predstavlja najobimniju fazu i u vremenskom rasporedu zauzima preko polovine ukupnog vremena predviđenog za projekat. Međutim, ukoliko su prethodne faze kvalitetno odrađene, rizici za narednu fazu prelaženja su svedeni na minimum. U fazi konstrukcije mogu se izdvojiti sledeće aktivnosti: prikupljanje preostalih ili izmenjenih zahteva; detaljna razrada arhitekture i izrada sistema; kontinuirana integracija komponenti i testiranje sistema; izrade uputstava i materijala za trening korisnika, konverzija podataka i dr

Faza transition ima za cilj prenošenje softverskog proizvoda u ruke krajnjih korisnika. U fazi konstrukcije se u ruke korisnika predaje beta verzija softverskog proizvoda, tako da ova faza počinje sa beta testiranjem. Kao rezultat beta testiranja dobijaju se povratne informacije od korisnika o prihvatljivosti proizvoda i njegovom zadovoljstvu. Takođe, podešavaju se performanse proizvoda i vrši obuka korisnika.

Model unificiranog procesa razvoja softvera poseduje sve one prednosti i nedostatke, koji se ispoljavaju kod inkrementalnog modela, stim da dodatno poseduje pozitivne osobine spiralnog modela, jer podržava iteracije i permanentnu analizu rizika.

3.9 Agilni modeli razvoja

Često probijanje vremenskih rokova i budžeta u realizaciji projekata razvoja softverskih proizvoda, permanentni rast složenosti tehnologije i učestale promene korisničkih zahteva, doveli su krajem dvadesetog veka do pojave novih modela razvoja. Nastali su agilni modeli, po osobinama mnogo gipkiji i prilagodljiviji promenama, koji omogućuju korisnicima aktivno učešće tokom svih faza i aktivnosti razvoja.

Agilni pristup se dakle suočio sa osnovnim problemom savremenog i ujedno brzog razvoja proizvoda. Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme i troškove razmene informacija između osoba koje učestvuju u razvoju na način da skrate vremenski period od donošenja odluke do povratne informacije o posledici te odluke.

Polazne pretpostavke agilnih modela su bile da je turbulentnim poslovnim i tehnološkim okruženjima neophodan proces razvoja softvera koji istovremeno kreira promene, ali brzo i odgovara na iste. Istovremeno, proces koji uključuje odgovorne učesnike i njihovu dobru organizaciju. Učesnicima odnosno njihovom talentu, veštinama i sposobnostima, kao i njihovoj međusobnoj komunikaciji se poklanja posebna pažnja. Usmerenost na učesnike je i najznačajnija osobina agilnih modela, prema pojedincima se prilagođava i kompletan proces razvoja.

U agilnim razvojnim timovima, kompetencije pojedinaca predstavljaju kritičan faktor uspešnosti projekta. Prema agilnim modelima, ukoliko su pojedinci na projektu dovoljno kvalitetni, tada oni mogu uz bilo koji proces razvoja realizovati očekivani cilj. U suprotnom, nema procesa razvoja koji može nadomestiti njihovu nekompetentnost. Istovremeno, nedostatak korisničke podrške može lako uništiti projekat razvoja, kao što i neadekvatna podrška može sprečiti završetak projekta.

Agilni procesi ističu jedinstvene sposobnosti pojedinaca i timova. Naime, procesi ne mogu premostiti nedostatak kompetencija pojedinaca. Timovi su samoorganizovani, sa intenzivnim komunikacijama u okviru i van organizacionih granica. Ovi timovi mogu u svakom trenutku promeniti svoju strukturu kako bi se prilagodili promenama. Agilnost podrazumeva da tim ima zajednički cilj, uzajamno poverenje i poštovanje, zajednički i brz postupak donošenja odluka i sposobnost savladavanja svih dvosmislenosti. Agilan tim koji radi u okviru krute organizacije ima poteškoća, kao što ih ima svaki pojedinac koji radi u krutom timu. U ovim timovima, dominira saradnja svih nivoa upravljanja. Za donošenje odluke nije važno ko donosi odluke, već je važna saradnja i obezbeđenje informacija za donošenje odluka. U projektu razvoja učestvuju osobe različitih veština, talenta i sposobnosti, koje rade u bliskom fizičkom okruženju i poštuju organizacionu kulturu. Osobe, okruženje i kultura su u strogoj međuzavisnosti.

Agilni razvoj nije prikladan za sve situacije. Nametanje agilnih principa procesno usmerenim i nekooperativnim organizacijama ne dovodi do uspeha. Nametanje izuzetno promenljivog procesa mirnim i staloženim timovima, vodi sigurno raspadu tima. Takođe, agilni razvoj se teško izvodi u timovima sa većim brojem članova. Najviše uspeha u agilnom razvoju pokazuju timovi do devet članova. Agilni razvoj se pokazao kao uspešan u specifičnim, kompleksnim i visoko-promenljivim projektima. Okruženje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na ljude i saradnju.

Postoji veoma veliki broj razvijenih modela agilnog razvoja. To su: Extreme Programming (XP), Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum, Feature Driven Development (FDD), Agile Modeling (AM) i drugi. Svi oni su zasnovani na agilnim principima, ali se istovremeno i značajno međusobno razlikuju po načinu realizacije procesa razvoja.

3.10 Kombinovani modeli

Napred opisani modeli su uglavnom prikazivani kao alternativni, a manje kao komplementarni modeli razvoja. U mnogim situacijama modeli se mogu kombinovati tako da se postignu prednosti od svih na samo jednom projektu. Spiralni model je i sam primer dobre kombinacije dva modela, kao što je i model unificiranog procesa razvoja. Međutim, i drugi modeli mogu poslužiti kao osnova na koju će se integrisati neki modeli.

Prikupljanje i selekcija zahteva

AnalizaSpiralni

modelPrototip 4GT

4GT

Testiranje

Iteracije

Dizajn

Kodiranje

4GT

Iteracije

Sistem

Održavanje

Ne treba biti dogmatičan u izboru određenog modela u razvoju informacionog sistema. Priroda aplikacije će diktirati model koji bi trebalo primeniti. Kombinovanjem modela, rezultat postignut u celini može biti povoljniji nego što bi to bio prosti zbir rezultata postignutih pojedinim modelima.

4. Metodi i tehnike razvoja informacionih sistema Metodi predstavljaju neophodan i uz određene pretpostavke propisani sistematizovani način na koji se izvršavaju pojedini zadaci odnosno aktivnosti razvoja informacionog sistema. Metodi pokrivaju široki spektar aktivnosti među kojima su: planiranje i procenjivanje projekata, analiza sistemskih i softverskih zahteva, projektovanje strukture podataka, definisanje arhitekture programa, kodiranje, testiranje i održavanje. Oni su bazirani na jednom ili više principa realizacije.

Proceduru razvoja informacionih sistema je celishodno realizovati primenom određenih metoda i tehnika. Izabrati odgovarajući metod i tehniku, koji će se primeniti u razvoju nije jednostavno, obzirom da su raspoložive brojne mogućnosti. Metodi i tehnike se mogu međusobno kombinovati nezavisno od toga koji je metod i tehnika najpogodnija za rešavanje datog problema. Najznačajnija težnja prilikom pravilnog izbora je minimizacija troškova razvoja i obezbeđenje visoko kvalitetnog proizvoda.

Metodi i tehnike u razvoju informacionih sistema uvek uvode specijalne jezičke ili grafičke notacije i grupe kriterijuma u definisanju kvaliteta softvera. Oni treba da budu nezavisni od područja primene. Drugim rečima, moraju obezbediti rešenje različitim problemima, na različite načine. Metodi i tehnike

razvoja su know-how koji se može uspešno primeniti u razvojnom procesu pri izvršenju pojedinih aktivnosti.

Naravno, ne postoji takav razvoj kojem nedostaju principi i metodi, ali ne postoje ni metodi koji se mogu primeniti u rešavanju svakog problema. U tom smislu, primarni i veoma odgovoran zadatak je izabrati za korisnika, sistem i proces razvoja najpogodniji i najprilagodljiviji metod i tehniku. Pravilan izbor ne podrazumeva definisanje jednog određenog metoda i tehnike, već u zavisnosti od kompleksnosti i vrste problema kombinaciju više različitih metoda i tehnika.

Metodi i tehnike razvoja informacionih sistema se mogu grupisati prema različitim kriterijumima, ali ih je veoma teško jednoznačno razvrstati. Najčešće se ipak grupišu s obzirom na faze razvoja informacionih sistema u kojima se primenjuju.

Kao izraz potreba za rešavanjem sve složenijih problema putem računara, razvijene su metodologije. One predstavljaju jedinstveni sistem metoda, čijim povezivanjem je omogućeno projektantima da na sistematizovani način pokriju više ili sve faze razvoja softvera.

5. Sredstva razvoja informacionih sistema Sredstva razvoja obezbeđuju automatizovanu ili poluautomatizovanu podršku u primeni metoda. Oni predstavljaju pomoć neophodnu da bi se automatizovale aktivnosti razvoja informacionih sistema kao: upravljanje projektom odnosno planiranje, procenjivanje, terminiranje, raspoređivanje, modeliranje, analiza, projektovanje (dizajn), kodiranje, dokumentovanje, testiranje, integracija elemenata sistema, upravljanje konfiguracijom, kontrola kvaliteta softvera i dr.

U praksi, danas svaki metod poseduje određeno pomoćno sredstvo, instrument, alat. Kada su alati na takav način integrisani u jedan sistem da se rezultati kreirani od jednog alata mogu upotrebiti i od drugog alata, tada govorimo o CASE tehnologijama. U nastavku su od sredstava upravo odabrane za detaljniji prikaz CASE tehnologije i UML - alati za vizuelno modelovanje.

5.1 Automatizacija procesa razvoja - CASE tehnologije

Pojam, osobine i struktura CASE tehnologije

Computer Aided Software Engineering (CASE) tehnologije označavaju softver koji se upotrebljava u razvoju drugih softverskih proizvoda. To je softver kojim se automatizuju aktivnosti životnog ciklusa razvoja softverskih proizvoda i koji obezbeđuje informacije o razvijenom softverskom proizvodu. U najopštijem slučaju, pojam CASE se upotrebljava za svaki softver namenjen za automatizaciju bilo koje aktivnosti procesa razvoja softvera. Saglasno tome, CASE tehnologije pokrivaju dijapazon od pojedinačnih alata za automatizaciju određenih aktivnosti, do kompletnih softverskih alata za automatizaciju većine koraka metodologije razvoja informacionih sistema. CASE tehnologije ne predstavljaju zamenu za bilo koji metod ili tehniku razvoja, već samo dodatak metodu ili tehnici u generisanju kvalitetnog proizvoda. Njihovo korišćenje je interaktivno, prilagođeno korisniku uz naglasak na upotrebu grafike.

CASE je akronim koji je prva koristila Nastec Corporation 1982. godine. Akronim poseduje dva značenja. CASE se koristi za označavanje pojma computer-aided software engineering, ali takođe i za označavanje pojma computer-aided systems engineering. U nastavku ovog teksta, CASE će označavati pojam Computer - Aided Software Engineering, koji se može prevesti kao inžinjerski razvoj softvera (i informacionih sistema) uz pomoć računara.

CASE tehnologije su razvijene kao rezultat nastojanja osoba, koje se bave razvojem softvera i informacionih sistema da unaprede sopstvenu produktivnost. Naime, ironičnom se smatrala situacija da se primenom informacionih tehnologija teži povećati produktivnost rada drugih, ignorišući pri tome potencijal računara za unapređenje sopstvene produktivnosti. Pored povećanja produktivnosti, osnovni ciljevi primene CASE tehnologije su: skraćenje vremena realizacije projekata razvoja informacionih sistema, povećanje kvaliteta i nivoa performansi informacionih sistema putem stroge primene principa, metoda, tehnika i procedura razvoja. Da bi se navedeni ciljevi postigli bila je neophodna disciplinirana primena konzistentne metodologije, čije faze odnosno aktivnosti bi se realizovale uz primenu računara. Jednom rečju, rešenje se tražilo u automatizaciji postupaka razvoja informacionih sistema primenom CASE tehnologija.

CASE tehnologije se usled brzog razvoja i trenutnog stanja razvijenosti ne mogu shvatati kao prost zbir alata koji su namenjeni razvoju informacionih sistema, već kao sistemi koji integrišu: (a) hardver, (b) softver, (c) bazu podataka, (d) procedure i (e) kadrove. U CASE terminologiji integralna celina hardverskih i softverskih komponenti se naziva CASE alatom. Procedure se nazivaju CASE metodologijom, a baza podataka CASE skladište (repozitorijum) enciklopedija.

Uspešna primena CASE tehnologije pretpostavlja prethodno opredeljenje i usvajanje odgovarajuće metodologije razvoja informacionih sistema. Naime, CASE tehnologije, posebno one koje su strukturirane od više CASE alata, mogu biti zavisne ili nezavisne od metodologije razvoja. Kada su zavisne od metodologije, one su restriktivne i zahtevaju strukturirano okruženje: tehničkih i ljudskih resursa, propisanih standarda i procedura, kao i jedinstenog metodološkog pristupa. Međutim, kada su nezavisne od metodologije, omogućuju primenu različitih metodologija, jednostavnije su i lakše za primenu, ali zbog manje standarda i propisanih procedura mogu proizvesti veoma negativne posledice u razvoju. Veoma često ne podržavaju ni kritične prelazne tačke između razvojnih faza.

CASE tehnologije zahtevaju disciplinovani pristup razvoju informacionih sistema, odnosno CASE tehnologije moraju biti odabrane i primenjene u onim aktivnostima za koje su i namenjene. Osobe koje rade sa njima moraju biti na adekvatan način obučene. Naime, CASE tehnologije su samo alati u rukama projektanata ili drugih korisnika, čiji efekat zavisi ne samo od kvaliteta CASE tehnologije već i od njihove sposobnosti i znanja. CASE tehnologije automatizuju većinu rutinskih aktivnosti razvoja. Još uvek je njihovo uvođenje u podršci kreativnijih aktivnosti razvoja neuspešno. Takođe, i želja da se podrži timski rad u razvoju informacionih sistema CASE tehnologijama je delimično ostvarena.

Opštu strukturu CASE tehnologije čine:

� Alati za dijagramiranje – služe za grafičko predstavljanje procesa, podataka i kontrolnih struktura i čine osnovu većine tehnologija.

� Alati za generisanje formi i izveštaja – služe za automatizovani razvoj računarskih formi i izveštaja putem kojih će korisnici biti u interakciji sa novim sistemom.

� Alati za analizu – služe u upravljanju kompleksnim razvojem velikih sistema, generišu izveštaje putem kojih se automatski proveravaju nekompletne, nekonzistentne ili nekorektne specifikacije u dijagramima, formama i izveštajima.

� Alati za projektovanje – služe za izgradnju komponenata sistema.

� Alati za generisanje dokumentacije – služe u izradi tehničke i korisničke dokumentacije u standardnim formatima.

� Alati za generisanje koda – služe za automatizovano generisanje koda programa i koda definicije baze podataka direktno iz dizajniranih dokumenata, dijagrama, formi i izveštaja.

� CASE skladište (enciklopedija).

Treba naglasiti, da ne poseduju sve CASE tehnologije navedenu opštu strukturu, mada softverske kompanije uglavnom teže da razviju u sopstvenoj režiji ili putem saradnje određene CASE tehnologije koje čine zaokružene celine. Takođe, one nemaju ni istu moć, pa se u primeni najčešće kombinuju alati različitih CASE tehnologija. Upotrebljavaju se tako alati iz jedne tehnologije u realizaciji jedne faze razvoja, a drugi alati iz druge tehnologije u realizaciji druge faze razvoja.

Ovakva primena CASE tehnologije stvara određene probleme jer ne postoji definisana standardna struktura CASE enciklopedije. Podaci u enciklopediji koje pružaju određeni alati uglavnom su nekompatibilni sa podacima u enciklopediji potrebnim za druge alate. Različite tehnologije i alati imaju različite standarde i formate podataka, pa se o tome pri izboru mora posebno voditi računa.

Najznačajnija korist upotrebe CASE tehnologije se svakako postiže ukoliko se integrišu svi alati koji čine njenu strukturu, da bi se njihovim povezivanjem integrisali i svi podaci kojima isti upravljaju. Integrisani alati se oslanjaju na zajedničku terminologiju, notaciju, metode i tehnike za razvoj sistema. Kompletno integrisani alati imaju zajednički korisnički interfejs i zajedničko skladište podataka za sve alate, tako da se informacije mogu lako deliti između pojedinih alata i aktivnosti životnog ciklusa razvoja bez prevođenja podataka iz jednog formata u drugi.

CASE skladište

CASE skladište, kao centralna baza podataka, je jezgro i najbitniji segment za integraciju alata koji se koriste kroz različite faze životnog ciklusa razvoja. Ono predstavlja centralnu komponentu strukture

Dokumentacija

Informacije o projektu

Izvorni i objektni kod

Standardna biblioteka

Rezultati analize i dizajna

Forme i

Izveštaji

Dijagrami

CASE skladište

CASE tehnologije, sponu između svih nabrojanih komponenti strukture CASE tehnologije, i ne samo to, već pruža mogućnost da se putem nje pojedine faze razvoja softverskog proizvoda automatski međusobno nadovezuju i pri tome rezultati iz određene faze istovremeno stavljaju na raspolaganje alatima u narednim fazama procesa razvoja. Što znači, da CASE skladište sadrži kompletne informacije potrebne za kreiranje, izmenu i ocenu softverskog proizvoda od iniciranja i planiranja projekta do njegovog održavanja.

CASE skladište čine dva primarna segmenta: skladište informacija i rečnik podataka.

Skladište informacija kombinuje poslovne informacije organizacije i njen aplikacioni portfolio i na taj način omogućuje automatizovanim alatima da upravljaju i kontrolišu pristup podacima u skladištu. Poslovne informacije su smeštene u korporativnu bazu podataka, dok se aplikacioni porfolio sastoji od aplikativnih softverskih rešenja (programa) koja se koriste za upravljanje poslovnim informacija.

Rečnik podataka je softverski alat koji se koristi za upravljanje i kontrolu pristupa skladištu informacija. On pruža mogućnost da se snime, čuvaju i obrade opisi relevantnih podataka organizacije, kao i resursi obrade podataka. Osobine rečnika podataka u okviru CASE skladišta su posebno od koristi za sistem analitičara zbog unakrsnog povezivanja podataka. Unakrsno povezivanje obezbeđuje da svaki podatak bude jedinstveno opisan u rečniku podataka i da istom mogu pristupati svi pojedinci (sistem analitičari i korisnici). To znači da postoji i upotrebljava se samo jedna definicija (opis) svakog podatka. Ovakav opis pomaže da se izbegne dupliranje podataka i ujedno čini razvoj i održavanje sistema efikasnijim. Takođe, u okruženju integrisanih CASE alata, svi dijagrami, forme, izveštaji i programi se mogu automatski ažurirati jednom promenom u definiciji (opisu) rečnika podataka.

Svaki elemenat u rečniku podataka ima standardnu "definiciju" koja uključuje informacije kao što su:

� naziv elementa i pseudonim

� tekstualni opis elementa

� lista elemenata sa kojima je u vezi

� tip elementa i format

� interval prihvatljivih vrednosti

� ostale informacije jedinstvene za odgovarajuću obradu elementa.

Pored napred navedenog efekta korišćenja CASE skladišta, koji se postiže integracijom podataka svih povezanih alata, treba istaći da CASE skladište obezbeđuje i dodatne efekte, u aktivnostima upravljanja projektima i ponovnom korišćenju izgrađenih komponenata softvera.

Obzirom da razvoj softverskih proizvoda podrazumeva izvršenje velikog broja aktivnosti i zahteva uključenje većeg broja učesnika u realizaciji projekta, neophodno je koristiti tehniku upravljanja projektom putem koje bi se najefikasnije koordinirale aktivnosti i učesnici razvoja. CASE skladište obezbeđuje bogatstvo informacija za menadžere projekata i omogućuje im da obavljalju odgovarajuću kontrolu na njima. Putem CASE skladišta, projektni menadžer može ograničiti pristup članovima razvojnog tima samo onim delovima projekta i aktivnostima za koje su oni odgovorni i tako redukovati složenost sistema za dati tim i obezbediti sigurnost od nepažljivo izmenjenih i izbrisanih podataka. Podela dozvoljava da više timova radi paralelno na različitim aspektima jednog sistema, redukujući krajnje vreme razvoja sistema.

Takođe, CASE skladište obezbeđuje određene efekte u ponovnom korišćenju izgrađenih komponenti softvera (reusability). U velikim organizacijama sa mnogo softverskih rešenja, više od 75% programskih aplikacija sadrži značajan broj identičnih funkcija. Prema tome, lak put za projektante i programere sistema da povećaju svoju produktivnost je da prestanu da reinvestiraju u funkcije. Ukoliko bi sva softverska rešenja bila kreirana korišćenjem CASE tehnologije sa zajedničkim skladištem, bilo bi moguće da se ponovo koristi značajan deo ranije izgrađenih komponenti sistema u razvoju novih. Postoje brojne komponente razvoja koje bi se mogle ponovo upotrebiti, a čijom upotrebom bi se skratilo vreme, snizili troškovi i poboljšao kvalitet razvijenih softverskih proizvoda.

Postoji tri tipa CASE skladišta – pasivna, aktivna i dinamična. Pasivna CASE skladišta nisu u interakciji sa procesom razvoja aplikacija, i ne održavaju se automatski sa meta podacima kreiranim tokom razvoja. Svako ažuriranje skladišta se izvodi nezavisno i direktno od strane korisnika. Aktivna CASE skladišta se ažuriraju automatski u pozadini (background modu) dok se realizuju druge razvojne aktivnosti. Dinamička CASE skladišta su povezana i ažuriraju se tokom izvršenja aplikacija.

Klasifikacija CASE tehnologija

Klasifikacije CASE tehnologija služe da bi se lakše razumeli i spoznali pojedini tipovi CASE tehnologija i njihove uloge u podršci razvoju softvera i informacionih sistema. Postoje brojni kriterijumi za klasifikaciju CASE tehnologija. Svaki od kriterijuma pruža različite poglede na iste. Tako se one najčešće klasifikuju: obzirom na funkcije koje poseduju, obzirom na aktivnosti koje u procesu razvoja podržavaju i obzirom na način kako su organizovani u integrisane celine za podršku jedne ili više aktivnosti procesa razvoja.

Klasifikacija CASE tehnologija obzirom na funkcije koje poseduju je prikazana u tabeli 1.

Tab.1.

Tipovi CASE tehnologija Primeri

Alati za planiranje PERT alati, alati za predviđanje, spregnute tabele

Alati za editovanje tekst editori, dijagram editori, procesori teksta

Alati za upravljanje konfiguracijom sistemi za upravljanje verzijama, alati za izgradnju sistema

Alati prototipskog razvoja generatori korisničkog interfejsa, jezici visokog nivoa

Alati za podršku metoda rečnici podataka, generatori koda

Alati za procesiranje jezika kompajleri, interpreteri

Alati za analizu programa statički analizatori, dinamički analizatori, generatori unakrsnih zavisnosti

Alati za testiranje generatori test podataka, alati za upoređivanje datoteka

Alati za pronalaženje grešaka interaktivni sistemi pronalaženja grešaka

Alati za izradu dokumentacije alati za definisanje izgleda, editori za slike

Alati za reinžinjering sistemi za programsko restruktuiranje, sistemi unakrsnog povezivanja

Jedan od mogućih kriterijuma pri klasifikaciji je i kompletnost CASE tehnologije, koja ukazuje na broj aktivnosti razvoja softvera i informacionih sistema, čiju automatizaciju CASE tehnologija podržava. Prema ovoj klasifikaciji diferenciraju se:

� Upper CASE - CASE tehnologije namenjene za automatizaciju aktivnosti faze strategijskog planiranja i aktivnosti faze upravljanja projektima.

� Middle CASE - CASE tehnologije namenjene za automatizaciju aktivnosti faze analize i aktivnosti faze dizajna.

� Lower CASE - CASE tehnologije za automatizaciju aktivnosti faza programiranja, testiranja i uvođenja informacionog sistema.

Prema integralnosti CASE tehnologije se strukturiraju na:

� CASE tool - CASE alati koji automatizuju pojedine aktivnosti u fazama razvoja informacionih sistema. Oni mogu biti opšte primenljivi, nezavisni/samostalni (standalone) ili povezani/grupisani u CASE workbench.

� CASE workbench - CASE tehnologije koje služe za automatizaciju aktivnosti pojedinih faza razvoja informacionih sistema. Oni se obično sastoje od kolekcije tj. više CASE alata sa manjim ili većim stepenom integracije.

� CASE environments – CASE okruženje služi za podršku celog ili najznačajnijeg dela procesa razvoja informacionih sistema. Okruženje uobičajeno uključuje nekolicinu integrisanih CASE workbench-ova.

U zavisnosti koje faze životnog ciklusa razvoja sistema pokrivaju, CASE tehnologije se strukturiraju na: Avison D.E., Fitzgerald G.

� Projektanski CASE - automatizuju prve tri faze životnog ciklusa: strategijsko planiranje, analizu i dizajn;

� Programerski CASE - automatizuju naredne tri faze životnog ciklusa: programiranje, implementaciju i eksploataciju i održavanje;

� Integrisani CASE (i-CASE) - podržava sve faze životnog ciklusa razvoja sistema.

Konačno, CASE tehnologije se razlikuju i po tome koliko su zavisne od metodologije razvoja, pa se razlikuju:

� Zavisne CASE tehnologije - zahtevaju strukturirano okruženje, u smislu tehničkih resursa, ljudskih resursa, propisanih standarda i procedura i jedinstveni metodološki pristup. Uključuju veoma ograničeni i mali broj alata.

� Nezavisne CASE tehnologije - su pod manjim uticajem određene metodologije i zato se jednostavnije i lakše primenjuje. S druge strane rezultat primene ovakvog niza alata, koji podržava različite metodologije, uz manje propisanih standarda i procedura može imati katastrofalne posledice. Pošto su alati dizajnirani za različite faze razvoja, oni često ne podržavaju kritične prelazne tačke između pojedinih faza, pa se rezultati nemogu prenositi i povezivati.

Primena CASE tehnologije u organizacijama

Osnovna svrha CASE tehnologije je da učini mnogo lakšom implementaciju filozofije pojedinačnog pristupa razvoju softvera i informacionog sistema u organizaciji sa mnogo projekata, sistema i ljudi. CASE može podržavati većinu aktivnosti životnog ciklusa razvoja. Nezavisno od toga što se CASE tehnologije koriste na mini i mainframe (velikim) računarima, skorašnji razvoj PC računara učinio ih je predominantnim CASE workstation (radnim stanicama). CASE tehnologije automatizacijom celokupnog procesa razvoja softvera i informacionog sistema, pomažu projektantima da upravljaju kompleksnim projektima razvoja informacionih sistema i da obezbede izgradnju sistema visokog kvaliteta, na vreme i u okviru budžeta.

Ciljevi primene:

� Povećanje produktivnosti projektanata i programera.

� Skraćenje vremena razvoja softverskog proizvoda.

� Viši nivo kvaliteta: projekta, softvera i dokumentacije.

� Visoka integrisanost razvojnih aktivnosti putem metodologije koju podržava i ujedno standardizovanost razvoja.

� Niži troškovi razvoja softverskog proizvoda.

� Jednostavnije, lakše i jeftinije održavanje i dalji razvoj softverskog proizvoda.

� Reusability modula i dokumentacije

Najčešće navođeni razlozi primene CASE tehnologije u organizacijama su:

� unaprediti kvalitet razvijenog sistema,

� povećati brzinu dizajniranja i razvoja sistema,

� olakšati i unaprediti proces testiranja putem upotrebe automatizovane provere,

� unaprediti povezivanje razvojnih aktivnosti putem odabrane zajedničke metodologije,

� unaprediti kvalitet i celovitost (kompletnost) dokumentacije,

� unaprediti znanje učesnika u procesu razvoja,

� pomoći u standardizaciji procesa razvoja,

� unaprediti upravljanje projektima razvoja sistema,

� pojednostaviti održavanje programa,

� promovisati ponovno korišćenje razvijenih komponenti softvera i dr.

Brojna empirijska istraživanja, međutim, identifikuju i veliki broj prepreka za uvođenje CASE tehnologija. Među njima su neke iz perspektive pojedinaca, dok je mnogo veći broj onih iz perspektive organizacije. Najčešće se navode sledeće:

� visoki troškovi nabavke CASE tehnologije,

� visoki troškovi obuke,

� neizvesnost efekata od uvođenja CASE tehnologije,

� nezrelost CASE tehnologije,

� nedostatak podrške menadžmenta,

� otpor analitičara i programera promenama koje CASE tehnologija donosi, posebno u slučaju potrebe usvajanja nove metodologije, metoda i tehnika,

� teškoće u menjanju postojeće prakse i nepostojanje standarda razvoja u organizaciji u kojoj se CASE tehnologija želi primeniti.

Efekti primene CASE tehnologije

Pri razvoju CASE tehnologije, specijalna pažnja se posvećuje automatizaciji prve tri faze životnog ciklusa. Razlog za to su visine relativnih troškova otklanjanja greške u pojedinim fazama životnog ciklusa. Što se greška kasnije otkrije, to više košta njeno otklanjanje.

Efektivna primena CASE tehnologije značajno doprinosi kvalitetu procesa razvoja softvera i informacionog sistema. CASE tehnologije su korisne jer u izvršenju svoje funkcije, štede vreme, štede radnu snagu, štede novac ili omogućuju nešto što je bez njih teško ili uopšte ne izvodivo. Produktivnost organizacije se povećava, a greške u razvoju se značajno smanjuju. CASE tehnologije u razvoju softvera i informacionih sistema doprinose nizu pozitivnih efekata:

� grafička prezentacija modela sistema,

� detekcija grešaka i korekcija nekonzistentnosti,

� interaktivna izrada prototipa sistema,

� identifikacija komponenti sistema koji se mogu ponovo upotrebiti u razvoju,

� efektivno upravljanje razvojem sistema,

� efikasna kontrola utrošenog vremena u razvoju,

� kontrola trošenja sredstava predviđenih za razvoj,

� automatizovano generisanje uvek ažurne dokumentacije i drugi.

Upravo zbog navedenih efekata, CASE tehnologije se preporučuju kao rešenje mnogih problema svojstvenih tradicionalnom načinu razvoja sistema, kao što su kašnjenje u realizaciji aktivnosti i faza, netačnost, teško sprovođenje izmena i loša dokumentovanost. Za sada, period primene CASE tehnologija je relativno kratak da bi se mogli tačnije proceniti efekti. Empirijska istraživanja pokazuju da se poboljšanja kreću u širokom intervalu, od neznatnih do veoma značajnih. Bez obzira na različite rezultate istraživanja dobijene u različitim studijama, ohrabruje da većina ukazuje na bitna poboljšanja. Povećanje produktivnosti, izgradnja mnogo kvalitetnijih sistema u kraćem vremenskom intervalu, uticali su na one koji se bave razvojem sistema da izmene ili kompletno restruktuiraju svoje metodologije razvoja softvera i informacionih sistema kako bi implementirali CASE tehnologije.

Osobine CASE tehnologije

Generalno posmatrano, razvoj CASE tehnologije zavisi od specifičnosti zahteva korisnika, okruženja u kojem se ista želi primeniti i ideja o tome kako bi tehnologija mogla da funkcioniše. Standardi u izgradnji CASE tehnologija ne postoje. CASE tehnologije su brojne i pokrivaju većinu aktivnosti faza razvoja softvera i informacionih sistema.

Osobine koje treba da poseduju CASE tehnologije koji pripadaju klasi kvalitetnih tehnologija su sledeća:

1. Jednostavno i lako korišćenje - Ova osobina predstavlja meru efektivnosti tehnologije u odnosu na korisnika. Nezavisno od funkcionalnosti i potpunosti, CASE tehnologija treba da je tako kreirana da je korisnik može lako, jednostavno i bez puno razmišljanja i neizvesnosti koristiti u rešavanju projektantskih zadataka. Ukoliko to nije slučaj, tada korisnik svoje vreme provodi u razmišljanju kako bi tehnologiju koristio ili kako tehnologija uopšte radi, a to znači da ista svojom ulogom ne pomaže već samo predstavlja smetnju ili čak prepreku u radu.

2. Tehnologija treba da poseduje mogućnost da otkriva greške korisnika, a poželjno je da sama te greške i otklanja. Tehnologija treba da omogući interakciju sa korisnikom putem dijaloga koji je razumljiv i prihvatljiv za korisnika. Ona treba da je fleksibilna i da se može kombinovati sa drugim tehnologijama kako bi se zadovoljili različiti zahtevi korisnika. Posebno je značajno da se minimiziraju ili potpuno isključe nepredviđena reagovanja tehnologije, koja obično rezultiraju nezadovoljstvom korisnika. CASE tehnologija ne bi smela svojim izlazima da iznenađuje, zbunjuje i blokira rad korisnika. Naredbe koje korisnik upotrebljava treba da su jasne, jednostavne i konzistentne.

3. Podobnost - Kvalitetna je ona tehnologija koja poseduje takav nivo podobnosti i performansi da može da podrži rešavanje velikog broja aktivnosti u razvoju informacionih sistema. Podobnost se izražava kroz obim kojim jednostavne naredbe tehnologije mogu uzrokovati njene glavne efekte. Uz ovo obeležje pridružuje se i zahtev da CASE tehnologija treba da bude u mogućnosti da pruža informacije o sopstvenom stanju. Dobra tehnologija može impresionirati i mnogo većom podobnošću nego što je ona ustvari, ukoliko poseduje više znanja o sopstvenom stanju.

4. Velika snaga tj. moć - Snaga tehnologije se ocenjuje na osnovu kombinacije sledećih faktora:

� pouzdanost tehnologije,

� osobine tehnologije koje se ispoljavaju pri oskudnim ili lošim uslovima,

� funkcionisanje,

� težina posledica nedostataka tehnologije,

� konzistentnost aktivnosti u funkcionisanju tehnologije i

� način na koji se tehnologija integriše u okruženje.

5. Pouzdanost je značajan zahtev koji se ispoljava kao sposobnost alata da rastereti korisnika od rizika greške koju sam napravi. CASE tehnologija treba da otkriva odnosno otklanja greške i posledice koje zbog istih nastanu. Tehnologija treba da poseduje sopstveni mehanizam samotestiranja koji obezbeđuje njegovo pravilno funkcionisanje.

6. Konzistentnost aktivnosti tehnologije potvrđuje veličinu tj. obim njene snage. Konzistentnost podrazumeva dobro definisanu sintaksu i semantiku. Istovremeno, tehnologija mora biti tako razvijana da podržava kompatibilnost između pojedinih verzija.

7. Funkcionalnost - Ova osobina nije definisana samo zadatkom zbog kojeg je tehnologija dizajnirana već i metodima koji se upotrebljavaju u izvršenju zadataka. Broj tehnologija koje podržavaju metodologije je veoma velik. Efikasnost koju ispoljava tehnologija u podršci metoda može neposredno doprineti razumevanju i definisanju osobina tehnologije, kao i određenju kvaliteta i korisnosti izlaza koje obezbeđuje.

8. CASE tehnologije integrišu metode i povezuju ih sa metodologijom. Pojedine tehnologije podržavaju jednu, više ili sve faze metodologije i prenose rezultate između njih. Koncepcija i struktura CASE tehnologije je određena izabranom metodologijom i njoj pripadajućim metodama i tehnikama. Tehnologija mora da obezbedi konzistentnu primenu metodologije i metoda na kojima se zasniva. Tako

ona mora funkcionisati korektno i kontrolisati da li se metodologija sprovodi u potpunosti. Pored toga, CASE tehnologija mora generisati izlaze koji su korektni i striktno definisani metodologijom.

9. Lako povezivanje sa postojećim sistemom - CASE tehnologija se mora lako i nesmetano uvesti u postojeći informacioni sistem. Ona se jednostavno instalira i omogućuje da se postojeće strukture datoteka ili baze podataka koriste na isti način kao i pre njene upotrebe. CASE tehnologija mora omogućiti i prenos podataka odnosno njihovu razmenu između različitih CASE tehnologija koje se već koriste u organizaciji.

10. Kvalitet podrške CASE tehnologije - Prilikom vrednovanja tehnologije sa aspekta kvaliteta podrške, značajno je sagledati i sledeće elemente podrške:

� reputacija dobavljača,

� zrelost tehnologije i njena rasprostranjenost,

� mogućnost smanjenja troškova pri kupovini više kopija,

� mogućnost iznajmljivanja tehnologije,

� mogućnost vraćanja tehnologije uz povrat sredstava,

� mogućnost dobijanja punih prava i pristupa izvornom kodu,

� mogućnost i uslovi održavanja,

� vreme odziva u održavanju,

� pružanje pomoći u obezbeđenju problematičnih odgovora,

� da li korisnik raspolaže pravom na nove verzije tehnologije bez naknade,

� koji je rok garancije,

� koji su rokovi isporuke,

� kakvi su uslovi obuke za korisnike tehnologije,

� da li postoje efikasni programi obuke i

� kakva su stručna i pedagoška svojstva kadrova koji vrše obuku.

CASE tehnologije obezbeđuju integralno razvojno okruženje koje pruža podršku svim aktivnostima od planiranja, preko dizajna do održavanja softvera i informacionog sistema. Pri tome, omogućujući optimalno funkcionisanje sistema uz najmanji mogući procenat grešaka.

Zahtevi i načini integracije CASE tehnologija

Već je ranije pomenut značaj i potreba integracije CASE tehnologija. Integracijom se obezbeđuje povezivanje CASE alata na način da su svima raspoložive prema potrebi sve informacije nastale u procesu razvoja, da je upotreba alata integrisana i da im je filozofija razvoja integrisana putem primene standardizovanog procesa u kojem se primenjuje savremena praksa i proverene metode i tehnike. Integrisana CASE tehnologija mora zadovoljiti sledeće zahteve:

� obezbediti mehanizam za podelu svih informacija nastalih u procesu razvoja između alata u njenom okruženju,

� omogućiti da se svaka promena određene informacije po potrebi reflektuje na ostale informacije sa kojima je ona u vezi,

� obezbediti kontrolu verzija za sve informacije nastale u procesu razvoja,

� dozvoliti direktan pristup svakom alatu koji je deo integrisane CASE tehnologije, odnosno njenog okruženja,

� omogućiti korisnicima svih alata konzistentan pogled i upotrebu korisničkog interfejsa,

� podržati komunikaciju između učesnika razvoja,

� prikupiti tehničke parametre koji se mogu upotrebiti za unapređenje procesa ili proizvoda i dr.

CASE tehnologije se mogu na različite načine integrisati. Mali je broj alata koji su potpuno nezavisni i tako se koriste. Takvi alati kreiraju samostalno izlaze u vidu dokumenata, programa, podataka i njihova veza prema ostalima u okruženju je papir koji prenosi projektant. U praksi, CASE tehnologije se povezuju i razlikujemo sledeće načine integracije:

Razmena podataka (Data exchange) - je najčešći slučaj i mogućnost koju poseduje većina alata, da se iz njih eksportuju podaci koje oni poseduju, tako što se kreira nestrukturirana datoteka u formatu štampe. Na taj način se vrši neposredna razmena podataka između dva alata, uobičajeno posredstvom prenosnog filtera. Ovaj oblik integracije omogućuje da se zaštite podaci alata, eliminiše potreba ponovnog unošenja podataka i spreče štamparske greške. Brojni prevodioci se razvijeni za potrebe ove razmene. Uglavnom su oni poreklom od isporučilaca alata, ali su takođe i od strane konsultanata i korisnika.

Nedostatak ovog načina je što se uglavnom samo deo prevedenih podataka može prihvatiti i koristiti u drugom alatu, pošto nisu kompatibilni. Takođe, nedostatak je i što stalni razvoj softvera zahteva da se i nakon manjih izmena podaci prevode i prenose, a što je vremenski zahtevno. Brojne verzije mogu lako dovesti do odsustva sinhronizacije. I ukoliko se koristi veliki broj alata na jednom projektu, neprihvatljivo je da se masovno prenose i prevode podaci. Prenos podataka je jednosmeran, jer ne postoje mogućnosti da se vrše izmene obostrano, a što znači da dolazi u pitanje održavanje integralnosti konfiguracije kroz nizove alata koji se upotrebljavaju.

Zajednički pristup alatima (Common Tool Access) - predstavlja sledeći nivo integracije, koji omogućuje korisniku da poziva veći broj različitih alata na isti način, npr. iz pull-down menija. U multitasking okruženju to znači da korisnik može simultano otvarati alate, ručno koordinirati ulaze u njih i upoređivati izlaze dizajna na način kako želi. Npr. korisnik može istovremeno prikazati dijagrame tokova podataka, dijagrame strukture, rečnik podataka i izvorni kod koje održavaju različiti alati. U ovom okruženju, razmena podataka između alata može biti uprošćena uvođenjem procedure prevođenja običnim izborom menija ili izborom makro funkcije.

Zajedničko upravljanje podacima (Common Data Management) - predstavlja način integracije pri kojoj se podaci iz različitih alata održavaju u jednoj logičkoj bazi podataka, koja može biti fizički centralizovana ili distribuirana. Integracija na ovaj način uprošćava razmenu informacija i podiže nivo integralnosti deljenih podataka, pošto svaki alat ima stalni i trenutni pristup ažurnim podacima. Istovremeno, prava pristupa podacima se mogu kontrolisati, a može se upravljati i verzijama alata, manuelno putem procedura prijavljivanja i odjavljivanja. Tipično, postoji funkcija integrisanja podataka koja omogućuje projektantima koji rade na različitim delovima aplikacija da kombinuju svoje poslove. Ukoliko ovakva grupa alata poseduje karakteristiku provere na projektu, tada je moguće utvrđivanje nekonzistentnosti između rezultata pojedinih autora.

Mada se podacima iz različitih alata upravlja zajedno na nivou zajedničkog upravljanja podacima, alati ne poznaju međusobno interne strukture podataka i semantiku predstavljanu u dizajnu. Konkretno,

potreban je i dalje korak prevođenja koji se manuelno aktivira da bi se jednom alatu omogućilo korišćenje izlaza drugog alata.

Podela podataka (Data Sharing) - je način integracije pri kojem alati poseduju kompatibilne strukture podataka i semantiku i mogu direktno upotrebljavati međusobno podatke bez prevođenja. Svaki alat je tako dizajniran da bi bio kompatibilan sa ostalima u uslovima podele podataka. Zbog toga, podela podataka se javlja uglavnom kod alata istog proizvođača ili kod više proizvođača koji su se strateški povezali upravo da bi proizveli takav proizvod (čak možda i na zahtev jednog korisnika). Za realizaciju ovog načina povezivanja, ključnu ulogu su odigrali standardi koji obezbeđuju dobru osnovu za integraciju CASE alata.

Međusobna operatibilnost (Interoperability) - je najviši nivo integracije pojedinačnih alata i javlja se ukoliko je realizovan zajednički pristup alatima i podela podataka.

Puna integralnost (Full Integration) - Da bi se postigla puna integrisanost CASE okruženja, neophodna su još dva dodatna elementa: upravljanje meta podacima i sredstva kontrole. Meta podaci su informacije o procesu softverskog inženjeringa proizvedene od pojedinih CASE alata. Meta podaci uključuju:

� definicije objekata (tip, atribute, veze),

� veze i zavisnosti između objekata proizvoljne detaljnosti,

� pravila dizajna softvera,

� tokove procesa, procedure i događaje.

Sredstva kontrole omogućuju pojedinačnim alatima da obaveste ostatak okruženja (ostale alate, rukovodioca podataka,...) o značajnim događajima i pošalju zahteve za akcijom ostalim alatima i servisima putem trigera. Npr. alat za dizajn bi morao obavestiti alat za upravljanje konfiguracijom da je kreirana nova verzija dokumenta dizajna i da je potrebno da ovaj izvrši proveru konzistentnosti. Sredstva kontrole pomažu u održavanju integriteta okruženja i obezbeđuju sredstva za automatizaciju standardnih procesa i procedura.

Ocena i izbor CASE tehnologije

Proces ocene vrednosti i izbor CASE tehnologije se izvodi od strane organizacije koja ga želi nabaviti. Svaka organizacija ima sopstvene potrebe i zahteve pri nabavci tehnologije. Proces procene čine sledeći metodološki koraci:

� analiza potreba i zahteva korisnika,

� analiza postojećeg okruženja,

� identifikovanje potencijalne liste CASE tehnologija i

� primena kriterijuma za ocenu kvaliteta i izbor tehnologije.

Analiza potreba i zahteva korisnika predstavlja veoma značajan korak u izboru CASE tehnologije. Organizacija treba da opredeli koji model razvoja softvera će primeniti, koji su osnovni tehnički i upravljački zadaci. Tačno se moraju identifikovati oni zadaci koji se žele potpuno ili delimično realizovati uz pomoć automatizovanih alata.

Analiza postojećeg okruženja je u potpunosti povezana sa prethodnim metodološkim korakom. CASE tehnologija mora potpuno da bude prikladna okruženju. Ograničenja su moguća i ona se moraju uzeti u obzir. Tako npr. novac, vreme, iskustvo zaposlenih, dosadašnja praksa, odnosi sa dobavljačima i dr. Ova ograničenja ne samo da se identifikuju nego se i analiziraju sa aspekta njihove moguće promene ili otklanjanja.

Identifikovanje potencijalne liste CASE tehnologija predstavlja korak kojim se potrebama i zahtevima korisnika pridružuju moguće tehnologije koje bi iste zadovoljili. Trenutno je izbor tehnologija veoma velik, a poseduje tendenciju daljeg brzog razvoja. Prezentacije, reklamni materijali i dr. obezbeđuju inicijalne informacije o postojećim tehnologijama.

Poslednji korak ove metodologije je sigurno najznačajniji. Svi identifikovani kriterijumi se primenjuju na svaku od CASE tehnologija koje su identifikovane u potencijalnoj listi. Kriterijumi se postavljaju za potrebe najobjektivnije selekcije. Troškovi i vreme su pri tome na vrhu liste. Ukoliko postoji mogućnost nije na odmet da se dobavljač poseti i na licu mesta tehnologija upozna i testira.

Beleške i zapažanja sa testa treba da su opredeljujući u određenju koliko tehnologija zadovoljava postavljene kriterijume. Posebna pažnja se pridaje kriterijumima koji su najviše rangirani. Konačna odluka treba da se bazira i na mišljenju zaposlenih u organizaciji koji bi trebali da ostvare najveću korist od primene tehnologije.

U tabeli xxxxx su dati nazivi poznatijih CASE tehnologija i njihovih proizvođača:

CASE

tehnologija

Metodologije

razvoja

Tehnike i razvojni

alati

Sistemi upravljanja

bazama podataka

IEW Warnier-Orr SQL, DB2, IMS-DL/1, Oracle

Promod PLUS Yourdon, de Marco, Hatley/Pirbhai

Uniface Six, Source Pilot, C, Fortran

Sybase, Oracle, Informix, Ingres, OCM

Oracle CASE J. Martin, de Marco, Ernst & Young

Uniface Six, CASE Generator SQL, Forms

Oracle, DB2

Synthesis Yourdon, Coad, Constantine, Ross

C, C++, Fortran, Cobol, Magic

Novell Btrieve, SQL, Sybase, Oracle, Informix

Westmount

ISEE

Yourdon, de Marco, Chen

Ingres 4GL, Informix 4GL, Uniface Six

Ingres, Informix, Sybase

Westmount

I-CASE

Ward-Mellor, de Marco, Chen, SSADM

Ingres 4GL, Informix 4GL

Ingres, Informix, SQL

PTECH Martin-Odell, OOAD

sopstveni ugrađeni C++ generator koda

OODBMS

Paradigm Plus Rumbaugh OMT, Martin-Odell, OOIE, Booch OOAD, Coad, Yourdon, Shalaer-Mellor, AOOD

ProtoScrpt, C, C++, Ada, SmallTalk, PowerBuilder, SQL, JAVA, Corba IDL, Visual Basic

ORACLE 7, dBase, DB2, uniSQL, Access, Centura, SQLB ase, Sybase/SQL, objectStore, gemStone

PTECH Martin-Odell OOAD C++ OODBMS

Rational CASE

family

Rumbaugh OMT, Booch OOAD, Jacobson Objectory Use Case,

C, C++, Forté, Java, SmallTalk, PowerBuilder, Gupta

Oracle 7, Sybase, SQLBase, SQLServer, Watkom SQL,

UML SQLWindows, VisualBasic

Ansi SQL

System

Architect

Gane-Sarson, Ward-Mellor, Catalyst, Coad-Yourdon, OOA/OOD, deMarco, Shlaer-Mellor, OMT, Martin IE, Booch

C++, Java, SmallTalk, Corba, Delphi, Gupta, ADA, Magic, PowerBuilder, VisualBasic

DB2, dBase, SQLServer, Oracle, Sybase, InterBase, SQLBAse, Watkom, Progress

ObjectMaker OpenOML, Colbert, OMT, Booch, Coad-Yourdon

C, C++, AAD Oracle, SQL

GDPro ER/Studio C++, Java, Corba-IDL, VisualBasic

Access, OOParabase Repository

StP Software

Through

Pictures

Booch, OMT C++, Java, ADA, Corba-IDL, Forte/tool

Sybase

5.2 Vizuelno modelovanje - UML

Akronim UML je danas među najpoznatijim u informatičkom svetu i označava termin Unified Modeling Language, što u prevodu znači jedinstveni jezik za modelovanje. UML predstavlja jedinstveni jezik za vizuelizaciju, specifikaciju, konstrukciju i dokumentovanje softverskih rešenja.

Grafički jezici poput UML-a se koriste već duže vremena u razvoju softvera. Međutim, ono što je specifično za sve njegove preteče, jeste njihova neusaglašenost, koja je i bila ključna za nastanak i razvoj UML-a.

UML je nastao objedinjavanjem više objektno orijentisanih grafičkih jezika za modelovanje. Tvorci UML-a su trojica stručnjaka, poznata u informatičkom svetu pod nadimkom „tri amigosa“, Grady Booch, Jim Rumbaugh i Ivar Jacobson. Svaki od njih je razvijao sopstveni objektno orijentisani jezik za modelovanje, da bi se udružili pod okriljem firme Rational (danas u sastavu IBM-a) i miksom pojedinačnih jezika stvorili UML. Prva zajednička verzija UML-a, nastala radom ova tri autora, jeste verzija 1.0 lansirana na tržište 1997. godine, koja je posedovala osobine standarda i bila opšteprihvaćena od svih učesnika u razvoju informacionih sistema. Od tada brigu za UML preuzima grupa OMG, tj. grupa za upravljanje objektima (Object Management Group, OMG).

Trenutno aktivna verzija UML-a jeste 2.0. U njoj postoji 13 vrsta dijagrama, strukturiranih u dve osnovne grupe: dijagrami ponašanja i dijagrami strukture. U procesu razvoja softvera pojavljuju se razne uloge koje koriste različite tehnike dijagramiranja, za rešavanje različitih problema. To u stvari znači da brojni učesnici u procesu razvoja „razgovaraju“ istim jezikom. Da ne bi došlo do zabune, potrebno je napomenuti da se proces razvoja ne može obaviti samo sa UML-om. Međutim, standardizacijom i opštim prihvatanjem UML-a stvoreni su preduslovi da sve aktivnosti koje se ne realizuju UML-om budu usaglašene sa aktivnostima koje se realizuju pomoću njega. U nastavku se ukratko opisuju 13 vrsta UML dijagrama.

UML dijagrami

Dijagrami ponašanja Dijagrami strukture

Dijagrami

slučajeva

upotrebe

Dijagrami

aktivnosti

Dijagrami

mašine stanja

Dijagrami

interakcije

Dijagrami

sekvenci

Dijagrami

saradnje

Dijagrami

pregleda

interakcija

Vremenski

dijagrami

Dijagrami

klasa

Dijagrami

složene

strukture

Dijagrami

objekata

Dijagrami

komponenti

Dijagrami

rasporeda

Dijagrami

paketa

Vrste UML dijagrama u verziji 2.0 Dijagrami slučajeva upotrebe (Dijagram korisničkih funkcija)

Dijagrami slučajeva upotrebe služe za grub opis funkcionalnosti posmatranog sistema ili posmatranog dela organizacije. U principu se može konstatovati da postoje dve vrste ovih dijagrama: dijagrami slučajeva upotrebe (Use Case Diagrams) i dijagrami slučajeva upotrebe poslovnog procesa (Business Use Case Diagrams). Dijagrami slučajeva upotrebe treba da daju odgovor na pitanje „Šta sistem radi?“, dok dijagrami slučajeva upotrebe poslovnog procesa treba da daju odgovor na pitanje „Šta organizacija radi?“. Pomoću dijagrama slučajeva upotrebe predstavljaju se funkcije sistema koje će biti automatizovane, a pomoću dijagrama slučajeva upotrebe poslovnog procesa i automatizovane i manuelne funkcionalnosti.

Pretplatnik

Pregled racuna

Podnosenje zahteva za

pregled racuna

Operater

Komponente ovih dijagrama su akteri, uloge, slučajevi upotrebe i relacije. Akteri predstavljaju nekoga ili nešto što se nalazi izvan sistema ili organizacije (u zavisnosti od vrste dijagrama), a u interakciji je sa njim. Uloge se koriste samo prilikom izrade dijagrama slučajeva upotrebe poslovnog procesa i predstavljaju nekoga ili nešto što se nalazi unutar organizacije i u interakciji je sa funkcionalnostima posmatranog dela organizacije. Slučajevi upotrebe i slučajevi upotrebe poslovnog procesa služe da bi se prikazale konkretne funkcionalnosti sistema, odnosno organizacije. Ovi dijagrami predstavljaju vodilju za

kompletan proces razvoja softvera, pa se često za razvoj zasnovan na UML-u kaže da je usmeravan slučajevima upotrebe.

Dijagrami aktivnosti

Dijagrami aktivnosti služe za opisivanje logike procedura, poslovnih postupaka i toka posla. Tokovi funkcionalnosti predstavljeni dijagramima slučajeva upotrebe se opisuju dijagramima aktivnosti, koji prikazuju sve aktivnosti koje se odvijaju u okviru posmatrane funkcionalnosti. Pomoću jednog dijagrama aktivnosti moguće je prikazati više potencijalnih scenarija koji se mogu desiti pri izvršavanju neke funkcionalnosti. Ukoliko se na dijagramima slučajeva upotrebe slučaj upotrebe posmatra kao „crna kutija“, na dijagramima aktivnosti se prikazuje redosled izvršavanja aktivnosti u okviru te „crne kutije“.

Dijagrami aktivnosti sadrže: stanja aktivnosti i stanja akcije, tranzicije, objekte, grananja, početnu (označava se crnim krugom) i krajnju tačku (označava se crnim krugom u belom krugu). Između početne tačke i prve akcije navodi se događaj koji je pobuđuje. Tranzicije povezuju početnu tačku, akcije i krajnju tačku i predstavljaju se usmerenim linijama. Ukoliko se tranzicije granaju, tačka u kojoj se vrži grananje prikazuje se rombom.Stanja aktivnosti i akcija navode se u elipsama, a za objekte važi standardna notacija.

Pristigle zahtevi

Prikupljanje

zahteva

Obrada

zahteva[Korektni zahtevi]

[Nekorektni zahtevi]

Dijagrami stanja mašine

Ovi dijagrami služe za prikazivanje ponašanja dela sistema, odnosno ponašanje objekta kao instance posmatrane klase. Na njima se predstavljaju stanja posmatranog objekta, tranzicije između stanja i događaji koji uzrokuju tranzicije objekta iz jednog u drugo stanje. Crtanje dijagrama stanja mašine se ne preporučuje za sve klase sistema. Najčešće se crtaju za najznačajnije klase sistema ili se uopšte ne crtaju ukoliko razvojni tim informacije koje se dobijaju ovim dijagramima dobije na drugi način.

Predstavljaju uopštenje dijagrama aktivnosti. Pomoću dijagrama stanja se modeluju dinamički aspekti sistema koji se projektuje. Koriste se za modelovanje životnog veka objekta, a najčešće se modeluju stanja objekata koji reaguju.

Na dijagramu se, u obliku konačnog automata, prikazuje odvijanje upravljanja od stanja do stanja. Ovo se prikazuje tako što se stanje prikazuje pravougaonikom sa zaobljenim ivicama, dok je tranzicija relacija izmedju dva stanja i prikazuje se strelicom, a stanje od kojeg počinje kreiranje ovog konačnog automata se prikazuje crnim kružićem.

Neaktivan Povezan

PozivanjeObrada

Dijagrami sekvenci i dijagrami saradnje

Ove dve vrste dijagrama prikazuju iste informacije iz različitih perspektiva. Pomoću njih se predstavljaju objekti koji se pojavljuju u okviru slučaja upotrebe i poruke koje oni razmenjuju. Razlika između ovih dijagrama je u tome što dijagrami sekvenci u prvi plan stavljaju vremensku dimenziju, tj. razmenu poruka sa aspekta vremena, dok dijagrami saradnje zanemaruju vremensku dimenziju i prikazuju saradnju objekata kroz razmenu poruka. CASE alati pomoću kojih se crtaju ovi dijagrami omogućavaju automatsko generisanje jedne vrste dijagrama, na osnovu nacrtanog dijagrama druge vrste.

Dijagram sekvence predstavlja specijalni slučaj dijagrama interakcije, a njime se prikazuje skup poruka razmenjenih između objekata koji sarađuju, da bi se realizovala određena operacija ili dobio neki rezultat. Ovaj dijagram se prikazuje u dve dimenzije: vertikalna dimenzija prikazuje vreme, a horizontalna određene objekte.

Na dijagramu se prikazuju poruke koje se razmenjuju u definisanom vremenskom redosledu između uočenih objekata. Među objektima se uspostavljaju veze, a dijagramom se prikazuje linija života svakog prikazanog objekta. Isto tako ovi dijagrami sadrže fokus upravljanja kojim se prikazuje vremenski period u kojem objekat vodi neku akciju.

Pretplatnik Transakcija

Upisi kli jenta(a,b,c)

Uradjeno

Prekini

Elementi dijagrama sekvenci se predstavljaju na sledeći način:

� objekti se prikazuju na ranije opisani način,

� veze između objekata su poruke, koje se prikazuju položenim usmerenim linijama,

� linija života objekta je vertikalna isprekidana linija,

� fokus upravljanja se predstavlja uzanim, vertikalno postavljenim pravougaonikom.

Dijagrami saradnje su semantički ekvivalentni dijagramima sekvence. Pomoću njih se ističe strukturna organizacija objekata koji učestvuju u interakciji. Za razliku od dijagrama sekvence, dijagrami saradnje ne sadrže liniju života objekta niti fokus upravljanja, već sadrže objekte iz interakcije sa vezama koje sadrže poruke između njih.

Objekti se prikazuju kao čvorovi grafa, a poruke između ovih objekata peikazuju se kao grane grafa. Poruke mogu imati svoje redne brojeve (sa prefiksom), a koji označavaju redosled razmene poruka. Ovaj redosled formira putanju poruka, koja se takođe označava i usmerenim strelicama na granama grafa.

Pretplatnik Transakcija1. Upisi klijenta (a, b, c)

2. Uradjeno

3. Prekini

Dijagrami pregleda interakcija

Dijagrami pregleda interakcija su jedna od novina verzije 2.0. Predstavljaju kombinaciju dijagrama aktivnosti i dijagrama sekvenci. Mogu se posmatrati kao dijagrami aktivnosti u kojima su aktivnosti zamenjene sa dijagramima sekvenci.

Vremenski dijagrami

Vremenski dijagrami su takođe novina u verziji 2.0. Iako se odavno koriste pri rešavanju elektro-tehničkih problema, tek su u verziji 2.0 uvršteni u UML. Ova vrsta dijagrama je slična dijagramima stanja mašine, sa tom razlikom što se vreme pojavljuje kao inicijator promene stanja objekta. Pored mogućnosti praćenja promena stanja jednog objekata moguće je pratiti i upoređivati promenu stanja više objekata. Dakle, ovi dijagrami prikazuju stanja u koja objekti dolaze nakon unapred predefinisanog vremenskog intervala.

Dijagrami klasa

Dijagrami klasa predstavljaju ključne dijagrame za opisivanje strukture sistema. Klasa predstavlja osnovni pojam u objektnom razvoju, te kao takva predstavlja i osnovnu komponentu objektno razvijanog sistema. Ovi dijagrami opisuju klase sistema i to kroz opis njima pripadajućih atributa, operacija i relacija između klasa.

Atributi predstavljaju obeležja koja opisuju svojstva klase. Navode se u okviru klase, a svaki atribut može da poseduje sledeća svojstva: vidljivost, ime, tip, multiplicitet, podrazumevanu vrednost, kao i opis nekih dodatnih svojstava atributa (npr. čitljivost). Operacije opisuju poslove koje će objekat, kao konkretna pojava klase, znati da obavi. Kada se od objekta zahteva da obavi neki posao, to se može zahtevati samo preko operacije koju on poseduje. I operacije, kao i atributi poseduju odgovarajuća svojstva, i to: vidljivost, ime, listu parametara, tip rezultata operacije, itd. Relacije služe da bi se prikazao međusobni

odnos klasa. Između klasa mogu da postoje sledeće vrste relacija: asocijacija, agregacija, zavisnost i generalizacija.

Dijagrami objekata

Dijagrami objekata su postojali i u ranijim verzijama UML-a, ali kao neformalni dijagrami. Od verzije 2.0 zvanično postaju UML dijagrami. Služe da prikažu objekte posmatranog dela sistema u posmatranom trenutku. Najsličniji su dijagramima saradnje, ali bez tretiranja poruka koje objekti razmenjuju. Koriste se da bi se dodatno opisala struktura sistema, u situacijama kada dijagrami klasa ne daju dovoljno kvalitetan opis iste.

Dijagrami komponenti

Dijagrami komponenti služe da bi se prikazale komponente sistema. Pod komponentama se podrazumevaju takvi delovi sistema koji se mogu samostalno isporučivati krajnjim korisnicima. Naravno da sve ove komponente moraju biti tako međusobno usaglašene da dodavanje nove komponente u sistem ne izazove poremećaje kompletnog sistema. Uobičajeno svaka komponenta se sastoji od jedne ili više klasa i predstavlja nezavisnu celinu, koja je povezana sa ostatkom sistema pomoću interfejsa. Na ovakav način se postiže da promene u jednoj komponenti ne deluju destruktivno na ostatak sistema, jer interfejs i dalje čuva integritet komponente i ostatka sistema. To su, u stvari, dijagrami klasa kod kojih je pažnja usmerena na komponente sistema. Na taj način se prikazuje konstrukcija izvršnih softverskih sistema.

index.html find.html

find.exe

dbasic.dll nateng.dll

Dijagrami paketa

Paketi predstavlju mehanizme za grupisanje UML elemenata. Iako se najčešće koriste za grupisanje klasa, mogu se koristiti i za grupisanje drugih elemenata, npr. za grupisanje slučajeva upotrebe, za grupisanje entiteta ili za grupisanje komponenti sistema. Predstavljaju se pomoću pravougaonika sa jezičkom u levom gornjem uglu, na kojem je ispisan naziv paketa. Između paketa se povlače relacije zavisnosti, koje govore da se neki od elemenata smeštenih u pakete između kojih postoji zavisnost nalaze u međusobnom odnosu.

Ukoliko govorimo o paketima klasa, tada bi do njihovog kreiranja moglo doći, npr. radi grupisanja hijerarhijske strukture klasa ili grupisanja klasa čije su instance u međusobnoj zavisnosti predstavljenoj na dijagramima sekvenci ili dijagramima saradnje. Moguće je takođe praviti pakete na osnovu stereotipova klasa. Dakle, ukoliko se klase nalaze u logičkoj ili fizičkoj povezanosti moguće ih je smestiti u paket klasa i predstaviti više takvih paketa na dijagramu paketa. Ovi su dijagrami, iako ranije nezvanično korišćeni, novina u UML verziji 2.0.

Dijagrami složene strukture

Dijagrami složene strukture prikazuju saradnju klasa, interfejsa ili komponenti u cilju opisa strukture zadužene za izvršavanje posmatrane funkcionalnosti. Ovi dijagrami su slični dijagramima klasa. Razlika je u tome što dijagrami klasa prikazuju statičku strukturu sistema, kroz prikaz klasa sa njihovim atributima i operacijama, a dijagrami složene strukture prikazuju izvršnu arhitekturu, relacije između njenih gradivnih elemenata i odnos posmatrane arhitekture sa okruženjem, u cilju prikazivanja informacija koji se ne mogu prikazati pomoću statičkih dijagrama. Dijagrami složene strukture su takođe novina u verziji UML-a 2.0.

Dijagrami raspoređivanja

Dijagrami raspoređivanja služe za predstavljanje hardverske arhitekture sistema. Oni prikazuju delove sistema raspoređene po fizičkim lokacijama. Ovi dijagrami se mogu posmatrati i kao prikaz arhitekturalnog rešenja celokupnog sistema. Pomoću njih se prikazuje konfiguracija procesnih čvorova u toku izvršavanja i komponenti koje se nalaze u njima. Predstavljaju posebnu vrstu dijagrama klasa namenjenih statičkom prikazu raspoređenosti hardvera sistema. Sastoje se iz čvorova, koji se prikazuju u obliku kvadra, kao i relacija između ovih čvorova.

Opisani UML dijagrami mogu se koristiti u različitim fazama razvoja softvera. U fazi analize najčešće se koriste: dijagrami slučajeva upotrebe, dijagrami aktivnosti i dijagrami stanja mašine, dok se u fazi projektovanja uobičajeno koriste: dijagrami klasa, dijagrami sekvenci i saradnje, dijagrami paketa, dijagrami raspoređivanja.

Internetserver za

keširanje

server za

keširanje

primarni

serverserver server server

lokalna mreza