22(45) Zapewnienie jakości oprogramowaniaid 29565 ppt

background image

Inżynieria oprogramowania

Zapewnienie jakości

oprogramowania

i metryki oprogramowania

background image

Slajd 2

Plan wykładu

Jakość oprogramowania
Liczba cyklomatyczna (McCabe’s

cyclomatic number)

Metoda COCOMO
Analiza Punktów Funkcyjnych
Metoda Punktów Przypadków Użycia
Model dojrzałości procesów

wytwórczych (CMM)

background image

Slajd 3

Jakość

oprogramowania

background image

Slajd 4

Jakość oprogramowania 1/2

Zapewnienie jakości jest rozumiane jako

zespół działań zmierzających do wytworzenia u
wszystkich zainteresowanych

przekonania

przekonania, że

dostarczony produkt właściwie realizuje swoje
funkcje
i odpowiada aktualnym wymaganiom i
standardom

• Problem jakości, oprócz mierzalnych

czynników technicznych, włącza dużą liczbę
niemierzalnych obiektywnie czynników
psychologicznych

background image

Slajd 5

Jakość oprogramowania 2/2

• Podstawą obiektywnych wniosków co do jakości

oprogramowania są

pomiary

pomiary pewnych parametrów

użytkowych (niezawodności, szybkości, itd.) w realnym
środowisku
, np. przy użyciu metod statystycznych

Obiektywne pomiary cech produktów

programistycznych są utrudnione lub niemożliwe

Jakość gotowych produktów programistycznych jest

bardzo trudna do zmierzenia ze względu na ich
złożoność, wieloaspektowość oraz niską
przewidywalności wszystkich aspektów ich
zastosowań
w długim czasie

background image

Slajd 6

Miary Jakości Oprogramowania

• Liczba błędów
• Liczba linii kodu
• Gęstość błędów (Liczba błędów/rozmiar

kodu)

• Liczba instrukcji wykonywalnych
• Złożoności algorytmów
• Koszty (Metoda COCOMO – osobo-

miesiące)

background image

Slajd 7

Elementy pomiaru oprogramowania

background image

Slajd 8

Modele i miary wydajności

Wydajność

Wartość

Koszt

Jakość

Ilość

Personel

Zasoby

Złożoność

Niezawodność

Defekty

Wielkość

Funkcjonalność

Czas

Pieniądze

Sprzęt

Oprogramowanie

Ograniczenia
środowiskowe

Trudność
problemu

Czynniki
wpływające
na ogólną
wydajność

Mylące, wręcz niebezpieczne jest zastępowanie wielu miar
jedną miarą, np. długością wyprodukowanego kodu

background image

Slajd 9

Techniki szacowania nakładów

pracy 1/2

Modele algorytmiczne

Modele algorytmiczne

- opis przedsięwzięcia

za pomocą charakteryzujących go
atrybutów
(liczbowych) i na tej bazie
wyliczenie (np. prosta formuła
matematyczna) nakładów

Ocena przez ekspertów

Ocena przez ekspertów

- bazują na

własnym doświadczeniu zdobytym przy
realizacji innych projektów

background image

Slajd 10

Techniki szacowania nakładów

pracy 2/2

Ocena przez analogię

Ocena przez analogię

- przy założeniu gromadzenia

informacji o uprzednio wykonanych projektach; wyszukuje
się podobne systemy poprzednio zrealizowane
i
wykorzystuje nakłady poniesione na ich stworzenie

Wycena dla wygranej

Wycena dla wygranej

(ang. pricing to win) - na podstawie

oceny możliwości klienta oraz przewidywanych
działań konkurencji
; opiera się na prawie Parkinsona -
przedsięwzięcia są wykonywane przy założonych kosztach
(jakie by one nie były)

Szacowanie wstępujące

Szacowanie wstępujące

- dzieli się przedsięwzięcie na

mniejsze zadania, które łatwiej oszacować; koszt
całości jest ich sumą (ew. z narzutem na integrację)

