5 Metryki jakosci cwiczenia

background image

Metryki jakości oprogramowania – ćwiczenia

Kryteria jakości, a niedociągnięcia

w oprogramowaniu

Wyznaczanie poziomu jakości

serwisu oprogramowania

Wyznaczanie wskaźnika problemów

klienta

Porównywanie awaryjności

oprogramowań

Wyznaczanie ilości błędów i

defektów w oprogramowaniu

background image

Ć

W. 0 – kryteria jakości oprogramowania

Firma ABC wyprodukowała oprogramowanie, jednak
zidentyfikowano w nim nast
ępujące niedociągnięcia:

- brak modułowej budowy programu

- brak kreatora instalacji programu

- brak szyfrowania hasła podczas procedury logowania

- wykorzystanie nieoptymalnych algorytmów

- niemożliwość odzyskania danych utraconych w wyniku
awarii programu

- zbyt lakoniczna dokumentacja

Na niekorzyść jakich kryteriów jakości zewnętrznej i
wewn
ętrznej oprogramowania świadczą znalezione ubytki?
Do ka
żdego kryterium podaj najlepiej odpowiadającą mu
charakterystyk
ę szczegółową.

background image

Ć

W. 0 – kryteria jakości oprogramowania

Kolejnym niedociągnięciom przyporządkujemy
odpowiednie kryteria i charakterystyki, na niekorzy
ść
których one wpływaj
ą:

- brak modułowej budowy programu

(PIELĘGNOWALNOŚĆ ---> modyfikowalność)

- brak kreatora instalacji programu

(PRZENOŚNOŚĆ ---> instalowalność)

- brak szyfrowania hasła podczas procedury logowania

(FUNKCJONALNOŚĆ ---> bezpieczeństwo)

background image

Ć

W. 0 – kryteria jakości oprogramowania

- wykorzystanie nieoptymalnych algorytmów

(SKUTECZNOŚĆ ---> przepustowość)

- niemożliwość odzyskania danych utraconych w wyniku
awarii programu

(NIEZAWODNOŚĆ ---> odtwarzalność)

- zbyt lakoniczna dokumentacja

(UŻYTECZNOŚĆ ---> zrozumiałość)

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Firma ABC do tej pory sprzedała łącznie 200 licencji na
oprogramowanie GAMMA.

Od 1 stycznia do 31 marca zgłoszono 42 problemy - w tym
czasie 25 tych problemów naprawiono z pozytywnym
skutkiem.

Poza tym 2 wydane poprawki nie naprawiły problemów, a 5
wydanych poprawek naprawiło zgłoszony problem ale
spowodowało wyst
ąpienie innego. Pozostałych problemów
w danym czasie nie udało si
ę naprawić.

Wyznacz i zinterpretuj następujące metryki:

- wskaźnik problemów klienta

- wskaźnik zarządzania opóźnieniem napraw (dla LCL=65%)

- odsetek źle wykonanych napraw

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Obliczymy najpierw wskaźnik problemów klienta (PUM):

Wartość wskaźnika problemów klienta jest stosunkowo
niska (poni
żej 10%), a więc akceptowalna –
oprogramowanie nie sprawia zbyt wielu problemów
u
żytkownikom.

42

problemów

wykrytych

liczba

=

600

3

200

licencji

miesiecy

liczba

=

=

%

7

07

,

0

600

42

=

=

=

PUM

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Sprawdźmy teraz czy zgłaszane przez użytkowników
problemy s
ą na bieżąco rozwiązywane (wskaźnik BMI):

Do problemów rozwiązanych zaliczamy tylko te naprawy,
które rozwi
ązały zgłoszony problem nie powodując innego.

25

problemów

ch

rozwiazany

liczba

=

42

problemów

h

zgloszonyc

liczba

=

%

60

6

,

0

42

25

=

=

BMI

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Wartość wskaźnika zarządzania opóźnieniem napraw jest
umiarkowanie wysoka (im wi
ększa, tym lepiej) i wynosi 60%.

