Testiranje softvera ta je testiranje softvera? Testiranje softvera je proces koji se koristi da bi se utvrdila ispravnost, potpunost i kvalitet razvijenog softvera. Imajui to u vidu, testiranje nikada ne moe u potpunosti da utvrdi ispravnost raunarskog softvera. Samo proces formalne verifikacije moe da pokae da u softveru nema greaka. Testiranje softvera je nain da se obezbedi manji broj greaka, manji troak odravanja i sveukupne cene softvera. U ovom projektu se usredsreujemo na proces testiranja i merenja softvera koja omoguavaju kvantitativnu procenu ovog kritinog dela procesa razvoja softvera. Testiranje softvera ukljuuje proces otkrivanja neusaglaenosti softvera kako bi one bile ispravljene pre nego budu instalirane u ivo okruenje koje je podrka za svakodnevni rad poslovnih jedinica kompanije. Testiranje je aktivnost koja se sprovodi radi evaluacije kvaliteta proizvodnje softvera i njegovog poboljanja. Ono 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, i 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. U bilo kom upotrebljivom softveru u praksi postoji beskonaan broj moguih testova koje je praktino nemogue sve izvesti, te je nemogue u odreenom vremenskom periodu, sa ogranienim resursima (ljudi, oprema i alati) izvriti totalno testiranje koje bi otkrilo sve greke u sofveru. Postoji mnogo pristupa u testiranju softvera, ali je efikasno testiranje sloenog proizvoda pre rezultat procesa istraivanja, a ne samo pitanje izrade i slepog praenja procedure. Jedna definicija testiranja softvera je: proces ispitivanja proizvoda u cilju njegove procene, gde se ispitivanje odnosi na to ta se testiranjem proizvoda eli postii, aproizvod daje odgovor kroz reakciju na probno testiranje. Zato testiranje softvera? Testiranje softvera je znaajno zato to softver moe, ukoliko ne radi adekvtano, izazvati neuspeh misije, uticati na operativnu efikasnost i pouzdanost. Efikasno testiranje softvera doprinosi isporuci kvalitetnog softverskog proizvoda koji zadovoljava potrebe, oekivanja i zahteve korisnika. Ukoliko radi loe, to vodi visokim trokovima odravanja i nezadovoljstvu korisnika. 20 zajednikih sotverskih problema: Netana kalkulacija, netano ureeni podaci, neefikasno ureeni podaci, netano kodiranje/primena poslovnih pravila, neadekvatan rezultat softvera, zbunjujui ili podaci koji mogu dovesti u zabludu, softver koji je teko koristiti, zastareo softver, neodslednost u obradi, tekoe u odravanju i razumevanju, nepouzdani rezultati, neadekvtana podrka poslovnim potrebama i ciljevima, slaba podrka od strane prodavca, netana ili neadekvatna povezanost sa drugim sistemima, netano povezivanje podataka, istraivanje podataka koje donosi netane rezultate, neadekvatna obrada povezanosti podataka, netano rukovanje fajlovima i podacima, neadekvatna kontrola, nemogunost rukovanja kapacitetima proizvodnje podataka.1

5 kljunih stvari u testiranju softvera su: 1. Strategija testiranja- koja pokazuje nain, tj.metod testiranja-koje tipove i koju koliinu testova treba upotrebiti da bi se na najbolji nain otkrile greke koje su skrivene u softveru. 2. Plan testiranja- koji sadri konkretne zadatke koji e omoguiti ostvarenje strategije testiranja. 3. Sluajevi tesiranja - koji su pripremljeni u formi detaljnih primera i koji se koriste da bi se proverilo da li softver odgovara zahtevima. 4. Podaci za testiranje- koji se sastoji i od ulaznih podataka i baze podataka, koji se koriste dok se izvravaju test sluajevi, 5. Okruenje testiranja- softversko i hardversko okruyenje (operativni sistem i druga softverska reenja)u kome se celo testiranje obavlja. ivotni ciklus testiranja: zapoinje planom testiranja, izradom sluajeva, sprovoenjem testiranja, praenjem greaka, i zavrava se izvetajem procesa testiranja. ta je kvalitet softvera? Kvalitet predstavlja sposobnost da se proizvede softver koji zadovoljava ili nadmauje postavljene zahteve (prema definisanim merljivim kriterijumima) i koji je proizveden definisanim procesom. Ovaj proces ne svodi se samo na zadovoljenje definisanih zahteva, vec se u okviru njega moraju definisati mere i kriterijumi koji usmeravaju process postizanja kvaliteta. Potrebno je usvojiti pravila za jedan ponovljiv i upravljiv proces ciji proizvodi ce dostizati odredeni nivo kaliteta. Jedna od definicija koja se pominje u softverskoj literaturi je i definicija sa stanovita potroaca. Potroac definie kvalitet kao meru zadovoljavanja potreba kupca od strane proizvoda ili usluge. Drugom recju, upotrebnim kvalitetom. Najee zablude o kvalitetu: 1. Kvalitet moe biti naknadno dodat iutestiran to ne stoji ve kvalitet mora biti opisan i ugraen u proces stvaranja proizvoda. 2. Kvalitet dolazi sam od sebe to ne stoji ve kalitet ne nastaje tek tako. Proces razvoja mora se definisati, sprovoditi i kontrolisati kako bi se dostigao odredeni nivo kvaliteta. 3. Kvalitet je jednodimenzionalna karakteristika i svakom znaci isto- to ne stoji ve kvalitet ima vie dimenzija od kojih su najvanije: funkcionalnost, pouzdanost, upotrebljivost, efikasnost, stepen podrke. Svaku od dimenzija prati odgovarajui tip testiranja softvera. 10 pravila testiranja: Testiranje treba da zapone jo u ranoj fazi i da se obavlja esto Treba integrisati razvoj aplikacije i ivotni ciklus testiranja. Dobie se bolji rezultati bez neophodnosti posredovanja izmeu dva zaraena tabora u procesu testiranja softvera Treba formalizovati metodologiju testiranja- a to znai treba sve testitati na identian nain i dobie se uniformisani rezultati Razviti obim plan testiranja- koji predstavlja osnovu za metodologiju testiranja Treba koristiti i statike i dinamike testove Definisati oekivane rezultate (problem Test Oracle) Razumeti poslovne potrebe koje stoje iza razvijene aplikacije-na taj nain e se razviti i bolja aplikacija i bolje testiranje Koristiti razliite nivoe i tipove testiranja (regresiju, sistemsko testiranje, integraciju) Pregledati i proveravati rad, to e smanjiti trokove2

-

Ne dozvolit svojim programerima da testiraju sopstveni rad- jer e prevideti sopstvene greke. Ovo se izbegava unakrsnim testiranjem tj. programeri raymenjuju kod i testiraju tui kod.

