4. METODOLOGIJE RAZVOJA INFORMACIONIH SISTEMA

4.1 Strukturalne metodologije Razvoj informacionog sistema prema principima ivotnog ciklusa podrazumeva takav proces koji tee kroz niz sukcesivno procesnih faza, gde zavretkom jedne faze zapoinje naredna i gde izmeu susednih faza postoji snana iterativna interakcija. Ovo je proces kojim sistem analitiari, softver inenjeri i programeri izgrauju informacioni sistem. To je, takoe, paradigma i sredstvo upravljanja ovako sloenim, dugotrajnim i skupim projektima. Prilazi i metodologije razvoja informacionih sistema se esto meaju sa ivotnim ciklusom. Neretko se postavlja pitanje: ima li razlike? Neki eksperti tvrde da su prilazi i metodologije razvoja informacionih sistema substitut za ivotni ciklus. Drugi misle da su prilazi i razvojne metodologije, vie-manje, namenjeni da upotpune, metodoloki razjasne i omogue da razvoj informacionog sistema bude efikasniji. Autori ove knjige nalaze pribeite ovom drugom stanovitu i smatraju, kao i mnogi drugi, da principi i filozofija ivotnog ciklusa informacionog sistema nije iezla, da su jo uvek veoma aktuelni, jer informacioni sistemi nastaju, razvijaju se, sazrevaju, ali i nestaju. Oni se, dakle, u okviru ovakvog stanovita mogu razvijati razliitim prilazima i metodologijama. Prilazi i metodologije, o kojima e u ovom delu knjige biti rei, su strukturni, objektni i agilni. Jedna od najvanijih metodologija razvoja informacionog sistema je strukturna metodologija ivotnog ciklusa, koja je usredsreena na strukturni prilaz. Osnova ove metodologije je strukturna sistem analiza, dizajn, implementacija i strukturne metode, tehnike, CASE alati. Najpoznatije u literaturi i u praksi najee koriene strukturne metodologije su:

a) SADT (Structured Analysis and Design Techniques) Whitten, J., Bentley, L.D. (1998), b) SSADM (Structured Analysis and Design Method) Whitten, J., Bentley, L.D. (1998), c) ISAC (Information System Work and Analysis of Change) Lundberg, F, et al. (1981), d) SSA (Structured Systems Analysis), Gane, C, Sarson, T. (1979), e) IE (Information Engineering) Martin, J.(1990), f) RAD (Rapid Application Development) Gane, C. (1990).

U ovoj glavi e biti rei o poslednjoj RAD ili Metodologiji brzog razvoja informacionog sistema. Ova metodologija ima sledee korake:

1. Uspostavljanje upravljake strukture projekta; 2. Identifikovanje, analiza i specifikacija informatikih zahteva i odgovora na informacione

zahteve; 3. Logika analiza i modelovanje sistema; 4. Logiko modelovanje podataka; 5. Projektovanje relacionih baza podataka; 6. Transformacija logikog u fiziki model; 7. Specifikacija logikih procedura obrade podataka; 8. Implementacija sistema.

Uspostavljanje upravljake strukture projekta je nuno zbog problema sa multiorganizacionim sistemima. Projekti razvoja novog ili modifikacije postojeeg sistema skoro uvek izazivaju radikalne promene u vie organizacionih jedinica i mogu biti uzrok mnogih konflikata i otpora. Veina ljudi u organizaciji ne voli promene, ak i ako su one veoma korisne za organizaciju kao celinu, odeljenja, radne grupe i pojedince. Izvori konflikata i otpori mogu biti

razliiti. Najee se, meutim, tiu problema opravdanosti ulaganja i preduzimanja ogromnih napora da se novi sistem razvije, jer menaderi su skloni tvrdnji da takva ulaganja i napor nisu srazmerni korisnosti koju sistem donosi, jedni se boje da e novi sistem smanjiti njihovu mo, a drugi da e njihov posao postati tei, dosadniji, pa ak da e i nestati. Za savlaivanje otpora i prevazilaenje konflikata zahteva se znaajno vreme, pa je to esto i razlog zato razvoj informacionog sistema dugo traje. Ljudi koji ine tim za razvoj informacionog sistema, strunjaci za informatike tehnologije, imaju pred sobom dve ozbiljne prepreke u efikasnom suzbijanju otpora i reavanju konflikata. Prva je ta, to oni ne poznaju dovoljno oblasti u kojima se otpori i konflikti pojavljuju, imaju pomanjkanje kompetencija. Druga, nemaju adekvatna ovlaenja i autoritet u odnosu na ove ljude. Iz ovih razloga je neophodno na vreme spoznati da klju uspeha brzog i efikasnog razvoja informacionog sistema lei u nainu upravljanja celokupnim projektom. Osoba koja e stati na elo projekta mora biti iz samog vrha menadmenta organizacije, koja ima odgovornost za uspeh projekta i autoritet nad delokrugom projekta, politikama koje e podravati razvoj projekta i omoguiti organizacione promene koji e razvoj i implementacija projekta implicirati. Menader koji dobija ovakvu ulogu poznat je kao "izvrni sponzor", i ova osoba uspostavlja odgovarajuu upravljaku strukturu projekta. Identifikovanje, analiza i specifikacija informacionih zahteva i odgovora na informacione zahteve - Analiza i definisanje informacionih zahteva je drugi deo jedinstvene metodologije brzog razvoja informacionog sistema. Metod koji se koristi u identifikaciji zahteva je metod intervjua. Za razliku od tradicionalnog pristupa, koji je akceptirao seriju nezavisnih, pojedinanih intervjua, ovde je re o primeni tehnike grupnih intervjua, gde jedan ili vie analitiara intervjuie "komitet" za upravljanje projektom i reprezente korisnika, u isto vreme. Sprovoenje niza i velikog broja pojedinanih intervjua, od strane veeg broja analitiara, prouzrokuje vie tekoa, meu kojima su najznaajnije: a) proces intervjuisanja dugo traje, izostaje komunikacija izmeu intervjuisanih i trokovi su

veliki; b) stavovi intervjuisanih u vezi sa istim problemima mogu biti razliiti i veoma je teko pomiriti

izraene razlike; c) izmeu razliitih organizacionih jedinica esto se javljaju razliiti ciljevi i zahtevi koji su

kolitini, uvek za posledicu imaju konflikte i otpore koje je veoma teko reiti odnosno ukloniti.

Ove vrste problema metod grupnog intervjua veoma efikasno reava. Grupni intervjui imaju teorijsko uporite u teoriji grupne dinamike. Sutina pristupa grupne dinamike se moe iskazati u sledee etiri paradigme: Sastanak je najproduktivniji ako je voen od moderatora, koji je "prirodni posluitelj" grupe,

koji vrednuje i distribuira ideje. Njegova je odgovornost da pomogne grupi da njihovu energiju usredsredi na zadatak sa predlaganjem metoda i procedura, zatitom lanova grupe od ataka i stvaranjem anse svakom da u radu uestvuje.

Najproduktivnije grupno odluivanje je konsenzus, u kojem se svako osea "pobednikom", ili ako nije dobio tano ono to je eleo, prihvata odluku bez kompromisa ili nekog "debelog" ubeivanja.

Grupna sesija je najproduktivnija ako se pridrava plana, koji je grupa prihvatila konsenzusom;

Grupna sesija je najproduktivnija ako se rezultati diskusije prikazuju na zidu, onako kako se oni pojavljuju, gde ih svako moe videti. Displej se esto oznaava kao "grupna memorija", a

lan grupe koji kreira displej igra ulogu "zapisivaa".

Grupni intervju podrazumeva zajedniki sastanak reprezentanta korisnika i projektantskog tima u istoj sobi i u isto vreme; koji kontinuirano dre radnu sesiju (workshoop) koja traje najmanje jedan, obino tri, a ponekad i pet dana. Uspeh ove tehnike identifikacije informacionih zahteva znaajno je zavisan od naina voenja sesije grupnog intervjua, koja treba da bude voena, prema indikacijama uspenosti iz dosadanje prakse, osobom koja nije optereena parcijalnim interesima konanih izlaza projekta, neko ko ima iskljuiv cilj da to pre i na to efikasniji nain doe do konsenzusa o koherentnom zajednikom skupu zahteva. Glavna korist upotrebe ovog metoda je veoma kratko vreme izvrenja faza identifikacije zahteva. Ako se konflikti pojave oni mogu biti otvoreno i neposredno raspravljani i razreeni veoma brzo. Posebno znaajna korist se ispoljava u mogunosti da korisnici participiraju u donoenju odluke o delokrugu i prirodi sistema koji se razvija za njih, i koji imaju oseaj izraen sledeom tvrdnjom: "Ovo je na sistem, a informatiko osoblje nam pomae da ga izgradimo" Gane, C. (1990). Svaki projekat razvoja informacionog sistema, tokom intervjua ukljuuje nekoliko grupa radnih sesija. To su po Gane, C. (1990): strategijska sesija sa zadatkom determinisanja delokruga projekta, ciljeva, resursa; podaci/procesi sesija sa zadatkom izgradnje ili proiavanja dijagrama toka podataka i modela podataka i definisanja logike poslovne politike; ekrani/izvetaji sesija sa zadatkom da se definie interaktivni dialog i izgledi izvetaja. Uesnici intervjua su predstavnici korisnika. Logika analiza i modelovanje sistema Ovim korakom metodologije se modeluju procesi sistema. Osnovni ciljevi koji se postiu putem upotrebe tehnike dijagrama toka podataka su:

