Dravni Univerzitet u Novom Pazaru Departman: Tehnikih nauka Smer: Raunarska tehnika Predmet: Softversko inenjerstvo

Projekat: Poslovno Inteligentna Simulaciona Arhitektura(PISA), OQT Sim verzija 1.1 Mentor: Doc. dr Ljubomir Lazic Tim#2: 1. Muratovi Emir 2. Halilovi Mirela 3. Muhovi Asmir

Sadraj:1 2 Uvod ............................................................................................................................................. 7 Opis funkcija PISA-e ................................................................................................................... 8 2.1 Osvrt na OQT SIM komponentu ......................................................................................... 10 RBOST Optimizer........................................................................................................ 12 Quality Analizer ........................................................................................................... 12 Benefit evaluator (ROI ,BCR) ..................................................................................... 12 Rules Simulator ............................................................................................................ 13 Scenario Simulator ....................................................................................................... 13 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 3 3.1 3.2 3.3 3.4 3.5 3.6 3.7

Root dijagram toka podataka ..................................................................................................... 14 Dekompozicija na prvi nivo ................................................................................................ 15 Dekompozicija na drugom nivou ........................................................................................ 16 Dekompozicija na primitivne f-je........................................................................................ 18 Scenario simulator ............................................................................................................... 18 Benefit evaluator .......................................................................................................... 19 Deployment view- pogled ugradnje arhitektonskog reenja ........................................ 22 Logiki pogled ..................................................................................................................... 20 Model klasa OQT SIM paketa............................................................................................. 23 Sekvencijalni model ............................................................................................................ 24 Simulacija scenarija ..................................................................................................... 24 RBOST ......................................................................................................................... 25 Benefit evaluator .......................................................................................................... 27 Ruls simulator .............................................................................................................. 28 Quality analyzer ........................................................................................................... 29

3.4.1 3.5.1

3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 4 4.1 4.2 4.3 4.4 4.5 5 5.1 5.2 5.3 5.4 5.5

Interakcija izmeu komponenti .................................................................................................. 30 Interakcija komponente OQT MNGR sa ostalim komponentama ..................................... 30 Interakcija OQT SIM komponente sa ostalim komponentama ........................................... 31 Interakcija komponente OQT BOX sa ostalim komponentama ......................................... 32 Interakcija komponente OQT OPST sa ostalim komponentama ....................................... 33 Interakcija komponente OQT MAINT sa ostalim komponentama .................................... 34 Profit eXpert ........................................................................................................................ 37 Planer eXpert ....................................................................................................................... 38 Risk Management eXpert .................................................................................................... 39 Quality eXpert ..................................................................................................................... 40 Maintenance eXpert ............................................................................................................ 41 [2]

Poslovni inteligenta simulaciona arhitektura (PISA) sa aspekta 4+1 pogleda........................... 35

5.6 6 6.1 6.2

Process Dynamics Control eXpert ...................................................................................... 42 Modeli za softverski process ............................................................................................... 44 Modeli razvoja softvera ....................................................................................................... 44 Model vodopada ........................................................................................................... 45 V Model ....................................................................................................................... 47 W model ....................................................................................................................... 48 Inkrementalni model .................................................................................................... 49 Spiralni model .............................................................................................................. 50 Agilni model ................................................................................................................ 52 Kombinovni model Rup model ................................................................................. 53

Softversko inenjerstvo .............................................................................................................. 43

6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 7 7.1

Analiza konkurentskih reenja ................................................................................................... 55 QSM Slim ............................................................................................................................ 55 SLIM Estimate ............................................................................................................. 57 SLIM Control ............................................................................................................... 58 SLIM Metrics ............................................................................................................... 59 Estimate Express .......................................................................................................... 60 Prednosti i nedostaci .................................................................................................... 61 7.1.1 7.1.2 7.1.3 7.1.4 7.1.5 7.2 7.3 7.4

Ocenjivanje kvaliteta QSM Slim-a pomou liste za proveru I ............................................ 62 Ocenjivanje kvaliteta QSM Slim-a pomou liste za proveru II .......................................... 65 Mosaic - MStar .................................................................................................................... 69 MStar - Mosaics Structured Testing and Assessment Repository .............................. 69 Prednosti i nedostaci .................................................................................................... 71

7.4.1 7.4.2 7.5 7.6 7.7

Ocenjivanje kvaliteta MOSAIC MStar-a pomou liste za proveru I .................................. 71 Ocenjivanje kvaliteta MOSAIC MStar-a pomou liste za proveru I .................................. 74 HP Quality assurances ......................................................................................................... 78 Zahtevi simulacije Perspektivna analiza ................................................................... 78 Sposobnost da se identifikuju potrebe ......................................................................... 78 Zahtevi komunikacija ................................................................................................... 79 Struktuirani zahtevi ...................................................................................................... 79 Visoke i niske vernosti simulacije ............................................................................... 79 Zahtevi validacije ......................................................................................................... 80 Integracija sa drugim alatima SDLC ............................................................................ 80 Rezime ......................................................................................................................... 80 HP Quality Management solutions (HP ALM, HP Quality Center) ............................ 80

7.7.1 7.7.2 7.7.3 7.7.4 7.7.5 7.7.6 7.7.7 7.7.8 7.7.9 7.8 7.9 8

Ocenjivanje kvaliteta Hp Quality Assurance pomou listi za proveru ............................... 86 Ocenjivanje kvaliteta Hp Quality Assurance pomou listi za proveru I ............................. 89

Razmatranje i odabir odgovarajue softverske arhitekture ........................................................ 93 [3]

8.1 8.2 8.3

Koncept CORBA arhitekture .............................................................................................. 93 Common Object Request Broker Architecture ................................................................... 93 Elementi CORBA standarda ............................................................................................... 94 Object Request Broker ................................................................................................. 94 Object Adapter ............................................................................................................. 94 Interface Definition Language ..................................................................................... 95 Repozitorijum Interfejsa .............................................................................................. 95 Dinamiki Poziv Interfejsa........................................................................................... 96 Interfejs Dinamikog Skeletona ................................................................................... 96 Udaljeni pozivi ............................................................................................................. 98 Meuoperabilnost u CORBA standardu ...................................................................... 99 Protokoli definisani od strane CORBA-e..................................................................... 99

8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6 8.4 8.4.1 8.4.2 8.4.3 9 10

Proceduralni koraci u razvoju CORBA baziranih na naem projektu ................................. 96

Klijent server arhitektura ......................................................................................................... 100 Java EE Platforma ................................................................................................................... 101 10.1 10.2 10.3 10.4 10.4.2 10.5 10.6 10.7 10.8 10.9 10.10 Java EE aplikacije model ............................................................................................... 101 Distribuirani Multitiered Aplikacije .............................................................................. 102 Bezbednost ..................................................................................................................... 103 Java EE komponente...................................................................................................... 103 Aplikacije Klijenta ..................................................................................................... 103 JavaBeans komponente arhitekture ............................................................................... 104 Java EE server komunikacije ......................................................................................... 104 Web komponente ........................................................................................................... 105 Tipovi kontejnera ........................................................................................................... 106 Namena i primena Java EE aplikacije ........................................................................... 106 Pakovanje Aplikacije ..................................................................................................... 107 Paradigms of Computing ............................................................................................... 108 Razlog uvodjenja Servisno Orjentisane Arhitekture ..................................................... 109 Paradigm of Service-Oriented Computing .................................................................... 111

10.4.1 Java EE Klijenti ......................................................................................................... 103 10.4.3 Apleti .......................................................................................................................... 104

10.7.1 Usluge Kontejnera..................................................................................................... 105

11

Uvod u Servisno Orjentisane Arhitekture ................................................................................ 108 11.1 11.2 11.3

