Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 1

Prezentacja na temat: "Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 1"— Zapis prezentacji:

1 Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 1
26/03/2017 Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 1 Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW

2 Źródła Materiały dra Waldemara Karwowskiego, wykładowcy w poprzednich semestrach Ian Sommerville, Inżynieria Oprogramowania, WNT, Warszawa 2003

3 Plan Wstęp Produktywność Metody szacowania kosztów Podsumowanie

4 Plan Wstęp Produktywność Metody szacowania kosztów Podsumowanie

5 Wstęp Manager powinien wiedzieć:
Ile pracy trzeba na ukończenie czynności? Ile czasu kalendarzowego potrzeba? Jaki jest całkowity koszt? Oszacowanie kosztu jest potrzebne przed harmonogramem: Aby ustalić budżet Aby wyznaczyć cenę dla klienta Oszacowania trzeba aktualizować Aby modyfikować zasoby lub pracę

6 Składniki kosztu Koszt sprzętu i oprogramowania + serwis
Podróże i szkolenia Praca (zapłata inżynierom oprogramowania) Zazwyczaj dominuje praca

7 Koszt pracy Składniki kosztu pracy Wynagrodzenia
netto (w PL około 2/3 ceny etatu) podatki świadczenia: ubezpieczenie zdrowotne, emerytury, ... Koszty ogólne (narzut) przestrzeń biurowa: budynek, energia personel pomocniczy sieć i telekomunikacja udogodnienia centralne: biblioteka, rekreacja, ... Koszty ogólne zazwyczaj stanowią 100% wynagrodzenia

8 Koszt pracy: przykład z podręcznika
Brutto $ rocznie na pracownika Netto + podatek: $ rocznie  $ miesięcznie

9 Kalkulacja ceny dla klienta
Typowa metoda: Cena = koszt + zysk Godziwy zysk: np % Trzeba realnie oszacować koszt Jednak zwykle związek koszt-cena nie jest tak prosty

10 Ustalanie ceny Zagadnienia firmowe, ekonomiczne, polityczne, gospodarcze Ustala wyższe kierownictwo + managerowie przedsięwzięć programistycznych Czynniki: Okazja rynkowa wejście w nowy segment rynku, oczekiwanie późniejszych zysków, zdobycie doświadczenia Niepewność szacowania kosztów rezerwa na rzecz niepewności Korzystne/niekorzystne warunki umowy + np. zgoda klienta na zatrzymanie praw do kodu źródłowego przez wykonawcę  ponowne wykorzystanie – np. wymaganie klienta aby zachować tajność zadania Płynność wymagań prawdopodobieństwo zmian wymagań to okazja do obniżenie ceny początkowej i przewidywania wysokiej ceny za zmianę wymagań Kondycja finansowa wykonawcy zła kondycja zmusza do obniżenia ceny, aby nie stracić kontraktu – lepszy mniejszy (ujemny?) zysk niż nic

11 Plan Wstęp Produktywność Metody szacowania kosztów Podsumowanie

12 Produktywność Liczba wyrobów / liczba roboczogodzin
nie działa Kod ma wiele atrybutów jakości efektywność czytelność i podatność na pielęgnację Mimo to jakoś trzeba szacować P. Miary wielkościowe liczba wierszy, l. instrukcji kodu pośredniego, liczba stron dokumentacji Miary funkcyjne kategorie ilości dostarczonej użytecznej funkcjonalności punkty funkcyjne, punkty obiektowe

13 Miary wielkościowe Liczba wierszy kodu
liczba wierszy ~ koszt w miesiącach to czas na analizę, projektowanie, kodowanie, dokumentowanie Jest to podejście powstałe w czasach asemblerów, FORTRANu i COBOLu Co z komentarzami, deklaracjami, makrodefinicjami? Co z ekspresyjnością języka? Standardy liczenia wierszy [Park 1992] mało znane Zatem, wyniki nieporównywalne zależne jedynie od fazy programowania, choć dotyczą wszystkich faz

14 Przykład Produktywność w asemblerze – wyższa
Jednak czas krótszy w języku wysokiego poziomu A do tego taniej

15 Miary funkcyjne Funkcjonalność nie zależy od języka implementacji
Istnieje wiele miar [McDonell 1994] Miara punktów funkcyjnych [Albrecht 1979], [Albrecht, Gaffney 1983] dobra dla systemów, w których dominują operacje we/wy prod. = liczba punktów funkcyjnych / osobomiesiąc liczbę p.f. szacuje się na podstawie elementów: zewnętrzne dane we i wy interakcje z użytkownikiem interfejsy zewnętrzne pliki (wewnętrzne) używane przez system każdy element otrzymuje punkty od 3 – proste zewnętrzne dane wyjściowe do 15 – złożone pliki wewnętrzne

