Fondacije u testiranju softvera Standardi testiranja softvera Testiranje kroz zivotni ciklus programa Tehnike testiranja softvera Tehnike

testiranja dizajna Menadzment testiranja Alati za testiranje Primer ISTQB fondacije

Uvod
Zar nisu pravila i mere ono to ini ivot sigurnim i lakim, jednom reju organizovanim?! Do koje mere je organizacija neophodna i u kojim oblastima i da li uopte postoje sfere ivota u kojima ne postoje standardizovane vrednosti?! Ovakva pitanja nastala su jako davno i bila nametnuta razvojem industrije i nauke, kao i tendencijom da se nae zajedniki jezik razvoja industrije, tehnologije i mnogih drugih grana, kako u internom(nacionalnom), tako i u eksternom(internacionalnom smislu). Otuda standardi. Zar nije ono to razdvaja dobro i loe, zapravo kvalitet, bilo da se radi o oveku ili proizvodu?! No, zanima nas proizvod...Ako proizvodimo, kako da dostignemo eljeni nivo kvaliteta, kako da taj nivo odrimo i kako da budemo sigurni da e to biti ono to kupac trai? Otuda standardi kvaliteta. Postoji li nain da razvijamo softver koji e biti kvalitetan, lak za odravanje i zadovoljiti zahteve trita?! Postoji li nain da taj nain bude jedinstven, ponovljiv i dokumentovan i da nam umanji trokove prekasno spoznatih nedostataka proizvoda?! Otuda primena standarda u informacionim tehnologijama, a posebno onih koji se odnose na kvalitet softverskih proizvoda. Negde izmeu elemenata uspeha i svuda u pozadini procesa razvija se nova i sve popularnija disciplina. Ono to se proizvodi za druge, mora se probati i okusiti na sopstvenom primeru. Otuda testiranje softvera. Danas, kada je trite nemilosrdno, ostaje samo jedan siguran nain da se postignu eljeni ciljevi i da se obezbedi bar priblino kontinuitet uspeha u softverskoj industriji. Softverski proizvod se, kao najnenija biljka, planira, razvija, prati i kontrolie, a na kraju posebno oblikuje, kako bi se isporuio kupcu i zadovoljio zahteve. Kao i obino, sve se koncentrie oko poslednje karike u lancu - kupca. ini se da je pored svih napora, dokumentacije, pravila, procesa, pored sve organizacije i planova, najvanija re onih koji proizvod zaista koriste. Recept za uspeh je jako

vaan, a sadraj recepta ine: standard, kvalitet, testiranje i razvoj softvera i kupac. Nekad i izmeanim redosledom.

1. Fondacije u testiranju softvera

1.1. Definicija testiranja

Testiranje je aktivnost izvedena radi evaluacije kvaliteta proizvoda i njegovog poboljanja, putem identifikovanja defekata i problema. Testiranje softvera se sastoji od dinamike verifikacije ponaanja programa na konanom skupu test sluajeva, prikladno izabranih iz obino beskonanog domena izvravanja, prema oekivanom ponaanju (izvor: Guide to the SWEBOK). Znaenje pojedinih termina iz prethodne definicije blie je objanjeno u nastavku teksta: 1) Dinamiko - testiranje podrazumeva izvravanje programa sa validnim ulazima. Sama ulazna vrednost nije dovoljna, kompleksni sistemi mogu reagovati razliito na isti ulaz u zavisnosti od stanja sistema. 2) Konano - u veini programa, mogue je postaviti toliko test sluajeva da iscrpno testiranje moe da zahteva vremenski dugotrajne periode (mesece ili godine). 3) Izabrano - mnoge predloene test tehnike razlikuju se po tome kako se bira skup testiranja, gde lei velika odgovornost na softver inenjeru, jer razliit izbor daje razliitu efikasnost. Kako identifikovati najprikladniji kriterijum selekcije je vrlo kompleksan problem. 4) Oekivano - kako odluujemo da li su posmatrani izlazi oekivani ili ne? Oekivano ponaanje moe biti provereno prema: oekivanjima korisnika (testing for validation) specifikaciji (testing for verfication)

Sl.1. Testiranje softvera Testiranje nije aktivnost koja poinje samo nakon kompletiranja faze kodiranja. Softversko testiranje se danas vidi kao aktivnost koja obuhvata ceo proces razvoja i odravanja i predstavlja vaan deo kompletne konstrukcije softvera. Planiranje testiranja treba da pone sa ranom fazom requirement procesa, i test planovi i procedure moraju biti sistematski i kontinualno razvijani i po potrebi redefinisani. Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbei probleme nego ih ispravljati.Na osnovu gore navedenog, oblast softverskog testiranja tesno je vezana sa svim drugim oblastima Softverskog Inenjerstva.

1.2.

Zahtevi za stalnim razvojem

Postoji veliki nesklad izmeu sve sloenijih softverskih reenja i tehnika, alata koji se primenjuju u procesu razvoja softvera i procesa testiranja softvera. Zahtevi za softverskim reenjima u svim oblastima dramatino rastu uz konstantan zahtev: bre, bolje i jeftinije. Sa druge strane, i oekivanja korisnika softvera su nerealno velika. Zahtevi za razvoj i testiranje softverskog proizvoda daleko prevazilaze znanje i iskustvo programera i menadera na tritu.

1.3.

Kvalitet softvera i testiranje

Kvalitet softverskog proizvoda se usmerava ka obezbeenju to je mogue manje greaka u softveru, njegovoj funkcionalnosti koja zadovoljava ili prevazilazi oekivanje korisnika softvera. Aktivnost testiranja softvera se normalno izvodi kao sredstvo pronalaenja greaka sa ciljem njihovog odstranjivanja iz softverskog proizvoda.

1.4.

Mitovi o testiranju softvera

Neki od mitova u procesu razvoja softvera su: "Testiranje softvera je proces kojim se demonstrira da defekti ne postoje u softveru razvijenom za datu aplikaciju." "Testiranje softvera je aktivnost ili proces kojim se pokazuje ili demonstrira da program ili sistem izvrava sve predviene funkcije korektno." "Testiranje softvera je aktivnost kojom se obezbeuje potreban nivo 'poverenja' u to da program ili sistem izvrava ono to je trebalo da uradi, na osnovu skupa zahteva koje je korisnik specificirao." Svi navedeni mitovi su opti za sve definicije testiranja softvera.U njima ima osnovnih pogrenih shvatanja koje spadaju u mitove o testiranju softvera.Problem je u tome to svi mitovi imaju pozitivistiki pristup u shvatanju definicije testiranja softvera. Drugim reima, svaki odnavedenih mitova testiranja softvera, u nabrojanim definicijama tvrdi da je testiranje softvera aktivnost kojom se potvruje da program ili sistem neto radi dobro. Meutim, vrlo je lako dokazati da softver/sistem neto radi dobro, ali je teko dokazati da neto ne radi dobro. Ustvari, skoro je nemogue dokazati da greke ne postoje. Ako neki konkretan test nije otkrio greku (defekt), to ne znai da defekti u softveru ne postoje. Postavlja se pitanje, ta znai to to taj test nije otkrio defekt? Ovi mitovi nose uverenje da se testiranje softvera vidi kao izbegavanje sutine greaka u softveru.ta je onda testiranje softvera?Testiranje softvera je proces izvravanja programa/funkcije sistema sa ciljem da se otkriju greke".

1.5.

Testiranje softvera i otkrivanje greaka

Posebna panja danas se posveuje aktivnosti otkrivanja greaka. Ovo je bitna razlika u odnosu na shvatanje da je vano potvrditi da program ili sistem radi. Ova definicija testiranja softvera je napisana u knjizi Glenford Myers "Umetnost testiranja softvera". Ovakvu definiciju je dao iz razloga to je tvrdio da je softver jedan od najkompleksnijih proizvoda ljudskog umnog rada. Nemogue je otkriti sve greke u softveru.Nemogue je dokazati da je softver bez greke.Takoe je jasno da je nemogue pobediti prosto ubeenje o imperativu da se otkriju sve greke.

1.6.

Zato testiranje?

Zato to su veliki gubici kompanija koje razvijaju softver upravo zbog velikog broja defekata u isporuenom softveru kupcima. Zato je prvenstveni zadatak test inenjera otkrivanje problema u softveru sa ciljem da se oni otklone pre predaje softverskog proizvoda kupcu. Test inenjer mora i eli da otkrije to je mogue vie problema i to to vie onih, vrlo ozbiljnih ije posledice mogu biti katastrofalne sa materijalnog i bezbednosnog aspekta. Tako postaje kritian zahtev da se proces testiranja softvera uini to efikasnijim i uz to manje trokove ukoliko je to mogue.

1.7.

Negativan prizvuk testiranja

Osnovni aksiom testiranja softvera u okviru razvojnog ciklusa softvera je "Izvreni test koji otkrije problem u softveru je uspeh?"Znai, imamo problem koji nazivamo uspehom? Doprinos aktivnosti testiranja softvera je programski kod visoke pouzdanosti, velike otpornosti (robustan), vrlo stabilan i da potvrdi da softver zadovoljava skoro sve zahteve krajnjeg korisnika ili one koje je obavezno zahtevao. Zato se aktivnost testiranja softvera smatra destruktivnom prema programskom kodu, mada se na kraju pokazuje da je ta aktivnost vrlo konstruktivna. Testiranje softvera je aktivnost za koju se vezuje negativan prizvuk iako je njen krajnji cilj, stvaranje boljeg softverskog proizvoda, jer je operativno usmerena na slabe karike' procesa razvoja kao i ka kvalitetu samog softverskog proizvoda.

1.8.

Vreme za testiranje

Ukoliko se uspostavi stroiji proces obezbeenja kvaliteta softvera u pogledu efikasne prevencije i detekcije greaka, utoliko menjamo opte miljenje o tome kako se obezbeuje visok kalitet softverskog proizvoda. Drugi problem je taj, da skoro nikad nema dovoljno vremena za testiranje softvera. Zato treba da menjamo odnos prema aktivnosti testiranja softvera i vremenu koje je planirano za testiranje, tako to emo ga efikasnije utroiti u ranim fazama razvoja softvera. Potrebno je misliti o testiranju softvera ve prvog dana nakon poetka projekta, a ne kao to je uobiajeno da se aktivnost testiranja softvera planira na kraju razvoja softvera.

1.9.

Otklanjanje greaka

Pristup testiranju softvera na bazi otklanjanja greaka je takoe proces koji je podloan grekama. Tester softvera mora da identifikuje i proprati uoen problem do mesta nastanka (izvora) greke u softveru. Za otklanjanje greaka u softveru se moraju istraiti sve prethodne verzije i dokumentacija o aktivnostima u svim prethodnim fazama u razvoju softvera, ukoliko su raspoloivi. Cilj da se pokae da softver nema greaka, kroz otkrivanje i otklanjanje greaka, je loija od strategije da se izvri analiza uzroka nastanka greaka pa tek onda izvri uklanjanje greaka.

1.10. Prevencija greaka

Mnogo je efikasnije spreiti nastanak greaka nego detektovati i otkloniti iste. To znai da treba testirati svaku proceduru ili modul odmah nakon njegovog pisanja. Testiranje u fazi integracije sistema se mora izvriti odmah nakon integracije komponenti softvera u sistem.

1.11. Trokovi otklanjanja greaka

Trokovi otklanjanja uoenih greaka, umesto spreavanja njihovog nastanka, su veliki i prouzrokuju veliki gubitak u poslovanju i nezadovoljstvo kupca zbog greaka u softveru. Pre nego to se eka zavretak faze implementacije komponente softvera, pa tek onda testiranje komponente u cilju otkrivanja i otklanjanja greaka u njima, a koje su nastale u ranijim fazama procesa razvoja, potrebno je preventivno delovati na nastanak tih greaka kako bi se izbegla kanjenja i uveali trokovi njihovog otklanjanja. Upravo je to cilj sprovoenja aktivnosti prevencije nastanka greaka. U poslednje vreme je razvijen veliki broj metoda u cilju spreavanja nastanka greaka u softveru (engl.Cleanroom Software Engineering, Zero Defect Software i dr.), metod dokazivanja korektnosti softvera, (engl.Failure Mode Analysis (FMA)), strategija projektovanja po Six Sigma i dr.

1.12. Testiranje i kvalitet

Gene Krinz, direktor svemirskog programa u NASI je konstatovao da postoji problem u softverskom inenjerstvu po pitanju kvaliteta softvera tvrdnjom da: "Ne moete testiranjem ugraditi kvalitet softvera". Ne moe se ugraditi kvalitet, niti otkloniti problemi u kvalitetu softvera samo aktivnostima testiranja softvera. Ovo postaje oigledno ukoliko zahtevi za kvalitetom nisu postavljeni u zahtevima za projekat softvera, u fazi analize, dizajna ili implementacije, tako da se testiranjem softvera ne moe ni ugraditi niti otkloniti problemi kvaliteta softvera kroz klasian pristup testiranja softvera. Jedan od ciljeva uspenih procesa razvoja je evaluacija kvaliteta softverskog proizvoda. Dok se nekoliko atributa kvaliteta softvera moe oceniti aktivnostima u sklopu testiranja, dobar deo njih mora se ugraditi kroz dizajn softverskog proizvoda.

1.13. Poboljanja procesa testiranja

Poboljanja procesa testiranja je konstantan proces zajedno sa svim drugim elementima razvoja softvera. Angauju se sve vei resursi kako velikih tako i malih kompanija u proces testiranja i njegovo unapredjenje. Postoji vie aspekata koji doprinose poboljanju procesa testiranja: obuka kadrova za proces testiranja automatizacija procesa testiranja razvoj novih alata razvoj novih modela testiranja integracije procesa merenja parametara efikasnosti i efektivnosti procesa testiranja analize slabih i jakih strana postojeeg procesa testiranja identifikacije rizika i njihovih posledica na uspeh procesa razvoja

2. Standardi u testiranju softvera

2.1. Standardi

Standard (eng. standard) - svaka zakonom utvrena mera, merilo; zakonska novana stopa i sl.; neto to vai kao uzor, obrazac, to je priznato kao klasino; standard ivota (eng. standard of life) prosena mera zadovoljavanja ekonomskih potreba kod pojedinca, pojedinih drutvenih klasa (apstraktno - naroda); trgovinski obrazac. Sandardni (eng. standard) - koji se odnosi na standard, koji odgovara standardu; istog tipa, tipian. zlato normalno, novano zlato, zlato od 22 karata; standard obrazac;

2.2.

Kratka istorija standarda

