1 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Szacowanie kosztu oprogramowania l Przedstawienie metod szacowania kosztu i pracy niezbędnej do wyprodukowania oprogramowania

2 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 2 Cele l Poznać podstawy szacowania kosztów i ustalania ceny oprogramowania oraz złożone związki między tymi kwestiami. l Poznać miary stosowane do szacowania produktywności programowania. l Zdać sobie sprawę, że do szacowania kosztów i harmonogramu tworzenia oprogramowania można stosować wiele różnych metod. l Poznać zasady modelu COCOMO 2 do algorytmicznego szacowania kosztu.

3 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 3 Zawartość l Produktywność l Metody szacowania l Modelowanie algorytmiczne kosztów l Czas trwania przedsięwzięcia i praca personelu

4 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 4 Pytania l Ile pracy trzeba na ukończenie czynności? l Ile czasu kalendarzowego trzeba na ukończenie czynności? l Jaki jest całkowity koszt czynności?

5 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 5 Koszt tworzenia oprogramowania l Wyznacza się na podstawie trzech następujących parametrów: kosztu sprzętu i oprogramowania wraz z pielęgnacją, kosztu podróży i szkoleń, kosztu pracy (zapłata inżynierom oprogramowania).

6 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 6 Składniki całkowitego kosztu pracy l Koszt udostępnienia, ogrzania i oświetlenia przestrzeni biurowej. l Koszt personelu pomocniczego związanego np. z prowadzeniem księgowości i sekretariatu, sprzątaniem i pomocą techniczną. l Koszt sieci i telekomunikacji. l Koszt udogodnień centralnych, takich jak biblioteka, pomieszczenia rekreacyjne. l Koszt ubezpieczenia społecznego, m.in. na świadczenia dla pracowników, takie jak emerytury i ubezpieczenie zdrowotne.

7 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 7 Czynniki wpływające na cenę oprogramowania CzynnikOpis Okazja rynkowaPrzedsię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 oszacowaniazwiększyć cenę o pewien czynnik rezerwowy powyżej swego zwykłego kosztówzysku. Warunki umowyKlient 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 przekazania 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ń. KondycjaFirmy produkujące w złej kondycji finansowej mogą obniżać swoje ceny w finansowacelu zdobycia kontraktu. Od wypadnięcia z rynku lepszy jest mniejszy niż zwykle zysk lub nawet strata.

8 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 8 l W wypadku budowy oprogramowania istnieje wiele różnych rozwiązań o różnych atrybutach. l Gdy pojawiają się dwa rozwiązania o różnych atrybutach, porównywanie szybkości ich tworzenia nic tak naprawdę nie daje. Jedno rozwiązanie może działać bardziej efektywnie, podczas gdy inne jest bardziej czytelne i łatwiejsze do pielęgnacji. l 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. Konieczność oszacowywania produktywności

9 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 9 l 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. l 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

10 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 10 l Ilość wierszy kodu na miesiąc pracy programisty to szeroko stosowana miara produktywności. l 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. l Ten czas obejmuje zatem czas potrzebny na analizę, projektowanie, kodowanie i dokumentowanie. Szacowanie kosztu pracy programisty za pomocą ilości wierszy kodu

11 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 11 Czas budowania systemu AnalizaProjek-KodowanieTestowanieDokumentowanie towanie Asembler3 tyg.5 tyg.8 tyg.10 tyg.2 tyg. Język wysokiego3 tyg.5 tyg.8 tyg.6 tyg.2 tyg. poziomu WielkośćPracaProduktywność Asembler500 wierszy28 tyg.714 wierszy/miesiąc Język wysokiego1500 wierszy20 tyg.300 wierszy/miesiąc poziomu

12 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 12 Szacowanie kosztów pracy programisty za pomocą liczby punktów funkcyjnych l Inną najlepiej znaną miarą jest liczba punktów funkcyjnych. l 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 miesiąca.

13 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 13 Wyznaczanie liczby punktów funkcyjnych l 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.

