ࡱ> 3 bjbjCC  !!jl$P$L2;J=J=J=J=J=J=J$N  PaJaJN(VL0N(N(N(;JN(;JN(4N(.6 GI I GILHLHPf'PIN( Modeliranje i sumulacija procesa testiranja programskih proizvoda Zdenko Marin i, Nenad Heimovi, Lovre Hribar R&D Ericsson Nikola Tesla Krapinska 45, Zagreb, Hrvatska Telefon: +385 1 3654372, E-mail:  HYPERLINK "mailto:Zdenko.Marincic@ericsson.com" Zdenko.Marincic@ericsson.com  Sa~etak  U ovom radu opisat e se modeliranje i simulaciju procesa testiranja provedena u studijskom slu aju u telekomunikacijskoj kompaniji. I. UVOD Programski proces testiranja predstavlja glavno podru je za poboljaanje kvalitete programskog proizvoda jer su mu inherentni mehanizmi za ispravljanje neispravnosti i provjeru funkcionalnosti programskog proizvoda. Dinami ka priroda okoline u kojoj se razvija neki programski proizvod zahtijeva mjerenja i stalna poboljaanja programskih procesa. Simulacija omoguava njihovu efikasnu analizu i rezultira performansama procesa na temelju kojih se mogu predlo~iti optimalna poboljaanja. Ljudi razvijaju programske proizvode i u tome esto dolazi do odreenih neispravnosti. U svakom standardnom komercijalnom softveru postoje greake. Greake su skupe, neke viae od drugih. Tester ne mo~e sprije iti njihovu pojavu, ali ih mo~e locirati i ispraviti u ranoj fazi, osobito one kriti ne. On mora razumjeti i imati znanja implementirati pripadajue tehnike testiranja. Ispitivanje svih ulaznih elementata koji bi mogli rezultirati greakom u softveru je nemogue. Potrebno je odabratati reprezentativne ulazne elemente i pomou njih izvoditi testiranje. Njome se mogu otkriti neispravnosti u kodu, ali ne i njihovo nepostojanje. Cilj testiranja je pronai neispravnost programskog koda i otkloniti ih. Brzi razvoj ra unalne tehnologije doveo do sve veeg broja programskih produkata na tr~iate. Ono postaje jako konkurentno i proizvoa i se natje u tko e prije izbaciti novi proizvod koji e biti kvalitetan i odgovarati zahtjevima korisnika. Da bi imao te karakteristike on mora biti kvalitetno testiran. Danas je nezamislivo razviti neki programski proizvod i ne testirati ga. Ne postoji savraeni razvojni proces i vjerojatnost je vrlo velika da greake postoje. U zadnjih par godina mnogo je istra~ivanja posveeno testiranju. Razvile su se metode, programska pomagala i tehnike. Proces testiranja narastao je iz ne eg ato je proizlazilo iz osnovnih akcija ocjenjivanja izraenog programskog proizvoda u va~an dio cijelog ciklusa razvoja programskog proizvoda. S vremenom se razvija i poboljaava, a time i raste va~nost programskih procesa kao grane programskog in~enjerstva. Cilj in~enjerstva programskih procesa je poboljaanje programskih procesa, ime se posredno poboljaava kvaliteta programskih proizvoda i smanjuju troakovi proizvodnje. II. OPENITO O TESTIRANJU SOFTVERSKIH APLIKACIJA IEEE/ANSI definicija [1]: Testiranje softverske aplikacije ili programa je proces u kojem se pod strogo definiranim uvjetima analizira izvedba (rad) jedne rutine i/ili cijele aplikacije. Cilj testiranja je uo iti i ispraviti greake koje uzrokuju da krajnji rezultat nije prema zahtjevima programa ili aplikacije te u skladu s propisanim naredbama (instrukcijama). A. Osnovni pojmovi Tester  osoba koja testira softverski program ili aplikaciju Test uzorak (test case)  ulazne domene koji omoguuje jedno samostalno izvoenje testne jedinice Skup test uzoraka (test suite)  programi ili rutine povezani u jednu logi nu cjelinu Otklanjanje (debugging) pogreanog kda - analiza kda radi lokaliziranja i otklanjanja neispravnosti. Neo ekivani prestanak rada programa (failure)  izvoenje programa ne odvija se prema propisanim zahtjevima Pogreaka u softverskom programu (fault, bug)  programski kd koji uzrokuje odstupanje od predvienog rada programa Test specifikacija  dokument koji propisuje ato i kako testirati Test jedinica (test unit)  programska cjelina koja se testira Funkcionalni test (function test)  testiranje koje se izvodi na temelju funkcionalnosti softverskog programa Sustavno testiranje (system test)  testiranje koje obuhvaa cjelokupnu aplikaciju i pojedina ne programe (rutine) koje ine neki sustav Osnovni test (basic test) testiranje koje se izvodi za jednu programsku jedinicu B. Testiranje Kao i svaki proces tako i testiranje treba promatrati s aspekta efikasnosti. U tu svrhu potrebno je odabrati najbolju metodu da se analizira i ocijene rezultati testiranja za daljnja poboljaanja i primjenu odreenog programa ili aplikacije. Uspjeano i efikasno testiranje obuhvaa planiranje, vrijeme, sredstva i obvezu. Za to su zadu~eni specijalisti koji organiziraju i izvode testiranje. Oni su, takoer, zadu~eni za pripremu test specifikacija, metodologiju, test uzoraka, redoslijed izvoenja, predvianje rizika, analiza, pronala~enje i ispravak greaaka te daljnja poboljaanja. Iako se primjenjuju razli ite metode i postupci testiranje se uglavnom svodi na sljedee: Testiranje po inje od najmanje programske jedinice (rutine) i zavraava s cijelom aplikacijom. Metoda i postupci testiranja se prilagouju zahtjevima i potrebama aplikacije ili programa. Testiranje vrae specijalisti koji su razvili i primijenili softver. Ovisno o veli ini aplikacije mo~e biti uklju eno i viae osoba. Pronala~enje i ispravak greaaka (debugging) mora biti sastavni dio svakog testiranja. Bez obzira na to ato se testiranje sastoji od vrlo temeljitih priprema, metoda i postupaka ono ipak ima odreene rizike. Ti rizici se moraju predvidjeti da bi se postigla ato vea pouzdanost i efikasnost. C. Rizici u testiranju programskih proizvoda Rizik je stanje koje mo~e rezultirati gubitkom. Cijeli problem u riziku je vjerojatnost da e se gubitak dogoditi. Rizi ne situacije uvijek postoje iako se gubitak mo~da nikada nee dogoditi. Naprimjer uvijek postoji rizik od po~ara, ali se po~ari rijetko dogode. S obzirom na to da postoji mogunost od po~ara moraju se poduzeti odreene preventivne mjere kako bi se smanjila vjerojatnost da do njega doe. Rizici se ne mogu eliminirati, ali se zato mo~e smanjiti vjerojatnost da se gubitak dogodi. Kao ato je prethodno spomenuto testiranje je proces kojim se posti~e da je primjena softversikih aplikacija pouzdana, tj. smanjenje predvienih i nepredvienih greaaka. I unato  svim poduzetim mjerama uvijek postoji vjerojatnost da : va~ni podaci bit e izgubljeni, funkcioniranje (rad) aplikacije bit e naruaen, usluga prema korisniku bit e nekvalitetna, aplikacija e biti komplicirana za odr~avanje, izvedba (rad) aplikacije bit e ispod zadovoljavajue razine, aplikacija se nee moi povezati s drugim aplikacijama i sustavima. Bilo koji od navedenih gubitaka jednostavno zna i neuspjeh softverske aplikacije ato mo~edovesti do ne~eljenih posljedica kao sto su financijski gubitci, neispunjenje rokova pa i ste aj. Prema veli ini rizika e se zato i odrediti i izvraiti testiranje, ocijeniti i primijeniti metoda testiranja. Za svaki softverski program mora se primijeniti najefkasnije testiranje koje e osigurati pouzdanost i povjerenje korisnika programa (aplikacije). Ovo zvu i jednostavno, meutim dosadaanje iskustvo govori da mo~e biti izuzetno veliki broj test uzoraka za samo par linija kda. Ako bi izvraavanje svakog test uzorka iznosilo pola sekunde, onda bi za neku veu aplikaciju trebalo skoro stoljee da se izvrae svi mogui test uzorci. Ovo ne zna i da se mora odustati od testiranja. Jednostavno nema dovoljno vremena da se sve u potpunosti testira. Odluka o tome ato e se testirati mora biti temeljena na rizicima. Kada se rizik koristi kao osnova za odluku ato e se testirati tada je to racionalno razmialjanje koje za rezultat ima fokus i koncentraciju testiranja u najkriti nijim dijelovima aplikacije. Jedna od osnova za odabir testiranja je dio kda koji se naj eae izvodi. Ako se tu nalazi greaka, frekventnost izvraavanja tog dijela kda rezultirat e neuspjehom ili promaaajem u aplikaciji (programu). Primjerice, ako se isti dio kda izvodi (ponavlja) u beskona noj petlji, i u tom dijelu kda se nalazi greaka, ona e se pojaviti svaki put kada program proe kroz taj dio. Stoga je va~no da se takva greaka ato prije ispravi. D. Isplativost Efikasno testiranje je najbolji na in pronala~enja greaaka gledano s financijskog aspekta. Stoga je potrebno razmotriti sve mogue gubitke uzrokovane neuspjehom aplikacije i na temelju toga planirati testiranje. U tom smislu treba razmotriti i odgovoriti sljedea pitanja: % Da li se znaju krajnji troakovi testiranja? % Kako e testiranje utjecati na vrijeme razvoja aplikacije (softverskog programa)? % Koliko sredstava i vremena odvojiti na testiranje? % Koje metode i softverske tehnike primijeniti za testiranje? % Je li testiranje isplativo? Kada doe do postavljanja ovih pitanja u nekoj organizaciji, raskorak izmeu akcija i svijesti gdje se problem nalazi mo~e biti velik. Taj problem je problem menad~menta i postoje mnoge studije o tome[1]. Za efikasno testiranje postoji ravnote~a izmeu kvalitete softvera i troakova utroaenih na testiranje. Premalo testiranja smanjuje kvalitetu softverskog programa, a time i manje troakove. Previae testiranja daje visoku kvalitetu, ali i visoke troakove. Ovaj problem prikazan je na slici 1.  Slika 1. Krivulja troakova testiranja Veina problema vezana uz testiranje dogaa se iz sljedeih razloga: Krivo se definira ato e se testirati, Testiranje se izvraavalo u krivoj fazi razvojnog procesa, Koristile su se neefikasne tehnike testiranja. `to je efikasnije pronala~enje greaaka to su i vee uatede u razvojnom procesu i procesu odr~avanja. E. Izvoenje testa Nakon izrade test specifikacije slijedi njeno pretvaranje u izvedivi (izvrani) oblik, obi no kao kd. Izvraavanje testa je obi no automatsko, ali isto tako koristi se i manualno izvraavanje. Kd automatskog izvraavanja koriste se programske tehnike u tu svrhu. One su napravljene tako da na temelju test specifikacije same izvraavaju test, te prijavljuju otkrivene greake. F. Ocjena testiranja Po zavraetku testiranja vrai se ocjena koja uklju uje sve aspekte koji proistje u iz tog cijelog procesa. Svakako se treba razmotriti uspjeanost i efikasnost testiranja. Jedan od va~nih aspekata u krajnjoj prosudbi je prihvaanje krajnjeg rezultata od strane onih koji nemaju iskustva u testiranju, a trebaju to odobriti i prihvatiti. To su uglavnom korisnici i menad~eri. Da bi tester dao kvalitetnu ocjenu testiranja predla~u se sljedea pitanja koja bi on morao postaviti na kraju svoga rada: Da li je testirao sve ope poznate greake? Da li je testom pokriosav kd? Da li je predvidio sve mogue uzroke koji e dovesti do prekida ili nepredvienog funkcioniranja (rada) programa? Da li je koristio sve ulazne podatke? Da li je predvidio i isprobao sve mogue izvedbe programa koje bi mogao i korisnik? Ova pitanja su uvijek korisna jednom testeru pomou kojih on sam mo~e odrediti u kojem trenutku testiranje prestaje i kada je programska aplikacija spremna upotrebu i isporuku. III. OPENITO O SIMULACIJI I MODELIRANJU U posljednjih nekoliko desetljea doalo je do velikog razvoja u softverskoj djelatnosti i paralelno s time potra~nja korisnika za boljim, br~im i jeftinijim softverom. Potra~nja na tr~iatu osjetno je podigla razinu kompleksnosti softvera, a time one koji rade na razvoju softvera da poboljaaju svoju kompetentnost. Istodobno, softverska djelatnost se oslanja na razvoj ra unala, programske tehnike i programske jezike. Pitanje koje se postavlja je kako poboljaati procese u ovoj djelatnosti koristei programske tehnike, cjelokupnu ra unalsku tehnologiju i poveati kompetentnost onih koji se bave razvojem softvera. Odgovor se nalazi u primjeni simulacije u softverskom in~enjerstvu. Najpoznatiju definiciju simulacije dao je Robert E. Shannon:  Simulacija je proces dizajniranja modela realnog sustava i izvoenje niza ekperimenata na tom modelu s ciljem razumijevanja ponaaanja sustava ili istra~ivanja razli itih pristupa upravljanja sustavom. [4] A. Modeliranje sustava Najva~nija komponenta u simulaciji je modeliranje sustava. Stoga su definirani sljedei postupci kako bi se razvio vjerodostojan simulacijski model [3]: 1) Identifikacija problema  prepoznati i navesti probleme u postojeem sustavu te postaviti zahtjeve za promatrani sustav. 2) Formuliranje problema  odrediti granice sustava ili njegovog dijela koji e se promatrati. Definirati ukupni cilj razmatranja i kvantitativne kriterije na osnovi kojih e se usporeivati i ocjenjivati razli ite konfiguracije sustava. Va~no je odrediti da li e se model koristiti za jednokratnu odluku ili e se koristiti na dulje vrijeme. Takoer se u cilju ato boljeg definiranja problema mora identificirati korisnik. 3) Sakupljanje i obrada podataka iz stvarnog sustava  prikupljanje podataka o specifikaciji sustava, ulaznim varijablama te o izvedbama postojeeg sustava. Takoer se treba uzeti u obzir vjerojatnost koja se odnosi na varijable i njhove raspodjele. 4) Formuliranje i razvoj modela  razvoj sheme i dijagrama tijeka sustava, tj. kako entiteti prolaze kroz sustav. Nakon toga kreira se model prilagoen simulacijskom programu. Ovdje se joa uklju uje provjera izvoenja modela prema danoj specifikaciji. 5) Validacija modela  provjera da li izgraeni simulacijski model uistinu odgovara realnosti. Validacija se provodi tako da se kao ulaz simuliranog modela koriste ulazne varijable iz realnog sustava za koje su poznate izlazne varijable. Nakon simulacije usporeuju se dobiveni rezultati s onima iz realnog sustava. Ako se poklapaju tada je modeliran sustav valjan. 6) Dokumentacija modela za buduu upotrebu  kako bi olakaali ponovnu upotrebu modela za druge namjene, dokumentiraju se ciljevi razvoja simulacijskog modela, pretpostavke koritene pri izgradnji te ulazne varijable. S obzirom na to da simulacijski modeli nadomjetaju eksperimente na stvarnim sustavima koji mogu biti jako skupi i kompleksni, oni moraju osiguravati aproksimaciju stvarnog sustava kako niti jedan zaklju ak izvu en iz njega ne bi bio pogreaan. U tu svrhu provodi se validacija simulacijskog modela. B. Metode verifikacije i validacije Dok validacija provjerava da li je model ispravan u odnosu na stvarni sustav, verifikacija provjerava da li je ra unalni model pomou kojeg e se realizirati simulacija ispravan u odnosu na konceptualni model. Putem tih procesa mora se osigurati dovoljna ispravnost modela s obzirom na svrhu i ciljeve. Metode verifikacije i validacije su sljedee[3]: 1) Validacija konceptualnog modela  ne postoji neka formalna metoda za validaciju konceptualnog modela. Naj eae se radi o prou avanju projektne specifikacije. U tom se slu aju analiziraju pristupi modeliranju i ciljevima nekog projekta. Dokument se kao izvjeataj aalje svim va~nim sudionicima s dobrim poznavanjem problematike te se od njih prikupljaju povratne informacije o prikladnosti modela. 2) Validacija podataka  da bi podaci bili ato precizniji potrebno je: (ispitati pouzdanost i vjerodostojnost svakog izvora podataka, (provjeriti da li postoje neke neto nosti u podacima, (ustanoviti postupak prikupljanja podataka u pogreanom formatu i njihovu pretvorbu u prikladni format, (spremiti podatke odvojene od simulacijskog kda. 3) Verifikacija i strukturna validacija ove dvije metode se navode zajedno jer se tijekom faze kodiranja modela obje izvode kontinuirano. Metode verifikacije i strukturne validacije su: (provjera kda prolaskom kroz kd provjerava se da li su primijenjeni pravi podaci i logika, (vizualna provjera modela  neki od na ina vizualne provjere modela su: prola~enje kroz model dogaaj po dogaaj, zaustavljanje modela u odreenom trenutku, predvianje sljedeeg dogaaja te njegova provjera uz ponovno aktiviranje, interaktivno postavljanje uvjeta kako bi se naglasilo izvoenje odreenih problemati nih dogaanja, izoliranje pojedinih dijelova modela, praenje kretanja pojedinog entiteta kroz model, provjera izlaznih rezultata simulacije usporeivanje pohranjenih rezultata i s onim koji se o ekuju. 4) Validacija cjelokupnog modela : (usporedba s realnim sustavom  prikupljanje zastarjelih podataka ponaaanja sustava te usporeivanje prosje ne vrijednosti, raspraenost podataka, distribucije podataka i odnosa ulaznih i izlazni veli ina za stvarni sustav i model, (usporedba s drugim modelima  ako ne postoje zastarjeli podaci onda se sljedee metode primjenjuju: usporedba s matemati kim modelom  gruba aproksimacija o ekivanih rezultata uz upotrebu matemati kih formula, teorije poslu~ivanja i statisti ke analize, usporedba s deterministi kim modelom  uklanjanje svih elemenata iz modela koji uzrokuju slu ajnost, usporedba s drugim simulacijskim modelima  usporedba s modelom koji je ve verificiran i ocijenjen kao valjan na temelju ulaznih i izlaznih podataka te njihovih odnosa[2]. C. Simulacija diskretnih dogaaja Simulacijom diskretnih dogaaja dobiva se najbolji opis dogaaja iz realnog svijeta. Ta simulacija spada pod vjerojatnosnu simulaciju kod koje se ulazni parametri mogu dobro opisati funkcijama raspodjele vjerojatnosti te na osnovi njih upotrijebiti algoritme koji generiraju slu ajne vrijednosti. Simulacija diskretnih dogaaja predstavlja model sustava koji se mijenja u vremenu. Njegove varijable stanja se trenutno mijenjaju u odvojenim vremenskim to kama. Ti dogaaji mogu utjecati na stanje simuliranog sustava. Zbog mogunosti mijenjanja dinamike stvarnog sustava ova simulacija ima jako veliku va~nost. Osnovne komponente od kojih se sastoje sve simulacije diskretnih dogaaja su [4]: 1) Entiteti  uzrokuju promjene u stanju simulacije. Bez njih se niata ne bi dogaalo. Imaju svoje jedinstvene karakteristike, tj. atribute. Atributi su va~ni za razumijevanje izvedbe i funkcije entiteta u simulaciji. 2) Aktivnosti i dogaaji  aktivnosti su procesi i logika unutar simulacije. Dogaaji su uvjeti koji se pojavljuju u odreenom vremenskom trenutku i uzrokuju promjene u sustavu. Dogaaj kreiraju entiteti u interakciji s aktivnostima. Tri su osnovne vrste aktivnosti: odgoda (delay), rep (red ekanja) i logika. Odgoda je aktivnost u kojoj je izvraenje entiteta odgoeno za to no odreeni vremenski period. Rep je aktivnost u simulaciji u kojoj entitet mora ekati neodreeni vremenski period. Logika omoguava entitetu da utje e na stanja sustava kroz upravljanje varijablama ili logikom odlu ivanja. 3) Sredstva  ona su u simulaciji sve ato ima ograni enu vrijednost i kapacitet. To mo~e biti npr. broj ulaznih varijabli, broj testera, broj ra unala i sl. 4) Globalne varijable  one se koriste kako bi se pratile vrijednosti svih va~nih faktora u simulaciji. Ove su varijable uvijek dostupne itavom modelu tijekom izvoenja simulacije. 5) Generator slu ajnih brojeva  slu~i generiranju slu ajnih vrijednosti izmeu 0 i 1. Te se vrijednosti koriste prilikom kreiranja vjerojatnosnih raspodjela. 6) Kalendar  kalendar sadr~i popis dogaaja koji se trebaju dogoditi nakon po etka simulacije. Ti dogaaji ovise samo o vremenu a ne o uvjetima u simulaciji. 7) Vrijeme  vrijeme je varijabla koja je zajedni ka svim simulacijskim modelima. . IV. SIMULACIJA STUDIJSKOG SLU AJA Studijski slu aj na kojem je provedena simulacija i analiza procesa sastoji se od aest testera. Testere prema razini znanja, brzini rjeaavanja problema i iskustvu dijelimo u tri skupine: eksperte, one koji su viae iskusni i one koji su manje iskusni. Studijski test tim sastoji se od jednog eksperta, dva viae iskusna testera i tri manje iskusna testera. A. Opis aktivnosti u studijskom slu aju Internim kompanijskim procesom testiranja definirane su dvije aktivnosti za testere: priprema test specifikacije i izvoenje testa. Ove dvije aktivnosti obuhvaaju niz podaktivnosti koje detaljnije opisuju rad pojedinog testera. Kod eksperta u internom kompanijskom procesu testiranja za pripremu test specifikacije spadaju sljedee podaktivnosti: prou avanje ulazne dokumentacije (dokumentacija vezana za ono ato e se testirati), priprema test specifikacije i pomo manje iskusnim testerima u izradi test specifikacije. U izvoenje testa definirano internim kompanijskim procesom testiranja spadaju sljedee podaktivnosti: izvoenje testa, pomo pri izvoenju testa manje iskusnim testerima, evidentiranje greake i regresijsko testiranje. Kod viae iskusnih testera u pripremu test specifikacije definirane internim kompanijskim procesom spadaju podaktivnosti: prou avanje ulazne dokumentacije i priprema test specifikacije. U izvoenje testa definirano internim kompanijskim procesom spadaju podaktivnosti: izvoenje testa, evidentiranje greake i regresijsko testiranje. Kod manje iskusnih testera u pripremu test specifikacije definirane internim kompanijskim procesom spadaju sljedee podaktivnosti: prou avanje ulazne dokumentacije, priprema test specifikacije i dorada test specifikacije. U izvoenje testa definirano internim kompanijskim procesom spadaju podaktivnosti: izvoenje testa, regresijski test i evidentiranje greake. B. Simulacija procesa u studijskom slu aju Model mre~e repova transformiran je u simulacijski model primjenom grafi kog su elja simulacijskog softvera Micro Saint. Repovi su pridru~eni onim vorovima koji prikazuju aktivnosti poslu~ivanja zahtjeva za modifikacijom koje se, zbog ograni enosti resursa procesa, ne odvijaju trenutno, nego se neko vrijeme provodi ekajui. S obzirom da je proces dizajniran tako da se neke aktivnosti nad istim zahtjevom izvode sekvencijalno od strane istog poslu~itelja, tim aktivnostima nije pridru~en rep, jer se pretpostavlja da poslu~itelj obrauje isti zahtjev od prve do zadnje aktivnosti u doti noj fazi procesa bez prekida i bez ekanja. Historijski podaci o projektu u studijskom slu aju dobiveni su iz baze podataka o projektu i iz intervjua sa svakim od testera. Svi dobiveni podaci uvrateni su u simulaciju za pojedinu aktivnost. Ukupna simulacija je imala sto reputacija, ato zna i da je u jednom pokretanju simulacijskog modela svaka pojedina. Vremenska jedinica koja se koristila u simulaciji i u svim aktivnostima su sati. U svakom koraku simulirao se proces kroz vremensko razdoblje od 12383 sata koje je ujedno i ukupno vrijeme trajanja testiranja u projektu. Na osnovi dobivenih podataka prilikom izvoenja simulacije te njihovih malih odstupanja od podataka iz stvarnog procesa mo~e se zaklju iti da se radi o valjanom modelu koji kao takav ini dobar prikaz stvarnog procesa (tablica 1.). Tablica 1. Broj ulazaBroj naenih greaakaHistorijski podaci7345Podaci dobiveni simulacijom74.6146.71 Daljnjom analizom podataka koji su dobiveni putem simulacije dobilo se da je iskoristivost eksperta 0.784, vie iskusnih testera 0.795 i manje iskusnih testera 0.641. Iz pretpostavke koje se dobila putem intervjua da manje iskusnom testeru za isti posao treba dva puta vie vremena od eksperta, i jedan i pol puta vie vremena od vie iskusnog testera vidi se da su manje iskusni testeri najkriti niji dio procesa testiranja u studijskom slu aju. Manje iskusne testere treba ato viae educirati da bi stekli odgovarajua znanja, vjeatine i iskustvo, a samim time bi se poveala efikasnost cjelokupnog procesa. Viae iskusni testeri imaju visoku iskoristivost i kada se uzme u obzir da oni naprave velik dio posla, omjer znanja i cijene koju se za njih mora platiti je najidealniji u procesu testiranja u studijskom slu aju. Ekspert napravi najvei dio posla u studijskom slu aju i kraj toga pomogne u radu manje iskusnim testerima. On je klju ni ovjek za projekt (eng. key person). V. ZAKLJU AK Programski proces testiranja predstavlja va~nu kariku u ~ivotnom ciklusu razvoja programskog proizvoda. Rije  je o vrlo slo~enom procesu koji uklju uje mnogo razli itih aktivnosti, interakcija i povratnih veza. Svaka od tih aktivnosti ima veliku va~nost u uspjeanom dovraenju programskog procesa testiranja. Proces zapo inje ulaskom radne cjeline ili promjene zahtjeva u fazu testiranja u studijskom slu aju u ijoj se grupi nalazi aest testera: jedan ekspert, dva viae iskusna testera i tri manje iskusna testera. Radna cjelina ili promjena zahtjeva se dodijeli jednom od aest testera i to po inju aktivnosti vezane uz testiranje. Za vrijeme testiranja se evidentiraju greake naene u softveru koje su u domeni radne cjeline ili promjene zahtjeva. Prethodnica postupku modeliranja predstavljalo je prikupljanje podataka i znanja o procesu, neizostavnih aktivnosti prilikom svakog modeliranja nekog procesa. Analizom prikupljenih podataka utvruje se ponaaanje procesa, a samim time se omoguuje lakae i efikasnije postizanje kona nog, valjanog modela. Modeliranje je zasnovano na temeljima teorije poslu~ivanja i mre~ama repova. Na taj je na in bilo mogue prikazati dogaaje iz realnog svijeta i u tome obuhvatiti interakcije promatranog procesa. Kao rezultat modeliranja dobiva se jasan prikaz redoslijeda i na ina odvijanja aktivnosti sadr~anih unutar procesa koji se promatra. Simulacija se pokazala kao korisna tehnika koja omoguuje razmatranje ponaaanja i performansi procesa testiranja programskih proizvoda. Njena primjena donosi velik napredak u daljnjoj analizi procesa. U radu se koristio simulacijski programski paket Micro Saint koji sadr~i razne mogunosti analize simuliranog procesa. Simulacijom su omoguena br~a i jednostavnija prikupljanja korisnih podataka koja bi u stvarnosti trajala puno du~e. Na osnovi prikupljenih podataka provedene su statisti ke obrade i analize, a omoguen je i prikaz putem raznih dijagrama i grafova. Ti e podaci otvoriti razne mogunosti poboljaanja doti nog procesa u onim segmentima koji su prema prikupljenim podacima na to ukazivali. Na taj na in e se ujedno smanjiti rizici ukoliko se krene u takav eksperiment jer e se sva ispitivanja obavljati na modelu bez uplitanja u stvarni proces. Rezultati koji su dobiveni provoenjem simulacije na modelu pokazali su da je model valjan, te da su na njemu mogue daljnje analize procesa. Analizom studijskog slu aja doalo se do saznanja o nedostacima procesa, i to konkretno kod manje iskusnih testera. Da bi se proces testiranja programskih proizvoda poboljaao potrebno je ato prije obu iti manje iskusne testere znanjem, vjeatinama i iskustvom. Analizom procesa se usredoto ilo na promatranje onih performansi procesa koje se mogu prikazati karakteristi nim parametrima mre~e repova. To se odnosi na vrijeme zadr~avanja, vrijeme poslu~ivanja i vrijeme ekanja radnih cjelina i promjeni zahtjeva, kao i stupnju iskoristivosti pojedinih testera. Prikupljeni podaci upozorili su na one dijelove koji trebaju krenuti za poboljaanjem kako bi se postigla viaa razina efikasnosti promatranog procesa, a na taj na in osigurati ato kvalitetniji programski proizvod. LITERATURA [1] Perry, W.,  Effective Methods for Software Testing , John Wiley & Sons, New York, USA, 1995. [2] Car, },  Modeliranje procesa odr~avanja telekomunikacijske programske podrake , Doktorska disertacija, Fakultet elektrotehnike i ra unarstva, Zagreb, 2001. [3] Law, A. M., W. D. Kelton.,  Simulation Modeling and Analysis, McGraw-Hill Inc., 2000. [4] Ingalls, R.G., Introduction to Simulation, Proceedings of the 2001 Winter Simulation, Conference, pp.7-16. PAGE  <>HJhjl"&p>P$зŮypfff6CJ]mHsHCJOJQJ^J CJmHsH5CJOJQJ\^J5CJOJQJ\^J 5CJ\5CJOJQJ\^JmHsH0JCJmHsHjCJUmHsHjCJUmHsH CJmHsHmHsH5CJOJQJ\^JmHsH OJQJ^JCJOJQJ^JmHsH&Z@BDFHJhjl|~P $a$2$$Ifl4#H$64 la $$Ifa$$If$a$P "$&p$F & FEƀx*]*$a$ $fB q*% & FF & FEƀxF & FEƀxF & FEƀxdf !!R"l"6#L#$'$b$c$r$s$))-*--&///Z5:h@CC&FIIIDLHLJLNLL O"OJOLO>R@RlRnRdUlUPZTZZZZ `` bCJCJmHsH CJmHsHjCJUmHsH CJmHsH5CJOJQJ\^J5CJ\mHsHCJOJQJ^JmHsH6CJ]mHsH5\mHsH CJmHsHCJaJmHsH;B *!!," #l%F & FEƀx F & FEƀx F & FEƀx & F #$b$c$r$s$)F*H*qomg^gg $ p#a$ p#F & FEƀx F & FEƀx H*++,iK & F p#EƀxK & F p#EƀxK & F p#Eƀx ,~--&/(///~3Z5\55YF & FEƀx$a$K p#hEƀx^h  & F p# 55T66q*F & FEƀxF & FEƀxF & FEƀx64777:h@CCCC&FFqojhjofhho$a$F & FEƀxF & FEƀx F,GGHNHIDLFLHLLLNLLL,M.M|MK & F p#Eƀx p#$a$$a$|MMNNPN O"OJOLO>R@Ricc][cRc $ p#a$*]* p#K & F p#EƀxK & F p#Eƀx @RlRnRdUbVdVVVRN$ & F p#Eƀxa$N$ & F p#Eƀxa$ $ p#a$ p#VW:XcN$ & F p#Eƀxa$N$ & F p#Eƀxa$:XXXPZRZTZZZ ``.b0b`bbbcc$*]*a$$a$$a$*]* $ p#a$N$ & F p#Eƀxa$ b.b0b`bccddgRhijklnorsuuu0vy8yyyzzzzX{Z{{||||| NPBޑjpЕNPPVf 6CJ]6]5CJ\mHsH jCJ jCJ j CJmH sH 6CJ]mHsHCJ CJmHsHLcdgikn6p7prrssuuu yyzz$`a$$*]*a$J$Eƀ)^a$$a$zX{{||N@BTjPF$Eƀ)a$$a$$`a$P4<>@XZ* `b`df~ $$Ifa$$^a$$a$$a$X `bB\fH¼ļF`ȼٶٶٶٶٯ0J j0JU 6CJ]5CJOJQJ\^J5CJOJQJ\^JmHsHCJ CJmHsH6CJmHsH6CJ]mHsH CJmHsH6]+´.:FHJhxxxxxxssss$a$ $$Ifa$~$$IflFN 06    4 la fn2h]h&`#$1$$a$$a$41h. A!"#$n%0 p#H 001h. A!"#$n% P0 V]DyK Zdenko.Marincic@ericsson.comyK Hmailto:Zdenko.Marincic@ericsson.comLDdG\ZT  C 0AisplativostRK{7h=MK;FK{7h=MJFIFddDuckyPAdobed      I~  !"զW 1w8#2AQ3$B%&' ?*JTJ.]HH0G\*^ֱ <<Mey )"Е f@5NO매Zm3 B\-^CxA^q'[z2IZnJT_ZVmilOA~|^_;zwvHpޑ+QaUiN;A]rGL` n>O,Qg`6x 9&4nBj>+)]Z"JEep6ڛ*Z3}Efg"y)3^Fiں72l"qZ&7 1L[RMi2S&%(Qv8-Ed<v2m' VŽ&+{!~W5-.-/gE7'3^|~Cy2*hQNoTבzvnl(mFI%Di3UueZᙞ*`9V<ՑF'Lif6y]/3_rrѺqOMA%@LטrYr>p׻>iϞV5pܙtEoGfu1HdĹͣSnDHZV5?J Ak9l^Ց3%`d}+d Wm[ZFڤjX7U ,X3 qİ$+ƒ3>9A&2Lkq,6cȝr=C`%ÎHY{Td}@{ r\ɬ<Ųڥw%H֒WHu6-~bS5ab\e6$ϵ=OPM]Pxη1ZX5g]]+*T 1Sf#Rg3ouOŝOtڣlDɏ2\4muđ-DԚӺ&AcST?qvKyrvCI4'Wk"7{ *b*)/D!SП#U_gjf`:SzW,(*vmTwX]2mQighmuM*&,U~_u)(iB*ٔIA4Jitvd/4^m~h\VîQdJmYwjI=z('8U wc?Xop_1%թi6'xN-A "ۨs| )0 ͷW:aUiS팂+pZlW*OD4j_Ju%g`+sz6e SRn-mm1|g"5cDM8S?gRLNiTetW8E%Mq+rl۲6 ֐m "F0|mPWAnU H6ji0?^$_. {UiL/3bcb-5E1bFJɥpe / Z%,Ϋ]bzo l랍em%Fcurudu Z=wk4ZfUY2owRMds+J*">Gӡ s׌Yۛ.lPo&ą}Z59jmIm%$jOp Ď`q~Xw#?*M9l&C<6S- qԨ}} &䆆3ab`[9X&_oiCdҞ%' &RM=IE+-OdlIKg!zQ^ԺS=9&MK,2^EMɕWԕڿN$:+ir GQRVODia%ɱB/N2>Wռ;M-QsHCk$aڗT҉+4]}z@bG'a*~3b:KpJ[n7%HeiSOf,?/Զ{p"H DTҡ|9Lo7U4I"&SJo ,sWf;y~o(-WKۗ/ 7캕!B+JI3#.1+zL™ھ;˲bȇXغDj2RH[1i3&"K:/1ގ&GXʪZoqؑ3",ϥI<:ˉSn JA"#q gbՑ24$afkf۹& y%;K]M'DafkSc +Dv+XW&Z<'Avaw8XOV0TXcH2;Rilˈ m4 BIQC 2Ua+/+C)w8QJ3*v|58fvJ*kTb[\./[STE}-M8Hu2m) O╥IQKV'"&}sx>kdd7Tځ_ Y%[~g%*An;$aUqMSgK}zD"me+a1!-*}L@q;Ɵڬ78`//Rl[R7e׳]cd61F%J;Iu2#($Zu{tmp-SsLqBbV}ppMN\5v%q+BB2M&0N癣ȍe)籜) y1L$*}.:F:HIugZ܇'$Y۽B 84fպ]ug~0JQ-պq8XOV0 Ouim_fn 5ꝱLZ {rbKl3!F̖Ց)-8_ Z k {dȆ(Q9u[9Ydkfkl0-g1{ιVس"9)<۝qVڣ%^qR`Ӏ`nq}蘮(tTPɶ[#5JRKq8)KqjS)KRa0@q;Ɵڬ78`/v탏Dʰܪ!ýFmٙ-*Ji[n6mI[kJ\mIZR 5ϸif|Ĭی4 mHib )tDˈfˉK2 *ȝ-OU_V^Yĺ{"LYqdahԇq %!i3%7Va9 LW bنd-R[mҥ%ҥ)0˧g\ٟ1 hoJߵ3x,ʣ6|'IZO:% LS wc?Xop_2e4UIƶ;)%: K }MkO8%RЄ$mqZVj}s"emI35,--v\ҞA8N*$RuMEC wc?Xop_264}#\fd֯  us'@b&ڛ$ȌȌDD .Y{>VFN#>=LĦ&C:XSjQ!fY%M>O ]aCc7dLa2ΦR2#VA7͂Ci8Nr22>{Epj*.ֿq0 p>2#3)'Ee3a$r+lKJt%j"rW3 QQMȲ i7/WRzfeF#\."5'F։i2ٳ/lect U*Pҕ?]8{Ƚڣ4./ӲSMGK->SK]GoV˨ո۷y,*N]$6nMfZJm$ϯB U'6( Ŏ4al3=W;&9{m\ūQH3B[u>މQ%DgS]ߵ~K.Z՚bnFX.Tc<3Q-g8ѥh5#ć:Ͼܙx\@f3zIs1ҙkK*<վIm]KS'XNvmҮuMĽrmC_U[ky<T'^KXܗe rҙ@Za닽M7!Ұvkĩ|p\HIq XJYB y'+~eqgLQ%k\̺cfǫ \2b{&#I%=:Tꏶ}{Rwm8>vjƓ>κJnLt*#%(+5ͳm٣Zq5^ZIDMajQ\e)F4w2[\nnUgny]`s*;Se͝a'_KdKU('8U guMJPqm 6Q>:2בIZDtsjk"]R]Dz:JCV̌X]Ljc1ȱ˱XHM!޹IN7\)l$KGp xn=uC*r2ff%IY%mҦmĥm*mĥiRH<0Zz;lMTjM%r5W0i ;7cdrYTj_md6jZ~(&sM֖ Q˩u0Ero?uTߙmB~cE7f-8T:z oe%qSȻ]Kl[lZůeUy Ӳk] /%Ԕ5؃.ϑ<;N~ Ȼ ;ٜ58Uc"D%Be)K3ve?2l&Kƒ7^q(LW{s`clٱl|Uy*Wi_sOc ݍљ4>'ܽ:ckҥJI&<]̈9{j!7+5INSL)ԢRW"QY:G?ȳ<4b,\9La2eZ\bV -iZV]?3櫲/0n2Yͤ]yrw24˦˨FJ/h Xwc?Xop_b֬1rk1cr#%C%::Z#BzIاwsOI굗i:$)B[#Z~\u`*WYhuS(j{67" Kld&Ե'6ҤjOzV}#i\c2L'dΥLMwʹQٌ)ƍj/}> mA 86k)Q]۩ Rc75 eF/̾Lԗ x;9əeXOkYe"*2kK8%5 c F`ҧ\}e)E~"I0-5ݕ<̗yoh\[Pc2#XRDu\xЦn$BWQ 5bKvYNֈzKk>{MΎCu$\Zx}Td9ýiY$=3>!`̬f/II'RKR:᣹xڜllfk.؜&{E 6qoIIYQ$hOA=g[k2u&Ɛ#l_%Y)28slKGѵ]^oj|8vȖNór鯼h)(#A+ƞq(5O 3 s6eD!ZRMo:ʜ孂YK8/ē4D0PLSwklKja _3s*s>J -yTROJI)= @q;Ɵڬ78`/>گ8x.Ě̱f,ZPqmO0HuiV]R$x=<04UIJs^T*Dx%.$$e҂9 ,$D}@ui8uƬwj)\{*E_zE޾[Pm:Q ͅ>-Wj8-J2x%4ZJYTm} hђ0ݙkO;NC\~Z5o;-ǍyyBm=.yM'PVOУZɬkv6jśhQQq fpCv~#ezx-i^Uy&Dqv:-h$}(!eX6jOpm/Z_&}]|5qN{46{0cɶ'Lsȓ\Y('X}5!BHZLDdd}tC66׹zVsvz)87%{ m%MӘŖUdv=eKg7(ߖm5yk5Ԯ hZ0hknC͙0β\vGfBMF)Ah~7% D%SG}Ѥ"SF܂bJ ԟ*ꈃ4xět湕cNW3jac&m'4:lЈ{C;`jXNyI2.;:I2qxqVoYYowVNn_p|Y;0IRq5Kڪ%-%,G\Oyċ6hIkQ$Ϡ oI˹mrql GQq6 %ñtNZ:JU=Rqe9VEG/ \,YOTL~\'q)yu?js ؊6 qY.tv+m&CM}es)5ZbTI sOvVDhZTaa8XOV0Sb55jfGw5dB{]TI{Lg:ܶkjG++fYL<'6[ξ(d5# J4-{-9a:lu J?+ ÄGԗ-s{y#_m\]:sn7g: 6:3 b!RSc82c$D3][S~8XOV0UPaTSrL`H[m<hc0"C!e uTBZRaIc-yhΚMt\Bl]Z?޸oݸ␄:\n[Sp:R$hv-Tz|XӼ%VشbƶcF0NٓhϹh 潣-B}miu~Yr*<8ʚ-Pcqb4"KL6laq\3An )׀('8U %ƟȮ"YIqJb4cww`L!PZ>q.Cӭ8Jд(t2q5vOiRϝ;eq{9 . \ JD!HGzc7R /l 3cH²K]m-[b묡H1q>h[m\BU1@q;Ɵڬ78`/,jX-b[#een.T}?06ږ%7 e>ڦN1N-Pʊ3ʢl gwP#Jj(S$㱍)[pZ[JTeqDvcZ]"VQ..ZHtg%%WNl'MM_i;͚KkA/]lez{mƳ_UrV"qQ&CO%0@q;Ɵڬ78`/u:Pb%7~\M7>EƓJo${~:\mQ%K'I5VuWumhvY[%AP GrCޒ ~KY)uз@&L{=M 8t~D)ն>|'XK&gwP=ݪQStٖe[ֲUhU7׸~taDj-yEJeASM)s= ?RBڪ%%Fg@ybˋ%F8ۈQ) I( Ŏ4atOmƬ񭕺%\__*;-=5f%|u-}gR R\GLaa&K2{*u}o+[[pKt""Km !$,^mhiN2eŕ|JmGy[vuԤ@q;Ɵڬ78`/kj ;8qq=F,dPm&FD#3>3͎GS-`s_kMGʉYJey~2BMQ,Ds`0{_kz&+ 22mjRRqũN8RZRԥLR{?JVg6br5瑱C:Z6Y+',2 Q-!qeiJN0$vS[,G-9DFu~Âo=f_o>ipNgk5v$ՐiPGŎ4>*D@6n;&.YOsoI%uiԮR̉Zyw mq$t_`db;XQGv7jSG7~s[2a95WVtW..={(\Y(6a%!B+BDfF]egڜo]xwFnZ*u#6[z K+9YF#Zń$Gd*Q% [,mL kgQ]z,2XWjU[nQ>j\ߓE\'SCpOxߌQc+^eg(jZ8JfC G~  6ֆ + 3#" jဿD, ص EТB%!i 6JJ&%}%]:SpsZ:;Ye[oѫ2} YB^uK /95٠% ͑SSdb=_P˔R~F4ҌОqf[Y?*}a~zf6\iLʩpjRF)/G: 4q[4k@.:q9OZEdzIvw?C^z{BVwc?Xop_('8U ?s׉6[N+u3GSİTuӭ QR@[ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0"wor?d\.G싅Y]p7˹?.}fw#`E. ȸ]܏ |0 )q9_'k1sV=a/ȝb#8u=6%)?" %hy1tǚzm! RIz┵zv5:kjm/h]R]Df}=&,PNjC ewm&wje$٣ȣUz&܂#WogRWb+0%#4Elj]V,i^$[]47,N! #7;H@fm\[dxH;r,euUꪬPC_aq\W(~79e?9ٙ9'-&kےڡ8o!Y5J̹Y{7V%ʠFfMG0KQ!ř%ËoyϮacCqԚ =K= EV2C-L~gc|[)vOTE{Y6j.+P\Osβɸ6L+NMVBJTG4)j6Ԯ#WH_E89e&c9~8-}"r嶺d6m-}z%I4rUqMR݇ѝL[D?hedcK)Ju{OI##"3 LP`UV_ϕ[ 0&3gȼjI/$NC5wYbFش(V.N;%FFIZRvO o]-g3= W_SJo%ȋ2Yq ^JfnH>CIIԈ%x(8>+;|m/fVȲekYp̛zIhmfF,()32y3T\*8Ǫ'm֤ʲuF3ղd }ViOjT`:y+xh8Z-qd_բ +)ˌ}^w$1'į* +5Bw5[ nمn*z/WrPo!BGU)=BջQ6:`g)mUH'Woyv]ӯCje9)[́W[LRMK-DԺ> iH1~ru,8'dz9RvVQr[5q\M$Ioi%&7`(K2 hU:ڶ\(V#5FuT"IJ%{ :\2}ikTkU5sLo&eBVe<* ЂEf$F}>O,1 l ZP^K}9f8QٱtQ% p{?ae's^o#ˬ[NYdq2?ķܴI) ,Ÿ)5[ պET^G`8-1,TdS_˓)ɩYؒp4bx/؝S)(X~ՎȚfdѽ BRGWj@9lvqJfձ}"r6TF вmtuOrzP U`OsXík:LWFcm b]щ KV$JJSRDn܋4{b5q"0?=m%N_YiVWč1B5uJMJ5) r(M؁cՔz^:ƞKysWI-<$[5(ȈN2qnSca.Zuƺֲ~BcP5_##u0&zTE\GLnF4R&vj0;4[b<4o"V83q}} 7\ [0V=6%pfl]Y*cxU&s^NOqVqe%- ᶢI]2xݝlj ڲ Jڶ2nӈXԤ̉2"Rש4$Lv)"I? i8@8 NormalCJ_HaJmH sH tH >@> Heading 1$@&6CJ]mHsHTT Heading 2$<@& 56CJOJQJ\]^JaJNN Heading 3$<@&5CJOJQJ\^JaJ22 Heading 4$@&6]D@D Heading 5$$@&a$6CJ]mHsH<A@< Default Paragraph FontB>@B Title$a$5CJOJQJ\^JmHsH.U@. Hyperlink >*B*phJB@J Body Text$a$5CJOJQJ\^JmHsH,@", Header  p#JP@2J Body Text 2$a$6OJQJ]^JmHsH>Q@B> Body Text 3 *]* CJmHsH, @R, Footer  p#&)@a& Page Number2Or2 Text $xa$ aJmHsHNC@N Body Text Indent$`a$ CJmHsH>V@> FollowedHyperlink >*B* phBOB Text 0 pta $1$a$\aJmHsH%j 6 DEtx !"#$%rG 8 @ S T L !bcrs#$i*\ 4!A!!! "'"""$#$$$&$'$M$N$$$$$'%(%%%%%' '6'7'(1)2)])|))*q*r*(+)+*+S+T+.G.//0/1///K0123]56676g7h777888:: ;E;;;<<?'?@ B!BCBDBDEEE5HHI(JJKKK KBKCKLLLLMOQRRRR0U2X3X?X@XKX`XaXtXwXzX{XXXXXX\\\\\_bfehhhi iji jejjjjj0000000000000`0000000000000000000,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 ,  0 , 0, 00O0O0O0O 0 O 0 O 0 O 0O0O0O0O0O0O0O0O0O 0O 0O 0O 0O 0O 0O0O0O0O0O0O000000000000000000 0 0 000000}%00}%00 '0 '0 '0 ' 0 0 0 0 00000000000000000000000000000000000000000000000000000000000H0H0H0000000H000000000000000000000000000000000000@0@0 0  bmr~P $B #H*,56F|M@RV:XczPnpqstuvwxyz{|}ojX!CE\eg%rwGL 8 @ S T   X Y b d s t !LP6:'+XYbcrw#$#${||} 48!!'"+""""$'$M$Q$$$'%+%%%%%&&&&&&&&' '6';'d(f((())1)2)L)M)q*v*++(+*+S+W+X+Y+. .G.H.////0/4///////c0f0)2,2334455\5]55556;6g7h777"8#8888899m:n::::: ;;E;F;;;< <<<<<'?(?@@ B!BCBHBDDDDDE EEEEFF@HDHHHIIJJ3J6JJJK K"K$KBKGKKKxLyLLLLLLLMMNNOOOOQQRRRR0U5U3V4V2X3X?X@X`XaXzX{XXX3Y4Y}\\\\__bb c cfejehhi i?iBijikiii j jJjMjejfjjjjjjjjjjCEstwx%qwFL 7 @ R T K L !acqw"$hi)*[\ 38!!@!A!!!!!" "&"+"""!$'$L$Q$$$$$$$&%+%%%%%' '5';'((0)2)\)]){)|)))**p*v*'+*+R+W+. .F.G.////4///J0K0112233\5]556;6f7h7778888:::: ;;D;F;;;;;<<<<??&?(? @@B!BBBHBDDDEEE4H5HHHII'J(JJJKKK KAKGKLLLLMMOOQQRRRR/U5U1X3X>X@XJXKX_XaXsXtXvXwXyX{XXXXXXX\\__abeejehhi iiiji j jdjejjjjjjEs @ R '$0$///0h77;;KKtX{XXXhi ijjjjMarincicnC:\Dokumente und Einstellungen\Marincic\Anwendungsdaten\Microsoft\Word\AutoRecovery save of Rad_mipro_2005.asdMarincic+C:\Zdenko\Projects\Mipro\Rad_mipro_2005.docMarincicnC:\Dokumente und Einstellungen\Marincic\Anwendungsdaten\Microsoft\Word\AutoRecovery save of Rad_mipro_2005.asdMarincic+C:\Zdenko\Projects\Mipro\Rad_mipro_2005.docMarincicnC:\Dokumente und Einstellungen\Marincic\Anwendungsdaten\Microsoft\Word\AutoRecovery save of Rad_mipro_2005.asdMarincic+C:\Zdenko\Projects\Mipro\Rad_mipro_2005.docMarincic+C:\Zdenko\Projects\Mipro\Rad_mipro_2005.doczorapero1C:\Zdenko\Projects\Mipro\RFR_2\Rad_mipro_2005.doczorapero1C:\Zdenko\Projects\Mipro\RFR_3\Rad_mipro_2005.docetklohr\C:\Documents and Settings\etklohr\My Documents\CLANAK\MIPRO\MIPRO_2005\Zdenko_mipro_2005.doc 0>BzcY%NtLt@-$:L3E9Zp}G,43`N\UcN9HfeMqx?x^q^`o(.^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.^`o()^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.88^8`o()^`OJPJQJ^Jo( 0 ^ `0o()  ^ `o()xx^x`.^`o(^`.^`.L^`L.p  ^ `OJPJQJ^Jo(   ^ `OJQJo(o xx^x`OJQJo( HH^H`OJQJo( ^`OJQJo(o ^`OJQJo( ^`OJQJo( ^`OJQJo(o X X ^X `OJQJo(88^8`o()^`. L ^ `L.  ^ `.xx^x`.HLH^H`L.^`.^`.L^`L.^`OJPJQJ^Jo( ^`OJQJo(o pp^p`OJQJo( @ @ ^@ `OJQJo( ^`OJQJo(o ^`OJQJo( ^`OJQJo( ^`OJQJo(o PP^P`OJQJo(^`o()^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.^`o(.^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.^`o()^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.^`o(.^`.pLp^p`L.@ @ ^@ `.^`.L^`L.^`.^`.PLP^P`L.88^8`o()^`. L ^ `L.  ^ `.xx^x`.HLH^H`L.^`.^`.L^`L. E9eMq3`N?xp}GcYUc%t@-:L30>B                    rtfnM >ZN   Ǝ        LlG                                                             #$?X@XKX`XaXtXwXzX{XXXXXj@HH0zHH "$%')*+./235679;<=?@BEJKLQY3Z3e3i3jj`````` `"`H@`&`:`H`L`N`R`V`X`Z```b`h`j`n`@`r`v`z`@`~`````````l@````@UnknowncarMarincicGz Times New Roman5Symbol3& z Arial?5 : Courier New;Wingdings"hʚFʚFtX-!r0d.lE 2QAModeliranje i sumulacija procesa testiranja programskih proizvodaMarincicetklohrOh+'00 @L h t BModeliranje i sumulacija procesa testiranja programskih proizvodaiode Marincicje ariari Normal.dot etklohr2klMicrosoft Word 9.0a@F#@“ I@“ ItX՜.+,D՜.+,l( hp|  Zt-.l BModeliranje i sumulacija procesa testiranja programskih proizvoda Title 8@ _PID_HLINKSA a$mailto:Zdenko.Marincic@ericsson.com~nHL isplativost  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F#IData M1TablePWordDocument SummaryInformation(DocumentSummaryInformation8CompObjjObjectPool#I#I  FMicrosoft Word Document MSWordDocWord.Document.89q