RAZPRAVE B Problematika sistemov za vodenje popravljanja in vzdrževanja Tomaž Dogša cV&Vs Center za verifikacijo in validacijo sistemov Fakulteta za elektrotehniko, računalništvo in informatiko, Univerza v Mariboru, Smetanova 17, 2000 Maribor tdogsa@uni-mb.si Povzetek Vsaka organizacija, ki želi delovati v skladu s smernicami glede kakovosti, mora vzpostaviti sistem, ki bo omogočal beleženje in nadzor nad nepravilnostmi ter spremembami (v nadaljevanju sistem SVPV). Kakovosten sistem SVPV ne omogoča samo nadzora nad zahtevki za spremembo, ampak tudi razne analize, s katerimi lahko ugotavljamo uspešnost oziroma slabosti razvoja. V prispevku je opisana problematika teh sistemov in na kratko komentiran standard IEEE 1044-1993. Abstract Difficulties of Problem Tracking and Maintenance Systems Each organisation intending to work according to the quality guidelines has to introduce a system of problem tracking and control of changes. The problem tracking system (PTS) of high quality does not support only data capturing, but also enables comparative analysis of effectiveness and weaknesses of software development cycle. In this paper a brief description of issues concerning PTS is presented and IEEE 1044-1993 Standard is also discussed. 1 Uvod Ena izmed značilnosti informacijskih sistemou je, da se pogosto spreminjajo. Formalni razlog, s katerim se zahteva sprememba komponente ali sistema, bomo poimenovali zahtevek za spremembo ali na kratko zahtevek. U mnogih primerih so obravnavane samo nepravilnosti in je zahtevek za spremembo v bistvu opažena nepravilnost ali problem. Zahtevki za spremembo so pomemben vir podatkov, na podlagi katerega lahko sklepamo o trenutni kakovosti produkta in razvoja, napovedujemo končno kakovost, razporejamo resurse in napovedujemo datum, ko bo produkt predan naročniku. Ker zahtevek sproži niz aktivnosti, ki lahko pomembno vplivajo na stroške, roke in kakovost sistema, je zelo pomembno, da imamo dober nadzor nad celotno življenjsko dobo zahtevka. Glede na razvojni cikel se spremembe sistema pojavljajo predvsem pri preverjanju in vzdrževanju. Vzroke za spremembo strukture sistema lahko uvrstimo v naslednje kategorije: nepravilno delovanje, izboljšava, prilagajanje spremembam v okolju in nove naročnikove zahteve. Prvi dve kategoriji kakovost dvigujeta, medtem ko jo zadnji dve samo ohranjata. Ko so vzroki za zahtevek odpravljeni, se konča njegov življenjski cikel. Vsaka organizacija, ki želi delovati v skladu s smernicami glede kakovosti, mora vzpostaviti sistem, ki bo omogočal beleženje in nadzor nad nepravilnostmi ter spremembami. Ta sistem bomo v nadaljevanju imenovali SVPV (sistem za vodenje popravljanja in vzdrževanja). Ker je kakovost produkta odvisna tudi od kakovosti procesa, se to odraža v nekaterih standardih, ki so povezani s kakovostjo. ISO 9001:2000 (sekcija 4.2.4 Obvladovanje zapisov) zahteva od dobavitelja, da mora vzpostaviti in vzdrževati postopke za prepoznavanje, zbiranje, urejanje, dopolnjevanje, shranjevanje, vzdrževanje in odstranjevanje zapisov o kakovosti. V ISO 9000-3 (Poglavje 5.7.3 Preskušanje) je zahtevano, da mora biti vsaka zaznana težava zapisana in njen status nadzorovan, dokler ni odpravljena. Tudi zrelostni model CMM (Capability Maturity Model) govori o procesiranju zapisov o ugotovljenih nepravilnostih. Nivo 2 zahteva samo beleženje in nadzor nad odpravo nepravilnosti, medtem ko nivo 3 zahteva še analizo nepravilnosti. Z vzročno analizo1 najdenih nepravilnosti in napak lahko dobimo vpogled v slabosti razvojnega procesa (glej zgled na preglednici 1). Na nivoju 4 je dodana še ocena napovedovanja zelo verjetnih nepravilnosti. Najvišji nivo (5) zahteva, da morajo biti vzpostavljene tudi aktivnosti za preprečevanje nepravilnosti. 1 Več o tej problematiki glej v članku [CARD, 1998], 2004 - številka 1 - letnik XII uporaBNA INFORMATIKA 5 Tomaž Dogša: Problematika sistemov za vodenje popravljanja in vzdrževanja Slika 1 prikazuje tipični razvojni proces, v katerem sistematično zapisujemo zahtevke. Ker je sistem za zapisovanje zahtevkov ključni element, od katerega so odvisne druge aktivnosti, se bomo v tem prispevku osredotočili predvsem na njegovo problematiko. taciji lastnega sistema SVPV3. Mnogo praktičnih napotkov se nahaja v [KANER,1993]. Ker je standard IEEE 1044-1993 eden redkih, ki lahko pomaga organizacijam pri vzpostavitvi sistemov SVPV, se bomo v prispevku nanj pogosto sklicevali. smernice, standardi razvoj produkta produkt preverjanje razvojni proces gS »u E O o o E CTl O) O Q. "D tfi nepravilnosti, ki jih je treba odpraviti opažene nepravilnosti, napake klasifikacija nepravilnosti, napake klasificirane nepravilnosti, napake skupina za vzročna kakovost priporočila analiza ■ Slika 1 Z vzročno analizo lahko izboljšujemo kakovost razvojnega procesa Na tržišču obstaja niz sistemov2 SVPV. To so podatkovno podprte aplikacije, ki so namenjene nadzoru nad popravljanjem in vzdrževanjem. Ker gre za relativno preproste podatkovne baze, so mnoge organizacije izdelale svoje sisteme SVPV. V večini primerov imajo dva ločena sistema za nadzor nad spremembami; prvi se uporablja v fazi razvoja in preverjanja, drugi pa v fazi validacije in kasnejšega vzdrževanja. Za učinkovito obvladovanje kakovosti je smiselno, da vsaj delno združimo oba, saj je mnogo aktivnosti enakih. Na kratko bomo opisali potek zapisovanja in opozorili na probleme, ki smo jih srečali pri implemen- Aktivnost Projekt 1 Projekt 2 Projekt 3 Pregled 10% 10% 2% Presoja 10% 8% 15% Inšpekcija 20% 22% 18% Testiranje 40% 38 % 5% Validacija 5% 2% 10% Uporaba 15 % 20% 50% Preglednica 1. Delež odkritih nepravilnosti po posameznih aktivnostih. Primerjava uspešnosti preverjevalnih metod kaže, da je zaradi neučinkovitega testiranja narastel delež odkritih nepravilnosti v fazi uporabe. 2 Povezava med preverjanjem, popravljanjem in uporabo V razvoju in kasnejšem vzdrževanju se sistem neprestano spreminja. Namen spremembe sistema lahko uvrstimo v naslednje kategorije: nepravilno delovanje, izboljšava, prilagajanje spremembam v okolju in nove naročnikove zahteve. Preverjanje, popravljanje in nadzor nad konfiguracijo so mnogokrat popolnoma ločene aktivnosti v življenjskem ciklusu, za katerega skrbi skupina za kakovost (slika 2). Med osebami, ki sodelujejo v teh aktivnostih, poteka izmenjava številnih informacij v obliki pisnih ali ustnih sporočil. Glede na stopnjo računalniške podpore in organiziranosti preverjanja ter popravljanja obstajajo naslednje stopnje beleženja zahtevkov: sistem, ki ga preverjamo uporabniki zahteva za spremembo zahteva za spremembo preverjevalci analitik vodja projekta poročilo o nepravilnostih predlog, ocene tveganja delovni nalog poročilo o popravilu skupina za kakovost popravljalci poročilo o kakovosti Slika 2: Povezava med preverjanjem, popravljanjem in uporabo 2 Na internetu jih iščemo z naslednjimi imeni: Problem management system, Bug tracking system, Incident tracking system, Problem tracking system. 3 Podrobnejši opis sistema SVPV, ki temelji na IEEE 1044-1993, je na naslovu: http://saturn.uni-mb.si/č cvv. 6 uroraona INFORMATIKA 2DD4 - številka 1 - letnik XII Tomaž Dogša: Problematika sistemov za vodenje popravljanja in vzdrževanja ■ Kaotični proces. Ni sistematičnega preverjanja. Avtorji sami preverjajo in sproti popravljajo. Če preverjanje izvaja posebna skupina, je komunikacija med preverjevalci in poprav]jalci ustna. Ni nobenih formalnih zahtevkov in pisnih poročil o najdenih neustreznostih in o popravilu. • Papirni proces. Skupina, ki preverja, zapisuje svoje ugotovitve na posebne formularje, ki jih pošiljajo popravljalcem. Vodja ima delni pregled nad obema skupinama. Ne analizira se učinkovitost popravljanja in preverjanja, saj analize zahtevajo dodatno delo. Uporabniki sporočajo opažene neustreznosti ustno, po telefonu ali elektronski pošti. • Avtonomno računalniško podprti procesi. Preverjevalci uporabljajo posebna računalniško podprta orodja, ki omogočajo učinkovito prevajanje. Podobno velja za popravljalce. Vsak ima svojo podatkovno bazo. Med bazami ni neposredne povezave. Uporabniki sporočajo opažene neustreznosti pisno ali po elektronski pošti. Tudi ti podatki se vnašajo v podatkovno bazo. • Centraliziran računalniško podprt proces. Sistem SVPV ima centralni repozitorij, ki ga koristijo vsa orodja, ki jih uporabljamo v razvoju. Uporabniki neposredno vpisujejo opažene nepravilnosti. Vodja ima zelo dober nadzor nad potekom popravljanja in preverjanja. Zasledovati je mogoče status vsake vpisane nepravilnosti. Izvajajo se razne analize, ki kažejo na kakovost preverjanja, popravljanja in tudi samega produkta. Z rezultati analiz lahko prognoziramo trenutne trende in racionat-neje razporejamo resurse. Slabost: velika odvisnost od centra. Končni (idealni) cilj je računalniško integriran razvoj, ki povezuje vse procese v celoto. Slabost tega pristopa so veliki stroški. V primeru, da že uporabljamo določena razvojna orodja, jih zelo težko vključimo v nov sistem. Potreben je nakup novih orodij in dodatno usposabljaje. Ker gre za zelo radikalne spremembe, povezane z velikim tveganjem, lahko pričakujemo, da se bodo le redki takoj odločali za centraliziran proces. 3 Tpični potek procesiranja zahtevka Ena izmed zelo pomembnih entitet v podatkovnem modelu sistema SVPV je zahtevek za spremembo. Nanaša se na točno določen objekt ali sistem oziroma na njegovo verzijo. Obstaja več postopkov procesiranja zahtevka. Večina ustreza modelu, ki ga prikazuje slika 3. Zahtevek za spremembo, ki je lahko obravna- Slika 3: Popravljanje oziroma spreminjanje sistema, prikazano z diagramom prehajanja stanj. Najpogostejša je popolnoma navpična pot. van kot izboljšava, nepravilnost ali sprememba spect-fikacij, sproži naslednje štiri aktivnosti: • sprejem in opis zahtevka za spremembo, • analizo zahtevka, ■ odločitev o ukrepih za odpravitev zahtevka, ■ odločitev o končnem statusu zahtevka. Vse te aktivnosti so lahko eksplicitno ločene ali pa so združene in se navzven kažejo kot samo ena aktivnost. Začetna aktivnost je sprejem zahtevka. Oseba, ki zahteva spremembo, navede namen zahtevka (izboljšava, odprava nepravilnosti ali sprememba specifikacij), na kratko opiše problem in ga klasificira glede na izbrani taksonomijski sistem. Nato sledi anat-iza zahtevka, kjer analitik podrobneje preuči zahtevek in poda predlog o rešitvi ter poišče vzroke, ki so povzročili nastanek zahtevka. Odločiti se mora, ali gre morebiti za napačno uporabo ali se obravnavani zahtevek že obdeluje, kakšen vpliv ima zahtevek na kakovost sistema, oceniti mora razna tveganja (popraviti ali ne popraviti). O predlaganih ukrepih odloča pristojna oseba. Sledi izvajanje tega predloga (npr. popravilo) in nato odločitev o končnem statusu 2004 - številka 1 - letnik XII uporABNA INFORMATIKA 7 Tomaž Dogša: Problematika sistemov za vodenje popravljanja in vzdrževanja zahtevka (rešen, odložen, združen z drugim zahtevkom, prenesen na drug projekt, vrnjen v popravilo). Če gre za nepravilnost, potem se mora odgovorna oseba odločiti, ali bo ta nepravilnost dobila status hibe (ni popravljanja) ali pa bo priznana kot odpoved, ki zahteva popravilo. Iz tega kratkega opisa je razvidno, da v celotnem procesu nastopajo sporočevalci (pre-verjevalci, uporabniki), analitik, popravljalci in odgovorna oseba (npr. vodja projekta). Seveda lahko vse te vloge opravlja samo ena oseba. Pri tem je treba razlikovati med pojmi, kot so napaka ali vzrok za nepravilnost, odpoved, nepravilnost in hiba [DOGŠA,1998]. Uporabniki in preverjevalci opazijo nepravilno obnašanje sistema. Torej zaznajo nepravilnost, ki je posledica ene ali več napak v programu ali dokumentaciji. Napake poiščejo in odpravijo popravljalci. Če se ne odločimo za popravilo, dobi nepravilnost status hibe, sicer jo klasificiramo kot odpoved. Odpravljanje napak ni nič drugega kot popravilo4. Popravljalec je oseba, ki z ustrezno spremembo sistema odpravi napake. Običajno popravljanju sledi preverjanje, ki naj ugotovi, ali so nepravli-nosti odpravljene. V vsakem izmed štirih korakov (sprejem, analiza, ukrepi in odločitev o končnem statusu) se izvajajo tri aktivnosti: opisovanje, klasificiranje in ocenjevanje vpliva na kakovost in ocena tveganja. Te aktivnosti se lahko v posameznih korakih ponavljajo oziroma dopolnjujejo; npr. ko nepravilnost odkrijemo, približno določimo domnevni vzrok.. Kasneje, ko nepravilnost podrobneje analiziramo, lahko tudi natančneje določimo te vzroke. Ker vsako spreminjanje sistema zahteva tudi ustrezno zapisovanje sprememb, se ves postopek še bolj zaplete, če vzdržujemo več različnih verzij. Ena izmed najpomembnejših aktivnosti je klasifikacija nepravilnosti in napak. Pri implementaciji sistema SVPV je smiselno, da se odločimo za ustrezen enoten klasifikacijski sistem. Takemu sistemu pravimo tudi taksonomijski sistem. Le če uporabimo enotno klasifikacijo, lahko izvajamo razne primerjave in analize o učinkovitosti testiranja, popravljanja in kakovosti sistema (glej preglednico 2). Najbolj znani klasifikacijski sistemi so: ortogonalni klasifikacijski sistem5, ki ga je razvil IBM [CHILLAREGE,1992], Hevvlett-Packardov sistem [PFLEEGER.,1998] in sistem, ki ga definira standard IEEE 1044 [IEEEstd,1993]. Slednjega bomo v nadaljevanju na kratko opisali. V mnogih primerih podatkovna aplikacija omogoča spreminjanje klasifikacijskega sistema. To pa ne velja za procesni vidik (slika 3), ki je v večini primerov vgrajen v sistem SVPV. 4 Standard IEEE 1044-1993 Standard IEEE 1044-1993 [IEEEstd, 1993] zelo dobro opisuje potek vodenja popravljanja in vzdrževanja informacijskih sistemov. Kljub temu, da je poudarek na programski opremi, se lahko z majhno prilagoditvijo uporablja tudi za strojno opremo. Standard opisuje postopek, ki smo ga na kratko povzeli v prejšnjem poglavju. Vodenje popravljanja in vzdrževanja sistemov je sestavljeno iz štirih zaporednih aktivnosti: • zaznave nepravilnosti (RR Recognition), • analize nepravilnosti (IV Investigation), > ukrepov za odpravitev nepravilnosti (AC Action), > določitve končnega statusa nepravilnosti (DP Disposition). Glavnina standarda opisuje razne klasifikacijske tabele (preglednica 2), ki so v nekaterih primerih zelo podrobne. Za opis vsakega zahtevka imamo na razpolago 21 atributov, obveznih jih je 11. Za vsako aktivnost je predvidena posebna neobvezna priloga (npr. ekran-ska slika). Vse priloge so opisane s 113 atributi. Če želimo uporabiti standard v polnem obsegu, je treba izpolniti približno5134 polj. Vrednosti atributov, s katerimi opisujemo zahtevke, črpamo iz klasifikacijskih tabel. Na ta način je možna primerjava med podatki, ki jih dobimo pri različnih projektih in uporabnikih. Z velikostjo klasifikacijske tabele se veča natančnost opisa in hkrati manjša preglednost ter veča napor, ki ga je treba vložiti v opis zahtevka. Najobširnejša je tabela, s katero opisujemo napako. Zaradi preglednosti je sestavljena iz dveh nivojev. Klasifikacijske tabele, ki so označene poudarjeno (domnevna domena vzroka, opis simptoma, dejanska domena vzroka, opis vzroka), so odvisne od vrste sistema. Če gre za strojno ali kombinirano opremo, jih je treba ustrezno spremeniti. V zadnjih štirih kolonah v preglednici 2 je opisano, kdaj naj določen podatek vpišemo oziroma ažuri-ramo. 4 Pogosto se po nepotrebnem uporablja izraz razhroščevanje (angl. debugging). s ODC Orthogonal Defect Classification. 6 Všteti niso atributi, ki se nanašajo na procesiranje zahtevka. 8 uporabna INFORMATIKA 2004 - številka 1 - letnik XI! Kategorije ¡atribut) Obvezen Velikost tabele (število atributov) Mirim, velikost tabele Prevod Komentar Sprejem Analiza Sprejeti ukrep Končni status Project activity da g 9 Preverjevalna aktivnost Aktivnost, s katero je bila odkrita nepravilnost. vnos Project phase da 24 6 Faza v projektu Faza, v kateri se produkt z nepravilnostjo trenutno nahaja. vnos Suspected cause ne 26 □ Domnevna domena vzroka Približna domnevna lokacija vzroka (program, strojna oprema) vnos ažuriraj Repeatability ne 5 0 Pogostost Pogostost pojavljanja nepravilnosti. vnos ažuriraj Symptom da 18 9 Opis simptoma vnos ažuriraj Product status ne 4 □ Uporabnost produkta Uporabljivost produkta, če ga ne spreminjamo. vnos ažuriraj Severity da 5 5 Resnost nepravilnosti Resnost z v vidika strokovnjaka. vnos ažuriraj Priority ne 5 D Prioriteta popravila vnos ažuriraj ažuriraj ažuriraj Customer value ne 6 Vpliv na zadovoljstvo uporabnika Kako vpliva odkrita nepravilnost na zadovoljstvo uporabnika? vnos Mission/Safety ne 5 0 Vpliv na uspešnost projekta vnos ažuriraj ažuriraj ažuriraj Actual cause da 26 6 Dejanska domena vzroka Približna lokacija vzroka (program, strojna oprema) vnos ažuriraj Source da 28 7 Poreklo vzroka (napake) Vmesni produkt v razvoju (specifikacije, koda), v katerem se nahaja napaka, ki je vzrok za nastanek nepravilnosti. vnos ažuriraj Type da 80 9 Opis vzroka (napake) Podroben opis vzroka, zaradi katerega se je pojavila nepravilnost. vnos ažuriraj Project schedule da 4 4 Vpliv na termine projekta vnos ažuriraj ažuriraj Project costs da 4 4 Vpliv na stroške projekta vnos ažuriraj ažuriraj Project risk ne 4 0 Tveganje v primeru popravila /spremembe produkta vnos ažuriraj ažuriraj Project quality/reliability ne 4 0 Vpliv na kakovost/zanesljivost projekta □cena spremembe kakovosti produkta, če ga bomo popravili/spremenili. vnos ažuriraj Societal ne 4 0 Vpliv na mnenje širše družbe Kako bi vplivalo popravilo/sprememba produkta na negativno mnenje družbe? vnos ažuriraj Resolution da 21 4 Ukrep Ukrepi, ki naj se izvedejo, vnos ažuriraj Corrective action 23 0 Bodoča preventiva vnos ažuriraj Disposition da 9 9 Končni status vnos Preglednica 2: Najpomembnejše klasifikacijske tabele [standard IEEE 1044-1993) Tomaž Dogša: Problematika sistemov za vodenje popravljanja in vzdrževanja 5 Sklep Najosnovnejši cilj sistema SVPV je nadzor nad odpravljanjem nepravilnosti. Pravilno izbran klasifikacijski sistem omogoča analize, s katerimi lahko ugotavljamo uspešnost oziroma slabosti razvoja. Ker zahteva uporaba sistema SVPV dodaten napor sodelujočih, je zelo pomembno, da je le-ta kakovosten v smislu implementacije in vsebine. Le na videz je sistem SVPV zelo preprosta podatkovna aplikacija, ki jo lahko napravimo v accessu v nekaj dneh. Vzdrževanje sistema SVPV obsega popravljanje in širjenje klasifikacijskih tabel ter spreminjanje postopka procesiranja zahtevka (sliko 3). Za slednjega velja, da je izvedljiv samo, če imamo dostop do izvorne kode. To je ena izmed največjih slabosti kupljenih sistemov SVPV. Za konec bomo na kratko opisali najpomembnejše lastnosti, ki jih mora imeti sistem SVPV. Ponovljivost je lastnost zahtevka, ki omogoča popolno rekonstrukcijo vzroka, zaradi katerega je bil podan zahtevek. Za zgled poglejmo zahtevek, ki obravnava opažene nepravilnosti v delovanju modula. Če je na podlagi informacij, ki so v zahtevku, vedno mogoče povzročiti opisano nepravilno delovanje modula, pravimo, da smo zadostili kriteriju ponovljivosti. Če zahtevek ni ponovljiv, je v splošnem zelo težko odpraviti njegove vzroke. To še posebej velja, kadar ni materialnih dokazov za nepravilno delovanje. Isto velja za ponovljivost klasificiranja. Neka druga oseba mora isti zahtevek klasificirati popolnoma enako. Uporabnost sistema je merilo napora, ki ga moramo vložiti v to, da lahko sistem učinkovito uporabljamo. Problemi se pojavljajo predvsem pri raznih klasifikacijah. Podrobnejše kot so klasifikacijske tabele, težja je klasifikacija. S pregrobo granulacijo lahko izgubimo informacije, ki jih potrebujemo pri analizi uspešnosti razvojnega procesa. Problematični so predvsem poreklo, domena in opis vzroka. Če želimo zagotoviti ponovljivost klasifikacije, je pri slabo zastavljenem klasifikacijskem sistemu potreben velik napor. V praksi se zato pogosto dogaja, da je klasifikacija izvedena površno. V večini primerov so sistemi SVPV tako zahtevni, da je potrebno posebno izobraževanje. Zelo pomem- ben je procesni vidik podatkovne aplikacije, katerega je kasneje težko spreminjati. Ker so zahtevki povezani s stroški, ki nastanejo z odpravljanjem vzrokov, nas zanima, kdo pošilja zahtevek. Avtentičnost je lastnost, na podlagi katere lahko identificiramo pošiljatelja. V veliki večini primerov firme ne želijo javno objavljati ugotovljene nepravilnosti, saj bi lahko konkurenti te podatke izkoristili. Ker je pri preverjanju in popravljanju potrebna diskretnost, morajo biti podatki zaščiteni pred nepooblaščenim branjem oziroma spreminjanjem. Ker je preverjanje povezano z velikimi stroški, se noben zahtevek ne sme izgubiti. Izgubljen zahtevek pomeni ponovitev preverjanja. To lastnost bomo poimenovali vestnost. Lahko se zgodi, da so nekateri zahtevki na prvi pogled nesmiselni oziroma nepomembni. Ignoriranje zahtevka je resna odločitev, za katero se lahko odloči lahko le odgovorna oseba. Običajno je vodja projekta oseba, ki nadzoruje reševanje zahtevkov in tudi nosi odgovornost za potek popravljanja. Sistem za vodenje popravljanja in vzdrževanja sistemov bo učinkovit, če bomo z njim zmanjšali stroške vzdrževanja. 6 Literatura [CARD.199B] David N. Card: "Learning from our Mistakes with Defect Causal Analysis", IEEE Software, januar/februar, 1998, str. 56-63. [CHILLAREGE,1992] Ram Chillarege in drugi: "Orthogonal defect classification—A concept for in-process measurment", IEEE Transaction on Software Engineering, VOL 98, številka 99, 9992, str. 943-956. [DOGSA,1998] Tomaž Dogša: "Gostota napak in odpovedi - problematično merilo kakovosti", Uporabna informatika, štev. 2, letnik VI, 9998, str. 20-25. [IEEEEtd,1993] "IEEE Std 1044-1993: IEEE Standard Classification for Software Anomalies", This Institute of Diectrical and Electronics Engineering, Inc., 9993. [WRNEER1993] Cern Kaner, Jack Falk, Hung Quoc Nguyen: "Testing Computer Software", Van Nostrand Eeinhoid, 9993. S. A. Pfleeger: "Software Engineering, Theoryand Practice", Prentice Hall, Inc. Dr. Tomaž Dogša je izredni profesor na Fakulteti za elektrotehniko, računalništvo in informatiko v Mariboru, kjer predava na dodiplomski in podiplomski stopnji in vodi Center za verifikacijo in validacijo sistemov. Na raziskovalnem področju se ukvarja predvsem z VSV tehnologijo oziroma testirnimi orodji. 10 upobabna INFORMATIKA 2004 - številka 1 - letnik XII