14 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 14 Szacowanie kosztów pracy programisty za pomocą liczby punktów obiektowych l W modelu szacowania COCOMO 2 liczba punktów obiektowych w programie jest miarą ważoną następujących składników: liczby różnych wyświetlanych ekranów (prosty ekran to 1 punkt obiektowy, bardzo złożony ekran - 3) liczby tworzonych raportów (prosty raport to 2 punkty obiektowe, bardzo złożony - 8 punktów) liczba modułów napisanych w innym języku, które należy opracować w celu uzupełnienia kodu (każdy moduł liczy się jako 10 punktów obiektowych.

15 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 15 Czynniki wpływające na produktywność inżynierów oprogramowania CzynnikOpis Wiedza Wiedza z dziedziny zastosowania jest konieczna do skutecznego tworzenia z dziedzinyoprogramowania. Inżynierowie, którzy już rozumieją dziedzinę, będą zastosowanianajbardziej produktywni. Jakość procesuZastosowany 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ęciaMniej czasu pozostaje na tworzenie, więc indywidualna produktywność jest mniejsza. WspomaganieDobre wspomaganie technologiczne, takie jak narzędzia CASE, pomocnicze technologicznesystemy zarządzania konfiguracjami itd. mogą poprawić produktywność. ŚrodowiskoCiche środowisko pracy z prywatnymi miejscami pracy przyczynia się do pracywzrostu produktywności.

16 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 16 l 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

17 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 17 Problemy szacowania pracy potrzebnej do zbudowania oprogramowania l Nie istnieje prosty sposób dokładnego szacowania pracy niezbędnej do zbudowania systemu oprogramowania. l Wstępne szacunki muszą być wykonywane na podstawie definicji wymagań wysokiego poziomu. l 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. l 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.

18 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 18 Metody szacowania kosztów wytwarzania oprogramowania MetodaOpis AlgorytmiczneNa podstawie historycznej informacji o kosztach opracowuje się model, który wiąże modelowaniepewną miarę oprogramowania (zwykle jego wielkość) z kosztem przedsięwzięcia. kosztówSzacuje się wartość tej miary i na podstawie modelu ustala się wymaganą pracę. OcenaZasięga się rady kilku ekspertów od zaproponowanych metod tworzenia ekspertówoprogramowania 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 przezTę 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ęć. Prawo Prawo Parkinsona mówi, ze praca rozciąga się tak, że wypełnia wyznaczony czas. ParkinsonaKoszt 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 cenyKoszt oprogramowania jest szacowany na tyle, ile klient może wydać na to pod zwycięstwoprzedsięwzięcie. Przybliżona praca zależy od budżetu klienta, a nie od funkcjonalności oprogramowania.

19 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 19 Sposoby obniżania kosztów l Oto niektóre przykłady takich technik: 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 użycie narzędzi CASE i generatorów programów zamiast tworzenia oprogramowania bez takiego wspomagania. l Jednak niewielu menedżerów ma doświadczenia w stosowaniu technik obniżających koszt przedsięwzięcia.

20 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 20 Modelowanie algorytmiczne kosztów l Model algorytmiczny kosztów można zbudować analizując koszty i atrybuty ukończonych przedsięwzięć. l 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. l 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.

21 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 21 Ogólna postać oszacowania algorytmicznego l Praca = A X Wielkość B X M l A jest stałym czynnikiem, który zależnie od lokalnych zwyczajów firmy i rodzaju tworzonego oprogramowania. l Wartość wykładnika B zwykle waha się między 1 i 1,5. Odzwierciedla nieproporcjonalność pracy niezbędnej w wypadku wielkich przedsięwzięć. l M to mnożnik określany na podstawie połączenia różnych atrybutów procesu, produktu i tworzenia.

22 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 22 Dokładność szacunków na podstawie modelu algorytmicznego l Zależy od dostępnej informacji o systemie. l W miarę postępów procesu tworzenia oprogramowania pojawia się coraz więcej informacji oszacowania stają się coraz bardziej precyzyjne.

23 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 23 Niepewność oszacowania algorytmicznego x 2x 4x 0.5x 0.25x Wykonalność Wymagania ProjektKod Dostarczenie

24 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 24 Model COCOMO l Wywnioskowano go na podstawie danych zebranych z wielkiej liczby przedsięwzięć programistycznych. l Zanalizowano je w celu wykrycia formuł najlepiej pasujących do obserwacji.

25 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 25 Cechy modelu COCOMO l Jest dobrze udokumentowany, publicznie bezpłatnie dostępny i wspomagany przez narzędzia bezpłatne i komercyjne. l Miał cały szereg zatosowań. l 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 (Boehm i in.).

26 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 26 Podstawowy model COCOMO 81 ZłożonośćFormułaOpis przedsięwzięcia ProstaPM = 2,4 (KDSI) 1,05 * MZrozumiałe programy użytkowe tworzone przez małe zespoły. ŚredniaPM = 3,0 (KDSI) 1,12 * MBardziej złożone przedsięwzięcia, w których członkowie zespołu mogą mieć ograniczone doświadczenia z podobnymi systemami. WbudowanaPM = 3,6 (KDSI) 1,20 * MZł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.

27 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 27 Modele algorytmiczne kosztów w planowaniu przedsięwzięć l 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. l 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.

28 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 28 Składniki, które trzeba wziąć pod uwagę przy kosztorysowaniu przedsięwzięcia: l Koszt docelowego sprzętu, na którym będzie działał system. l Koszt platformy (komputer i oprogramowanie) do budowania systemu. l Koszt pracy niezbędnej do utworzenia oprogramowania.

29 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 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

30 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 30 Koszty opcji menedżerów Opcja RELY STOR TIME TOOL LTEX Całkowity Koszt KosztKoszt wysiłek oprogramowania sprzętu całkowity A 1,39 1,06 1,11 0,86 1 63 949 393 100 000 1 049 393 B 1,39 1 1 1,12 1,22 88 1 313 550 120 000 1 402 025 C 1,39 1 1,11 0,86 1 60 895 653 105 000 1 000 653 D 1,39 1 1,11 0,86 0,84 51 769 008 100 000 897 490 E 1,39 1 1 0,72 1,22 56 844 425 220 000 1 044 159 F 1,39 1 1 1,12 0,84 57 851 180 120 000 1 002 706

31 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 31 Czas trwania przedsięwzięcia i praca personelu l 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 i jaki personel będzie potrzebny w przedsięwzięciu. l 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ą. l 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.

32 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 32 Formuła do szacowania czasu w modelu COCOMO l TDEV = 3 X (PM) (0,33 + 0,2 x (B – 1,01)) l 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.

33 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 33 Przykład l Aby zilustrować obliczenie harmonogramu tworzenia w COCOMO, przypuśćmy, że pracę niezbędną do ukończenia przedsięwzięcia oszacowano na 60 miesięcy. l Załóżmy też, że wartością wykładnika B jest 1,17. l Na podstawie równania harmonogramu obliczamy czas niezbędny do ukończenia przedsięwzięcia: TDEV = 3(60) 0,36 = 13 miesięcy

34 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 34 Główne tezy l 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. l 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. l Oprogramowanie jest często wyceniane tak, żeby zdobyć kontrakt. Funkcjonalność systemu dostosowuje się później do oszacowanej ceny. l 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.

35 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 35 Główne tezy l 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. l Modele algorytmiczne kosztów są cenne dla kierownictwa, ponieważ pomagają w ilościowej analizie opcji. Umożliwiają obliczenie kosztów różnorodnych wariantów. l 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ć.