Komparacija pravaca - ekonomski aspekti U literaturi se navode prednosti nekih od pravaca ili metoda u testiranju posmatrano sa aspekta trokova pre svega: 1. Prevencija ili detekcija: Kvalitet se ne moe postici na vec gotovom proizvodu. Cilj je da se sprece defekti ili nedostaci i da se proizvod ucini merljivim pomocu parametara kvaliteta. Neke od mera kvaliteta su: struktuiranje razvojnog procesa uz pomoc standarda za razvoj softvera i podrku razvojnog procesa metodama, tehnikama i alatima. Nedetektovane greke koje su izazvale milione poslovnih gubitaka uslovile su rast nezavisnog testiranja. Trokovi proizvodnje se smanjuju sa ranim otkrivanjem I ispravkom greaka. Uz alate za automatsko testiranje, dugorocno gledano, rezultat su proizvodi visokog kvaliteta i smanjeni trokovi odravanja. Ukupni troak efektivnog upravljanja kvalitetom predstavlja sumu cetri komponente trokova: prevencije, inspekcije, internih i eksternih otkaza. Preventivni trokovi sastoje se od akcija koje se preduzimaju kako bi se sprecili defekti. Inspekcioni trokovi sastoje se od merenja, procene i provere proizvoda ili usluga i njihovog slaganja sa standardima i specifikacijama. Trokovi internih otkaza su oni koji podrazumevaju ispravku proizvoda sa grekama pre njihove isporuke. Trokovi eksternih otkaza sastoje se od greaka otkrivenih nakon lansiranja proizvoda. Prevencija se najvie isplati jer povecavanje preventivnih trokova smanjuje broj defekata koji idu kupcu neotkriveni i tako se unapreduje kvalitet proizvoda i smanjuju trokovi proizvodnje i odravanja. 2. Verifikacija ili validacija: Verifikacija omogucava da proizvod zadovolji zahtevekoji si specificirani tokom prethodnih aktivnosti i oblikovani kroz ivotni ciklus proizvoda, a validacija zadovoljenje zahteva kupaca na kraju ivotnog ciklusa proizvoda. Kreiranje test proizvoda je blie validaciji nego verifikaciji. Testiranje softvera se posmatra kao validacioni proces. Nakon zavretka programiranja sistem se validira ili testira da bi se odredile funkcionalne ili operativne performanse. Naravno, savremeni procesi testiranja se ne odvijaju samo nakon zavretka programiranja, vec su utkane u sam proces razvoja softvera. Dobitna kombinacija je koricenje verifikacije i validacije u procesu testiranja. Verifikacija obuhvata sistematicne procedure pregleda, analize i testiranja ugradene u ivotni ciklus, pocevi od faze softverskih zahteva, do faze kodiranja. Verifikacija obezbeduje kvalitet i odravanje softvera. Koncept verifikacije ukljucuje dva kriterijuma: softver mora adekvatno i korektno izvravati sve funkcije i ne sme izvravati one funkcije koje sam po sebi ili u kombinaciji sa ostalim funkcijama mogu degradirati performanse citavog sistema. Verifikacija takode omogucava interoperabilnost medu razlicitim sekcijama u softverskoj dokumentaciji i povezanim delovima zahteva. Jedina kritika verifikacije je da povecava trokove razvoja softvera. Kada se trokovi softvera posmatraju kroz citav ivotni vek proizvoda, verifikacija zapravo umanjuje trokove softvera. Uz efektivan proces verifikacije redukuju se defekti instaliranih sistema. Ukupna uteda prevazilazi pocetni troak, jer ispravka greaka moe kotati 20 do 100 puta vie za vreme operacija i odravanja sistema, nego za vreme dizajniranja. Jednostavno je uoiti razliku izmeu specifikacije programa (odreuje ta program treba da radi, a esto i na koji nain), specifikacije arhitekture (prikazuje arhitekturu programa, tj. komponente unutar programa i njihove odnose) i detalje specifikacije programa ( opisuje kako se primenjuje svaka komponenta programa ). Ukoliko su specifikacije u hijerarhijskim odnosima, program se moe testirati u razliitim fazama razvoja. Na osnovu hijerarhije programa specifikacije, evidentni su razliiti nivoi testiranja:3

1. Testiranje jedinice (podrazumeva testiranje svake jedinice kao osnovne komponente u cilju odreivanja korektnosti) 2. Testiranje integracije programa korak po korak ( sa sve veim i veim komponenata programa koje se integriu ali i testiranjem sve do onog momenta kada funkcioniu kao celina) 3. Sistemsko testiranje ( program se integrie u proizvod koji se moe nazvati konaan proizvod i potom se vri testiranje da se utvrdi da i su ispunjeni svi zahtevi) 4. Testiranje prihvatanja (vri se prihvatanje gotovog programa i esto se koristi podskup sistemskih testova) Proces testiranja Testiranje se sastoji od sledecih aktivnosti: 1. Planiranje testiranja (odreduje se predmet, cilj i razlog testiranja( na osnovu zahteva, modela i drugih ulaza testiranja), gde se testiranje vri, kada se vri i ko izvrava testove) 2. Dizajn testova (odreduje kako se sprovodi testiranje na osnovu artefakta tj. Testprimera) 3. Implementacija testova (pravljenje viestruko upotrebljivih test scriptova koji realizuju test primere) 4. Izvravanje testova (izvravanje implementacije testa radi provere funkcionalnosti sistema) 5. Evaluacija testova (procena testova tj. validnosti izvravanja testa, analiza izlaza, pregled zbirnih rezultata, uticaj promene zahteva i ulaza na plan testiranja) Svaka od ovih aktivnosti ima ulaze i izlaze. U procesu testiranja koriste se i razliciti alati koj pospeuju proces i daju bolji uvid u rezultate(npr.Rational, Test Complete i sl.).

Slika1: Proces testiranja4

