©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Szacowanie kosztu oprogramowania l Szacowanie kosztu i pracy niezbędnej do wyprodukowania oprogramowania

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 2 Zawartość l Produktywność l Metody szacowania l Modelowanie algorytmiczne kosztów l Czas trwania przedsięwzięcia i praca personelu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 3 Najważniejsze pytania szacowania l Ile pracy trzeba na ukończenie czynności? l Ile czasu kalendarzowego trzeba na ukończenie czynności? l Jaki jest całkowity koszt czynności? l Szacowanie i ustalanie harmonogramu przedsięwzięcia zwykle wykonuje się równolegle

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 4 Składniki kosztu l Koszty sprzętu i oprogramowania l Koszty podróży i szkoleń l Koszty pracy (zazwyczaj dominujące) Płace programistów Ubezpieczenie i podatki l Dodatkowe koszty, które trzeba brać pod uwagę wynajęcie budynku, ogrzewanie i oświetlenie koszt sieci i komunikacji udogodnienia centralne (biblioteka, pomieszczenia rekreacyjne)

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 5 Kosztorysowanie i wycena l Koszt wytworzenia oprogramowania jest szacowany l Nie ma prostej zależności pomiędzy kosztem wytworzenia oprogramowania i ceną przedstawianą klientowi l Szerokie powody organizacyjne, ekonomiczne, polityczne i biznesowe wpływają na ostateczną cenę

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 6 Czynniki wpływające na cenę CzynnikOpis Okazja rynkowa Przedsiębiorstwo produkujące może podać niską cenę, aby wejść na nowy segment rynku. Zdobyte doświadczenie może potem zaprocentować Niepewność kosztów Jeśli oszacowanie kosztów jest niepewne, to przedsiębiorstwo może sobie zostawić większy niż zazwyczaj margines zysku Warunki umowy Jeśli kod zostaje własnością przedsiębiorstwa, to może ono obniżyć cenę licząc na jego wielokrotne wykorzystanie Płynność wymagań Jeśli wymagania będą się zmieniać, to przedsiębiorstwo może obniżyć cenę żądając później wyższej ceny za zmiany wymagań Kondycja finansowa Firma w złej kondycji finansowej może obniżać swoje ceny. Od wypadnięcia z rynku lepszy jest mały zysk lub nawet strata

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 7 l Miara indywidualnego wkładu pracy włożonej przez pojedynczego programistę w tworzenie systemu i dokumentacji l Nie jest rozpatrywana jakościowo, chociaż zapewnienie jakości jest jednym z procesów podczas tworzenia oprogramowania l Generalnie chcemy mierzyć jak duża funkcjonalność produkowana jest w jednostce czasu Produktywność programistów

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 8 l Miary wielkościowe oparte są na części wyników powstających podczas tworzenia oprogramowania. Mogą to być linie kodu, klasy itp. l Miary funkcyjne są związane z funkcjonalnością dostarczonego oprogramowania. Punkty funkcyjne to najlepiej znana miara tego typu Miary produktywności

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 9 l Określenie metody pomiaru l Określenie czasu pracy programistów l Oszacowanie produktywności poddostawców (np. dokumentacja) i umieszczenie tego czasu w całkowitym szacowaniu Problemy z produktywnością

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 10 l 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 l Które programy są częściami systemu? l Zakłada zależność liniową pomiędzy rozmiarem systemu a dokumentacji Linie kodu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 11 l 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 l 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 Porównywanie produktywności

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 12 Języki wysokiego i niskiego poziomu AnalizaProjektowani e KodowanieTestowanieDokumentowani e Asemble r 3 tyg.5 tyg.8 tyg.10 tyg.2 tyg. Java3 tyg.5 tyg.8 tyg.6 tyg.2 tyg. WielkośćPracaProduktywność Asemble r 5000 wierszy 28 tygodni 714 w/m Java1500 wierszy 20 tygodni 300 w/m

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 13 Punkty funkcyjne l 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 l Z każdym elementem jest skojarzona waga (3-15) l Liczba punktów funkcyjnych jest wyznaczana na podstawie sumy wag elementów systemu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 14 Punkty funkcyjne l Punkty funkcyjne powinny uwzględniać czynnik skomplikowania przedsięwzięcia l 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 dla asemblera do 2-40 dla języków czwartej generacji l PF są subiektywne i zależą od szacującego Nie można policzyć punktów funkcyjnych automatycznie

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 15 Punkty obiektowe l Punkty obiektowe są alternatywą dla miar zorientowanych na funkcje i są używane w językach czwartej generacji l Punkty obiektowe NIE są klasami l 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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 16 Szacowanie punktów obiektowych l Punkty obiektowe są łatwiejsze do oszacowania na podstawie specyfikacji niż punkty funkcyjne l Można je szacować we wczesnych fazach procesu tworzenia oprogramowania. W tej fazie bardzo trudno szacować liczbę linii kodu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 17 l Systemy czasu rzeczywistego, LK/PM l Programy systemowe, LK/PM l Aplikacje komercyjne, LK/PM l W punktach obiektowych produktywność wynosi od 4 do 50 punktów na miesiąc w zależności od stosowanych narzędzi Szacunki produktywności

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 18 Czynniki wpływające na produktywność CzynnikOpis Wiedza z dziedziny zastosowania Inżynierowie rozumiejący dziedzinę są bardziej produktywni Jakość procesuIm lepszy proces tworzenia tym wyższa produktywność Wielkość przedsięwzięcia Im większe przedsięwzięcie tym więcej komunikacji potrzeba i zmniejsza się produktywność Wspomaganie technologiczne Narzędzia CASE i pomocnicze systemy zwiększają efektywność Środowisko pracyCiche środowisko pracy z prywatnymi miejscami pracy zwiększa produktywność

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 19 l Metryki mierzące rozmiar jednostkowej czynności mają zapominają o jakości l Produktywność łatwo zwiększyć zmniejszając jakość l Trudno ocenić jak miary jakości i produktywności mają się do siebie l Jeśli zmiany następują ciągle to podejście polegające na liczeniu linii kodu przestaje się liczyć Jakość i produktywność

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 20 Techniki szacowania l 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ą l Szacunki mogą być samospełniające Szacunki określają budżet a produkt jest dostosowywany do budżetu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 21 Techniki szacowania l Algorytmiczne modelowanie kosztów l Ocena ekspertów l Szacowanie przez analogię l Prawo Parkinsona l Ustalanie ceny pod zwycięstwo

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 22 Modelowanie algorytmiczne l Tworzenie obliczalnej formuły, która jest oparta na danych historycznych i generalnie ocenia koszt oprogramowania na podstawie jego rozmiaru

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 23 Ocena ekspertów l Jeden lub więcej ekspertów zarówno w dziedzinie tworzenia jak również użytkowania oprogramowania w dziedzinie szacują koszt. l Zalety: Relatywnie tania metoda. Może być dokładna jeśli eksperci mają doświadczenie z podobnymi systemami l Wady: bardzo niedokładna jeśli eksperci są kiepscy!

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 24 Przez analogię l Kosz jest obliczany przez porównanie przedsięwzięcia z podobnymi przedsięwzięciami z tej samej dziedziny l Zalety: Dokładna jeśli mamy dostęp do koniecznych danych l Wady: Nie można jej zastosować jeśli nie mamy z czym porównywać naszego przedsięwzięcia. Konieczna ciągła aktualizacja danych

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 25 Prawo Parkinsona l Przedsięwzięcie zużyje wszystkie dostępne zasoby l Zalety: Nie przekroczymy budżetu l Wady: Zazwyczaj nie ukończymy systemu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 26 Cena pod zwycięstwo l Cena przedsięwzięcia to tyle ile klient może wydać l Zalety: Mamy kontrakt l Wady: Prawdopodobieństwo, że klient otrzyma system jakiego chciał jest małe. Koszty nie odwzorowują nakładu pracy

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 27 Zstępujące i wstępujące szacowanie kosztów l W każdej metodzie można zastosować oba l Zstępujące Zaczynamy od poziomu całego systemu, określamy jego koszt a następnie dopasowujemy ją do podsystemów l Wstępujące Zaczynamy od wyceny komponentów a dopiero potem je sumujemy

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 28 Zstępujące l Można go używać nie rozumiejąc jaka jest architektura systemu i z jakich komponentów może się on składać l Bierze pod uwagę koszt integracji, konfiguracji i dokumentacji l Za nisko szacuje trudne do rozwiązania problemy techniczne

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 29 Wstępujące l Konieczna jest znajomość architektury systemu l Metoda jest dokładna jeśli system został zaprojektowany w szczegółach l Za nisko szacuje koszty integracji i dokumentacji

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 30 Metody szacowania l Każda ma swoje mocne i słabe strony l Szacowanie powinno być oparte na kilku metodach l Jeśli różne metody zwracają różne wyniki, to znaczy to, że jest za mało danych l Trzeba wtedy podjąć działania mające na celu znalezienie brakujących danych l Czasami jedynie ustalanie ceny pod zwycięstwo jest dopuszczalne

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 31 Szacowanie oparte na doświadczeniu l Szacowanie jest oparte głównie na doświadczeniu l 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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 32 Szacowanie pod zwycięstwo l Wydaje się nieetyczne i niebiznesowe l Jednak, przy braku koniecznych informacji może być jedyną drogą l Koszt przedsięwzięcia jest uzgodniony i ogranicza on jego zakres l Można negocjować dokładną specyfikację lub użyć podejścia ewolucyjnego

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 33 Modelowanie algorytmiczne l Koszt jest otrzymywany jako funkcja atrybutów produktu, przedsięwzięcia i procesu tworzenia szacowanych przez menadżerów Praca = A Rozmiar B 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 l Jako rozmiar najczęściej bierze się rozmiar kodu l Modele są podobne za wyjątkiem różnych wartości A, B i M

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 34 Dokładność szacowania l Rozmiar systemu znamy dokładnie po jego ukończeniu l Czynniki mające wpływ na rozmiar Użycie gotowych komponentów Język programowania Dystrybuowanie systemu l W miarę postępu prac dokładność szacowania się zwiększa

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 35 Niepewność

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 36 Model COCOMO l Model empiryczny oparty na doświadczeniu l Dobrze udokumentowany i niezależny od żadnej dużej firmy l Pierwsza wersja z 1981 roku (COCOMO-81) aktualna COCOMO 2 l COCOMO 2 bierze pod uwagę różne podejścia do procesu tworzenia oprogramowania

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 37 COCOMO 81

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 38 Poziomy COCOMO 2 l COCOMO 2 jest modelem trójpoziomowym który pozwala na szacowanie kosztów z wzrastającą dokładnością l Poziom wczesnego prototypowania Podstawą oszacowań są punkty obiektowe l Poziom wczesnego projektowania Podstawą oszacowań są punkty funkcyjne przeliczane na linie kodu l Poziom post-architektoniczny Podstawą oszacowań jest rozmiar kodu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 39 Poziom wczesnego prototypowania l Gotowe do użycia w fazie prototypowania z dużym wykorzystaniem wielokrotnego użycia l Oparte na szacowaniu produktywności programisty w punktach obiektowych na miesiąc l Bierze pod uwagę użycie narzędzi CASE l Formuła wygląda następująco: PM = ( NOP (1 - %reuse/100 ) ) / PROD PM to praca w osobomiesiącach, NOP to liczba punktów obiektowych a PROD to produktywność

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 40 Produktywność w punktach obiektowych

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 41 Poziom wczesnego projektowania l Oszacowania można dokonać po uzgodnieniu wymagań l Oparte jest na standardowej formule PM = A Wielkość B M + PM m gdzie M = PERS RCPX RUSE PDIF PREX FCIL SCED PM m = ( 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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 42 Mnożniki l 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 l PM m - ilość automatycznie generowanego kodu

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 43 Poziom post-architektoniczny l Używa tych samych formuł co poprzedni l 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. ASLOC to liczba linii kodu koniecznych do zmodyfikowania, DM to procent modyfikowanego projektu, CM to procent modyfikowanego kodu, IM to odsetek pierwotnej pracy integracyjnej. »SU to czynnik oparty na koszcie zrozumienia kodu, AA to czynnik odzwierciedlający koszt ustalenia czy oprogramowanie może być użyte wielokrotnie

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 44 l Zależy od pięciu czynników. Ich suma jest dzielona przez 100 i dodawana do 1.01 l 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 l Wykładnik wynosi więc 1.17 Wykładnik

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 45 Czynniki

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 46 l Atrybuty produktu Oczekiwane właściwości tworzonego produktu l Atrybuty komputera Ograniczenia narzucone przez wybór platformy sprzętowej l Atrybuty personelu Doświadczenie i możliwości osób biorących udział w przedsięwzięciu l Atrybuty przedsięwzięcia Właściwości przedsięwzięcia budowania oprogramowania Mnożniki

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 47 Czynniki kosztów przedsięwzięcia

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 48 Wpływ czynników kosztów

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 49 l Algorytmiczne modelowanie kosztu może stanowić podstawę dla planowania. Pozwala na porównywanie różnych strategii l System w statku kosmicznym Niezawodny Mała waga (mało układów scalonych) Mnożniki niezawodności i sprzętu > 1 l Składniki kosztu Sprzęt docelowy Platforma tworzenia oprogramowania Wymagany wysiłek Planowanie przedsięwzięcia

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 50 Opcje menedżerów

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 51 Koszt różnych opcji

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 52 Wybór opcji l Opcja D (lepszy personel) wydaje się być najlepsza Niestety ryzyko nie znalezienia doświadczonego personelu jest wysokie l Opcja C (więcej pamięci) mniej oszczędza koszty ale jest mniej ryzykowna l Model pokazuje, że bardzo ważny jest doświadczony personel

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 53 Czas trwania przedsięwzięcia l Oprócz kosztu konieczne jest szacowanie czasu trwania przedsięwzięcia l Formuła COCOMO 2 TDEV = 3 (PM) ( *(B-1.01)) PM oszacowanie pracy B wykładnik obliczony uprzednio (1 dla wczesnego prototypu) l Konieczny czas jest niezależny od liczby osób zaangażowanych w przedsięwzięcie

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 54 Praca personelu l Nie można obliczyć rozmiaru zespołu dzieląc oszacowanie pracy przez pensję l W różnych fazach w przedsięwzięcie jest zaangażowana różna liczba ludzi l Im więcej ludzi zaangażowanych tym większe oszacowanie pracy l Gwałtowny wzrost liczby osób zbiega się z opóźnieniem harmonogramu