Elektronika.lt
 2024 m. kovo 29 d. Projektas | Reklama | Žinokite | Klausimai | Prisidėkite | Atsiliepimai | Kontaktai
Paieška portale
EN Facebook RSS

 Kas naujo  Katalogas  Parduotuvės  Forumas  Tinklaraščiai
 Pirmas puslapisSąrašas
 NaujienosSąrašas
 StraipsniaiSąrašas
 - Elektronika, technika
 - Kompiuterija
 - Telekomunikacijos
 - Įvykiai, visuomenė
 - Pažintiniai, įdomybės
 Vaizdo siužetaiSąrašas
 Nuolaidos, akcijosSąrašas
 Produktų apžvalgosSąrašas
 Naudingi patarimaiSąrašas
 Vykdomi projektaiSąrašas
 Schemų archyvasSąrašas
 Teorija, žinynaiSąrašas
 Nuorodų katalogai
 Įvairūs siuntiniai
 Bendravimas
 Skelbimai ir pasiūlymai
 Elektronikos remontas
 Robotų kūrėjų klubas
 RTN žurnalo archyvas






 Verta paskaityti
Kovo 28 d. 20:32
„Elektrum Lietuva“ į elektromobilių įkrovimo tinklo plėtrą šiemet investuos 9 mln. eurų
Kovo 28 d. 17:25
NASA „BurstCube“ palydovas paleistas tirti galingiausius sprogimus kosmose
Kovo 28 d. 14:50
„Logitech“ pristato „Signature Slim“ klaviatūrą ir darbo bei gyvenimo derinį prie rašomojo stalo
Kovo 28 d. 11:17
Kaip atrodys mokslai, studijos ir darbas DI eroje: pagrindiniai parodos „Karjera & studijos Lietuvoje“ akcentai
Kovo 28 d. 08:52
Jungikliai pagaminti iš atliekų – naujovė tvariems namams
Kovo 27 d. 20:30
Saulės elektrinė – daugiabučio balkone: ar tai įmanoma Lietuvoje? (1)
Kovo 27 d. 18:19
4 išmanūs sprendimai, leidžiantys efektyviai taupyti elektrą
Kovo 27 d. 16:36
Ekspertė apie dirbtinį intelektą ir darbuotojų produktyvumą: „Svarbu suprasti, jog nėra vieno stebuklingo įrankio, kuris išspręstų visas problemas“
Kovo 27 d. 14:14
„Philips Monitors“ E1 serija turės tris naujus daugiafunkcinius modelius, skirtus hibridiniam ir nuotoliniam darbui
Kovo 27 d. 12:43
Reikalavimas elektrifikuoti penktadalį stovėjimo vietų glumina verslą: nukentės galutiniai vartotojai
FS 22 Tractors
Farming Simulator 19 Mods, FS 22 Maps, FS22 Mods
ETS2 Mods
ETS2 Trucks, ETS2 Bus, Euro Truck Simulator 2 Mods
FS22 Tractors
Farming Simulator 22 Mods, FS22 Maps, FS22 Trucks
VAT calculator
VAT number check, What is VAT, How much is VAT
Paskola internetu
Vartojimo paskola, paskola automobiliui, paskola būsto remontui
Thermal monocular
Thermal vision camera,
Night vision ar scope,
Night vision spotting scope
FS22 Mods
FS22 Harvesters, FS22 Tractors Mods, FS22 Maps Mods
FS22 Mods
FS22 Maps,
FS22 Harvesters,
FS22 Tractors
Dantų protezavimas
All on 4 implantai,
Endodontija mikroskopu,
Dantų implantacija
Sims 4 Mods
Sims 4 CC Clothes,
Sims 4 Hair CC,
Sims 4 Skill Cheat
Optic sight
Binoculars for hunting elk,
Best compact binoculars,
Riflescope hunting
Reklama
 Straipsniai » Kompiuteriai, IT Dalintis | Spausdinti

Programinės įrangos defektų valdymas

Publikuota: 2005-12-25 07:29
Tematika: Kompiuteriai, IT
Skirta: Profesionalams
Autorius: Jolita Mackienė
Aut. teisės: ©Baltijos programinė įranga, UAB
Inf. šaltinis: Baltijos programinė įranga, UAB

Testavimas – tai įrankis kokybei pamatuoti. Norint, kad atrastos problemos būtų pašalintos, apie jas visų pirma turi būti pranešta. Iš kitos pusės testavimas yra susijęs su rizikos valdymu, o mes negalime valdyti rizikos neturėdami duomenų. Todėl kyla poreikis atrastus defektus ne tik komunikuoti, bet ir valdyti juos.

 Rodyti komentarus (0)