Strategija testiranja predstavlja celokupan pristup testiranju, pri emu se definiu nivoi testiranja, metode, tehnike i alati. Ukoliko bi se radilo u idealnim uslovima, strategija testiranja bila bi zajednika za celu organizaciju, kao i za sve programe unutar nje. Primena i razvoj strategije vrlo su bitni za postizanje odreenog kvaliteta programa a samim tim i realizaciju projekta. Prvi korak pri izboru strategije testiranja programa jeste specifikacija. Specifikacija predstavlja osnovnu komponentu svih definicija. Programi mogu biti veoma jednostavni ili sloeni, dok specifikacija (zavisno od veliine i primenjenih programerskih metoda) moe da bude u obliku jednog dokumenta ili da predstavlja sloenu hijerarhiju dokumenata. Ukoliko se posmatraju razliite hijerarhije programa specifikacija moe se zakljuiti da se one sastoje od tri ili vie nivoa dokumenata Organizacija procesa testiranja Proces testiranja mora se odvijati tokom svih faza ivotnog ciklusa. Za ovaj process moraju se realizovati standardizovani propisi i procedure koje definiu nacin rada I aktivnosti test odeljenja, kao i svih ucesnika u razvoju. Sve aktivnosti clanova tima koji ucestvuju u realizaciji procesa testiranja moraju biti dokumentovane i moraju pokriti sledece: - Odgovornosti i zaduenja za planiranje testa, izvrenje i evaluaciju. - Ciljeve testa, tipove koji ce se primeniti, raspored i zaduenja kod testiranja kroz plan testiranja. - Odgovarajuci materijal (dokumenta, test primeri i dr.). - Test materijal je podloan periodicnim aktivnostima kontrole kvaliteta Tipovi testiranja Inspekcije, recenzije i pregledi: Inspekcije, recenzije i pregledi su specificne tehnike fokusirane na ocenjivanje artefakata(pogodno za dokumentaciju, programski kod) i efikasne su metode za poboljanje kvaliteta i razvojnog procesa proizvoda. Sprovode se na sastancima, gde jedan od ucesnika ima ulogu vodeceg, a ostali uloge zapisicara(belei pitanja, predloge, probleme i sl.). Ove tehnike opisuju se u okviru IEEE standarda na sledeci nacin: Recenzija (review) formalni stastanak na kome se artefakt ili skup artefakata predstavlja korisniku ili drugim stranama koje ucestvuju u procesu odobravanja ili komentarisanja. Inspekcija (inspection) fomalna tehnika procene u kojoj se artefakti detaljno pregledaju. Pregled vre osobe koje nisu autori, da bi se lake uocile greke i drugi problemi. Pregledi (walkthrough) Tehnika pregleda u kojoj autor upoznaje ostale clanove tima sa elementima artefakta koji je izgradio. Ostali clanovi ucestvuju aktivno u raspravi. Tehnike testiranja 1. Jedinicno testiranje (unit testing) primenjuje se na pojedine klase, module ili komponente programskog koda. Ova tehnika deli se na tehnike bele i crne kutije. 2. Integraciono testiranje primenjuje se na softverski sitem kao celinu. Integraciono testiranje je faza u testiranju softvera u kojoj se pojedinani moduli softverskog sistema kombinuju i testiraju kao grupa i tako se otkrivaju greke. Ovo testiranje se deava pre sistemskog, a nakon jedininog testiranja. 3. U testiranja vieg reda spadaju: - testiranje sigurnosti (security testing): da li su funkcije dostupne onim i samo onim korisnicima kojima su i namenjene. - testiranje kolicine podataka verifikovanje da li softver moe obraditi veliku kolicinu podataka.5

- testiranje upotrebljivosti(usability testing) estetski aspekti, konzistentnost korisnickog interfejsa, korisnicka dokumentacija. - testiranje integriteta(integrity testing) robusnost(otpornost na otkaze), konzistentna upotreba resursa i sl. - test u stresnim uslovima(stress testing) vrsta testa pouzdanosti sistema pod nenormalnim uslovima (velika opterecenja sistema, nedovoljno memorije ili drugih resursa, neraspoloivi servisi i sl.). - etalonski test - uporedenje performansi novog sistema sa nekim, referentnim, poznatim sistemom. - test zaguenja provera da li sistem moe da zadovolji viestruke zahteve razlicitih aktera za istim resursom. - test opterecenja vrsta testa performansi kojim se procenjuju operativni limiti nepromenjivog sistema pod razlicitim opterecenjima ili razlicitih konfiguracija sistema pri istom opterecenju. Najcece se mere protok i vreme odziva (srednja i granicna vrednost). - test konfiguracije (configuration testing) testira ponaanje softvera u razlicitim hardversko/softverskim okruenjima. - test instalacije(installation testing) testira instaliranje softvera na razlicitim sistemima i u razlicitim situacijama (npr. prekid napajanja ili nedovoljno prostora na disku). 4. Regresiono testiranje na osnovu jednom razvijenog testa vie puta se sprovodi testiranje softvera (tipicno nakon neke izmene u softveru da bi se utvrdilo da nisu pokvarene funkcionalnosti softvera). ...pregled tehnika testiranja Testiranje se posmatra kao posebna faza ivotnog ciklusa proizvoda koja prati kodiranje. Moderni model softverskog ivotnog ciklusa izbegava ovakvo gledanje na stvari i u prvi plan stavlja iterativno testiranje kroz razvoj ivotnog ciklusa. Testiranje omogucava ranu detekciju greaka i ispravku istih i tehnicki uvid u pravu prirodu performansi sistema. Obicno se koristi nekoliko testnih metodologija da bi se obradili razliciti aspekti softverskog proizvoda. Kako su do sada objanjeni samo neki od tipova i tehnika testiranja u tabeli je dat pregledsavremenih tehnika testiranja sa opisom. Tehnike se kombinuju i variraju.

Tehnika Acceptance testing Testiranje prihvatljivosti

Kratak opis Finalno testiranje bazirano na specifikacijma krajnjeg korisnika/potroaa, ili bazirano na korienju krajnjih korisnika/potroaa u odreenom vremenskom periodu. Slino istraivakom testiranju, ali se esto odnosi na to da testeri dobro razumeju softver pre samog testiranja.

Ad hoc testing Ad hoc testiranje

6

Alpha testing Alfa testiranje

Testiranje kada je razvoj pri kraju; manje promene u dizajnu mogue su kao rezultat ovog testiranja. Obino ga izvravaju krajnji korisnici ili drugi, a ne programeri i testeri. Identifikovanje testova na bazi tokova i putanja programa ili sistema. Kada su razvoj i testiranje u sutini zavreni i potrebno je pronai konane greke i probleme pre samog lansiranja proizvoda. Obavljaju ga krajnji korisnici ili drugi, ne programeri ili testeri. Testovi se generiu na osnovu funkcionalnosti sistema. Integrisanje modula ili programa poevi od dna. Testovi se generiu iz graninih vrednosti odgovarajuih klasa. Verifikacija da svaka grana ima true ili false izlaze. Verifikacija da svaki uslov obuhvata sve mogue izlaze . Oznaavanje viestrukih simultanih ulaza koji mogu uticati na uslove testa. Uporeivanje slabosti i dobrih strana softvera sa konkurentskim proizvodima. Testiranje koliko dobro softver radi u odreenom hardversko/softverskom/OS/mrenom okruenju. Potvrda da svaki uslov obuhvata sve mogue izlaze. Pravljenje CRUD matrice i testiranje svih

Basis path testing Testiranje osnovnih tokova Beta testing Beta testiranje

Black-box testing Black-box testiranje

Bottom up testing Testiranje od dna ka vrhu Boundary value testing Testiranje graninih vrednosti Branch coverage testing Branch(gransko) testiranje Branch/condition coverage Grana/uslov testiranje Cause/effect graphing Uzrok/posledica graf Comparison testing Uporedno testiranje

Compatibility testing Testiranje kompatibilnosti

Condition coverage testing Testiranje pokrivenosti uslova CRUD testing CRUD testiranje

7

kreacija objekata, itanja, auriranja i brisanja. Database testing Testiranje baze podataka Decision tables Tabele odluka Provera integriteta vrednosti u poljima baze podataka. Tabele koje pokazuju kriterijume odluke i respektivne akcije. Developer pregleda kod. Slino sistemskom testiranju, ukljuuje test kompletnog okruenja aplikacije u situaciji kada se oponaa stvarni korisniki svet, npr. interakcija sa bazom podataka, korienje mrene komunikacije, ili interakcija sa drugim hardverom, aplikacijama ili sistemima. Svaki ulazni uslov se deli na dve ili vie grupa. Testovi se generiu iz reprezentativnih validnih ili nevalidnih klasa. Identifikovanje poruka o greci i obrade izuzetaka i uslova koji ih okidaju. esto oznaava kreativno, neformalno testiranje koje se ne bazira na formalnim test planovima ili test case-ovima; testeri ue o softveru za vreme testiranja. Korienje ad hoc ili brainstorming intuicije za definisanje test case-ova. Kombinacija Black-box i white-box testiranja, kako bi se izvukle najbolje strane oba ova tipa. Grafika reprezentacija izmerenih vrednosti organizovanih prema frekvenciji dogaanja koja se koristi da naglasi vrue take. Kontinualno testiranje aplikacije kada se