11.3.1 Osnovni koncepti i terminologije ............................................................................... 111 11.3.2 Service-Oriented Computing ..................................................................................... 112 11.4 11.5 ESB (Enterprise Service Bus ......................................................................................... 114 Servis poruka ................................................................................................................. 116 [4] 11.4.1 Servisi ESB-a ............................................................................................................. 115

11.5.1 Upravljaki servis ...................................................................................................... 116 11.5.2 Interfejs servis ............................................................................................................ 116 11.5.3 Posredniki servis ...................................................................................................... 117 11.5.4 Servis meta podataka ................................................................................................. 117 11.5.5 Sigurnosni servis ........................................................................................................ 117 11.5.6 Karakteristike ESB-a.................................................................................................. 118 11.6 SOA Registar ................................................................................................................. 118 11.6.1 Objavljivanje .............................................................................................................. 118 11.6.2 Upravljanje meta-podacima ....................................................................................... 118 11.6.3 Upravljanje korienjem ............................................................................................ 119 11.6.4 Komponente SOA Registra ........................................................................................ 119 11.7 11.8 11.9 12 12.1 12.2 Workflow Engine........................................................................................................... 119 Servis Broker ................................................................................................................. 120 SOA Supervizor ............................................................................................................. 121 Razlika izmeu makro i mikro procena ......................................................................... 123 Nekoliko koraka do procene softverskih troskova ........................................................ 124

Estimacija ................................................................................................................................. 123

12.2.1 Korak 1: Dimenzionisanje specifikacija, izvorni kod, i test ...................................... 124 12.2.2 Korak 2: Estimacija defekata i nivoi efikasnosti uklanjanja defekata ....................... 128 12.2.3 Korak 3: Odabir projektnih aktivnosti ....................................................................... 129 12.2.4 Korak 5: Procena napora softvera .............................................................................. 131 12.2.5 Korak 6: Procena trokova softvera ........................................................................... 132 12.2.6 Korak 7: Procena rasporeda za razvoj softvera .......................................................... 133 12.2.7 Korak 8: Procena promene zahteva tokom razvoja ................................................... 133 13 Capers Jones-ova pravila ........................................................................................................ 134 13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10 13.11 13.12 13.13 Pravilo 1 Estimacija veliine izvornog koda .............................................................. 134 Pravilo 2 Estimacija dokumentacije ........................................................................... 134 Pravilo 3 Estimacija odudaranja korisnikih zahteva ................................................. 134 Pravilo 4 - Estimacija broja sluajeva testiranja ............................................................ 134 Pravilo 5 - Estimacija mogunosti dolaska do greke tj. potencijalnog broja greaka .. 134 Pravilo 6 Estimacija efikasnosti otklanjanja greke ................................................... 134 Pravilo 7 - Estimacija efikasnosti organizovanog otklanjanja greaka ......................... 134 Pravilo 8 - Estimacija efikasnosti otklanjanja greke nakon putanja u rad .................. 134 Pravilo 9 - Estimacija trajanja realizacije projekta ........................................................ 135 Pravilo 10 - Estimacija potrebnih ljudi za realizaciju projekta..................................... 135 Pravilo 11 - Estimacija ljudi potrebnih za odravanje softvera ..................................... 135 Pravilo 12 - Estimacija ukupnih napora u realizaciji softverskog projekta ................... 135 Estimacija trokova ........................................................................................................ 135 [5]

13.13.1 13.13.2 14 14.1 14.2 14.3 14.4 14.5 14.6

Cocomo model ....................................................................................................... 135 Cocomo II ............................................................................................................... 136

Tipovi softvera ......................................................................................................................... 138 Softver za krajnjeg korisnika ......................................................................................... 138 Informacioni sistem upravljanja (MIS) ......................................................................... 138 Spoljni projekti .............................................................................................................. 138 Sistemski softver............................................................................................................ 138 Komercijalni softver ...................................................................................................... 139 Vojni softver .................................................................................................................. 139

[6]

1 Uvodinjenica je da poslovni sistemi postaju sve sloeniji, a softverski inenjeri se suoavaju sa sve teim zahtevima i izazovima. Usled stalnih promena i rastue sloenosti postavljaju se brojna pitanja. Kako razumeti, dokumentovati i realizovati jedan sloen softverski sistem, kako realizovati sloenu poslovnu logiku, a u isto vreme sauvati jednostavnost i razumljivost softverskog sistema? Koju od postojeih strategija projektovanja treba koristiti i kada? Koju strategiju odabrati u cilju postizanja najboljih rezultata? Kako ostvariti konkurentsku prednost u odnosu na druge proizvoae softvera?Kako sauvati rezultate projektovanja od zastarevanja prouzrokovanog stalnim promenama na podruju tehnologija, hardverskih platformi, operativnih sistema i samog poslovnog okruenja kome je softver namenjen? Testiranje je aktivnost koja se sprovodi radi evaluacije kvaliteta proizvodnje softvera i njegovog poboljanja. Testiranje nije aktivnost koja poinje samo nakon kompletiranja faze kodiranja. Softversko testiranje se danas vidi kao aktivnost koja obuhvata ceo proces razvoja i odravanja i predstavlja vaan deo kompletne konstrukcije softvera. Planiranje testiranja treba da pone sa ranom fazom izrade zahteva za kvalitet softverskog proizvoda i procesa njegovog projektovanja, test planovi i procedure moraju biti sistematski i kontinualno razvijani i po potrebi redifinisani. Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbei probleme nego ih ispravljati, kao i za sve ostale ivotne situacije fraza je neizbena da je bolje spreiti, nego leiti. Ima neminovnih greaka, nae je da ih svedemo na minimum ili potpuno uklonimo. Da stvorimo harmoniju i balans. Testiranje softvera je nain da se obezbedi manji broj greaka, manji troak odravanja i sveukupne cene softvera. Inovativna ideja OptimalSQM-a se usreuje na proces testiranja i merenja softvera koja omoguavaju kvalitetnu procenu ovog kritinog dela procesa razvoja softvera.

[7]

2 Opis funkcija PISA-eOptimalSQM sadri (OQT MNGR, OQT BOX, OQT MAINT, OQT OPST, OQT SIM) i dostupan je kao sveobuhvatni paket reenja za upravljanje testiranjem i simulacijom moguih scenarija procesa testiranja konkretne kompanije i konkretnog projekta. MNGR je u srcu sistema, prua integrisano i koherentno upravljanje multidisciplinarnim aspektima ispitivanja softvera i omoguava testiranje pravila u upravljanju procesom testiranja odreenog tipa softvera na optimalan nain, konkretne kompanije i konkretnog projekta putm simlacije moguih scenarija realizacije procesa testiranja u okviru planiranog budeta, trajanja i atribta kvaliteta softvera koji se razvija. OQT MNGR komponenta se nalazi u srcu PISA-e, obezbeuje integrisano i koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omoguavajui naprednu generaciju pravila testiranja. MNGR sadri SaaS-ove (Softwere as a Service) paradigme pravila koja e biti prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred definisanim predlocima pravila - za reavanje kritinih vektorskih (preko 100 promenljivih) u procesu upravljanja testiranjem. Takoe, vana funkcija MNGR komponente je da prui sve upitnike na projektu: aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi izraunavanja ogranienja procene rizika i radi postizanja odrive procene odreenih preduzea i projekata.

OQT SIM komponenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih pravila pre primene. Zahvaljujui nadgledanjem planiranja, OQT-SIM takoe proverava poboljanje kvaliteta i efikasnosti postojeih pravila postavljenih tokom vremena, to omoguava poreenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis. OQT-SIM nudi tano razumevanje stvarne koristi i ROI postavljenih pravila, prua dokaz koncepta za vie scenarija stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije (iz sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, procesa testiranja u datoj kompaniji i sl.), procenu optimalnog scenarija za dati projekat na bazi rezultata simulacije moguih scenarija testiranja spremljenog pre primene u realizaciji datog konkretnog softverskog projekta. SIM nudi simulaciju ablona koji sadre algoritme iz razliitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao to su smanjenje vremena testiranja, napredna statistika kontrola procesa, kvalitet i pouzdanost, smanjenje naknadne dorade usled napravljenih greaka u svim fazama razvoja softvera. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQTMNGR modelima, OQT-SIM omoguava simulaciju pravila i postavljena pravila definisana u OQT-pravilima, koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruenju. Simulacijoni tok je intuitivan, jednostavan za korienje i podran je jakom metodologijom.

[8]

OQT BOX komponenta e biti najbolja praksa i skup univerzalnih tehnika za testiranje softvera po metodi Crne kutije, Bele kutije i Sive kutije u IT industriji, koje e biti spremljene za sve vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis i kupljene softverske alate za testiranje. BOX komponenta e biti potpuno nezavisna od modela procesa razvoja softvera i vrste softverskih proizvoda, podravajui sve nivoe i tipove testiranja softvera. Kao deo reenja OptimalSQM-a, izvravae se na zahtev OQT MNGR komponente, a na osnovu proverenih pravila koja su kreirana i proverena simulacijom moguih scenarija testiranje softvera pre njihove primene u tesetiranju konkretnog softvera koji razvija i testira konkretna kompanija sa svojim ljudskim, procesnim i laboratorijskim kapacitetima, a prema uspostavljenim kriterijumima efikasnosti i efektivnosti za sve SDLC aktivnosti.

OQT MAINT komponenta razmilja o svim rezultatima testiranja radi poboljanja kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom, adaptivnom i perfektivnom odravanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na upotrebu. MAINT komponenta vri unakrsne procene kvaliteta svih flota testiranja, za sve procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (poveenje prinosa otkrivenih greaka), nudei ekstremni integritet podataka. Osim toga, MAINT komponenta poboljava pouzdanost softvera kroz SRE (Software Reliability Engineering) metodologiju metrike pouzdanosti softverskog proizvoda u predvianju i proceni kritinih faktora kao to su: stopa greaka po fazama razvoja softvera, konana stopa greaka nakon 6 meseci upotrebe softvera, gustine greaka na KSLOC ili FP metrici veliine softvera, profil greka itd. Na osnovu ovih podataka MAINT komponenta obezbeuje kompletnu tehniku podrku nakon putanja softverskih proizvoda u promet, odnosno program za aktivnosti odravanje tj.za korektivno, adaptivno, perfektivno i preventivno odravanje na optimizovan nain.

OQT OPST komponenta (OPeratinonal Software Testing) treba timu za planiranje i sprovoenje testiranja konkretnog razvijanog softvera, konkretne kompanije (Project Specific Software Testing) omogui da na osnovu stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije i pronaenog optimalnog scenarija za dati projekat na bazi REZULTATA izvrenih simulacija (OQT SIM komponente) moguih scenarija testiranja pre primene u realizaciji datog konkretnog softverskog projekta odredi karakteristike integralnog i optimalnog PTS (IOPTS). Dakle, na osnovu sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija, performansi razvojnog tima, zrelosti (TMM nivoa) procesa testiranja u datoj kompaniji i sl., odredi aktivnosti i objekte testiranja u takama provere artifakata datog PTS (SDLC), odredi adekvatne tehnike detekcije greaka koje obezbeuju zahtevani kvalitet tokom razvoja softverskog proizvoda u okvirima projektnih ogranienja tj. sve parametre IOPTS.

[9]

2.1 Slika Komponente softverske arhitekture OptimalSQM reenja 2.1 Osvrt na OQT SIM komponentu

Kako je testranje kljuna aktivnost u procesu razvoja kvalitetnog softvera, pravila testiranja nisu vie samo pravila - to su poslovne odluke koje direktno utiu na trokove, testiranje kvaliteta i pouzdanosti. Dananje tehnike i metode nastoje da izbegnu viestruko testiranje, uzimajui u obzir testiranje karakteristika kvaliteta softverskog proizvoda, kao i visok nivo pouzdanosti krajnjeg proizvoda. Na kraju ovoga pogleda, potrebno je ponuditi reenje koje moe da precizno i lako kvalifikuje i kvantitativno utvrdi uticaj procesa testiranja softvera, pre njegovog uvoenja u proizvodnju tj. realno okruenje kod korisnika. To reenje predstavlja u ustvari zadatak simulacije moguih scenarija realizuje procesa razvoja i testiranja konkretnog softverskog proizvoda date kompanije sa aspekta: zrelosti, tehnikih kapaciteta, ljudskih resursa u cilju pronalaenja optimalnog scenarija realizacije softverskog projekta.

[ 10 ]

Slika 2.1.1 Komponente softverske arhitekture OpimalSQM Sim reenja OQT SIM komponenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih pravila pre primene. Zahvaljujui nadgledanjem planiranja, OQT-SIM takoe proverava poboljanje kvaliteta i efikasnosti postojeih pravila postavljenih tokom vremena, to omoguava poreenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis. OQT-Sim nudi tano razumevanje stvarne koristi i ROI postavljenih pravila, prua dokaz koncepta za vie scenarija. SIM nudi simulaciju ablona koji sadre algoritme iz razliitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao to su smanjenje vremena testiranja, napredna statistika kontrola procesa, kvalitet i pouzdanost, dispozitiv i naknadna obrada. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQT-MNGR modelima, OQT-Sim omoguava simulaciju pravila i postavljena pravila definisana u OQT-pravilima, koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruenju. Simulacijoni tok je intuitivan, jednostavan za korienje i podran je jakom metodologijom.

[ 11 ]

Slika 2.1.2 Blizi prikaz QTSIM komponenti

2.1.1 RBOST OptimizerTestiranje predstavlja znaajan deo budeta softverskih aplikacija. RBOST (optimizirani proces testiranja softvera na bazi rizika) treba da bude dizajniran da pobolja efikasnost i efektivnost testiranja niskog rizika u razvoju projekta i odravanja visokog kvaliteta sloenih softverskih sistema u okviru budetskih ogranienja. RBOST predstavlja optimizaciju modela koji je baziran na povraaju investicija i odgovarajue aktivnosti upravljanja rizikom koji omoguuje utedu na trokovima izbegavanja veza sa otkrivanjem i ispravljanjem greaka to RBOST Optimizer. Testiranje predstavlja znaajan deo budeta softverskih aplikacija. RBOST (optimizirani proces testiranja softvera na bazi rizika) treba da bude dizajniran da pobolja efikasnost i efektivnost testiranja niskog rizika u razvoju projekta i odravanja visokog kvaliteta sloenih softverskih sistema u okviru budetskih ogranienja.RBOST predstavlja optimizaciju modela koji je baziran na povraaju investicija i odgovarajue aktivnosti upravljanja rizikom koji omoguuje utedu na trokovima izbegavanja veza sa otkrivanjem i ispravljanjem greaka to pre.

2.1.2 Quality AnalizerAnalizator kvaliteta softvera (QA) je deo aplikacije koja na osnovu neke poznate metrike softvera procenjuje kvalitet, odnosno upotrebljivost i broj gresaka u softveru.

2.1.3 Benefit evaluator (ROI ,BCR)Benefit predstavlja ukupan iznos dobijenog novca od novog i poboljanog softverskog procesa. [ 12 ]

U radu emo predstaviti tehnike za povratak investicija koje su apsolutno neophodne u postupku poboljanja softverskog procesa. Dve tehnike koje opisujemo su: ROI BCR ROI (model povratka investicija) je model koji slui da bi smo doprineli smanjenju ukupnih trokova izazvanih osiguranjem kvaliteta softvera i on predstavlja odnos prilagoenih koristi i trokova. Postoje softveri u koje je uloeno puno novca a pritom i vremena ali oni nikada nisu dobili svoju trinu verifikaciju i validaciju. BCR predstavlja taku ili oblast(u viedimenzionom prostoru-faktori kvaliteta,vreme, i trokovi) gde odnos koristi i trokova je vei od 1 tj. Vie se dobija nego to je potroeno na poboljanje procesa razvoja i testiranja softvera.

2.1.4 Rules SimulatorRuls simulator simulator usvojenih pravila za poboljanje procesa razvoja i testiranja softvera, treba da vrsi simulaciju pravila koja se primenjuju za donosenje odredjenih odluka u procesu projektovanja softvera. Zahtevi u okviru ove komponente su postojanje odreenih strategija,metoda,tehnika i alata koje komponenta OQT MNGR dostavlja komponentama naeg OQT SIM paketu .

2.1.5 Scenario SimulatorScenario simulator- realizacije softverskog projekta konkretne kompanije, treba da bude skup razliitih alata za simulaciju razliitih scenarija u razvoju kvalitetnog softvera. Njegov zadatak je da na osnovu ulaznih podataka koje dobije korinika koji je pokrenuo simulator I uneo putanju do svog XML fajla ili od naseg serveraI zadatih parametara simulira razliite mogue scenarije koji ce posluiti korisniku,projektantu, test timu i celokupnom menadmentu na projektu da odabere odgovarajui scenario ili scenarije kakobi smanjio rizik zadovoljenja za neke od vanih karakteristika kako kvalitetasofvtera da odabere odgovarajuci kako bi smanjio rizik za neke od vaznih karakteristika kakosoftvera tako i njegovog procesa projektovanja(npr. Greke, vreme izvravanja pojedinih aktivnosti, trokovi razvoja i odravanja i cena softverskog proizvoda itd.)

[ 13 ]

3 Root dijagram toka podataka

Slika 3.1 Prikaz root dijagrama Optimal SQM-a Koraci u root dijagramu toka podataka : 1. Pristupa sistemu korisnik da bi pristupio neem softveru odnosno riznici alata i reenja (BISA), neophodno je da se prijavi na sajt, kako bi mu bile dostupne sve informacije na sajtu, koje se tiu korisnika. 2. Odgovor sistema o pristupu korisnika nakon ispunjenog formulara, korisnik od sistema dobija odgovor o uspenoj prijavi ili o ponovnom ispunjanju formulara u sluaju neuspelog prijavljivanja. 3. Zahteva potrebne informacije od sistema nakon to se korisnik uspeno prijavio, on od sistema zahteva eljene informacije koje su mu potrebne. 4. alje potrebne informacije korisniku korisnik dobija od sistema informaciju da moze da pristupi svim fajlovima koji se nalaze u bazi podataka koji se tiu korisnika.

5. Nakon pregleda vri odabir - korisnik nakon primljenih informacija od strane sistema vri odabir na osnovu svojih potreba. 6. Posle obraenih zahteva, Optimal SQM alje detaljne informacije nakon sto je korisnik jasno definisao svoje zahteve, alati u sistemu obrauju te zahteve gde je svaki alat zaduen

[ 14 ]

za odreeni posao, tako da korisnik dobija detaljnje informacije koje se tiu cene izrade, vremena potrebnog za izradu, kao i cene za dalju saradnju, npr. odravanja softvera.

7. Prihvata ili odbija ponudjene uslove nakon to je korisnik dobio detaljne informacije, prihvata ili odbija, u zavisnosti od isplativosti i vremenske ogranienosti.

3.1

Dekompozicija na prvi nivo

Slika 3.1.1 Prikaz dekompozicijije root dijagrama na prvi nivo

Iz priloenog dijagrama vidimo odnos naeg paketa i korisnika. Korisnici su na dijagramu odvojeni na korisnike van Optimal SQM reenja i na korisnike unutar reenja, odnosno na pakete koji koriste nae usluge. U sluajevima interakcije sa korisnikom van reenja, na paket zahteva neke informacije od OQT MNGR paketa koje su mu potrebne da bi proverio korisnika, kao i od drugih paketa da bi pribavio odgovarajue tehnike, alate i metode koje nisu u naem posedu, odnosno ne moemo direktno da im pristupamo. Na osnovu dijagrama moemo definisati ulazne i izlazne fajlove i podatke i to na sledei nain: Eksterni podatak je podatak za proveru korisnika Eksterni fajlovi su alati i tehnike koje prua na paket drugim, rezultati Interni falovi su su alati i tehnike koje na paket koristi od drugih paketa, zahtevi za uslugom [ 15 ]

Ovde su bili definisani zahtevi koji su gledano u odnosu na Optimal SQM reenje internog tipa, eksternog tipa bi bili: eksterni fajl: rezultati zahtevane operacije, interni podatak: zahtev za operacijom, interni fajl: prosledjivanje potrebnih podataka. Na osnovu izlienog moemo rei sledee: da na paket ima 1 prost izlaz, gde na primer daje vrednost nekog faktora koji je izraunao kao to je ROI ili ROTI, tri izlaza srednje sloenosti za scenarije, ekonomske proraune i simulaciju kvaliteta softvera, dva ulaza prosene i dva sloena ulaza za podatke od ostalih komponenti, paketa, i jedan sloeni interfejs

3.2

Dekompozicija na drugom nivou

Na dijagramu su prikazani osnovni procesi koji postoje unutar OQT Sim paketa. Ovi procesi se dalje razlau na primitivne procese. Postoji jedan interfejs koji predstavlja korisnika u globalu, odnosno internog (neki od paket) i eksternog korisnika. Svaki korisnik alje zahtev za izvravanje neke funkcije i dobija razultate koji su smeteni u bazu podataka rezultata simulacije. Na dijagramu se vidi da postoji samo ulaz za smetanje podataka o rezultatima simulacije a da je izlaz neki drugi proces u okviru nekog paketa kom su ti podaci potrebni. Svi procesi svoje meurezultate i metode/tehnike/alate smetaju u bazu simulacije, a izlaz te baze je ulaz procesa scenario simulatora koji daje finalan rezultat pokrenute operacije. Takoe, osim tih rezultata potrebni su i jo neki kao to su informacije o koriniku u sluaju kada je korisnik koji zahteva izvrenje eksterni. Na sledeoj slici je prikazan drugi nivo dekompozicije toka podataka u okviru paketa.

[ 16 ]

Slika 3.2.1 Prikaz dekompozicije root dijagrama na drugi nivo

[ 17 ]

3.3

Dekompozicija na primitivne f-je

Dekompozicijom na primitivne funkcije moemo videti ta se deava unutar svakog procesa iz drugog nivoa dekompozicije po naosob.

3.4

Scenario simulator

U simulatoru scenarija postoje dva primitivna procesa. Jedan proces je zaduen za odabir odgovarajuih metoda na osnovu kojih se vri sama simulacija, dok je drugi proces zaduen sa izraunavanje na osnovu odabrane metode i podatak iz baze simulacije. Za dato izraunavanje koristi alate koji su mu na raspolaganju a zavise od primenjene metode. Rezultate smeta u bazu podataka rezultati, koja je prikazana na slici. Ulaz u pomenutu bazu moe biti od nekog drugog procesa koji su dati na drugom nivou.

Slika 3.4.1 Scenario simulator

[ 18 ]

3.4.1 Benefit evaluatorOva komponenta vri razne proraune zasnovene na nekim matematickim algoritmima . U ovoj komponenti su zathevi prethodno definisani, na osnovu ekonomskih parametara,Interfejs je komponenta koja zahteva proraun, a proces Cost Xpert alat koji vri proraun i rezultate smeta u bazu podataka. Na sledeoj slici su prikazani primitivni procesi komponente benefit evaluator.

Slika 3.4.1.1 Dekompozicija drugog nivoa

[ 19 ]

3.5 Pregled: Pregled Statike strukture Interakcije Dinamiko ponaanje

Logiki pogled

Svrha logikog pogleda je da odredi funkcionalne zahteve sistema.Glavni artefakt logikog pogleda je model dizajna.Dizajn modela daje konkretan opis funkcionalnih ponaanja sistema koja je izvedena od analize modela.Model analize daje apstraktan opis sistema ponaanja koji su zasnovani na modelu sluaja korienja.Generalno samo dizajn modela se odrava u logikom prikazu,jer analiza modela daje grubu skicu koja je kasnije promenjena u dizajn predmeta. Dizajn modela se sastoji od saradnika klase,organizovani unutar podsistema ili paketa. Artefakti koji su ukljueni u dizajn modela mogu biti: Klase,interakcije,dijagram stanja Podsistem i njihovi interfejsi opisani korienjem paketa dijagrama Kod statikih struktura se koriste klase koje neemo obradjivati. Implementacija ,pogled procesa,pogled rasporedjivanja: Motivacija Pogled procesa Pogled implementacije Pogled rasporedjivanja.

[ 20 ]

uc Logiki pogled - OQT Sim OQT Sim

Logov anje include Validacija

include

include Registracija

Pristup sajtu

include include

Softv erski alati extend Korisnik Riznica alata i reenja

extend

Zahtev i korisnika

Obrada zahtev a include Maintenance eXpert

Odrzav anje

Slika 3.5.1 Sluaj upotrebe - pristup korisnika komponenti OQT SIm Na slici 3.5.1 prikazan je sluaj upotrebe kada korisnik pristupi naem portal. Ukoliko korisnik nije registrovan, ima mogunost registracije, i nakon registracije moe pristupiti riznici alata koje nudi nae reenje PISA. U ovom sluaju je prikazan pristup korisnika komponenti OQT SIM, i daljim mogunostima koje nudi komponenta SIM.

[ 21 ]

3.5.1 Deployment view- pogled ugradnje arhitektonskog reenjaDeployment view predstavlja raspored komponenti u naem reenju, odnosno raspored softvera na odredjenom hardveru. Iz slike moemo videti i veze izmedju nezavisnih hardverskih uredjaja.

Slika 3.5.1.1. Deployment view

[ 22 ]

3.6

Model klasa OQT SIM paketa

Prikaz klasa koje realizuju SIM paketa i njihova meusobna zavisnost.

Slika 3.6.1. Dijagram klasa dela sistema

[ 23 ]

3.7

Sekvencijalni model

3.7.1 Simulacija scenarijaSimulator scenarija smo predstavili sekvencijalnim dijagramom a objanjenje ovog dijagrama sledu u nekoliko koraka: 1. Prvi korak: OQT MNGR trai zahtev od Simulatora za simulaciju scenarija i kao odgovor vraa OQTMNGR podatke, parametre i vrste scenarija 2. Drugi korak: Prosleuje podatke i preko simulatora trai nivo zrelosti projektnog tima i parametre koji su vezani za taj tim u bazi podataka, baza podataka alje odgovor Simulatoru 3. Trei korak: Simulator poziva OQT BOX da prosledi metode i tehnike koje su potrebne za simulaciju i nakon toga simulator dobija odgovor i prosledjene podatke 4. etvrti korak: Simulator dobijene podatke i beleenje moguih scenarija smeta u bazu podataka i kao odgovor dobija izbor najboljeg mogueg scenarija, i nakon te obrade unutar simulatora on vraca preostale podatke i analize u predhodnom zapisu u bazu podataka 5. Peti korak: Baza podataka prosleuje podatke simulatoru koji nakon te obrade prosleuje reenje optimalnog scenarija Boxu Sa ovim petim korakom se i zavrava simulator scenarija

Slika 3.7.1.1. Sekvencijalni dijagram Simulator scenarija [ 24 ]

3.7.2 RBOSTCilj analize rizika u proceni trokova je da se menaderu projekta predoi da postoji prihvatljiv nivo rizika da e trokovi projekta biti premaeni. Ovom tvrdnjom da postoji verovatnoa da e EAC podaci napraviti probleme nekim uesnicima u projektu, ali da je to posledica injenice da uvek postoje rizici u realizaciji svakog projekta pa ignorisanje te injenice nee te rizike otkloniti. Zato treba integrisati analizu rizika i u proceni budeta celog projekta kako bi se odredio najverovatniji troak celog projekta. Pored toga, to e pomoi u planiranju eksplicitnih budetskih rezervi koje e zatititi premaenje planiranih trokova projekta. Takoe e pomoi menaderu projekta da napravi listu najrizinijih WBS elemenata sa aspekta trokova na koje treba da obrati posebnu panju. Prvobitne procene trajanja i trokovi pojedinih aktivnosti u velikim projektima su najee preterano optimistike, tako da je veliki rizik u ispunjenju ogranienja u vremenu i dudetu ako se oni procenjuju u jednoj taki tj. uzimaju samo fiksne vrednosti bez uraunavanja verovatnoe njihove raspodele oko oekivanih vrednosti. Treba jo jednom naglasiti da je prikupljanje iskustvenih podataka iz ranijih projekata najvanija aktivnost u analizi rizika. Najee se to postie putem intervjua sa ekspertima iz odgovarajuih oblasti u prikupljnju informacija o najmanjim, najverovatnijim i najveim vrednostima pojedinih elemenata u proceni trajanja i trokovima u aktivnostima pri realizaciji projekta. Proces analize rizika se izvodi u sledeih pet koraka:1.

Prvi korak je da se planiraju sve aktivnosti sa ugraenim RBOSTP optimizacionim modelom datog projekta. Sve aktivnosti treba da budu prikazane preko kompletne mree kritinih puteva realizacije projekta kako bi se dobili realni rezultati analize rizika. Karakteristike dobrog modela mree kritinih puteva realizacije projekta su: Sva vremenska ogranienja su zadovoljena. Aktivnosti najnieg nivoa detaljnosti imaju i predhodnika i naslednika. Preko 80% vezanih aktivnosti zavravaju se pre poetka sledee aktivnosti.

Drugi korak je da se identifikuju aktivnosti koje imaju najvei rizik za koje e se prikupiti, statistiki gledano, dovoljno podataka. U ovom koraku mora se, takoe, identifikovati i aktivnost pregleda meu rezultata u toku simulacije (Reporting Tasks). 3. Trei korak zahteva unos parametara za simulaciju rizika pojedinih aktivnosti. Za svaku rizinu aktivnost treba uneti najmanju, najveu i oekivanu ocenjenu vrednost za trajanje i/ili trokove sprovoenja te aktivnosti. Zatim, odabrati funkciju raspodele za ocenu intervala trajanja i trokove svake rizine aktivnosti. 4. etvrti korak je izvravanje analize rizika na osnovu sprovedenih simulacija. Zato je potrebno zadati broj iteracija (replika) izvravanja simulacija i odabrati opcije prikupljenih podataka koje se odnose na trajanje i trokove svake rizine aktivnosti u unapred definisanim opsezima. Ovi rezultati iterativnih simulacija se memoriu radi naknadne analize. 5. Peti korak je analiza simulacionih rezultata. U zavisnosti od odabranih opcija. U naem sluaju ova analiza bi izgledala ovako: 1. Prvi korak: Korisnik prosleuje korisnike parametre RBOST-u. 2. Drugi korak: RBOST alje bazi podataka zahtev o nivou zrelosti projektnog tima i od baze podataka dobija odgovor.2.

[ 25 ]

3. Trei korak: RBOST se obraa Benefit evaluatoru i alje zahtev za dobijanje parametara, pri emu kasnije i dobija odgovor. 4. etvrti korak: RBOST trai od Simulatora scenarija zahtev za simulaciju na osnovu proenih parametara i kao rezultat dobija odgovor 5. Peti korak: RBOST alje podatke za generisanje izvetaja generatoru izvetaja, pri emu generator izvetaja prosleuje podatke u bazu podataka i od baze podataka dobija rezultat posle ega prosleuje izvetaj RBOST-u. 6. esti korak: RBOST nakon izvrenih pet koraka prosleuje izvetaj koji je dobijo od generatora izvetaja korisnicima odreenih boksova.

Slika 3.7.2.1. Sekvencijalni dijagram RBOST

[ 26 ]

3.7.3 Benefit evaluatorOsnovna ideja IOPTS bie objanjena na osnovu sledeeg pojednostavljenog modela detekcije i korekcije greaka tokom PRS-PTS. Naime, neotkrivene greke vieg ili najvieg nivoa katastrofalnosti (s4, s=1..5) ako prebegnu, otkriju se i otklone u narednoj fazi PRS-PTS mogu kotati 10 i vie puta nego da je to uinjeno u momentu generisanja istih. Greke manjeg nivoa katastrofalnosti (s3) meutim, kotaju obino 2-3 puta vie nego da su detektovane i korigovane u momentu generisanja. to se tano deava u ovom delu moe se videti i dijagramu za simulator scenarija koji se nalazi ispod ovog teksta.

Slika 3.7.3.1.Sekvencijalni dijagram Benefit eval

Objanjenje ovog dijagrama u opisati po koracima kako je ovaj dijagram i iao: 1. Prvi korak: Korisnik zahteva parametre ekonomskog modela od Profit experta, Profit expert alje zahtev za parametre koji trai od koristnika, i korisnik natrag alje parametre Profit expertu 2. Drugi korak: Profit expert alje izvetaj CRM da bi pitao za nivo zrelosti projektnog tima koji nakon toga alje izvetaj u bazu podataka i nakon toga dobija odgovor od baze podataka, kada primi odgovor CRM alje takoe odgovor Profit expert.

[ 27 ]

3. Trei korak: Profit expert nakon dobijanja odgovora od CRM-a, alje zahtev za simulaciju ekonomskog modela na osnovu projektovanih parametara i kao odgovor dobija prosleene parametre 4. etvrti korak: Prilikom dobijanja parametara Profit Expert prosleuje podatke izvetaja generatoru izvetaja koji taj izvetaj belei u bazu podataka i od baze podataka dobija odgovor pri emu generator izvetaja zatim prosleuje podatke korisnicima.

3.7.4 Ruls simulatorTok operacija koje izvrava ova komponenta su dati na dijagramu. Opis dijagrama: 1. Prvi korak: Paketi zahtevaju pravila simulacije od rulsa simulatora koji nakon toga trai parametre i paket mu alje odgovor 2. Drugi korak: Nakon dobijenog odgovora Ruls simulator trai nivo zrelosti prijektnog tima u CRM-u koji vri pretragu u bazi podataka, baza podataka nalazi odgovor i prosleuje ga prvo CRM u pa zatim i ruls simulatoru. 3. Trei korak: Ruls simulator generise podatke I prosleuje ih generator izvetaja da se postave u odreenu formu , kada se podaci postave u odreenu formu alju se bazi podataka da zabelei izvestaj, nakon tog perioda baza podataka odgovara o izvrenoj operaciji generator izvetaja koji vraa odgovor Ruls simulatoru. 4. etvrti korak: Nakon izvrena tri koraka Ruls simulator daje odgovor i na taj nain prosleuje pravila za simulaciju.

Slika 3.7.4.1. Sekvencijalni dijagram Ruls sim komponente

[ 28 ]

3.7.5 Quality analyzer

Slika 3.7.5.1. Sekvencijalni dijagram Quality analizera Quality analizer: 1. Prvi korak:Paketi zahtevaju analizu kvaliteta od Quality analizera i on trai parametre od Paketa i dobija ih kao odgovor 2. Drugi korak: Quality analizer pita CRM za kvalitet zrelosti projektnog tima, zatim CRM alje izvetaj bazi podataka i baza podataka vraa odgovor CRM-u, a zatim i CRM vraa odgovor Quality analizer-u 3. Trei korak: Quality analizer alje zahtev za kvalitet softvera Quality MNGR-u i od njega dobija odgovor 4. etvrti korak: Quality analizer prosleuje podatke za generisanje izvetaja generatoru izvetaja koji to belei u bazu podataka i nakon toga salje odgovor u obliku izvetaja Quality analizer-eru. 5. Peti korak: Nakon etvrtog koraka Quality analizer alje izvetaj o analizi kvaliteta zahtevanog objekta odgovorajuem paketu

[ 29 ]

4 Interakcija izmeu komponenti4.1 Interakcija komponente OQT MNGR sa ostalim komponentama

OQT MNGR komponenta se nalazi u srcu PISA-e, obezbeuje integrisano i koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omoguavajui naprednu generaciju pravila testiranja. Vana funkcija MNGR komponente je da prui sve upitnike na projektu: aktivnosti razvoja procesa i bitne stavke produktivnosti procesa radi izraunavanja ogranienja procene rizika i radi postizanja odrive procene odreenih preduzea i projekata.

Slika 4.1.1 Interakcija komponente OQT MNGR sa ostalim komponentama Poto se OQT MNGR komponenta nalazi u srcu PISA-e, ona predstavlja svi ostalim komponentama klijenta, jer trai od ostalih komponenti podatke koje su one predhodno obradile.

[ 30 ]

4.2

Interakcija OQT SIM komponente sa ostalim komponentama

OQT SIM komponenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih pravila pre primene. Zahvaljujui nadgledanjem planiranja, OQT-SIM takoe proverava poboljanje kvaliteta i efikasnosti postojeih pravila postavljenih tokom vremena, to omoguava poreenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda. SIM nudi simulaciju ablona koji sadre algoritme iz razliitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao to su smanjenje vremena testiranja, napredna statistika kontrola procesa, kvalitet i pouzdanost, smanjenje naknadne dorade usled napravljenih greaka u svim fazama razvoja softvera. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba.

Slika 4.2.1 Interakcija OQT SIM komponente sa ostalim komponentama OQT SIM komponenta je klijent komponentama kao to su: OQT MAINT, OQT BOX i OQT OPST jer njima prua adekvatne podatke koje one trae od nje, a sa surge strane predstavlja server komponenti OQT MNGR jer njoj alje potrebne informacije.

[ 31 ]

4.3

Interakcija komponente OQT BOX sa ostalim komponentama

OQT BOX komponenta e biti najbolja praksa i skup univerzalnih tehnika za testiranje softvera po metodi Crne kutije, Bele kutije i Sive kutije u IT industriji, koje e biti spremljene za sve vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pruamo servis i kupljene softverske alate za testiranje. BOX komponenta e biti potpuno nezavisna od modela procesa razvoja softvera i vrste softverskih proizvoda, podravajui sve nivoe i tipove testiranja softvera.

Slika 4.3.1 Interakcija komponente OQT BOX sa ostalim komponentama OQT BOX komponenta predstavlaja server komponentama kao to su: OQT SIM i OQT MNGR jer njima prua potrebne informacije koje te komponente trae od OQT BOX-a. Ostalim dvema komponentama OQT MAINT i OQT OPST, OQT BOX je klijent i njima prua potrebne informacije.

[ 32 ]

4.4

Interakcija komponente OQT OPST sa ostalim komponentama

OQT OPST komponenta (OPeratinonal Software Testing) treba timu za planiranje i sprovoenje testiranja konkretnog razvijanog softvera, konkretne kompanije (Project Specific Software Testing) da omogui da na osnovu stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije i pronaenog optimalnog scenarija za dati projekat na bazi REZULTATA izvrenih simulacija (OQT SIM komponente) moguih scenarija testiranja pre primene u realizaciji datog konkretnog softverskog projekta, odredi karakteristike integralnog i optimalnog PTS (IOPTS)

Slika 4.4.1. Interakcija komponente OQT OPST sa ostalim komponentama Komponenta OQT OPST je svim ostalim komponentama server, jer sve ostale komponente od OQT OPST-a zahtevaju informacije koje su njima potrebne.

[ 33 ]

4.5

Interakcija komponente OQT MAINT sa ostalim komponentama

OQT MAINT komponenta razmilja o svim rezultatima testiranja radi poboljanja kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom, adaptivnom i perfektivnom odravanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na upotrebu. MAINT komponenta vri unakrsne procene kvaliteta svih flota testiranja, za sve procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (poveenje prinosa otkrivenih greaka), nudei ekstremni integritet podataka.

Slika 4.5.1. Interakcija komponente OQT OPST sa ostalim komponentama Komponenta OQT MAINT predstavlja server komponentama kao to su OQT BOX, OQT SIM i OQT MNGR jer te komponente zahtevaju potrebne informacije od OQT MAINT komponente, dok komponenti OQT OPST, komponenta OQT MAINT je klijent, jer zahteva informacije koje ona obradi.

[ 34 ]

5 Poslovni inteligenta simulaciona arhitektura (PISA) sa aspekta 4+1 pogleda

Slika 5.1 Prikaz pogleda arhitekure

Pogled sluaja upotrebe : Pregled Grafiki konstruktor Tekstualni opis Arhitektonski pogled na model sluaja upotrebe

[ 35 ]

Slika 5.2. Softverski alati, tehnike i modeli koje nudi nae PISA reenje

[ 36 ]

Na slici 8.2.2 su prikazani alati ija je uloga objanjena u sledeim stavkama : 5.1 Profit eXpert

Zadatak Profit eXpert softverske komponente e biti da na bazi izraenog ekonomskog modela kvaliteta softvera oceni isplativost predloenih aktivnosti obezbeenja i kontrole kvaliteta PRS-PTS na osnovu ekonomskih parametara (ROI, BCR, CAPEX, OPEX i dr.). Profit eXpert razvija metrike uravnoteene produktivnosti (BPM) kako bi se merilo poboljanje uinaka i produktivnosti. BPM se fokusira na SEI CMM mere kao to su veliina, vreme, napor i defekti, i ostali podaci prikupljeni za merenje poboljanje procesa. BPM se zasniva na principu da upravljanje poboljanjem produktivnosti treba da se usredsredi na postizanje ravnotee vremena (raspored), trokova (napor), i kvaliteta (procenat defekta) , to je u skladu sa Balanced Scorecard metodologijom.

Slika 5.1.1 Slucaj upotrebe-profit expert

[ 37 ]

5.2

Planer eXpert

Planer eXpert treba na osnovu istraenih modela estimacije i predikcije veliine softvera, sloenosti, trajanja razvoja, trajanja testiranja, broja potencijalnih greaka u softveru, trajanja i cene njihove popravke tokom PRS-PTS, prui neophodne podatke za simulaciju razliitih scenarija PRS-PTS iz kojih se bira optimalni scenario realizacije projekta. Planer eXpert bi trebalo da obezbedi optimalan raspored vremena i procenu trokova za softverski projekat. On primenjuje najbolje metode procene bazirane na brojnim modelima kao to su COCOMO, funkcionalne take i drugi. U cilju poboljanja preciznosti predvianja modela Planer eXpert sakuplja podatke o prethodnim projektima u posebnu bazu podataka koja sadri iste promenljive, tj. napor i veliinu, koji kasnije mogu da se detaljnije iskoriste za procene korienjem standardnih statistikih regresionih tehnika.

Slika 5.2.1 Sluaj upotrebe-planer expert

[ 38 ]

5.3

Risk Management eXpert

Risk Management eXpert treba da u saradnji sa Profit eXpert sofverskim alatom prui servis menaderima dizajna i testiranja softvera u: identifikaciji, proceni efekata, plana aktivnosti smanjenja i kontrole rizika na prihvatljivom nivou, datog softverskog projekta. Risk Management eXpert koristi veliku bazu podataka koja sadri vie od 8 000 projekata koji se koriste u modelu za optimizaciju testiranja baziranom na riziku u cilju otklanjanja defekata u ranim fazama projekta i poveanja pouzdanosti softvera. Procena pouzdanosti softvera omoguava vrstu osnovu za izvoenje znaajnih studija na poetku projekta. Takoe omoguava predvianje verovatnoe otkaza softvera pre testiranja ili u bilo kom trenutku u toku testiranja. Procena pouzdanosti softvera (Software Reliability Estimation) slui za fino podeavanje i kalibraciju u cilju da odreeni projekat bude konzistentan i pouzdan.

Slika 5.3.1 Slucaj upotrebe-risk managment expert

[ 39 ]

5.4

Quality eXpert

Quality eXpert treba da integrie specijalizovane ekspertske alate (Quality Metrics eXpert, Test Effort Estimation eXpert, Reliability eXpert, Product release eXpert) koji obezbeuju servis menaderima dizajna i testiranja softvera u: izradi metrike integrisanog procesa merenja kvaliteta softvera, automatizaciji procesa planiranja zasnovanog na modelima estimacije veliine softvera, cene, broju projektanata, trajanja razvoja i testiranja, proceni i predikciji pouzdanosti softverskog reenja tokom simulacije razliitih scenarija dizajna i u toku realizacije PRS-PTS, koji treba da dovedu do donoenja odluke o zavretku PRS-PTS i predaje softveskog proizvoda (IS) na upotrebu. Quality eXpert se koristi za poboljanje SDP-SDT preko SQA alternativnih planova korienjem naprednih reenja modela detekcije i otklanjanja kvarova kao to je opisano u naim ranijim radovima, datim u referencama. Odgovarajue metrike i instrumenti omoguavaju precizno planiranje procesa i izvrenje tog plan uz mogunost brzog prilagoavanja u nepredvienim okolnostima.

Slika 5.4.1 Sluaj upotrebe-quality expert

[ 40 ]

5.5

Maintenance eXpert

Maintenance eXpert treba da obezbedi servis menaderima dizajna i testiranja softvera u: izradi plana i proceni trokova korektivnog, adaptivnog, perfektivnog i preventivog odravanja softvera. Kao to smo ve istakli, razvoj kvalitetnog softvera je jako sloen i nepouzdan posao, ali je upravljanje sloenim, dinamikim procesom razvoja i testiranja (sa preko 100 promenljivih) jo tee bez adekvatnog softverskog alata koji je obradjen u sledeoj taki Maintenance eXpert treba da obezbedi servis menaderima dizajna i testiranja softvera u: izradi plana i proceni trokova korektivnog, adaptivnog, perfektivnog i preventivog odravanja softvera.

Slika 5.5.1 Sluaj upotrebe-maintenance expert

[ 41 ]

5.6

Process Dynamics Control eXpert

Process Dynamics Control eXpert, koji treba da identifikje observabilne i kontrolabilne promenjive konkretnog softverskog projekta, da uspostavi kriterijume stabilnosti i optimalnosti u svakoj fazi PRS-PTS i za ceo proces. Da bi ovako realizovano softversko okruenje za optimalan razvoj kvalitetnog softvera zaista obezbedilo uspeh na konkretnom softverskom projektu tj. dalo oekivane rezultate, neobhodno je stalno ulaganje u: ocenjivanje i praenje performansi projektnog tima, podizanje strunog kapaciteta ljudi koji realizuju projekat. Za to je odgovoran softveski alat People Performance eXpert. Razvoj kvalitetnog softvera je jako sloen i nepouzdan posao, ali je upravljanje sloenim, dinamikim procesom razvoja i testiranja (sa preko 100 promenljivih) jo tee bez adekvatnog softverskog alata Process Dynamics Control eXpert, koji treba da identifikuje observabilne i kontrolabilne promenjive konkretnog softverskog projekta, da uspostavi kriterijume stabilnosti i optimalnosti u svakoj fazi PRS-PTS i za ceo proces.

Slika 5.6.1 Sluaj upotrebe-process dznamics control expert

[ 42 ]

6 Softversko inenjerstvoSoftverski proizvod je skup racunalnih programa i pripadne dokumentacije, stvoren zato da bi se prodao. Moe biti razvijen za sasvim odreenog korisnika (engleski bespoke product, customized product) ili uopteno za trite (engleski generic product). Softverski proizvod esto emo krae nazivati softver. Za dananji softver se podrazumeva da on mora biti kvalitetan. Preciznije, od softverskog proizvoda se oekuje da se on odlikuje sledeim atributima kvaliteta. Mogunost odravanja - Softver se mora moi menjati u skladu s promenjenim potrebama korisnika. Pouzdanost i sigurnost - Softver se mora ponaati na predvidiv nain, te ne sme izazivati zike ili ekonomske tete. Ekasnost - Softver mora imati zadovoljavajue performanse, te on treba upravljati mainskim resursima na tedljiv nain. Upotrebljivost - Softver treba da radi ono to korisnici od njega oekuju, intrefejs mu treba biti zadovoljavajui, te za njega mora postojati dokumentacija. Softversko inenjerstvo je nauna i struna disciplina koja se bavi svim aspektima proizvodnje softvera. Dakle, softversko inenjerstvo bavi se modelima, metodama i alatima koji su nam potrebni da bi na to jeftiniji nain mogli proizvoditi to kvalitetnije softverske proizvode. Softversko inenjerstvo poelo se razvijati krajem 60-tih godina 20-tog veka, kao odgovor na takozvanu softversku krizu. Naime, pojavom raunara tree generacije (na primjer IBM serija 360) stvorila se potreba za sloenijim softverom (na primjer multi-tasking operacijski sistem). Pokrenuti razvojni projekti viestruko su premaili planirane trokove i rokove. Videlo se da se dotadanje neformalne tehnike individualnog programiranja ne mogu uspeno skalirati na velike programe gde uestvuje velik broj programera. Oseala se potreba za sloenijim metodama razvoja softvera, koje bi liile na metode iz tradicionalnih tehnikih struka (na primer mostogradnja) te bile u stanju kontrolisati kompleksnost velikog softverskog projekta. Od 60-tih godina do danas, softversko inenjerstvo uspelo se ustaliti kao vaan deo tehnike i raunarstva. Softver se danas proizvodi daleko predvidljivije i ekasnije nego pre. Ipak, jo uvek postoji prostor za poboljanje. Softversko inenjerstvo se i dalje intenzivno razvija, disciplina jo nije dosegla svoju zrelu fazu, te u njoj nema jednoumlja. Softversko inenjerstvo je projektovanje, razvoj, dokumentacije i odravanja softvera primenjujui tehnologije i prakse iz vie disciplina, ukljuujui raunarsku nauku, upravljanje projektima, inenjering, dizajn interfejsa, integraciju 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, ugravanje kvaliteta razmiljanje u procesu razvoja softvera, testiranje, upravljanje razvojnih timova, project management, projekt izvjetavanje, projekt brzine razvoja projekta, [ 43 ]

komunikacija svih uesnika.

6.1

Modeli za softverski process

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 )