Įvertinimas:  1 2 3 4 5 
Defekto ataskaita yra priemonė, leidžianti įvertinti, ar įmonei yra verta leisti savo laiką ir pinigus klaidos ištaisymui.
– Cem Kaner

Testavimas – tai įrankis kokybei pamatuoti. Jo metu mes siekiame įvertinti, ar programinė įranga atitinka apibrėžtus kokybės kriterijus ir nustatyti problemas (defektus), dėl kurių sistema negali atitikti vartotojo lūkesčių.

Norint, kad atrastos problemos būtų pašalintos, apie jas visų pirma turi būti pranešta. Iš kitos pusės testavimas yra susijęs su rizikos valdymu, o mes negalime valdyti rizikos neturėdami duomenų. Todėl kyla poreikis atrastus defektus ne tik komunikuoti, bet ir valdyti juos. Defektų valdymui visų pirma reikalingas jų dokumentavimas. Tokiu būdu defektų komunikavimas ir valdymas tampa būtina testavimo proceso dalimi, o defekto ataskaita – technine dokumentacija, aprašančia defekto simptomus, kai sistema elgiasi ne taip, kaip turėtų.

Kodėl defektų komunikavimo ir raportavimo procesas yra toks svarbus? Defektų ataskaita yra ne tik aprašomi klaidos simptomai, bet ir:

  1. Įvertinama rizika, kad klaidą pastebės tipinis sistemos vartotojas.
  2. Nurodoma žala, kurią klaida daro vartotojui ir sistemai.
  3. Izoliuojant defektą padedama tiksliau nustatyti klaidos ištaisymo kaštus ir riziką.

Ši defektų ataskaitose pateikta informacija padeda tiksliau nustatyti testuojamo produkto kokybės lygį, įvertinti reikalingų pataisymų kiekį ir su jais susijusius kaštus.

Defektų raportavimo procesas

Geriausias testuotojas yra ne tas, kuris atranda daugiausia defektų. Geriausias testuotojas yra tas, kurio atrastų defektų yra daugiausia ištaisoma.
– Cem Kaner

Defekto ataskaita visų pirma yra komunikacijos priemonė tarp kokybės inžinieriaus ir kitų projekto narių. Kuo aiškiau ir tiksliau bus aprašyta klaida, tuo didesnė tikimybė, kad ji greičiau bus ištaisyta. Deja, dažnai defektų raportavimas yra suprantamas kaip elementari ir nereikalaujanti įgūdžių veikla. Dėl neefektyvių defektų ataskaitų didelė dalis defektų yra grąžinami kaip nepakartojami. Rezultatas – gaištamas laikas defekto ataskaitos taisymui, ilgėja defekto ištaisymo ciklas, prastėja santykiai tarp kokybės inžinieriaus ir programuotojo.

UAB „Baltijos programinė įranga“ klaidų ataskaitų rašymas yra laikomas techninės dokumentacijos kūrimu: defektų raportavimo procesas yra apibrėžtas įmonės ir projektų lygiuose, nustatytas defekto ataskaitos šablonas, sukurtas defektų ataskaitų rašymo stiliaus rekomendacijų dokumentas. Įmonėje defekto raportavimo procesą sudaro šios veiklos:

1. Pakartojimas

Lietuvių liaudies patarlė sako: „Devynis kartus matuok, dešimtą kirpk“. Prieš rašant defekto ataskaitą, klaidinga situacija turi būti pakartota bent keletą kartų. Bet ką daryti, jei defekto nepavyksta pakartoti kiekvieną kartą? UAB „Baltijos programinės įranga“ defektų ataskaitos stiliaus rekomendacijose tokiu atveju į defekto ataskaitą yra siūloma įtraukti papildomą informaciją apie defekto pakartojamumą. Pavyzdžiui, „Jei nepavyko pakartoti defekto, nukopijuok tekstą ir pakartok testavimo žingsnius iš naujo“.

2. Perteklinių žingsnių pašalinimas

Kokybės inžinieriaus tikslas yra kuo tiksliau programuotojui pateikti informaciją apie rastą defektą. Tiksliai aprašyti defekto simptomai padeda programuotojui greitai atrasti ir pašalinti defekto priežastį. Defekto ataskaitoje turi būti palikti tik tie žingsniai, kurie yra tiesiogiai susiję su klaida. Perteklinių žingsnių pašalinimas atliekamas defekto kartojimo metu naudojant skirtingas žingsnių kombinacijas, taip pat paeiliui šalinant žingsnius ir stebint, ar jie turėjo įtakos defekto atsiradimui.