Standardizacija je proces koji ima korene u drevnim civilizacijama Vavilona i ranog Egipta. Najraniji standardi su bili fiziki standardi za teinu i mere.Neki su nastali u kraljevskim porodicama. Kralj Henri I je standardizovao merenja, tako to je uveo meru ell(lakat), koji je bio ekvivalent za duinu njegove ruke. Praistorija - Jedan od najranijih primera standardizacije je kalendar. Drevne civilizacije, oslanjajui se na poloaj sunca, meseca i zvezda, odreivale su pravo vreme da sade i beru useve, da slave praznike i prate vane dogaaje. Pre vie od 20000 godina, preci ledenog doba u Evropi pratili su dane crtajui linije u peinama tapiima i kostima. Kasnije, kako se razvijala agrokultura i obraivala zemlja, bili su potebni mnogo precizniji naini da se predvide sezonske promene. Sumeri su, u dolini Tigra i Eufrata, imali kalendar jako slian ovom koji danas koristimo. Pre 5000 godina , sumerski zemljoradnik je koristio kalendar koji je godinu delio na 30 meseci. Svaki dan je bio podeljen na 12 sati, a sat na 30 minuta. Egipani su prvi razvili 365- dnevni kalendar. Bazirali su merenje godine na izlasku zvezde Sirus svakih 365 dana i povezivali ga sa poetkom uzgajanja u dolini Nila. Neki standardi su bili ishod ovekove elje da harmonizuje aktivnosti uvoenjem vanih izmena u okruenju. Drugi su opet kreirani kao posledica odgovora na potrebe sve kompleksnijeg drutva. Kako se trgovina i razmena razvijala, pisani dokumenti postali su nain da se izraze standardi vezani za proizvode i usluge (u oblasti agrokulture, brodogradnje, graevine i oruja).U poetku su predstavljali samo vid dogovora izmeu snabdevaa i korisnika.Kasnije su se koristili u transakcijama formirajui osnovu za modernu standardizaciju.Industrijska revolucija - Sa razvojem industrijske revolucije u XIX veku, povana potreba za transportom dobara dovela je do pojave

naprednih oblika transporta. Izum eleznice je predstavljao brz, ekonomian i efektivan nain slanja proizvoda irom zemlje. Ovu prednost omoguila je standardizacija ina.Nakon industrijalizacije u XIX veku, odsustvo standarda izazivalo je haos i ugroavanje javne sigurnosti. Brojni su primeri raznih neslaganja u elektrinim instalacijama koja su dovodila do spojeva, eksplozija i oteenja.Ovakvi dogaaji su rezultirali standardizacijom, na optu dobrobit svih. XX vek - Gradovi su doiveli veliku ekspanziju u XX veku. Kako su se gradovi irili i infrastruktura postajala sloenija postalo je oito da e biti neophodan jedinstven skup nacionalnih standarda, kako bi se obezbedila opta sigurnost stanovnitva. Godine 1904, izbio je poar u skladitu John E. Hurst & Company Building u Baltimoru(SAD). Nakon to je zahvatio celokupnu strukturu, prelazio je sa zgrade na zgradu, dok se nije proirio na 80 blokova grada. Kako bi pomogla u gaenju poara, pristigla su pojaanja iz Njujorka, Filadelfije i Vaingtona, ali to nije uspelo. Creva za vodu nisu se mogla prevezati na hidrante u Baltimoru. Primorani su da bespomono gledaju kako se vatra iri i unitava oko 2500 zgrada i gori vie od 30 sati. Bilo je jasno da se mora razviti novi nacionalni standard, kako bi se spreile sline situacije u budunosti. Razvoj tehnologije pratio je razvoj standardizacije. Danas je ona na zavidnom nivou i bavi se i najsitnijim detaljima obezbeujui red i preciznost. U proteklih 100 godina standardizacija se proirila sa proizvodnje na usluge.

2.3.

Pojam standarda

ta su stanardi? Objavljeni dokment koji je doneen konsenzusom i odobravanjem uvaenog tela, koji uspostavlja specifikacije i procedure kako bi osigurao da materijal, proizvod, metod ili usluga slui sopstvenoj svrsi I da je konzistentna sa namenom.ISO/IEC voidi 2: 1996 definie standard kao dokument, uspostavljen konsenzusom i slaganjem priznatog tela koji omoguava stalnu upotrebu pravila, vodia ilikarakteristika, za aktivnosti ili rezultate aktivnosti, sa ciljem da se dostigne optimalni stepen reda u datom kontekstu. Prosto reeno, standard je objavljeni dokument koji uspostavlja specifikacije i procedure, dizajniran da obezbedi da meterijal, proizvod, metodili usluga slue svrsi i da su konzistentni u upotrebi.

Standardi reavaju pitanja kompatibilnosti proizvoda, sigurnosti klijenata i zdravstvena pitanja.Standardi takoe pojednostavljuju razvoj proizvoda, raduciraju trokove i omoguavaju korisniku da poredi konkurentske proizvode.Standardi su osnovni gradivni elementi meunarodne razmene.Samo kroz korienje standarda se mogu postii zahtevi interkonektivnosti i interoperabilnosti, potvren kredibilitet novih proizvoda i novih trita i omoguena brza implementacija tehnologije. Zato su standardi vani? Godinji izvetaj amerikog drutva za testiranje i resurse (ASTM) iz 1991.godine daje pogodan odgovor na ovo pitanje: Standardi predstavljaju tokove komunikacije za proizvoae i korisnike. Oni slue kao zajedniki jezik, definiu kvalitet i uspostavljaju sigurnosni kriterijum.Trokovi su manji kada proizvoai koriste standarde.Trening je pojednostavljen.Kupci prihvataju proizvode mnogo lake kada mogu da ih procene na osnovu pravih vrednosti. Kako nastaju standardi? Standardi - objavljene specifikacije - su neprocenjivi svetski resurs, a proces koji vodi ka standardizaciji je jako zahtevan. Postoji vie od pola miliona objavljenih standarda, koji su proizvod vie od 1000 priznatih organizacija za razvoj standarda irom sveta. U sutini, svaka zemlja ima telo koje je zadueno za nacionalne standarde. To su privatne ilijavne organizacije ili kombinacije ova dva oblika. Objavljeni standardi ne obuhvataju brojne interne standarde, koji podupiru svaki uspean poslovni proces. Kriterijum za razvoj javno dostupnih standarda je da predstavljaju konsenzus zajednice tehnikih eksperata, naroito odabranih da donose odluke i doprinose procesu standardizacije.Velika kolekcija akumuliranog znanja i ekspertize je skupa. Postoji pratei ekonomski troak njihovog doprinosa koji danas poprima velike razmere. U Australiji postoji oko 9000 lanova tehnikog komiteta. Procenjeno je da njihov doprinos vredi 30 miliona dolara godinje, kada se posmatra kao oportunitetni troak. U Nemakoj postoji oko 50 000 lanova tehnikog komiteta, a u Egleskoj oko 31000. U Sjedinjenim Amerikim Dravama postoji preko 400 organizacija za razvoj standarda iz oblasti industrije, gde svaka od njih ima mnogo tehnikih komiteta, od kojih su neki po lanstvu vei od nekih komiteta u svetu. Procena broja ljudi koji uestvuju u procesu standardizacije irom sveta ukazuje na cifru od preko pola miliona ljudi. Koristei australijski oportunitetni troak kao parametar, realno je zakljuiti da se u

proseku 1.5 milion dolara investira na globalnom nivou svake godine za kreiranje i menadment standarda. Rezime U poetku su standardi bili jedinstveni dokumenti i deo dogovora izmeu dobavljaa i korisnika. Kasnije se koncept standarda proirio, kako bi se isti mogli koristiti u mnogim transakcijama. Ova portabilnost proizvela je skup kriterijuma i osnova je moderne standardizacije. Nakon ubrzane industrijalizacije ranog XIX veka, sveopte odsustvo nacionalne standardizacije izazvalo je veliku neefikasnost. Nedostatak pravila bio je veliki troak.Vrednost standardizacije u obliku specifikacija, materijala, testiranja je prepoznata kao nacionalni prioritet tek krajem XIX veka. Do kraja stolea standardizacija je doivela procvat i nastavljala je sa razvojem u savremenom drutvu. Proirila se daleko izvan prvobitnih okvira i ukljuila sigurnost kupaca, zdravlje u cilju poboljanja kvaliteta i komfora svakodnevnog ivota. Standardi predstavljaju alat za organizaciju tehnikog sveta i merila koja se koriste za uspostavljanje norme za menadment procedure. Oni podravaju oekivanja kupaca da eproizvodi koje koriste biti sigurni, pouzdani i da e odgovarati svrsi. Dakle, standardi su postali sastavna komponenta ekonomskog, socijalnog i pravnog sistema u toj meri da se esto podrazumevaju i predstavljaju nezaobilazni deo modernog drutva.

2.4.

Standardizacija

Standardizacija (eng. standardization) - racionalizacija proizvodnje putem smanjivanja veeg oblika proizvodnje na manji broj tipinih obrazaca (standarda istog kvaliteta, oblika, veliine, teine itd.). Standardizacija je proces koji ukljuuje planiranje, razvoj i primenu dokumentacije vezane za standarde. To je proces spajanja naunog istraivanja sa iskustvom primene radi utvrivanja preciznih, optimalnih tehnikih zahteva jednog aspekta tehnologije. Ishod ovog spajanja je autoritativni dokument koji se naziva standard. Standard je dokument koji uspostavlja uniformni inenjering ili tehnike specifikacije, kriterijume, metode, procese ili prakse. Neki standardi su obavezni, dok su drugi voluntarni. Neki standardi su de facto, oznaavaju norme ili zahteve koji imaju neformalni, ali dominantni status. Neki standardi su de jure, oznaavaju formalno-pravne zahteve. Tela za standardizaciju npr. Internacionalna organizacija za standardizaciju(ISO) ili Ameriki nacionalni institut za standardizaciju(ANSI) su nezavisne od proizvoaa dobara za koje objavljuju standarde. Cilj standardizacije moe biti i podsticanje nezavisnosti dobavljaa, kompatibilnosti, interoperabilnosti, sigurnosti, pouzdanosti ili kvaliteta. U drutvenim naukama,

ukljuujui i ekonomiju, ideja standardizacije bliska je pojmu reenja koordinacionog problema, situaciji u kojoj sve strane mogu da realizuju dobit, ali samo ako zajedniki donose odluke. Standardizacija je proces za odabir boljih opcija i potvrdu istih u obliku standarda. Ovo stanovite ukljuuje sluaj spontane standardizacije procesa kako bi se kreirali de facto standardi. Dakle, standardi mogu biti: - De facto standardi koji su praeni neformalnom konvencijom ili dominantnim korienjem. - De jure standardi koji su deo pravno kreiranih ugovora, zakona ili regulativa. - Voluntarni standardi koji su objavljeni i raspoloivi za upotrebu. Kada bi koristili vojniku terminologiju, pod pojmom standardizacija podrazumeva se: Razvoj i implementacija koncepata, doktrina, procedura i dizajna za postizanje i odravanje zahtevanih nivoa kompatibilnosti, razmene ili jedinstva u operativnom, proceduralnom, materijalnom, tehnikom i administrativnom smislu, kako bi se dostigla interoperabilnost. Standardizacija je poznata kao neophodna disciplina za sve trine uesnike koji tee da budu kompetitivni. Kompanije u dananje vreme integruu standardizaciju i poslovno planiranje u glavni tehniki i komercijalni element.

2.5.

Standardi u informacionim tehnologijama

2.5.1. Primena standarda u informacionim tehnologijama

Standardizacija u informacionim tehnologijama doprinosi efikasnijem uspostavljanju informacionih funkcija, njihovoj veoj stabinosti i lakoj tranziciji. Primena meunarodnih, nacionalnih i internih standarda u procesu razvoja softverskih proizvoda stvara uslove za razvoj efikasnog, ekonominog, pouzdanog i sigurnog softverskog proizvoda. Standardizacijom procesa razvoja softvera, njegovim planiranjem, kvantifikovanjem i praenjem, dokumentovanjem i neprekidnim poboljanjem I unapreenjem stvaraju se preduslovi za realizaciju softverskih proizvoda definisanog kvaliteta. Dobro dokumentovani sistem, u skladu sa standardima, je lako zamenjiv, prenosiv sa jedne softverske i hardverske platforme na drugu i titi investiciju. Da bi se razvio kvalitetan informacioni sistem neophodno je da se njegov razvoj zasniva na usvojenim standardima(meunarodnim, nacionalnim, internim) i da se vre mnogobrojna vrednovanja tokom njegovog ivotnog ciklusa. Vrednovanja ukljuuju:

vrednovanje korienih softverskih proizvoda, meuproizvoda u vakoj fazi ivotnog ciklusa i, krajnjih proizvoda tj. instaliranog softvera i dokumentacije. Vrednovanje i standardizacija alata koji se koriste u procesu razvoja informacionih sistema stvaraju mogunost da kvalitet samog procesa, kao i krajnjih proizvoda, bude na eljenom i oekivanom nivou. Posmatrano sa stanovita sloenih informacionih sistema, u ijem razvoju i implementaciji uestvuje vie organizacija, primena standarda, ne samo da obezbeuje odgovarajui kvalitet krajnjeg proizvoda i procesa razvoja, nego stvara mogunosti za razmenu projekata izmeu pojedinih organizacija, olakava obuku korisnika i stvara uslove za zajedniki rad na projektima predstavnika razliitih organizacija. Ekspanziju razvoja softvera, u razliitim oblastima, pratio je i razvoj standarda, procedura, metoda i alata za razvoj i upravljanje softverom. Raznovrsnost je stvorila mogue potekoe u upravljanju softverom, posebno kada se radi o softveru koji je vezan za proizvode ili usluge. Ova pojava uslovila je potrebu da se za softversku disciplinu definie zajedniki okvir koji bi posluio svima koji se bave softverom da govore istim jezikom u razvoju, projektovanju i upravljanju softverom u njihovim okruenjima. Standard je tako projektovan da se moe prilagoditi potrebi organizacije, projekta ili specifinoj primeni. Moe se primeniti u sluajevima kada je softver samostalan entitet ili sastavni deo sloenog sistema. Danas se standardi primenjuju u mnogim granama. Informacione tehnologije predstavljaju klju za reformu zdravstva. Elektronski zdravstveni izvetaji tede vreme i novac, umanjuju verovatnou medicinske greke, a kada ih je mogue deliti elektronskim putem, tada utiu na svaki korak u procesu leenja. Deljenje informacija zahteva interoperabilnost. Postizanje interoperabilnosti znai utvrivanje standarda, kako bi jedan sistem mogao da govori sa drugim, razmenjujui podatke precizno, efikasno i sigurno. Zdravstveni IT standardi omoguavaju da slube zdravstva imaju brz, siguran pristup tanim izvetajima svakog pacijenta. Herbalna medicina je grana u kojoj se standardizacija odnosi na obezbeenje procesa proizvodnje materijala koji sadri odreenu koncentraciju specifinog indikatora koji se u njemu sadri. U statistici, standardizacija se odnosi na konverziju u standardne rezultate. U testnoj teoriji, standardizacija oznaava merenja sprovedena pod preciznim, specificiranim i ponovljivim uslovima. Sa stanovita nove institucionalne ekonomije, standardizacioni proces poinje sa socijalnim problemom poznatim kao ve pomenuta koordinaciona dilema i realizacija sveoptih ciljeva. Naravno, kako se informacione tehnologije ubrzano razvijaju u svakom pogledu i ispunjavaju sve

sfere ivota, tako i standardi postaju pratei element koji uvodi red i omoguava kontinuitet napretka.

2.6.

Tvorci informacionih standarda

ISO (Meunarodna organizacija za standardizaciju) i IEC (Meunarodna elektrotehnika komisija) zajedno formiraju sistem za optepriznatu standardizaciju kao celinu. Nacionalne institucije, koje su lanice ISO i IEC, uestvuju u razvoju meunarodnih standarda kroz rad u tehnikim komitetima koje je ustanovila odgovarajua organizacija radi obrade posebnih oblasti tehnikih aktivnosti. Tehniki komiteti ISO i IEC sarauju na poljima od obostranog interesa. Meunarodne organizacije, vladine i nevladine, koje su u vezi sa ISO i IEC, takoe uestvuju u tom radu.

Sl.2. ISO logo

Sl.3. IEC logo

