©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 1

Szacowanie kosztu
oprogramowania



Przedstawienie

metod

szacowania

kosztu

i

pracy

niezbędnej

do

wyprodukowania
oprogramowania

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 2

Cele



Znać podstawy szacowania kosztów i ustalania
ceny oprogramowania oraz złożone związki
między tymi kwestiami.



Znać trzy miary stosowane do szacowania
produktywności programowania.



Zdawać sobie sprawę, że do szacowania kosztów
i harmonogramu tworzenia oprogramowania
trzeba stosować wiele różnych metod;



Znać

zasady

modelu

COCOMO

2

do

algorytmicznego szacowania kosztu.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 3

Zawartość



Produktywność



Metody szacowania



Modelowanie algorytmiczne kosztów



Czas trwania przedsięwzięcia i praca
personelu

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 4

Pytania



Ile pracy trzeba na ukończenie
czynności?



Ile czasu kalendarzowego trzeba na
ukończenie czynności?



Jaki jest całkowity koszt czynności?

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 5

Tworzenie
oprogramowania



Wyznacza się na podstawie trzech
następujących parametrów:

•

koszt

sprzętu

i

oprogramowania

wraz

z

pielęgnacją

•

koszty podróży i szkoleń

•

koszt pracy (zapłata inżynierom oprogramowania).

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 6

Składniki całkowitego
kosztu pracy



Koszt udostępnienia, ogrzania i oświetlenia
przestrzeni biurowej.



Koszt personelu pomocniczego, na przykład
księgowe, sekretarki, sprzątaczki i technicy.



Koszt sieci i telekomunikacji.



Koszt udogodnień centralnych, takich jak
biblioteka, pomieszczenia rekreacyjne.



Koszt ubezpieczenia społecznego, m.in.
świadczenia dla pracowników, takie jak
emerytury i ubezpieczenie zdrowotne.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 7

Czynniki wpływające na
cenę oprogramowania

Czynnik

Opis

Okazja rynkowa

Przedsiębiorstwo produkujące może podać niską cenę, ponieważ chce

zaistnieć w nowym segmencie rynku oprogramowania. Zgoda na mały
zysk z jednego przedsięwzięcia może dać okazję do późniejszych zysków.
Zdobyte doświadczenie może umożliwić tworzenie nowych produktów.

Niepewność

Jeśli przedsiębiorstwo nie jest pewne swoich szacunków kosztów, to może

oszacowania

zwiększyć cenę o pewien czynniki rezerwowy powyżej swego zwykłego

kosztów

zysku.

Warunki umowy

Klient może wyrazić zleceniobiorcy zgodę na zatrzymanie prawa własności

kodu źródłowego i wielokrotne wykorzystanie go w następnych
przedsięwzięciach. Ustalona cena może być wówczas niższa niż w wypadku
przekazywania kodu źródłowego klientowi.

Płynność

Jeśli wymagania przypuszczalnie będą się zmieniać, to firma może obniżyć

wymagań

cenę, aby zdobyć kontrakt. Po przyznaniu kontraktu można zażądać

wysokich cen za zmiany wymagań.

Kondycja

Firmy produkujące w złej kondycji finansowej mogą obniżać swoje ceny w

finansowa

celu zdobycia kontraktu. Od wypadnięcia z rynku lepszy jest mniejszy niż
zwykle zysk lub nawet strata.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 8



W wypadku budowy oprogramowania istnieje wiele

różnych rozwiązań o różnych atrybutach.



Jedno rozwiązanie może działać bardziej efektywnie,

podczas gdy inne jest bardziej czytelne i łatwiejsze do

pielęgnacji.



Gdy pojawiają się dwa rozwiązania o różnych

atrybutach, porównywanie szybkości ich tworzenia nic

tak naprawdę nie daje.



Mimo tego w procesie tworzenia oprogramowania

menedżerowie

muszą

oceniać

produktywność

inżynierów. Takie oszacowania mogą być niezbędne

przy szacowaniu przedsięwzięcia i przy ustalaniu, czy

ulepszenia procesowe i technologiczne były skuteczne.

Produktywność

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 9



Miary wielkościowe. Są związane z wielkością
pewnego wyniku czynności. Najczęściej
stosowaną miarą wielkościową jest liczba
wierszy dostarczonego kodu źródłowego.