3. Apibendrinimas

Dažnai klaidos simptomai, kuriuos stebi kokybės inžinierius konkrečiu atveju iš tiesų yra bendros problemos dalis. Tarkime, kokybės inžinierius atranda problemą, kad lentelės sukūrimui naudojamas spartusis klavišas Ctrl+Shift-1 neveikia, jei skaičius įvedamas naudojant klaviatūros skaitmenų sritį. Atlikus papildomą testavimą paaiškėja, kad visi naudojantys skaičius spartieji klavišai neveikia, jei skaičių įvedimui naudojama klaviatūros skaitmenų sritis. Defekto apibendrinimas padeda tiksliau įvertinti klaidos poveikį sistemą ir įvertinti jos ištaisymo svarbą.

4. Dviprasmiškumo panaikinimas

Ištrauka iš defekto ataskaitos: „Prisijungimo lange įvesk ilgą vartotojo vardą“. Kas yra ilgas vartotojo vardas: 6, 10, ar 100 simbolių? Aiškumas yra kokybiškos defekto ataskaitos pagrindas. Defekto ataskaitoje neturi būti vartojami žodžiai ar frazės, kuriuos perskaičius kiltų klausimas: ką tiksliai kokybės inžinierius norėjo pasakyti?

5. Defekto prioriteto ir poveikį įvertinimas

Vienas iš testavimo principų sako: „Ne visi rasti defektai bus ištaisyti“. Kaip pasirinkti, kokius defektus taisyti, o kokius ne? Nėra programinės įrangos, kuri neturėtų defektų. Tiesiog gera programinė įranga yra ta, kurioje yra atrasti ir ištaisyti tie defektai, kuriuos pastebėtų didžioji dalis sistemos vartotojų. Todėl kiekvieną rastą defektą mes turime įvertinti dviem aspektais: 1) kokia tikimybė, kad sistemos tipinis vartotojas pastebės defektą ir tokiu būdu nustatyti jo prioritetą; 2) kokią žalą defektas daro sistemai ir vartotojui ir taip nustatyti jo poveikį.

UAB „Baltijos programinė įranga“ prioriteto ir poveikio reikšmės gali būti apibrėžtos kiekvienam projektui atskirai. „MagicDraw“ projekte defektai gali būti A, B arba C prioriteto ir daryti kritinį, didelį, blokuojantį, mažą, trivialų arba kosmetinį poveikį sistemai.

6. Papildoma informacija

Be defekto simptomų aprašymų, poveikio ir prioriteto nustatymo defektų valdymui yra svarbi defektą papildanti informaciją: kas rado defektą, kada jis buvo rastas, kokiame sistemos modulyje, kokioje testuojamos sistemos versijoje ir pan. UAB „Baltijos programinė įranga“ defektų ataskaitų įvedimui yra naudojama defektų valdymo sistema (paveikslas Nr. 1).

7. Santrauka

Defekto ataskaitos santrauka yra trumpas klaidos apibūdinimas vienu sakiniu. Trumpa defekto santrauka padeda greitai suprasti, kurioje produkto dalyje yra klaida ir koks jos poveikis sistemai. Pavyzdžiui, defekto santrauka „Stereotipo piktograma nėra rodoma diagramoje“ yra žymiai aiškesnė nei „Stereotipo pikrogramos rodymas“.

Geros defekto ataskaitos santraukos parašymui gali prireikti daugiau įgūdžių nei atrodytų iš pirmo žvilgsnio. Trumpam ir aiškiam tekstui parašyti dažnai reikia skirti daug laiko. Thom Jefferson kartą ilgą laišką užbaigė sakiniu: „Būčiau parašęs trumpesnį laišką, bet neturėjau laiko“.

8. Peržiūra

Projekto artefaktų peržiūros padeda anksti atrasti defektus ir taip sumažinti jų ištaisymo kaštus. Defekto ataskaita taip pat yra techninis dokumentas, kuriam turi būti taikoma peržiūra. UAB „Baltijos programinė įranga“ defektų ataskaitų peržiūras priklausomai nuo projekto dydžio atlieka kokybės grupės vadovas arba projekto vadovas.


1 pav. Defekto ataskaitos įvedimo forma

Programinės įrangos defektų valdymo sistemos

Kiekviena defekto ataskaita turi savo gyvavimo ciklą: ji yra sukuriama, defektas išsprendžiamas, patikrinamas ir uždaromas. Periodo nuo defekto ataskaitos sukūrimo iki uždarymo trukmė priklauso nuo pasirinkto programinės įrangos kūrimo proceso, o taip pat nuo defektų valdymo efektyvumo.