Meunarodni standardi se objavljuju prema pravilima koja su data u ISO/IEC uputstvima.U podruju informacione tehnologije ISO i IEC su ustanovili zdrueni tehniki komitet, ISO/IEC JTC 1. Nacrti meunarodnih standarda koje je usvojio zdrueni tehniki komitet alju se svim nacionalnim telima na saglasnost pre njihovog usvajanja kao meunarodnih standarda. Usvajaju se prema postupku po kome standard mora da usvoji najmanje 75 % lanica. Postoje dva osnovna tipa standarda: 1. Standardi proizvoda (odreuju karakteristike i funkcionalne zahteve proizvoda) 2. Standardi procesa (odreuju nain na koji proizvodi treba da budu razvijeni)

Institucije u Srbiji Zavod za standardizaciju je nacionalna organizacija za standardizaciju. lanica je meunarodnih organizacija za donoenje standarda ISO i IEC. Na osnovu lanstva u tim organizacijama, Zavod za standardizaciju, dobija standarde i ostala dokumenta tehnikih komiteta. Komisije Zavoda za standardizaciju prate rad meunarodnih tela za donoenje standarda u odgovarajuim oblastima (npr. komisija KSI 1/07 prati rad tehnikog komiteta ISO/IEC JTC1 SC 07, Information technology - Software and system engineering). U skladu sa mogunostima i potrebama, komisije Zavoda za standardizaciju uestvuju u radu meunarodnih tehnikih komiteta, prisustvuju njihovim zasedanjima i po potrebi (u zavisnosti koji status imaju: posmatra ili aktivni lan) mogu glasati ili stavljaju primedbe na ponuene tekstove nacrta meunarodnih standarda. Institut za standardizaciju Srbije je vladina organizacija. Pored razvoja standarda,organizacija se bavi aktivnostima sertifikacije i nudi tehniku podrku na zahtev korisnika. Standardizacija je prvi put bila formalno, institucionalno organizovana 1946. godine. Vlada je usvojila Dekret o standardizaciji, na osnovu koga je organizovana Komisija za standardizaciju ija odgovornost je bila da razvija standarde. Razvoj je kasnije uneo transformacije u razliite institucionalne forme i omoguila oficijelni status vladinim organizacijama i Institutu za standardizaciju. Aktivnosti Instituta imaju za cilj da promoviu standardizaciju i kvalitet i da doprinesu poboljanju proizvoda i usluga. Odgovornost Instituta se regulie od strane Zakona o standardizaciji koji je stupio na snagu 2006. godine. Od 1996. godine standardi se razvijaju iskljuivo kao voluntarni standardi. Institut predstavlja Srbiju meu internacionalnim i evropskim organizacijama za standardizaciju(ISO, IEC, CEN i CENELEC) i u sistemima/emama za sertifikaciju (IECEE, IECEx i IECQ).

2.7.

Primena standarda na kvalitet softvera

Stanje u softverskoj tehnologiji jo ne obezbeuje dovoljno dobru i iroko prihvaenu emu za ocenjivanje kvaliteta softverskih proizvoda. Od 1976.godine uraeno je mnogo od strane pojedinaca na definisanju osnove za kvalitet softvera. Usvojeni su i proireni mnogi modeli (McCall-a, Boehm-a, US Air Force i drugi). Due vreme pouzdanost je bila jedini nain za merenje kvaliteta. Vremenom su kroz razne studije predloeni i drugi modeli. Iako su studije bile korisne, stvorile su zabunu, zbog toga to su ponueni mnogi aspekti kvaliteta. Dakle, postojala je potreba za jednim modelom standarda. Iz tog razloga je ISO/IEC JTC1 poeo da radi na usaglaavanju i ohrabruje opte prihvaenu standardizaciju. Prva razmatranja potiu iz 1978.godine, a 1985.godine poeo je razvoj standarda ISO/IEC 9126. Predloeni modeli prvenstveno uvode svojstva softvera koja zavise od aspekata primene ili implementacije, radi opisivanja kvaliteta softvera. Prvi korak

ISO tehnikog komiteta u sistematskom ureivanju svojstava je propao zbog nedostatka definicija. Eksperti su razliito interpretirali termine. Sve pominjane strukture nisu imale zajedniki osnovu. Na kraju je odlueno da je najbolji nain za postavljanje meunarodnog standarda postavljanje skupa karakteristika koje se zasnivaju na definiciji kvaliteta. Konano, nastali su i prvi standardi koji se odnose na kvalitet proizvoda i kvalitet softvera: ISO 9000, ISO/IEC 9126 i mnogi drugi pratei standardi.

3. Testiranje kroz zivotni ciklus programa

Da bi se razumeo nain izrade dobrog softvera, procenjivanje rizika kao i mogunosti koje softver unosi u na svakodnevni ivot, neophodno je vrsto teorijsko i praktino razumevanje softverskog inenjerstva. Izrada dobrog softvera predstavlja umetnost koja se ogleda u razumevanju naina apstrahovanja i modelovanja sutinskih elemenata problema, a zatim korienju takvih apstrakcija za projektovanje reenja. Dobra softver-inenjerska praksa tei da obezbedi softver koji e dati pozitivan doprinos nainu na koji ivimo, jer je u dananje vreme rad softvera prisutan u svim aspektima naeg ivota. Da bi se razumelo kako se softversko inenjerstvo uklapa u svet raunarske nauke treba objasniti da se raunarstvo usredsreuje na raunare i programske jezike, a softversko inenjerstvo iste koristi kao alate u projektovanju i primeni reenjanekog problema. Umesto da istrauje dizajn hardvera, softver inenjer se usredsreuje na raunar kao sredstvo za reavanje problema. Svaki haker moe da napie programski kod koji neto radi, ali su potrebni umee i znanje profesionalnog softverskog inenjera da bi se proizveo stabilan i razumljiv kod koji se lako odrava i koji efikasno i efektivno radi ono zbog ega je napravljen. Sutina softverskog inenjerstva je u projektovanju i razvoju visoko kvalitetnog softvera. Softversko inenjerstvo je stvaralaki postupan proces, koji okuplja veliki broj ljudi na poslovima izrade razliitih vrsta proizvoda. Prilikom pruanja usluga ili izrade proizvoda uvek se sledi niz koraka kako bi se izvrio neki skup zadataka. Zadaci se obino izvravaju u istom redosledu. Ureeni skup zadataka smatra se procesom: nizom koraka koji obuhvataju aktivnosti, ogranienja i resurse, a rezultiraju eljenim ostvarenjem. Proces izrade nekog proizvoda se ponekad naziva ivotni ciklus. Zbog toga se nekada softverski razvojni proces naziva i ivotni ciklus softvera jer opisuje ivot softverskog proizvoda od formulisanja, preko implementacije do isporuke, upotrebe, operativnog korienja i odravanja.

Procesi su vani jer omoguavaju strukturisanje i konzistentno predstavljanje skupa aktivnosti. Proces razvoja softvera moe biti fleksibilan u pogledu korienja alata i tehnika, koji pojedincima vie odgovaraju. Proces pomae da se odri nivo konzistentnosti i kvaliteta proizvoda ili usluga koje razliiti ljudi realizuju. Proces je sloeniji pojam od postupka. Postupak je umeren nain kombinovanja alata i tehnika u cilju izrade proizvoda (softvera). Proces predstavlja skup postupaka, organizovanih tako da rezultujui proizvod zadovolji unapred postavljeni skup ciljeva i standarda. Na primer, proces moe da zahteva da proverimo delove projekta pre poetka procesa kodiranja. Provera moe da se izvede neformalnim pregledom ili formalnom inspekcijom, od kojih je svaki postupak za sebe, ali im je isti cilj. Postojanje procesa omoguuje uenje na iskustvima ranije razvijenih projekata, dokumentovanje izrade softvera visokog kvaliteta i praenje procesa razvoja softvera. Razvoj softvera obino obuhvata sledee faze: Definisanje korisnikih zahteva; Projektovanje; Implementacija; Testiranje; Isporuka; Odravanje.

Svaka faza predstavlja proces koji se moe opisati skupom aktivnosti pri emu svaka aktivnost ukljuuje ogranienja, izlaze i resurse. Na primer, u fazi prikupljanja zahteva, kao poetni ulaz koriste se iskazi, koje formulie korisnik na neki od moguih naina. Izlaz ove faze je skup zahteva.

Postoje ogranienja kao to su budet i vremenski rok za izradu dokumenata o zahtevima, standardi vezani za tipove ukljuenih zahteva i notacija za njihovo iskazivanje.

Sl.4. Model procesa razvoja

3.1.

Modeli ivotnog ciklusa softvera

Svaki proces moe da se opie na razliite naine, pomou teksta, slika, ili njihovom kombinacijom. Istraivai u oblasti softverskog inenjerstva predlau razliite forme takvih opisa, odnosno modele ivotnog ciklusa softvera sa ciljem da se utvrdi nain na koji organizovane aktivnosti unutar procesa moe da dovede do efikasnijeg razvoja softverskog sistema. Na slici 4. prikazan je model razvoja procesa. Kao to se vidi sa slike na ulazu je specifikacija zahteva, u modelu razvoja procesa vri se projektovanje i testiranje aplikacije a na kraju se isporuuje gotov proizvod. Razlozi za modelovanje procesa: Kada grupa opie primenjivani proces projektovanja,opis postaje zajedniko shvatanje aktivnosti, resursa i ogranienja ukljuenih u razvoj softvera. Modelovanje pomae u nalaenju nedoslednosti, vikova i izostavljenih elemenata u samom procesu, to poboljava efikasnost procesa. Model treba da odraava ciljeve razvoja. Nakon izrade modela projektni tim ocenjuje aktivnosti sa aspekta njihove usklaenosti sa postavljenim ciljevima. Svaki proces mora biti napravljen prema situaciji ukojoj e se primenjivati. Modelovanje procesa pomae da projektni tim utvrdi mesta na kojima su potrebna prilagoavanja.

3.2.

Modeli za razvoj softvera

Razvoj softvera prolazi kroz niz procesa, zvani ivotni ciklus, koji ukljuuje sve aktivnosti i zadatke koji vode do inicijalnog otputanja proizvoda. Mogue je izgraditi model ivotnog ciklusa, koji ilustruje aktivnosti na velikim nivoima apstrakcije, i slui da uspostavi redosled u kojem projekat specificira, upotrebljava, testira i izvodi svoje aktivnosti. Modeli razvoja se pojavljuju od vremena kada su se projektima razvijali veliki softverski sistemi i prikazuju razliite poglede na proces razvoja softvera. Osnovni razlog njihove pojave bila je elja da se obezbedi uoptena ema razvoja softvera, koja bi sluila kao osnova u planiranju, organizovanju, snabdevanju, koordinaciji, finansiranju i upravljanju aktivnostima razvoja softvera. Modeli su apstrakcije koje pomau u procesu razvoja. Model softvera predstavlja komponente razvoja softvera i razvijen je na osnovu ideja konstruktora i njegove predpostavke ta je najznaajnije u tom razvoju. Model moe predstavljati: 1) 2) 3) Model procesa razvoja Model softvera ili Model naina upravljanja softverom

Primarni cilj kreiranja jednog modela je da se obezbede softverski proizvodi koji odgovaraju zahtevima korisnika. Zavisno od pojedinih faza i aktivnosti razlikujemo nekoliko modela softvera: 1) Preskriptivni modeli razvoja- konvencionalni modeli sa delimino razliitim tokom

procesa razvoja ali sa istim generikim aktivnostima; Model vodopada 2) 3) Inkrementalni modeli razvoja: Inkrementalni model, RAD model, Razvojni modeli: Model prototipskog razvoja, Spiralni model, Istovremeni model

razvoja ( Concurrent Development) 4) Specijalizovani modeli: Model zasnovan na komponentama, model zasnovan na

formalnim metodama, Model unificiranog procesa razvoja( Unified Process)

5)

Modeli

agilnog

razvoja:

Exreme

Programming

(XP),

Adaptive

Software

Development (ASD), Dynamic Systems Development Method (DSDM),Srum,Feature Driven Development (FDD) , Agile Modeling (AM)

3.2.1. Model vodopada (Waterfall)

Faze modela vodopada su prikazane na slici 5 na kojoj se vidi da je model vodopada visoko struktuiran proces baziran na dobro razvijenim koracima. Faze modela vodopad su: Prikupljanje informacija; Analiza; Projektovanje; Aplikativno modeliranje; Integracija sistema; Testiranje sistema; Odravanje sistema.

Prikupljanje informacija Analiza Projektovanje Aplikativno modeliranje Integracija sistema Testiranje sistema Odravanje sistema

Sl.4. Model Vodopad

Svaki korak je zavren i potpuno dokumentovan pre nego to sledei korak mora da zapone. Iskljuiva upotreba modela vodopada nije preporuljiva. Praenje ovog modela prouzrokovae nekoliko problema u ivotnom ciklusu razvoja softvera koji su dole navedeni: ekstra vreme tipino vie vremena nego to je u poetku predvieno za integraciju podsistema, radnih aplikacija. promene dizajna planovi zahtevaju specifine izmene proizvoda u procesu kodiranja softvera. neodgovarajue reflektovanje rizika projektni rizik nije reen sve do kasne faze ivotnog ciklusa softvera; nedostatak traenih revizija potrebe koje zahteva projekat moraju da budu stacionirana u prvim fazama razvojnog procesa. esto se deava da naruioci softvera ne razumeju u potpunosti posao, i proizvodne potrebe na poetku projekta. Veina softverskih projekata potrauje promene kroz projekat, koji dramatino poveavaju cenu i odlau vreme isporuke projekta. Ako izmene nisu integrisane u proizvodu, naruioci misle da proizvod koji primaju nije onaj koji su potraivali. manjak pregleda prva etiri stadijuma modela vodopada su papirno bazirane vebe i dokazuju da je projekat u progresu, tabaci papira mogu biti proizvedeni na kraju svakog zavrnog stadijuma. Kako su nivoi sistemske dokumentacije prezentovani veina shvaenih taaka su esto one koje se ponovo pregledaju, dok se za kompleksnije take prosto pretpostavlja da su tane. Tabela 1. Prednosti i nedostaci modela vodopada: PREDNOSTI: - Izlaz je definisan unapred - Striktna kontrola - Moe dobro da radi i sa tehniki slabo potkovanim i neiskusnim osobljem - Radi dobro kada su zahtevi za kvalitetom visoki NEDOSTACI: - Faze nisu povezane Potrebna je velika koliina

dokumentacije - Na kraju nema realnog izlaza - Zasniva se na dokumentaciji - Promene se teko ostvaruju - Teko je definisati poetak projekta

3.2.2. Spiralni (Spiral) model

Novije menaderske tehnike su rezultovale iterativnim pristupom primeni razvoja softvera, zvanog spiralni model, kao to se vidi na slici 5.2 nivoi primene razvoja ine da je ovaj model okarakterisan kroz faze [5]: prihvatanje aplikaciono planiranje i analiza elaboracija aplikacioni dizajn izgradnja implementacija aplikacije tranzicija ispitivanje i stabilizacija aplikacije;

90

Sl.6. Spiralni model Svaki stadijum spiralnog modela ukljuuje pet faza aktivnosti:

1. Zahtevi 2. Dizajn 3. Implementacija 4. Razvoj 5. Menadment Spiralni model se sastoji iz kontinualnih krugova. Kroz svaki krug se postie napredak ka konanoj funkcionalnosti softvera. Razvoj ivotnog ciklusa je dizajniran da ue definie softver preko vremena, tako da svaka iteracija pribliava softver do take isporuke.