Miary funkcyjne. Są związane z ogólną
funkcjonalnością

dostarczonego

oprogramowania. Produktywność wyraża się
w

kategoriach

ilości

użytecznej

funkcjonalności dostarczonej w pewnym
czasie.

Rodzaje miar

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 10



Wiersze kodu na miesiąc pracy programisty to szeroko

stosowana miara produktywności. Wyznacza się ją przez

obliczenie całkowitej liczby dostarczonego kodu źródłowego.

Tę liczbę dzieli się następnie przez całkowity koszt (w

miesiącach pracy programisty) konieczny do ukończenia

przedsięwzięcia. Ten czas obejmuje zatem czas potrzebny na

analizę,projektowanie, kodowanie i dokumentowanie.



Podejście to opracowano, gdy większość programów

powstawała w językach FORTRAN, asembler i COBOL.



Programy w językach takich jak Java i C++ składają się

jednak z deklaracji, instrukcji wykonywalnych i komentarzy.

Mogą zawierać makrodefinicje, które rozwijają się na kilka

wierszy kodu. W jednym wierszu może być więcej niż jedna

instrukcja. Nie ma więc prostego związku między instrukcjami

programu i wierszami wydruku.

Praca programisty

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 11

Czas budowania systemu

Analiza Projek- Kodowanie

Testowanie

Dokumentowanie

towanie

Asembler

3 tyg.

5 tyg.

8 tyg.

10 tyg.

2 tyg.

Język wysokiego 3 tyg.

5 tyg.

8 tyg.

6 tyg.

2 tyg.

poziomu

Wielkość

Praca

Produktywność

Asembler

500 wierszy

28 tyg.

714 wierszy/miesiąc

Język wysokiego 1500 wierszy

20 tyg.

300 wierszy/miesiąc

poziomu

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 12

Praca programisty



Innym niż wielkość kodu sposobem pomiaru

przybliżonego atrybuty produktu jest użycie

pewnych miar funkcjonalności kodu. Umożliwia to

uniknięcie opisanej wcześniej anomalii, ponieważ

funkcjonalność nie zależy od implementacji.



Najlepiej znaną taką miara jest liczba punktów

funkcyjnych. Punkty funkcyjne są niezależnie od

języka, można więc za ich pomocą porównywać

produktywność

w

różnych

językach

programowania. Produktywność wyraża się jako

liczby punktów funkcyjnych utworzonych w czasie

osobomiesiąca.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 13

Punkty funkcyjne



Całkowitą liczbę punktów funkcyjnych
wyznacza się przez zmierzenie lub
oszacowanie następujących elementów
programu:

•

zewnętrzne dane wejściowe i wyjściowe,

•

interakcje z użytkownikiem,

•

interfejsy zewnętrzne,

•

pliki używane przez system.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 14

Punkty obiektowe



Punkty obiektowe nie są klasami obiektów, które

tworzy się przy obiektowym podejściu do

tworzenia oprogramowania. Liczba punktów

obiektowych w programie jest miarą ważoną

następujących składników:

•

Liczba różnych wyświetlanych ekranów. Proste ekrany liczą się

jako 1 punkt obiektowy, średnio złożone ekrany jako 2, a bardzo

złożone ekrany jako 3.

•

Liczba tworzonych raportów. Prosty raport to 2 punkty

obiektowe, średnio złożone raporty to 5 punktów, a raporty które

prawdopodobnie trudno będzie utworzyć, liczy się jako 8

punktów.

•

Liczba modułów 3GL, które należy opracować w celu

uzupełnienia kodu 4GL. Każdy moduł 3GL liczy się jako 10

punktów obiektowych.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 15

Czynniki wpływające na
produktywność inżynierów
oprogramowania

Czynnik

Opis

Wiedza

Wiedza z dziedziny zastosowania jest konieczna do skutecznego tworzenia

z dziedziny

oprogramowania. Inżynierowie, którzy już rozumieją dziedzinę, będą

zastosowania

najprawdopodobniej najbardziej produktywni.

Jakość procesu Zastosowany proces tworzenia może mieć znaczący wpływ na

produktywność.

Wielkość

Im przedsięwzięcie jest większe, tym więcej trzeba komunikacji zespołu.

przedsięwzięcia

Mniej czasu pozostaje na tworzenie, więc indywidualna produktywność

jest mniejsza.

