21
1 INTERNACIONALI UNIVERZITET U NOVOM PAZARU FAKULTET ZA INFORMATIKU I INFORMACIONE TEHNOLOGIJE SEMINARSKI RAD Predmet: Softversko inženjerstvo Tema: Modeli softverskog procesa Mentor: Student: prof. dr.Mirsad Niković Tatjana Dimitrijević br.ind 2296 / 06 Panĉevo, Mart 2010. god.

Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

Embed Size (px)

DESCRIPTION

Pretmet: Softversko inzenjerstvo; Tema: Modeli razvoja softverskog procesa; Student: Tatjana Dimitrijevic- Seminarski rad

Citation preview

Page 1: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

1

INTERNACIONALI UNIVERZITET U NOVOM PAZARU

FAKULTET ZA INFORMATIKU I INFORMACIONE TEHNOLOGIJE

SEMINARSKI RAD

Predmet: Softversko inženjerstvo

Tema: Modeli softverskog procesa

Mentor: Student: prof. dr.Mirsad Niković Tatjana Dimitrijević br.ind 2296 / 06

Panĉevo, Mart 2010. god.

Page 2: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

2

SADRŽAJ

Uvod 1

1. Softverski proizvod 3

2. Principi i modeli razvoja softvera 3

3. Najĉešći modeli razvoja softvera 4

3.1. Model vodopada 4

3.2. Model V 6

3.3. Inkrementalni model 7

3.4. Model prototipskog razvoja 8

3.5. Spiralni model 9

3.6. Model zasnovan na komponentama 10

3.7. Model unificiranig procesa razvoja 11

3.8. Agilni model razvoja 12

3.9. Kombinovani model 13

3.10. Extreme programming 14

4. Zakljuĉak – Pregled i evaluacija softverskog projekta 15

Page 3: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

3

UVOD

Softversko inženjerstvo je raĉunarska disciplina koja se bavi razvojem složenih aplikacija. Ono se bavi ne samo tehniĉkim aspektima izgradnje softverskog sistema, već i manadžerskim

problemima poput organizacije programerskog tima, terminskim planiranjem, finansijama … (http://www.webopedia.com)

Softversko inženjerstvo je inženjerska disciplina koja vodi brigu o svim aspektima

proizvodnje softvera od specifikacije sistema do implementacije sistema i održavanja (Sommerville, 2001.).

Možemo prometiti da se javljaju dva kljuĉna pojma: Inženjerska disciplina: Inženjeri ĉine da proizvod radi. Oni primenjuju teoriju, metode i alate, ali to

ĉine selektivno, uvek pokušavajda naĊu što bolje rješenje za odreĊene probleme. Ograniĉeni su finansijskim i organizacijskim ograniĉenjima.

Svi aspekti proizvodnje softvera: Softverski inženjeri brinu ne samo o tehniĉkim aspektimaspektima

procesa razvoja softvera, već i o upravljanju softverskim projektom, kvaliteti proizvoda i dr.

Ilustracija 1. Životni ciklus razvoja softvera

Softversko inženjerstvo je projektovanje, razvoj, dokumentacije i održavanja softvera

primjenjujućitehnologije i prakse iz više disciplina, ukljuĉujući raĉunarsku nauku, upravljanje projektima, inženjering, dizajn interfejsa, integraciju u produĉja promene itd.

Softversko inženjerstvo obuhvata važna područja kao što su: voĊenje poslovanja i IT,

razvoj softverskih metodoligija i okvira,

troškovi razvoja

trajanje razvoja,

rizici u razvoju softvera,

ugraĊivanje kvaliteta razmišljanje u procesu razvoja softvera,

testiranje,

upravljanje razvojnih timova,

project management,

projekt izvještavanje,

projekt brzine razvoja projekta,

komunikacija svih uĉesnika.

Page 4: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

4

1. Softverski proizvod

Softverski proizvod (aplikacija) stvoren po principima softverskog inženjerstva može biti

razvijen kao: Generiĉki proizvod (fleksibilan, slobodno oblikovan, razvijen od proizvoĊaĉa softvera,

ponuĊen na tržištu bilo kojem kupcu),

Naruĉeni proizvod (izraĊen prema dogovorenim zahtevima, strogo determiniran, namenjen i isporuĉen konkretnom odreĊenom kupcu).

Temeljni cilj softverskog inženjerstva ogleda se u težnji da se stvori visoko kvalitetan

softverski proizvod u dogovorenom roku i uz što manje troškove. U skladu s izreĉenim ciljem moguće

je prepoznati tri kljuĉne kategorije u procesu razvoja softverskog proizvoda: Isporuka softvera u dogovorenom roku,

Troškovi razvoja softvera u dogovorenim okvirima, Zadovoljavajući kvalitet softvera.

Za razvoj softvera karakteristične su odreĎene temeljne aktivnosti:

Specifikacija potreba (identifikacija, transformacija potreba u zahteve, analiza, odreĊivanje

prioriteta …) Dizajniranje problema (oblikovanje problema grafiĉkom notacijom, oblikovanje procesa,

analiza …) Implementacija (kodiranje, testiranje, uvoĊenje u rad, dokumentiranje, edukacija …)

Validacija (testiranje softverskog sistema, procena kvaliteta …)

Evolucija (održavanje sistema, reinženjering …)

Softverski proces (ili životni ciklus softvera) je skup administrativnih i tehniĉkih aktivnosti koje se realizuju u toku prikupljanja, razvoja, održavanja i povlaĉenja softvera, odnosno sve aktivnosti koje se

sprovode da bi se proizveo neki softverski proizvod i svi rezultati koji se pri tom dobijaju.

2. Principi i modeli razvoja softvera

Softverski inženjering ĉine skupovi koraka koji ukljuĉuju metode, alate i procedure. Ti

koraci su zasnovani na razvojnim principima i upućuju na modele razvoja softvera u softverskom

inženjeringu. Model razvoja se odabira u zavisnosti od prirode projekta i aplikacije, tehniĉke orijentacije

ljudi koji će uĉestvovati u razvoju, metoda i alata koji će se upotrebljavati pri razvoju, naĉina kontrole i samih proizvoda koji se zahtevaju.

Razvojni principi su takvi opšte važeći osnovni principi koji odreĊuju naĉin izvršenja rada i

omogućuju uopštavanje odreĊenih specifiĉnosti i zakonitosti objektivne stvarnosti. Oni mogu biti osnovni principi naĉina izvršenja rada i principi razvoja s obzirom na metodološke korake i redosled

njihovog izvršenja.

Osnovni principi načina izvršenja rada su: princip modelovanja,

princip iteracija,

princip simulacije, princip dokumentovanja.

To su opšte poznati i prihvaćeni principi u razliĉitim podruĉjima, koji se samo i u razvoju softvera

primenjuju. Principi razvoja obzirom na metodološke korake se menusobno razlikuju po tome

koliki znaĉaj pridaju pojedinim fazama u razvoju softvera, koliko ih detaljno posmatraju i u kojem redosledu izvršavaju.

Page 5: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

5

Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki softverski

sistemi i prikazuju razliĉite poglede na proces razvoja softvera. Osnovni razlog njihove pojave je

bila želja da se obezbedi uopštena šema razvoja softvera, koja bi služila kao osnova u planiranju, organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju

aktivnostima razvoja softvera.

Modeli su apstrakcije koje pomažu u procesu razvoja softvera.

Model softvera predstavlja komponente razvoja softvera i razvijen je na osnovu ideja konstruktora i njegove predstavke šta je najznaĉajnije u tom razvoju.

Model može predstavljati: model procesa razvoja,

model softvera ili model naĉina upravljanja softverom.

Primarni cilj kreiranja modela je da se obezbede softverski proizvodi koji odgovaraju zahtevima korisnika.

U zavisnosti od znaĉaja koji se pojedinim fazama i aktivnostima razvoja softvera pridaje, zatim forme

organizacije i upravljanja razvojem, kao i iskustva zaposlenih i prirode proizvoda, razlikuju se:

Preskriptivni modeli razvoja – konvencionalni modeli sa delimiĉno razliĉitim tokom procesa

razvoja ali sa istim generiĉkim aktivnostima; Model vodopada,

Inkrementalni modeli razvoja: Inkrementalni model, RAD model,

Razvojni modeli: Model prototipskog razvoja, Spiralni model, Istovremeni model razvoja (Concurrent Development)

Specijalizovani modeli:

Model zasnovan na komponentama, Model zasnovan na formalnim metodama, 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)