6.2 1. 2. 3. 4. 5. 6. 7. Model vodopada V Model W model Inkrementalni model Spiralni model Agilni modeli razvoja RUP

Modeli razvoja softvera

[ 44 ]

6.2.1 Model vodopadaModel 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 zapo.inje definisanjem zahteva prema svim elementima sistema i alociranjem jednog dela adekvatnih i odreenih zahteva prema softveru. Ovaj 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. 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. 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 jednoznacno 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, [ 45 ]

postoji dovoljno vremena i strpljenja kod korisnika za dugi period razvoja i visoki razvojni trokovi i saobrazno potrebna finansijska sredstva nisu ogranicavajui 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 pocetku 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 stravicno distorziono dejstvo na projekat razvoja.

Slika 6.2.1.1 Model vodopada

[ 46 ]

6.2.2 V ModelV 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. 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 W modela mogu se ponoviti radi popravke i poboljanja zahteva, dizajna ili koda, pre nego to se ponove testiranja na desnoj strani modela. Prednosti modela: Naredna faza poinje tek kada se predhodna faza zavri, Aktivnosti planiranja testiranja i kreiranje testova se izvrava pre kodiranja, Greke koje su nastale u predhodnim fazama bie otklonjene u tekuoj fazi. Nedostaci modela: Model je vrlo krut u pogledu izmena. Svaka promena u projektovanju povlai promene u dokumentaciji i test dokumentaciji (odnosno promene samog testa), Moe se implementirati samo u velikim preduzeima, Potrebno je mnogo sredstava za primenu i odravanje ovog modela.