UAB „Baltijos programinė įranga“ defektai yra valdomi naudojant defektų valdymo sistemą. Kodėl defektų valdymui buvo pasirinktas įrankis? Defektų valdymo sistemos naudojimas teikia įvairiapusę naudą projektui:

1. Aiškesnė komunikacija

Remiantis apibrėžta forma sukurtos defektų ataskaitos yra suprantamos kur kas aiškiau nei žodžiu perduota ar laisva forma parašyta informacija apie klaidą.

2. Defekto gyvavimo ciklo valdymas

Defektų ataskaitos yra valdomos nuo jų sukūrimo momento iki galutinio uždarymo. Defektų valdymo įrankiai paprastai jau turi įdiegtą defekto gyvavimo ciklą, tačiau jis gali būti modifikuojamas ir pritaikomas pagal projekto poreikius. UAB „Baltijos programinė įranga“ yra apibrėžtas defektų valdymo ciklas (paveikslas Nr. 2):

  • Naują defekto ataskaitą projekto vadovas priskiria programuotojui.
  • Programuotojas analizuoja naujo defekto ataskaitą ir, jei ištaiso klaidą, pažymi defekto ataskaitą kaip ištaisytą. Jei programuotojas negali ištaisyti klaidos, defekto ataskaitai yra nurodoma viena iš standartinių žymių, rodančių, kad defektas bus taisomas vėliau ar nebus taisomas iš viso.
  • Kokybės inžinierius tikrina išspręstą defekto ataskaitą ir patvirtina jos išsprendimą, jeigu klaida ištaisyta tinkamai, arba atmeta išsprendimą, jeigu klaida yra neištaisyta, ištaisyta netinkamai ar tik dalinai. Atmetus išsprendimą, defekto ataskaita vėl yra laikoma nauja.
  • Patvirtintos defekto ataskaitos gali būti uždaromas arba naudojamos pakartotinio testavimo metu. Jei defektas, kurio simptomai aprašyti jau uždarytoje defekto ataskaitoje, atsinaujina, defekto ataskaita yra pakartotinai atidaroma.

2 pav. Defekto gyvavimo ciklas

3. Ataskaitų generavimo funkcijos

Defektų valdymo sistemoje yra saugoma visa informacija apie testuojamos programinės įrangos defektus. Duomenų analizės ir ataskaitų generavimo priemonės padeda projekto vadovui įvertinti ir stebėti testuojamos sistemos kokybę.

4. Defekto ataskaitos istorijos saugojimas

Defekto ataskaitai pereinant iš vieno gyvavimo ciklo etapo į kitą vis daugiau informacijos yra sužinoma apie defekto atsiradimo priežastį. Defektų valdymo sistemos turi komentarų rašymo ir pokyčių istorijos saugojimo funkcijas, kurios suteikia vertingos informacijos apie defekto būseną ir jo vienokio ar kitokio išsprendimo priežastis.

5. Skirtingos vartotojų grupės

Defektų valdymo sistema yra naudojama visų projekto funkcinių grupių: kokybės inžinierius kuria naujas defektų ataskaitas ir tikrina ištaisytus defektus; programuotojas dirba tik su naujomis defektų ataskaitomis; analitikas peržiūri pasiūlymus; projekto vadovas priskiria defektų ataskaitas programuotojams, o taip pat seka defektų kitimo tendencijas. Defektų valdymo sistemose gali būti sukuriamos vartotojų grupės, suformuotos atsižvelgiant į projekto funkcines grupes ir jų dažniausiai atliekamas veiklas.

6. Užklausų galimybės

Defektų valdymo sistemą naudoja vartotojų grupės, kurioms svarbi skirtinga informacija. Jei programuotojas paprastai dirba su jam priskirtomis naujomis defektų ataskaitomis, tai kokybės inžinieriui testuojančiam konkrečią sistemos dalį yra svarbūs visi su ta dalimi susiję duomenys. Defektų valdymo sistemos turi užklausų formavimo galimybes, kurios leidžia efektyviai filtruoti duomenis ir matyti tik tą informaciją, kuri yra reikalinga.

Defektų valdymo sistemą galima įdiegti keliais būdais: 1) nusipirkti; 2) nusipirkti ir pritaikyti pagal savo poreikius; 3) sukurti naują defektų valdymo sistemą patiems. Pasirinkimo būdą gali įtakoti tai, ar įmonė jau vykdo defektų valdymą. Jei defektų valdymo procesas yra jau apibrėžtas, įmonei verta kurti savo defektų valdymo sistemą arba pirkti pritaikomą individualiam procesui įrankį. UAB „Baltijos programinė įranga“ taip pat naudoja savo sukurtą defektų valdymo sistemą.

