Zarządzanie jakością i metryki oprogramowania.pdf

Zapewnienie jakości

produktu informatycznego

• Pomiar jako główny element technik

zapewniania jakości

• Statystyczna kontrola procesu

(jedna z podstaw sukcesu gospodarczego Japonii)

Zarządzanie jakością

i metryki oprogramowania

Organizacja i Zarządzanie

Projektem Informatycznym

•Zapewnienie jakości – w oprogramowaniu:

zbiorczy termin odnoszący się do zestawu mgliście

zdefiniowanych działań, w związku z którymi

większość ludzi nie dostrzega żadnej potrzeby

dokonywania pomiarów

Jarosław Francik,

kwiecień 2002

NormanFenton

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Plan

Podstawowe parametry mierzalne

•Zapewnienie jakości produktu informatycznego

• Podstawowe parametry mierzalne

• Metryki oprogramowania

• Rejestrowanie problemów

• Wybrane normy i standardy

•Podsumowanie

•Koszt i nakład pracy

•Wydajność ludzi

•Oprogramowanie

•Niezawodność

•Wydajność

•Złożoność

•Dojrzałość procesu wytwarzania

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Zapewnienie jakości

produktu informatycznego

•Zapewnienie jakości (quality assurance):

Podstawowe parametry mierzalne

kryteria

czynniki

komunikatywność

dokładność

spójność

efektywność urządzeń

dostępność

kompletność

strukturalność

zwartość

niezal. od urządzeń

czytelność

autoopisowość

śladowość

użyteczność

użycie

Działanie związane z dostarczeniem wszystkim

zainteresowanym dowodów wystarczających

do powstania przekonania, że funkcja jakości

jest realizowana poprawnie

działanie

produktu

niezawodność

efektywność

wielokrotne

wykorzystanie

METRYKI

Zaplanowany i systematyczny ogół wszystkich działań

niezbędnych do wytworzenia odpowiednio silnego

zaufania, że element lub produkt odpowiada

ustalonym względem niego wymaganiom technicznym

norma IEEE 729 (1983)

pielęgnowalność

retrospekcja

produktu

przenośność

testowalność

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Plan

Metryki oprogramowania

Pomiary gęstości defektów

•Ws ęp: Elementy pomiaru oprogramowania

• Pomiary gęstości defektów

• Pomiary wielkości

• Pomiary złożoności

– nauka o programach Halsteada

– liczba cyclomatyczna McCabea

• Szacowanie nakładów

– model COCOMO

– modelowanie regresyjne

• Szacowanie funkcjonalności – metoda punktów funkcyjnych

•Dojrzałość procesu wytwarzania - model CMM

metryka gęstości defektów

liczba defektów odkrytych w C

rozmiar C

M =

Problemy:

–wyraża jakość programu czy może rzetelność testów?

– brak zgody co do definicji defektu

– brak zgody co do sposobu pomiaru rozmiaru kodu

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Elementy pomiaru oprogramowania

Metryki oprogramowania

Pomiary gęstości defektów

•Pomiar:

Proces, w którym atrybutom elementów świata

rzeczywistego przydzielane są liczby lub symbole

w taki sposób, aby scharakteryzować te atrybuty

według jasno określonych zasad. Jednostki

przydzielone atrybutom nazywamy ich miarą .

metryka gęstości defektów

liczba defektów odkrytych w C

rozmiar C

M =

•Mimo to:

–standard de facto

– formalne definicje na użytek wewnętrzny

–poszukiwanie możliwości porównania zewnętrznego

•LOC (LineofCode):jednostka miary długości

programu (ale nie złożoności ani nawet

rozmiaru)

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Elementy pomiaru oprogramowania

Metryki oprogramowania

Pomiary wielkości

• Elementy – przedmioty pomiaru:

–procesy

(projektownie, kodowanie, pierwsze trzy miesiące)

–produkty

(kod źródłowy, specyfikacja, modyfikacja, plan testów,

podręcznik użytkownika, pakiet instalacyjny)

–zasoby

(osoby, zespoły, oprogramowanie, infrastruktura, biura)

• Mierzone atrybuty:

–wewnętrzne

–zewnętrzne

• Metryki długości kodu źródłowego:

–LOC –LinesofCode

– KLOC – Kilo Lines of Code

– Liczba instrukcji

– Liczba instrukcji wykonywalnych (bez deklaracji)

– DSI – Delivered Source Instruction

•Problemy:

– mierzalne na etapie implementacji

– trudne do wcześniejszego prognozowania

– wielkość ≠długość (co ze złożonością?)

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Pomiary złożoności

Metryki oprogramowania

Szacowanie nakładów

Nauka o programach Halsteada

Halstead’ssoftwarescience

n 1 – iczba różnych operatorów

n 2 – iczba różnych operandów

N 1 –całkowita liczba wystąpień operatorów

N 2 –całkowita liczba wystąpień operandów

Wysiłek:

E = n 1 N 2 (N 1 + N 2 ) log(n 1 + n 1 ) / 2n 2

Czas:

T ≈ E / 18 [s]

oraz wiele innych wskaźników...

