Szacowanie kosztu oprogramowania

1. Szacowanie kosztu oprogramowania • Przedstawienie metod szacowania kosztu i pracy niezbędnej do wyprodukowania oprogramowania

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.

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

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?

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

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.

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.

8. Produktywność • 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.

9. Rodzaje miar • 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.

10. Praca programisty • 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.

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

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.

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.

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.

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.

16. Problemy z miarami • 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.

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.

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ę. OcenaZasię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.

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.

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.

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.

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.

23. Niepewność oszacowania 4 x 2 x x Wykonalność Wymagania Projekt Kod Dostarczenie 0 . 5 x 0 . 2 5 x

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.

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

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.

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.

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.

29. Opcje menedżerów • Użycie istniejącego sprzętu, • systemu tworzenia i zespołu • wytwórczego C. Ulepszenie tylko pamięci Rośnie koszt sprzętu D. Bardziej doświadczony personel B. Ulepszenie procesora i pamięci Rośnie koszt sprzętu Doświadczenie maleje E. Nowy system tworzenia Rośnie koszt sprzętu Doświadczenie maleje F. Personel z doświadczeniami ze sprzętem

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

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

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

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

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