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.
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
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.
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.
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:
I nkrementalni model,
RAD model,
Razvojni modeli:
Model prototipskog razvoja,
Spiralni model,
Istovremeni model razvoja (Concurrent Development)
Specijalizovani modeli:
M odel 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
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.
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.
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
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
r ealni 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,
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
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.
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.
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
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.
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.
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.
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
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.
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].
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.
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.
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.
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
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.
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.
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:
I nkrementalni model,
RAD model,
Razvojni modeli:
Model prototipskog razvoja,
Spiralni model,
Istovremeni model razvoja (Concurrent Development)
Specijalizovani modeli:
M odel 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
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.
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.
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
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
r ealni 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,
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
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.
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.
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
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.
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.
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.
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
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.
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].
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.
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.
No comments:
Post a Comment