background image

Slajd 11

Modele algorytmiczne szacowania

nakładów 1/2

• Większość modeli przyjmuje, że jednym z

istotnych atrybutów jest

rozmiar systemu

rozmiar systemu,

mierzony np. liczbą instrukcji (linii) kodu
(ang. Lines Of Code - LOC), KLOC (ang. Kilo-
LOC), KDSI (ang. Kilo (thousand) of
Delivered Source code Instructions
)

Najlepiej jest stosować zestawy metryk,

co pozwala zmniejszyć błędy pomiaru

background image

Slajd 12

Modele algorytmiczne szacowania

nakładów 2/2

Metryki powinny być wykorzystywane jako metody

wspomagania ekspertów (stosowane
formalistycznie mogą być groźne)

• Pomimo pochodzenia empirycznego, metryki

skutecznie pomagają w szybkiej i mniej
subiektywnej ocenie oprogramowania

Żadna metoda przewidywania kosztów nie jest

doskonała i jest oparta na szeregu arbitralnych
założeń; niemniej dla celów planowania tego rodzaju
metody stają się koniecznością

background image

Slajd 13

wrażliwość na błędy,

możliwości testowania,

częstotliwość

występowania awarii,

dostępność systemu,

propagacja błędów,

ilość linii kodu, złożoność

kodu, złożoność programu,

złożoność obliczeniową,

funkcjonalną, modułową,

łatwość implementacji,

rozmiar dokumentacji,

ilość zadań wykonanych

terminowo i po terminie,

Różnorodne metryki uwzględniają m.in.
następujące aspekty

współzależność zadań,

wielkość i koszt projektu,

czas trwania projektu,

zagrożenia projektu

(ryzyko),

czas gotowości produktu,

kompletność wymagań,

kompletność planowania,

stabilność wymagań,

odpowiedniość

posiadanych zasobów
sprzętowych, materiałowych
i ludzkich,

efektywność zespołu,

efektywność poszczególnych
osób.

background image

Slajd 14

Miary Jakości Oprogramowania

background image

Slajd 15

Liczba

cyklomatyczna

(McCabe’s cyclomatic

number)

background image

Slajd 16

Liczba cyklomatyczna

(McCabe’s cyclomatic number)

• Zaproponowana przez McCabe’a; odnosi się do schematu

blokowego programu i jest równa liczbie niezależnych
dróg w takim schemacie
(liczba decyzji w programie +1)

• Krytykowana m.in. za nieuwzględnienie złożoności

przepływów danych lub złożoności programów
niestrukturalnych

Program P jest reprezentowany przez graf G, gdzie:
e - liczba krawędzi
n - liczba węzłów
d - liczba węzłów decyzyjnych

v(P)=e-n+2
v(P)=d+1

v(P) - liczba niezależnych ścieżek w G

background image

Slajd 17

Metoda COCOMO

background image

Slajd 18

Metoda COnstructive COst MOdel

(COCOMO) 1/2

Powstała w oparciu o dane z rzeczywistych

projektów, realizowanych tradycyjnie (np. bez
narzędzi CASE)

Wymaga

oszacowania liczby instrukcji

, z których

będzie składał się system (co może być tak samo
trudne jak oszacowanie nakładów)

background image

Slajd 19

Metoda COnstructive COst MOdel

(COCOMO) 2/2

Wyróżnia się trzy klasy przedsięwzięć:

Łatwe

Łatwe

(organiczne, ang. organic) - wykonywane przez

stosunkowo małe zespoły, złożone z osób o podobnych
wysokich kwalifikacjach; dziedzina oraz wykorzystywane
metody i narzędzia są dobrze znane

Pośrednie

Pośrednie

(półoderwane, ang. semi-detached) - członkowie

zespołu różnią się stopniem zaawansowania; pewne
aspekty dziedziny problemu lub wykorzystywane narzędzia
nie są dobrze znane

Trudne

Trudne