Jednak z drugiej strony oznacza to, że 40% problemów nie
zostało rozwi
ązanych w ciągu analizowanego okresu (3
miesi
ące). Dla zwiększenia dokładności analizy należałoby
sprawdzi
ć, czy są to problemy zgłoszone pod koniec tego
okresu – wówczas mo
że to podwyższyć ocenę jakości
procesu serwisowania.

Dodatkowo wartość BMI jest mniejsza niż założona przez
organizacj
ę ABC dolna granica kontrolna (BMI < LCL=65%),
wi
ęc należy niezwłocznie przyspieszyć proces efektywnego
rozwi
ązywania problemów klienta.

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Sprawdźmy również ile spośród wykonanych napraw
zostało
źle wykonanych, obliczając odsetek źle
wykonanych napraw.

Ź

le wykonane naprawy to takie, które nie rozwiązują

głównego problemu, bądź rozwiązując go powodują
wyst
ąpienie innego.

Odsetek źle wykonanych napraw wynosi

7

5

2

napraw

h

wykonanyc

le

liczba

=

+

=

ź

32

7

25

napraw

h

wykonanyc

liczba

=

+

=

%

22

22

,

0

32

7

=

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Zatem 22% wszystkich napraw w ciągu analizowanego
okresu zostało
źle wykonanych.

Wartość ta powinna być bardzo bliska zero, gdyż każda źle
wykonana naprawa bardziej psuje jako
ść (oraz wizerunek
firmy w oczach klienta) ni
ż niewykonanie naprawy w
terminie.

W związku z tym w badanej firmie należałoby poświęcić
wi
ęcej uwagi analizie zgłoszonych problemów, w celu
prawidłowego ich rozwi
ązywania.

background image

Ć

W. 1 – problemy klienta i ich rozwiązywanie

Podsumowując, 60% problemów rozwiązano poprawnie i w
terminie (BMI=60%), jednak jest to za mało w stosunku do
ustalonego limitu kontrolnego (LCL=65%). Natomiast
pozostałe 40% problemów w dalszym ci
ągu z różnych
powodów czeka na napraw
ę.

Końcowy wniosek analizy jest taki, że w organizacji ABC
nale
ży zdecydowanie podnieść jakość serwisowania
oprogramowania.

background image

Ć

W. 2 – czas pracy do wystąpienia awarii

Oprogramowanie ALFA stworzone przez firmę ABC w fazie
testowania ma awari
ę średnio przez 0,25 sekundy w ciągu
minuty.

Natomiast oprogramowanie BETA ma
prawdopodobie
ństwo bezawaryjności równe 0,996.

Które oprogramowanie na obecnym etapie rozwoju jest
bardziej niezawodne?

background image

Ć

W. 2 – czas pracy do wystąpienia awarii

W celu porównania niezawodności oprogramowania ALFA
oraz BETA nale
ży w obu przypadkach wyrazić poziom
awaryjno
ści w tych samych jednostkach.

Niech będzie to prawdopodobieństwo wystąpienia awarii.
Obliczmy zatem prawdopodobie
ństwo wystąpienia awarii
dla oprogramowania ALFA:

0042

,

0

240

1

sek

60

sek

25

,

0

min

1

sek

25

,

0

)

(

=

=

=

ALFA

P

awaria

background image

Ć

W. 2 – czas pracy do wystąpienia awarii

Wyznaczmy teraz prawdopodobieństwo awaryjności
oprogramowania BETA:

Zatem prawdopodobieństwo wystąpienia awarii jest
nieznacznie wi
ększe dla oprogramowania ALFA, więc
bardziej niezawodne jest aktualnie oprogramowanie BETA
(chocia
żżnica jest bardzo niewielka).

004

,

0

996

,

0

1

)

(

1

)

(

=

=

=

BETA

P

BETA

P

bezawar

awaria

0042

,

0

)

