Prijavljivanje grešaka

Proces izveštavanja o greškama i preduzetim akcijama takođe mora biti precizno definisan. Česti su slučajevi otežanog identifikovanja grešaka usled nerazumevanja zahteva, kao i nepotpunog procesiranja zahteva za ispravkama. Sa druge strane, sam proces prihvatanja zahteva i ispravljanja mora biti vođen po unapred definisanoj proceduri. Mora se dati precizan odgovor na pitanja:

  • ko prijavljuje grešku,
  • kako je prijavljuje,
  • kako je opisuje,
  • kakvog je tipa,
  • kakav je status greške,
  • ko prihvata i dalje delegira zahtev, itd...

Na sledećoj slici su prikazane informacije relevantne za proces izveštavanja o greškama:


Slika 1. Izveštavanje o greškama
(izvor: www.software-quality-assurance.de)

Prioritet i uticaj greške

Najgori slučaj greške je onaj koji izaziva pad sistema bez mogućnosti oporavka sistema. Drugi tip su greške koje onemogućavaju funkcionalnu upotrebljivost pojedinih delova softvera. Postoje i greške u grafičkom interfejsu, odnosno prikazu podataka. Najbezazlenije su greške u dokumentaciji, koje takođe treba što pre ispraviti.


Opseg vidljivosti greške

Greške možemo klasifikovati i prema opsegu vidljivosti. Najdrastičnije slučaj kada su svi korisnici pogođeni uticajem greške. Postoje i slučajevi kada su samo pojedini klijenti pod uticaj određene greške kao npr. prikaz podataka prema nivou pristupa.


Vlasništvo greške

Na ovom polju je potrebno dati odgovor na pitanja:

  • Ko je prijavio grešku?
  • Kome je prijavljena greška?
  • Ko ispravlja grešku?
  • Ko testira ispravljenu grešku?

Pažljivo vođenje celog procesa i precizan odgovor na svako od pitanja doprinose brzom otklanjanju uočenih nedostataka.


Status greške

Sama greška koja se prijavi može biti novo otkrivena ili je u pitanju greška koja se već javljala u toku razvoja. Ukoliko je greška novo otkrivena, potrebno je uraditi analizu greške od strane Quality Assurance tima. Ako je greška već ranije prijavljena, mogući su sledeći slučajevi:

  • još nije počeo proces ispravke
  • tim za održavanje već radi na ispravljanju greške
  • uradjena ispravka, radi se testiranje dopune


Naravno, po okončanju kompletnog postupka potrebno je izvršiti zaključivanje izveštaja o grešci.


Predviđanje troškova ispravki defekata

Nivo i ozbiljnost softverskih defekata u softveru značajno utiču na troškove i vreme završetka razvoja. Broj otkrivenih i popravljenih softverskih grešaka u procesu testiranja najviše utiču na troškove, trajanje pojedinih aktivnosti razvoja, napore i potrebne resurse, performanse i kvalitet softvera, kao i na održavanje softvera. Pri oceni kvaliteta softvera moraju se precizno odrediti potencijalni defekti u softveru i efikasnost procesa otklanjanja uočenih defekata.


Težina ispravljanja defekata

Nisu svi uočeni defekti u softveru podjednako lako i jeftino popravljivi. Greške u projektnim zahtevima, problemi u projektovanju (dizajnu) i loše popravke uočenih grešaka predstavljaju najveće probleme u procesu razvoja. U momentu predaje softverskog proizvoda kupcu, greške nastale u fazi izrade projektnih zahteva i dizajna softverskog proizvoda imaju tendenciju da značajno premaše po broju greške napravljene pri kodiranju softverskih komponenti.


Faktori defekata

Postoji nekoliko faktora koji su specifični za greške:

  • Neponovljivost defekta - Tim za održavanje ne može da replicira tj. ponovo izazove prijavljeni opis (simptom) defekta.
     
  • Lažni defekt - Greška u sistemu nije izazvana softverskom aplikacijom (npr. uzrok je hardversko okruženje).
     
  • Greška pri servisiranju - Otklanjanjem prijavljene greške u softveru napravljena je nova greška, odnosno više novih grešaka.
     
  • Duplirana greška - Greške su prijavljene od više korisnika, a u pitanju je ista vrsta greške, koja je objašnjena na različite načine.

 

Slika 2. Software development life cycle
izvor: The Eye On Security Research Group India
http://www.eos-india.net/

 


Reference:

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

  • Izveštavanje o greškama 1
  • Izveštavanje o greškama 2