Szacowanie kosztu oprogramowania

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 23 Slide 1

Szacowanie kosztu oprogramowania

Szacowanie kosztu i pracy niezbędnej do wyprodukowania oprogramowania


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


Najważniejsze pytania szacowania Ile pracy trzeba na ukończenie czynności? Ile czasu kalendarzowego trzeba na ukończenie

czynności? Jaki jest całkowity koszt czynności? Szacowanie i ustalanie harmonogramu

przedsięwzięcia zwykle wykonuje się równolegle


Składniki kosztu Koszty sprzętu i oprogramowania Koszty podróży i szkoleń Koszty pracy (zazwyczaj dominujące)

• Płace programistów • Ubezpieczenie i podatki

Dodatkowe koszty, które trzeba brać pod uwagę• wynajęcie budynku, ogrzewanie i oświetlenie• koszt sieci i komunikacji• udogodnienia centralne (biblioteka, pomieszczenia rekreacyjne)


Kosztorysowanie i wycena Koszt wytworzenia oprogramowania jest

szacowany Nie ma prostej zależności pomiędzy kosztem

wytworzenia oprogramowania i ceną przedstawianą klientowi

Szerokie powody organizacyjne, ekonomiczne, polityczne i biznesowe wpływają na ostateczną cenę


Czynniki wpływające na cenęCzynnik Opis

Okazjarynkowa

Przedsiębiorstwo produkujące może podać niską cenę, aby wejść na nowy segment rynku. Zdobyte doświadczenie może potem zaprocentować

Niepewnośćkosztów

Jeśli oszacowanie kosztów jest niepewne, to przedsiębiorstwo może sobie zostawić większy niż zazwyczaj margines zysku

Warunkiumowy

Jeśli kod zostaje własnością przedsiębiorstwa, to może ono obniżyć cenę licząc na jego wielokrotne wykorzystanie

Płynnośćwymagań

Jeśli wymagania będą się zmieniać, to przedsiębiorstwo może obniżyć cenę żądając później wyższej ceny za zmiany wymagań

Kondycjafinansowa

Firma w złej kondycji finansowej może obniżać swoje ceny. Od wypadnięcia z rynku lepszy jest mały zysk lub nawet strata


Miara indywidualnego wkładu pracy włożonej przez pojedynczego programistę w tworzenie systemu i dokumentacji

Nie jest rozpatrywana jakościowo, chociaż zapewnienie jakości jest jednym z procesów podczas tworzenia oprogramowania

Generalnie chcemy mierzyć jak duża funkcjonalność produkowana jest w jednostce czasu

Produktywność programistów


Miary wielkościowe oparte są na części wyników powstających podczas tworzenia oprogramowania. Mogą to być linie kodu, klasy itp.

Miary funkcyjne są związane z funkcjonalnością dostarczonego oprogramowania. Punkty funkcyjne to najlepiej znana miara tego typu

Miary produktywności


Określenie metody pomiaru Określenie czasu pracy programistów Oszacowanie produktywności poddostawców (np.

dokumentacja) i umieszczenie tego czasu w całkowitym szacowaniu

Problemy z produktywnością


Co to jest linia kodu?• Miara została zaproponowana, gdy programiści dziurkowali

karty• Ma się to nijak do programów w nowoczesnych językach

programowania Które programy są częściami systemu? Zakłada zależność liniową pomiędzy rozmiarem

systemu a dokumentacji

Linie kodu


Im niższy poziom języka tym produktywność wyższa• Tą samą funkcjonalność da się zapisać w mniejszej liczbie linii

przy użyciu języka programowania wyższego poziomu Im bardziej rozwlekły programista tym wyższa

produktywność • Liczenie linii kodu karze programistów piszących zwięzły kod

sugerując, że im więcej kodu tym lepiej

Porównywanie produktywności


Języki wysokiego i niskiego poziomu

Analiza Projektowanie Kodowanie Testowanie Dokumentowanie