Wspomaganie Dobre wspomaganie technologiczne, takie jak narzędzia CASE, pomocnicze
technologiczne systemy zarządzania konfiguracjami itd. mogą poprawić produktywność.

Środowisko

Ciche środowisko pracy z prywatnymi miejscami pracy przyczynia się do

pracy

wzrostu produktywności.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 16



Kłopot miarami wyrażonymi za pomocą

ilości w czasie polega na tym, że nie bierze

się w nich pod uwagę niefunkcjonalnych

właściwości oprogramowania, takich jak

niezawodność, zdatność do pielęgnacji itd.

Przy takich miarach zawsze im więcej, tym

lepiej. Beck (2000) błyskotliwie zauważył,

że

przy

podejściu

polegającym

na

ustawicznym upraszczaniu i poprawianiu

kodu liczba wierszy kodu oznacza niewiele.

Problemy z miarami

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 17

Metody szacowania



Nie istnieje prosty sposób dokładnego szacowania

pracy

niezbędnej

do

zbudowania

systemu

oprogramowania.



Wstępne szacunki muszą być wykonywane na

podstawie definicji wymagań wysokiego poziomu.



Oprogramowanie może być przeznaczone do działania

na słabo znanym komputerze lub jego tworzenie może

odbywać się z użyciem nowej technologii.



Ludzie biorący udział w przedsięwzięciu i ich

umiejętności nie będą prawdopodobnie znane.

Wszystkie te czynniki oznaczają, że trudno jest podać

dokładnie oszacowanie kosztu budowania systemu we

wczesnej fazie przedsięwzięcia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 18

Metody szacowania
kosztów

Metoda

Opis

Algorytmiczne

Na podstawie historycznej informacji o kosztach opracowuje się model, który wiąże

modelowanie

pewną miarę oprogramowania (zwykle jego wielkość) z kosztem przedsięwzięcia.

kosztów

Szacuje się wartość tej miary i na podstawie modelu ustala się wymaganą pracę.

Ocena

Zasięga się rady kilku ekspertów od zaproponowanych metod tworzenia

ekspertów

oprogramowania i dziedziny zastosowania. Każdy z nich szacuje koszt

przedsięwzięcia. Te szacunki porównuje się i omawia. Proces szacowania powtarza
się do chwili ustalenia uzgodnionego oszacowania.

Szacowanie przez

Tę metodę można zastosować, jeśli ukończono już podobne przedsięwzięcia w tej

analogię

samej dziedzinie zastosowań. Koszt nowego przedsięwzięcia ocenia się przez
analogię do kosztów tych zakończonych przedsięwzięć. Myers (1989) podał bardzo
jasny opis tego podejścia.

Prawo

Prawo Parkinsona mówi, ze praca rozciąga się tak, że wypełnia wyznaczony czas.

Parkinsona

Koszt jest determinowany przez dostępne zespoły, a nie przez obiektywną ocenę.

Jeśli oprogramowanie musi być dostarczone w ciągu 12 miesięcy i mamy do
dyspozycji pięć osób, to niezbędną pracę ocenia się na 60 osobomiesięcy.

Ustalanie ceny

Koszt oprogramowania jest szacowany na tyle, ile klient może wydać na to

pod zwycięstwo przedsięwzięcie. Przybliżona praca zależy od budżetu klienta, a nie od

funkcjonalności oprogramowania.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 19

Trudności



Wielu menedżerów ma niewiele doświadczenia w
stosowaniu technik lub wiedzy o ich wpływie na
koszt przedsięwzięcia. Oto niektóre przykłady
zmian, które mogą wpłynąć na oszacowanie na
podstawie doświadczenia:

•

tworzenie obiektowe zamiast tworzenia funkcyjnego

•

system klient-serwer zamiast systemu na komputerze głównym

•

użycie komponentów z półki zamiast tworzenia tych
komponentów

•

tworzenie z wykorzystaniem użycia wielokrotnego zamiast
budowy od nowa wszystkich części systemu,użycie narzędzi
CASE

i

generatorów

programów

zamiast

tworzenia

oprogramowania bez takiego wspomagania.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 20

Modelowanie
algorytmiczne kosztów



Model algorytmiczny kosztów można zbudować
analizując

koszty

i

atrybuty

ukończonych

przedsięwzięć.