Desk checking Provera End-to-end testing Sa kraja na kraj testiranje

Equivalence partitioning Ekvivalentno particionisanje

Exception testing Testiranje izuzetaka

Exploratory testing Istraivako testiranje

Free form testing Slobodna forma testiranja Gray-box testing Gray-box testiranje

Histograms Histogrami

Incremental integration testing

8

Inkrementalno integraciono testiranje

doda nova funkcionalnost, zahteva da razliiti aspekti funkcionalnosti aplikacije budu dovoljno nezavisni da rade zasebno, pre kompletiranja svih delova programa. Izvravaju ga testeri ili programeri. Formalni pregled koji koristi ekliste, ulazne i izlazne kriterijume. Testiranje kombinovanih delova sistema radi utvrivanja da li zajedno dobro funkcioniu. Delovi mogu biti kodni moduli, individualne aplikacije ili klijent/server aplikacije na mrei. Ovaj tip testiranja je jako vaan za klijent/server i distribuirane sisteme. Tehnika koja spaja korisnike i developere pri dizajnu sistema. Testiranje aplikacije pod optereenjem. Metod odreivanja da li je skup testnih podataka ili testova koristan, namernim uvoenjem raznih promena u kodu(bugs) i retestiranje sa originalnim test podacima/sluajevima kako bi se odredilo da li su otkrivene greke. Zahteva velike resurse. Matematika tehnika odreivanja koje varijacije parametara treba da se testiraju. Analiza paterna defekata radi identifikacije uzroka i posledica. Koristi se esto sa stres i load testovima. Definisano je u zahtevima ili test planovima. Testiranje pozitivnih i negativnih vrednosti svih ulaza. Testovi se kreiraju ili ponovo pokreu za svaki defekt koji se pronae u prethodnim

Inspections Inspekcije

Integration testing Integraciono testiranje

JADs Load testing Load testiranje Mutation testing Mutaciono testiranje

Orthogonal array testing Ortogonalno testiranje niza Pareto analysis Pareto analiza

Performance testing Testiranje performansi

Positive and negative testing Pozitivno i negativno testiranje Prior defect history testing Testiranje prethodnih defekata

9

testovima sistema. Prototyping Prototipovanje Pristup prikupljanja podataka od korisnika izgradnjom i demonstracijom nekog dela potencijalne aplikacije. Nasumina selekcija iz skupa ulaznih vrednosti, gde je svaka vrednost jednako vana. Za svaki ulaz definie se opseg za koji bi ponaanje sistema trebalo da bude isto. Testiranje koliko dobro se sistem oporavlja od padova, hardverskih otkaza ili drugih velikih problema ovog tipa. Testiranje sistema sa manjim izmenama za vreme spiralnog razvoja, debagovanja, odravanja ili razvoja u novom release-u. Meri stepen poslovnog rizika u sistemu kako bi se poboljalo testiranje. Grafiki prikaz kako karakteristike kvaliteta variraju u vremenu. Intergacija modula ili programa sa vrha i dna simultano. Inicijalni test napor kako bi se odredilo da li se novi softver dobro ponaa, kako bi se prelo na vei stepen testiranja. Npr. Ako novi softver obara sistem svakih 5 minuta, nee biti potrebno testiranje u takvom stanju. Testiranje koliko dobro sistem reaguje na neautorizovane napade. Tehnika u kojoj se prvo identifikuju stanja sistema, a potom se piu test case-ovi kako bi se testirali okidai koji prouzrokuju prelaz iz jednog stanja u drugo.

Random testing Nasumino testiranje

Range testing Testiranje opsega

Recovery testing Testiranje oporavka

Regression testing Regresiono testiranje

Risk-based testing Testiranje zasnovano na riziku Run charts Grafici izvravanja

Sandwitch testing Sendvi testiranje

Sanity testing Zdravorazumsko testiranje

Security testing Testiranje sigurnosti

State transition testing Testiranje prelaza stanja

10

Statement coverage testing Testiranje izraza Statistical profile testing Statistiko profil testiranje

Svaki izraz programa se izvrava bar jednom. Statistike tehnike se koriste da razviju korisniki profil sistema koji pomae da se definiu prelazne putanje, uslovi, funkcije i tabele podataka. Testiranje funkcionalnosti sistema pod optereenjem, ponavljanjem odreenih akcija ili ulaza, veliki ulazni brojevi ili kompleksni upiti nad bazom. Tehnika za upravljanje sastankom na kom uesnici projekta ispituju rad proizvoda. Tehnika voena podacima i test kombinacijama ulazne sintakse. Black-box tip testiranja koji se bazira na zahtevima; pokriva sve kombinovane delove sistema. Testiranje pristupa, sigurnosti i integriteta podataka tabela ulaza. Kombinovanje individualnih jedinica u okviru niti funkcionalnosti koje zajedno postiu neku funkciju ili skup funkcija. Integracija modula ili programa poevi od vrha. Mikro testiranje odreenih funkcija ili modula koda. Obino ih obavlja programer, a ne tester, jer zahteva detaljno poznavanje internog dizajna i koda programa. Test izgleda aplikacije za korisnika. Subjektivno je i zavisi od ciljne grupe korisnika. Koriste se intervjui, video zapisi i druge tehnike. Programeri i testeri ne odgovaraju za ovaj tip testiranja. Testovi se definiu ispitivanjem logikih

Stress testing Stres testiranje

Structured walkthroughs Strukturni pregledi Syntax testing Sintaksno testiranje

System testing Sistemsko testiranje

Table testing Tabelarno testiranje

Thread testing Testiranje niti

Top-down testing Testiraje od vrha ka dnu Unit testing Jedinino testiranje

Usability testing Testiranje korisnosti

White-box testing White-box testiranje

11