(osadzonych, ang. embedded) - przedsięwzięcia

realizujące systemy o bardzo złożonych wymaganiach;
dziedzina problemu, stosowane narzędzia i metody mogą
być w dużej mierze nieznane
; członkowie zespołu nie
mają doświadczenia
w realizacji podobnych zadań

background image

Slajd 20

Wady metody COCOMO 1/2

• Liczba linii kodu jest znana dokładnie dopiero

wtedy, gdy system jest napisany a szacunki
mogą być (i zwykle są ) obarczone bardzo
poważnym błędem
(niekiedy ponad 100%)

• Określenie “linii kodu źródłowego” inaczej

wygląda dla każdego języka
programowania (np. 1 linia w Smalltalk’u jest
równoważna 10-ciu linii w C; dla języków
4GL ten stosunek może być nawet 1000:1)

background image

Slajd 21

Wady metody COCOMO 2/2

• Koncepcja oparta na liniach kodu źródłowego natomiast

całkowicie nie przystaje do współczesnych narzędzi
programistycznych
, np. opartych o programowanie
wizyjne

Opiera się tylko na długości kodu i nie bierze w ogóle

pod uwagę funkcjonalności ani złożoności produktu

Kwalifikacja przedsięwzięcia do predefiniowanych

klas oraz dobór czynników modyfikujących jest
trudny
, a ewentualne błędy mogą prowadzić do
znacznych rozbieżności pomiędzy oczekiwanym i
rzeczywistym kosztem

background image

Slajd 22

Analiza Punktów

Funkcyjnych

background image

Slajd 23

Analiza Punktów Funkcyjnych 1/6

Metoda analizy punktów funkcyjnych (ang.

functional points - FP), została opracowana
przez Albrechta; łączy ona własności
metody, badającej rozmiar projektu
programu z możliwościami metody
badającej produkt programowy (jego
funkcjonalność)

FP = UFP * TCF

background image

Slajd 24

Analiza Punktów Funkcyjnych 2/6

Liczbę pierwotną punktów funkcyjnych (UFP) wylicza się

korzystając z następujących danych:

Wejścia użytkownika

:

obiekty wejściowe wpływające

na dane w systemie

Wyjścia użytkownika

: obiekty wyjściowe związane z

danymi w systemie

Zbiory danych wewnętrzne

: liczba wewnętrznych

plików roboczych

Zbiory danych zewnętrzne

: liczba plików

zewnętrznych zapełnianych przez produkt programowy

Zapytania zewnętrzne

: interfejsy z otoczeniem

programu

background image

Slajd 25

Pierwotne punkty funkcjonalne 3/6

Czynnik złożoności
Wejścia użytkownika (I)
Wyjścia użytkownika (O)
Zbiory danych
wewnętrzne (l)
Zbiory danych
zewnętrzne (E)
Zapytania zewnętrzne
(F)

Prost

y
3
4
7
5
3

Średn

i

4
5

10

7
4

Złożo

ny

6
7

15
10

6

Wagi przypisywane elementom zależą od ich typu

UFP = w

i

*e

i

+ w

o

*e

o

+ w

e

*e

e

+ w

l

*e

l

+

w

f

*e

f

gdzie w

x

- wagi czynników, e

x

- liczności elementów

background image

Slajd 26

Współczynnik złożoności technicznej

(TCF) 4/6

TCF - liczba ustalana na podstawie wpływu 14

czynników (0.65<=TCF<=1.35 ):

1. występowanie urządzeń komunikacyjnych
2. rozproszenie
przetwarzania
3. długość czasu oczekiwania na odpowiedź

systemu

4. stopień obciążenia sprzętu istniejącego
5. częstotliwość wykonywania dużych transakcji
6. wprowadzanie danych w trybie bezpośrednim
7. wydajność użytkownika końcowego

background image

Slajd 27

Współczynnik złożoności technicznej

(TCF) 5/6

8. aktualizacja danych w trybie bezpośrednim
9. złożoność przetwarzania danych
10. możliwość ponownego użycia programów