16 Miara punktów funkcyjnych
liczbę p.f. szacuje się na podstawie elementów: zewnętrzne dane we i wy interakcje z użytkownikiem interfejsy zewnętrzne pliki (wewnętrzne) używane przez system każdy element otrzymuje punkty od 3 – proste zewnętrzne dane wyjściowe do 15 – złożone pliki wewnętrzne UFC =  <liczba elementów danego typu> <waga typu elementu> UFC: Unadjusted Function-point Count a potem się modyfikuje (adjust)

17 Modyfikacje UFC Na podstawie ogólnej złożoności przedsięwzięcia
stopień rozproszenia przetwarzania zakres użycia wielokrotnego efektywność kodu ... UFC mnoży się przez współczynniki  Silna zależność od rozsądku kosztorysanta Opinie o metodzie bardzo zróżnicowane Użytkownicy stosują z powodzeniem

18 Metoda punktów obiektowych
Używając języka czwartej generacji (4GL) można zastosować metodę punktów obiektowych [Banker et al. 1992] prod. = liczba p.o. / osobomiesiąc liczbę p.o. szacuje się na podstawie: liczba różnych wyświetlanych ekranów (1: prosty, 3: bardzo złożony) liczba tworzonych raportów (2: prosty, 5: średni złożony, 8: prawdopodobnie trudny do utworzenia) liczba modułów 3GL, które trzeba będzie opracować dla uzupełnienia kodu 4GL (10: każdy moduł)

19 Cechy metod punktów funkc./obiekt.
Metoda punktów obiektowych jest łatwiejsza w zastosowaniu do specyfikacji oprogramowania wysokiego poziomu Obydwu metod można użyć przed decyzją o języku implementacji Wystarczy znać strukturę przetwarzania Można także połączyć je z metodami wielkościowymi próbując szacować liczbę linii kodu/punkt

20 Metody wielkościowe/m. punktów
Oszacowanie: <wielkość kodu> = AVC * <liczba pkt. funkcyjnych> AVC: Average number of Verses of Code wierszy w asemblerze 2-40 wierszy w 4GL

21 Punkty/wiersze a produktywność
osobomiesiąc = koszt pracy ($ 7 500) osobomiesiąc może napisać / przez osobomiesiąc można napisać / potrzeba osobomiesiąca aby napisać 30 wierszy (złożony system wbudowany) 900 wierszy (programy łatwe do zrozumienia) 4-50 punktów obiektowych „Wierszówka”? Upraszczanie kodu? pomijamy ważne czynniki: funkcjonalność, efektywność, zdatność do pielęgnacji, niezawodność, bezpieczeństwo, ...

22 Metody wielkościowe/m. punktów
Oszacowanie: <wielkość kodu> = AVC * <liczba pkt. funkcyjnych> AVC: Average number of Verses of Code wierszy w asemblerze 2-40 wierszy w 4GL

23 Czynniki produktywności
Wiedza z dziedziny zastosowania Jakość procesu tworzenia oprogramowania Wielkość przedsięwzięcia duże  więcej komunikacji Wsparcie technologiczne Dobre środowisko pracy ciche, prywatne miejsce pracy Najważniejsze: Zdolności różnice produktywności ponad 10-krotne

24 Plan Wstęp Produktywność Metody szacowania kosztów Podsumowanie

25 Nie ma prostego sposobu
Wiele czynników nieznanych Oszacowanie jako samospełniająca się przepowiednia Dobrze jest stosować więcej metod Podejście wstępujące i zstępujące wady/zalety: uzasadnienie na niskim poziomie (konkret)  koszty systemowe Badania menedżerów pokazują: szacowanie kosztów dość dokładne szacowanie wielkości oprogramowania niedokładne

26 Stosowane metody szacowania
Metody algorytmiczne oszacowana wielkość + historyczne wskaźniki    ...  koszt Ocena ekspertów szacunki porównuje się i omawia do uzyskania konsensusu Szacowanie przez analogię jeśli podobny system już wykonano Prawo Parkinsona praca w dostępnym czasie i przy wcześniej ustalonym budżecie Ustalanie ceny pod zwycięstwo koszt według możliwości klienta, wymagania dostosowuje się do kosztu

27 Powody zmian względem historii
Zmiana stylu programowania funkcyjne  obiektowe Zmiana architektury komputer główny  klient/serwer Komponenty z półki zamiast tworzenia Użycie wielokrotne własnych komponentów Użycie narzędzi CASE i generatorów  Utrudnia to menedżerom szacowanie kosztów

28 Plan Wstęp Produktywność Metody szacowania kosztów Podsumowanie

29 Podsumowanie Produktywność programisty zależy przede wszystkim od zdolności, a także od innych czynników Istnieje wiele metod szacowania kosztu przedsięwzięć; różnice wyników wskazują na uproszczenia modelu i nieadekwatność użytych informacji Cenę często ustala się tak, aby zdobyć kontrakt; funkcjonalność się dostosowuje Istnieją modele algorytmiczne; będą omówione w następnym wykładzie Dane do modeli są dobrze znane dopiero na końcu procesu wytwarzania; jednak modele są przydatne przynajmniej do porównań