Kao i model vodopada, spiralni model se suoava sa problemima kao to su sledei: odlaganje karakteristika kompleksne karakteristike koje su vane za naruioce i korisnike su pomerene u kasnije iteracije projekta. Pomeranje vanih karakteristika umanjuje upotrebljivost projekta; nikad dovreni projekti pojedinci i organizacije treba projekte da privedu kraju. Ako se poslovni ciljevi projekta menjaju posle brojnih iteracija u projektu, postoji tendencija da lanovi tima nastave sa radom da bi dobili komplementarnih karakteristika, bez adresiranja izmenjenih ciljeva; nepoznati trokovi kontinualna iteracija koja pomera i odgaa karakteristike, oteava cost/benefit analizu karakteristika. Ovi trokovi projekta su teki za identifikaciju i upotrebu u buduim projektnim opravdanjima; bez oseaja stabilnosti kada su sistemi u konstantnom kretanju, kupci i korisnici esto oseaju da je proizvod nestabilan. Konstantna modernizacija zahteva resurse za odravanje proizvoda i znaajno uveava trokove razvoja softvera; nedostatak automatizacije mnoge organizacije proputaju da investiraju adekvatan kapital u automatizaciju procesa razvoja softvera. Pomenuti trokovi za automatizaciju i alat za produktivnost se ee posmatra kao projektni troak nego vanija investicija. Bez jednog automatski razvijenog procesa, broj iteracija koje zahtevaju isporuku softvera mogu znaajno da kasne sa datumima isporuke. Dodatno, kada je softver spreman za razvoj, nedostatak razvijenog alata za automatizaciju softvera oteava kontinualnu modernizaciju svih korisnikih raunara sa novim verzijama softvera.

3.2.3. Jedinstveni proces razvoja ( Unified Process UP )

Osnovni model koji se koristi za analizu, projektovanje i implementaciju aplikacije preduzea je jedinstveni proces razvoja softvera (Unified Process UP). Zahteva ekstenzivnu upotrebu jedinstveni jezik za modelovanje (UML) i korienje: Sluajeva korienja Centrine arhitekture Iterativni proces razvoja Inkrementalni proces razvoja

Aktivno upravljanje rizikom Objektno orijentisan i vieslojni pristup projektovanju Razvoj uzora, objekata i koda.

WORKFLOW

#1

#2

#n

#n+1

#n+2

#m

#m+1

Sl.7. Jedinstven proces razvoja (Unifed Process)

3.2.3.1.

Workflow jedinstvenog procesa razvoja

Jedinstveni proces razvoja softvera (Unified Process) se sastoji iz pet radnih tokova koji se kontinualno izvravaju tokom etiri faze razvojnog procesa i tako sve dok se aplikacija ne kompletira. Svaki korak od pet radnih tokova se naziva iteracijom, a svaka iteracija se zavrava sa unapred postavljenim ciljem za datu iteraciju. Kljuni tokovi su:

1. 2.

Zahtevi sakupljanje poslova, aplikacija i tehnikih zahteva Analiza obezbeuje poslovno i aplikaciono modeliranje dobijeno iz zahteva

3. 4. 5.

Projektovanje koristi objektno-orijentisane tehnike projektovanja za kompletiranje aplikacije Implementacija predstavlja izvrenje projektovanog posla ukljuujui prototipove Testiranje verifikuje da je posao dobro obavljen.

Sledea iteracija zapoinje krug sa novim zahtevima.

1. Zahtevi Osnovna svrha zahteva radnog toka je voenje iteracije prema razvoju ispravnih aplikacija za naruioca i korisnike. Podcilj je opis aplikacije sa dovoljno detalja i uspostavljanje dogovora izmeu naruioca, korisnika i razvojnog tima o tome ta aplikacija treba da obezbedi.

Projektni tim skuplja informacije, pravi listu zahteva. Zahtevi mogu da budu struktuirani sa kratkim nazivom, opisom, statusom, procenjenim trokovima implementacije, prioritetima i nivoima rizika. Sadraj aplikacije je takoe deo ovog radnog toka. Tim moe da isporui skup dizajniranih korisnikih interfejsa ili prototipova koji predstavljaju osnovnu interakciju sa korisnicima. Zahtevi radnih tokova moemo definisati kao: poslovni model za postavljenje sadraja sistema sluajevi korienja koji obuhvataju funkcionalne i nefunkcionalne zahteve koji su specifini za svaki od sluaja korienja skup korisnikih interfejsa za nacrte i prototipove za svaku ulogu specifikacija zahteva koji su generiki i ne odnose se na pojedinane sluajeve korienja.

2. Analiza Zahtevi aplikacije su ispitani i opisani dijagramima sluajeva korienja (use-case diagram). Analiza je jedan meukorak koji slui kao apstrakcija zahteva i vodi projektovanje aplikacije. Analizu moemo opisati sledeim:

precizna specifikacija zahteva, ukljuujui model sluajeva korienja model analize struktuira zahteve, tei njihovom ostvarenju, menja ih i odrava analiza je prvi korak projektovanja.

Analiza se zavrava kada se dobije celovit arhitekturni pogled na: Analizu klasa krajnje klase, klase entiteta i klase kontrola. Krajnje klase su smetene izmeu korisnika i rada aplikacija i esto su kandidati za sloj prezentacije ili sloj korisnikih servisa. Klase entiteta opisuju rok i postajanost informacija. Klase kontrola opisuju ponaanje aplikacija koja je sekvencijalna, transakciono orijentisana i sadri velik broj kontrola ukljuujui ih sa krajnjim klasama i klasama entiteta. Sluajevi korienja slue za opis ponaanja, odnosno za definisanje funkcija sistema s take gledita korisnika sistema, bez razmatranja interne strukture sistema. Odnosi se samo na onaj sistem koji se modelira. On predstavlja skup sekvenci akcija koje se izvravaju u okviru sitema, a rezultati njihovog izvravanja su znaajne za korisnika. Paketi kao izlaz iz faze analize slue za prikaz organizacije i analizu klasa, realizacije sluajeva korienja. Predstavljaju grupisanje funkcionalnih zahteva koji su opisani pomou sluajeva korienja.

3. Projektovanje Nakon procesa analize aplikacije projektovanje na niem nivou zapoinje. Klase su projektovane i njihova ponaanja su dodeljena nekom od sledea etiri nivoa: standardni korisniki interfejs (sloj prezentacije); sloju poslovne logike; sloju za pristup podacima, sloju podataka. Projektovanje se sastoji iz sledeih aktivnosti:

definisanje strukture u podsistemima; distribucija podsistema na nivoe; definisanje klasa i interfejsa; mapiranje aktivnih klasa u razvojne vorove.

Ovim aktivnostima aplikaciona arhitektura je kompletirana. Projektovani model bi trebalo da je primenjiv kroz ceo ivotni ciklus aplikacije. Projektovane klase su potpuno opisane ukljuujui njihova stanja, osobine i metode kao i povezanost sa drugim klasama.

4. Implementacija

Jedinstven proces je baziran na spiralnom modelu i inkrementaciji prototipa. Implementacija predstavlja ostvarenje faze projektovanja. Tu bi trebalo da se ostvari odnos 1:1 izmeu projektovanih klasa i koda koji je razvijen tokom implementacije.

Koraci za fazu implementacije su:

implementacija prototipova; implementacija komponenti (klasa i objekata); jedinica testiranja komponenti; integracija komponenti; izgradnja aplikacija; testiranje sluajeva korienja; evaluacija arhitekture; planiranje sledee izgradnje aplikacije; iterativni razvoj.

5. Testiranje Testiranje verifikuje oekivane rezultate u odnosu na tekue dobijene rezultate. Testiranje se obavlja u toku svih koraka bez obzira da li je iteracija na poetku, u sredini ili treba da se pusti u rad. Test sluajevi odreuju pojedinano validaciju aplikacije, ukljuujui zahtevane ulaze i oekivane izlaze. Test sluajevi se dobijaju iz sluajeva korienja. Ako se eli testirati cela aplikacija, drugi test sluaj bi trebalo da bude izveden da verifikuje instalaciju na odgovarajuoj platformi. Komponente testa mogu da budu razvijene da bi automatizovale izvoenje test sluaja.

3.2.3.2.

Faze jedinstvenog procesa razvoja

Svaka faza projekta je usmerena ka postizanju specifinih ciljeva: Faza prihvatanja je fokusiranje na poslovne dogaaje; Faza elaboracije je odgovorna za razvoj osnovne arhitekture; Faze konstrukcije se fokusira na kreiranje proizvoda sa postepenim inkrementiranjem karakteristika proizvoda; Faze tranzicije obezbeuju spremnost za eksploataciju proizvoda.

Postavljanje zahteva, analiza, projektovanje i implementacija predstavljaju glavne aktivnosti unutar faze prihvatanja i elaboracije. Kompletiranje svih faza opisuje aplikaciju sa svim potrebnim nivoima detaljnosti. Pomeranje iz jedne faze u drugu je postizanje cilja za svaku od faza. U svakoj prekretnici faze, kritina da/ne poslovna odluka se donosi u zavisnosti od toga da li projekat treba da se nastavi, u odnosu na budet delova projekta. FAZA 1. Prihvatanje

Faza prihvatanja ne prelazi dve iteracije i oslanja se na postavljane zahteve. Definisana je striktno sa svojim ciljevima ta proizvod treba da radi, smanjuje mogunost da se rizik projekta materijalizuje. etiri koraka se koriste za kreiranje poslovnog sistema: ograniiti obim predloenog sistema ovo je identifikacija aplikacionih granica i njenih relacija sa drugim sistemima; opisati kandidate arhitekture sadri detalje o novim, tekim ili rizinim delovima u razvoju aplikacije. identifikacija kritinih rizika pojednostavljuje identifikaciju rizika, menadment plan je kreiran za ublaavanje rizika u odgovarajuem timu; demonstracija aplikacioni prototip sa inicijalnim sluajem korienja.

FAZA 2. Elaboracija Faza elaboracije je ograniena sa dve ili tri iteracije. Primarni ciljevi ove faze su isporuka osnovne arhitekture aplikacije sa procenom trokova, rasporeda i planiranje faze konstrukcije. Osnovni koraci ove faze su sledei: kreiranje osnove arhitekture funkcionalnost i osobine koje su vane za naruioce; identifikacija znaajnih rizika obraunski plan, trokovi; specifikacija kvalitetnih atributa pouzdanost, procenu defekata, i performanse; prihvatanje sluajeva korienja ukljuuje 80% funkcionalnih zahteva; pripremanje projektnih ponuda ovo obuhvata raspored, personalne zahteve i trokove unutar ogranienja koja su postavljena poslovnom praksom; FAZA 3. Izgradnja Faza izgradnje ima najdui vremenski period i zahteva najvee resurse, zahteve i ima najvei broj iteracija. Fokusirana je na kreiranju aplikacije. Njen primarni cilj je kompletiranje aplikacije i obezbeenje poetka tranzicije prema kupcima. Aktivnosti faze izgradnje ukljuuju sledee: proirivanje sluajeva korienja ukljuuje identifikaciju detalja, opisa za sve sluajeve korienja; zavravanje prva tri radna toka analiza, projektovanja i implementacija; poetak testiranja oko 15% testiranja radnog toka treba da se zavri; podravanje integriteta arhitekture izmene i modernizacija bi trebalo da budu iznesene kao potrebe, ali unutar konteksta arhitekture aplikacije; upravljanje rizikom nastavak upravljanja rizikom identifikovanog u ranim fazama;

FAZA 4. Tranzicija

Faza tranzicije je obeleena inicijalnom beta aplikacijom za kupce. Dva primarna cilja ove faze su da obezbedi proizvod za realizaciju i da obui korisnike kako da ga koriste. Aktivnosti faze tranzicije ukljuuje sledee: pripremu za razvoj savetovanje kupaca o neophodnim modernizacijama; priprema dokumentacije uputstva za korisnike i druge prirunike koji e pratiti proizvod nakon njegovog zavretka; usaglaavanje aplikacije proizvod mora da bude pripremljen za proizvodno okruenje; ispravljanje greaka sve greke koje su naene moraju da budu adresirane; izmene aplikacije softver moe da zahteva modifikacije koje su bile nepredvidljive u ranijim fazama procesa.

3.2.3.3.

Iteracije jedinstvenog procesa razvoja

Kao to se razvoj softvera nastavlja kroz njegove faze, svaka iteracija radnog toka pribliava softver finalnoj verziji. Iteracije se nastavljaju unutar odreene faze sve dok se cilj ne postigne. Slika 5.3 pokazuje koje su iteracije neophodne za izvravanje svakog radnog toka u ivotnom ciklusu softvera. Ivar Jacobson zabeleio da su vane konsenkvence jedinstvenog procesa razvoja: da kreira sluajeve korienja koji odgovaraju poslovnim potrebama u fazi prihvatanja; da kreira poslovne zahteve na kraju faze elaboracije; organizacija mora da zna ta je ugovoreno za izgradnju (osnova arhitekture plus zahtevi) i da bude sigurna da ne sadri skrivene rizike; minimizira trokove, defekte i marketinko vreme; izbegava zastoj u isporuci softvera slabog kvaliteta i prekoraenja trokova; izbegava izgradnju softvera koji se isporuuje van datuma isporuke.

3.2.4. V model
V model (nemako Ministarstvo odbrane, 1992.) je modifikovani kaskadni model koji pokazuje odnos testiranja i faza analize i projektovanja, inei eksplicitnim neke povratne sprege koje su skrivene u kaskadnom modelu. V model sugerie da testiranje delova i testiranje pri integraciji mogu da se koriste za verifikovanje projektovanog programa. Tokom testiranja delova i testiranja pri integrisanju programeri i lanovi tima za testiranje treba da se osiguraju da su svi aspekti projektovanja ispravno implementirani u kodu. Slino tome, testiranje sistema treba da verifikuje projektovani sistem, uz potvrdu da su svi aspekti ispravno implementirani.

Sl.8. V model Kao to se moe videti sa slike, veze leve strane sa desnom stranom u slopu V modela ukazuju da, ako se pronau problemi tokom verifikacije i validacije, tada se aktivnosti sa leve strane V modela mogu ponoviti radi popravke i poboljanja zahteva, izgleda ili koda, pre nego to se koraci testiranja definisani na desnoj strani, ponovo izvre. V model ini eksplicitnijim neke iteracije i

prepravke koje su sakrivene u modelu vodopada. U sreditu panje modela vodopada esto su dokumenti i artifakti, dok se V-model usredsreuje na aktivnosti i ispravan rad sistema. V model se prvenstveno bavi aktivnostima i ispravnim radom sistema, za razliku od kaskadnog modela koji je usredsreen na dokumente i meuproizvode.

Osobine V modela: Testiranje delova, testiranje sistema pri integraciji i testiranje sistema utvruju ispravnost

programa i mogu se koristiti za verifikovanjeprojekta programa. Zavrni test slui za validacijuzahteva, tj. proveru da li su svi zahtevi potpuno implementirani. Ako se pronau problemi tokom verifikacije ili validacije, aktivnosti sa leve strane V modela mogu se ponoviti radi popravke i poboljanjazahteva, izgleda ili koda, pre nego to se ponove testiranja na desnoj strani modela.

Prednosti modela: Naredna faza poinje tek kada se predhodna faza zavri, Aktivnosti planiranja testiranja i kreiranje testovase izvrava pre kodiranja, Greke koje su nastale u predhodnim fazama bie otklonjene u tekuoj fazi.