Asembler 3 tyg. 5 tyg. 8 tyg. 10 tyg. 2 tyg.

Java 3 tyg. 5 tyg. 8 tyg. 6 tyg. 2 tyg.

Wielkość Praca Produktywność

Asembler 5000 wierszy 28 tygodni

714 w/m

Java 1500 wierszy 20 tygodni

300 w/m


Punkty funkcyjne Oparte na połączeniu następujących elementów

programu • Zewnętrzne wejścia i wyjścia• Interakcje z użytkownikiem• Interfejsy zewnętrzne• Pliki używane przez system

Z każdym elementem jest skojarzona waga (3-15) Liczba punktów funkcyjnych jest wyznaczana na

podstawie sumy wag elementów systemu


Punkty funkcyjne Punkty funkcyjne powinny uwzględniać czynnik

skomplikowania przedsięwzięcia Punkty funkcyjne mogą służyć do szacowania

liczby linii kodu • LLK = SLLK * liczba punktów funkcyjnych• SLLK zależy od języka i waha się od 200-300 dla asemblera do

2-40 dla języków czwartej generacji PF są subiektywne i zależą od szacującego

• Nie można policzyć punktów funkcyjnych automatycznie


Punkty obiektowe Punkty obiektowe są alternatywą dla miar

zorientowanych na funkcje i są używane w językach czwartej generacji

Punkty obiektowe NIE są klasami Liczba punktów obiektowych jest ważoną sumą

• Liczby rożnych wyświetlanych ekranów • Liczby raportów generowanych przez system • Liczby modułów 3GL tworzonych dla wsparcia modułów 4GL


Szacowanie punktów obiektowych

Punkty obiektowe są łatwiejsze do oszacowania na podstawie specyfikacji niż punkty funkcyjne

Można je szacować we wczesnych fazach procesu tworzenia oprogramowania. W tej fazie bardzo trudno szacować liczbę linii kodu


Systemy czasu rzeczywistego, 40-160 LK/PM

Programy systemowe, 150-400 LK/PM Aplikacje komercyjne, 200-800

LK/PM W punktach obiektowych produktywność wynosi

od 4 do 50 punktów na miesiąc w zależności od stosowanych narzędzi

Szacunki produktywności


Czynniki wpływające na produktywnośćCzynnik Opis

Wiedza z dziedziny zastosowania

Inżynierowie rozumiejący dziedzinę są bardziej produktywni

Jakość procesu Im lepszy proces tworzenia tym wyższa produktywność

Wielkość przedsięwzięcia

Im większe przedsięwzięcie tym więcej komunikacji potrzeba i zmniejsza się produktywność

Wspomaganie technologiczne

Narzędzia CASE i pomocnicze systemy zwiększają efektywność

Środowisko pracy Ciche środowisko pracy z prywatnymi miejscami pracy zwiększa produktywność


Metryki mierzące rozmiar jednostkowej czynności mają zapominają o jakości

Produktywność łatwo zwiększyć zmniejszając jakość

Trudno ocenić jak miary jakości i produktywności mają się do siebie

Jeśli zmiany następują ciągle to podejście polegające na liczeniu linii kodu przestaje się liczyć

Jakość i produktywność


Techniki szacowania Nie ma prostych metod służących do dokładnego

szacowania wysiłku koniecznego do budowy systemu• Szacowanie wstępne jest oparte na wyliczeniach opartych na

niedokładnych wymaganiach użytkownika • Oprogramowanie może być tworzone przy użyciu nowej

technologii • Ludzie w przedsięwzięciu mogą być niewiadomą

Szacunki mogą być samospełniające• Szacunki określają budżet a produkt jest dostosowywany do

budżetu


Techniki szacowania Algorytmiczne modelowanie kosztów Ocena ekspertów Szacowanie przez analogię Prawo Parkinsona Ustalanie ceny pod zwycięstwo


