Inżynieria oprogramowania - 23 Slide 1
Szacowanie kosztów oprogramowania
. Szacowanie zasobów
wymaganych w procesie tworzenia
oprogramowania
Inżynieria oprogramowania - 23 Slide 2
Cele
. Wprowadzenie podstawowych zasad szacowania
kosztów i ustalania ceny oprogramowania
. Opis trzech miar stosowanych do szacowania oceny
produktywności oprogramowania
. Wyjaśnienie dlaczego do szacowania kosztów
oprogramowania powinny być używane różne
techniki
. Opis algorytmicznego modelu szacowania kosztów -
COCOMO 2
Inżynieria oprogramowania - 23 Slide 3
Zawartość
. Produktywność
. Metody szacowania
. Modelowanie algorytmiczne kosztów
. Czas trwania przedsięwzięcia i praca personelu
Inżynieria oprogramowania - 23 Slide 4
Podstawowe pytania przy szacowaniu
. Ile pracy potrzeba na ukończenie czynności?
. Ile czasu kalendarzowego potrzeba na ukończenie
czynności?
. Jaki jest całkowity koszt czynności?
. Jak oszacować i ustalić harmonogram
przedsięwzięcia?
Inżynieria oprogramowania - 23 Slide 5
Składowe kosztu oprogramowania
. Koszty sprzętu i oprogramowania
. Koszty podróży i szkoleń
. Koszty pracy (dominujący czynnik w większości projektach)
. wynagrodzenie inżynierów zaangażowanych w projekt
. koszty socjalne i ubezpieczeniowe
. W koszty pracy wlicza się także:
. koszty udostępniania, ogrzania i oświetlenia budynków
. koszty sieci i komunikacji
. koszty udogodnień współdzielonych (np. biblioteka, restauracja dla
personelu itd.)
Inżynieria oprogramowania - 23 Slide 6
Sporządzanie kosztorysu i wycena
. Oszacowanie wykonywane jest w celu określenia
kosztu produkcji systemu oprogramowania
. Nie istnieje prosty związek pomiędzy kosztem
wytworzenia i ceną jaką obciążony jest klient
. Przy ustalaniu ceny oprogramowania należy wziąć
od uwagę ogólniejsze kwestie firmowe,
ekonomiczne, polityczne i gospodarcze
Inżynieria oprogramowania - 23 Slide 7
Czynniki wpływające na cenę
oprogramowania
Czynnik Opis
Okazja rynkowa Przedsiębiorstwo produkujące może podać niską cenę, ponieważ chce zaistnieć
w nowym segmencie rynku oprogramowania. Zgoda na mały zysk z jednego
przedsięwzięcia może dać okazję do późniejszych zysków. Zdobyte
doświadczenie może umożliwić tworzenie nowych produktów
Niepewność
oszacowania
kosztów
Jeśli przedsiębiorstwo nie jest pewne swoich szacunków kosztów, to może
zwiększyć cenę o pewien czynnik rezerwowy powyżej swego zwykłego zysku
Warunki umowy Klient może wyrazić zleceniobiorcy zgodę na zatrzymanie prawa do własności
kodu źródłowego i wielokrotne wykorzystanie go w następnych
przedsięwzięciach. Ustalona cena może być wówczas niższa niż w wypadku
przekazywania kodu źródłowego klientowi
Płynność wymagań Jeśli wymagania przypuszczalnie będą się zmieniać, to firma może obniżyć
cenę, aby zdobyć kontrakt. Po przyznaniu kontraktu może zażądać wysokich
cen za zmiany wymagań.
Kondycja finansowa Firmy produkujące w złej kondycji finansowej mogą obniżać swoje ceny w celu
zdobycia kontraktu. Od wypadnięcia z rynku lepszy jest mniejszy zysk.
Inżynieria oprogramowania - 23 Slide 8
. Miara szybkości, z którą poszczególni inżynierowie
zaangażowani w proces tworzenia oprogramowania
wytwarzają oprogramowanie i związaną z nim
dokumentację
. Nie zorientowana na jakość pomimo iż zapewnienie
jakości jest czynnikiem branym pod uwagę w ocenie
produktywności
. Zasadniczo, chcemy mierzyć użyteczną
funkcjonalność wytwarzaną w jednostce czasu
Produktywność programisty
Inżynieria oprogramowania - 23 Slide 9
. Miary wielkościowe - związane z wielkością
pewnego wyniku procesu tworzenia
oprogramowania. Mogą to być np. linie
dostarczonego kodu źródłowego
. Miary funkcyjne - bazują na szacowaniu
funkcjonalności dostarczanego oprogramowania.
Najbardziej znaną miarą tego typu są punkty
funkcyjne
Miary produktywności
Inżynieria oprogramowania - 23 Slide 10
. Rodzaj, wielkość miary
. Szacowanie całkowitej liczby miesięcy pracy
programisty
. Szacowanie produktywności wykonawcy (np. zespół
dokumentujący) i uwzględnienie tego w całkowitych
szacunkach
Problemy z pomiarami
Inżynieria oprogramowania - 23 Slide 11
. Co to są linie kodu?
. Pomiar taki zaproponowany został na początku kiedy programy
pisane były na kartach, jedna instrukcja na kartę
. Jak to odpowiada instrukcjom pisanym w języku Java, w którym
można łączyć kilka linii i gdzie kilka instrukcji może znajdować się
w jednej linii
. Jakie programy powinien być liczone jako część
systemu?
. Zakłada się liniowy związek pomiędzy rozmiarem
systemu i objętością dokumentacji
Linie kodu
Inżynieria oprogramowania - 23 Slide 12
. Język niskiego poziomu a wydajny programista
. Zaimplementowanie tej samej funkcjonalności w języku niskiego
poziomu wymaga większej liczby linii kodu niż w języku
wysokiego poziomu
. Rozwlekły programista a większa wydajność
. Mierzenie wydajności bazujące na liczbie linii kodu sugeruje, że
programista, który pisze rozwlekły kod jest bardziej wydajny niż
programista który pisze kod zwięzły
Porównania wydajności
Inżynieria oprogramowania - 23 Slide 13
Języki wysokiego i niskiego
poziomu
Analiza Projektowanie Kodowanie Zatwierdzanie
Analiza Projektowanie Kodowanie Zatwierdzanie
Język wysokiego poziomu
Język niskiego poziomu
Inżynieria oprogramowania - 23 Slide 14
Czas tworzenia systemu
Analiza Projekt Kodowanie Testowanie
3 tygodnie 5 tygodni 8 tygodni 10 tygodni 2 tygodnie
Dokumentacja
3 tygodnie 3 tygodnie 6 tygodni 6 tygodni 2 tygodnie
Wielkość Praca Produktywność
5000 linii 28 tygodni 714 linii/miesiąc
1500 linii 20 tygodni 300 linii/miesiąc
Analiza
Analiza
Analiza
Analiza
Inżynieria oprogramowania - 23 Slide 15
Punkty funkcyjne
. Bazują na zbiorze charakterystyk programu
. Zewnętrzne dane wejściowe i wyjściowe
. Interakcje z użytkownikiem
. Interfejsy zewnętrzne
. Pliki używane przez system
. Szacuje się złożoność każdego z wymienionych elementów i
przypisuje się im wagę
. Nie unormowana liczba punktów funkcyjnych obliczana jest
poprzez przemnożenie każdej liczby punktów przez wagę i
zsumowanie wszystkich wartości
Inżynieria oprogramowania - 23 Slide 16
Punkty funkcyjne
. Liczba punktów funkcyjnych modyfikowana jest poprzez czynnik
określający złożoność projektu
. Punkty funkcyjne mogą być użyte do oszacowania liczby linii
kodu (LOC) w zależności od średniej liczby linii kody
przypadającej na punkt funkcyjny dla danego języka
programowania
. LOC = AVC * liczba punktów funkcyjnych
. AVC jest czynnikiem zależnym od języka programowania: Assembler (200-300),
język 4GL (2-40)
. Punkty funkcyjne są bardzo subiektywne. Zależą one od osoby
dokonującej szacowania.
. Zautomatyzowanie procesu zliczania punktów funkcyjnych jest niemożliwe
Inżynieria oprogramowania - 23 Slide 17
Punkty obiektowe
. Punkty obiektowe są alternatywną opcją wobec punktów
funkcyjnych, wykorzystywaną kiedy do tworzenia
oprogramowania używa się języka 4GL lub podobnego
. Punkty obiektowe to nie to samo co klasy obiektów
. Liczba punktów obiektowych w programie jest miarą ważoną
następujących składników
. Liczby oddzielnych ekranów, które są wyświetlane
. Liczby raportów, które są tworzone przez system
. Liczby modułów 3GL które muszą być opracowane w celu uzupełnienia
kodu 4GL
Inżynieria oprogramowania - 23 Slide 18
Szacowanie punktów obiektowych
. Punkty obiektowe są łatwiejsze do oszacowania na
podstawie specyfikacji oprogramowania niż punkty
funkcyjne, ponieważ biorą pod uwagę ekrany,
raporty i moduły 3GL
. Punkty obiektowe mogą być oszacowane we
wstępnej fazie procesu tworzenia. Na tym etapie jest
bardzo ciężko oszacować liczbę linii kodu
Inżynieria oprogramowania - 23 Slide 19
. Systemy czasu rzeczywistego 40-160 LOC na miesiąc pracy
programisty
. Programy systemowe, 150-400 LOC na miesiąc pracy
programisty
. Aplikacje komercyjne 200-800 LOC na miesiąc pracy
programisty
. W przypadku punktów obiektowych, zmierzona
produktywność wynosi od 4 do 50 punktów
obiektowych/miesiąc zależnie od wsparcia narzędziowego i
umiejętności programistów
Szacowanie produkcyjności
Inżynieria oprogramowania - 23 Slide 20
Czynniki wpływające na
produktywność
Czynnik Opis
Wiedza z dziedziny
zastosowania
Wiedza z dziedziny zastosowania jest konieczna do skutecznego tworzenia
oprogramowania. Inżynierowie, którzy już rozumieją dziedzinę, będą
najprawdopodobniej najbardziej produktywni
Jakość procesu Zastosowany proces tworzenia może mieć znaczący wpływ na produktywność.
Wielkość
przedsięwzięcia
Im przedsięwzięcie jest większe, tym więcej trzeba komunikacji zespołu. Mniej
czasu pozostaje na tworzenie, więc indywidualna produktywność jest mniejsza
Wspomaganie
technologiczne
Dobre wspomaganie technologiczne, takie jak narzędzia CASE, pomocnicze
systemy zarządzania konfiguracjami itd. mogą poprawić produktywność
Środowisko pracy Ciche środowisko pracy z prywatnymi miejscami przyczynia się do wzrostu
produkcyjności
Inżynieria oprogramowania - 23 Slide 21
. Wszystkie miary wyrażane za pomocą
ilości/jednostkę czasu nie uwzględniają jakości
. Produktywność można zwiększyć kosztem jakości
. Nie jest jasne jak miary produktywność/jakość są
powiązane
. Jeśli zależność jest stała wtedy podejście bazujące na
liczeniu linii kodu nie jest sensowne
Jakość i produktywność
Inżynieria oprogramowania - 23 Slide 22
Metody szacowania
. Nie istnieje prosty sposób dokładnego szacowania pracy
niezbędnej do zbudowania systemu oprogramowania
. Wstępne szacunki bazują na niepełnych informacjach zawartych w definicji
wymagań
. Oprogramowanie może działać na nieznanych komputerach lub jego
tworzenie może odbywać się z użyciem nowej technologii
. Ludzie biorący udział w przedsięwzięciu mogą być nieznani
. Oszacowanie kosztów przedsięwzięcia może być
samospełniającą się przepowiednią
. Oszacowanie definiuje budżet przedsięwzięcia a produkt jest
dopasowywany tak aby zrealizować założenia budżetu
Inżynieria oprogramowania - 23 Slide 23
Metody szacowania kosztów
. Algorytmiczne modelowanie kosztów
. Ocena ekspertów
. Szacowanie przez analogię
. Prawo Parkinsona
. Ustalanie ceny pod zwycięstwo
Inżynieria oprogramowania - 23 Slide 24
Modelowanie algorytmiczne kosztów
. Używające formuły matematycznej podejście,
bazujące na historycznych informacjach na temat
kosztów, generalnie wykorzystujące rozmiar
oprogramowania
Inżynieria oprogramowania - 23 Slide 25
Opinia eksperta
. Jeden lub więcej ekspertów zarówno w tworzeniu
oprogramowania jak i dziedzinie zastosowania
wykorzystują swoje doświadczenie do oszacowania
kosztów oprogramowania. Proces powtarzany jest tak
długo aż zostanie osiągnięta pewna jednomyślność
. Zalety: Relatywnie tania metoda szacowania. Może
być precyzyjna jeśli eksperci posiadają doświadczenie
w budowaniu podobnych systemów
. Wady: Bardzo niedokładna jeśli nie istnieją
odpowiedni eksperci
Inżynieria oprogramowania - 23 Slide 26
Szacowanie poprzez analogię
. Koszt projektu obliczany jest poprzez jego
porównanie do innego projektu z tej samej dziedziny
zastosowania
. Zalety: Precyzyjne jeśli dostępne są dane projektowe
. Wady: Niemożliwe do zastosowania jeśli nie
ukończono porównywalnego projektu. Potrzebna jest
porządnie sporządzona baza danych o kosztach
Inżynieria oprogramowania - 23 Slide 27
Prawo Parkinsona
. Koszt projektu determinowany jest przez dostępne
zasoby
. Zalety: Nie przepłaca się
. Wady: System zwykle jest niedokończony
Inżynieria oprogramowania - 23 Slide 28
Ustalanie ceny pod zwycięstwo
. Koszt projektu szacowany jest na tyle, ile klient
może wydać na to przedsięwzięcie
. Zalety: Dostajesz kontrakt
. Wady: Prawdopodobieństwo, że klient otrzyma
system taki jak chciał jest małe. Koszty nie
odzwierciedlają dokładnie pracy jaką należy
wykonać
Inżynieria oprogramowania - 23 Slide 29
Szacowanie zstępujące i wstępujące
. Omawiane metody szacowania kosztów mogą być
realizowane za pomocą podejścia zstępującego lub
wstępującego
. Podejście zstępujące
. Rozpoczyna się na poziomie systemu i ocenia całościową funkcjonalność
systemu oraz sposob jej dostarczania przez podsystemy
. Podejście wstępujące
. Zaczyna się na poziomie komponentów i szacuje pracę potrzebną do
utworzenia każdego z tych komponentów. Następnie dodaje się pracę
potrzebną do integracji w celu ustalenia końcowego kosztu budowy całego
systemu
Inżynieria oprogramowania - 23 Slide 30
Szacowanie zstępujące
. Użyteczne w sytuacjach gdy nie posiadamy wiedzy
na temat architektury systemu i komponentów które
mogą być częścią systemu
. Bierze pod uwagę koszty związane z integracją,
zarządzaniem konfiguracją i dokumentowaniem
. Może nie docenić kosztów rozwiązywania trudnych
trudnych problemów technicznych
Inżynieria oprogramowania - 23 Slide 31
Szacowanie wstępujące
. Może być wykorzystywana kiedy znana jest
architektura systemu i zidentyfikowane są
komponenty
. Metoda precyzyjna jeśli system został
zaprojektowany w szczegółach
. Może nie docenić kosztów czynności systemowych
takich jak integracja i dokumentowanie
Inżynieria oprogramowania - 23 Slide 32
Metody szacowania
. Każda metoda ma słabe i mocne strony
. Szacowanie powinno bazować na kilku metodach
. Jeśli zastosowane metody nie dają porównywalnych wyników,
oznacza to że nie są dostępne wystarczające informacje
. Powinny być przedsięwzięte odpowiednie czynności w celu
zdobycia bardziej szczegółowych informacji w celu
opracowania bardziej dokładnych szacunków
. Zdarza się że jedyną odpowiednią metodą dająca się zastosować
jest metoda ustalania ceny pod zwycięstwo
Inżynieria oprogramowania - 23 Slide 33
Szacowanie bazujące na
doświadczeniu
. Szacowanie przede wszystkim bazuje na
doświadczeniu
. Jednakże, nowe metody i technologie mogą sprawić
iż szacowanie oparte na doświadczeniu może być
niedokładne
. Tworzenie obiektowe zamiast tworzenia funkcyjnego
. Systemy klient-serwer zamiast systemów na komputerze głównym
. Użycie komponentów z półki zamiast ich tworzenie
. Inżynieria oprogramowania bazująca na komponentach
. Użycie narzędzi CASE i generatorów programów
Inżynieria oprogramowania - 23 Slide 34
Ustalanie ceny pod zwycięstwo
. Podejście to wydaje się nieetyczne i niezgodne z ekonomią
. Jednakże, kiedy brak szczegółowych informacji, może okazać
się jedyna odpowiednią strategią
. Koszty projektu ustalane są na podstawie szkicowej
propozycji i tworzenie ograniczone jest poprzez koszt
. Szczegółowa specyfikacja może być negocjowana lub do
tworzenia systemu stosuje się podejście ewolucyjne
Inżynieria oprogramowania - 23 Slide 35
Algorytmiczne modelowanie kosztu
. Koszt szacowany jest jako matematyczna funkcja produktu,
projektu i atrybutów procesu których wartości są szacowane
przez menedżerów projektu
. Praca = A x WielkośćB x M
. A jest stałym czynnikiem zależnym od lokalnych zwyczajów firmy i
rodzaju tworzonego oprogramowania
. B odzwierciedla nieproporcjonalność pracy w przypadku wielkich
przedsięwzięć
. M jest to mnożnik odzwierciedlający atrybuty produktu, procesu i ludzi
. Najpowszechniej używanym atrybutem produktu dla szacowania
kosztów jest rozmiar kodu
. Większość modeli jest zasadniczo podobnych do siebie lecz mają
różne wartości stałych A, B i M
Inżynieria oprogramowania - 23 Slide 36
Dokładność szacowania
. Rozmiar systemu oprogramowania może być
dokładnie znany tylko wtedy gdy jest ukończony
. Szereg czynników wpływa na końcowy rozmiar
. Użycie COTS i komponentów
. Język programowania
. Rozproszenie systemu
. W miarę postępowania procesu tworzenia
szacowanie rozmiaru staje się coraz bardziej
dokładne
Inżynieria oprogramowania - 23 Slide 37
Niepewność oszacowania
x
2x
4x
0.5x
0.25x
Feasibility Requirements Design Code Delivery Wykonalność Wymagania Projekt Kod Dostarczanie
Inżynieria oprogramowania - 23 Slide 38
Model COCOMO
. Model empiryczny opierający się na doświadczeniu projektowym
. Dobrze udokumentowany .niezależny. model który nie jest
związany z określonymi sprzedawcami oprogramowania
. Długa historia od wstępnej wersji opublikowanej w 1981 roku
(COCOMO-81) przez różne wersje aż po COCOMO 2
. COCOMO 2 bierze pod uwagę różne podejścia do tworzenia
oprogramowania np. tworzenie z ponownym wykorzystaniem itd.
Inżynieria oprogramowania - 23 Slide 39
Model COCOMO 81
Złożoność
przedsięwzięcia
Proste Zrozumiałe programy użytkowe tworzone przez
małe zespoły
Średnie Bardziej złożone przedsięwzięcia, w których
członkowie zespoły mogą mieć ograniczone
doświadczenia z podobnymi systemami
Wbudowane Złożone przedsięwzięcia, w których
oprogramowanie jest częścią silnie powiązanego
złożonego sprzętu, oprogramowania, regulacji i
procedur działania
Formuła Opis
PM=2,4 (KDSI)1,05 x M
PM=3,0 (KDSI)1,12 x M
PM=3,6 (KDSI)1,20 x M
Inżynieria oprogramowania - 23 Slide 40
Poziomy COCOMO 2
. COCOMO 2 jest trzypoziomowym modelem który pozwala na
bardziej szczegółowe szacowanie w trakcie postępowania
procesu tworzenia oprogramowania
. Poziom wczesnego prototypowania
. Szacowanie bazujące na punktach obiektowych, następnie wykorzystywana jest
prosta formuła w celu oszacowania pracy
. Poziom wczesnego projektowania
. Szacowanie bazujące na punktach funkcyjnych które następnie tłumaczone są na
linie kodu (LOC)
. Poziom postarchitektoniczny
. Szacowanie opierające się na liniach kodu źródłowego
Inżynieria oprogramowania - 23 Slide 41
Poziom wczesnego prototypowania
. Wspomaganie szacowania pracy wymaganej w
przedsięwzięciach prototypowania i w przedsięwzięciach, w
których oprogramowanie tworzy się przez składanie istniejących
komponentów
. Bazuje na standardzie szacowania produktywności programistów
poprzez szacowanie punktów obiektowych/miesiąc
. Bierze pod uwagę narzędzia CASE
. Ostateczna formuła ma postać:
. PM= ( NOP × (1 - %reuse/100 )) / PROD
. PM to praca liczona w osobomiesiącach, NOP jest to liczba punktów
obiektowych, PROD to produktywność
Inżynieria oprogramowania - 23 Slide 42
Produktywność w punktach
obiektowych
Doświadczenie i
umiejętności
programisty
Dojrzałość i
możliwości CASE
PROD
(NOP/miesiąc)
Bardzo małe Małe Przeciętne Duże Bardzo duże
Bardzo małe Małe Przeciętne Duże Bardzo duże
4 7 13 25 50
Inżynieria oprogramowania - 23 Slide 43
Poziom wczesnego projektowania
. Szacowanie może być wykonane po uzgodnieniu wymagań
. Podstawą oszacowań opracowywanych na tym etapie jest
standardowa formuła modeli algorytmicznych
. PM= A × WielkośćB × M + PMm gdzie
. M= PERS × RCPX × RUSE × PDIF × PREX × FCIL × SCED
. PMm
= (ASLOC × (AT/100)) / ATPROD
. A = 2.5 we wstępnej kalibracji, Wielkość w KLOC, B zmienia się od 1,1 do
1,24 w zależności od nowości projektu, elastyczność tworzenia,
zastosowanego procesu panowania nad ryzykiem i stopnia dojrzałości
procesu
Inżynieria oprogramowania - 23 Slide 44
Mnożniki
. Mnożniki odzwierciedlają zdolności programistów,
wymagania niefunkcjonalne, znajomość tworzonej
platformy itd.
. RCPX - niezawodność i złożoność produktu
. RUSE - wymagane użycie wielokrotne
. PDIF - trudność platformy
. PREX -doświadczenia personelu
. PERS -możliwości personelu
. SCED - harmonogram
. FCIL - udogodnienia pomocnicze
. PM odzwierciedla ilość automatycznie generowanego
kodu
Inżynieria oprogramowania - 23 Slide 45
Poziom postarchitektoniczny
. Wykorzystuje te same formuły których używa się na poziomie
wczesnego projektowania
. Szacowanie przybliżenia wielkości oprogramowania powinny być
dokładniejsze
. Płynność wymagań - ponowne prace wymagane do wsparcia zmian
. Zakres możliwego użycia wielokrotnego - koszty użycia wielokrotnego są
nieliniowe tak więc nie jest to prosta redukcji linii kodu LOC
. ESLOC = ASLOC × (AA + SU +0.4DM + 0.3CM +0.3IM)/100
» ESLOC jest to równoważna liczba linii nowego kodu. ASLOC to liczba wierszy kodu
użycia wielokrotnego, które trzeba zmodyfikować, DM to wyrażony w procentach
odsetek modyfikowanego projektu, CM to wyrażony w procentach odsetek
modyfikowanego kodu, IM to wyrażony w procentach odsetek pierwotnej pracy
integracyjnej wymaganej przy integracji użytego wielokrotnie oprogramowania
» SU jest to czynnik, którego podstawą jest koszt zrozumienia oprogramowania, AA jest
to czynnik odzwierciedlający początkowy koszt ustalenia, czy oprogramowanie może
być użyte wielokrotnie=
Inżynieria oprogramowania - 23 Slide 46
. Wykładnik zależy od 5 czynników skali (zobacz następny
slajd). Ich suma podzielona przez 100 dodawana jest do
wartości 1,01
. Przykład
. Doświadczenie . nowy projekt . 4
. Elastyczność tworzenia . brak zaangażowania klienta . bardzo duża .
1
. Panowanie nad ryzykiem architektonicznym . brak analizy ryzyka .
bardzo niska . 5
. Spójność zespołu . nowy zespół . przeciętna . 3
. Dojrzałość procesu . pewien zakres panowania nad procesem .
przeciętna . 3
. Czynnik skali wynosi 1,17
Określanie wykładnika
Inżynieria oprogramowania - 23 Slide 47
Czynniki skali używane do
obliczenia wykładnika
Czynnik skali Wyjaśnienie
Doświadczenie Odzwierciedla wcześniejsze doświadczenia firmy z przedsięwzięciami tego
rodzaju. Mała wartość oznacza brak takich doświadczeń. Bardzo duża wartość
oznacza, że w firmie ta dziedzina zastosowania jest całkowicie poznana
Elastyczność
tworzenia
Odzwierciedla stopień elastyczności procesu tworzenia. Mała wartość oznacza
użycie nakazanego procesu. Bardzo duża wartość oznacza, żę klient ustala
jedynie ogólne cele.
Panowanie nad
ryzykiem
architektonicznym
Odzwierciedla zakres wykonywanej analizy ryzyka. Mała wartość oznacza
bardzo mało analizy. Bardzo duża wartość oznacza wykonywanie pełnej i
wyczerpującej analizy ryzyka
Spójność zespołu Wynika z niego jak dobrze znają się członkowie zespołu wytwórczego i jak ze
sobą pracują. Mała wartość oznacza bardzo trudną interakcję. Bardzo duża
wartość oznacza, że zespół jest zintegrowany i skuteczny oraz że nie ma
trudności komunikacyjnych
Dojrzałość procesu Odzwierciedla dojrzałość procesu w przedsiębiorstwie. Tę wartość oblicza się
na podstawie Kwestionariusza Dojrzałości CMM. Można ją jednak przybliżyć
przez odjęcie poziomu dojrzałości procesu CMM od pięciu
Inżynieria oprogramowania - 23 Slide 48
. Atrybuty produktu
. Związane z oczekiwanymi właściwościami tworzonego
produktu programowego
. Atrybuty komputera
. Ograniczenia narzucone na oprogramowanie przez platformę
sprzętową
. Atrybuty personelu
. Mnożniki które biorą pod uwagę doświadczenie i możliwości
osób pracujących w przedsięwzięciu
. Atrybuty przedsięwzięcia
. Związane z poszczególnymi charakterystykami przedsięwzięcia
budowania oprogramowania
Mnożniki
Inżynieria oprogramowania - 23 Slide 49
Czynniki kosztów przedsięwzięcia
Atrybuty produktu
RELY DATA Wymagana niezawodność systemu Rozmiar użytej bazy danych
CPLX REUSE Złożoność modułów systemowych Wymagany odsetek komponentów
użycia wielokrotnego DOCU Zakres wymaganej dokumentacji
TIME STOR Ograniczenia na czas działania Ograniczenia pamięciowe
PVOL Płynność platformy tworzenia
Atrybuty komputera
Atrybuty personelu
ACAP PCAP Możliwości analityków systemowych Możliwości programistów
PCON AEXP Ciągłość zatrudnienia personelu Doświadczenie analityków w
dziedzinie przedsięwzięcia PEXP
LTEX
Doświadczenie programistów w dziedzinie
przedsięwzięcia Doświadczenie w stosowaniu języków
i narzędzi
Atrybuty przedsięwzięcia
TOOL SITE Użycie narzędzi programowych Stopień rozproszenia pracy po różnych
ośrodkach i jakość komunikacji między
ośrodkami
SCED Kompresja harmonogramu tworzenia
Inżynieria oprogramowania - 23 Slide 50
Wpływ czynników kosztów na
oszacowanie pracy
Wartość wykładnika 1,17
Wielkość systemu (z uwzględnieniem czynnika użycia
wielokrotnego i płynności wymagań)
128 000 DSI
Wstępne oszacowanie COCOMO bez czynników kosztowych 730 osobomiesięcy
Niezawodność Bardzo duża, mnożnik = 1,39
Złożoność Bardzo duża, mnożnik = 1,3
Ograniczenie pamięciowe Duże, mnożnik = 1,21
Użycie narzędzi Małe, mnożnik = 1,12
Harmonogram Przyspieszony, mnożnik = 1,29
Unormowane oszacowanie COCOMO 2306 osobomiesięcy
Złożoność Bardzo mała, mnożnik = 0,75
Ograniczenie pamięciowe Brak, mnożnik = 1
Użycie narzędzi Bardzo duże, mnożnik = 0,72
Harmonogram Normalny, mnożnik = 1
Unormowane oszacowanie COCOMO 295 osobomiesięcy
Niezawodność Bardzo mała, mnożnik = 0,75
Inżynieria oprogramowania - 23 Slide 51
. Algorytmiczne modele kosztów dostarczają podstaw do
planowania przedsięwzięcia jako że pozwalają na porównanie
alternatywnych strategii
. Wbudowany system dla statku kosmicznego
. Musi być niezawodny
. Musi mieć minimalną wagę (zminimalizowana liczba układów na płycie
głównej)
. Mnożniki związane z ograniczeniami komputera i niezawodnością są
większe niż 1
. Komponenty kosztów
. Koszt docelowego sprzętu
. Koszt platformy do budowania systemu
. Koszt niezbędnej pracy
Planowanie przedsięwzięcia
Inżynieria oprogramowania - 23 Slide 52
Opcje menedżerów
A. Użycie istniejącego sprzętu,
systemu tworzenia i zespołu
wytwórczego
B. Ulepszenie procesora i
pamięci
Rośnie koszt sprzętu
Doświadczenie maleje
C. Ulepszenie tylko
pamięci
Rośnie koszt sprzętu
D. Bardziej
doświadczony
personel
F. Personel z
doświadczeniami ze
sprzętem
E. Nowy system tworzenia
Rośnie koszt sprzętu
Doświadczenie maleje
Inżynieria oprogramowania - 23 Slide 53
Koszty opcji menedżerów
Opcja RELY STOR TIME TOOL LTEX Całkowity
wysiłek
Koszt
oprogramowania
Koszt
sprzętu
Całkowity
koszt
A 1,39 1,06 1,11 0,86 1 63 949393 100000 1049393
B 1,39 1 1 1,12 1,22 88 1313550 120000 1402025
C 1,39 1 1,11 0,86 1 60 895653 105000 1000653
D 1,39 1,06 1,11 0,86 0,84 51 769008 100000 897490
E 1,39 1 1 0,72 1,22 56 884425 220000 1044159
F 1,39 1 1 1,12 0,84 57 851180 120000 1002706
Inżynieria oprogramowania - 23 Slide 54
Wybór opcji
. Opcja D (wykorzystuje bardziej doświadczony
personel) wydaje się być najlepszą alternatywą
. Jednakże, opcja ta związana jest z pewnym ryzykiem związanym ze
znalezieniem odpowiednio doświadczonego personelu
. Opcja C (modyfikacja pamięci) pozwala mniej
zaoszczędzić lecz obarczona jest małym bardzo
ryzykiem
. Ogólnie, porównanie to ukazuje znaczenie
doświadczonego personelu w procesie tworzenia
oprogramowania
Inżynieria oprogramowania - 23 Slide 55
Czas trwania przedsięwzięcia i
praca personelu
. Oprócz szacowania niezbędnej pracy, menadżerowie muszą
oszacować jak długo potrwa budowa i kiedy personel będzie
potrzebny w przedsięwzięciu
. Czas ten może być oszacowany na podstawie formuły
COCOMO 2
. TDEV = 3 × (PM)(0.33+0.2*(B-1.01))
. PM to oszacowanie pracy, B to wykładnik obliczony zgodnie z
wcześniejszymi rozważaniami (B wynosi 1 w modelu wczesnego
prototypowania). To obliczenie pozwala przewidzieć przeciętny
harmonogram przedsięwzięcia
. Wymagany czas jest niezależny od liczby ludzi pracujących w
projekcie
Inżynieria oprogramowania - 23 Slide 56
Wymagania odnośnie personelu
. Wymagany personel nie może być obliczony
poprzez podzielenie niezbędnej pracy przez
harmonogram tworzenia
. Liczba osób pracujących nad projektem zmienia się
w zależności od aktualnej fazy projektu
. Gwałtowny wzrost liczby osób często zbiega się z
poślizgiem harmonogramu
Inżynieria oprogramowania - 23 Slide 57
Główne tezy
. Czynniki wpływające na produktywność to m.in.
indywidualne zdolności, doświadczenie z dziedziny
zastosowania, proces tworzenia, wielkość
przedsięwzięcia, wspomaganie narzędziowe i
środowisko pracy
. Do oszacowania kosztu oprogramowania należy
użyć kilku technik przewidzianych do tego celu
. Oprogramowanie jest często wyceniane tak aby
zdobyć kontrakt, a funkcjonalność systemu
dostosowuje się do oszacowanej ceny
Inżynieria oprogramowania - 23 Slide 58
Główne tezy
. Modelowanie algorytmiczne kosztów wiąże się z
zasadniczymi trudnościami, które wynikają z
wykorzystania atrybutów ukończonych produktów do
szacowania kosztów
. W model COCOMO przy szacowaniu kosztu bierze się
pod uwagę atrybuty przedsięwzięcia, produktu, sprzętu i
personelu
. Modele algorytmiczne kosztów pomagają w ilościowej
analizie opcji
. Czas niezbędny do ukończenia przedsięwzięcia nie jest
proporcjonalny do liczby osób w nim pracujących