of 21 /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

Text of Modeli Softverskog Procesa Razvoja- Softversko inzenjerstvo, Tatjana Dimitrijevic

  • 1. INTERNACIONALI UNIVERZITET U NOVOM PAZARU FAKULTET ZA INFORMATIKU I INFORMACIONE TEHNOLOGIJE SEMINARSKI RAD Predmet: Softversko inenjerstvo Tema: Modeli softverskog procesa Mentor: Student: prof. dr.Mirsad Nikovi Tatjana Dimitrijevi br.ind 2296 / 06 Panevo, Mart 2010. god. 1
  • 2. SADRAJ Uvod 1 1. Softverski proizvod 3 2. Principi i modeli razvoja softvera 3 3. Najei 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. Zakljuak Pregled i evaluacija softverskog projekta 15 2
  • 3. UVOD Softversko inenjerstvo je raunarska disciplina koja se bavi razvojem sloenih aplikacija. Ono se bavi ne samo tehnikim aspektima izgradnje softverskog sistema, ve i manaderskim problemima poput organizacije programerskog tima, terminskim planiranjem, finansijama (http://www.webopedia.com) Softversko inenjerstvo je inenjerska disciplina koja vodi brigu o svim aspektima proizvodnje softvera od specifikacije sistema do implementacije sistema i odravanja (Sommerville, 2001.). Moemo prometiti da se javljaju dva kljuna pojma: Inenjerska disciplina: Inenjeri ine da proizvod radi. Oni primenjuju teoriju, metode i alate, ali to ine selektivno, uvek pokuavajda nau to bolje rjeenje za odreene probleme. Ogranieni su finansijskim i organizacijskim ogranienjima. Svi aspekti proizvodnje softvera: Softverski inenjeri brinu ne samo o tehnikim aspektimaspektima procesa razvoja softvera, ve i o upravljanju softverskim projektom, kvaliteti proizvoda i dr. Ilustracija 1. ivotni ciklus razvoja softvera Softversko inenjerstvo je projektovanje, razvoj, dokumentacije i odravanja softvera primjenjujuitehnologije i prakse iz vie disciplina, ukljuujui raunarsku nauku, upravljanje projektima, inenjering, dizajn interfejsa, integraciju u produja promene itd. Softversko inenjerstvo obuhvata vana podruja kao to su: voenje poslovanja i IT, razvoj softverskih metodoligija i okvira, trokovi razvoja trajanje razvoja, rizici u razvoju softvera, ugraivanje kvaliteta razmiljanje u procesu razvoja softvera, testiranje, upravljanje razvojnih timova, project management, projekt izvjetavanje, projekt brzine razvoja projekta, komunikacija svih uesnika. 3
  • 4. 1. Softverski proizvod Softverski proizvod (aplikacija) stvoren po principima softverskog inenjerstva moe biti razvijen kao: Generiki proizvod (fleksibilan, slobodno oblikovan, razvijen od proizvoaa softvera, ponuen na tritu bilo kojem kupcu), Narueni proizvod (izraen prema dogovorenim zahtevima, strogo determiniran, namenjen i isporuen konkretnom odreenom kupcu). Temeljni cilj softverskog inenjerstva ogleda se u tenji da se stvori visoko kvalitetan softverski proizvod u dogovorenom roku i uz to manje trokove. U skladu s izreenim ciljem mogue je prepoznati tri kljune kategorije u procesu razvoja softverskog proizvoda : Isporuka softvera u dogovorenom roku, Trokovi razvoja softvera u dogovorenim okvirima, Zadovoljavajui kvalitet softvera. Za razvoj softvera karakteristine su odreene temeljne aktivnosti: Specifikacija potreba (identifikacija, transformacija potreba u zahteve, analiza, odreivanje prioriteta ) Dizajniranje problema (oblikovanje problema grafikom notacijom, oblikovanje procesa, analiza ) Implementacija (kodiranje, testiranje, uvoenje u rad, dokumentiranje, edukacija ) Validacija (testiranje softverskog sistema, procena kvaliteta ) Evolucija (odravanje sistema, reinenjering ) Softverski proces (ili ivotni ciklus softvera) je skup administrativnih i tehnikih aktivnosti koje se realizuju u toku prikupljanja, razvoja, odravanja i povlaenja 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 inenjering ine skupovi koraka koji ukljuuju metode, alate i procedure. Ti koraci su zasnovani na razvojnim principima i upuuju na modele razvoja softvera u softverskom inenjeringu. Model razvoja se odabira u zavisnosti od prirode projekta i aplikacije, tehnike orijentacije ljudi koji e uestvovati u razvoju, metoda i alata koji e se upotrebljavati pri razvoju, naina kontrole i samih proizvoda koji se zahtevaju. Razvojni principi su takvi opte vaei osnovni principi koji odreuju nain izvrenja rada i omoguuju uoptavanje odreenih specifinosti i zakonitosti objektivne stvarnosti. Oni mogu biti osnovni principi naina izvrenja rada i principi razvoja s obzirom na metodoloke korake i redosled njihovog izvrenja. Osnovni principi naina izvrenja rada su: princip modelovanja, princip iteracija, princip simulacije, princip dokumentovanja. To su opte poznati i prihvaeni principi u razliitim podrujima, koji se samo i u razvoju softvera primenjuju. Principi razvoja obzirom na metodoloke korake se menusobno razlikuju po tome koliki znaaj pridaju pojedinim fazama u razvoju softvera, koliko ih detaljno posmatraju i u kojem redosledu izvravaju. 4
  • 5. Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki softverski sistemi i prikazuju razliite poglede na proces razvoja softvera. Osnovni razlog njihove pojave je bila elja da se obezbedi uoptena ema razvoja softvera, koja bi sluila kao osnova u planiranju, organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju aktivnostima razvoja softvera. Modeli su apstrakcije koje pomau u procesu razvoja softvera. Model softvera predstavlja komponente razvoja softvera i razvijen je na osnovu ideja konstruktora i njegove predstavke ta je najznaajnije u tom razvoju. Model moe predstavljati: model procesa razvoja, model softvera ili model naina upravljanja softverom. Primarni cilj kreiranja modela je da se obezbede softverski proizvodi koji odgovaraju zahtevima korisnika. U zavisnosti od znaaja 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 delimino razliitim tokom procesa razvoja ali sa istim generikim 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. Naei modeli razvoja softvera 3.1. Model vodopada Model vodopada je uveo W. Royce 1970. godine. Prema njemu razvoj softvera zahteva sistematian pristup, jer se odvija po strogo definisanom sekvencijalnom redosledu koraka, postepenim prevoenjem rezultata od prve do poslednje faze razvoja softvera. Razvoj zapoinje na sistemskom nivou da bi se nastavio preko analize, projektovanja, kodiranja, testiranja i zavrio odravanjem. Faze i aktivnosti razvoja prema ovom modelu su sledee: Analiza i definisanje zahteva sistema - Obzirom da softver predstavlja samo deo nekog sistema, rad na razvoju softvera zapoinje definisanjem zahteva prema svim elementima sistema i alociranjem jednog dela adekvatnih i odreenih zahteva prema softveru. Ovaj 5
  • 6. sistemski pogled je posebno znaajan 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 specifinih i posebnih zahteva softveru. Da bi softverski inenjer 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: korisniki interfejs, ulazne ekranske forme, izlaze, bazu podataka, procedure obrade i sistemsku kontrolu. Ova faza prevodi zahteve korisnika u odreeni softverski proizvod koji se moe oceniti sa aspekta kvaliteta pre nego to zapone kodiranje. Kao i zahtevi, rezultati projektovanja se dokumentuju i predstavljaju deo konfiguracije softvera. Kodiranje Ovom fazom se izvrava zadatak prevoenja rezultata projektovanja u mainski prepoznatljivu formu. Ukoliko je projektovanje uraeno dovoljno detaljno, tada se kodiranje obavlja mehaniki. Testiranje - Kada se jednom izgenerie kod programa, tada zapoinje njegovo testiranje. Testiranje se svodi na unutranju logiku softvera , sa ciljem da se svi iskazi provere odnosno da se proveri da li su isti tani. Takone, testiranje se svodi i na spoljnu funkciju softvera, da bi se otkrile greke i proverilo da li e definisani ulazi proizvesti rezultate koji se podudaraju sa identifikovanim zahtevima. Odravanje - Softver e sigurno pretrpeti odrenene izmene nakon to se distribuira korisniku. Potrebe za izmenama se javljaju zbog proirenja funkcija ili performansi koje zahteva korisnik, zbog potreba da se softver prilagoava promenama koje uzrokuje promenjeno okruenje ili zbog razvoja tehnologija koje se upotrebljavaju. Svaka od navedenih faza u modelu poseduje specifinosti, rezultira izvesnim proizvodom i omoguuje reviziju. Aktivnosti faze se izraavaju 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 sledeu aktivnost. U stvarnosti, razvoj nikad nije tako eksplicitno odreen. Uvek postoji povratna sprega izmeu 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 najvie i najire primenjivan do danas. Uspeno se kombinuje sa drugim modelima razvoja. 6
  • 7. Primena ovog modela se predlae u sledeim 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 jednoznano moe definisati svoje zamisli i potrebe u odnosu na softver, koji na toj bazi izgraen ne sadri suvine komponente i funkcionie veoma brzo i uspeno, postoji dovoljno vremena i strpljenja kod korisnika za dugi period razvoja i visoki razvojni trokovi i saobrazno potrebna finansijska sredstva nisu ograniavajui faktor razvoja. Slabost modela je nedostatak povratne sprege izmenu koraka koji nisu sukcesivni i ne odvijaju se u sekvencijalnom redosledu. Takoe, kao nedostaci se navode sledee 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 teko za korisnika da u poetku rada na razvoju softvera navede eksplicitno sve svoje zahteve (a to model zahteva), jer se teko prilagoava 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, greke koje se ne otklone u fazi testiranja programa, mogu imati stravino distorziono dejstvo na projekat razvoja. 3.2. Model V V model (nemako Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, inei 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 usredsreen na dokumente i meuproizvode. V model se koristi na sledei nain: Testiranje delova, testiranje sistema pri integraciji i testiranje sistema bave se ispravnou programa i mogu se koristiti za verifikovanje dizajna programa. Zavrni test slui za validaciju zahteva, tj. proveru da li su svi zahtevi potpuno implementirani. Ako se pronau problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela mogu se ponoviti radi popravke i poboljanja zahteva, dizajna ili koda, pre nego to se ponove testiranja na desnoj strani modela. 7
  • 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 takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu. Ilustracija 5. Iteracija Projektovanje softvera se izvodi u prvom koraku, ali se uvoenje softvera odvija sukcesivnom razradom (usavravanjem inicijalnog podskupa). Softver se razvija malim dodacima (inkrementima) kojima se moe jednostavno i lako upravljati. Svaki inkrement dodaje postojeem softveru pojedine nove funkcije, pri emu se postojee zadravaju. Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definiu kao funkcionalni podsistemi, tako da se svakoj novoj verziji prikljuuju nove funkcije. Sistem se nadograuje do potpune funkcionalnosti. Prednost ovakvog razvoja je u tome da se dodaci odnosno nove funkcije lake razumeju i testiraju. Korienje mogunosti da se stalno dodaju nove funkcionalnosti softverskom proizvodu, daje mogunost ugradnje bogatog korisnikog iskustva u redefinisani proizvod na manje skup nain. Ovaj model predstavlja kombinaciju klasinog modela ivotnog ciklusa softvera sa iterativnim mogunostima razvoja. On takone obezbenuje nain da se periodino distribuira auriranje i odravanje softvera razliitim korisnicima. Posebno je popularan i koriste ga u softverskim kuama. Ilustracija 6. Logaritam inkrementalnog modela 8
  • 9. 3.4. Model prototipskog razvoja Model prototipskog razvoja se koristi da bi se za potrebe korisnika razvio inicijalni model budueg softvera koji simulira njegove stvarne funkcije sa ciljem da korisnik da svoje miljenje i odlui koji i kakvi su njegovi zahtevi. Kod razvoja softvera po ovom modelu korisnik ve u najranijem stadijumu moe videti na koji e se nain zadovoljiti njegovi zahtevi. Komponente razvijenog softvera esto predstavljaju samo korisniki interfejs. Implementacija kostura ovog interfejsa je sa eljom da se obezbedi mogunost za povratnu spregu od korisnika, pre nego da se specificira i projektuje konana verzija reenja. Mada je razjanjenje korisnikog interfejsa jedan od ciljeva, prototip moe biti takoe iskorien kao koncept unutar konteksta drugog modela. U tom sluaju, drugi model moe posmatrati prototip kao jedan elemenat procesa, koji se koristi u razjanjenju ponaanja sistema u razliitim takama razvoja softvera. Model obino prihvata neku vrstu funkcionalne specifikacije softvera kao ulaz, koji se simulira, analizira i izvrava. Ova tehnologija omoguuje da aktivnosti projektovanja softvera budu inicijalno preskoene ili premotene. Takoe, omoguuje da se brzo izgrade primitivne verzije softvera, koje kasnije korisnik moe i sam razvijati. Korisniki razvoj je ukljuen u povratnu spregu za redefinisanje sistemskih specifikacija i dizajna. U zavisnosti od tehnologije prototipskog razvoja, ceo radni sistem moe biti razvijen kontinuiranim procesom obezbenuje radne verzije sistema koje razvija i to u veoj meri od drugih modela angauje korisnika na razvoju, te unaprenuje kvalitet procesa. ISPORUENI SISTEM Ilustracija 7. Model prototipskog razvoja Model prototipskog razvoja se najee upotrebljava i daje solidne rezultate u situacijama: kada su od strane korisnika samo uopteno definisani ciljevi razvoja softverskog proizvoda, ali ne i detalji u pogledu ulaza, procedura i izlaza, kada je mogue simulirati rad softvera da bi korisnik mogao videti kako e budui softverski proizvod funkcionisati i kada same razvojne organizacije ele proveriti efikasnost algoritama ili adaptibilnost sistema. Model uobiajeno moe imati tri oblika: prototip u obliku papira koji opisuje vezu oveka i maine na nain da korisniku omogui razumevanje tog odnosa, radni prototip koji implementira neke od funkcija postavljenih kao zahtevi softverskom proizvodu ili realni program koji izvrava deo ili celinu zahtevanih funkcija. Model prototipskog razvoja zapoinje prikupljanjem zahteva. Projektant i korisnik, zajedniki definiu opte ciljeve razvoja softverskog proizvoda, identifikuju sve njima poznate zahteve i odrenuju podruja 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 slui da bi se preistili zahtevi prema softveru koji se razvija. Preiavanje je iterativno i odvija se dok prototip ne zadovolji zahteve korisnika i istovremeno omogui projektantu potpuno razumevanje potreba koje mora zadovoljiti. Idealno, prototipski razvoj i slui kao mehanizam za identifikovanje zahteva prema softveru. Ukoliko se razvija radni prototip, 9
  • 10. korisniku se omoguuje da koristi delove softvera ili primenjuje alate koji brzo generiu radne verzije softvera. Ovaj model ima i svoje nedostatke odnosno primena modela prototipskog razvoja moe biti diskutabilna: Korisnik uoava radnu verziju softvera neznajui na koji su nain delovi softvera meusobno povezani, neznajui da u brzini realizacije nisu razmatrani aspekti kvaliteta ili odravanja u duem vremenskom periodu. Kada doe do informacija da je potrebno izvriti "remont" ili dalju dogradnju jo ne uvedenog softverskog proizvoda, korisnik se osea 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 izgraeni prototip to pre stavi u funkciju. Neadekvatan operativni sistem ili programski jezik se jednostavno upotrebljavaju samo zato to su raspoloivi ili poznati; neefikasan algoritam se primenjuje samo da bi se demonstrirala sposobnost softvera. Nakon izvesnog vremena, zaboravlja se na nain odabira i njihove uzroke, pa manje idealna reenja ili bolje reeno manje kvalitetna reenja ostaju integralni deo konanog softverskog reenja. Zbog toga, znaajno je da se projektant i korisnik, u cilju efikasnosti ovog modela, dogovore i definiu pravila igre na poetku procesa razvoja softvera. Drugim reima oni se moraju sloiti da se prototip razvija kao mehanizam za definisanje zahteva, a softver se razvija u cilju zadovoljenja kriterijuma kvaliteta i mogunosti odravanja. 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 ukljuivanje aktivnosti analize rizika. Model se predstavlja spiralom na kojoj su definisane etiri faze razvoja: planiranje faza koju ine aktivnosti odrenivanja ciljeva, alternativa i ogranienja, analiza rizika faza koju ine aktivnosti analize alternativa i identifikovanja rizika, inenjering faza razvoja novih nivoa proizvoda i razvoj i ocenjivanje faza procene rezultata inenjeringa. 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 izvrila analiza rizika inicijalnih zahteva. Ilustracija 8. Spiralni model 10
  • 11. Nakon to se donese odluka o daljem razvoju, obavlja se ininjering u svakom ciklusu spirale i to odabranim modelom razvoja softvera (model vodopada i-ili model prototipskog razvoja). Broj aktivnosti u inenjeringu raste, ukoliko se ciklusi udaljuju od centra spirale. Istovremeno, aktivnosti su sloenije i uvek sa mnogo manje apstrakcije. Po zavretku ininjerskog posla razvoja, korisnik ocenjuje i daje sugestije za modifikaciju softverskog proizvoda. Zasnovana na korisnikom inputu, javlja se sledea faza planiranja novog ciklusa razvoja i analize rizika. Svaki ciklus razvoja na spirali, zahteva analizu rizika i donoenje odluke "nastaviti" ili "ne nastaviti" sa daljim razvojem. Ukoliko je rizik isuvie velik i ulaganja nesrazmerno visoka u odnosu na efekte koji se oekuju, terminira se dalji rad i zadrava u upotrebi proizvod nastao u prethodnom ciklusu ili prethodnim ciklusima. Svaki novozapoeti ciklus spirale donosi kompletniji proizvod, ali i znaajnije i vie trokove. Tipina raspodela vremena, za koja ipak treba rei 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 zavrava ocenom. Model podrazumeva da se svaki deo proizvoda ili svaki nivo proizvoda na istovetan nain provlai kroz ovu spiralu odnosno ocenu. Osnovna premisa modela je da se odreeni redosled koraka ponavlja u razvoju i odravanju softvera. Model prilagonava svaku kombinaciju razliitih pristupa u razvoju softvera. Ovo je trenutno najrealniji pristup u razvoju softvera za velike sisteme. Model omoguuje brzu reakciju na uoene rizike, a primenom prototipskog razvoja prua mehanizam za njihovo smanjenje. I pored velikog broja prednosti, model poseduje i nedostatke. Nedostatak ovog modela je odsustvo veze prema postojeim standardima, odnosno ne postojanje standarda za ovaj nain razvoja softvera . Takoe, model zahteva vie uniformnosti i konzistentnosti u razvoju. Velike probleme stvara situacija kada se na vreme ili uopte ne otkriju rizici. Konano, 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 postojee komponente softvera u novi aplikativni sistem. Osobine komponenti zavise od njihove veliine, kompleksnosti i funkcionalnih mogunosti. Veina pristupa pokuava da iskoristi sline komponente obzirom na zajednike strukture podataka sa algoritmima za njihovu manipulaciju. Drugi pristupi pokuavaju da iskoriste komponente funkcionalno slinih kompletnih sistema ili podsistema kao to su korisniki interfejs. 11
  • 12. Viestruko korienje softvera je proces ukljuivanja u novi proizvod pojedinih komponenti: prethodno testiranog koda, prethodno proverenog dizajna, pretnodno razvijene i koriene specifikacije zahteva i prethodno korienih procedura za testiranje. Koristi koje sobom donosi ponovno korienje komponenti razvijenog softvera su sledee: podie robustnost softvera, poveava produktivnost izrade softvera, poveava kvalitet softvera, smanjuje trokove razvoja softvera, tedi odnosno skrauje vreme izrade, zadovoljava ciljeve softverskog inenjeringa, iri korienje softvera, obezbenuje adekvatnu dokumentaciju, olakava odravanje softvera, modelira sistem za lake 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 korienjem UML - objedinjenog jezika za modelovanje u objektno-orijentisanom razvoju softvera. Ovaj model se zasniva na 3 osnovna principa - osnovu ine dijagrami sluajeva korienja, u centru modela se nalazi njegova arhitektura koja sazreva sa razvojem novih dijagrama korisnika i razvija se kroz iteracije koje donose nove inkremente konanog proizvoda. Sutinski posmatrano, u svakoj od iteracija odvijaju se analiza, projektovanje, implementacija i testiranje proizvoda. Prema autorima, model se moe opisati kao proces klasificiranja iteracija, koje se mogu podeliti u 4 grupe: u prvoj grupi se nalaze poetne iteracije interakcija sa stekholderima, tj. znaajnim uesnicima u razvoju softvera, drugu grupu sainjavaju razranene iteracije elja i potreba korisnika, iteracije konstruisanja inicijalnih operacionih mogunosti sainjavaju treu grupu i prelazne iteracije kompletiranja proizvoda su etvrta, konana iteracija razvoja softvera prema ovom modelu. Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu. 12
  • 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 pokuavali da nametnu neki oblik discipline vezane za osmiljavanje softvera, dokumentovanje, razvoj i testiranje. Ideja je da se naglasi uloga fleksibilnosti u spretnom brzom razvoju softvera. esta kanjenja projekata razvoja softvera, probijanje budeta i postavljenih vremenskih rokova u njihovoj realizaciji, permanentni rast sloenosti tehnologije i uestale promene korisnikih zahteva, doveli su krajem dvadesetog veka do pojave novih modela razvoja. Nastali su agilni modeli, po osobinama mnogo gipkiji i prilagodljiviji promenama, koji omoguuju korisnicima aktivno uee tokom svih faza i aktivnosti razvoja. Agilni pristup se dakle suoio sa osnovnim problemom savremenog i ujedno brzog razvoja softvera. Dominantna ideja je da timovi mogu biti efikasniji u realizaciji promena ako su u stanju da smanje vreme i trokove razmene informacija izmenu osoba koje uestvuju u razvoju na nain da skrate vremenski period od donoenja odluke do povratne informacije o posledici te odluke. Polazne pretpostavke agilnih modela su bile da je turbulentnim poslovnim i tehnolokim okruenjima neophodan proces razvoja softvera koji istovremeno kreira promene, ali brzo i odgovara na iste. Istovremeno, proces koji ukljuuje odgovorne uesnike i njihovu dobru organizaciju. Uesnicima odnosno njihovom talentu, vetinama i sposobnostima, kao i njihovoj menusobnoj komunikaciji se poklanja posebna panja. Usmerenost na uesnike je i najznaajnija osobina agilnih modela, prema pojedincima se prilagonava i kompletan proces razvoja. Ilustracija 10. 4 principa agilnog razvoja 13
  • 14. U agilnim razvojnim timovima, kompetencije pojedinaca predstavljaju kritian faktor uspenosti projekta. Prema agilnim modelima, ukoliko su pojedinci na projektu dovoljno kvalitetni, tada oni mogu uz bilo koji proces razvoja realizovati oekivani cilj. U suprotnom, nema procesa razvoja koji moe nadomestiti njihovu nekompetentnost. Istovremeno, nedostatak korisnike podrke moe lako unititi projekat razvoja, kao to i neadekvatna podrka moe spreiti zavretak projekta. Agilni procesi istiu jedinstvene sposobnosti pojedinaca i tima. Naime, procesi ne mogu nadvladati nedostatak kompetencija pojedinaca. Timovi su samoorganizovani, sa intenzivnim komunikacijama u okviru i van organizacionih granica. Ovi timovi mogu u svakom trenutku promeniti svoju strukturu kako bi se prilagodili promenama. Agilnost podrazumeva da tim ima zajedniki cilj, uzajamno poverenje i potovanje, zajedniki i brz postupak donoenja odluka i sposobnost savladavanja svih dvosmislenosti. Ilustracija 11. Model agilnog razvoja softvera Agilan tim koji radi u okviru krute organizacije ima potekoa, kao to ih ima svaki pojedinac koji radi u krutom timu. U ovim timovima, dominira saradnja svih nivoa upravljanja. Za donoenje odluke nije vano ko donosi odluke, ve je vana saradnja i obezbenenje informacija za donoenje odluka. U projektu razvoja uestvuju osobe razliitih vetina, talenta i sposobnosti, koje rade u bliskom fizikom okruenju i potuju organizacionu kulturu. Osobe, okruenje i kultura su u strogoj 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 staloenim timovima, vodi sigurno raspadu tima. Takone, agilni razvoj se teko izvodi u timovima sa veim brojem lanova. Najvie uspeha u agilnom razvoju pokazuju timovi do devet lanova. Agilni razvoj se pokazao kao uspean u ekstremnim, kompleksnim i visoko- promenljivim projektima. Okruenje u kojem ovaj pristup daje najbolje rezultate je organizaciona kultura koja je orijentisana na ljude i saradnju. 3.9. Kombinovani modeli Napred opisani modeli su uglavnom prikazivani kao alternativni, a manje kao komplementarni modeli softverskog inenjeringa. Meutim, 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 posluiti kao osnova na koju e se integrisati neki modeli. 14
  • 15. Ilustracija 12. Kombinovani model Ne treba biti dogmatian u izboru odrenenog modela u softverskom inenjeringu. Priroda aplikacije e diktirati model koji bi trebalo primeniti. Kombinovanjem modela, rezultat postignut u celini moe 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 omoguavanje kreativnosti projektnog tima uz minimizovanje prekomernog administriranja. Zasnovana je na jednostavnosti, komunikaciji, feedbacku i hrabrosti. Timovi koriste jednostavnu formu planiranja i praenja kako bi odluili ta sledee da rade. Timovi kreiraju softver u seriji malih, potpuno integrisanih izdanja koja su prola sve testove koje je korisnik definisao. Faze koje prate Ekstremno programiranje su: Planiranje Identifikuju se korisniki zahtevi. Planiranjem verzijakreira seraspored verzija. esto se pravemala izdanja. Projekt je podeljen uiteracije. Planiranje iteracijezapoinje svaku iteraciju. Upravljanje Daje timu lokalniotvoreni radni prostor. Odreuje odriv korak. Svaki dan zapoinjepoetnim sastankom. Prati sebrzina projekta. Ljudi se razmetaju. Popravljase XPkada doe do problema. Dizajniranje Jednostavnost.KorienjeCRC karticaza dizajn sesija. Kreiranjeklinastih reenjada bi se smanjio rizik. Funkcionalnosti se ne dodaju u ranim fazama. Ponovno planiranjekada god i gde god je potrebno. 15
  • 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 parintegrie kod u jednom trenutku. este integracije. Odreen je raunar za integraciju.Postojikolektivno vlasnitvo. Testiranje Sav kod mora imatitestove jedinica. Sav kod mora proi sve testove jedinicapre nego to se moe staviti u upotrebu. Kadase pronae bagkreiraju se testovi. Testovi prihvatljivostise esto izvravaju a rezultati se objavljuju. Ilustracija 13. Extremno programiranje Alati i tehnike za modelovanje Izbor alata i tehnika za modelovanje zavisi od sadraja modela. Postoje razliite vrste notacija koje se mogu koristiti: tekstualne, u kojima se procesi iskazuju kao funkcije, grafike, u kojima se procesi prikazuju u formi hijerarhije pravougaonika i strelica, kombinovane, koje kombinuju slike, tekst i grafiki prikaz sa tabelama. 16
  • 17. ZAKLJUAK Pregled i evaluacija softverskog projekta Ilustracija 14. Pregled i evaluacija softverskog procesa U kritinim taakama projekta, procenjuje se sveukupni napredak ka postizanju zacrtanih ciljeva i zadovoljavanje zahteva zainteresovanih strana. Slino tome, procenjuje se delotvornost celokupnog procesa do zacrtanog datuma, ukljuenog osoblja kao i alata i metoda koje se preduzimaju tokom razvoja. Utvrivanje ispunjenja zahteva S obzirom da je ispunjenje oekivanja i zadovoljstvo naruioca jedan od glavnih ciljeva, vano je da se napredak ka ovom cilju stalno procenjuje i uvaava. To se naroito pojavljuje pri realizaciji bitnih taaka u razvoju projekta (na primer, prihvatanje arhitekture softverskog dizajna, tehniki pregled softverske integracije). Pri Identifikaciji odstupanja od oekivanja, preduzimaju se odgovarajue akcije. Kao i u aktivnostima procesa kontrole (videti prethodnu lekciju), u svim sluajevima promene kontrole i procedure upravljanja softverskom konfiguracijom se takoe potuju (opirnije u kursu Upravljanje softevrskom 17
  • 18. konfiguracijom). Odluke se dokumentuju i dostavljaju svim relevantnim stranama, planovi se ponovo pregledaju i vre izmene gde je to potrebno, a relevantni podaci se upisuju u centralnoj bazi projekta. Ispunjenje zahteva naruioca vri se i testovima razliitog tipa kojima se potvruje usaglaenost sa postavljenim zahtevima. Preporuuje se uspostavljanje testova i test sluajeva na samom poetku razvoja ime se uz svaki ustanovljen zahtev vee i pripadajui test. To je nain kojim se osigurava i proverljivost svih postavljenih zahteva. Vie informacija o testiranju moe se pronai u kursu Softversko testiranje.[6] Razmatranje i vrednovanje performansi Periodini pregledi performansi, za osoblje koje radi na projektu pruaju uvid u pridravanje plana kao i vidljivost moguih problematinih oblasti (na primer, konflikt lanova tima). Razliite metode, alati i primenjene tehnike se evaluiraju u cilju poveanja njihove efektivnosti i prikladnosti, a proces se sistemski i periodino ocenjuje u pogledu svoje relevantnosti, korisnosti i delotvornosti u projektnom kontekstu. Gde je to primereno, vre se promene i njihova organizacija.[1] Zakljuenje projekta Projekat se zakljuuje kad se svi planovi i pripadajui procesi odobre i zavre. U ovoj fazi, kriterijui za uspeh projekta se ponovo pregledaju. Kada se projekat jednom zakljui, arhivira se i dokumentuje radi analiza, slede i aktivnosti unapreenja procesa. Utvrivanje zakljuivanja projekta Parametri za zakljuivanje projekta utvruju se na osnovu kompletiranja zadataka prema specifikaciji u planu i potvrde uspenog postignua kriterijuma kompletnosti. Svi planirani proizvodi se isporuuju sa prihvatljivim karakteristikama. Zahtevi se proveravaju, potvruje se njihovo ispunjenje u pogledu zadovoljavanja planiranog i ostvarivanja cilja projekta. Ovi procesi generalno ukljuuju sve zainteresovane strane i rezultuju u dokumentovanju klijentovog prihvatanja i izvetavanju o bilo kom preostalom problemu [6]. Aktivnosti pri zakljuivanju Nakon to je zatvaranje projekta potvreno, arhivski materijal projekta se dostavlja i uporeuje zajedno sa dokumentacijom zainteresovanih strana o dogovorenim metodama, alokaciji i trajanju. Organizaciona baza podataka merenja i vrednovanja se aurira sa finalnim podacima projekta uz sprovoenje post-projektne analize. Post-projektna analiza se sprovodi kako bi se analizirala pitanja i problemi koji su se javili tokom procesa razvoja (naroito kroz proveru i ocenjivanje) i pronale bolje mogunosti tokom rada na procesu. Nauene lekcije, odnosno, izvedeni zakljuci iz datog procesa se belee i pohranjuju u bazu organizacionog sektora kako bi se kasnije mogle upotrebiti za poboljanje rada i u drugim procesima. Merenje softverskog inenjerstva Vanost merenja i njegove uloge u boljim praksama menadmenta je iroko prepoznata i njegova vanost e samo i dalje rasti u narednim godinama. Efikasno merenje je postalo jedan od kamena temeljaca organizacione zrelosti. Kljuni termini metoda softverskih merenja i vrednovanja definisani su u standardu ISO15939-02 na osnovu ISO internacionalnog renika metrologije. I pored toga, u literaturi se moe pronai vie razliitih oznaavanja. 18
  • 19. Ovde sledimo internacionalni standard ISO/IEC 15939 koji opisuje proces za definisanje aktivnosti i zadataka neophodnih radi implementacije softverskog merenja i ukljuuje informacioni model merenja. Uspostavljanje i odravanje posveenosti merenju Prihvatanje zahteva za merenja - Svaki rad na merenju treba da bude voen pod organizacionim ciljevima i sproveden pomou skupa mernih zahteva utvrenih na osnovu organizacije i projekta. Na primer, organizacioni cilj moe da bude biti prvi na tritu s novim proizvodom[2]. To sa druge strane moe 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 moe sastojati od funkcionalne oblasti, jednog projekta ili ak celokupnog preduzea. Svi naknadni poslovi merenja koji se odnose na ovaj zahtev trebalo bi da budu unutar definisanog opsega. Takoe, trebalo bi da se identifikuju i sve zainteresovane strane u projektu. Privrenost menadmenta i ostalog osoblja merenju - Zalaganje mora da bude formalno uspostavljeno, kroz dobru komunikaciju izmeu svih uesnika i podrano resursima. Utvrivanje resursa za merenja - Organizaciona opredeljenost ka merenju je sutinski faktor za uspeh, a to se pokazuje pri rasporeivanju sredstava za izvoenje procesa merenja. Raspodela resursa ukljuuje raspodelu odgovornosti za razliite zadatke mernog procesa (npr. korisniku, analitiaru i bibliotekaru) te pruanje dovoljno sredstava, obuku, alate i podrku za sprovoenje procesa u trajnu aktivnost. Planiranje procesa merenja Karakterizacija organizacionih jedinica - Organizacione jedinice obezbeuju kontekst za merenja, tako da je vano da taj kontekst prua eksplicitne i jasne pretpostavke koje se temelje u okviru konteksta i ogranienja koja se nameu. Karakterizacija moe biti u pogledu organizacionih procesa, domena aplikacije, tehnologije i organizacionog interfejsa. Identifikacija potrebnih informacija - Potrebe za informacijama se zasnivaju na ciljevima, ogranienjima, rizicima i problemima. One mogu da budu izvedene iz poslovnih, organizacionih, regulatornih i proizvodnih ciljeva. Informacije moraju da budu identifikovane kao prioriteti. Zatim, obrauje se oznaeni podskup, rezultati se dokumentuju i vri 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 trokovi prikupljanja, stepen ometanja procesa tokom prikupljanja, jednostavnosti analize, lakoe dobijanja tanih rezultata itd. [ISO15939-02: 5.2.3]. Definisanje naina prikupljanja podataka, analize i procedura izvetavanja - To obuhvata skup postupaka i rasporeda, skladitenja, verifikacije, analize, izvjetaje i podatake za upravljanje konfiguracijom [ISO15939-02: 5.2.4]. Pregled, odobravanje i obezbeivanje sredstva za zadatke merenja - Plan merenja mora biti pregledan i odobren od strane predstavnika zainteresovanih strana. To ukljuuje sve postupke prikupljanja podataka, skladitenje, analize i procedure izvetavanja, kriterijume vrednovanja, rasporede i odgovornosti. Kriterijumi za pregled ovih artefakata treba da budu uspostavljeni na nivou organizacione jedinice ili na viem 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 predloenih postupaka. [ISO15939-02: 5.2.6.1]. 19
  • 20. Resursi treba da budu na raspolaganju za implementaciju planiranih i odobrenih zadataka merenja. Posebnu panju treba posvetiti prilikom dodeljivanja resursa za uspenu implementaciju novih postupaka ili merenja [ISO15939-02: 5.2.6.2]. Dobijanje i implementacija pratee tehnologije - Ukljuuje procenu raspoloivosti pratee tehnologije, izbor najprikladnijih tehnologija, nabavka tih tehnologija i njihovu implementaciju [ISO 15939-02: 5.2.7]. Sprovoenje 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 moe ukljuivati i promenu tekueg procesa radi prilagoavanja ovim aktivnostima. Moralna pitanja i ostala pitanja ljudskih resursa takoe moraju biti razmatrena u cilju uspene primene procedura merenja. Podrka i obuka takoe treba da budu obezbeeni. Analiza podataka i procedure izvetavanja moraju biti integrisane u organizacione procese. Prikupljanje podataka - Svi podaci moraju biti prikupljeni, verifikovani i na pravilan nain skladiteni . Analiza podataka - Podaci mogu biti objedinjeni ili preureeni kao rezultat procesa analize, koristei odreen stepen rigidnosti, prikladan prirodi obraivanih podataka i potrebnih informacija. Rezultati analize su predstavljeni svim zainteresovanim uesnicima najee grafiki, brojano ili nekim drugim nainom prikladno izabranim za prikaz podataka koji su predmet obrade. Rezultati i zakljuci moraju biti pregledani, koristei procese uspostavljene u organizaciji. Uesnici u procesu merenja treba da uestvuju u pregledu i analizi podataka radi osiguranja njihovog znaenja i tanosti. Na osnovu analize preduzimaju se logine akcije. [3] Evaluacija merenja Evaluacija procesa merenja - Proces merenja treba evaluirati i raditi poreenja procesa merenja prema specifinim evaluacionim kriterijumima. Takoe se merenjem procesa odreuju i dobre i loe strane procesa. Ovo moe biti izvedeno internim procesima ili eksternim revizijama i treba da ukljui povratnu spregu od osoblja na merenjima. Prema standardu ISO/IEC 15939 [3] preporuuje se snimanje iskustava u odgovarajuoj bazi podataka. Identifikacija potencijalnih poboljanja - Takva poboljanja mogu biti promene u formi indikatora, promene u jedinici merenja ili ponovne klasifikacije kategorija merenja. Treba utvrditi trokove i prednosti potencijalnih poboljanja i izabrati odgovarajue akcije poboljanja. Preporuljivo je diskutovati o predloenim poboljanjima u procesu merenja u krugu svih zainteresovanih strana radi pregleda i prihvatanja i razgovarati o nedostatku potencijalnih poboljanja, ako analiza ne uspe da identifikuje unapreenja. 20
  • 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. 21