Modelowanie algorytmiczne Tworzenie obliczalnej formuły, która jest oparta

na danych historycznych i generalnie ocenia koszt oprogramowania na podstawie jego rozmiaru


Ocena ekspertów Jeden lub więcej ekspertów zarówno w dziedzinie

tworzenia jak również użytkowania oprogramowania w dziedzinie szacują koszt.

Zalety: Relatywnie tania metoda. Może być dokładna jeśli eksperci mają doświadczenie z podobnymi systemami

Wady: bardzo niedokładna jeśli eksperci są kiepscy!


Przez analogię Kosz jest obliczany przez porównanie

przedsięwzięcia z podobnymi przedsięwzięciami z tej samej dziedziny

Zalety: Dokładna jeśli mamy dostęp do koniecznych danych

Wady: Nie można jej zastosować jeśli nie mamy z czym porównywać naszego przedsięwzięcia. Konieczna ciągła aktualizacja danych


Prawo Parkinsona Przedsięwzięcie zużyje wszystkie dostępne

zasoby Zalety: Nie przekroczymy budżetu Wady: Zazwyczaj nie ukończymy systemu


Cena pod zwycięstwo Cena przedsięwzięcia to tyle ile klient może

wydać Zalety: Mamy kontrakt Wady: Prawdopodobieństwo, że klient otrzyma

system jakiego chciał jest małe. Koszty nie odwzorowują nakładu pracy


Zstępujące i wstępujące szacowanie kosztów

W każdej metodzie można zastosować oba Zstępujące

• Zaczynamy od poziomu całego systemu, określamy jego koszt a następnie dopasowujemy ją do podsystemów

Wstępujące• Zaczynamy od wyceny komponentów a dopiero potem je

sumujemy


Zstępujące Można go używać nie rozumiejąc jaka jest

architektura systemu i z jakich komponentów może się on składać

Bierze pod uwagę koszt integracji, konfiguracji i dokumentacji

Za nisko szacuje trudne do rozwiązania problemy techniczne


Wstępujące Konieczna jest znajomość architektury systemu Metoda jest dokładna jeśli system został

zaprojektowany w szczegółach Za nisko szacuje koszty integracji i dokumentacji


Metody szacowania Każda ma swoje mocne i słabe strony Szacowanie powinno być oparte na kilku

metodach Jeśli różne metody zwracają różne wyniki, to

znaczy to, że jest za mało danych Trzeba wtedy podjąć działania mające na celu

znalezienie brakujących danych Czasami jedynie ustalanie ceny pod zwycięstwo

jest dopuszczalne


Szacowanie oparte na doświadczeniu Szacowanie jest oparte głównie na doświadczeniu Niestety zmieniająca się rzeczywistość wpływa

na szacowanie i czyni go niedokładnym• Zmiana projektowania funkcyjnego na obiektowe • Systemy klient serwer zamiast centralnych • Gotowe komponenty• Inżynieria oprogramowania z wykorzystaniem wielokrotnego

użycia• Narzędzia CASE i generatory kodu


Szacowanie pod zwycięstwo Wydaje się nieetyczne i niebiznesowe Jednak, przy braku koniecznych informacji może

być jedyną drogą Koszt przedsięwzięcia jest uzgodniony i

ogranicza on jego zakres Można negocjować dokładną specyfikację lub

użyć podejścia ewolucyjnego


Modelowanie algorytmiczne Koszt jest otrzymywany jako funkcja atrybutów

produktu, przedsięwzięcia i procesu tworzenia szacowanych przez menadżerów • Praca = A RozmiarB M

• A jest stałe i zależy od lokalnych zwyczajów firmy, B oddaje nieproporcjonalność pracy w przypadku wielkich przedsięwzięć a M oddaje atrybuty przedsięwzięcia

Jako rozmiar najczęściej bierze się rozmiar kodu Modele są podobne za wyjątkiem różnych wartości