Slika 6.2.2.1 Prikaz V- modela [ 47 ]

6.2.3 W modelS obzirom na testiranje, svi modeli predstavljeni ranije su deficitarni na razliite naine: test aktivnosti prvog pokretanja nakon implementacije veza izmeu razliitih faza testiranja i osnova za test nije jasna uska veza izmeu testa, debug i promena zadataka tokom testne faze nije jasna U sledeem tekstu, predstavljen je W-model. Zasnovan je na optem V-modelu i prethodno pomenuti nedostaci su uklonjeni. Test proces obino dobija premalo panje u predstavljanju modela i obino se pojavljuje kao neprivlaan zadatak da se izvri posle kodiranja. U sortiranju prostora testiranja na ravnopravnoj osnovi, drugi "V" posveen testiranju je integrisan u modelu. Oba "V" zajedno daju "W" od W model

Slika 6.2.3.1 Prikaz W-modela Prednosti W modela: U W modelu znaaj testova i redosled pojedinih aktivnosti za testiranje su jasni. Paralelno sa razvojem procesa, dalji proces - proces testiranja - se sprovodi. Ovo nije prvi poetak nakon zavretka razvoja. Stroga podela izmeu konstruktivnih zadataka na levoj strani i vie destruktivnih zadataka na desnoj strani koja postoji u V-modelu je uklonjena. U W-modelu, jasno je da takva podela zadataka nije pametna i da blia saradnje izmeu razvoja i testiranja aktivnosti mora da postoji. Od samog poetka projekta pa nadalje testeri i programeri imaju poverene zadatke i smatraju ravnopravnim partnerstvo. Tokom testne faze, programer je odgovoran za otklanjanje kvarova i ispravljanje implementacije. [ 48 ]

