Inzynieria Oprogramowania

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

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

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

Slajd 9

Techniki szacowania nakładów

pracy 1/2

•

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

- bazują na

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

Slajd 10

Techniki szacowania nakładów

pracy 2/2

•

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

(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

- dzieli się przedsięwzięcie na

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

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

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ą

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.

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

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)

Slajd 19

Metoda COnstructive COst MOdel

(COCOMO) 2/2

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

•

Ł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

(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

(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ń

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)

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

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

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

4
5

7
4

Złożo

6
7

15
10

Wagi przypisywane elementom zależą od ich typu

UFP = w

+ w

gdzie w

- wagi czynników, e

- liczności elementów

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

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

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

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

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

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

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

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 są

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

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

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

Document Outline