(http://yunus.hun.edu.tr/~sencer/complexity.html)

Model COCOMO

ConstructiveCostModel

nakład pracy = a * rozmiar b

[osobomiesiące]

rozmiar = KDSI –kilo DSI (DeliveredSourceInstructions)

system ograniczony

a = 2,4

b = 1,05

system częściowo wydzielony

a = 3,0

b = 1,12

system wbudowany

a = 3,6

b = 1,2

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Pomiary złożoności

Metryki oprogramowania

Szacowanie nakładów

Model COCOMO

ConstructiveCostModel

Liczba cyklomatyczna McCabe’a

McCabe’scyclomaticnumber

czas = a * nakład-pracy b

[miesiące]

M = liczba niezależnych dróg w schemacie blokowym

system ograniczony

a = 2,5

b = 0,38

M = liczba decyzji w programie + 1

system częściowo wydzielony

a = 2,5

b = 0,45

system wbudowany

a = 2,5

b = 0,32

• WADA:

– wymagana znajomość rozmiaru kodu

(jeden problem prognostyczny zastępujemy innym)

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Pomiary złożoności

Metryki oprogramowania

Szacowanie nakładów

•Problemy:

Model regresyjny

log E (nakład pracy)

Niektórzy twierdzą, że metryki te

nie są lepsze niż LOC!

10000

– nie pozwalają przewidzieć nakładu pracy,

niezawodności, pielęgnowalności

– mierzalne na etapie implementacji

–wciąż zbyt uproszczone (nie uwzględniają złożoności

przepływów danych, zagnieżdżenia itd..)

1000

100

log E = log a + b * log S

E = a * S b

log a

10K

100K

1000K

10000K

log S

(rozmiar)

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Szacowanie funkcjonalności

Metryki oprogramowania

Dojrzałość procesów wytwarzania

Metoda punktów funkcyjnych Albrechta

•Model dojrzałości procesu wytwarzania CMM

poziom 5:

optymalizujący

FP = UFC * TCF

poziom 4:

zarządzany

UFC –pierwotna liczba punktów funkcyjnych:

ważona liczba wejść, wyjść, logicznych plików głównych

(pamięć danych), plików interfejsowych i usług

TCF –współczynnik złożoności technicznej:

dodatkowy wpływ 14 innych czynników

poziom 3:

zdefiniowany

poziom 2:

powtarzalny

poziom 1:

początkowy

InternationalFunctionPoint UserGroup

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Szacowanie funkcjonalności

Rejestrowanie problemów

Metoda punktów funkcyjnych Albrechta

• Rodzaje problemów:

– usterka ( defekt ) – wada w produkcie powstała na

skutek błędu człowieka

– awaria –odstępstwo systemu od wymaganego

zachowania

– incydent –niepożądane zdarzenie zaobserwowane

podczas pracy systemu, mogące być skutkiem awarii

(ale niekoniecznie!)

• Metoda precyzyjna

• Prognoza uzyskiwana na podstawie specyfikacji

NIE TRZEBA PROGNOZOWAĆ ROZMIARU

•Zastosowania:

– metryka rozmiaru (zamiast LOC),

–wydajności programistów,

–metryki gęstości defektów

•Podważana sensowność użycia TCF

• WADA: metoda skomplikowana i trudna w użyciu

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Metryki oprogramowania

Dojrzałość procesów wytwarzania

Rejestrowanie problemów

• Cel: Poprawa procesów programowych

(SPI –SoftwareProcessImprovement)

•Model dojrzałości procesu wytwarzania

(CMM -CapabilityMaturityModel)

–CarnegieMellonUniv.

– zastosowanie: Dept. Obrony USA

• Rejestrowane informacje:

– Lokalizacja

– Czas

–Tryb

–Skutek

– Mechanizm

–Przyczyna

–Natężenie

–Koszt

ortogonalna baza cech

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Rejestrowanie problemów

Podsumowanie

•

• Raport o incydencie:

– Lokalizacja

– Czas

–Tryb

–Skutek

– Mechanizm

–Przyczyna

–Natężenie

–Koszt

• Rola metryk w zarządzaniu jakością

• Cele:

– polepszenie oceny nakładów na produkcję

oprogramowania

–ocena wydajności programistów

–ocena i kontrola jakości końcowego produktu

– id komputera, nr seryjny, platforma

– data i godzina wystąpienia incydentu

– komunikat o błędzie

– np. utrata danych, załamanie systemu

– np. poprzedzające komendy klawiatury

– próba diagnozy

– nieznaczny / powazny / krytyczny

– koszt naprawy + utraconych danych

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Rejestrowanie problemów

•

• Raport o usterce:

– Lokalizacja

– Czas

–Tryb

–Skutek

– Mechanizm

–Przyczyna

–Natężenie

–Koszt

– id modułu lub dokumentu

– faza w której usterkę wprowadzono

– sposób wykrycia usterki

– opis awarii będącej skutkiem usterki

– jak usterka powstała i jak ją wykryto

–na czym polegał błąd człowieka

–czy może prowadzić do awarii (jakiej)

– koszt lokalizacji i skorygowania

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Wybrane normy i standardy

• ISO 9001 : Standard kontroli jakości

nie odnosi się do żadnej konkretnej branży

• ISO 9003

wersja ISO 9001 dotycząca oprogramowania

• TickIT

uregulowanie brytyjskie, oparte na ISO 9003

Institute of Informatics, Silesian University of Technology, Gliwice, Poland

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: