Szacowanie kosztu oprogramowania

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

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

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

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

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

6. Czynniki wpływające na cenę

7. Produktywność programistów • 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

8. Miary produktywności • 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

9. Problemy z 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

10. Linie kodu • 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

11. Porównywanie produktywności • 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

12. Języki wysokiego i niskiego poziomu

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

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

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

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

17. Szacunki produktywności • 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

18. Czynniki wpływające na produktywność

19. Jakość i 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ć

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

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

22. Modelowanie algorytmiczne • Tworzenie obliczalnej formuły, która jest oparta na danych historycznych i generalnie ocenia koszt oprogramowania na podstawie jego rozmiaru

23. 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!

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

25. Prawo Parkinsona • Przedsięwzięcie zużyje wszystkie dostępne zasoby • Zalety: Nie przekroczymy budżetu • Wady: Zazwyczaj nie ukończymy systemu

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

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

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

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

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

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

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

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

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

35. Niepewność

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

37. COCOMO 81

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

39. 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 • PMto praca w osobomiesiącach, NOP to liczba punktów obiektowych a PROD to produktywność

40. Produktywność w punktach obiektowych

41. Poziom wczesnego projektowania • Oszacowania można dokonać po uzgodnieniu wymagań • Oparte jest na standardowej formule • PM = A´WielkośćB´M + PMmgdzie • 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

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

43. 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. ASLOCto liczba linii kodu koniecznych do zmodyfikowania, DM to procent modyfikowanego projektu, CM to procent modyfikowanego kodu, IM to odsetek pierwotnej pracy integracyjnej. • SUto czynnik oparty na koszcie zrozumienia kodu, AA to czynnik odzwierciedlający koszt ustalenia czy oprogramowanie może być użyte wielokrotnie

44. Wykładnik • 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

45. Czynniki

46. Mnożniki • 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

47. Czynniki kosztów przedsięwzięcia

48. Wpływ czynników kosztów

49. Planowanie przedsięwzięcia • 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

50. Opcje menedżerów