Nedostaci modela: Model je vrlo krut u pogledu izmena. Svaka promena u projektovanju povlai promene u dokumentaciji i test dokumentaciji (odnosno promene samog testa). Moe se implementirati samo u velikim preduzeima. Potrebno je mnogo sredstava za primenu i odravanjeovog modela.

3.2.5. Inkrementalni model

U ovom modelu (slika 9) razvoja se prvobitno potpuno razvija inicijalni podskup funkcija softvera,a zatim se sukcesivnim koracima razvijaju,kao nadgradnja prethodnog koraka, stalno novije i komplikovanije verzije.

Sl.9. Inkrementacija Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu.

Sl.10. Iteracija Projektovanje softvera se izvodi u prvom koraku, ali se uvoenje softvera odvija sukcesivnom razradom (usavravanjem inicijalnog podskupa). Softver se razvija malim dodacima (inkrementima) kojima se moe jednostavno i lako upravljati. Svaki inkrement dodaje postojeem softveru pojedine nove funkcije, pri emu se postojee zadravaju Inkrementalni razvoj podrazumeva da se sistem u skladu sa specifikacijom zahteva deli na podsisteme prema funkcijama. Verzije se definiu kao funkcionalni podsistemi, tako da se svakoj novoj verziji prikljuuju nove funkcije. Sistem se nadograuje do potpune funkcionalnosti. Prednost ovakvog razvoja je u tome da se dodaci odnosno nove funkcije lake razumeju i testiraju. Korienje mogunosti da se stalno dodaju nove funkcionalnosti softverskom proizvodu, daje mogunost ugradnje bogatog korisnikog iskustva u redefinisani proizvod na manje skup nain. Ovaj model predstavlja kombinaciju klasinog modela ivotnog ciklusa softvera sa iterativnim mogunostima razvoja. On takoe obezbeuje nain da se periodino distribuira auriranje i odravanje softvera razliitim korisnicima. Posebno je popularan i koriste ga u softverskim kuama.

3.2.6. Model prototipskog razvoja

Ovaj model se koristi da bi se za potrebe korisnika razvio inicijalni model budeeg softvera koji simulira njegove stvarne funkcije sa ciljem da korisnik da svoje miljenje i odlui koji i kakvi su njegovi zahtevi. Kod razvoja softvera po ovom modelu korisnik ve u najranijem stadijumu moe videti na koji e se nain zadovoljiti njegovi zahtevi. Komponente razvijenog softvera esto predstavljaju samo korisniki interfejs. Implementacija kostura ovog interfejsa je sa eljom da se obezbedi mogunost za povratnu spregu od korisnika, pre nego to se specifira i projektuje konana verzija reenja. Mada je razjanjenje korisnikog interfejsa jedan od ciljeva, prototip moe biti takoe iskorien kao koncept unutar konteksta drugog modela. U tom sluaju,drugi model moe posmatrati prototip kao jedan elemenat procesa, koji se koristi u razjanjenju ponaanja sistema u razliitim takama razvoja softvera. Model obino prihvata neku vrstu funkcionalne specifikacije softvera kao ulaz, koji se simulira, analizira i izvrava. Ova tehnologija omoguuje da aktivnosti projektovanja softvera budu inicijalno preskoene ili premotene. Takoe, omoguuje da se brzo izgrade primitivne verzije softvera, koje kasnije korisnik moe i sam razvijati. Korisniki razvoj je ukljuen u povratnu spregu za redefinisanje sistemskih specifikacija i dizajna. U zavisnosti od tehnologije prototipskog razvoja, ceo radni sistem moe biti razvijen kontinuiranim procesom obezbeuje radne verzije sistema koje razvija i to u veoj meri od drugih modela angauje korisnika na razvoju, te unapreuje kvalitet procesa.

Sl.11. Model prototipskog razvoja Model prototipskog razvoja (slika 11.) se najee upotrebljava i daje dobre rezultate u sledeim situacijama:

1) kada su od strane korisnika samo uopteno definisani ciljevi razvoja softverskog proizvoda,ali ne i detalji u pogledu ulaza,procedura i izlaza, 2) kada je mogue simulirati rad softvera da bi korisnik mogao videti kako e budui softverski proizvod funkcionisati i 3) kada same razvojne organizacije ele da provere efikasnost algoritama ili adaptilnost sistema. Model se uglavnom moe sastojati od tri oblika: 1) prototip u obliku papira koji opisuje vezu oveka i maine na nain da korisniku omogui razumevanje tog odnosa,vezu 2) radni prototip koji implementira neke od funkcija postavljenih kao zahtevi softverskom proizvodu ili 3) realni program koji izvrava deo ili celinu zahtevanih funkcija.

Model prototipskog razvoja zapoinje prikupljanjem zahteva. Projektant i korisnik, zajedniki definiu opte ciljeve razvoja softverskog proizvoda, identifikuju sve njima poznate zahteve i odreuju podruja na kojima su obavezne dalje aktivnosti preciznijeg definisanja. Sledi "brzi" dizajn u kome se fokusira na realizaciju onih aspekata softvera koji e biti vidljivi za korisnika (ulazni i izlazni formati i dr.). Nakon takvog dizajna, razvija se prototip. On slui da bi se preistili zahtevi prema softveru koji se razvija. Preiavanje je iterativno i odvija se dok prototip ne zadovolji zahteve korisnika i istovremeno omogui projektantu potpuno razumevanje potreba koje mora zadovoljiti. Idealno , prototipski razvoj i slui kao mehanizam za identifikovanje zahteva prema softveru. Ukoliko se razvija radni prototip, korisniku se omoguuje da koristi delove softvera ili primenjuje alate koji brzo generiu radne verzije softvera. Evo nekih od nedostataka gde primena modela prototipskog razvoja moe biti diskutabilna: 1) Korisnik uoava radnu verziju softvera neznajui na koji su nain delovi softvera meusobno povezani,neznajui da u brzini realizacije nisu razmatrani aspekti kvaliteta ili odravanja u duem vremenskom periodu. 2) Kada doe do informacija da je potrebno izvriti "remont" ili dalju dogradnju jo ne uvedenog softverskog proizvoda, korisnik se osea prevarenim i insistira da se putem

izvesnih intervencija brzo realizuje njemu potreban proizvod. Upravljanje razvojem softvera u ovakvim situacijama postaje nekontrolisano. 3) Projektant esto ini kompromise u implementaciji sa ciljem da izgraeni prototip to pre stavi u funkciju. 4) Neadekvatan operativni sistem ili programski jezik se jednostavno upotrebljavaju samo zato to su raspoloivi ili poznati; neefikasan algoritam se primenjuje samo da bi se demonstrirala sposobnost softvera. 5) Nakon izvesnog vremena, zaboravlja se na nain odabiranja i njihove uzroke, pa manje idealna reenja ili bolje reeno manje kvalitetna reenja ostaju integralni deo konanog softverskog reenja. Veoma je znaajno da se projektant i korisnik, u cilju efikasnosti ovog modela dogovore i definiu pravila igre na poetku procesa razvoja softvera. Drugim reima moraju se sloiti da se prototip razvija kao mehanizam za definisanje zahteva,a softver se razvija u cilju zadovoljenja kriterijuma kvaliteta i mogunosti odravanja.

3.2.7. Model zasnovan na komponentama

Osnovni pristup ovog modela je kako konfigurisati i specijalizovati ve postojee komponente softvera u novi aplikativni sistem.Osobine komponenti zavise od njihove veliine, kompleksnosti i funkcionalnih mogunosti. Veina pristupa pokuava da iskoristi sline komponente obzirom na zajednike strukture podataka sa algoritmima za njihovu manipulaciju. Drugi pristupi pokuavaju da iskoriste komponente funkcionalno slinih kompletnih sistema ili podsistema kao to su npr. korisniki interfejs. Viestruko korienje softvera je proces ukljuivanja u novi proizvod pojedinih komponenti: 1) prethodno testiranog koda, 2) prethodno proverenog dizajna, 3) pretnodno razvijene i koriene specifikacije zahteva i 4) prethodno korienih procedura za testiranje. Koristi koje sa sobom donosi ponovno korienje komponenti razvijenog softvera su sledee: 1) podie robusnost softvera, 2) poveava produktivnost izrade softvera, 3) poveava kvalitet softvera,

4) smanjuje trokove razvoja softvera, 5) tedi,odnosno skrauje vreme izrade, 6) zadovoljava ciljeve softverskog inenjeringa, 7) iri korienje softvera, 8) obezbeuje adekvatnu dokumentaciju, 9) olakava odravanje softvera, 10) modelira sistem za lake razumevanje i dr.

3.2.8. Model unificiranog procesa razvoja

U odnosu na prethodno opisane modele razvoja softvera, Ivan Jacobson, Grady Booch i James Rumbaugh su 1999.godine objavili USDP model unificiranog procesa razvoja softvera.

Sl.12. Model unificiranog procesa Ovaj model opisuje process razvoja korienjem UML objedinjenog jezika za modelovanje u objektno orijentisanom razvoju softvera. Model unificiranog procesa razvoja zasniva se na 3 osnovna principa osnovu ine dijagrami sluajeva korienja, u centru modela nalazi se njegova arhitektura koja sazreva sa razvojem novih dijagrama korisnika i razvija se kroz iteracije koje

donose nove inkremente konanog proizvoda. Ako posmatramo sutinski u svakoj od iteracija odvijaju se analiza,projektovanje,implementacija i testiranje proizvoda. Prema autorima, model se moe opisati kao process klasificiranja iteracija,koje se mogu podeliti u 4 grupe: 1) u prvoj grupi se nalaze poetne iteracije interakcija sa stekholderima, tj. znaajnim uesnicima u razvoju softvera, 2) drugu grupu sainjavaju razraene iteracije elja i potreba korisnika, 3) iteracije konstruisanja inicijalnih operacionih mogunosti sainjavaju treu grupu i 4) prelazne iteracije kompletiranja proizvoda su etvrta, konana iteracija razvoja softvera prema ovom modelu. Iterativni razvoj takoe podrazumeva podelu sistema na podsisteme prema funkcijama, ali se potpun sistem isporuuje u svim verzijama, s tim to se u svakoj novoj verziji menjaju funkcije svakog podsistema. Svaka sledea verzija unapreuje prethodnu.

4. Tehnike testiranja softvera

Jedan od ciljeva testiranja je otkrivanje koliki je potencijal greaka mogu, i mnoge tehnike su razvijene na osnovu ovoga, tehnike koje pokuavaju da slome program, izvravanjem jednog ili vie testova izvedenog iz identifikovanih klasa ekvivalenta egzekucija. Vodei princip ovih tehnika je da budu to sistematinije u identifikaciji reprezentativnog skupa programskog ponaanja; na primer, posmatranje podklasa oblasti ulaza, scenario, stanja i toka podataka. Teko je nai homogenu bazu za klasifikaciju svih tehnika, i ona koja je ovde data mora se smatrati za

kompromisnu. Klasifikacija je bazirana na tome kako su testovi generisani iz intuicije i iskustva softverskih inenjera, kao i specifikacije, strukture koda, (realne ili vetake) greke koje bi trebalo nai, prirode aplikacije. Ponekad su ove tehnike klasifikovane kao bele-kutije (white-box, ili glassbox), ako se test oslanja na informacije kako je softver dizajniran ili kakvi su kodovi, ili crnekutije (black-box) ukoliko se sluajevi testiranja oslanjaju samo na ulaz/izlaz ponaanje. Poslednja kategorija odnosi se na kombinovanu upotrebu dve ili vie tehnika. Oigledno, ove tehnike se ne koriste podjednako esto.Ukljuene su u listu one koje bi inenjer trebalo da zna.

4.1.

Bazirane na intuiciji i iskustvu softverskih inenjera

4.1.1. Ad hoc testiranje

Verovatno najrasprostranjenija tehnika ostaje ad hoc testiranje: testovi se izvode oslanjajui se na inenjersko umee, intuiciju, i iskustvo sa slinim programima. Ad hoc testiranje moe biti korisno za identifikaciju specijalnih testova, onih koje nije lako zabeleiti formalizovanim tehnikama.

4.1.2. Istraivako testiranje (Explorarity testing)

Ovo testiranje je definisano kao simultano uenje, dizajn testa i izvravanje testa; odnosno, testovi nisu odreeni unapred u okviru utvrenog plana testa, ve su dinamiki dizajnirani, izvreni i modifikovani. Efektivnost ovih testova oslanja se na znanje inenjera, koje se moe izvesti iz mnogo izvora: posmatranog ponaanja proizvoda tokom testiranja, upoznatosti sa aplikacijom, platformom, procesom neuspeha, tipom moguih greaka i mana, rizika povezanog sa posebnim proizvodom i slino.

4.2.

Tehnike bazirane na specifikaciji

4.2.1. Ekvivalentno deljenje (Equivalence partitioning)

Domen ulaza je podeljen na kolekciju podskupova, ili ekvivalentnih klasa, koje se smatraju ekvivalentima prema odreenim relacijama, i reprezentativan skup testova (ponekad samo jedan) je uzet iz svake klase.

4.2.2. Analize vrednosti granica (Boundary-value analysis)

Sluajevi testa izabrani su na ili blizu granica oblasti ulaza promenljivih, sa obrazloenjem kao osnovom da mnoge greke imaju tendenciju da se koncentriu blizu ekstremnih vrednosti ulaza. Proirenje ove tehnike su testiranja robustnosti, gde su sluajevi testa takoe izabrani izvan ulazne oblasti promenljivih, kako bi se testirala robustnost programa prema neoekivanim ili pogrenim ulazima.

4.2.3. Tabela odluka (Decision table)

Tabele odluka predstavljaju logike veze izmeu uslova (grubo reeno, ulaza) i akcija (grubo, izlaza).Sluajevi testa su sistematino dobijeni razmatranjem svake mogue kombinacije uslova i akcija. Tehnika povezana sa ovom je grafiko predstavljanje uzrok-efekat.

4.2.4. Konanog stanja bazirane na maini (Finite-state machine-based)

Modeliranjem programa kao maine konanih stanja, testovi se mogu odabrati sa ciljem da se pokriju stanja i tranzicije na njima.

4.2.5. Testiranje

iz

formalnih

specifikacija

(Testing

from

formal

specifications)
Davanje specifikacije u formalnom jeziku omoguava automatsku derivaciju funkcionalnih sluajeva testa i istovremeno, obezbeuje referentni izlaz, oracle, za proveru rezultata testa. Metode postoje i za dobijanje sluajeva testa iz onih baziranih na modelu ili algebarskih specifikacija.

4.2.6. Sluajno testiranje (Random testing)

Testovi su generisani samo sluajno, ali ih ne bi trebalo meati sa statistikim testovima iz operacionog profila kao to je opisano u podtemi 3.5.1 Operativni profil. Ovaj vid testiranja pada pod naslov ulaza zasnovanih na specifikaciji jer bar oblast ulaza mora biti poznata kako bismo mogli da uzimamo sluajne take unutar nje.

4.3.

Tehnike bazirane na kodu (Code-based)

4.3.1. Kriterijum baziran na kontrolnom protoku (Control-flow-based criteria)