definisanje granice sistema i poslovnog domena koji isti pokriva; veoma jednostavna i za korisnika krajnje prihvatljiva prezentacija sistema, potpuno

razumljiva za poslovni svet koji nije familijaran sa informacionim tehnologijama; prikaz memorisanih podataka (datoteka, evidencija, kartoteka, arhiva) u sistemu i procesa

koji te podatke transformiu, kao i njihov meusobni odnos (relacije). Logiko modelovanje sistema u najuem smislu podrazumeva izradu DTP za odreeno domensko podruje i takozvani First-Cut ("prvi presek") modela podataka. Bilo bi metodoloki konzistentnije u pojam logike analize i modelovanja sistema ukljuiti i entitet-odnos analizu (E-O-M) podataka i specifikaciju logikih jedinica procedura obrade. Prema tome, logiku analizu i modelovanje sistema moemo shvatiti kao proces od dva koraka. Prvi korak u logikom modelovanju je razvoj sistemskog dijagrama toka podataka (SDTP), koji opisuje prirodu svega onoga to se deava u nekom domenskom podruju. DTP je jednostavna tehnika (koristi samo etiri simbola), ali veoma dragocena za izradu slike celovitog logikog modela i prirode informacionog sistema, podsistema, aplikacija. etiri simbola od kojih se formira slika logikog modela integralnog informacionog sistema su: kvadrat (za spoljne entitete), otvoreni pravouganonik (spremita podataka), zaobljeni pravougaonik (proces) i strelica (tok podataka) (Slika 12-26).

Slika 12-26

1

Prodaja

4

Determinisanjekoliina i

dobavljaa zaponovne narudbe

2

Pripremabankarskihdepozita

3

Izrada izvetajao prodaji

5

Analizaisporuka

D1 Proizvodi

D2 Zalihe

D4 Dobavljai

D3 Prodaja D5 Isporuke

c

Kupci

s

Dobavljai

b

Banke

m

Uprava

Porudbine

Proda

te jedinice

Stanje zaliha

Cena, kvalitet, vremeisporuke

Narudbe

Prole

ispo

ruke

Prihvaen

ekoliine

Inform

acije o ispo

ruci

Povean

je zaliha

Pod

aci o proda

jiSume

Ned

avna

prod

aja

Dokumenti odepozitu

Podaci oprodaji

Drugi korak u logikom modelovanju je derivacija "prvog preseka" modela podataka, specifikacija liste elementarnih podataka koji e biti memorisani u svakom spremitu podataka prikazanom na DTP (u naem primeru: PROIZVODI, ZALIHE, DOBAVLJAI, PRODAJA, PORUDBINE). Izbor i pridruivanje podataka pojedinanim entitetima se zasniva na sopstvenom znanju ili znanju korisnika o tome koji su podaci znaajni i treba da budu memorisani da bi opisivali entitete kao to su PROIZVOD, DOBAVLJA, KUPCI itd. Izbor podataka moe biti potpomognut analizom sadraja ulaznih dokumenata i analizom sadraja izlaznih dokumenata. Dijagram na slici 12-27 prikazuje rezultate "prvog preseka" modela podataka.

Slika 12-27

1

Prodaja

4

Determinisanjekoliina i

dobavljaa zaponovne narudbe

2

Pripremabankarskihdepozita

3

Izrada izvetajao prodaji

5

Analizaisporuka

D1 Proizvodi

D2 Zalihe

D4 Dobavljai

D3 Prodaja D5 Isporuke

c

Kupci

s

Dobavljai

b

Banke

m

Uprava

Porudbine

Prodate jedinice

Stanje zaliha

Cena, kvalitet, vremeisporuke

Narudbe

Prole

isporuke

Prih

vaene

koliine

Inform

acije o isporuci

Poveanje zaliha

Podaci o prodaji

Sume

Nedavna

prodaja

Dokumenti odepozitu

Podaci oprodaji

Isporuke

Datum_Por Narueni proizvod Naruena koliina Dobavlja Ugovoreni datum Isporuena koliina Datum isporuke

Zalihe

ifra Cena Koliina na zalihi Koliina u narudbi

Proizvod

Identifikacija dobavljaa Kontakt Adresa Proizvod(*) Cena Vreme isporuke

Proizvod

ifra Naziv Cena

Prodaja

Prodavac Datum Proizvod Kod Koliina Vrednost

Logiko modelovanje podataka Tokom realizacije ovog koraka metodologije, sprovodi se entitet-odnos analiza podataka. Koristei E-R-M (Entity-Relationship Model) moe se veoma brzo dobiti opti pogled na klastere podataka koji su ukljueni u sistem. Logiko modelovanje podataka je prirodni nastavak logikog modelovanja sistema i oslanja se na sainjene dijagrame tokova podataka. Entitet-odnos analiza podataka zapoinje sledeim pitanjem: "Koji su entiteti podataka relevantni za memorisanje u sistemu?". Odgovor na ovo pitanje moe, na primer, biti: KUPAC, PROIZVOD, PRODAJA, DOBAVLJA, NARUDZBA, ZALIHA. Identifikacija entiteta se znaajno olakava ako se paljivo analiziraju prethodno pominjani dijagrami, na kojima se ve nalaze ucrtani razliiti tipovi entiteta. Treba, meutim, naglasiti da je esta pojava da se entitet-odnos analizom identifikuju neki novi entiteti koji u DTP nisu prikazani, ili da se neki entiteti prikazani DTP u entitet-odnos analizi izostavljaju. Identifikovani entiteti se predstavljaju simbolom pravougaonika. Oni se zatim simbolom usmeravajue strelice povezuju i tako formira model podataka. Veze koje egzistiraju izmeu identifikovanih entiteta mogu biti sledeih tipova: 1:1, 1:M i N:M. One prikazuju koliko slogova

jednog tipa entiteta stoji u odnosu sa slogovima drugog tipa entiteta. Definisanjem odgovora na postavljena pitanja, i primenom simbola i konvencionalnih pravila za izradu dijagrama, dobija se model podataka na slici 12-28.

Slika 12-28

Kupac

Prodaja

Proizvod

Zaliha

Dobavlja

Narudba

Projektovanje relacionih baza podataka - Relaciona analiza podataka se preduzima sa ciljem da se projektuje logika struktura baze obeleja relacionog modela baze podataka, odnosno da se dobije struktura n meusobno povezanih dvodimenzionalnih tabela koje e sainjavati jednu bazu podataka. Metod kojim se takva struktura dobija je poznat pod nazivom metod normalizacije. Svaka od dvodimenzionalnih tabela, dobijena procedurom "prvog-preseka" modela podataka, mora biti podvrgnuta postupku normalizacije. Za neku tabelu se moe rei da je normalizovana, da se nalazi u treoj normalnoj formi, ako su sve nekljune kolone u potpunoj zavisnosti od kljua i ako ne postoje takozvane tranzitivne zavisnosti. Relaciona analiza podataka se izvodi u sledeim koracima: Egzaktno definisanje sadraja svakog podatka koji e biti memorisan; Utvrivanje opisa i naziva elementarnih podataka; Odreivanje indetifikatora entiteta, tabela; Pojednostavljenje tabela kroz proces normalizacije; Redizajniranje dijagrama toka podataka.

Polazei od rezultata prvog-preseka modela podataka i rezultata entitet-odnos analize, a primenjujui metod normalizacije, za primer koji smo uzeli za ilustraciju, dobijena je serija normalizovanih tabela (Slika 12-29).

Slika 12-29 PROIZVODI DOBAVLJAI PRODAJA ISPORUKA SIF-PR(*) SIF-DOB(*) SIF-PRO(*) SIF-NAR(*) NAZIV UGOVOR DAT-PRO DAT-ISP(*) CENA ADRESA PRODAVAC ISP-KOL KOL-NA-ZAL NAR-KOLA

IZVORI PROIZVODA ELEMENTI-PRODAJE NARUDZBA SIF-DOB(*) SIF-PRO(*) SIF-NAR(*) SIF-PRO(*) SIF-PR(*) DAT-NAR NAB-CEN PRO-KOL SIF-PR PRO-TRO SIF-DOB NAR-KOL OB-DAT-ISP

Sada DTP moe biti reprojektovan, poto su nastale odreene izmene u podacima koje treba zajedniki memorisati, i tako e se dobiti realniji i precizniji pogled na sistem (Slika 12-30). Nastale su odreene izmene: D2-zalihe, su nestale i integrisale se sa D1; dva spremita podataka D3 i D4 su promenila ime, parovi zasebnih tabela su formirani i ine jedno spremite, pristupa im se zajedno poto opisuju iste entitete; spremite D5 je razbijeno na dva, jer su zasebne logike celine i imaju odvojene procedure auriranja.

Slika 12-30

1

Prodaja

4

Determinisanjekoliina i

dobavljaa zaponovne narudbe

2

Pripremabankarskihdepozita

3

Izrada izvetajao prodaji

5

Analizaisporuke

D1 Proizvodi D2DobavljaiIzvori proizvoda

D3ProdajaProdate koliine

D5 Porudbine

c

Kupci

