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

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

©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

©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?

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 5 Tworzenie oprogramowania l 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 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, na przykład księgowe, sekretarki, sprzątaczki i technicy. l Koszt sieci i telekomunikacji. l Koszt udogodnień centralnych, takich jak biblioteka, pomieszczenia rekreacyjne. l Koszt ubezpieczenia społecznego, m.in. świadczenia dla pracowników, takie jak emerytury i ubezpieczenie zdrowotne.

©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 czynniki 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 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ń. 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.

©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 Jedno rozwiązanie może działać bardziej efektywnie, podczas gdy inne jest bardziej czytelne i łatwiejsze do pielęgnacji. l Gdy pojawiają się dwa rozwiązania o różnych atrybutach, porównywanie szybkości ich tworzenia nic tak naprawdę nie daje. 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. Produktywność

©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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 10 l 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. l Podejście to opracowano, gdy większość programów powstawała w językach FORTRAN, asembler i COBOL. l 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 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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 12 Praca programisty l 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. l 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 2000Software Engineering, 6th edition. Chapter 23Slide 13 Punkty funkcyjne 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.

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 14 Punkty obiektowe l 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 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ą zastosowanianajprawdopodobniej najbardziej 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.

©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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 18 Metody szacowania kosztów 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ęć. 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. 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.

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

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

©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. l Oszacowania staja się coraz bardziej precyzyjne.

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

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

©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 Stosowano i oceniano go szeroko. 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 r. (Boehm i inni).

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 26 Podstawowy model COCOMO 81 ZłożonośćFormułaOpis ProstePM = 2,4 (KDSI) 1,05 * MZrozumiałe programy użytkowe tworzone przez małe zespoły. ŚredniePM = 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. WbudowanePM = 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.

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

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

©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

©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, B 1, ,12 1, C 1,39 1 1,11 0, D 1,39 1 1,11 0,86 0, E 1, ,72 1, F 1, ,12 0,

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 32 Formuła do szacowani czasu kalendarzowego 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.

©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 l W tym wypadku nie ma skracania ani wydłużania harmonogramu, więc ostatni czynnik wzoru nie ma wpływu na obliczenia.

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

©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, co - nawet mimo błędów - umożliwia porównanie ich na podstawie obiektywnych kryterió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ć.