W-model postaje blii praksi, kada je test rashoda 40% i vie. Model jasno naglaava injenicu da je testiranje vie od same izgradnje, izvoenja i evaluacije testiranja. Nedostaci W modela: Modeli pojednostavljuju stvarne injenice. U praksi postoji vie odnosa izmeu razliitih delova razvojnog procesa. Meutim, postoji potreba za jednostavan model, ako ga svi ljudi ukljueni u projekat prihvate. Ovo je takoe razlog zato se jednostavan V model tako esto koristi u praksi. Modeli razvoja softvera predstavljaju nerazjanjene potrebne trokove za resurse koji treba da budu dodeljeni pojedinanim aktivnostima. Takoe u W-modelu, ini se da razliite aktivnosti imaju jednaki uslov za resurse (vreme, osoblje, itd). U praksi to svakako nije sluaj. U svakom projektu najvaniji aspekti mogu da variraju i zbog toga alokacija resursa ima malu verovatnou da bude ravnopravna u aktivnostima. Za visoko kritine aplikacije test aktivnosti sigurno imaju vee teine, ili bar jednake teine sa drugim aktivnostima.

6.2.4 Inkrementalni modelU 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. 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.

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

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 [ 49 ]

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.

6.2.5 Spiralni modelSpiralni model je razvijen od. B Boehma 1988. godine, da bi se objedinile dobre osobine modela vodopada i modela prototipskog razvoja uz istovremeno ukljuivanjeaktivnosti 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.