s

Dobavljai

b

Banke

m

Uprava

Povean

je zaliha

Pod

aci o proda

ji

Sume

Ned

avna

prod

aja

Dokumenti odepozitu

Podaci oprodaji

Isporuke

K Broj-porK Dat-isp Ispor-kol

Proizvodi

ifraNazivCenaKoliina na zalihiKoliina u narudbi

Dobavljai

K Identifikacija dobavljaa Kontakt Adresa

Prodaja

K Broj-prod Dat-prod Prodavac

Podaci oproizvodima

Prodatejedinice

D6 Isporuke

Prihvaenekoliine

Prole ispo

ruke

Stanje zaliha

Izvori proizvoda

K Identifikacija dobavljaaK ifra proizvoda Cena Vreme isporuke

Porudbine

K Broj-por Dat-opr ifra-proizvoda Identifikacija-dobavljaa Poruena-kol Obe-dat-isp

Prodate-koliine

K Broj-prodK ifra-proizvoda Prod-kol Vrednost

Konani logiki model

sistema

Operacije sa relacijama se tiu standardnih procedura za definisanje tabela, sortiranje podataka u njima i pretraivanje podataka na razliite naine. Vana osobina relacionih baza podataka je raspolaganje sa DBMS koji ima "aktivni" renik podataka: skup drugih tabela (meta baza podataka) koje dre podatke o podacima: naziv, opis, moguu vrednost, lokaciju svake kolone u

tabeli i slino. Standardni jezik koji je razvijen za ove svrhe je SQL (Structured Query Language), koji e koristiti renik podataka da bi determinisao gde se podaci, kojima treba pristupiti, nalaze u bazi podataka. Budui da se za svaku definisanu tabelu dre podaci u reniku podataka, mogue je menjati strukturu tabele ili dodavati nove tabele, a da se ne zahteva nikakva promena programa koji koriste date tabele. SQL omoguava izvoenje niza operacija, kao to su: kreiranje tabela, selekcija pojedinih kolona (projekcija), selekcija pojedinih redova (selekcija), sortiranje redova po redosledu, promena sortiranih vrednosti, dodavanje kolona u tabele, sub-upiti, spajanje tabela, kreacija virtualnih tabela (views) i indeksiranje. Transformacija logikog u fiziki model Ovaj korak metodologije predstavlja prirodni nastavak prethodnih faza razvoja informacionog sistema. Naime, u prethodnim aktivnostima razmatran je nain i tehnike definisanja i specifikacije logikog modela informacionog sistema. Logiki model sainjavaju sistemski dijagram toka, E-R-M i grupe normalizovanih tabela koje opisuju strukturu i sadraj baze podataka. Tokom ovog koraka se logiki definisani procesi prikazani na redizajniranom DTP prevode u fizike procedure. Dva su u sutini problema: Pre-implementacioni kompromis modela podataka; Razlaganje sistemskog DTP na proceduralne jedinice; na jedinice zasebnih logikih

procedura. Pre-implementaciono "sreivanje" modela podataka se odnosi na njegovo prilagoavanje zahtevima kao to su prihvatljivo vreme pristupa i pretraivanja, prihvatljiv memorijski prostor neophodan za smetaj baze podataka. Spajanje relacija moe biti uputno i korisno realizovano u cilju da se utedi vreme i unapredi integralnost celine. Dizajner baze podataka e, pre nego to nacrta E-R-M, obaviti konsultacije po ovim pitanjima i zajedno sa administratorom baze podataka izvriti konsolidaciju modela. Termin "jedinice zasebnih logikih procedura", u ovom udbeniku, podrazumeva "komadie" automatizovanih i/ili manuelnih procedura koje mogu biti izvravane zasebno. Jedinice zasebnih logikih procedura mogu biti: programi, manuelne procedure i memorisana lista komandi, ili kombinacija ove tri. One su ustvari deo logikog modela. Definisanje jedinica zasebnih logikih procedura polazi od paljivog analiziranja svakog inputa i outputa na DTP. Za svaku pojedinanu analizu inputa odnosno outputa postavljaju se sledea pitanja: Kada se deava? Koliko podruje DTP je zahvaeno?, i Moe li to podruje biti implementirano kao posebna jedinica, ako ne, zato?

Specifikacija logikih procedura obrade podataka U ovom koraku metodologije detaljno se specificiraju detalji definisanih jedinica logikih procedura. Specifikacija obavezno sadri sledee elemente Gane, C. (1990): Iseak iz sistemskog DTP, koji pokazuje gde se ova proceduralna jedinica nalazi u ostatku

sistema; Detalje o tabelama (relacijama) kojima se pristupa ovom jedinicom procedure; Izgled ekrana ili izvetaja koji su ukljueni u jedinicu procedure; Napomene o logici i sadraju procedure koja treba da bude implementirana, pisane u

strukturnom engleskom ili nekoj drugoj nedvosmislenoj formi. Poto su sve specifikacije jedinica procedure uraene, programeri mogu veoma brzo izgraditi prototip ili izvesti direktnu celovitu implementaciju u nekom programskom jeziku, odnosno alatu. Implementacija sistema - Implementacija sistema i razvoj softverskog dela sistema, je poslednji korak RAD metodologije. Neproceduralnim alatima i softverom za upravljanje bazama podataka kao to su ORACLE, INFORMIX, DB-2, PROGRES, FOCUS, aplikacije se razvijaju veoma brzo, zahvaljujui, pre svega, tome to oni obezbeuju lako ili brzo definisanje ekrana i editovanje podataka koji se unose putem ekrana, raunanje i manipulaciju nizovima, pretraivanje i auriranje baza podataka (SQL standardi), generisanje planiranih izvetaja i ekranskih displeja, sistemsko generisanje aplikacija. Veina ovih jezika su "klasterizovani sub-jezici", jer obezbeuju subjezike za razliite funkcije, na primer: subjezik za definisanje ekrana, drugi za pretraivanje baza podataka itd. 4.2 Objektne metodologije Rational Unified Process (u nastavku RUP) predstavlja objektno orijentisani proces za izradu softvera. Ovaj proces je zasnovan na pristupu baziranom na disciplinama, u okviru kojih se vri raspodela poslova i odgovornosti na lanove razvojnog tima i ostale uesnike u procesu razvoja softvera. Osnovna namena RUP-a jeste proizvodnja visoko kvalitetnog softvera, kao krajnjeg rezultata projekta, koji zadovoljava potrebe korisnika, a u okviru planiranog budeta i vremena. RUP je framework (radni okvir) koji je mogue prilagoavati potrebama organizacije koja ga usvaja. On sadri skup dobro definisanih preporuka i uputstava za uspean razvoj softverskog proizvoda. Upravo radi toga se kod navoenja definicije RUP-a izbegava izraz metodologija, koji predstavlja znatno vri set pravila od navedenog izraza framework. Meutim pojedinanim podeavanjem RUP-a organizacija moe da kreira svoj metodoloki okvir, a u okviru njega i vrsta pravila izgraena na osnovu datih preporuka i uputstava. Najpoznatije u literaturi i u praksi najee koriene objektne metodologije su:

a) OOAD (Object Oriented Analysis and Design) Martin, J., Odell, J.J. (1992), b) OOADA (Object Oriented Analysis and Design) Booch, G. (1994), c) OMT (Object Modeling Technique) Rumbaugh, J. (1991) d) OOA/OOD (Object Oriented Analysis/Object Oriented Design) Yourdon, E. (1995) e) RUP (Rational Unified Process) Jacobson, I. et.al (1999)

U izgradnji informacionog sistema, RUP preporuuje korienje raznih metoda i tehnika, ali su svakako najdominantnije tehnike modelovanja korienjem Unified Modeling Language-a (u nastavku UML) tj. jedinstvenog jezika za modelovanje. Za RUP se ak moe rei da predstavlja uputstvo za korienje UML-a. RUP je inicijalno zamiljen za razvoj velikih projekata, ali je svoju primenu naao i u srednjim i malim softverskim projektima. Softverski timovi, naroito veliki, znatno unapreuju svoju produktivnost korienjem RUP-a. RUP omoguuje svakom lanu razvojnog tima lak uvid u bazu znanja, zasnovanu na uputstvima, templejtima i uputstvima za korienje alata, to predstavlja podrku u svim kritinim razvojnim aktivnostima. To doprinosi da svi lanovi razvojnog tima, bez obzira na aktivnosti koje obavljaju, koriste zajedniku metodologiju, jezik i pogled na to kako treba razvijati softverski proizvod.

Principi na kojima je zasnovan RUP, omoguuju razvoj kvalitetnih softverskih proizvoda i postavljanje metodolokih koraka kojima e se realizovati kompletne preporuke i uputstva zasnovane na dole navedenim principima. Iterativan razvoj - Klasini proces razvoja softvera se zasniva na modelu vodopada, koji je ranije opisan. Alternativa modelu vodopada jeste iterativno-inkrementalni model razvoja softvera. Korienjem ovoga modela dolazi se do relativno brze realizacije poetne verzije softvera koja se razvija dodatnim iteracijama. Takoe, integrisanje i testiranje softvera se obavlja ee, te se na taj nain postie smanjenje rizika. to je razlika izmeu trenutka otkrivanja greke i trenutka nastanka greke vea, to je njeno otkrivanje i otklanjanje tee i skuplje. Kao to se vidi na slici 12-31., iterativni proces se sastoji iz vie sekvencijalnih procesa zasnovanih na modelu vodopada. Time je vremenska dimenzija izmetena u odnosu na sadrajnu dimenziju, pa je vreme izmeu potencijalnog nastanka i otkrivanja greaka znaajno skraeno.