3. Načešći modeli razvoja softvera

3.1. Model vodopada

Model vodopada je uveo W. Royce 1970. godine. Prema njemu razvoj softvera zahteva sistematiĉan pristup, jer se odvija po strogo definisanom sekvencijalnom redosledu koraka,

postepenim prevoĊenjem rezultata od prve do poslednje faze razvoja softvera. Razvoj zapoĉinje na sistemskom nivou da bi se nastavio preko analize, projektovanja, kodiranja, testiranja i završio

održavanjem.

Faze i aktivnosti razvoja prema ovom modelu su sledeće:

Analiza i definisanje zahteva sistema - Obzirom da softver predstavlja samo deo nekog sistema, rad na razvoju softvera zapoĉinje definisanjem zahteva prema svim elementima

sistema i alociranjem jednog dela adekvatnih i odreĊenih zahteva prema softveru. Ovaj

Page 6: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

6

sistemski pogled je posebno znaĉajan kada se softver povezuje sa ostalim elementima

strukture kao što su hardver, menver (organizacija i zaposleni), podaci i dr.

Analiza i definisanje zahteva softveru – Ovom fazom i njenim aktivnostima se intenzivira prikupljanje specifiĉnih i posebnih zahteva softveru. Da bi softverski inženjer razumeo prirodu

softvera koji treba razviti, on mora razumeti domen koji informacija ima za softver kao i zahtevane funkcije, performanse i menusobne veze. Zahtevi sistema i zahtevi softveru se

dokumentuju, a zatim analiziraju i pregledaju sa korisnicima.

Ilustracija 2. Model vodopada

Projektovanje ili dizajn softvera - Projektovanje softvera je faza razvoja koju ĉine

aktivnosti 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 u odreĊeni softverski proizvod koji se može oceniti sa aspekta kvaliteta pre nego što zapoĉne kodiranje. Kao i zahtevi, rezultati projektovanja se

dokumentuju i predstavljaju deo konfiguracije softvera.

Kodiranje – Ovom fazom se izvršava zadatak prevoĊenja rezultata projektovanja u mašinski prepoznatljivu formu. Ukoliko je projektovanje uraĊeno dovoljno detaljno, tada se kodiranje

obavlja mehaniĉki. Testiranje - Kada se jednom izgeneriše kod programa, tada zapoĉinje njegovo testiranje.