Programinės įrangos defektų analizė naudojant metrikas

Rakštis gali būti ištraukta, tik jei žinai, kur ji yra.
– Rabindranath Tagore

Programinės įrangos defektų valdymo sistemos ne tik padeda sutrumpinti ir valdyti defektų gyvavimo ciklą. Duomenų apie defektus analizė gali mums padėti įvertinti testuojamos sistemos kokybės lygį ar jos tinkamumą atiduoti vartotojui. Vienas iš testavimo tikslų yra defektų prevencija – priemonių, padedančių sumažinti klaidų kiekį vėlesniuose programinės įrangos etapuose, paieška ir taikymas. Analizuodami defektų valdymo sistemoje užregistruotus defektus, mes galime suprasti klaidų atsiradimo priežastis, o tai leidžia sumažinti tokių pačių klaidų pasikartojimą ateityje.

Defektų duomenų analizė yra atliekama naudojant metrikas – kiekybinius matus, parodančius, kiek sistema ar jos komponentas atitinka nustatytus atributus. Projektuose gali būti naudojamos standartinės programinės įrangos defektų metrikos (pavyzdžiui, defektų tankis – defektų skaičiaus ir kodo eilučių kiekio santykis) arba sukurti individualūs, pritaikyti projektui arba įmonės procesui matavimai.

Metrikos yra naudojamos ir UAB „Baltijos programinė įranga“, kuriant „MagicDraw“ produktą. Remiantis matavimais yra sekamas produkto kokybės lygis testavimo etapų metu, taip pat nustatoma, ar produktas atitinka išleidimo kriterijus. Sprendimus apie produkto kokybės lygį padeda priimti duomenys apie sukurtų, ištaisytų ir patikrintų defektų santykį ir jų kitimą. Informacija yra pateikiama naudojant grafikus (paveikslas Nr. 3), kurie yra puiki komunikacijos priemonė, kalbant apie produkto kokybę su kitais projekto nariais.


3 pav. Raportuotų ir ištaisytų defektų santykio sekimo grafiko pavyzdys

Tam, kad matavimai būtų tikslūs, defektų valdymo sistemos duomenys yra suderinami su informacija iš darbuotojų laiko valdymo sistemos.

Baigiamasis žodis

Natūralu, kad testavimo metu yra atrandami defektai. Norėdami, kad jie būtų ištaisyti, mes turime apie juos pranešti kitiems projekto nariams. Norėdami taisyti defektus efektyviai, mes turime juos valdyti. Norėdami tiksliai įvertinti testuojamos sistemos kokybę arba nebekartoti tokių pačių klaidų ateityje, naudodami įvairius matavimus mes turime analizuoti duomenis apie defektus. UAB „Baltijos programinė įranga“ visos šios veiklos yra vykdomos ir matoma jų teikiama nauda. Mes tikimės, kad šiame straipsnyje pateikta informacija Jums buvo aktuali ir naudinga.


BPI



Draudžiama platinti, skelbti, kopijuoti
informaciją su nurodyta autoriaus teisių žyma be redakcijos sutikimo.

Global electronic components distributor – Allicdata Electronics

Electronic component supply – „Eurodis Electronics“

LOKMITA – įvairi matavimo, testavimo, analizės ir litavimo produkcija

Full feature custom PCB prototype service

GENERAL FINANCING BANKAS

Mokslo festivalis „Erdvėlaivis Žemė

LTV.LT - lietuviškų tinklalapių vitrina

„Konstanta 42“

Technologijos.lt

Buitinė technika ir elektronika internetu žemos kainos – Zuza.lt

www.esaugumas.lt – apsaugok savo kompiuterį!

PriedaiMobiliems.lt – telefonų priedai ir aksesuarai

„Deinavos baldai“ — šeimos baldai


Reklama
‡ 1999–2024 © Elektronika.lt | Autoriaus teisės | Privatumo politika | Atsakomybės ribojimas | Reklama | Turinys | Kontaktai LTV.LT - lietuviškų tinklalapių vitrina Valid XHTML 1.0!
Script hook v, Openiv, Menyoo
gta5mod.net
Farming Simulator 2019 Mods, FS22 Mods, FS22 Maps
farmingsimulator19mods.fr
Optical filters, UV optics, electro optical crystals
www.eksmaoptics.com
Reklamos paslaugos
SEO sprendimai

www.addad.lt
Elektroninių parduotuvių optimizavimas „Google“ paieškos sistemai
www.seospiders.lt
FS22 mods, Farming simulator 22 mods,
FS22 maps

fs22.com
Reklama


Reklama