iskaza sistema. Tabela 1.Opis tehnika za testiranje Cesta je i podela testiranja na: 1. black-box, white-box i gray-box testiranje, 2. manuelno i automatsko testiranje, 3. staticko i dinamicko testiranje. Metoda bele kutije "White-box" Ovo testiranje proverava i analizira izvorni kod i zahteva dobro poznavanje programiranja, odgovarajueg programskog jezika, kao i dizajna konkretnog softverskog proizvoda. Plan testiranja se odreuje na osnovu elemenata implementacije softvera,kao to su programski jezik, logika i stilovi. Testovi se izvode na osnovu strukture programa. Kod ove metode postoji mogunost provere skoro celokupnog koda, na primer proverom da li se svaka linija koda izvrava barem jednom, proverom svih funkcija ili proverom svih moguih kombinacija razliitih programskih naredbi. Specifinim testovima moe se proveravati postojanje beskonanih petlji ili koda koji se nikada ne izvrava. Kodna pokrivenost je navedena u 6 sledeih koraka: Segment pokrivenost svaki segment koda u B/W kontroli strukture se izvrava makar jednom Podruna rasprostanjenost ili vorno testiranje svaki ogranak u kodu se koristi u jednom moguem smeru barem jednom Sloeno stanje rasprostranjenosti kada postoji vie uslova, mora se testirati ne samo svaki smer, ve i sve mogue kombinacije uslova, to se obino obavlja pomou kombinacijske tabele (Truth Table) Osnovni put testiranja svaka nezavisna staza kroz kod koristi prethodno definisan niz Testiranje toka podataka u ovom pristupu, skup srednjih staza kroz kod definie praenje specifinih promenljivih kroz svaki mogui proraun. Praenje se zasniva na svakom odabranom pojedinanom delu koda.Iako ove staze smatraju nezavisnim, zavisnosti izmeu viestrukih staza zapravo nisu testirane za ovaj pristup. DFT (Data Flow Testing) tei da odrava zavisnosti, ali to je uglavnom kroz manipulaciju sekvenci podataka. Ovaj pristup prikazuje skrivene bugove i koristi ih kao promenljive, deklarie ih ali ih ne koristi. Put testiranja put testiranja definie i pokriva sve mogue puteve kroz kod. Ovo testiranja su vrlo teka i dugotrajana. Testiranje petlje ove strategije se odnose na testiranju jedne petlje, grupnih petlji i ispletenih petlji. Zavisnost petlji je prilino jednostavno testirati, osim ako postoji meu petlja ili kod sadri B/W petlju.

U White box testingu, koristi se kontrola strukture proceduralnog dizajna za dobijanje test sluajeva. Korienjem White box testing metoda jedan tester moe izvui probne sluajeve koji:

12

Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom. Izvravaju sve logike odluke o njihovoj istinitosti ili lanoj vrednosti Izvlae sve petlje na sopstvenim granicama i unutar svojih dozvoljenih operativnih granica. Upotrebljava unutranje strukture podataka kako bi obezbedio njihovu valjanost.

Metoda crne kutije "Black-box" Analizira se samo izvravanje specificiranih funkcija i vri se provera ulaznih i izlaznih podataka. Tanost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver. U ovim testovima se ne vri analiza izvornog koda. Problem funkcionalnog testiranja moe da se pojavi u sluaju dvosmislenih zahteva i nemogunosti opisivanja svih naina korienja softvera. Skoro 30% svih greaka u kodu posledica su problema nepotpunih ili neodreenih specifikacija. Sinonimi za black box ukljuuju: ponaanje, funckionalnost, neprozinost i zatvorenost Testiranjem se pokuavaju pronai greke u sledeim kategorijama: Neispravna ili nepotpuna funkcija Greka interfejsa Greka u strukturi podataka ili u pristupu spoljnoj bazi podataka Greka performanse Greka inicijalizacije i greka izvravanja

Primenom metode crne kutije izrauje se skup test sluajeva koji ispunjavaju zahteve: Test sluaja koji smanjuju broj test sluaja na mogunost razumnog testiranja Test sluaja koji e nam prikazati prisutnost ili odsutnost klase greaka Prednosti Black box testinga Testiranje moe biti ne tehniko Ovo testiranje e najverovatnije pronai one bugove koje je korisnik pronaao Testiranje pomae u identifikovanju nejasnoa i protivrenosti funkcionalnih specifikacija Test sluajevi mogu biti izraeni po zavretku funkcionalnih specifikacija Nedostatci Black box testinga anse za ponavljanje testova koje je ve odradio proramer Test inputa zauzima veliki deo prostora Teko je utvrditi sva mogua testiranja ulaza u ogranienom vremenu. Pisanje test sluaja je prilino sporo i teko anse za posedovanje neidentifikovanih staza tokom testiranja

13

Alati koji se koriste u Black box testingu Osnovni funkcionalni alati testiranja izvode rezultate testova crne kutije u obliku skripte. Jednom izvedene, ove skripte mogu koristiti u buduem razvoju softvera,kao aplikacija koja verifikuje novu funkcionalnost a da ne onemogui prethodnu. Ekvivalentno particionisanje Ekvivalentno particionisanje je metoda testiranja crne kutije koja deli ulazni softverski domen u klasu podataka od kojih se izrauju u test sluajevi. Idealan test sluaja otkriva klasu greaka pre nego to je greka detektovana. Ekvivalentnost particionisanja pokuava da identifikuje naznaenu klasu greaka u test sluaju. Dizajn test sluaja za ekvivalentnost particionisanja je zasnovano na planiranju ekvivalentnih vrednosti unosa (inputa). Ekvivalentne vrednosti prikazuju skup vaeih i nevaeih ulznih uslova (input conditions) u sistemu. Ekvivalentna vrednost moe da se odreuje na osnovu sledeeg: Ako je ulazni uslov (input conditions) specifian niz, jedna vaea i dve nevaee ekvivalentne vrednosti su definisane Ako ulazni uslov (input conditions) zahteva specifinu vrednost, jedna vaea i dve nevaee ekvivalentne vrednosti su definisane Ako je ulazni uslov (input conditions) lan specifinog niza, jedna vaea i jedna nevaea ekvivalentna vrednost je definisana Ako je ulazni uslov (input conditions) Bulova, jedna vaea i jedna nevaea ekvivalentna vrednost je definisana

Manuelno i automatsko testiranje Osnove manuelnog testiranja pocivaju na tome da su njegovi nosioci ljudi i da nije implementirano na racunaru; osnove automatskog, upravo na tome da je implementirano na racunaru. Staticko i dinamicko testiranje Staticko testiranje ne zavisi od vremena npr. provera sintakse, strukture i sl. Dinamicke tehnike zavise od vremena i podrazumevaju izvravanje specificnog niza instrukcija na papiru ili racunaru.

14