Slika 6.2.5.1 Spiralni model razvoja softvera 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 spiralnom modelu, proces razvoja softvera se odvija u 4 iteracije:

[ 50 ]

Slika 6.2.5.2 4 iteracije procesa razvoja softvera 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 veliki 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 nivoproizvoda 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 prilagoava 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. Prednosti spiralnog modela su: Eksplicitno prepoznavanje rizika koje omoguuje njegovo ekasno uklanjanje. Procene (budet i plan) su realistinije kako projekat napreduje jer se poveava broj pitanja. Mogue je uhvatiti se u kotac s (gotovo neizbenim) promenama koje razvoj softvera namee. Softverski inenjeri mogu ranije poeti delovati na projektu. [ 51 ]

Nedostaci su: Glavni nedostatak spiralnog modela je to su procene koje se tiu budeta i plana grube na poetku jer neke analize nisu zavrene sve dok te etape nisu prole fazu dizajna.

6.2.6 Agilni modelAgilne 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 omogu.uju korisnicima aktivno uee 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 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 tehnolo.kim okruenjima 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. Uesnicima 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. 4 principa agilnog modela

Slika 6.2.6.1 Ilustracija 4 principa agilnog modela 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 korisni.ke podr.ke mo.e lako unititi projekat razvoja, kao .to i neadekvatna podr.ka mo.e spre.iti zavr.etak 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 zajedni.ki cilj, uzajamno poverenje i [ 52 ]

