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 www.lchmiel.pl

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

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

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

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ę

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

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

Koszt pracy: przykład z podręcznika Brutto $ 180 000 rocznie na pracownika Netto + podatek: $ 90 000 rocznie  $ 7 500 miesięcznie

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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ń