Do przewidywania kosztów używa się formuły
matematycznej, w której uwzględnia się oszacowanie
wielkości przedsięwzięcia, liczbę programistów oraz
inne czynniki procesowe i produktowe.



Większość

modeli

algorytmicznych

szacowania

zawiera komponent wykładniczy. Odzwierciedla on
fakt, że zwykle koszt nie rośnie liniowo wraz ze
wzrostem wielkości przedsięwzięcia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 21

Ogólna postać
oszacowania
algorytmicznego



Praca = A

X

Wielkość

B

X

M



A jest stałym czynnikiem, który zależnie od

lokalnych zwyczajów firmy i rodzaju

tworzonego oprogramowania.



Wartość wykładnika B zwykle waha się

między

1

i

1,5.

Odzwierciedla

nieproporcjonalność pracy niezbędnej w

wypadku wielkich przedsięwzięć.



M to mnożnik określany na podstawie

połączenia różnych atrybutów procesu,

produktu i tworzenia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 22

Dokładność szacunków na
podstawie modelu
algorytmicznego



Zależy od dostępnej informacji o
systemie.



W miarę postępów procesu tworzenia
oprogramowania pojawia się coraz
więcej informacji.



Oszacowania staja się coraz bardziej
precyzyjne.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 23

Niepewność oszacowania

x

2x

4x

0.5x

0.25x

Wykonalność

Wymagania

Projekt

Kod

Dostarczenie

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 24

Model COCOMO



Wywnioskowano go na podstawie
danych zebranych z wielkiej liczby
przedsięwzięć programistycznych.



Zanalizowano je w celu wykrycia
formuł

najlepiej

pasujących

do

obserwacji.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 25

Cechy modelu COCOMO



Jest dobrze udokumentowany, publicznie
bezpłatnie dostępny i wspomagany przez
narzędzia bezpłatne i komercyjne.



Stosowano i oceniano go szeroko.



Ma długi rodowód od pierwszego wcielenia
w 1981 (Boehm), poprzez poprawki w celu
dostosowania do tworzenia oprogramowania
w Adzie (Boehm i Royce, 1989), aż do
najnowszej wersji opublikowanej w 1995 r.
(Boehm i inni).

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 26

Podstawowy model
COCOMO 81

Złożoność

Formuła

Opis

Proste

PM = 2,4 (KDSI)

1,05

* M

Zrozumiałe programy użytkowe

tworzone przez małe zespoły.

Średnie

PM = 3,0 (KDSI)

1,12

* M

Bardziej złożone przedsięwzięcia, w

których członkowie zespołu mogą mieć
ograniczone doświadczenia z
podobnymi systemami.

Wbudowane PM = 3,6 (KDSI)

1,20

* M

Złożone przedsięwzięcia, w których

oprogramowanie jest częścią silnie
powiązanego złożonego sprzętu,
oprogramowania, regulacji i procedur
działania.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 27

Modele algorytmiczne
kosztów w planowaniu
przedsięwzięć



Menedżerowie przedsięwzięć mogą użyć
modelu

algorytmicznego

kosztów

do

porównania różnych sposobów inwestowania
pieniędzy w celu zmniejszenia kosztów
przedsięwzięcia.



Jest to szczególnie istotne tam, gdzie
konieczny

jest

kompromisowy

wybór

droższego sprzętu albo oprogramowania, oraz
tam, gdzie trzeba przyjąć nowy personel z
umiejętnościami

specyficznymi

dla

przedsięwzięcia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 28

Składniki, które trzeba wziąć
pod uwagę przy
kosztorysowaniu
przedsięwzięcia:



Koszt docelowego sprzętu, na którym
będzie działał system.



Koszt

platformy

(komputer

i

oprogramowanie)

do

budowania

systemu.



Koszt pracy niezbędnej do utworzenia
oprogramowania.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 29

Opcje menedżerów

A. Użycie istniejącego sprzętu,

systemu tworzenia i zespołu

wytwórczego

A. Użycie istniejącego sprzętu,

systemu tworzenia i zespołu

wytwórczego

D. Bardziej

doświadczony

personel

D. Bardziej

doświadczony

personel

C. Ulepszenie tylko

pamięci

Rośnie koszt

sprzętu

C. Ulepszenie tylko

pamięci

Rośnie koszt

sprzętu

B. Ulepszenie procesora i pamięci

Rośnie koszt sprzętu