Kao prednosti iterativnog razvoja mogu se navesti sledee:

Greke uinjene u razvoju se ranije identifikuju i na njih je mogue uspenije reagovati; Omoguava se korisniki feedback; Razvojni tim je primoran da se fokusira na ona pitanja koja su najvanija za projekat; Kontinuirano i iterativno testiranje prua objektivan uvid u status razvoja; Nepravilnosti uinjene tokom analize zahteva, dizajna i implementacije otkrivaju se ranije; Tim za testiranje, je ukljuen tokom celog ivotnog ciklusa projekta; Tim usavrava nauene lekcije i samim tim moe neprekidno da unapreuje proces razvoja; Slika 12-31

Upravljanje zahtevima - Pratei rezultate Standish grupe dolazi se do spoznaje, da je u 37% sluajeva razlog za neuspeh projekata vezan za informacione zahteve. Nedostatak korisnikih zahteva predstavlja razlog neuspeha projekata u 13% sluajeva, nepotpuni zahtevi i specifikacije u 12% sluajeva, a promena zahteva i specifikacija takoe u 12% sluajeva. Dodajui navedenim podacima injenicu, da su trokovi otklanjanja greaka nastalih u oblasti zahteva izuzetno visoki, iako ih iterativan pristup znaajno umanjuje, namee se zakljuak da se zahtevima ne posveuje dovoljna panja, u procesu razvoja informacionih sistema. Informacioni zahtevi predstavljaju inpute za dizajn sistema, testiranje sistema, kao i izradu korisnike dokumentacije. Greke u fazi analize zahteva su pogubne po uspeh projekta razvoja.

Da bi se gore navedeni procenti smanjili potrebno je posvetiti znaajnu panju pronalaenju, organizovanju, dokumentovanju i upravljanju zahtevima. RUP upravo to i radi kroz disciplinu zahteva iji je cilj da opie ta sistem treba da radi. Taj opis treba da bude prihvaen, kako od strane korisnika, tako i od strane razvojnih ininjera. Upotreba arhitekture zasnovane na komponentama - Vizuelizacija, specifikacija, konstrukcija i dokumentovanje softverskog sistema zahteva da sistem bude sagledan iz brojnih perspektiva. Svaki stejkholder (analitiari, integratori sistema, testeri, projektni menaderi, dizajneri, ...) donosi razliitu sliku projekta, i svaki od njih gleda sistem na razliite naine, mnogo puta tokom ivota projekta. Arhitektura sistema je moda najvanija podela, koja se moe koristiti da bi se upravljalo ovim razliitim gleditima i na taj nain kontrolisao iterativni i inkrementalni razvoj sistema, tokom njegovog ivotnog ciklusa. Arhitektura je prevashodno bitna za razvojni tim koji realizuje projekat, ali indirektno utie i na zadovoljstvo krajnjeg korisnika. Arhitektura sistema obuhvata grupu znaajnih odluka o: Organizaciji softverskog sistema Izboru gradivnih elemenata i njihovih interfejsa, od kojih je sistem sastavljen Ponaanju gradivnih elemenata, odreenom upravo njihovom saradnjom Kompoziciji strukturalnih i bihevioralnih elemenata u vee rastue podsisteme Arhitektonskom stilu, koji objedinjuje gore navedene odluke u jednu celinu. Razvoj baziran na komponentama (CBD - Component-Based Development) je znaajan pristup softverskoj arhitekturi jer omoguava ponovnu upotrebu, kao i specijalizaciju komponenti. Pored sopstvene izgradnje komponenti za ponovnu upotrebu mogua je upotreba komponenti i iz velikog broja komercijalno dostupnih izvora (Microsoft Component Object Model - COM i Microsoft Foundation Classes - MFC, Common Object Request Broker Architecture - CORBA, Enterprise JavaBeans - EJB samo su neke od iroko podranih platformi na kojima je arhitektura zasnovana na komponentama ostvariva). Kombinujui iterativan razvoj sa arhitekturom zasnovanom na komponentama svaki korak proizvodi izvrnu arhitekturu sistema, koja je merljiva, pogodna za testiranje i vrednovanje u odnosu na zahteve sistema. Na ovaj nain se otvara mogunost za konstantno napadanje kljunih rizika projekta. Vizuelno modelovanje - Model predstavlja pojednostavljenu sliku realnosti, koja kompletno opisuje sistem iz pojedinanih perspektiva. U softverskom ininjeringu modeli se izgrauju da bi se bolje razumeo sistem koji se modeluje. Kod izrade velikih sistema modelovanje pomae njihovom razumevanju u potpunosti. Slobodno se moe konstatovati da bi bez modelovanja automatizacija takvih sistema bila nemogua. injenica da jedna slika govori vie nego hiljadu rei je poznata odavno. Meutim, ono to je nedostajalo jeste standardizacija. UML kao jedinstveni jezik za modelovanje je prihvaen od strane vodeih svetskih IT kompanija i nametnut kao standard u softverskoj industriji. On slui za vizuelizaciju, specifikaciju, konstrukciju i dokumentaciju sistema koji se izgrauje. UML je omoguio svim lanovima razvojnog tima da razgovaraju istim jezikom. Standardizacija je dovela do toga da se UML izuava u kolama i fakultetima irom sveta, pa je time zamenjivost bilo kojeg lana razvojnog tima znaajno olakana. RUP i UML predstavljaju nerazdvojivu celinu. Vizuelno modelovanje podie kvalitet procesa razvoja softverskog proizvoda, to je lako uoljivo

preko sledeih karakteristika:

Use Case-ovi i scenarija nedvosmisleno definiu ponaanje sistema, Dizajn je jasan i nedvosmislen, Nemodularne i nefleksibilne arhitekture su lako uoljive na nivou modela, Razliite perspektive i razliiti nivoi detaljnosti se mogu koristiti u razliiti situacijama, Otklanjanje nekonzistentnosti na nivou dizajna, znaajno olakava implementaciju, Use Case model i dizajn model stvaraju jasne inpute za testiranje, Korienje UML-a namee standardizaciju u softverskoj industriji.

Kontinuirana potvrda kvaliteta softvera - Kao to slika 12-32 ilustruje, softverski problemi su 100 do 1000 puta skuplji kada se pronalaze i otklanjaju nakon uvoenja nego pre toga. Upravo zato, vano je kontinuirano proveravati kvalitet sistema sa posebnim akcentom na njegovu funkcionalnost, pouzdanost, aplikativne performanse i sistemske performanse. Proveravanje funkcionalnosti sistema ukljuuje kreiranje testova, za svaki kljuni scenario koji predstavlja neki aspekt eljenog ponaanja sistema. Prilikom proveravaja funkcionalnosti sistema potrebno je evidentirati svaki scenario koji nije zadovoljio zahteve i pristupati njegovom osposobljavanju. Potujui itearativan razvoj softvera tako je potrebno pristupati i testiranju, testirajui svaku iteraciju. Slika 12-32

Vreme

Novac

Provera kvaliteta softvera prua brojna reenja kljunim uzrocima problema razvoja softvera:

Procena statusa razvojnog projekta se izrauje objektivno, ne subjektivno, jer se vrednuju rezultati testa

Objektivno procenjivanje otkriva nekonzistentnosti u zahtevima, dizajnu i implementaciji Testiranje i verifikacija su usmereni na oblasti najvieg rizika, te se na taj nain uveavaju

kvalitet i efektivnost tih oblasti Greke se otkrivaju rano, radikalno sniavajui trokove njihovog ispravljanja

Kontrola promena softvera - Kljuni izazov prilikom razvoja softverskih sistema je usklaivanje rada razvojnih ininjera, organizovanih u razvojne timove koji zajedno rade na vie iteracija stvarajui softverski proizvod. Tokom razvoja novonastajui sistem se menja i razvija, a kontrola tih razvojnih promena je nuna za spreavaje haosa u procesu razvoja.

Usklaivanje aktivnosti, artifakta i uloga predstavlja ponovljivi workflow koji prati razvoj softvera kroz promene u procesu razvoja. Standardizacija workflow-a, sastavljenih od aktivnosti, artifakta i uloga, u procesu razvoja omoguuje praenje promena, rano otkrivanje problema i brzo reagovanje u cilju njihovog otklanjanja.

Slika 12-33

RUP razvoj informacionih sistema postavlja izmeu dve dimenzije, vremenske i sadrajne. Vremenska dimenzija je podeljena u etiri faze: uvoenje, elaboracija, konstrukcija i tranzicija. Sadrajna dimenzija je podeljena u est osnovnih i tri pomone discipline. U osnovne spadaju disciplina poslovnog modelovanja, disciplina zahteva, disciplina analize i dizajna, disciplina implementacije, disciplina testiranja i disciplina rasporeivanja. Pomone discipline su konfigurisanje i upravljanje promenama, upravljanje projektom i okruenje. Svaki element matrice RUP-a predstavlja kombinaciju elemenata statike strukture RUP-a i vremenskog rasporeda istih. Vidi sliku 12-33 Jacobson, I. et al. (!999). RUP je mogue posmatrati kroz dve dimenzije, kroz dinamiku u kojoj se proces opisuje kroz ivotni ciklus razvoja proizvoda i statiku u kojoj se opisuju aktivnosti i rezultati aktivnosti podeljeni na uloge. U nastavku je dat kratak opis dinamike strukture RUP-a predstavljene na slici 12-34.