w innych zastosowaniach

11. łatwość instalacji
12. łatwość obsługi systemu
13. rozproszenie terytorialne
14. łatwość wprowadzania zmian -

pielęgnowania systemu

background image

Slajd 28

Wykorzystanie punktów funkcyjnych

6/6

Ocena złożoności realizacji systemów
Audyt projektów
Szacowanie liczby testów
• Ocena jakości pracy i wydajności zespołów ludzkich
• Ocena stopnia zmian, wprowadzanych przez

użytkownika na poszczególnych etapach budowy
systemu informatycznego

Prognozowanie kosztów pielęgnacji i rozwoju

systemów

Porównanie i ocena różnych ofert dostawców

oprogramowania pod kątem merytorycznym i
kosztowym

background image

Slajd 29

Szacowanie przez Punkty Funkcyjne

• Szacowanie liczby linii kodu w aplikacji

– 1 FP = 125 instrukcji w C

background image

Slajd 30

Użyteczność Punktów

Funkcyjnych

Szacowanie czasu projektu

– czas = FP x czas na jeden FP

Szacowanie ilość błędów

– Ilość błędów na jeden FP

Umowy

– Mogą zawierać cenę za jeden FP
– Śledzenie postępu – ile FP zostało już

spełnionych

background image

Slajd 31

Metoda Punktów Przypadków

Użycia

background image

Slajd 32

Metoda Punktów Przypadków Użycia –

Use Case Points (UCP)

• Bazuje na diagramach Use Case
• Wymaga:

– Starannego modelowania aktorów
– Ostrożności w oznaczaniu powiązań

między poszczególnymi przypadkami
użycia

– Odpowiedniego poziomu

szczegółowości modelu

background image

Slajd 33

Metoda Punktów Przypadków Użycia

Klasyfikacja aktorów

Aktor prosty - zewnętrzny wobec

analizowanego, komunikujący się przez jeden z

interfejsów programistycznych (Waga – 1)

Aktor średnio-złożony - system zewnętrzny,

dostępny przez protokół z rodziny TCP/IP, HTTP

lub podobny; również zbiory danych (Waga – 2)

Aktor złożony - zazwyczaj użytkownik końcowy,

komunikujący się z systemem poprzez interfejs

graficzny lub stronę WWW (Waga – 3)

Suma nieskorygowanych wag aktorów

(UAW)

– Suma wszystkich aktorów, pomnożona przez

współczynniki ich wag

background image

Slajd 34

Metoda Punktów Przypadków Użycia

Klasyfikacja przypadków użycia

Prosty przypadek użycia – do trzech transakcji

(Waga – 5)

Średnio-złożony przypadek użycia od czterech

do siedmiu transakcji (Waga – 10)

Złożony przypadek użycia – więcej niż siedem

transakcji (Waga – 15)

• Możliwa również poprzez

zliczenie klas potrzebnych

do obsługi przypadku

Prosty przypadek użycia - nie więcej niż pięć klas

(Waga – 5)

Średnio-złożony przypadek użycia - od pięciu do

dziesięciu klas (Waga – 10)

Złożony przypadek użycia - powyżej dziesięciu

klas (Waga – 15)

Suma nieskorygowanych wag przypadków użycia

(UUCW)

– Suma wszystkich przypadków, pomnożona przez

współczynniki ich wag

background image

Slajd 35

Metoda Punktów Przypadków Użycia

•Modyfikacja przez czynniki techniczne

Technical Complexity Factor(TCF) = 0,6 + (0,01 * Wagowa suma

powyższych)

background image

Slajd 36

Metoda Punktów Przypadków Użycia

• Modyfikacja przez czynniki środowiskowe

Environmental Factor(EF) = 1,4 + (-0,33 * Wagowa suma

powyższych)

background image

Slajd 37

Metoda Punktów Przypadków Użycia

• Ostatecznie poszukiwany rezultat