Doświadczenie maleje

B. Ulepszenie procesora i pamięci

Rośnie koszt sprzętu

Doświadczenie maleje

F. Personel

z doświadczeniami

ze sprzętem

F. Personel

z doświadczeniami

ze sprzętem

E. Nowy system tworzenia

Rośnie koszt sprzętu

Doświadczenie maleje

E. Nowy system tworzenia

Rośnie koszt sprzętu

Doświadczenie maleje

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 31

Czas trwania
przedsięwzięcia i praca
personelu



Oprócz szacowania pracy niezbędnej do budowania

system oprogramowania i całkowitego kosztu pracy

menedżerowie przedsięwzięć muszą także ocenić,

jak długo potrwa budowa i kiedy personel będzie

potrzebny w przedsięwzięciu.



Czas budowania w przedsięwzięciu nosi nazwę

harmonogramu przedsięwzięcia. Firmy chcą coraz

krótszych harmonogramów tworzenia, aby ich

produkty mogły trafić na rynek przed konkurencją.



Związek między liczbą osób pracujących w

przedsięwzięciu, całkowitą niezbędną pracą i

czasem budowania nie jest liniowy. W miarę

wzrostu wielkości personelu trzeba więcej pracy.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 32

Formuła do szacowani
czasu kalendarzowego



TDEV = 3

X

(PM)

(0,33 + 0,2 x

(B – 1,01))



PM to oszacowanie pracy. B to
wykładnik

obliczony

zgodnie

z

wcześniejszymi

rozważeniami

(B

wynosi 1 w modelu wczesnego
prototypowania). To obliczenie pozwala
przewidzieć przeciętny harmonogram
przedsięwzięcia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 33

Przykład



Aby

zilustrować

obliczenie

harmonogramu

tworzenia w COCOMO, przypuśćmy, że pracę
niezbędną

do

ukończenia

przedsięwzięcia

oszacowano na 60 miesięcy.



Załóżmy też, że wartością wykładnika B jest 1,17.



Na podstawie równania harmonogramu obliczamy
czas niezbędny do ukończenia przedsięwzięcia:

TDEV = 3(60)

0,36

= 13 miesięcy



W tym wypadku nie ma skracania ani wydłużania
harmonogramu, więc ostatni czynnik wzoru nie
ma wpływu na obliczenia.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 34

Główne tezy



Czynniki wpływające na produktywność to m.in. indywidualne

zdolności (czynnik dominujący), doświadczenie z dziedziny

zastosowania,

proces

tworzenia,

wielkość

przedsięwzięcia,

wspomaganie narzędziowe i środowisko pracy.



Istnieją rozmaite metody szacowania kosztu oprogramowania. Przy

szacowaniu należy użyć kilku z nich. Otrzymanie istotnie różniących

się od siebie wyników oznacza, że dostępne informacje użyte do

szacowania są nieadekwatne.



Oprogramowanie jest często wyceniane tak, żeby zdobyć kontrakt.

Funkcjonalność systemu dostosowuje się później do oszacowanej

ceny.



Modelowanie algorytmiczne kosztów wiąże się z zasadniczymi

trudnościami,

które

wynikają

z

wykorzystania

atrybutów

ukończonych produktów do szacowania kosztów. We wczesnych

fazach przedsięwzięcia nie da się precyzyjnie oszacować wartości

tych atrybutów.

©Ian Sommerville 2000

Software Engineering, 6th edition. Chapter 23

Slide 35

Główne tezy



Model

kosztorysowania

COCOMO

jest

dobrze

dopracowany. Przy ustaleniu oszacowania kosztu bierze się

w nim pod uwagę atrybuty przedsięwzięcia, produktu,

sprzętu i personelu. Obejmuje także sposoby szacowania

harmonogramu tworzenia.



Modele algorytmiczne kosztów są cenne dla kierownictwa,

ponieważ

pomagają

w

ilościowej

analizie

opcji.

Umożliwiają obliczenie kosztów różnorodnych wariantów,

co - nawet mimo błędów - umożliwia porównanie ich na

podstawie obiektywnych kryteriów.



Czas niezbędny do ukończenia przedsięwzięcia nie jest

wprost proporcjonalny do liczby osób w nim pracujących.

Dodawanie personelu do opóźnionego przedsięwzięcia

może je jeszcze bardziej opóźnić.