PISA (Poslovno Inteligentna Simulaciona Arhitektura) Kratak opis projekta OptimalSQM predstavlja skup njboljih model i tehnik iz prkse, integrisnih u optimizovn i kvntittivno rukovoen proces rzvoj, testirnj i odrvnj softver koji zadovoljava 3, 4 i 5-ti nivo zrelosti kompanije u pogledu testiranja softvera (TMM). To su pre svega ekspertski alati koji se integrisu na zahtev korisnika. Okruenje z simulciju scenrij rzvoj kvlitetnog softver koje omoguv minimizciju trokov i rizik, izborom lterntivnih plnov testirnj koji zdovoljvju ogrnienj u pogledu slobodnih resurs, kriterijum optimlnosti i performnsi dte kompnije i ekonomski model kvlitet softver z ocenu ispltivosti predloenih ktivnosti SQA, mere z poboljnje PRS-PTS(Proces Razvoja Softvera, Proces Testiranja Softvera) n osnovu ekonomskih prmetr. Razvoj softvera troi vie od polovine svog budeta na aktivnosti povezane sa testiranjem u toku projektovanja softvera i na odravanju softvera nakon njegove predaje na upotrebu. Tabela 2 - Nivoi zrelosti TS tzv. TMM levels TMM Nivo 1 Inicijalna faza: Testiranje softvera (TS) je haotian proces; loe je definisan i nije jasno razgranien sa fazom otklanjanja greaka (debugging). Testiranju se pristupa neplanirano i na kraju faze kodiranja programa. Cilj testiranja softvera je da se pokae da program radi. Softver se iznosi na trite bez primene sistema obezbeenja kvaliteta. Nedostaju resursi, alati i adekvatno obuen kadar. Ovaj tip organizacije odgovara SEI CMM Level 1, zrelosti softverske kompanije. TMM Nivo 2 Faza Definisana: Testiranje softvera je odvojena od faze otklanjanja greaka (debugging) i definisano je kao odvojena faza nakon kodiranja. Mada je planirana kao aktivnost, Testiranje softvera na Nivou 2, je definisano nakon faze kodiranja zbog nezrelosti samog procesa Testiranja softvera. Glavni cilj Testiranja softvera, na ovom nivou zrelosti (TMM), je da se pokae da je softver zadovoljio specifikaciju. Primenjuju se osnovne tehnike i postupci. Mnogi problemi vezani za kvalitet softvera na ovom TMM nivou posledica su planiranja TS kasno u ciklusu razvoja softvera (SDLC). Dalje, greke (otkazi) softvera u ranim fazama propagiraju se do zadnjih faza SDLC tj. ne otkrivaju se blagovremeno, odnosno onda kada se i generiu. TMM Nivo 3 Faza Integrisanja: TS nije vie faza koja sledi fazu kodiranja, naprotiv, TS je integrisani deo SDLC. Organizacije koje su ovladale TMM Nivo 2, za razliku od TMM Nivoa 2, na Nivou 3 aktivnost TS se odvija i planira od poetka SDLC tj. projektnih zahteva za softver pa do kraja najee V modela SDLC. Ciljevi i zadaci TS su utvreni na bazi zahteva klijenata i moguih kupaca softvera i koriste se u fazi dizajna test primera i kriterijuma uspenog odziva testa. Organizaciono je uspostavljena grupa za TS, a TS je profesionalni posao lanova tima. Obuka kadra je15

fokusirana na oblast TS. Osnovna sredstva, alati za TS su u upotrebi. Iako organizacije na ovom TMM nivou znaju za znaaj kontrole i obezbeenja kvaliteta, ova funkcija nije formalno primenjena u SDLC. Program merenja kvaliteta TS kao i samog kvaliteta softvera kao proizvoda nije jo uspostavljen. TMM Nivo 4 Faza Merenja i Upravljanja: Proces TS se meri i kvalitet (cena, efikasnost, efektivnost) ocenjuje. Inspekcije i revizije se primenjuju planski u svim fazama SDLC kao obavezna aktivnost u TS i kontroli kvaliteta. Softverski proizvod se testira radi ocene faktora kvaliteta kao to su pouzdanost, upotrebljivost i pogodnost za odravanje. Aurira se baza podataka o test-primerima sa svih projekata radi ponovne upotrebe pri regresionom (ponovljenom) testiranju. Otkazi, greke, se evidentiraju u bazi podataka o otkazima, grekama i dodeljuje im se znaaj (kritinost). Nedostatak TS na ovom TMM nivou je i dalje primenjena preventivna aktivnost generisanja softverskih greaka, slabo razvijena metrika kvaliteta TS kao i sredstva automatizacije TS. TMM Nivo 5 Faza Optimizacije, Prevencije greaka i Kontrola kvaliteta: Nakon uspene izgradnje infrastrukture kroz sazrevanje TMM od Nivoa 1 do 4, za koji se moe rei da je TS definisan i kontrolisan, preko metrika kao to su trokovi, efikasnost, efektivnost sada se na TMM Nivo 5 pristupa finom podeavanju i stalnom unapreenju kvaliteta TS. Proces TS je kontrolisan statistikim postupcima uzorkovanja i merenja nivoa poverenja metrika kvaliteta TS kao to su trokovi, efikasnost, efektivnost. Uspostavljena je procedura za izbor i ocenu sredstava i alata za TS. Automatska sredstva TS se koriste u svim fazama testiranja softvera dizajnu test primera, izvravanju testova, ponovnom izvravanju, auriranju baze podataka o otkazima, grekama, alati za metriku, praenje generisanja i analizu uzroka istih kao i sredstva odravanja tzv. Testware. Razvoj softvera obuhvata: Precizno planiranje(resursa, trokova, trajanja, obuke kadra i td.) Identifikaciju, procenu i kontrolu rizika na softverskom projektu Utvrivanje merenja kvaliteta softverskog proizvoda Kvantitativno upravljanje procesom testiranja tj. aktivnostima osiguranja kvaliteta softvera u cilju poveanja efikasnosti i efikasnosti otkrivanja i otkrivanja greaka u toku razvoja softvera.

Poto je nemogue izvriti testiranje i dokazati da je softver bez greke kako u fazi razvoja tako i u fazi odravanja softvera cilj ovog projekta bi bio da se predloi model razvoja, odgovarajue metode, algoritmi i odgovarajue softverski alati za integralni i optimizirani proces testiranja i odravanja softvera. U postizanju to boljeg kvaliteta softverskog proizvoda optimizacija se vri uz navedena ogranienja u pogledu vremena i predvienog budeta.

16

Slika 2. Arhitektura OptimaISQM-a i Komponente softverske arhitekture OpimalSQM reenja OptimalSQM 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.

17

OQT SIM componenta 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 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.

18

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.

19

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.

20

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.

21

22

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.

1.1

Slika 3. Softverski alati, tehnike i modeli koje nudi nae OptimalSQM reenje 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 kontrola23

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.

Realizacijom servisno orijentisane arhitekture (PISA) sa integrisanim ekspertskim alatima (Profit eXpert, Planner eXpert, Risk Management eXpert, Quality eXpert, Maintenance eXpert, People Performance eXpert and Process Dynamics Control eXpert) bie ponueno OptimalSQM reenje, koje se sastoji od skupa softverskih servisa koji se integriu na zahtev da bi se optimalno upravljalo procesom razvoja kvalitetnog softvera. OptimalSQM reenje e biti izbalansirano i unificirano tako da nudi potpun repertoar servisa obezbeenja i kontrole razvoja kvalitetnog softvera na efikasan, efektan i konzistentan nain, izborom najboljih strategija i tehnika (zasnovane na simulaciji vie scenarija) testiranja softvera (TS) na poetku softverskog projekta. Malim i srednjim preduzeima koja razvijaju softver, prvenstveno, bie ponuen kao proizvod: 1) Web portal - repozitorij najboljih modela i tehnika iz prakse, integrisanih u optimizovan i kvantitativno rukovoen proces testiranja i odravanja softvera; 2) softversko okruenje za optimalan razvoj kvalitetnog softvera (bre, bolje i jeftinije od drugih reenja) koje omoguava minimizaciju trokova i rizika, izborom i prelaenjem na alternativne planove testiranja, kada trenutni24