Disciplines

Slika 12-34

Faza uvoenja Faza elaboracije Faza konstrukcije Faza tranzicije

Kljuna takafaze uvoenja

Kljuna takafaze elaboracije

Kljuna takafaze konstrukcije

Kljuna takafaze tranzicije

VREME

4.2.1 Dinamika struktura RUP-a RUP razvojni proces predstavlja kroz ciklus od etiri napred u tekstu navedene faze. Kao krajnji proizvod ovog ciklusa dobija se gotov softverski proizvod. Faze u procesu razvoja se ne izvravaju u jednom prolazu, ve se svaka od faza izvrava u nekoliko iteracija. RUP ne predvia taan broj iteracija. Do tanog broja iteracija po svakoj fazi se dolazi prilikom prilagoavanja RUP-a sopstvenim potrebama, tj. prilikom definisanja konkretnog procesa razvoja. Svaka od utvrenih iteracija donosi inkrement koji uveava vrednost softverskog proizvoda u izradi. Kraj svake od faza se smatra kljunom takom u procesu razvoja. Kljune take predviaju, na osnovu izvrene intergacije inkremenata realizovanih u posmatranij fazi, krajnje rezultate date faze. Faza uvoenja Faza uvoenja predstavlja prvu fazu u ivotnom ciklusu razvoja informacionog sistema. U ovoj fazi je potrebno definisati obim projekta i izvriti poslovnu procenu budueg sistema, u cilju donoenja odluke o nastavku procesa razvoja softverskog proizvoda. U kljunoj taci faze uvoenja potrebno je znati odgovore na sledea pitanja: Da li je rizik smanjen na prihvatljiv nivo? Da li je projekat izvodljiv? Da li je projekat finansijski isplativ? Da bi se dobili odgovori na ova pitanja, u ovoj fazi razvoja se realizuju sledee aktivnosti: Razumevanje ta se gradi. Iako preovladava miljenje da svi uesnici u razvojnom projektu

dobro znaju ta se gradi, najee se njihovi pogledi ne podudaraju. Zato je potrebno definisati ta se gradi, na takav nain da svi stejkholderi sistema imaju jednoznanu predstavu o tome. U tom cilju izrauje se dokument vizije sistema, mile-wide, inch-deep (irok i ne mnogo detaljan) opis sistema i detaljan opis kljunih aktera i Use Case-ova sistema. Paralelno sa opisom Use Case-ova potrebno je izraditi prototip korisnikog interfejsa.

Identifikovanje kljunih funkcionalnosti sistema. U toku ove aktivnosti utvruju se najznaajniji Use Case-ovi sistema. Ovu aktivnost obavljaju menader projekta i arhitekta ukljuujui i ostale stejkholdere po potrebi. Najee se za sistem od 20-tak Use Case-ova identifikuje 4-5 kljunih, ijim opisom se ustvari opisuju kljune funkcionalnosti koje budui sistem treba da prua.

Definisanje najmanje jedne mogue arhitekture sistema. Ovom aktivnou se utvruje da li postoji odgovarajua arhitektura sistema kojom se mogu zadovoljiti traene funkcionalnosti. Ukoliko se uoi vie arhitekturalnih solucija potrebno ih je sve predstaviti, a u kasnijim fazama e se doneti odluka izbora optimalne arhitekture.

Identifikovanje trokova, utvrivanje rasporeda izvrenja projekta i prepoznavanje rizika. Ovo je kljuna aktivnost poslovne procene budueg sistema. Na osnovu nje se obezbeuje odgovor na pitanje da li je projekat finansijski isplativ.

Razrada procesa razvoja i odreivanje alata koji e se koristiti. Neophodno je da svi lanovi razvojnog tima dele isti pogled na to kako e se softverski proizvod razvijati. U tom cilju se vri razrada procesa razvoja i odreuju se alati pomou kojih e se razvijati softverski proizvod.

Faza elaboracije Faza elaboracije predstavlja drugu fazu u ivotnom ciklusu razvoja informacionog sistema. Osnovni zadatak ove faze jeste uspostavljanje takve arhitekture sistema koja obezbeuje vrste osnove za veinu aktivnosti dizajna i implementacije koje e biti obavljene u fazi konstrukcije. Takoe zadatak ove faze je i identifikovanje kljunih rizika. Identifikuju se rizici vezani za zahteve, rizici vezani za arhitekturu, rizici vezani za trokove i na kraju rizici vezani za sam postupak izvrenja procesa razvoja i za primenu izabranih alata. Aktivnosti koje se obavljaju u fazi elaboracije su sledee: Detaljna razrada korisnikih zahteva. Kao rezultati faze uvoenja u fazi elaboracije su

dostupni kompletan dokument vizije, detaljan opis oko 20 procenata Use Case-ova (najbitniji Use Case-ovi) i kratak opis preostalih Use Case-ova. Do kraja faze elaboracije potrebno je zavriti kompletan opis Use Case-ova i izraditi prototip korisnikog interfejsa. U tom cilju se vri razrada Use Case-ova i izrada potpunog prototipa korisnikog interfejsa, a zatim se svaki od razraenih Use Case-ova detaljno kontrolie od strane korisnika i dorauje ukoliko je potrebno. Svaki od Use Case-ova se moe dodatno razraivati i u fazi konstrukcije ukoliko se za tim ukae potreba.

Dizajniranje, implementacija i ocenjivanje arhitekture sistema. Ova aktivnost ima zadatak da dizajnira, implementira i testira osnovnu strukturu budueg sistema. Tokom ove aktivnosti moraju se doneti neke od kljunih dizajnerskih odluka vezanih za arhitekturu sistema. Kao prvo mora se doneti odluka da li e se glavni gradivni blokovi kupovati, graditi ili e se izvriti ponovna upotreba ranije koritenih gradivnih blokova sistema. Zatim se mora opisati nain primene ovih gradivnih blokova na primeru najvanijih scenarija. Na kraju je potrebno izvriti implementaciju i testiranje izabrane arhitekture u cilju otklanjanja kljunih tehnikih rizika i utvrivanja kvaliteta gradivnih blokova.

Ublaavanje kljunih rizika, izrada detaljnog rasporeda projekta i izrada detaljnog prorauna trokova. Tokom faze elaboracije vri se ublaavanje veine kljunih rizika projekta. Detaljnom razradom korisnikih zahteva znaajno se ublaavaju rizici vezani za razumevanje funkcionalnosti budueg sistema. Implementacijom osnovne strukture, tj. izvrne arhitekture sistema ublaavaju se i tehniki rizici. Poto se u fazi elaboracije mora barem jednom proi kroz itav ivotni ciklus, radi implementacije i testirana osnovne strukture sistema, stiu se neophodna znanja o tome kako efektivno raditi sa ljudima, alatima i tehnologijom koja e se primenjivati u projektu. Sve to omoguuje izradu detaljnog rasporeda i prorauna trokova projekta.

Usavravanje razvojnog procesa i razvojnog okruenja. Dok se tokom faze uvoenja definie proces razvoja i odreuju se alati pomou kojih e se razvijati softverski proizvod. Tokom faze elaboracije se prolazi kroz itav ivotni ciklus razvoja proizvoda, te se na osnovu steenih iskustava vri usavravanje razvojnog procesa i razvojnog okruenja.

Faza konstrukcije Ovo je trea faza votnog ciklusa razvoja informacionog sistema. Tokom ove faze ivotnog ciklusa fokus je na detaljnom dizajnu, implementaciji i testiranju sistema. Faza konstrukcije predstavlja najobimniju fazu i u vremenskom rasporedu zauzima preko polovine ukupnog vremena predvienog za projekat. Meutim, ukoliko su predhodne faze kvalitetno odraene, rizici u fazi tranzicije su svedeni na minimum. Aktivnosti koje se obavljaju u ovoj fazi su u cilju iterativnog razvoja proizvoda i pripreme istog za isporuku krajnjem korisniku uz minimalne trokove razvoja. U fazi tranzicije mogu se izdvojiti sledee aktivnosti:

Podizanje kvaliteta komunikacije u okviru projekta. Za velike razvojne timove ova aktivnost ima veliki znaaj. Ukoliko se pristupi modelu komunikacije u kojem svako komunicira sa svakim, broj potencijalnih linija komunikacije za N lanova iznosi N * (N1) / 2. Sa podizanjem broja lanova broj potencijalnih linija komunikacije se multiplicira, te dostie nivo kada je apsolutno neefikasan. Upravo radi toga potrebno je uvesti novi nain komunikacije. U komunikaciju se uvodi tim za arhitekturu, preko kojeg se vodi komunikacija izmeu razvojnih timova. Na ovakav nain se uvodi komunikacioni vor kojim se smanjuje broj potencijalnih komunikacionih linija.