potovanje, zajedniki i brz postupak donoenja odluka i sposobnost savladavanja svih dvosmislenosti. Agilan tim koji radi u okviru krute organizacije ima pote.ko.a, kao .to ih ima svaki pojedinac koji radi u krutom timu. U ovim timovima, dominira saradnja svih nivoa upravljanja. Za dono.enje odluke nije vano ko donosi odluke, ve. je va.na saradnja i obezbenenje informacija za dono.enje odluka. U projektu razvoja uestvuju osobe razliitih vetina, talenta i sposobnosti, koje rade u bliskom fizikom okruenju i po.tuju 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. Takoe, agilni razvoj se teko izvodi u timovima sa veim brojem lanova. Najvie uspeha u agilnom razvoju pokazuju timovi do devet lanova. Agilni razvoj se pokazao kao uspe.an 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.

6.2.7 Kombinovni model Rup modelJedna od najee korienih metodologija razvoja softvera je RUP (Rational Unified Process). RUP je kreiran 1996. godine od strane kompanije Rational Software, koja inae pripada IBM-u od 2003. godine. Definicija RUP - a nije jednoznana. Mogao bi se definisati kao iterativni pristup razvoju softvera koji je orjentisan ka arhitekturi i voen sluajevima upotrebe. RUP je takoe i dobro definisan, struktuiran proces softverskog inenjerstva koji jasno definie prekretnice u projektu, ko ta radi i ta i kada treba uraditi. RUP predstavlja i proizvodni proces koji prua prilagodljiv okvir za softversko inenjerstvo. Proizvodni proces moe se prilagoditi malim i velikim projektima i timovima. Osnovni elementi RUP-a su skup postulata i principa na kojima je zasnovan razvoj, razvojno okruenje i skup metoda koje e biti koriene i jezik za opisivanje procesa i modela. Celine za gradnju i elementi sadraja predstavljaju: Uloge koje definiu skup povezanih vetina, sposobnosti i odgovornosti. Proizvode rada koji predstavljaju ono to proizilazi iz zadatka zajedno sa svim proizvodima i modelima nastalim tokom rada. Zadatake koji opisuju jedinicu posla dodeljenu ulozi, koja obezbeuje rezultat. Kako je RUP pristup koji poiva na iterativnom ciklusu, tokom svake iteracija zadaci su organizovani u 9 disciplina. Prvih 6 disciplina su inenjerske : poslovno modelovanje, zahtevi, analiza i dizajn, implementacija, test, isporuivanje, a poslednje 3 discipline su discipline podrke: konfiguracija i upravljanje izmenama, projektovanje izmena, okruenje). RUP definie etiri faze ivotnog ciklusa projekta: fazu usvajanja (Inception), fazu razrade (Elaboration), fazu konstrukcije (Construction) i fazu prelaska (Transition).

