Professional Documents
Culture Documents
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
3.1.
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.
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
5)
Modeli
agilnog
razvoja:
Exreme
Programming
(XP),
Adaptive
Software
Development (ASD), Dynamic Systems Development Method (DSDM),Srum,Feature Driven Development (FDD) , Agile Modeling (AM)
Prikupljanje informacija Analiza Projektovanje Aplikativno modeliranje Integracija sistema Testiranje sistema Odravanje sistema
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
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.
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
3.2.3.1.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
4.2.
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.3.
procentima; na primer, kada su sve grane izvrene makar jednom u testu, 100% pokrivenosti grana se kae da je postignuto.
4.4.
Sa razliitim nivoima formalizacije, ove tehnike testiranja smiljaju sluajeve za testiranja posebno namenjene za otkrivanje kategorija verovatno ili unapred definisanih defekata.
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.
4.6.
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
4.7.
5.1.
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.
Podela na klase ekvivalencije Analiza graninih vrednosti Testiranje zasnovano na tablici odluivanja
5.2.
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.
3. 4.
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
instaliranja, lokalizacije.
Za svaku od ovih dimenzija kvaliteta mora se definisati i sprovesti odgovarajui tip testiranja.
6.1.
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.
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
kontrolom repozitorijuma za upravljanje konfiguracijama (engl. Configuration Management, skraeno CM). d. Test materijal je podloan periodinim aktivnostima kontrole kvaliteta.
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.
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.
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.
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.
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 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.
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.
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.
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.
narednim opisom, uspeno upravljanje aktivnostima testa u velikoj meri zavisi od procesa menadmenta softverske konfiguracije.
osnovne linije softvera, tada se kao glavno razmatra vreme i napor potreban za obezbeivanje da je okruenje za test postavljeno na odgovarajuoj konfiguraciji.
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).