izbor ne moe da zadovolji ogranienja koja postavljaju zahtevi kvaliteta, slobodni resursi (ljudi i oprema), kvantitativni kriterijumi optimalnosti i stabilnosti koji se uspostavljaju na bazi raspoloivih resursa i performansi date kompanije i 3) na bazi izraenog ekonomskog modela kvaliteta softvera oceni isplativost predloenih aktivnosti obezbeenja i kontrole kvaliteta, kao i mera za stalno poboljanje PRSPTS na osnovu ekonomskih parametara (ROI, BCR, CAPEX, OPEX i dr.). Menadment (odgovoran za projektovanje i testiranje) softverskog projekta e na brz i jednostavan nain izraivati: glavni plan testiranja na bazi utvrene metrike kvaliteta softvera, izgraditi testno okruenje (oprema i softver tzv. Testware), strategiju i opis aktivnosti u implementaciji automatizovanog procesa TS, test sluajeve za svaku odabranu tehniku TS, izvetaje o uoenim problemima tokom TS i postignutim rezultatima u odnosu na plan TS, predloga izmena u dokumentima planiranog PRS-PTS tzv. Upravljanje konfiguracijom i sve izvetaje o performansama procesa TS (efiksanosti, trokovima, rizicima) i kvalitetu softverskog proizvoda koje menadment zahteva.

Takoe, OptimalSQM reenje e ponuditi menadmentu softverskog projekta itav spektar servisa 4. i 5. nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM metodologiji, na njihov zahtev, kao to su: 1. Menadment servisi ostvarenog u odnosu na planiranu dobit softverskog projekta u toku PRS-PTS 2. Kvantitativno upravljanje softverskim projektom (veliinom softvera, trokovima, potrebnim resursima, procenu trajanja pojedinih poslova i zadataka na projektu i sl.) 3. Kvantitativno upravljanje rizicima (Ocenjivanje rizika preko identifikacije kritinih rizika na projektu i preporuke kako se ti rizici mogu smanjiti i drati pod kontrolom na prihvatljivom nivou. Kvantitatino e moi odreivati upotrebu resursa u procesu TS koji daju najbonje rezultate). 4. Kvantitativna predikcija i ocenjivanje pouzdanosti softverskog proizvoda 5. Prilagoen (datoj) kompaniji proces merenja P3 (Proizvoda, Projektnih procesa, Projektanata) Kljuna metrika i merenje kvaliteta softverskog proizvoda kao to su merenje veliine, prekrivenost projektnih zahteva, upravljanje defektima i sl. Kljuna metrika i merenje napredovanja na projektu , i Kljuna metrika i merenje performansi projektnog tima, koji skupa pruaju mogunost da menadmnjnt projekta moe kvantitativno ocenjivati efikasnost i efektivnost realizacije projekta i da identifikuje rizike na softverskom projektu. Procenjuje se, na osnovu do sada obvjavljenih rezultata istraivanja u okviru projekta TR13018, da e za tri godine primene predloenog softverskog okruenja sa integrisanim ekspertskim alatima, dovesti do povraaja investicije tj. ROI od 100:1, odnosno za svaku investiranu monetarnu jedinicu dobie se 100 novanih jedinica u odnosu na postejee modele i infrastrukturu PRS-PTS softverske kompanije 1 i 2 nivoa CMM i TMM zrelosti. Vaan cilj projekta je i da se sprei odliv strunih kadrova iz regiona, a pre svega omogui da eksperti iz oblasti matematike, informatike i raunarstva ostanu u regionu i nakon odbrane magistarskih i doktorskih disertacija, rade na Univerzitetu u Novom Pazar, kao i u centru, koji e sluiti kao podrka poslovanju malih i srednjih preduzea, posebno onih koji se bave razvojem i odravanjem softvera. Predloeni projekt je u tom smislu u potpunosti usklaen sa osnovnom idejom finansiranja nauno-istraivakog rada u Evropi, koji treba da bude u funkciji podrke poslovanja i razvoja malih i srednjih preduzea kao i podrke komercijalizaciji naunih rezultata.

25

Strategijom naunog i teholokog razvoja predvien je intenzivan razvoj IKT, emu direktno doprinosi ovaj projekat. Osim toga, projekat je znaajan i sa stanovita tehnolokog razvoja regiona, jer je Dravni univerzitet u Novom Pazaru njegov nosilac. Takoe, ovaj projekat je logian nastavak projekta TR13018, iji ostvareni rezultati istraivanja, posebno koncept Poslovne Inteligentne Simulacione Arhitekture-PISA ulivaju poverenje u njegov uspeh. Pregledi, inspekcije i testiranje softvera (TS), kao aktivnosti osiguranja kvaliteta (SQA) su bitan preduslov za uspean razvoj i implementaciju IKT. Industrija razvoja softvera troi vie od polovine svog budeta na aktivnosti povezane sa testiranjem u toku projektovanja softvera i na odravanje softvera nakon njegove predaje na upotrebu. Razvoj kvalitetnog softvera je jako sloen i nepouzdan posao, ali je upravljanje sloenim procesom razvoja i testiranja (PRS-PTS) jo tee bez adekvatnog softverskog okruenja sa integrisanim tehnikama, procedurama i alatima koje obezbeuju razvoj kvalitetnog softvera u okviru planiranog budeta i trajanja razvoja (OptimalSQM). Ova tvrdnja je evidentna, ako se proui poznati izvetaj Chaos Report, USA Standish Group kompanije iz 2001, na bazi 8,000 pregledanih velikih projekata, u kome je konstatovano da 25% velikih projekata nikada nije zavren usled znatnog prekoraenja u trokovima, vremenu razvoja, loem kvalitetu ili njihovom kombinacijom. Takoe je proseno 90% vie potroeno od planiranog, preko 120% je due trajao razvoj od planiranog kod zavrenih projekata. Takoe, veliku podrku ovom istraivanju i pristupu PRS-PTS dao je i izvetaj Amerikog Instituta za standarde i tehnologije (NIST) iz 2002, koji je ukazao da se izgradnjom pomenutnog adekvatnog softverskog okruenja sa infrastrukturom efikasnog i efektivnog PRS-PTS, na bazi veoma opirnog uzorka analiziranih softverskih projekata u finansijskom sektoru i oblasti saobraajne grane industrije, mogu postii znaajne utede u ovim privrednim granama (izmeu $600 i $1.500 miliona dolara). Da bi se realizovalo softversko okruenje OptimalSQM, istraivanja u okviru ovog projekta e se fokusirati na dalju razradu i dogradnju PISA, sa odgovarajuim softverskim komponentama koje omoguavaju dizajnerima softvera da postignu vii kvalitet dizajna, bolji uvid u predvianje kvaliteta izabranog dizajna, rukovodiocu testiranja da omogui unapreenje PRS-PTS kroz ocenu efikasnosti i efektivnosti alternativnih planova SQA upotrebom naprednih, kvantitativnih modela simulacije procesa detekcije i uklanjanja defekata, potrebnih resursa tokom PRS-PTS na sistematski i automatizovan nain. PISA treba da obezbedi potpun spektar servisa koji zadovoljavaju najvie nivoe (4 i 5 nivo zrelosti PRS-PTS po SEI CMM i TMM metodologiji) za razvoj kvalitetnog softvera na optimalan nain. Istraivanje reenja PISA se sastoji u: 1) izradi kolekcije najboljih znanja reenja iz prakse, metoda, ablona smetenih u bazi znanja; 2) automatizaciji procesa planiranja zasnovanog na modelima estimacije veliine softvera, cene, broju projektanata, trajanja razvoja i testiranja; 3) optimizaciji PRSPTS zasnovane na modelovanju i simulaciji kroz razliite nivoe apstrakcije softvera koji testiramo, a u cilju postizanja stabilnog (predvidljivog i kontrolabilnog) procesa testiranja softvera sa najniim rizikom, po prihvatljivoj ceni i u prihvatljivom vremenu. Optimalno reenje se odreuje na bazi scenarija angaovanja resursa na poetku projekta (na osnovu sopstvenih ili iskustvenih podataka iz prakse drugih kompanija) kao i u toku same realizacije PRS-PTS; 4) izradi okruenja za komjutersko eksperimentisanje po principima planiranog eksperimenta (Design of Experiments) sa razraenim pravilima preko arobnjaka tzv. Rules by wizards; 5) implementaciji integrisanog procesa merenja kvaliteta softvera; 6) izradi ekonominog modela kvaliteta softvera i tehnika upravljanja trokovima realizacije PRS-PTS; 7) razradi metodologije upravljanja rizikom PRS-PTS; 8) izradi balansirane metrike produktivnsti, usagleene sa strategijom balansirane tabele eljenih i postignutih rezultata (Balanced Scorecard) na putu dostizanja 4 i 5 nivoa zrelosti PRS-PTS (po SEI CMM i TMM metodologiji) i est sigma strategiji stalnog poboljanja PRS-PTS; 9) izradi grafikog korisnikog interfejsa za konkurentan, jednostavan rad veeg broja lanova tima, zasnovan na internet tehnologijama (Web-based GUI) radi izvoenja velikog26