Razrada preostalih Use Case-ova. Pomoni Use Case-ovi se ne razrauju u fazi elaboracije. U fazi elaboracije se obino razrauje izmeu 80 i 85 procenata Use Case-ova. Preostali Use Case-ovi se razrauju u fazi konstrukcije. Takoe i neki od osnovnih Use Case-ova su predmet ponovne razrade u dialogu izmeu analitiara i dizajnera.

Detaljan dizajn Use Case-ova. Tokom faze konstrukcije vri se detaljan dizajn Use Case-ova u okviru kojih se prepoznaju objekti koji se pojavljuju u potencijalnim scenarijima Use Case-ova. Identifikuje se saradnja izmeu objekata i sekvence poruka koje objekti razmjenjuju, identifikuju se klase i relacije izmeu klasa. Na ovakav nain se Use Case-ovi pripremaju za implementaciju.

Dizajn baze podataka. U fazi elaboracije se postavlja osnovni dizajn baze podataka, a tokom konstrukcije se detaljno definie. Dodaju se nove kolone u tabele, kreiraju se pogledi kao pomo pri izradi upita, kreiraju se indeksi nad tabelama za optimizaciju performansi, itd. Ipak znaajne izmene u oblasti dizajna baze podataka se ne deavaju, a ukoliko se ipak pojave to je znak da faza elaboracije nije odraena kvalitetno i da je faza konstrukcije preuranjena.

Implementacija i testiranje jedinica obrade. Ova aktivnost se vri po unapred utvrenom rasporedu implementacije i testiranja Use Case-ova. Implementacija i testiranje se obavljaju pojedinano, Use Case po Use Case. Dominantna aktivnost u fazi implementacije je kodiranje programskih jedinica. Nakon kodiranja pristupa se testiranju, a kao parametri na osnovu kojih se vri testiranje se koriste zahtevi korisnika.

Integracija komponenti i testiranje sistema. Po zavretku izrade svaku pojedinanu programsku komponentu je potrebno je integrisati u postojei sistem, a potom izvriti testiranje sistema, obraajui posebnu panju na novopridruenu komponentu, kao i na sve bone efekte koje ona moe prouzrokovati u sistemu.

Rano rasporeivanje i dobijanje povratne informacije od korisnika. Ovde se radi o testiranju radnih verzija softvera. Od korisnika se oekuje da testira softver i da povratnu informaciju vezanu za kvalitet softvera. Ukoliko se radi o testiranju komercijalnog softvera, gde je korisnik u ovoj fazi nepoznat javlja se problem pronalaenja i motivacije korisnika da izvre testiranje. Ukoliko se radi softverski proizvod za poznatog korisnika, tada ovaj problem ne postoji, a korisnik je ve od ranije ukljuen u razvoj i praktino ini deo razvojnog tima. I ovu aktivnost je potrebno obavljati kontinuirano u vie iteracija.

Beta rasporeivanje. Beta rasporeivanje zavrava sa okonanjem faze konstrukcije i predstavlja njen osnovni zadatak, a zapoinje po zavretku izrade prve upotrebljive i potpune verzije softverskog proizvoda. Po izradi upotrebljive i potpune verzije softvera ona se

dostavlja krajnjem korisniku, ime se stvaraju potrebni preduslovi za poetak beta testiranja i faze tranzicije.

Priprema za konano rasporeivanje. Ova aktivnost se odvija paralelno sa beta rasporeivanjem i ima za cilj da stvori preduslove za poetak beta testiranja. U okviru nje se vri priprema materijala za trening korisnika, priprema hardvera neophodnog za softverske instalacije, konverzija podataka sa starih sistema na nove, izrada uputstava, itd.

Faza tranzicije Osnovni cilj ove faze jeste tranzicija softverskog proizvoda u ruke krajnjih korisnika. U fazi konstrukcije se u ruke korisnika predaje beta verzija softverskog proizvoda, tako da faza tranzicije poinje sa beta testiranjem. Kao rezultat beta testiranja dobijaju se povratne informacije od korisnika. Ova faza treba da da odgovor na pitanje da li je izraena verzija softvera spremna za isporuku. Slika 12-35

Faza uvoenja Faza elaboracije Faza konstrukcije Faza tranzicije

Prototip nakonceptualnom nivou

Definisanaarhitektura

Betaverzija

Isporuenoreenje

VERZIJA 1.

ITERACIJE - VREME

It. UV1 It. UV2 It. EL1 It. EL2 It. EL3 It. KO1 It. KO2 It. KO3 It. TR1 It. TR2

Faza uvoenja Faza elaboracije Faza konstrukcije Faza tranzicije

Prototip nakonceptualnom nivou

Definisanaarhitektura

Betaverzija

Isporuenoreenje

VERZIJA 2.

ITERACIJE - VREME

It. UV1 It. UV2 It. EL1 It. EL2 It. EL3 It. KO1 It. KO2 It. KO3 It. TR1 It. TR2

Aktivnosti koje se obavljaju u ovoj fazi su sledee: Obuhvat, analiza i implementacija promena u zahtevima. Kao to je gore navedeno na

osnovu isporuene beta verzije softvera korisnici, tokom beta testiranja, daju povratne informacije razvojnom timu. Te povratne informacije mogu biti takve prirode da zahtevaju manje izmene, kao to su popravljanje manjih greaka, unapreivanje korisnike dokumentacije i materijala za trening ili podizanje performansi softvera. Ukoliko su promene u zahtevima tolike da zahtevaju ponovno iniciranje razvojnog procesa, to znai da su predhodne faze loe odraene ili korisnici ranije nisu bili spremni da daju adekvatne zahteve. U tom sluaju faza tranzicije se pretvara u novi razvojni ciklus, kao to je predstavljeno na slici broj 12-35.

Izrada programa zakrpa i dodatne beta verzije. U sluaju kada su uoene greke takve prirode da se mogu izraditi odgovarajui programi zakrpe (eng. - patch) pristupa se njihovoj izradi i isporuci beta korisnicima. Nakon instaliranja zakrpa dobija se nova verzija beta

proizvoda. Najee se ovakve verzije oznaavaju brojano, pa se dobija, npr. beta verzija 2. Utvrivanje mernih jedinica za odreivanje kraja faze tranzicije. Svaki projekat, pa i softverski

mora imati svoj kraj. Da bi se utvrdio kraj faze tranzicije potrebno je definisati standarde koji e dati odgovore na pitanje, koliko je potrebno da proizvod bude kvalitetan. U tom cilju vri se praenje: koliko je novih greaka pronaeno dnevno i koliko je greaka otklonjeno, takoe dnevno. Na osnovu ovih podataka moe se utvrditi mesto na kojem su novopronaene greke svedene na nivo koji ne ugroava zahtevani kvalitet.

Trening korisnika i tima za odravanje. Tokom faze tranzicije potrebno je preneti znanja neophodna za korienje proizvoda, svim korisnicima i znanja potrebna za odravanje proizvoda, timu zaduenom za odravanje. Ukoliko je broj korisnika toliko velik da njihova obuka zahteva dui vremenski period, ovu aktivnost je potrebno zapoeti jo u fazi konstrukcije.

Pakovanje proizvoda. Ova aktivnost podrazumeva izradu finalnog upakovanog proizvoda, koji u sebi sadri softver na nekom mediju za uvanje podataka, dokumentaciju i uputstva, licence i ambalau.

Marketing aktivnosti. Tokom ove aktivnosti izrauje se dokument koji sadri kratak opis proizvoda, njegovu poziciju na tritu, kljune karakteristike i prednosti. Dalje se izrauje tehnika dokumentacija proizvoda, web sajt sa informacijama o proizvodu, demo verzije proizvoda, multimedijalne prezentacije, prie o uspenoj primeni proizvoda, itd.

Zvanino prihvatanje proizvoda od strane kupca. Ova aktivnost se obavlja kroz testiranje proizvoda koje moe biti formalno, neformalno i beta testiranje. Beta testiranje je ranije opisano i ukoliko je tokom ove aktivnosti postignuta saglasnost o tome da proizvod poseduje zahtevani kvalitet, nema potrebe za dodatnim testiranjem. Ukoliko to nije sluaj pristupa se dodatnom testiranju koje moe biti formalno ili neformalno. Razlika je u tome to formalno testiranje ima vre definisana pravila i korake testiranja, ali krajnji rezultat je isti saglasnost kupca da je proizvod prihvatljiv.

Objektne metodologije, naravno, imaju i prednosti i nedostataka. Martin (1995,s.726-727) navodi sledee prednosti: Objektni dizajn uspeno rukuje kompleksnou, ukljuujui bilo koji vid podataka; Objektni dizajn obezbeuje fleksibilnost jer objekti imaju skrivene podatke i metode; Objektni dizajn uveava odzivnost; Objektno dizajn uveava kvalitet: vodi odsustvu defekata, obezbeuje saobraenost svrsi

(potrebama korisnika) i uveava upotrebljivost jer obuhvata iri raspon korisnikovih potreba.

Takoe se veruje da objektno orijentisani pristup objedinjuje mnogo raznih aspekata procesa razvoja informacionog sistema. Coad i Yourdon (1990, s.72), autori jedne od metodologija objektne analize, ukazuju na sledee prednosti:

Sposobnost da reava teke problemske situacije usled razumevanja problemske situacije, koje je tim pristupom omogueno;