A, B i M


Dokładność szacowania Rozmiar systemu znamy dokładnie po jego

ukończeniu Czynniki mające wpływ na rozmiar

• Użycie gotowych komponentów• Język programowania• Dystrybuowanie systemu

W miarę postępu prac dokładność szacowania się zwiększa


Niepewność

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design Code Delivery


Model COCOMO Model empiryczny oparty na doświadczeniu Dobrze udokumentowany i niezależny od żadnej

dużej firmy Pierwsza wersja z 1981 roku (COCOMO-81)

aktualna COCOMO 2 COCOMO 2 bierze pod uwagę różne podejścia

do procesu tworzenia oprogramowania


COCOMO 81


Poziomy COCOMO 2 COCOMO 2 jest modelem trójpoziomowym który

pozwala na szacowanie kosztów z wzrastającą dokładnością

Poziom wczesnego prototypowania• Podstawą oszacowań są punkty obiektowe

Poziom wczesnego projektowania• Podstawą oszacowań są punkty funkcyjne przeliczane na linie kodu

Poziom post-architektoniczny• Podstawą oszacowań jest rozmiar kodu


Poziom wczesnego prototypowania Gotowe do użycia w fazie prototypowania z

dużym wykorzystaniem wielokrotnego użycia Oparte na szacowaniu produktywności

programisty w punktach obiektowych na miesiąc Bierze pod uwagę użycie narzędzi CASE Formuła wygląda następująco:

• PM = ( NOP (1 - %reuse/100 ) ) / PROD

• PM to praca w osobomiesiącach, NOP to liczba punktów obiektowych a PROD to produktywność


Produktywność w punktach obiektowych


Poziom wczesnego projektowania Oszacowania można dokonać po uzgodnieniu

wymagań Oparte jest na standardowej formule

• PM = A WielkośćB M + PMm gdzie

• M = PERS RCPX RUSE PDIF PREX FCIL SCED• PMm = (ASLOC (AT/100)) / ATPROD

• A = 2.5 jest początkowym oszacowaniem, rozmiar jest liczony w tysiącach linii kodu, B waha się od 1.1 do 1.24 w zależności od nowatorstwa przedsięwzięcia, elastyczności, zarządzania ryzykiem i dojrzałości procesu oraz zespołu


Mnożniki Mnożniki odzwierciedlające umiejętności

programistów, wymagania niefunkcjonalne znajomość platformy, itd. • RCPX – niezawodność i złożoność• RUSE – wymagane użycie wielokrotne• PDIF – trudność platformy• PREX – doświadczenie personelu• PERS – możliwości personelu• SCED – wymagany harmonogram• FCIL – udogodnienia pomocnicze

PMm - ilość automatycznie generowanego kodu


Poziom post-architektoniczny Używa tych samych formuł co poprzedni Dokładniejsze szacowanie rozmiaru kodu

• Płynność wymagań. Potrzeba więcej pracy• Rozszerzenie możliwego użycia wielokrotnego. Trzeba zwiększyć ilość

linii kodu, które w rzeczywistości powstaną • ESLOC = ASLOC (AA + SU +0.4DM + 0.3CM +0.3IM)/100

» ESLOC równoważna liczba wierszy nowego kodu. ASLOC to liczba linii kodu koniecznych do zmodyfikowania, DM to procent modyfikowanego projektu, CM to procent modyfikowanego kodu, IM to odsetek pierwotnej pracy integracyjnej.

» SU to czynnik oparty na koszcie zrozumienia kodu, AA to czynnik odzwierciedlający koszt ustalenia czy oprogramowanie może być użyte wielokrotnie


Zależy od pięciu czynników. Ich suma jest dzielona przez 100 i dodawana do 1.01

Przykład• Nadrzędność – nowy projekt - 4• Elastyczność tworzenia – klient niezaangażowany – bardo