Testiranje se svodi na unutrašnju logiku softvera, sa ciljem da se svi iskazi provere odnosno da se proveri da li su isti taĉni. Takone, testiranje se svodi i na spoljnu funkciju softvera, da bi

se otkrile greške i proverilo da li će definisani ulazi proizvesti rezultate koji se podudaraju sa

identifikovanim zahtevima. Održavanje - Softver će sigurno pretrpeti odrenene izmene nakon što se distribuira

korisniku. Potrebe za izmenama se javljaju zbog proširenja funkcija ili performansi koje zahteva korisnik, zbog potreba da se softver prilagoĊava promenama koje uzrokuje

promenjeno okruženje ili zbog razvoja tehnologija koje se upotrebljavaju.

Svaka od navedenih faza u modelu poseduje specifiĉnosti, rezultira izvesnim proizvodom i omogućuje

reviziju. Aktivnosti faze se izražavaju neophodnim ulazom, procesom i realizovanim izlazom. Razvoj softvera tako prolazi kroz niz koraka sa iterativnim interakcijama izmenu aktivnosti koje su sukcesivne

odnosno povezane kao susedne. Rezultat realizacije odrenene aktivnosti je izlaz – uglavnom proizvod koji se koristi kao ulaz u sledeću aktivnost.

U stvarnosti, razvoj nikad nije tako eksplicitno odreĊen. Uvek postoji povratna sprega izmeĊu

aktivnosti, ali samo onih koje su susedne i u neposrednoj vezi. Zbog toga razvijeni proizvodi u svakoj fazi zahtevaju proveru i reviziju pre prihvatanja. Model vodopada je posebno efikasan u

struktuiranju i upravljanju malim projektima razvoja softvera u organizacijama. To je najstariji model razvoja koji je najviše i najšire primenjivan do danas. Uspešno se kombinuje sa drugim modelima

razvoja.

Page 7: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

7

Primena ovog modela se predlaže u sledećim situacijama:

prilikom razvoja softvera 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,

kada korisnik jednoznaĉno može definisati svoje zamisli i potrebe u odnosu na softver, koji na toj bazi izgraĊen ne sadrži suvišne komponente i funkcioniše veoma brzo i uspešno,

postoji dovoljno vremena i strpljenja kod korisnika za dugi period razvoja i

visoki razvojni troškovi i saobrazno potrebna finansijska sredstva nisu ograniĉavajući faktor razvoja.

Slabost modela je nedostatak povratne sprege izmenu koraka koji nisu sukcesivni i ne odvijaju se u

sekvencijalnom redosledu. TakoĊe, kao nedostaci se navode sledeće činjenice: realni projekti veoma retko prate modelom definisani sekvencijalni tok, a iteracije uvek

izazivaju ili se kod njih javljaju problemi u primeni modela,

uvek je teško za korisnika da u poĉetku rada na razvoju softvera navede eksplicitno sve svoje zahteve (a što model zahteva), jer se teško prilagoĊava neizvesnosti koja uglavnom egzistira

na startu, kupac mora biti veoma strpljiv i istrajan, jer će mu radne verzije programa biti dostupne tek

na kraju aktivnosti razvoja softvera,

greške koje se ne otklone u fazi testiranja programa, mogu imati straviĉno distorziono dejstvo na projekat razvoja.

3.2. Model V