Unapreivanje odnosa analitiar - korisnik, poto pristup moraju razumeti i jedan i drugi i poto nije usmeren na raunar;

Unapreivanje konzistentnosti rezultata, poto pristup modeluje sve aspekte problema na isti nain;

Sposobnost da reprezentuje inioce promena u modelu vodei tako ka fleksibilnijem modelu.

Jedan od vanih nedostataka objektne metodologije se ogleda u tome to je objektni pristup mnogo bolje usklaen sa modelovanjem podataka nego sa modelovanjem procesa.

4.3 Agilne metodologije esta kanjenja projekata razvoja informacionih sistema, probijanje budeta i postavljenih vremenskih rokova u realizaciji projekata, permanentni rast sloenosti tehnologije i uestale promene korisnikih zahteva, doveli su krajem dvadesetog veka do pojave nove grupe metodologija. Nastale su agilne metodologije po osobinama mnogo gipkije i prilagodljivije promenama, koje omoguuju korisnicima aktivno uee tokom svih faza i aktivnosti razvoja. Agilni pristup se dakle suoio sa osnovnim problemom savremenog i ujedno brzog razvoja softvera. Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme i trokove razmene informacija izmeu osoba koje uestvuju u razvoju na nain da skrate vremenski period od donoenja odluke do povratne informacije o posledici te odluke. Termin agilan je odabran od strane grupe osoba, velikog iskustva u razvoju informacionih sistema. Polazne pretpostavke su bile da je turbulentnim poslovnim i tehnolokim okruenjima neophodan proces razvoja softvera i informacionog sistema koji istovremeno kreira promene, ali brzo i odgovara na iste. Istovremeno, proces koji ukljuuje odgovorne uesnike i njihovu dobru organizaciju. Uesnicima odnosno njihovom talentu, vetinama i sposobnostima, kao i njihovoj meusobnoj komunikaciji se posebna panja. Usmerenost na uesnike je i najznaajnija osobina agilnih metodologija, prema pojedincima se prilagoava i kompletan proces razvoja. U agilnim razvojnim timovima, kompetencije pojedinaca predstavljaju kritian faktor uspenosti projekta. Prema agilnim metodologijama, ukoliko su pojedinci na projektu dovoljno kvalitetni, tada oni mogu uz bilo koji proces razvoja realizovati oekivani cilj. U suprotnom, nema procesa razvoja koji moe nadomestiti njihovu nekompetentnost. Istovremeno, nedostatak korisnike podrke moe lako unititi projekat razvoja, kao to i neadekvatna podrka moe spreiti zavretak projekta. Mada ni ranije koriene metodologije iz reda strukturnih (tradicionalnih) i objektnih nisu zanemarivale sposobnosti pojedinaca, ipak one su ih posmatrale na drugi nain i isto tako na drugi nain razvijale njihove sposobnosti. Kruti i standardizovani procesi, poznatih i ranije primenjivanih metodologija razvoja, su bili dizajnirani da standardizuju i prilagoavaju pojedince prema organizaciji procesa, dok agilni procesi istiu jedinstvene sposobnosti pojedinaca i tima. Naime, procesi ne mogu nadvladati 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 zajedniki cilj, uzajamno poverenje i potovanje, zajedniki i brz postupak donoenja odluka i sposobnost savladavanja svih dvosmislenosti. Agilan tim koji radi u okviru krute organizacije ima potekoa, kao to ih ima svaki pojedinac koji radi u krutom timu. U ovim timovima, dominira saradnja svih nivoa upravljanja. Za donoenje odluke nije vano ko donosi odluke, ve je vana saradnja i obezbeenje informacija za donoenje odluka. U projektu razvoja uestvuju osobe razliitih vetina, talenta i sposobnosti, koje rade u bliskom fizikom okruenju i potuju organizacionu kulturu. Osobe, okruenje i kultura su u strogoj meuzavisnosti. 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 staloenim timovima, vodi sigurno raspadu tima. Takoe, agilni razvoj se teko izvodi u timovima sa veim brojem lanova. Najvie uspeha u agilnom razvoju pokazuju timovi do devet lanova. Agilni razvoj se pokazao kao uspean u ekstremnim, kompleksnim i visoko-

promenljivim projektima. Okruenje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na ljude i saradnju. Meu najpoznatijim i najee primenjenim metodologija su: Ekstremno programiranje (XP), Scrum, Porodica kristalnih metodologija, FDD (Feature-driven development), Metodologija razvoja dinamikog sistema (DSDM), ASD (Adaptive software development), Lean development i dr. U ovoj glavi e biti rei o prvoj XP ili metodologiji ekstremno programiranje. kstremno programiranje (Xstreme Programing - XP) predstavlja najpoznatiju agilnu metodologiju. Njen idejni tvorac je Beck, K. (1999), koji ju je kreirao sa osnovnom eljom da se pomeri granica oekivanih performansi sistema i da se odbaci veina sigurnosnih sistema prisutna u ostalim (sporijim) metodologijama. XP metodologiju ine nekoliko pravila i skroman broj postupaka koji su veoma laki i jednostavni za korienje. Softver se razvija putem iteracija, koje u proseku traju dve nedelje, i tokom kojih se implementiraju korisnike prie, tj. osobine softvera koje zajedniki formuliu budui korisnici i projektanti razvoja. snovu XP predstavlja saradnja sa korisnicima i vrsta povratna veza, pa su usled toga korisnici i ukljueni u planiranje i celokupan razvoj. Korisnik usmerava ceo razvojni tim i ima na raspolaganju svakih nekoliko dana novi softver. Naglasak u razvoju se stavlja na testiranje putem korisnikih testova, programiranje u parovima i razvoj voen testiranjem, ime se dobija visokokvalitetan kod. XP je kombinacija jednostavne prakse koja naglaava komunikaciju, timskog rada, zahteva korisnika i njegovog zadovoljstva. Prema Beku, ivotni ciklus XP ine sledee faze: istraivanje, planiranje, iteracije do distribucije, proizvodnja, odravanje i naputanje. Istraivanje - U ovoj fazi korisnici piu korisnike prie koje ele da ukljue u prvu distribuciju. Svaka korisnika pria sadri zahteve koji se trebaju realizovati u softveru. U isto vreme, razvojni tim se upoznaje sa alatima, tehnologijom i postupcima koji e se koristiti u projektu. Posle upoznavanja, vri se testiranje tehnologija. Izgradnjom prototipa sistema, istrauju se mogunosti arhitekture sistema. Ova faza traje od nekoliko nedelja do nekoliko meseci, to najvie zavisi od toga koliko su projektanti upoznati sa tehnologijom. Planiranje U ovoj fazi se utvruje redosled i raspored korisnikih pria i sadraj prve distribucije. Razvojni tim prvo procenjuje koliko resursa zahteva svaka korisnika pria i utvruje raspored njihovog izvrenja. Vremenski period do prve distribucije obino ne traje due od dva meseca. Sama faza planiranje traje nekoliko dana. Iteracije do distribucije Ova faza obuhvata nekoliko iteracija pre prve distribucije. Utvreni raspored u fazi planiranja se deli na nekoliko iteracija, od koji svaka traje od jedne do etiri nedelje. Prva iteracija se usredsreuje na komponente arhitekture, koje su neophodne da bi se postavila osnova sistema. To je ujedno i iteracija "nulte poslovne vrednosti", poto se vri odabir onih korisnikih pria koje podstiu izgradnju strukture celokupnog sistema, tehnike su prirode i ne donose neposredne koristi korisniku. Naredne iteracije proizvode poslovne vrednosti koje vremenom rastu. Korisnici odluuju o implementaciji pojedinih pria u svakoj iteraciji. Prioritet se sigurno daje priama koje donose najveu poslovnu vrednost. Odabrane prie se zatim razlau na programerske zadatke koji iste podravaju. Programeri rade zajedno u timovima, kako bi pronali prvo zadatke koje treba izvriti, zatim se prijavljuju za realizaciju pojedinih zadataka i procenjuju koliko je napora i resursa potrebno za njihovo izvrenje. Nakon toga, zapoinje se sa