broja simulacija i deljenja rezultata obavljenih simulacija, i 10) da omogui razmenu podataka i dokumenata sa standardnim radnim okruenjem lanova tima jedne kompanije u obavljanju poslova planiranja, rasporeda poslova, estimacije trokova, resursa kao to su: MS Office, MS Rroject i drugi specijalizovani softverski alati). PISA treba, u osnovi, da bude zasnovana na servisno orijentisanoj arhitekturi ( SOA) sa integrisanim ekspertskim alatima (Profit eXpert, Planner eXpert, Risk Management eXpert, Quality eXpert, Maintenance eXpert, People Performance eXpert and Process Dynamics Control eXpert) za sve modele PRS-PTS. 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.). 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. 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. 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. 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 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: ocenjivanje i praenje performansi projektnog tima, podizanje strunog kapaciteta ljudi koji realizuju projekat korienjem softveskog alata People Performance eXpert. Oekuju se, nakon implementacije OptimalSQM reenja u malim i srednjim preduzeima, velike utede, poveanje konkurentnosti, podizanje nivoa zrelosti preduzea na 4 i 5 nivo CMM i TMM zrelosti i zadovoljstva korisnika proizvoda i usluga. Realizacijom PISA sa integrisanim opisanim ekspertskim alatima, malim i srednjim preduzeima, prvenstveno, bie ponuen: 1) Web portal-repozitorij najboljih modela i tehnika iz prakse, integrisanih u optimizovan i kvantitativno rukovoen proces testiranja i odravanja softvera; 2) okruenje za simulaciju scenarija razvoja kvalitetnog softvera koje omoguava minimizaciju trokova i rizika, izborom alternativnih planova testiranja koji zadovoljavaju ogranienja u pogledu slobodnih resursa, kriterijuma optimalnosti i performansi date kompanije i 3) ekonomski model kvaliteta softvera za ocenu isplativosti predloenih aktivnosti SQA, mere za poboljanje PRS-PTS na osnovu ekonomskih parametara (ROI i dr.). Menadment (odgovoran za projektovanje i testiranje) projekta e na brz i jednostavan nain izraivati: glavni plan testiranja na bazi utvrene metrike kvaliteta softvera, izgraditi testno okruenje (oprema i softver tzv. Testware), strategiju i opis aktivnosti u implementaciji automatizovanog procesa27

TS, test sluajeve za svaku odabranu tehniku TS, izvetaje o uoenim problemima tokom TS i postignutim rezultatima u odnosu na plan TS, predloga izmena u dokumentima planiranog PRS-PTS tzv. Upravljanje konfiguracijom i sve izvetaje o performansama procesa TS (efiksanosti, trokovima, rizicima) i kvalitetu softverskog proizvoda koje menadment zahteva. Oekuju se, nakon implementacije OptimalSQM reenja u malim i srednjim preduzeima, velike utede, poveanje konkurentnosti, podizanje nivoa zrelosti preduzea na 4 i 5 nivo CMM i TMM zrelosti i zadovoljstva korisnika proizvoda i usluga. Procenjuje se, na osnovu do sada obavljenih istraivanja na projektu TR13018, da e za tri godine primene predloenog softverskog okruenja sa integrisanim ekspertskim alatima, dovesti do povraaja investicije - ROI od 100:1, u odnosu na postejeu nfrastrukturu PRS-PTS softverske kompanije 1 i 2 nivoa CMM i TMM zrelosti. Takoe, OptimalSQM reenje e ponuditi menadmentu softverskog projekta itav spektar servisa 4. i 5. nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM metodologiji, na njihov zahtev, kao to su: 1. Menadment servisi ostvarenog u odnosu na planiranu dobit softverskog projekta u toku PRS-PTS 2. Kvantitativno upravljanje softverskim projektom (veliinom softvera, trokovima, potrebnim resursima, procenu trajanja pojedinih poslova i zadataka na projektu i sl.) 3. Kvantitativno upravljanje rizicima (Ocenjivanje rizika preko identifikacije kritinih rizika na projektu i preporuke kako se ti rizici mogu smanjiti i drati pod kontrolom na prihvatljivom nivou. Kvantitatino e moi odreivati upotrebu resursa u procesu TS koji daju najbonje rezultate). 4. Kvantitativna predikcija i ocenjivanje pouzdanosti softverskog proizvoda 5. Prilagoen (datoj) kompaniji proces merenja P3 (Proizvoda, Projektnih procesa, Projektanata) Kljuna metrika i merenje kvaliteta softverskog proizvoda kao to su merenje veliine, prekrivenost projektnih zahteva, upravljanje defektima i sl. Kljuna metrika i merenje napredovanja na projektu , i Kljuna metrika i merenje performansi projektnog tima, koji skupa pruaju mogunost da menadmnjnt projekta moe kvantitativno ocenjivati efikasnost i efektivnost realizacije projekta i da identifikuje rizike na softverskom projektu. Vaan oekivani kljuni rezultat projekta je i da se sprei odliv strunih kadrova iz regiona, a pre svega omogui da eksperti iz oblasti matematike, informatike i raunarstva ostanu u regionu i nakon odbrane magistarskih i doktorskih disertacija, rade na Univerzitetu u Novom Pazar, kao i u centru, koji e sluiti kao podrka poslovanju malih i srednjih preduzea, posebno onih koji se bave razvojem i odravanjem softvera. Predloeni projekt je u tom smislu u potpunosti usklaen sa osnovnom idejom finansiranja nauno-istraivakog rada u Evropi, koji treba da bude u funkciji podrke poslovanja i razvoja malih i srednjih preduzea kao i podrke komercijalizaciji naunih rezultata.

28