(

=

ALFA

P

awaria

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

W przykładowym "miniaturowym" programie napisanym w
j
ęzyku PHP:

- popraw wszystkie błędy składniowe (te, które
uniemo
żliwiają kompilację)

- następnie wyznacz metrykę częstości występowania
defektów

- wskaż w kodzie te defekty, które spowodują awarię
programu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

ędy składniowe w programie napisanym w konkretnym
j
ęzyku uniemożliwiają kompilację i uruchomienie
programu. Jednak nie s
ą one traktowane jako defekty.

Defekty są bowiem nieprawidłowościami występującymi
podczas działania programu. Mo
żna je zatem analizować
dopiero po uruchomieniu programu, a wi
ęc po poprawieniu
ędów składniowych.

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

Po poprawieniu błędów składniowych należy rozpocząć
poszukiwanie defektów, czyli nieprawidłowo
ści (anomalii)
w działaniu programu.

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

Częstość defektów wyliczamy przy pomocy wzoru:

Jako miarę sposobności popełnienia defektu można
przyj
ąć liczbę linii kodu. Jednak policzenie wszystkich linii
jako sposobno
ści popełnienia błędu byłoby nieobiektywne.

Dlatego warto policzyć tylko linie z konkretnymi
instrukcjami, a tak
że deklaracje funkcji (bez nawiasów
klamrowych, komentarzy, pustych linii).

background image

Ć

W. 3 – błędy i defekty w oprogramowaniu

Zgodnie z omówionym podejściem można wyróżnić od 21
do 24 linii kodu – przyjmijmy,
że będą to 24 linie.

Po poprawieniu błędów składniowych w kodzie znaleziono
12 defektów.

Dlatego częstość defektów wynosi

Zatem częstość występowania defektów jest bardzo duża –
połowa programu (w sensie kodu
źródłowego) jest
nieprawidłowo napisana. Program bezwzgl
ędnie wymaga
poprawy.

W praktyce, tak wysoki poziom występowania defektów
jest usprawiedliwiony tylko w przypadku, gdy autorem
programu jest osoba ucz
ąca się programować.

%

50

5

,

0

24

12

=

=


Wyszukiwarka

Podobne podstrony:
5 Metryki jakosci cwiczenia id 40274
4. Zarządzanie Jakością - ćwiczenia - Kaizen - Fabryka samochodów, Zarządzanie UG, Sem. III, Zarząd
Zarządzanie jakością ćwiczenia, Uczelnia, Zarządzanie jakością
4 Metryki jakosci id 37754 Nieznany (2)
Inżynieria jakości Ćwiczenia 1
metody jakościowe ćwiczenia, Socjologia I rok
5. Zarządzanie Jakością - ćwiczenia - Dom Jakości, Zarządzanie UG, Sem. III, Zarządzanie jakością
3. Zarządzanie Jakością - ćwiczenia - Normalizacja 6 Sigma, Zarządzanie UG, Sem. III, Zarządzanie ja
Procedura reklamacji obuwia, Studia - Politechnika Śląska, Zarządzanie, I STOPIEŃ, Zarządzanie jakoś
Ocena jakosci, cwiczenia1, PROBLEMATYKA NORMALIZACYJNA:
Ocena jakosci, cwiczenia5, WĘGLOWODANY - to związki organiczne występujące w roślinie
Ocena jakosci, cwiczenia6, Oznaczanie kwasowości ogólnej w produkcji ogrodniczej
Zarządzanie jakością â Ćwiczenia44
Zarządzanie Jakością Ćwiczenia 2
Zarządzanie jakością ćwiczenia
1 ćwiczenie (Analiza jakościowa wody) OZNACZANIE CHLORKÓW I SIARCZANÓW
notatki, STUDIA, WZR I st 2008-2011 zarządzanie jakością, podstawy ochrony środowiska, Zachowania Or

więcej podobnych podstron