V model (nemaĉko Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje

odnos testiranja i faza analize i projektovanja, ĉineći eksplicitnim neke povratne sprege koje su

skrivene u kaskadnom modelu.

Ilustracija 3. V model procesa

V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za razliku od kaskadnog

modela koji je usredsreĊen na dokumente i meĊuproizvode. V model se koristi na sledeći naĉin:

Testiranje delova, testiranje sistema pri integraciji i testiranje sistema bave se ispravnošću

programa i mogu se koristiti za verifikovanje dizajna programa. Završni test služi za validaciju zahteva, tj. proveru da li su svi zahtevi potpuno

implementirani. Ako se pronaĊu problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela

mogu se ponoviti radi popravke i poboljšanja zahteva, dizajna ili koda, pre nego što se ponove testiranja na desnoj strani modela.

Page 8: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

8

3.3. Inkrementalni model

U ovom modelu razvoja se prvobitno potpuno razvija inicijalni podskup funkcija

softvera, a zatim se sukcesivnim koracima razvijaju, kao nadgradnja prethodnog koraka, stalno novije i komplikovanije verzije.

Ilustracija 4. Inkrementacija

Iterativni razvoj takoĎe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se

potpun sistem isporuĉuje u svim verzijama, s tim što se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledeća verzija unapreĊuje prethodnu.

Ilustracija 5. Iteracija

Projektovanje softvera se izvodi u prvom koraku, ali se uvoĊenje softvera odvija sukcesivnom

razradom (usavršavanjem inicijalnog podskupa). Softver se razvija malim dodacima

(inkrementima) kojima se može jednostavno i lako upravljati. Svaki inkrement dodaje postojećem softveru pojedine nove funkcije, pri ĉemu se postojeće zadržavaju.

Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na

podsisteme prema funkcijama. Verzije se definišu kao funkcionalni podsistemi, tako da se svakoj novoj

verziji prikljuĉuju nove funkcije. Sistem se nadograĊuje do potpune funkcionalnosti.

Prednost ovakvog razvoja je u tome da se dodaci odnosno nove funkcije lakše razumeju i testiraju. Korišćenje mogućnosti da se stalno dodaju nove funkcionalnosti softverskom proizvodu, daje

mogućnost ugradnje bogatog korisniĉkog iskustva u redefinisani proizvod na manje skup naĉin. Ovaj model predstavlja kombinaciju klasiĉnog modela životnog ciklusa softvera sa iterativnim

mogućnostima razvoja. On takone obezbenuje naĉin da se periodiĉno distribuira ažuriranje i

održavanje softvera razliĉitim korisnicima. Posebno je popularan i koriste ga u softverskim kućama.

Ilustracija 6. Logaritam inkrementalnog modela

Page 9: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

9

3.4. Model prototipskog razvoja

Model prototipskog razvoja se koristi da bi se za potrebe korisnika razvio inicijalni model budućeg softvera koji simulira njegove stvarne funkcije sa ciljem da korisnik da

svoje mišljenje i odluči koji i kakvi su njegovi zahtevi.

Kod razvoja softvera po ovom modelu korisnik već u najranijem stadijumu može videti na koji će se naĉin zadovoljiti njegovi zahtevi. Komponente razvijenog softvera ĉesto predstavljaju samo

korisniĉki interfejs. Implementacija kostura ovog interfejsa je sa željom da se obezbedi mogućnost za povratnu

spregu od korisnika, pre nego da se specificira i projektuje konaĉna verzija rešenja. Mada je razjašnjenje korisniĉkog interfejsa jedan od ciljeva, prototip može biti takoĎe iskorišćen kao

koncept unutar konteksta drugog modela. U tom sluĉaju, drugi model može posmatrati prototip

kao jedan elemenat procesa, koji se koristi u razjašnjenju ponašanja sistema u razliĉitim taĉkama razvoja softvera.

Model obiĉno prihvata neku vrstu funkcionalne specifikacije softvera kao ulaz, koji se simulira, analizira i izvršava. Ova tehnologija omogućuje da aktivnosti projektovanja softvera budu inicijalno

preskoĉene ili premoštene. TakoĊe, omogućuje da se brzo izgrade primitivne verzije softvera,

koje kasnije korisnik može i sam razvijati. Korisniĉki razvoj je ukljuĉen u povratnu spregu za redefinisanje sistemskih specifikacija i dizajna. U zavisnosti od tehnologije prototipskog razvoja, ceo

radni sistem može biti razvijen kontinuiranim procesom obezbenuje radne verzije sistema koje razvija i što u većoj meri od drugih modela angažuje korisnika na razvoju, te unaprenuje kvalitet procesa.

ISPORUĈENI SISTEM

Ilustracija 7. Model prototipskog razvoja

Model prototipskog razvoja se najčešće upotrebljava i daje solidne rezultate u situacijama:

kada su od strane korisnika samo uopšteno definisani ciljevi razvoja softverskog proizvoda, ali ne i detalji u pogledu ulaza, procedura i izlaza,

kada je moguće simulirati rad softvera da bi korisnik mogao videti kako će budući softverski proizvod funkcionisati i

kada same razvojne organizacije žele proveriti efikasnost algoritama ili adaptibilnost sistema.

Model uobičajeno može imati tri oblika: prototip u obliku papira koji opisuje vezu ĉoveka i mašine na naĉin da korisniku omogući

razumevanje tog odnosa, radni prototip koji implementira neke od funkcija postavljenih kao zahtevi softverskom

proizvodu ili

realni program koji izvršava deo ili celinu zahtevanih funkcija.

Model prototipskog razvoja zapoĉinje prikupljanjem zahteva. Projektant i korisnik, zajednički definišu opšte ciljeve razvoja softverskog proizvoda, identifikuju sve njima poznate zahteve i

odrenuju podruĉja na kojima su obavezne dalje aktivnosti preciznijeg definisanja. Sledi "brzi" dizajn u

kome se fokusira na realizaciju onih aspekata softvera 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 softveru 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 zahteva prema softveru. Ukoliko se razvija radni prototip,

Page 10: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

10

korisniku se omogućuje da koristi delove softvera ili primenjuje alate koji brzo generišu radne verzije

softvera.

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

Korisnik uoĉava radnu verziju softvera neznajući na koji su naĉin delovi softvera 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 softverskog 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 samo da bi se demonstrirala sposobnost softvera.

Nakon izvesnog vremena, zaboravlja se na naĉin odabira i njihove uzroke, pa manje idealna rešenja ili bolje reĉeno manje kvalitetna rešenja ostaju integralni deo konaĉnog softverskog rešenja.

Zbog toga, znaĉajno je da se projektant i korisnik, u cilju efikasnosti ovog modela, dogovore i definišu „pravila igre‟ na poĉetku procesa razvoja softvera. Drugim reĉima oni se moraju složiti da

se prototip razvija kao mehanizam za definisanje zahteva, a softver se razvija u cilju zadovoljenja kriterijuma kvaliteta i mogućnosti održavanja.

3.5. 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.

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

planiranje – faza koju ĉine aktivnosti odrenivanja ciljeva, alternativa i ograniĉenja, analiza rizika – faza koju ĉine aktivnosti analize alternativa i identifikovanja rizika,

inženjering – faza razvoja novih nivoa proizvoda i razvoj i ocenjivanje – faza procene rezultata inženjeringa.

Posmatranjem spirale, svakom iteracijom se progresivno razvijaju kompletnije i potpunije verzije softvera. Tokom prvog ciklusa kretanja spiralom, prikupljaju se zahtevi i planira projekat

razvoja, da bi se izvršila analiza rizika inicijalnih zahteva.

Ilustracija 8. Spiralni model

Page 11: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

11

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 manje apstrakcije.

Po završetku inžinjerskog posla razvoja, korisnik ocenjuje i daje sugestije za modifikaciju

softverskog proizvoda. Zasnovana na korisniĉkom inputu, javlja se sledeća faza planiranja novog

ciklusa razvoja i analize 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 velik

i ulaganja nesrazmerno visoka 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ĉajnije i više troškove.

Tipična raspodela vremena, za koja ipak treba reći da variraju od ciklusa do ciklusa, je:

planiranje i dizajn 20%, procena rizika 5%,

realizacija (sa testiranjem) 40%, revizija 15% i

ocenjivanje 20%.

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 softvera. Model prilagonava svaku kombinaciju razliĉitih pristupa u razvoju softvera.

Ovo je trenutno najrealniji pristup u razvoju softvera za velike sisteme.

Model omogućuje brzu reakciju na uoĉene rizike, a primenom prototipskog razvoja pruža mehanizam za njihovo smanjenje.

I pored velikog broja prednosti, model poseduje i nedostatke. Nedostatak ovog modela je odsustvo veze prema postojećim standardima, odnosno ne postojanje standarda za ovaj naĉin razvoja softvera.

TakoĊe, model zahteva više uniformnosti i konzistentnosti u razvoju. Velike probleme stvara situacija

kada se na vreme ili uopšte ne otkriju rizici. Konaĉno, model je relativno nov i nije bio široko primenjivan.

3.6. Model zasnovan na komponentama

Osnovni pristup u ovom modelu je konfigurisati i specijalizovati već postojeće komponente softvera u novi aplikativni sistem.

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.

Page 12: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

12

Višestruko korišćenje softvera je proces uključivanja u novi proizvod pojedinih

komponenti: 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 softvera, povećava produktivnost izrade softvera,

povećava kvalitet softvera, smanjuje troškove razvoja softvera,

štedi odnosno skraćuje vreme izrade,

zadovoljava ciljeve softverskog inženjeringa, širi korišćenje softvera,

obezbenuje adekvatnu dokumentaciju, olakšava održavanje softvera,

modelira sistem za lakše razumevanje i dr.

3.7. Model unificiranog procesa razvoja

Za razliku od prethodno opisanih modela razvoja softvera, Ivar Jacobson, Grady

Booch i James Rumbaugh su 1999. godine objavili USDP – model unificiranog procesa

razvoja softvera. Ovaj model opisuje proces razvoja korišćenjem UML - objedinjenog jezika za modelovanje u objektno-orijentisanom razvoju softvera.

Ovaj model se zasniva na 3 osnovna principa - osnovu ĉine dijagrami sluĉajeva korišćenja, u centru

modela se nalazi njegova arhitektura koja sazreva sa razvojem novih dijagrama korisnika i razvija se

kroz iteracije koje donose nove inkremente konaĉnog proizvoda. Suštinski posmatrano, u svakoj od iteracija odvijaju se analiza, projektovanje, implementacija i testiranje proizvoda.

Prema autorima, model se može opisati kao proces klasificiranja iteracija, koje se mogu podeliti u 4 grupe:

u prvoj grupi se nalaze početne iteracije interakcija sa stekholderima, tj. znaĉajnim

uĉesnicima u razvoju softvera, drugu grupu saĉinjavaju razranene iteracije želja i potreba korisnika,

iteracije konstruisanja inicijalnih operacionih mogućnosti saĉinjavaju treću grupu i prelazne iteracije kompletiranja proizvoda su ĉetvrta, konaĉna iteracija razvoja softvera

prema ovom modelu.

Iterativni razvoj takoĊe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se

potpun sistem isporuĉuje u svim verzijama, s tim što se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledeća verzija unapreĊuje prethodnu.

Page 13: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

13

Ilustracija 9. Model unificiranog procesa

3.8. Agilni modeli razvoja

Agilne metode (Agile Alliance, 2001.) su nastale kao otpor mnogim ranijim modelima

razvojnog procesa koji su pokušavali da nametnu neki oblik discipline vezane za osmišljavanje softvera, dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga fleksibilnosti u spretnom

brzom razvoju softvera. Ĉesta kašnjenja projekata razvoja softvera, probijanje budžeta i postavljenih vremenskih

rokova u njihovoj realizaciji, 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 softvera.

Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme i troškove razmene informacija izmenu 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 menusobnoj komunikaciji se

poklanja posebna pažnja. Usmerenost na uĉesnike je i najznaĉajnija osobina agilnih modela, prema pojedincima se prilagonava i kompletan proces razvoja.

Ilustracija 10. 4 principa agilnog razvoja

Page 14: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

14

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 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 zajedniĉki cilj, uzajamno poverenje i poštovanje, zajedniĉki i brz postupak donošenja odluka i sposobnost savladavanja svih dvosmislenosti.

Ilustracija 11. Model agilnog razvoja softvera

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 obezbenenje 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 menuzavisnosti.

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. Takone, 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 ekstremnim, kompleksnim i visoko- promenljivim projektima.

Okruženje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na ljude i saradnju.

3.9. Kombinovani modeli

Napred opisani modeli su uglavnom prikazivani kao alternativni, a manje kao komplementarni

modeli softverskog inženjeringa. MeĊutim, 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, ali i drugi modeli mogu poslužiti kao osnova na koju će se integrisati neki modeli.

Page 15: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

15

Ilustracija 12. Kombinovani model

Ne treba biti dogmatiĉan u izboru odrenenog modela u softverskom inženjeringu. 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.

3.10. Extreme programming (XP)

Ekstremno programiranje, XP (eXtreme Programming), (Beck, 1999.) predstavlja skup

tehnika za omogućavanje kreativnosti projektnog tima uz minimizovanje prekomernog administriranja.

Zasnovana je na jednostavnosti, komunikaciji, feedbacku i hrabrosti. Timovi koriste jednostavnu formu planiranja i praćenja kako bi odluĉili šta sledeće da rade.

Timovi kreiraju softver u seriji malih, potpuno integrisanih izdanja koja su prošla sve testove

koje je korisnik definisao.

Faze koje prate Ekstremno programiranje su: Planiranje

Identifikuju se korisniĉki zahtevi.

Planiranjem verzijakreira seraspored verzija. Ĉesto se pravemala izdanja.

Projekt je podeljen uiteracije. Planiranje iteracijezapoĉinje svaku iteraciju.

Upravljanje Daje timu lokalniotvoreni radni prostor.

OdreĊuje održiv korak.

Svaki dan zapoĉinjepoĉetnim sastankom. Prati sebrzina projekta.

Ljudi se razmeštaju. Popravljase XPkada doĊe do problema.

Dizajniranje

Jednostavnost.KorišćenjeCRC karticaza dizajn sesija. Kreiranjeklinastih rešenjada bi se smanjio rizik.

Funkcionalnosti se ne dodaju u ranim fazama. Ponovno planiranjekada god i gde god je potrebno.

Page 16: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

16

Kodiranje

Korisnik je uvek dostupan.

Kod se mora pisati tako da bude u skladu sa standardima. Kodira se test jedinice prvo.

Sav produktivni kod je programiran u paru.S amo jedan parintegriše kod u jednom trenutku.

Ĉeste integracije.

OdreĊen je raĉunar za integraciju.Postojikolektivno vlasništvo. Testiranje

Sav kod mora imatitestove jedinica. Sav kod mora proći sve testove jedinicapre nego što se može staviti u upotrebu.

Kadase pronaĊe bagkreiraju se testovi. Testovi prihvatljivostise ĉesto izvršavaju a rezultati se objavljuju.

Ilustracija 13. Extremno programiranje

Alati i tehnike za modelovanje Izbor alata i tehnika za modelovanje zavisi od sadržaja modela. Postoje razliĉite vrste notacija koje se

mogu koristiti:

tekstualne, u kojima se procesi iskazuju kao funkcije, grafiĉke, u kojima se procesi prikazuju u formi hijerarhije pravougaonika i strelica,

kombinovane, koje kombinuju slike, tekst i grafiĉki prikaz sa tabelama.

Page 17: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

17

ZAKLJUČAK

Pregled i evaluacija softverskog projekta

Ilustracija 14. Pregled i evaluacija softverskog procesa

U kritiĉnim taĉakama projekta, procenjuje se sveukupni napredak ka postizanju zacrtanih

ciljeva i zadovoljavanje zahteva zainteresovanih strana. Sliĉno tome, procenjuje se delotvornost

celokupnog procesa do zacrtanog datuma, ukljuĉenog osoblja kao i alata i metoda koje se preduzimaju tokom razvoja.

UtvrĎivanje ispunjenja zahteva

S obzirom da je ispunjenje oĉekivanja i zadovoljstvo naruĉioca jedan od glavnih ciljeva, važno je da se napredak ka ovom cilju stalno procenjuje i uvažava. To se naroĉito pojavljuje pri realizaciji

bitnih taĉaka u razvoju projekta (na primer, prihvatanje arhitekture softverskog dizajna, tehniĉki

pregled softverske integracije).

Pri Identifikaciji odstupanja od oĉekivanja, preduzimaju se odgovarajuće akcije. Kao i u aktivnostima procesa kontrole (videti prethodnu lekciju), u svim sluĉajevima promene kontrole i procedure

upravljanja softverskom konfiguracijom se takoĊe poštuju (opširnije u kursu „Upravljanje softevrskom

Page 18: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

18

konfiguracijom“). Odluke se dokumentuju i dostavljaju svim relevantnim stranama, planovi se ponovo

pregledaju i vrše izmene gde je to potrebno, a relevantni podaci se upisuju u centralnoj bazi projekta.

Ispunjenje zahteva naruĉioca vrši se i testovima razliĉitog tipa kojima se potvrĊuje usaglašenost sa

postavljenim zahtevima. Preporuĉuje se uspostavljanje testova i test sluĉajeva na samom poĉetku razvoja ĉime se uz svaki ustanovljen zahtev veže i pripadajući test. To je naĉin kojim se osigurava i

proverljivost svih postavljenih zahteva. Više informacija o testiranju može se pronaći u kursu

„Softversko testiranje“.[6]

Razmatranje i vrednovanje performansi

Periodiĉni pregledi performansi, za osoblje koje radi na projektu pružaju uvid u pridržavanje

plana kao i vidljivost mogućih problematiĉnih oblasti (na primer, konflikt ĉlanova tima). Razliĉite metode, alati i primenjene tehnike se evaluiraju u cilju povećanja njihove efektivnosti i prikladnosti, a

proces se sistemski i periodiĉno ocenjuje u pogledu svoje relevantnosti, korisnosti i delotvornosti u projektnom kontekstu. Gde je to primereno, vrše se promene i njihova organizacija.[1]

Zaključenje projekta

Projekat se zakljuĉuje kad se svi planovi i pripadajući procesi odobre i završe. U ovoj fazi,

kriterijui za uspeh projekta se ponovo pregledaju. Kada se projekat jednom zakljuĉi, arhivira se i dokumentuje radi analiza, slede i aktivnosti unapreĊenja procesa.

UtvrĎivanje zaključivanja projekta

Parametri za zakljuĉivanje projekta utvrĊuju se na osnovu kompletiranja zadataka prema specifikaciji u planu i potvrde uspešnog postignuća kriterijuma kompletnosti. Svi planirani proizvodi se

isporuĉuju sa prihvatljivim karakteristikama. Zahtevi se proveravaju, potvrĊuje se njihovo ispunjenje u pogledu zadovoljavanja planiranog i ostvarivanja cilja projekta. Ovi procesi generalno ukljuĉuju sve

zainteresovane strane i rezultuju u dokumentovanju klijentovog prihvatanja i izveštavanju o bilo kom

preostalom problemu [6].

Aktivnosti pri zaključivanju

Nakon što je zatvaranje projekta potvrĎeno, arhivski materijal projekta se

dostavlja i uporeĎuje zajedno sa dokumentacijom zainteresovanih strana o dogovorenim metodama, alokaciji i trajanju. Organizaciona baza podataka merenja i vrednovanja se ažurira sa

finalnim podacima projekta uz sprovoĊenje post-projektne analize. Post-projektna analiza se sprovodi kako bi se analizirala pitanja i problemi koji su se javili tokom procesa razvoja (naroĉito kroz proveru i

ocenjivanje) i pronašle bolje mogućnosti tokom rada na procesu. „Nauĉene lekcije”, odnosno, izvedeni

zakljuĉci iz datog procesa se beleže i pohranjuju u bazu organizacionog sektora kako bi se kasnije mogle upotrebiti za poboljšanje rada i u drugim procesima.

Merenje softverskog inženjerstva

Važnost merenja i njegove uloge u boljim praksama menadžmenta je široko prepoznata i njegova važnost će samo i dalje rasti u narednim godinama. Efikasno merenje je postalo jedan od

kamena temeljaca organizacione zrelosti.

Kljuĉni termini metoda softverskih merenja i vrednovanja definisani su u standardu ISO15939-02 na

osnovu ISO internacionalnog reĉnika metrologije. I pored toga, u literaturi se može pronaći više razliĉitih oznaĉavanja.

Page 19: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

19

Ovde sledimo internacionalni standard ISO/IEC 15939 koji opisuje proces za definisanje aktivnosti i

zadataka neophodnih radi implementacije softverskog merenja i ukljuĉuje informacioni model

merenja.

Uspostavljanje i održavanje posvećenosti merenju

Prihvatanje zahteva za merenja - Svaki rad na merenju treba da bude voĊen pod organizacionim

ciljevima i sproveden pomoću skupa mernih zahteva utvrĊenih na osnovu organizacije i projekta. Na primer, organizacioni cilj može da bude “biti prvi na tržištu s novim proizvodom”[2]. To sa druge

strane može izazvati zahteve za merenjem onih faktora koji doprinose tom cilju kako bi projekat ispunio zadati cilj.

Definisanje opsega merenja - Mora se uspostaviti organizaciona jedinica na koju se primenjuje svaki zahtev za merenjem. Ona se može sastojati od funkcionalne oblasti, jednog projekta ili ĉak

celokupnog preduzeća. Svi naknadni poslovi merenja koji se odnose na ovaj zahtev trebalo bi da budu unutar definisanog opsega. TakoĊe, trebalo bi da se identifikuju i sve zainteresovane strane u

projektu.

Privrženost menadžmenta i ostalog osoblja merenju - Zalaganje mora da bude formalno

uspostavljeno, kroz dobru komunikaciju izmeĊu svih uĉesnika i podržano resursima.

UtvrĊivanje resursa za merenja - Organizaciona opredeljenost ka merenju je suštinski faktor za uspeh,

a to se pokazuje pri rasporeĊivanju sredstava za izvoĊenje procesa merenja. Raspodela resursa ukljuĉuje raspodelu odgovornosti za razliĉite zadatke mernog procesa (npr. korisniku, analitiĉaru i

bibliotekaru) te pružanje dovoljno sredstava, obuku, alate i podršku za sprovoĊenje procesa u trajnu aktivnost.

Planiranje procesa merenja

Karakterizacija organizacionih jedinica - Organizacione jedinice obezbeĊuju kontekst za merenja, tako

da je važno da taj kontekst pruža eksplicitne i jasne pretpostavke koje se temelje u okviru konteksta i ograniĉenja koja se nameću. Karakterizacija može biti u pogledu organizacionih procesa, domena

aplikacije, tehnologije i organizacionog interfejsa.

Identifikacija potrebnih informacija - Potrebe za informacijama se zasnivaju na ciljevima,

ograniĉenjima, rizicima i problemima. One mogu da budu izvedene iz poslovnih, organizacionih, regulatornih i proizvodnih ciljeva. Informacije moraju da budu identifikovane kao prioriteti. Zatim,

obraĊuje se oznaĉeni podskup, rezultati se dokumentuju i vrši se neophodna komunikacija i pregled od strane zainteresovanih strana [3].

Izbor merenja - Potrebna merenja moraju da budu odabrana, sa jasnim vezama ka potrebnim informacijama. Merenja dalje moraju biti odabrana na temelju prioriteta potrebnih informacija i drugih

kriterijuma kao što su troškovi prikupljanja, stepen ometanja procesa tokom prikupljanja, jednostavnosti analize, lakoće dobijanja taĉnih rezultata itd. [ISO15939-02: 5.2.3].

Definisanje naĉina prikupljanja podataka, analize i procedura izveštavanja - To obuhvata skup postupaka i rasporeda, skladištenja, verifikacije, analize, izvještaje i podatake za upravljanje

konfiguracijom [ISO15939-02: 5.2.4].

Pregled, odobravanje i obezbeĊivanje sredstva za zadatke merenja - Plan merenja mora biti pregledan

i odobren od strane predstavnika zainteresovanih strana. To ukljuĉuje sve postupke prikupljanja podataka, skladištenje, analize i procedure izveštavanja, kriterijume vrednovanja, rasporede i

odgovornosti. Kriterijumi za pregled ovih artefakata treba da budu uspostavljeni na nivou organizacione jedinice ili na višem novou, i trebalo bi da se koriste kao osnova za te preglede. Takav

kriterijum treba da uzme u obzir prethodna iskustva, dostupnost resursa kao i potencijalne probleme

na projektu kada dolazi do promena predloženih postupaka. [ISO15939-02: 5.2.6.1].

Page 20: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

20

Resursi treba da budu na raspolaganju za implementaciju planiranih i odobrenih zadataka merenja.

Posebnu pažnju treba posvetiti prilikom dodeljivanja resursa za uspešnu implementaciju novih

postupaka ili merenja [ISO15939-02: 5.2.6.2].

Dobijanje i implementacija prateće tehnologije - Ukljuĉuje procenu raspoloživosti prateće tehnologije, izbor najprikladnijih tehnologija, nabavka tih tehnologija i njihovu implementaciju [ISO 15939-02:

5.2.7].

SprovoĎenje procesa merenja

Integracija procedura merenja sa relevantnim procesima - Procedure merenja, kao što su prikupljanje

podataka, moraju biti integrisane u procese koji se mere i vrednuju. Ovo može ukljuĉivati i promenu

tekućeg procesa radi prilagoĊavanja ovim aktivnostima. Moralna pitanja i ostala pitanja ljudskih resursa takoĊe moraju biti razmatrena u cilju uspešne primene procedura merenja. Podrška i obuka

takoĊe treba da budu obezbeĊeni. Analiza podataka i procedure izveštavanja moraju biti integrisane u organizacione procese.

Prikupljanje podataka - Svi podaci moraju biti prikupljeni, verifikovani i na pravilan naĉin skladišteni .

Analiza podataka - Podaci mogu biti objedinjeni ili preureĊeni kao rezultat procesa analize, koristeći odreĊen stepen rigidnosti, prikladan prirodi obraĊivanih podataka i potrebnih informacija. Rezultati

analize su predstavljeni svim zainteresovanim uĉesnicima najĉešće grafiĉki, brojĉano ili nekim drugim

naĉinom prikladno izabranim za prikaz podataka koji su predmet obrade. Rezultati i zakljuĉci moraju biti pregledani, koristeći procese uspostavljene u organizaciji. Uĉesnici u procesu merenja treba da

uĉestvuju u pregledu i analizi podataka radi osiguranja njihovog znaĉenja i taĉnosti. Na osnovu analize preduzimaju se logiĉne akcije. [3]

Evaluacija merenja

Evaluacija procesa merenja - Proces merenja treba evaluirati i raditi poreĊenja procesa merenja prema specifiĉnim evaluacionim kriterijumima. TakoĊe se merenjem procesa odreĊuju i dobre i loše

strane procesa. Ovo može biti izvedeno internim procesima ili eksternim revizijama i treba da ukljuĉi

povratnu spregu od osoblja na merenjima. Prema standardu ISO/IEC 15939 [3] preporuĉuje se snimanje iskustava u odgovarajućoj bazi podataka.

Identifikacija potencijalnih poboljšanja - Takva poboljšanja mogu biti promene u formi indikatora,

promene u jedinici merenja ili ponovne klasifikacije kategorija merenja. Treba utvrditi troškove i

prednosti potencijalnih poboljšanja i izabrati odgovarajuće akcije poboljšanja. Preporuĉljivo je diskutovati o predloženim poboljšanjima u procesu merenja u krugu svih zainteresovanih strana radi

pregleda i prihvatanja i razgovarati o nedostatku potencijalnih poboljšanja, ako analiza ne uspe da identifikuje unapreĊenja.

Page 21: Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

21

Reference:

1. M. Dorfman and R.H. Thayer, eds., Software Engineering, IEEE Computer Society Press, 2002. 2. N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, second ed.,

International Thomson Computer Press, 1998. 3. ISO/IEC 15939:2002, Software Engineering “Software Measurement Process”, ISO and IEC,

2002. 4. S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice Hall, 2001. 5. R.S. Pressman, Software Engineering: A Practitioner's Approach, sixth ed., McGraw-Hill, 2004. 6. D.J. Reifer, ed., Software Management, IEEE Computer Society Press, 2002. 7. I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005. 8. R.H. Thayer, ed., Software Engineering Project Management, IEEE Computer Society Press,

1997. 9. Dragica Radosav, Softversko inzenjerstvo,tehnicki fakulete Ćmihajlo PupinĆ, Yrenjanin 2008.