wysoka - 1• Panowanie nad ryzykiem - brak - 5• Spójność zespołu – nowy zespół - 3• Dojrzałość procesu - częściowa - 3

Wykładnik wynosi więc 1.17

Wykładnik


Czynniki

Czynnik Wyjaśnienie Nadrzędność Oddaje doświadczenie organizacji w podobnych przedsięwzięciach. Elastyczność tworzenia Odzwierciedla stopień elastyczności procesu tworzenia. Mała –

użycie nakazanego procesu. Duża – klient ustala cele. Panowanie nad ryzykiem architektonicznym

Zakres wykonywanej analizy ryzyka.

Spójność zespołu Jak dobrze członkowie zespołu się znają i jak dobrze ze sobą współpracują.

Dojrzałość procesu Odzwierciedla dojrzałość procesu w przedsiębiorstwie. Można ją mierzyć w modelu CMM


Atrybuty produktu• Oczekiwane właściwości tworzonego produktu

Atrybuty komputera• Ograniczenia narzucone przez wybór platformy sprzętowej

Atrybuty personelu• Doświadczenie i możliwości osób biorących udział w

przedsięwzięciu

Atrybuty przedsięwzięcia• Właściwości przedsięwzięcia budowania oprogramowania

Mnożniki


Czynniki kosztów przedsięwzięcia


Wpływ czynników kosztów


Algorytmiczne modelowanie kosztu może stanowić podstawę dla planowania. Pozwala na porównywanie różnych strategii

System w statku kosmicznym• Niezawodny• Mała waga (mało układów scalonych)• Mnożniki niezawodności i sprzętu > 1

Składniki kosztu• Sprzęt docelowy• Platforma tworzenia oprogramowania• Wymagany wysiłek

Planowanie przedsięwzięcia


Opcje menedżerówA. Use existing hardware,development system and

development team

C. Memoryupgrade only

Hardware costincrease

B. Processor andmemory upgrade

Hardware cost increaseExperience decrease

D. Moreexperienced staff

F. Staff withhardware experience

E. New developmentsystem

Hardware cost increaseExperience decrease


Koszt różnych opcji

Option RELY STOR TIME TOOLS LTEX Total effort Software cost Hardware cost

Total cost

A 1.39 1.06 1.11 0.86 1 63 949393 100000 1049393 B 1.39 1 1 1.12 1.22 88 1313550 120000 1402025 C 1.39 1 1.11 0.86 1 60 895653 105000 1000653 D 1.39 1.06 1.11 0.86 0.84 51 769008 100000 897490 E 1.39 1 1 0.72 1.22 56 844425 220000 1044159 F 1.39 1 1 1.12 0.84 57 851180 120000 1002706


Wybór opcji Opcja D (lepszy personel) wydaje się być

najlepsza• Niestety ryzyko nie znalezienia doświadczonego personelu jest

wysokie Opcja C (więcej pamięci) mniej oszczędza koszty

ale jest mniej ryzykowna Model pokazuje, że bardzo ważny jest

doświadczony personel


Czas trwania przedsięwzięcia Oprócz kosztu konieczne jest szacowanie czasu

trwania przedsięwzięcia Formuła COCOMO 2

• TDEV = 3 (PM)(0.33+0.2*(B-1.01))

• PM oszacowanie pracy B wykładnik obliczony uprzednio (1 dla wczesnego prototypu)

Konieczny czas jest niezależny od liczby osób zaangażowanych w przedsięwzięcie


Praca personelu Nie można obliczyć rozmiaru zespołu dzieląc

oszacowanie pracy przez pensję W różnych fazach w przedsięwzięcie jest

zaangażowana różna liczba ludzi Im więcej ludzi zaangażowanych tym większe

oszacowanie pracy Gwałtowny wzrost liczby osób zbiega się z

opóźnieniem harmonogramu

Szacowanie kosztu oprogramowania

Documents

Transcript of Szacowanie kosztu oprogramowania