Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 1 Szacowanie kosztu oprogramowania l Szacowanie kosztu i pracy niezbędnej do wyprodukowania."— Zapis prezentacji:

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

2 ©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

3 ©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

4 ©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)

5 ©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ę

6 ©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

7 ©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

8 ©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

9 ©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ą

10 ©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

11 ©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

12 ©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

13 ©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

14 ©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 200-300 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

15 ©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

16 ©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

17 ©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 23Slide 17 l Systemy czasu rzeczywistego, 40-160 LK/PM l Programy systemowe, 150-400 LK/PM l Aplikacje komercyjne, 200-800 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

18 ©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ść

19 ©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ść

20 ©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

21 ©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

22 ©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

23 ©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!

24 ©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

25 ©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

26 ©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

27 ©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

28 ©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

29 ©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

30 ©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

31 ©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

32 ©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

33 ©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

34 ©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

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

36 ©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

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

38 ©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

39 ©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ść

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

41 ©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

42 ©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

43 ©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

44 ©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

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

46 ©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

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

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

49 ©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

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

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

52 ©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

53 ©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) (0.33+0.2*(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

54 ©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


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

Podobne prezentacje


Reklamy Google