Ovi kriterijumi su usmereni za pokrivanje svih naredbi ili blokova naredbi u programu, ili njihovih posebnih kombinacija. Nekoliko kriterijuma je predloeno kao pokrivanje uslov/odluka. Najjai od kriterijuma baziranih na kontrolnom toku je testiranje puta (path testing), koje ima za cilj izvravanje svih od-ulaska-do-izlaska putanja kontrolnog toka u grafikonu toka. Zato to testiranje putanje generalno nije izvodljivo zbog petlji, drugi manje strogi kriterijumi koriste se u praksi, kao to je testiranje izjava, testiranje grana, i testiranje uslov/odluka. Adekvatnost takvih testova meri se

procentima; na primer, kada su sve grane izvrene makar jednom u testu, 100% pokrivenosti grana se kae da je postignuto.

4.3.2. Kriterijum baziran na toku podataka (Data flow-based criteria)

U ovakvom testiranju, kontrolni grafik toka belei se sa informacijama o tome kako su promenljive u programu definisane, koriene, i ubijene (nedefinisane). Najjai kriterijum, sve definicije koriste puteve, zahteva da se za svaku promenljivu, svaki segment putanje kontrolnog toka iz definicije te promenljive koristi dok se izvrava. Kako bi se smanjio broj potrebnih putanja, slabije strategije kao svih definicija (all-definitions) i svih upotreba (all-uses) se koriste.

4.3.3. Referentni modeli za testiranje bazirano na kodu (flowgraph, call graph)

Iako sama po sebi nije tehnika, kontrolna struktura programa grafiki se prikazuje korienjem grafa tokova u tehnikama testiranja baziranim na kodu. Graf tokova je usmereni graf od kojeg vorovi i lukovi odgovaraju programskim elementima. Na primer, vorovi mogu predstavljati naredbe ili neometane sekvence naredbi, i lukovi transfer kontrole izmeu vorova.

4.4.

Tehnike bazirane na defektima (Fault-based techniques)

Sa razliitim nivoima formalizacije, ove tehnike testiranja smiljaju sluajeve za testiranja posebno namenjene za otkrivanje kategorija verovatno ili unapred definisanih defekata.

4.4.1. Pogaanje greaka (Error guessing)

U pogaanju greaka, sluajevi za testiranje su posebno dizajnirani od strane softverskih inenjera koji su pokuavali da otkriju najprihvatljivije greke datog programa. Dobar izvor informacija je istorija greaka otkrivenih u ranijim projektima, kao i inenjerska ekspertiza.

4.4.2. Testiranje mutacija (Mutation tetsing)

Ovo je blago izmenjena verzija programa pod testom, razlikujui se malom, sintaksikom promenom.Ukoliko je sluaj testiranja uspean u utvrivanju razlike izmeu programa i mutanta, drugi se ubija.Originalno je osnovana kao tehnika evaluacije skupa testiranja. Mutaciono testiranje je samo po sebi kriterijum testiranja: ili su testovi sluajno generisani dok se dovoljan broj mutacija ne ubije, ili su testovi posebno dizajnirani da ubiju preivele mutacije. U drugom sluaju testiranje

mutacija moe se kategorisati kao tehnika bazirana na kodu. Osnovna pretpostavka testiranja mutacija, efekat zdruivanja, je ta da se traenjem jednostavnih sintaksikih greaka nalaze kompleksnije ali realni defekti. Kako bi tehnika bila efektivna, na sistematian nain se mora automatski proizvesti veliki broj mutanta.

4.5.

Tehnike bazirane na upotrebi (Usage-based)

4.5.1. Operativni profil (Operational profile)

U testiranju procene pouzdanosti okruenje testa mora reprodukovati operativno okruenje softvera to je blie mogue.Ideja je da se iz posmatranih rezultata testa zakljuuje budua pouzdanost softvera kada je u pravoj upotrebi. Kako bi se to uradilo, ulazima se dodeljuje raspodela verovatnoe, ili profil, prema njihovom pojavljivanju u stvarnim operacijama.

4.5.2. Testiranje projektovano na pouzdanosti softvera (Software Reliability Engineered Testing)

Testiranje projektovano na pouzdanosti softvera (SRET) je metoda testiranja koja obuhvata itav proces razvoja, gde je testiranje dizajnirano i voeno ciljevima pouzdanosti i oekivanim relativnim korienjem i kritinostima razliitih funkcija u oblasti.

4.6.

Tehnike bazirane na prirodi aplikacije

Ove tehnike se odnose na sve tipove softvera. Ipak, za neke vrste aplikacija, potreban je dodatni know-how za izvoenje testa. Lista nekoliko specijalizovanih oblasti testiranja data ovde, bazirana na prirodi aplikacije : Testiranje bazirano na objektu (Object-oriented testing) Testiranje bazirano na

komponentama (Component-based testing) Web-bazirano testiranje (Web-based testing) GUI testiranje Testiranje konkurentnih programa Testiranje usaglaenosti protokola Testiranje sistema realnog vremena

Testiranje bezbednosno-kritinih sistema (IEEE1228-94)

4.7.

Selekcija i kombinovanje tehnika

4.7.1. Funkcionalne i strukturne

Tehnike testiranja bazirane na specifikaciji i kodu esto su kontrastne kao funkcionalno nasuprot strukturnom testiranju. Ova dva pristupa odabiru testa ne treba posmatrati kao alternativne ve komplementarne; zapravo, one koriste razliite izvore informacija i dokazano je da daju akcenat na razliite vrste problema. Mogu se koristiti u kombinaciji, u zavisnosti od budeta.

4.7.2. Deterministike nasuprot sluajnim

Sluajevi testa se mogu izabrati na deterministiki nain, prema raznim tehnikama koje su nabrojene, ili sluajno iz nekih raspodela ulaza, kao to se obino radi u testiranju pouzdanosti. Nekoliko analitikih i empirijskih poreenja je sprovedeno kako bi se analizirali uslovi koji ine da je jedan pristup efektivniji od drugog.

5. Tehnike testiranja dizajna

Tehnika crne kutije Tehnika bele kutije

5.1.

Tehnika crne kutije

Pristup crne kutije je metoda testiranja u kojoj se dolazi do testnih podataka na

temelju specificiranih funkcijskih zahteva, ne uzimajui u obzir konanu strukturu programa. Ovo testiranje naziva se jo i testiranje upravljano podacima (engl. data driven), ulazno/izlazno testiranje (engl. input/output driven) ili testiranje zasnovano na zahtevima (engl. requirements based). Kako se kod testiranja uzima u razmatranje samo funkcionalnost programskih modula, ovo testiranje se uglavnom odnosi na metode testiranja kod kojih je naglaeno izvravanje funkcija, kao i objanjavanje njihovih ulaznih i izlaznih podataka. Kod testiranja, program se tretira kao crna kutija nepoznata sadraja kod koje su vidljivi samo ulazi i izlazi, a funkcionalnost je odreena posmatranjem dobijenih izlaznih podataka na temelju odgovarajuih poznatih ulaza. Prilikom testiranja, na osnovu razliitih ulaznih

podataka dobijeni izlazni podaci se usporeuju s unapred oekivanima te se na taj nain vri vrednovanje ispravnosti programa. Svi testovi proizlaze iz specifikacije programa pri emu se ne vri nikakvo razmatranje programskog koda. Detaljno testiranje kombinacija razliitih ulaznih podataka za veinu programa je neizvodljivo, ak i ako se posmatra ispravnost samo ulaznih podataka kroz najosnovnije injenice, kao to su ispravnost unesenih vrednosti, vreme unosa, redosled unosa, itd. Mnogo razliitih kombinacija koje mogu nastupiti kod ulaznih podataka glavna je prepreka u funkcijskom testiranju. Dodatnu potekou unosi nekompletnost ili neispravnost datih specifikacija programa. Do pojave razliitih dvosmislenosti dolazi zbog ogranienja jezika (najee prirodni jezik) koji se koristi za opis specifikacija. Iako se koristi odreeni tip formalnog ili restriktivnog jezika, jo se moe pogreiti i pri opisivanju svih moguih sluajeva. Ponekad, uzrok teko reivog problema je i sama specifikacija, jer korienjem formalnog ili restriktivnog jezika s ogranienim skupom rei najee nije mogue specificirati svaku situaciju koja se moe dogoditi. Takoe, i ljudi pri opisivanju retko znaju jasno specificirati to tano ele, nego toga postanu svesni kod ve zavrenog specificiranja. Problemi zbog neodgovarajueg specificiranja obuhvataju priblino 30% svih bug-ova u programima. Istraivanja koja se sprovode kod ove metode uglavnom su fokusirana na to kako postii maksimalnu efikasnost testiranja uz minimalne trokove, odnosno kako odrediti potreban broj testova. Nije mogue smanjiti broj ulaznih podataka, ali je mogue smanjiti broj testova koji se odnose na odreeni broj razliitih kombinacija ulaznih podataka koje mogu nastupiti. Jedna od tehnika koja se koristi je podela ulaznih podataka na skupine (domene). Ako se prostor ulaznih podataka podeli po skupinama i uz pretpostavku da su sve ulazne vrednosti u jednoj skupini ekvivalentne, dovoljno je izvriti testiranje samo za jednu reprezentativnu vrednost iz svake skupine da bi se zadovoljavajue pokrilo itav ulazni prostor. Posebno su zanimljive granine vrijednosti. Iskustva pokazuju da testovi koji otkrivaju granine zakone imaju viu cenu od onih koji to ne rade. Analiza graninih vrednosti zahtijeva da se jedna ili vie graninih vrednosti selektuje kao sluaj reprezentativnog testa. Tekoe koje mogu nastupiti kod primene ove tehnike su takve da neispravno definisane skupine u specifikaciji nije naknadno mogue efikasno otkriti. Da bi se primenila ova metoda i izvrila dobra podela na skupine, potrebno je dobro poznavanje strukture programske podrke. Iz tog razloga dobar plan testiranja nee sadravati samo ovu , nego i metodu bele kutije kao i kombinaciju obe metode.

5.1.1. Metode crne kutije

Kod ovog testiranja, program se tretira kao crna kutija nepoznatog sadraja kod koje su vidljivi samo ulazi i izlazi, a funkcionalnost je odreena promatranjem dobijenih izlaznih podataka na temelju odgovarajuih poznatih ulaza. Prilikom testiranja, na osnovu razliitih ulaznih podataka dobijeni izlazni podaci se uporeuju s unapred oekivanim te se na taj nain vri vrednovanje ispravnosti programa. Svi testovi proizlaze iz specifikacije programa pri emu se ne vri nikakvo razmatranje programskog koda. Oigledno je da e se, im se primeni vie moguih ulaznih podataka, pronai i vie neispravnosti te e se njihovim otklanjanjem poveati i pouzdanost kvaliteta programa. Detaljno testiranje kombinacija razliitih ulaznih podataka za veinu programa je neizvedivo, ak i ako se promatra ispravnost samo ulaznih podataka kroz najosnovnije injenice, kao to su ispravnost unesenih vrednosti, vreme unosa, redosled unosa, itd. Mnogo razliitih kombinacija koje mogu nastupiti kod ulaznih podataka glavna je prepreka u funkcijskom testiranju. Navedena su tri primera za metode Crne kutije:

Podela na klase ekvivalencije Analiza graninih vrednosti Testiranje zasnovano na tablici odluivanja

5.1.2. Podela na klase ekvivalencije

Klase ekvivalencije definiemo da bismo testirali program sa po jednom reprezentativnom vrednou ulaza iz svake klase ekvivalencije. U idealnom sluaju podskupovi su meusobno disjunktni i pokrivaju celi skup ulaza (relacija slinosti ulaza je relacija ekvivalencije). Klase ekvivalencije se odreuju tako to se razmatraju svi zakoni vezani za ulaze programa koji proizilaze iz specifikacije. Za svaki zakon se razmatraju dve grupe klasa prema zadovoljenosti zakona: legalne klase obuhvataju doputene situacije. nelegalne klase obuhvataju sve ostale situacije.

5.1.3. Analiza graninih vrijednosti

Posebnu panju treba obratiti na granicama klasa ekvivalencije! Veoma mnogo greaka se pojavljuje u granicama klasa ekvivalencije i iz tog razloga se koristi analiza graninih vrednosti. Analiza granine vrednosti pripada dizajnu test sluaja koji upotpunjuje ekvivalentnost participiranja. Analiza granine vrednosti se odreuje na osnovu sledeeg: Ako ulazni zakon specificira stanje okvirno u rasponu od vrednosti A do B, dobija se test sluajeve sa vrijednostima A i B, samo iznad i ispod A i B. Ako ulaz specifira stanje razliitih vrednosti, test sluajevi trebaju biti izraeni za vebu sa minimalnim i maksimalnim brojkama.

5.1.4. Uzrono - posledini grafovi

Testiranje softvera bi bilo znatno olakano kada bi se mogli automatski generirati test primeri iz zahteva. Stoga je potrebno analizirati zahteve i preformulisati ih u vidu logike relacije izmeu ulaza i izlaza. Rezultat se moe predstaviti u obliku takozvanog uzrono posledinog grafa. Uzrono posledini grafovi nisu primenjivi na sisteme koji poseduju vremenska ogranienja i na sisteme koji posjeduju konkurentne procese. Tabela odluivanja je dvodimenzionalno mapiranje uzroka na posledice. Moe se izvesti iz uzrono posledinog grafa. Tabela odluivanja ima po jedan red za svaki uzrok i posledicu. Redovi tabele odgovaraju test primerima. Kolone se definiu analiziranjem vorova posledica u uzrono posledinom grafu. Upotrebom tabele odluivanja broj test primjera se znaajno smanjuje.

5.2.

Tehnika bele kutije

Suprotno pristupu crne kutije, ovde se programska podrka pri testiranju posmatra

kao bela kutija, to znai da su prilikom testiranja poznati struktura i tok izvoenja pojedinih programskih modula. Plan testiranja se radi u skladu s detaljima implementacije programskog reenja kao to su programski jezik, logika programa, stil, itd. Pojedini testovi proizlaze iz same programske strukture. Ovaj pristup testiranju naziva se jo pristupom

staklene kutije (engl. glass-box), testiranje voeno logikom (engl. logic driven testing) ili testiranje zasnovano na dizajnu (engl. design-based testing). Razvijene su razliite tehnike koje se koriste pri ovom testiranju jer se kompleksnost problema smanjuje s poznavanjem i pozornim promatranjem strukture programa prilikom testiranja. Kod ove metode prisutna je namera detaljnog posmatranja nekih aspekata programske podrke kao to je: izvravanja svake linije programskog koda najmanje jednom (engl.statement coverage), prolaenje svakog skoka (engl. branch coverage), ili razotkrivanje svih moguih kombinacija ispravnih i neispravnih zakona (engl. multiple condition coverage). Testiranje kontrole toka naredbi, testiranje ponavljanja i testiranje toka podataka je testiranje kod kojeg se tok programske strukture posmatra kao graf. Pojedini testovi se paljivo selektuju u ovisnosti od kriterijuma, da se svi vorovi i veze izmeu njih pokriju ili obuhvate najmanje jednom. Na taj se nain moe otkriti nepoeljni mrtvi programski kod, kod koji nije u upotrebi ili se nikad nee izvravati, ali koji se ne moe otkriti funkcijskim testiranjem.

5.2.1. Metode bele kutije

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. Ovaj oblik testiranja se naziva i strukturno testiranje. Objasniemo sledee tehnike testiranja bele kutije: 1. 2. Pokrivanje iskaza (Statement coverage) Pokrivanje odluka (Decision coverage)

3. 4.

Pokrivanje zakona Metoda graninog testiranja

5.2.2. Pokrivanje iskaza (Statement coverage)