UCP = UUCP * TCF * EF

• Przyjmuje się, że

1 UCP = 20

osobogodzin

pracy programisty

background image

Slajd 38

Model dojrzałości procesów

wytwórczych (CMM)

background image

Slajd 39

Dojrzałość procesów wytwórczych

Niedojrzałość

Dojrzałość

Improwizacja podczas

procesu wytwórczego

 Proces jest wyspecyfikowany,

ale specyfikacja nie jest
stosowana

Doraźne reagowanie w

sytuacji kryzysów

Harmonogram i budżet

przekraczane

Funkcjonalność jest

stopniowo okrajana

Jakość produktu jest niska
Brak obiektywnych

kryteriów oceny

 Zdolność do budowy

oprogramowania jest cechą
organizacji
a nie personelu

 Proces jest zdefiniowany,

znany i wykorzystywany

 Proces jest obserwowany i

ulepszany

 Prace są planowane i

monitorowane

Role i odpowiedzialności

są zdefiniowane

 Obiektywna, ilościowa

ocena

background image

Slajd 40

Poziomy dojrzałości wytwórców 1/2

Wyróżniono 5 poziomów dojrzałości wytwórców

(poczynając od p. najniższego):

początkowy

początkowy (1)

- proces chaotyczny, nie

istnieją żadne standardy, decyzje
podejmowane ad hoc
; może dotyczyć nawet
firm o dobrym zaawansowaniu technicznym

powtarzalny

powtarzalny (2)

proces

zindywidualizowany; przedsięwzięcia
wykonywane w podobny sposób (standardy de
facto
); standardy nie są udokumentowane
i nie istnieją ścisłe procedury kontroli

background image

Slajd 41

Poziomy dojrzałości wytwórców 2/2

zdefiniowany

zdefiniowany (3)

- proces zinstytucjonalizowany;

standardy postępowania są zdefiniowane, sformalizowane
i ich stosowanie jest kotrolowane

zarządzany

zarządzany (4)

- proces nie tylko podlega kontroli ale

jest również mierzony w sposób ilościowy; informacje
zwrotne wykorzystywane są do sterowania procesem

optymalizujący

optymalizujący (5)

- standardy są ciągle uaktualniane;

informacje zwrotne wpływają na ulepszenie procesu;
standardy zawierają elementy pozwalające na dostrojenie
procesu do aktualnych potrzeb

Niewiele firm uzyskało poziom 3-ci, umożliwiający

dostarczanie oprogr. dla Dep. Obrony; tylko IBM w
zakresie oprogr. promu kosmicznego dla NASA uzyskał
poziom 5-ty

background image

Slajd 42

O czym był wykład?

Jakość oprogramowania
Liczba cyklomatyczna (McCabe’s

cyclomatic number)

Metoda COCOMO
Analiza Punktów Funkcyjnych
Metoda Punktów Przypadków Użycia
Model dojrzałości procesów

wytwórczych (CMM)


Document Outline


Wyszukiwarka

Podobne podstrony:
14(45) Proces Tworzenia oprogramowaniaid 15602 ppt
1(45) Przedmiot i cele inżynierii oprogramowaniaid 10176 ppt
standardy oprogramowania, Zapewnienie jakości
21(45) Testowanie, weryfikacja i walidacja oprogramowaniaid 29151 ppt
1(45) Przedmiot i cele inżynierii oprogramowaniaid 10176 ppt
informatyka inzynieria oprogramowania jak zapewnic jakosc tworzonym aplikacjom bogdan bereza jarocin
08 Prototypowanie oprogramowaniaid 7587 ppt
Sytemy zapewnienia jakości`, Systemy Zapewnienia Jakości, Systemy Zapewnienia Bezpieczeństwa Zdrowot
11(45) Diagram interakcji cz2id 12714 ppt
33 Algorytmy zapewnienia jakości i niezawodności mikrosystem
10(45) Diagramy interakcjiL cz1id 11241 ppt

więcej podobnych podstron