radom na zadacima u parovima. Kada se zadatak izvri, programerski par oznaava svoj zadatak kao zavren i pristupa aktivnosti stalne integracije koda na posebnom raunaru namenjenom integraciji. Na kraju svake iteracije se izvrava funkcionalni test koji je kreiran od strane korisnika, a na kraju poslednje iteracije je sistem spreman za produkciju. Proizvodnja Pre distribucije sistema korisniku ili kupcu, vri se dodatno testiranje i provera njegovih svojstava. Tokom ove faze se mogu unositi eventualne izmene, ali poto je vreme svake iteracije fiksirano, izmene se mogu sprovoditi samo na tekuoj distribuciji. Posle testiranja, vri se ugradnja sistema u radno okruenje kupca. Odravanje Posle prve distribucije sistema koji moe biti od koristi korisniku, vri se njegovo odravanje i rad na novoj iteraciji naredne distribucije. Brzina razvoja sistema se moe usporiti poto se pusti u upotrebu. Tokom ove faze se moe vriti izmena strukture timova i dodavati novi izvrioci. Naputanje U ovu fazu se ulazi kada se iscrpe korisnike prie koje treba implementirati i kada vie nema nikakvih promena u arhitekturi, dizajnu i kodu. Tokom ove faze se vri kompletiranje celokupne dokumentacije sistema, koje ima dovoljno ali ne i previe. Faza naputanja moe nastupiti i kada sistem ne daje zadovoljavajue rezultate ili postane preskup za dalji razvoj. Nakon kratkog opisa XP metodologije, umesto komentara njenih osobine, u nastavku se navode vrednosti i principi opisani u Agilnom manifestu, tekstu koji je proglasila Agilna alijansa, a koje poseduju veina agilnih metodologija. Osnovne i primarne vrednosti agilnog pristupa su: Individualnost i interakcija naspram standardnih procesa ili alata Dosadanji pristupi u razvoju informacionih sistema su panju usmeravali na procese, smatrajui ljude, uesnike u razvoju, zamenljivim komponentama razvoja. Meutim, agilni pristup podrazumeva da samo od projektnog tima zavisi uspeh razvoja, te bez "jakih" igraa nema kvalitetnog softvera. Pri tome jaki igrai nisu vrhunski projektanti i programeri, ve osobe prosenog znanja ali i sposobnosti da rade u timu sa drugima. Komunikacija i interakcija u timu su vaniji inioci uspeha od samog talenta. Tim sa osobama prosenog znanja ima vie izgleda za uspeh od tima nadprosenog znanja koje ne mogu raditi u timu. Razvojni alati prema agilnom pristupu imaju veliku vanost za uspeh projekta, ali je obilje alata isto tako negativno kao i njihov nedostatak. Prema ovom pristupu, sugerie se korienje besplatnih alata, a ne kupovina licenci najnovijih i najskupljih CASE proizvoda. Prelazak na kvalitetnije alate se sprovodi tek nakon to oni primenjivani i najjeftiniji ne zadovoljavaju potrebe razvoja. Praktian softver naspram obimne dokumentacije Pristalice i zagovornici agilnog pristupa smatraju da je obimna dokumentacija nepotrebna i da proizvodi negativne efekte. Zbog toga je po njima bolje vreme troiti u izradu programskog koda. Istina da kod nije sredstvo za komunikaciju, ali i dokumentaciju treba racionalizovati za potrebe donoenja odluka i obuavanje novih lanova tima. Kratka, racionalna dokumenta ne ograniavaju njihovu obuku, jer se prema agilnom pristupu ona odvija saradnjom u okviru timova. Novi lanovi interakcijom sa starim lanovima u timu postepeno postaju delovi buduih timova. Saradnja sa korisnicima naspram ugovornog odnosa Agilan pristup podrazumeva aktivno i stalno uee korisnika u razvojnom timu, a ne samo tokom identifikacije i saoptavanja njihovih zahteva. Povremeno ili fragmentalno uee u razvoju vodi neuspehu i niskom kvalitetu realizovanog informacionog sistema. Da bi projekat bio

uspean, autori agilnih metodologija, ceo postupak i sve vreme razvoja zasnivaju na estim kontaktima sa korisnicima koji pruaju inicijalne ili povratne informacije. Takav odnos je po njima bolji od ugovornog odnosa u kojem se eksplicit navodi potreba saradnje ove dve polarizovane strane.

Prilagoavanje promenama naspram praenja planova Sposobnost reagovanja na promene veoma uestalo predstavlja presudnu komponentu za uspeh ili neuspeh projekta. Agilni pristup se zalae da se pri izradi planova mora voditi rauna o tome da oni budu fleksibilni i prilagodljivi promenama, jer se pravci razvoja projekta u ovoj oblasti ne mogu predviati daleko u budunost. Poslovno okruenje se stalno menja, kao i sami korisnici koji menjaju svoje zahteve kako vide sistem koji funkcionie. Strategija planiranja, koja se predlae, podrazumeva detaljan plan za prvih nekoliko nedelja projekta, veoma grub i okviran plan za nekoliko meseci i uproeni plan za vremenski period nakon toga. Naime, dobro se poznaju zadaci za par nedelja, povrno zadaci za narednih nekoliko meseci, a samo kroz maglu naziru zadaci ili bolje reeno ideje nakon godinu dana. Sve etiri navedene vrednosti se realizuju kroz sledeih dvanaest principa: Najvii prioritet u razvoju ima zadovoljenje korisnika putem rane i uestale isporuke

upotrebljivog softvera. Njegova upotreba u najranijim fazama razvoja i njegova esta distibucija, donose nekoliko koristi. Pre svega, razvojni tim ima povratne informacije o onome to je ve uraeno tj. da li je na ispravnom putu razvoja. Takoe, korisnici su u mogunosti da upotrebljavaju realizovano reenje veoma rano ukoliko procene da im je izgraena funkcionalnost dovoljna ili da ga samo pregledaju i zahtevaju njegove dalje izmene.

Promene zahteva su uvek dobrodole, pa ak i na samom kraju razvoja. Putem estih promena, realizovano reenje se prilagoava izmenjenim potrebama korisnika, to doprinosi viem kvalitetu. Agilni razvojni timovi tee da strukturu reenja odre veoma fleksibilnom, da bi promene zahteva imale mali uticaj na softver.

Uestalo isporuivati za korisnika upotrebljiva reenja, u intervalima od nekoliko nedelja do nekoliko meseci, sa preferiranjem to kraih vremenskih perioda. Osnovni cilj je isporuivati reenja veoma rano i esto. Kratkim vremenskim ciklusima se dobija uestala povratna informacija od korisnika na osnovu koje se, ukoliko je potrebno, vri brza ispravka isporuenih reenja. Sve isporuke do poslednje odnosno krajnje ne sadre dokumentaciju.

Korisnici i projektanti svakodnevno rade zajedno do samog zavretka projekta. Da bi projekat bio agilan, mora postojati znaajna i uestala interakcija kako korisnika, razvojnih timova, tako i svih ostalih zainteresovanih strana u razvoju.

Na projektu moraju raditi i zadatke izvravati motivisani pojedinci. Njima je neophodno obezbediti odgovarajuu podrku, radno okruenje i poverenje da e posao zavriti na pravi nain. Posebno se istiu osobine koje pojedinci trebaju posedovati kao to su ljubaznost, komunikativnost i talentovanost. U agilnom pristupu uesnici razvoja predstavljaju najvaniji faktor uspeha. Svi ostali faktori kao to su procesi, standardi, okruenje, upravljanje su od sekundarnog znaaja i mogu se uvek promeniti tokom razvoja. Takoe, ukoliko pojedine aktivnosti ili metodoloki koraci razvoja predstavljaju prepreku timu u realizaciji zadataka, mogu se slobodno menjati.

Najefikasniji i najefektniji nain prenosa informacija u timu je putem linog kontakta tj. licem u lice. Tokom razvoja se mogu kreirati i dokumenta koja e sluiti za prenoenje informacija izmeu lanova razvojnog tima, ali ona nisu obavezna. Obavezna je samo komunikacija.

Merilo napredovanja na projektu je stepen upotrebljivosti softvera. Napredak agilnog projekta razvoja informacionih sistema se meri koliinom softverskih reenja koja se upotrebljavaju a ne na osnovu faze razvoja u kojoj se projekat nalazi, koliine napisanog koda, koliine kreirane dokumentacije i slino.

Agilni proces podrava odrivi razvoj. Prema agilnom pristupu, razvojni tim mora odravati trajnu i konstantnu snagu i brzinu u razvoju. Umorno i pod stresom osoblje nije poeljno na projektu jer ne produkuje dobre rezultate. Zbog toga svi akteri projektnog tima trebaju imati razumnu radnu angaovanost koja im omoguuje da ostanu stalno zaposleni i pribrani. Agilni tim samostalno odreuje svoj tempo, vodei pri tome rauna da ne potroi sutranju energiju kako bi danas uradio neto malo vie.

Neprekidna usmerenost na tehniko savrenstvo i dobar dizajn uveava agilnost. Ukoliko je dizajn sistema saet i uredan, lake ga je menjati, pa se time poveava agilnost. Obaveza projektanata je da od samog poetka projekta pruaju dobar dizajn i da tokom itavog razvoja isti stalno razmatraju i auriraju.

Osnovu razvoja ini jednostavnost tj. sposobnost maksimiranja poslova koji nisu obavljeni. Agilni pristup insistira na implementaciji samo dogovorenih karakteristika, a nikako i onih koje to nisu. Predvianje buduih problema nije njegova karakteristika, ve samo reavanje problema koji su nastali. Osnovna ideja je da se posao izvrava i trai jednostavno i kvalitetno reenje, kako bi se po nastanku problema isto moglo lako promeniti i prilagoditi.

Najbolja arhitektura, zahtevi i dizajn dovode do samoorganizujueg tima. Odgovornosti i uloge su u timu i nikad izvan njega. One se dodeljuju celini tima, pa se u timu delegiraju dogovorno pojedincima. lanovi tima rade zajedno na svim aktivnostima projekta. Nema pojedinanih odgovornosti za arhitekturu, zahteve ili testiranje, ve ih snosi tim.

U redovnim vremenskim intervalima se preispituju naini realizacije bolje efikasnosti i prema tome prilagoava ponaanje. Razvojni tim se redovito sastaje kako bi analizirao i raspravljao o radnim navikama lanova tima, sa ciljem podizanja njihove agilnosti. Zbog toga se povremeno menja njegova organizacija, pravila, konverzacija, veze i tako odrala agilnost.