Svaki iskaz u programu se mora bar jednom izvriti, jer ne moemo znati da li u bilo kojem iskazu postoji greka ukoliko ga ne izvrimo bar jednom. Meutim, ne moemo garantirati da e se iskaz koji se ispravno izvravao za jednu ulaznu vrednost , isvravati ispravno i za neku drugu ulaznu vrednost, to je loa strana ove tehnike.

5.2.3. Pokrivanje odluka (Decision coverage)

Svaka od zakona grana se izvrava najmanje jednom. Ova metoda je jaa od metode pokrivanja iskaza jer pokrivanje odluka garantuje pokrivanje iskaza. Svaka izlazna grana mora biti izabrana bar jednom.

5.2.4. Pokrivanje zakona

Svaka elementarna komponenta sloenog zakonskog izraza uzima i tanu i netanu vrednost. Elementarni zakoni se posmatraju nezavisno jedan od drugog. Ova metoda ne garantuje pokrivanje svih odluka . Samim tim nije garantovano ni pokrivanje svih iskaza.

5.2.5. Metoda graninog testiranja unutranje putanje (boundary interior path testing)
Zahteva pokrivanje sledeih putanja u programu: izvravanje tela petlje 0 puta izvravanje tela petlje 1 put (granini test) ponavljanje tela petlje bar jednom (unutranji test)

Za svaki od prethodnih sluajeva potrebno je potpuno prekriti sve (otvorene) putanje u grafu.

6. Menadzment testiranja
Kvalitet e biti definisan kao sposobnost da se proizvede softver koji zadovoljava ili nadmauje postavljene zahteve (prema definisanim merljivim kriterijumima) i koji je proizveden definisanim procesom. Postizanje kvaliteta ne svodi se na jednostavno "zadovoljenje zahteva" ili izradu proizvoda koji zadovoljava korisnikove potrebe i oekivanja, nego se takoe moraju ukljuiti mere i kriterijumi koji demonstriraju postizanje kvaliteta i definisati proces koji e biti ponovljiv i upravljiv, i koji e obezbediti da proizvod tog procesa dostie postavljeni nivo kvaliteta. Naveemo i objasniti neke najee zablude u vezi kvaliteta softvera. Kvalitet moe biti naknadno dodat ili "utestiran". Kao to proizvod ne moe biti napravljen bez opisa ta treba da radi, ko treba da ga upotrebljava i na koji nain, itd, tako ni kvalitet ne moe biti postignut ako prethodno nije opisan, samerljiv i da predstavlja sastavni deo procesa kojim se stvara proizvod. Kvalitet dolazi sam od sebe. Kvalitet naravno ne nastaje tek tako. Da bi se postigao, mora se definisati, sprovoditi i kontrolisati odgovarajui proces razvoja. Svrha ovog dokumenta je da obezbedi disciplinovan pristup razvoju, sa definisanim zadacima i odgovornostima u cilju proizvodnje kvalitetnog softvera koji zadovoljava potrebe korisnika, unutar predvidivog plana i budeta. Kvalitet je jednodimenzionalna karakteristika i svakome znai istu stvar. Kvalitet nije jednodimenzionalna karakteristika. Meu vane dimenzije kvaliteta softvera spadaju: resursa stepen podrke mogunost testiranja, proirivanja, prilagoavanja, konfigurisanja, funkcionalnost u kojoj meri softver zadovoljava specifikacije i potrebe korisnika pouzdanost pokazatelji: frekvencija i teina otkaza, sposobnost oporavka, upotrebljivost meri se naporom koji zahteva uenje programa, njegovo korienje, efikasnost brzina odziva, raspoloivost, brzina oporavka, protok, iskorienje

predvidivost, tanost, srednje vreme izmeu otkaza,...

priprema ulaza i interpretacija izlaznih rezultata

instaliranja, lokalizacije.

Za svaku od ovih dimenzija kvaliteta mora se definisati i sprovesti odgovarajui tip testiranja.

6.1.

Tipovi testiranja 6.1.1. Inspekcije, recenzije i pregledi

Inspekcije, recenzije i pregledi su specifine tehnike fokusirane na ocenjivanje

artefakata (pogodno za dokumentaciju, programski kod) i efikasni su metodi poboljanja kvaliteta i produktivnosti razvojnog procesa. Sprovode se na sastancima gde jedan od prisutnih igra ulogu voditelja, a drugi zapisniara (belei zahteve za izmenama, probleme, pitanja itd). IEEE standardi opisuju ove tehnike na sledei nain: Recenzija (engl. review) Formalni sastanak na kome se artefakt, ili skup artefakata predstavlja korisniku ili muteriji ili drugim zainteresovanim stranama za komentare i odobrenje. Inspekcija (engl. inspection) Formalna tehnika procene kojom se artefakti detaljno pregledaju od strane osoba koje nisu autori da bi se uoile greke, naruavanje razvojnih pravila i drugi problemi. Pregledi (engl. walkthrough) Tehnika pregleda u kome autor upoznaje ostale lanove tima sa segmentom artefakta koji je on izradio. Ostali lanovi postavljaju pitanja i daju komenare o tehnici, stilu, moguim grekama, naruavanju razvojnih propozicija i drugim problemima. Jedinino testiranje (engl. unit testing) primenjuje se na pojedine klase, module ili komponente programskog koda. Tehnike jedininog testiranja dele se na tehnike crne kutije i tehnike bele kutije. Ovi metodi se obino kombinuju pri primeni. Integraciono testiranje primenjuje se na softverski sistem kao celinu. U testiranja vieg reda spadaju: testiranje sigurnosti (engl. security testing) da li su posmatrane funkcije dostupne testiranje koliine podataka (engl. volume testing) verifikovanje da li softver moe

onim i samo onim korisnicima kojima su namenjene obraditi veliku koliinu podataka

testiranje upotrebljivosti (engl. usability testing) ocenjuju se estetski aspekti, testiranje integriteta (engl. integrity testing) ocenjuje se robusnost (otpornost na test naprezanja (engl. stress testing) vrsta testa pouzdanosti sistema pod

konzistencija korisnikog interfejsa, korisnika dokumentacija i trenani materijal. otkaze), konzistentna upotreba resursa i slino. nenormalnim uslovima (ekstremna optereenja, nedovoljno memorije ili drugih resursa, servisi koji nisu raspoloivi itd). uporedni test (engl. benchmark testing) vrsta testa performansi koja uporeuje novi test zaguenja (engl. contention testing) proverava da li softver moe da zadovolji test optereenja (engl. load testing) vrsta testa performansi, kojim se procenjuju

nepoznati sistem sa poznatim referentnim sistemom viestruke zahteve razliitih aktera za istim resursom operativni limiti nepromenljivog sistema pod razliitim optereenjima, ili razliitih konfiguracija sistema pri istom optereenju. Merene veliine su najee protok i vreme odziva (srednja i vrna vrednost). test konfiguracije (engl. configuration testing) testira ponaanje softvera u test instalacije (engl. installation testing) testira instaliranje softvera na razliitim razliitim hardversko/softverskim okruenjima sistemima i u razliitim situacijama (npr. prekid napajanja ili nedovljno prostora na disku) Regresivno testiranje je vrsta testiranja u kome se na osnovu jednom razvijenog test primera vie puta sprovodi testiranje softvera (tipino posle neke izmene u softveru, da bi se utvrdilo da nije dolo do kvarenja funkcija softvera koje nisu obuhvaene izmenom).

6.2.

Organizacija procesa testiranja

Proces testiranja mora se odvijati tokom svih faza ivotnog ciklusa. Za proces

testiranja moraju biti realizovani standardizovani propisi i procedure koje definiu nain rada i aktivnosti test odeljenja kao i svih uesnika u razvoju. Sve aktivnosti lanova tima koji uestvuju u realizaciji procesa testiranja moraju dokumentovane. Definisanje aktivnosti mora da pokrije sledee: a. Odgovornosti i zaduenja za planiranje testa, izvrenje i evaluaciju se eksplicitno

moraju zadati.

b.

Ciljevi testa, tipovi testa koji e se primenti, kao i raspored i zaduenja kod testiranja Odgovarajui materijal (dokumenta, test primeri i drugo) se uvaju i nalaze se pod

moraju biti jasni i dokumentovani u Planu testiranja. c.

kontrolom repozitorijuma za upravljanje konfiguracijama (engl. Configuration Management, skraeno CM). d. Test materijal je podloan periodinim aktivnostima kontrole kvaliteta.

6.2.1. Zaduenja i odgovornosti

Nadalje u ovom odeljku dat je opis uloga koje se tiu procesa testiranja; nisu ukljuene uloge koje se tiu procesa razvoja. Menader kvaliteta odgovaran je za planiranje testa, kako dugorono (u okviru menadmenta projekta), tako i kratkorono.Vri kontrolu izvrenja, eventualne korekcije i evaluacije testiranja. Obezbeuje infromacije menadmentu projekta o rezultatima rada test grupe. Vri proveru korektnosti planova i rokove realizacije.Obezbeuje neophodni materijal lanovima zaduenim za razvoj i sprovoenje testiranja pre i nakon testiranja, izvetaje o testiranju, zbirne izvetaje o grekama, neophodnu dokumentaciju. lan tima za razvoj testova uestvuje u razvoju test primera (engl. test cases) i serije testova (test suites). lan tima za sprovoenje testiranja vri testiranje pojedinih modula ili celog softvera primenom testova iz Test specifikacije. alje izvetaje sa testiranja, prijavljuje otkaze. Menader zahteva za promenom procenjuje pojedinane i zbirne rezultate testova i na osnovu toga generie zahteve za promenama, dodeljuje im prioritete i planira ih po iteracijama.

6.2.2. Aktivnosti procesa testiranja

Uspean zavretak analize i prikupljanja zahteva, u kojoj su definisani svi funkcionalni zahtevi za proizvod u odgovarajuim dokumentima i modelima, jeste preduslov za poetak ne samo faze projektovanja, ve i za poetak faze testiranja. U narednim sekcijama dat je opis aktivnosti procesa testiranja proizvoda: planiranje, specifikacija, realizacija i evaluacija rezultata.

6.2.2.1.

Planiranje testa

Plan testiranja identifikuje zahteve za razliitim tipovima testiranja, daje procenu rizika i ustanovljava prioritete testiranja i definie strategiju testiranja (vrste testiranja, u kojoj fazi razvoja se sprovode, tehnike testiranja i kriterijume zavretka). Sledi opis pojedinih elemenata plana testiranja:

Identifikacija zahteva za testiranjem Zahtevi za testiranjem identifikuju ta e se testirati. Zahtevi za testiranjem funkcija, kao to im ime kae, izvedeni su iz opisa funkcija posmatranog softvera.Minimalno svaki sluaj upotrebe treba da proizvede bar jedan zahtev za testiranjem. Zahtevi za testiranjem performansi izvode se iz specifikacije performansi posmatranog softvera. Tipino su performanse izraene preko vremena odziva i potronje resursa pri raziitim reimima rada. Zahtevi za pouzdanou izvode se iz vie izvora, tipino iz nefunkcionalnih specifikacija softvera, vodia za dizajniranje korisnikog interfejsa, projektnih i implementacionih pravilnika.

Procena rizika Ustanovljavanje prioriteta testiranja poinje procenom rizika. Sluajevi korienja ili komponente koji predstavljaju najrizinije u pogledu otkaza ili imaju veliku verovatnou otkaza treba da budu meu prvim testiranim. Odreivanje operacionog profila Sledei korak u proceni rizika i ustanovljavanju prioriteta jeste da se odredi operacioni profil softvera koji se razmatra. Tipino, to je vei broj upotreba nekog sluaja upotrebe ili neke komponente od strane razliitih aktera, bie vei indikator operacionog profila.

Ustanovljavanje prioriteta testiranja Finalni korak u proceni rizika i upostavljanju prioriteta jeste da se identifikuju i opiu pojedini sluajevi korienja ili komponente upotrebom indikatora prioriteta kao to su: H mora se testirati M trebalo bi testirati, ali tek poto se obavi testiranje svih H celina L moda e se testirati, ali tek posle svih H i M celina

Strategija testiranja Strategija testiranja opisuje generalni pristup i ciljeve odreenih aktivnosti testiranja. Dobra strategija trebalo bi da sadri sledee elemente: tip testa koji e se sprovesti i cilj testiranja faza razvoja u kojoj e se testiranje primeniti tehnika testiranja mere i kriterijumi za procenu rezultata i zavretka testiranja bilo kakva dodatna razmatranja koja utiu na aktivnost testiranja

6.2.2.2.

Specifikacija testova

U ovoj fazi potrebno je identifikovati i opisati skup test primera dovoljnih za verifikaciju proizvoda i test procedura koje opisuju nain izvrenja test primera. Za realizaciju Specifikacije testova mogu se koristiti: Studija (ako postoji), specifikacija zahteva, model sluajeva upotrebe, razvojni plan, projektna dokumentacija i postojei projektni modeli. Specifikacija testa sadri sledea poglavlja (nadalje je dat i kratak opis sadraja poglavlja): 1. Beleka specifikatora testa Ovaj odeljak treba da sadri opis za konkretan test primer, svrhu testa, tip testiranja i opis primenjene metodologije, eventualno dati potrebne preduslove za izvrenje, hardverske i softverske zahteve (ako postoje). 2. Radnje/Ulazi Ovaj odeljak sadri, za konkretan test primer, opis radnji, odnosno vrednosti koje treba obaviti/uneti kao ulaz.

3. Oekivani Odzivi/Izlazi U ovom odeljku, za konkretan test primer, dati opis ili slike odziva koji je rezultat primene radnji/ulaza opisanih u prethodnom odeljku. Podrazumeva se da se daju ispravni odzivi/izlazi, a ne ono sto se dobije u testu. 4. Zavrne radnje Ova sekcija sadri informacije o svim neophodnim aktivnostima/radnjama koje su potrebne za smirivanje odnosno zavretak celog testa, na primer: zatvaranja projekata, brisanje.

6.2.2.3.

Realizacija testiranja

Faza implementacije test procedura, tj izvrenja testa se moe ponavljati za svaki build. Mogue je manuelno sprovoditi testiranje, ili upotrebom automatizovanih alata (pri emu se moraju razviti i odravati test skriptovi koji odgovaraju test sluajevima). Ulaz, odnosno polazni dokument za testere je Specifikacija testa. Rezultati testiranja se unose u dokumenti TestLog i Izvetaj o rezultatima testa. Izvetaj o rezultatima testa treba da bude podeljen na sledee sekcije kako bi se dao pregled rezultata testiranja: Generalna procena testiranog softvera Ova sekcija treba da: a. b. Obezbedi generalnu procenu softvera preko rezultata testa datih u ovom izvetaju Identifikovati sve preostale nedostatke, ogranienja ili prinudna reenja koja su

detektovana testiranjem. Za obezbeivanje informacija o nedostacima koristiti izvetaje o problemima i promenama. Uticaj test okruenja Ova sekcija treba da obezbedi procenu naina kako se test okruenje moe razlikovati od radnog/operativnog okruenja i uticaj tih razlika na rezultate testa. Preporuena poboljanja Ova sekcija treba da obezbedi preporuena poboljanja u specifikaciji, upotrebi ili testiranju softvera koji se posmatra.

