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

1. Inżynieria Oprogramowania10. Szacowanie kosztu oprogramowaniacz. 1 Leszek J Chmielewski Wydział Zastosowań Informatyki i MatematykiSGGW www.lchmiel.pl

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 • $ 180000 rocznie na pracownika • Netto + podatek: • $ 90000 rocznie  $ 7500 miesięcznie

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

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 • 200-300 wierszy w asemblerze • 2-40 wierszy w 4GL

21. Punkty/wiersze a produktywność • osobomiesiąc = koszt pracy ($ 7500) • 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 • 200-300 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ń