1 Inżynieria Oprogramowania 10. Szacowanie kosztu oprogramowania cz. 126/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 + serwisPodróże i szkolenia Praca (zapłata inżynierom oprogramowania) Zazwyczaj dominuje praca
7 Koszt pracy Składniki kosztu pracy Wynagrodzenianetto (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ęcznikaBrutto $ rocznie na pracownika Netto + podatek: $ rocznie $ miesięcznie
9 Kalkulacja ceny dla klientaTypowa 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 roboczogodzinnie 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 koduliczba 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ższaJednak czas krótszy w języku wysokiego poziomu A do tego taniej
15 Miary funkcyjne Funkcjonalność nie zależy od języka implementacjiIstnieje 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 funkcyjnychliczbę 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 =
17 Modyfikacje UFC Na podstawie ogólnej złożoności przedsięwzięciastopień 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 obiektowychUż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ówOszacowanie:
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ówOszacowanie:
23 Czynniki produktywnościWiedza 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 sposobuWiele 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 szacowaniaMetody 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 historiiZmiana 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ń