[ 53 ]

Slika 6.2.7.1 ivotni ciklus projekta; Statika i dinamika dimenzija RUP-a Dijagram moemo protumaiti na dva naina. Prema prvom, dijagram prikazuje sadraj svake faze ivotnog ciklusa. Tanije svaka faza moe sadrati vie iteracija i pri tome se u svakoj iteraciji svake faze prolazi kroz 9 disciplina. Drugo tumaenje je sagledavanje statike i dinamike dimenzije RUP-a. 5 Statiku dimenziju predstavljaju discipline koje se ponavljaju u svakoj iteracij svake faze, dok dinamiku dimenziju predstavlja prelazak procesa iz faze u fazu tokom vremena. Dinaminost se ogleda i u promenljivom broju iteracija. Na kraju svake faze postoje neka pitanja na koja moramo odgovoriti. Ova pitanja predstavljaju prekretnice (milestones) u projektu.

Slika 6.2.7.2 Prekretnice (Milestones) na kraju svake faze ivotnog ciklusa Prednosti kombinovanog modela Rup modela Osnovna prednost RUP-a je visok nivo prilagodljivosti konkretnom projektu. Ovo je posledica toga to RUP nita ne zahteva ve preporuuje. RUP se lako se prilagoava projektima o kojima [ 54 ]

posedujemo malo informacija. Ovo je posledica fleksibilnosti faza razvoja. Malo vie se treba pomuiti tokom faze usvajanja i razrade kako bismo dobili neophodne informacije. Iz istog razloga moemo se prilagoditi i projektima sa dobro definisanim zahtevima i datom potrebnom dokumentacijom. Kod takvih projekata prve dve faze razvoja postaju veoma jednostavne. Druga prednost RUP-a je inkrementalni razvoj. Mnogo je lake postepeno razvijati makoji sistem, jer ovakav pristup tedi vreme i umanjuje trokove. Posebna pogodnost je to to na kraju svake iteracije moemo prikupiti sugestije korisnika kako bismo to pre mogli da pristupimo izmenama koje oni zahtevaju. Trea prednost bi bio razvoj upravljan rizicima. Analiza rizika nas usmerava tokom razvoja. Ponekad je bolje krenuti naizgled skupljim putem jer su na njemu anse za nastupanje rizika i trokovi koji nastaju ukoliko doe do problema znatno nii. Nedostaci kombinovanog modela Rup modela Kao najvea mana RUP-a uzima se neprilagoenost malim projektima. Za male projekte faze usvajanja i razrade praktino nemaju znaaja za dalji razvoj. RUP je prilagoen velikim projektima sa obimnijom dokumentacijom koja e imati veliki uticaj na dalji razvoj. Kao druga mana moe se uzeti malopreanja prednost. Iterativni razvoj moe biti i mana. RUP nije pogodan za neiskusne voe timova i timove. Ukoliko ovakvi timovi pokuaju da primene iterativni razvoj, esto dolazi do velikih propusta i promena u zahtevima koje rezultiraju probijanjem rokova, a u najgorem sluaju i odustajanjem od projekta. Uprkos svemu, RUP je veoma koriena metodologija u krugu iskusnih timova upravo zbog svoje prilagodljivosti najrazliitijim projektima.

7 Analiza konkurentskih reenjaCilj uporedne analize konkurentskih reenja na tritu je da se pronau mane tih reenja i one pomognu da se ne ponove u naem proizvodu ili da se u krajnjoj meri smanji uticaj istih, sa druge strane analiza ovih reenja nam omoguava da uvidimo prednosti i iskoristimo ih na naem projektu, konkretno u okviru oblasti OQT Sim-a. Tri konkurentska proizvoda su reenja: QSM Slim Mosaic - MStar i HP Quality Assurances. 7.1 QSM Slim

QSM Slim (Software Lifecycle Management) je softversko reenje koje je zasnovano na teoriji profesora Putmana koji ima dugogodinje iskustvo u oblasti projektovanja softvera. Reenje nudi razliite mogunosti koje se mogu iskoristiti tokom estimacije, razvoja ali i testiranja proizvoda koji razvijamo. Sastoji se od nekoliko koponenti i to: SLIM MasterPlan je alat koji, kako navodi kompanija koja ga je proizvela, idealan analizu organizacionih reenja i planiranja velikih i kompleksih sistema. Alat omoguava da se prate veliki projekti i da se brzo dodje do alternativa koristei moni what-if simulator. SLIM Estimate pomae u proceni vremena, truda i trokova koje moraju da zadovolje i daju skup zahteva i da odrede najbolju strategiju za projektovanje i implemetaciju softvera ili sistema projekta. Pored razvoja softvera, klijenti mogu da koriste alate za vie prejektovanje procesa ukljuujui razvoj, hardver, infrastrukturu, model zasnovan na razvoju, ininjering i arhitekturu, servisno orijentisana arhitekturu, centar razvoja i jo mnogo toga.

[ 55 ]

SLIM Control sadri statiki kontrolni proces tehnike koji je potreban da se proceni stanje projekta (tj. da se uporedi plan projekta sa stvarnim projektom i generisanje zavr