Szacowanie kosztu oprogramowania

©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


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.


Zawartość Produktywność Metody szacowania Modelowanie algorytmiczne kosztów Czas trwania przedsięwzięcia i praca personelu


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?


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).


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.


Czynniki wpływające na cenę oprogramowania

Czynnik OpisOkazja 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żeoszacowania 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.


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ść


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


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


Czas budowania systemuAnaliza 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ącpoziomu


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.


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.


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.


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

Czynnik Opis

Wiedza Wiedza z dziedziny zastosowania jest konieczna do skutecznego tworzeniaz 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.


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


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.


Metody szacowania kosztówMetoda OpisAlgorytmiczne Na podstawie historycznej informacji o kosztach opracowuje się model, który wiążemodelowanie 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.


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.


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.


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.


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.


Niepewność oszacowania

x

2x

4x

0.5x

0.25x

Wykonalność Wymagania Projekt Kod Dostarczenie


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.


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).


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ą silniepowiązanego złożonego sprzętu,oprogramowania, regulacji i procedur działania.


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.


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.


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 tylkopamięci

Rośnie kosztsprzętu

C. Ulepszenie tylkopamięci

Rośnie kosztsprzętu

B. Ulepszenie procesora i pamięci

Rośnie koszt sprzętuDoświadczenie maleje

B. Ulepszenie procesora i pamięci


F. Personelz doświadczeniami

ze sprzętem

F. Personelz doświadczeniami

ze sprzętem

E. Nowy system tworzenia


E. Nowy system tworzenia



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.


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.


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.


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.


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ć.

Szacowanie kosztu oprogramowania

Documents

Transcript of Szacowanie kosztu oprogramowania