Detalji o rezultatima testa Ova sekcija treba da bude podeljena na podsekcije navedene kasnije tako da predstavlja detaljan opis rezultata primene svakog testa. Podsekcije su identifikovane jedinstvenim identifikatorom testa i dati su pregled rezultata testa, pronaeni problemi i odstupanja od predvienih procedura testiranja. Test LOG Ova sekcija treba da obezbedi hronoloki zapis test dogaaja. Preporuka je da se izradi Log obrazac u obliku tabele gde bi se upisivali dogaaji. Takav test Log treba da sadri: a. b. Datum, vreme, lokacija gde je test izvren Hardverska i softverska konfiguracija koja je koriena za svaki test, ukljuujui (ako

je dostupno) podatke o modulu, modelu, serijskom broju, proizvoauitd. za hardver i obavezno broj verzije i ime softverske(ih) komponente(i) koja se koristi. c. Vreme i datum svake test aktivnosti, identitet lanova tima koji realizuju testiranje.

6.2.2.4.

Evaluacija rezultata testiranja

Na kraju neke faze testiranja radi se evaluacija rezultata testiranja. U ovoj fazi treba definisati mere (metrike) za evaluaciju kvaliteta testiranja i realizovati Izvetaj o proceni kvaliteta testiranja. U ovoj fazi se moe uraditi i analiza pronaenih defekata sa ciljem da se ukae na este i zajednike greke razvojnog dela tima, da se preporue naknadne aktivnosti (kursevi, doobuka, promena alata i sl).

6.3.

Proces testa
Koncepti testa, strategije, tehnike i mere potrebno je da budu integrisani u odreen i

kontrolisan proces koji vode ljudi. Proces testiranja podrava aktivnosti testiranja i omoguava voenje timovima testiranja, od planiranja testa do procene izlaza testa, kao to obezbeuje opravdano osiguranje da e ciljevi testiranja biti efikasno ispunjeni.

6.3.1. Praktina razmatranja 6.3.1.1. Programiranje bez stavova/bezlino

programiranje (Attitudes/Egoless programming)

Veoma bitna komponenta uspenog testiranja je stav saradnje za testiranje i kvalitetne aktivnosti uverenja. Menaderi imaju kljunu ulogu u usvajanju opteg pozitivnog prihvatanja otkrivanja defekata tokom razvoja i odravanja; na primer, prevencijom razmiljanja o vlasnitvu koda meu programerima, tako da se ne oseaju odgovornim za defekte koji su otkriveni njihovim kodom.

6.3.1.2.

Voenje testova (Test guides)

Faza testiranja moe biti voena raznim ciljevima, na primer: u testiranju baziranom na riziku, koje koristi rizik proizvoda radi utvrivanja prioriteta i fokusiranja na strategiju testa; ili u testiranju baziranom na scenariju, u kojem su sluajevi testa bazirani na utvrenom scenariju softvera.

6.3.1.3.

Menadment procesa testa

Aktivnosti testa sprovedene na razliitim nivoima moraju biti organizovane, zajedno sa ljudima, alatima, politikama, i merama, u dobro definisan proces koji je integralni deo ivotnog ciklusa. U IEEE/EIA Standardu 12207.0, testiranje se ne opisuje kao samostalan proces, ve su principi aktivnosti testiranja ukljueni u pet primarnih pocesa ivotnog ciklusa kao i u procese podrke. U IEEE Std 1074, testiranje je grupisano sa drugim aktivnostima evaluacije, kao znaajno za itav ivotni ciklus.

6.3.1.4.

Dokumentacija testa i proizvodi rada

Dokumentacija je integralni deo formalizacije procesa testa. IEEE Standard for Software Test Documentation (IEEE829-98) obezbeuje dobar opis dokumentacije testa i njihove meusobne veze i veze sa procesom testiranja. Dokumentacija testa moe

ukljuivati, izmeu ostalog, plan testa, specifikaciju dizajna testa, specifikaciju procedure testa, specifikaciju sluajeva testa, log testa, i incidente testa ili izvetaj o problemima. Softver pod testom se dokumentuje kao predmet testiranja. Dokumentacija testa bi trebalo da bude oformljena i kontinualno aurirana, do istog nivoa kvaliteta kao i drugi tipovi dokumentacije u softverskom inenjeringu.

6.3.1.5.

Interni vs. Nezavisni tim (Internal vs. independent

test team)
Formalizacija procesa testiranja moe ukljuivati formalizaciju i organizacije tima koji vri testiranje. Ovaj tim mogu sainjavati interni lanovi (odnosno, projektni tim, ukljuen ili ne u konstrukciju softvera), ili eksterni lanovi, sa ciljem da se dobiju objektivne, nezavisne perspektive, ili, na kraju, da bude sainjen i od internih i od eksternih lanova. Razmatranja trokova, vremena, zrelosti nivoa ukljuene organizacije, i kritinost aplikacije mogu presuditi u odluivanju.

6.3.1.6.

Procena trokova/napora i druge mere procesa

(Cost/effort estimation and other process measures)

Nekoliko mera povezanih sa resursima potroenim za testiranje, kao i u vezi sa relativnom efektivnou pronalaenja defekata na razliitim fazama testa, koriste menaderi kako bi kontrolisali i unapredili proces testa. Ove mere testa mogu pokrivati aspekte kao to su broj odreenih sluajeva testa, broj izvrenih sluajeva testa, broj sluajeva koji su proli, broj sluajeva koji su bili neuspeni, izmeu ostalih. Evaluacija faza testa moe se kombinovati sa analizom korenih uzroka (root cause) kako bi se procenila efektivnost procesa testa u nalaenju defekata to je ranije mogue. Takva procena se moe povezati sa analizom rizika. Povrh toga, resursi potroeni za testiranje trebalo bi da budu propocionalni sa upotrebom/kritinou primene: razliite tehnike imaju razliite trokove i daju razliite nivoe poverenja pouzdanosti proizvoda.

6.3.1.7.

Zavretak (Termination)

Potrebno je doneti odluku koliko je testiranja dovoljno i kada se moe zavriti faza testiranja. Temeljne mere, kao to je dostignuta pokrivenost koda ili funkcionalna kompletnost, kao i procene gustine defekata ili operativne pouzdanosti, omoguuju korisnu podrku, ali same nisu dovoljne. Odluka takoe ukljuuje razmatranja o trokovima i rizicima nastalim iz potencijalnih preostalih defekata, nasuprot trokovima koji bi podrazumevali nastavak testa.

6.3.1.8.

Ponovna upotreba testa i obrasci testa

Kako bi se testiranje ili odravanje sprovelo na organizovan i trokovno-efikasan nain, sredstva koriena za testiranje svakog dela softvera trebalo bi se sistematski ponovo koristiti. Ovo skladite materijala za testiranje mora biti pod kontrolom menadmenta za softversku konfiguraciju, tako da se promene zahteva softvera ili dizajna odraavaju u promenama prostora sprovedenog testa. Reenja testa prihvaena za testiranje nekih tipova aplikacija pod odreenim okolnostima, sa motivacijom iza sprovedene odluke, formiraju obrazac testa koji se moe dokumentovati za kasnije ponovne upotrebe u slinim projektima.

6.4.

Aktivnosti testa (Test activities)

Pod ovom temom dat je kratak pregled aktivnosti testa; kao to se esto podrazumeva

narednim opisom, uspeno upravljanje aktivnostima testa u velikoj meri zavisi od procesa menadmenta softverske konfiguracije.

6.4.1. Planiranje (Planning)

Kao i bilo koji drugi aspekt projektnog menadmenta, i aktivnosti testiranja mogu biti planirane.Kljuni aspekti planiranja testa ukljuuju koordinaciju zaposlenih, upravljenje dostupnih objekata za testove i opreme (koja moe da ukljuuje magnetske medije, planove i procedure testova), i planiranje moguih neeljenih ishoda. Ukoliko se odrava vie od jedne

osnovne linije softvera, tada se kao glavno razmatra vreme i napor potreban za obezbeivanje da je okruenje za test postavljeno na odgovarajuoj konfiguraciji.

6.4.2. Generisanje test-sluajeva (Test-case generation)

Generisanje test-sluajeva je bazirano na nivou testiranja koji treba izvriti i u odnosu na posebne tehnike testiranja. Test-sluajevi bi trebalo da budu pod kontrolom menadmenta softverske konfiguracije i ukljuuju oekivane rezultate za svaki test.

6.4.3. Razvoj okruenja testa (Test environment development)

Okruenje korieno za testiranje trebalo bi da je kompatibilno sa alatima softverskog inenjeringa. Trebalo bi da olaka razvoj i kontrolu test-sluajeva, kao i povraaj oekivanih rezultata, skripti, i drugih materijala za testiranje.

6.4.4. Izvravanje (Execution)

Izvravanje testa bi trebalo da otelotvori osnovni princip naunog eksperimentisanja: sve to je uraeno tokom testa trebalo bi da je izvreno i dokumentovano dovoljno jasno da bi druga osoba mogla da ponovi rezultate. Stoga, testiranje bi trebalo izvravati u skladu sa dokumentovanim procedurama, upotrebom jasno definisane verzije softvera u testu.

6.4.5. Procena rezultata testa (Test results evaluation)

Rezultati testa se moraju oceniti kako bi se utvrdilo da li je test bio uspean. U veini sluajeva, uspean znai da je softver dao oekivane rezultate i nije imao veih problema sa neoekivanim izlazima. Nisu svi neoekivani izlazi obavezno defekti.Pre nego to se defekt moe ukloniti, potrebna je analiza i napor kako bi se izolovao, identifikovao i opisao problem.Kada su rezultati testa posebno znaajni, moe se sazvati formalni sastanak za pregled kako bi to procenio.

6.4.6. Izvetavanje problema (Problem reporting)/Test log

Aktivnosti testiranja mogu se uneti u log testa kako bi se identifikovalo kada je test izvren, ko je izvrio test, koja je softverska konfiguracija bila osnova za testiranje, i druge relevantne informacije. Neoekivani ili netani rezultati testa mogu se zabeleiti u sistemu izvetavanja problema, podaci od kojih se formira baza za kasnije popravljanje greaka koji su bili zapaeni kao defekti tokom testiranja. Takoe, anomalije koje nisu klasifikovane kao defekti mogu se dokumentovati za sluaj da se kasnije ispostavi da su vanije od onoga to se prvo smatralo. Izvetaji testa su takoe ulaz za promenu procesa upravljanja.

6.4.7. Praenje kvarova (Defect tracking)

Neuspesi posmatrani tokom testiranja najee nastaju zbog defekata ili kvarova softvera. Takvi kvarovi se mogu analizirati kako bi se utvrdilo kada su uvedeni u softver, kakve greke su dovele do njihovog nastanka (loe definisane potrebe, netane deklaracije promenljivih, curenje memorije, greka programske sintakse) i kada su prvi put mogle biti primeene u softveru. Informacije o praenju kvarova koriste se za utvrivanje koje aspekte softverskog inenjeringa bi trebalo unaprediti i koliko su bile uspene prethodne analize i testiranja.

7. Alati za testiranje softvera

Pored raznih tehnika i metoda testiranja softvera razvijeni su i mnogi alati koji olakavaju ili potpuno automatizuju proces testiranja. Gotovo da je nemogue uiniti proces testiranja jasno definisanim i ponovljivim bez prednosti koje alati za testiranje nude.

Osnovna podela testiranja podrazumeva manuelno i automatsko testiranje. Naravno, manuelno testiranje se ne odigrava u potpunosti runo. Oba oblika testiranja koriste alate koji omoguavaju efikasnije testiranje. Razvoj automatskih alata za testiranje je reakcija na napredovanje web baziranih, klijent/server i alata za razvoj softvera koji su omoguili ubrzani razvoj aplikacija sa znatno boljim funkcionalnostima. Sektori za testiranje dolaze u dodir sa softverom koji je jako

unapreen, ali i kompleksan. Novi alati za testiranje se razvjaju kao podrka procesu obezbeenja kvaliteta. Postoji nekoliko kategorija alata po ciljevima i karakteristikama: Alati funkcija/regresija pomau u testiranju grafikog korisnikog interfejsa. Neki pomau i kod drugih tipova interfejsa. Npr. web test alati koji testiraju kroz pretraiva(capture/replay) alati. Alati za test dizajn/podatke pomau stvaranju test case-ova i generisanju test Load/performance alati alati za test optereenja i performansi. Test proces/menadment alati pomau organizovanje i izvravanje paketa

podataka.

testova na nivou komandne linije, API-ja ili protokola. Neki alati imaju grafiki korisniki interfejs, ali nemaju nikakvu specijalnu podrku za testiranje proizvoda koji imaju izvorni GUI. Unit test alati ovi alati, okviri i biblioteke podravaju unit testiranje, koje se Alati za test implementacije pomau testiranju u vreme izvravanja. Alati procene testa pomau procenu kvaliteta testova. Ukljuuju alate za Statistiki test analajzeri analiziraju programe bez pokretanja istih. Metriki Alati za upravljanje defektima alati koji prate softverski proizvod i defeke i obino izvrava od strane developera, obino korienjem interfejsa ispod javnog.

pokrie koda.

alati spadaju u ovu kategoriju. upravljaju zahtevima za njihovo poboljanje. Obuhvataju stanja defekta od otkria do zatvaranja problema. Alati za praenje performansi/usaglaenosti aplikacije mere i maksimiziraju vrednosti u IT ivotnom ciklusu isporuke, kako bi obezbedili da aplikacije zadovolje nivo kvaliteta, performanse i ciljeve dostupnosti. Alati runtime analize analiziraju programe dok su pokrenuti.

Postoji viestruka korist od korienja alata u procesu testiranja: Sistematika procesa: alati "vode" kroz odreene aktivnosti i na sistematizovan nain hijerarhijski organizuju i memoriu sve neophodne artefakte.

Poboljano upravljanje: u svakom trenutku mogue je proceniti u kom procentu je testiranje obavljeno i ta je jo ostalo da se uradi. Produktivnost: automatizovano testiranje obezbeuje da se vei broj testova sprovodi u jedinici vremena nego manuelno. Ponovljivost testa (podrka regresionom testiranju): kroz formalno implementiranje testova kroz test skriptove obezbeeno je da se test vie puta moe ponoviti pod identinim uslovima. Firma Rational nudi vrlo razraeno reenje automatizacije procesa testiranja u vidu

niza alata razliitih namena, koji sarauju meusobno i sa ostalim razvojnim alatima za druge faze razvojnog ciklusa softvera: Rational Administrator slui za administraciju repozitorijuma svih artefakata koji se odnose na projekat i aktivnost testiranja, pravljenje, auriranje projekata, dodela prava pristupa pojedinim lanovima tima itd. Rational TestManager prvenstveno se koristi za organizaciju i upravljanje

procesom testiranja, pravljenje test planova, dizajn testova i evaluaciju rezultata testiranja. Rational Robot implementacija testa kroz automatizovano funkcionalno i

performansno testiranje zasnovano na test skriptovima, sa funkcijom snimanja korisnikovih akcija nad aplikacijom i autogenerisanja skripta. Rational TestFactory analiziranje strukture aplikacija (prvenstveno gui, java, c++, vb) rada podrke implementacije testa kroz automatizovano generisanje test skriptova. Rational QualityArchitect specijalizovan za testiranje komponentnih tehnologija srednjeg sloja, EJB i COM. Rational ManualTest alat za implementaciju manuelnog testa. Rational SiteCheck alat za ispitivanje i kontrolisanje strukture i funkcije web aplikacija. Rational Purify detektuje greke u izvravanju i curenje memorije. Rational Quantify sakupljanje i analiza podataka o performansama. Rational PureCoverage podaci o pokrivenosti koda (white box testiranje).