COCOMO 2, grudzień 2004
1
Metody szacowania kosztu przedsięwzięć informatycznych
Materiał do wykładu z przedmiotu
Inżynieria Oprogramowania
Opracowane głównie na podstawie materiału źródłowego
B.Boehma i współautorów
po przekładzie T.Tarnawskiego pod kierunkiem G.Bliźniuka
Ostateczne przygotowanie dla studentów: G.Bliźniuk
Warszawa, grudzień 2004r.
COCOMO 2, grudzień 2004
2
Spis treści
1.
Wprowadzenie...........................................................................................................................................................5
2.
Uwarunkowania oceny kosztu procesu wytwórczego oprogramowania ...................................................................6
3.
Podział kosztu procesu wytwórczego na poszczególne etapy cyklu życia oprogramowania ....................................9
4.
COCOMO 2 ............................................................................................................................................................14
4.1.
Cele Cocomo2 ...............................................................................................................................................14
4.2.
Modele Cocomo2...........................................................................................................................................14
4.3.
Charakterystyka modeli Cocomo2.................................................................................................................15
4.4.
Czynniki wpływające na koszt: Rozmiar.......................................................................................................18
4.4.1.
Komponowanie Aplikacji: Punkty Obiektowe ..............................................................................................18
4.4.1.1.
Procedura szacowania kosztu metodą Punktów Obiektowych wykorzystana w Cocomo2 ......................19
4.4.2.
Rozwój Aplikacji ...........................................................................................................................................21
4.4.2.1.
Reguły zliczania Linii Kodu .....................................................................................................................21
4.4.2.2.
Reguły naliczania Punktów Funkcyjnych .................................................................................................23
4.4.3.
Ponowne Użycie istniejącego kodu i Reinżynieria........................................................................................25
4.4.3.1.
Nieliniowe Koszty Ponownego Użycia istniejącego kodu........................................................................25
4.4.3.2.
Model Dostosowywania istniejącego kodu użyty w Cocomo2.................................................................26
4.4.3.3.
Szacowanie kosztów reinżynierii i konwersji oprogramowania ...............................................................29
4.4.4.
Występowanie Usterek ..................................................................................................................................30
4.4.5.
Pielęgnacja oprogramowania .........................................................................................................................30
4.5.
Czynniki wpływające na koszt: Skala Programu ...........................................................................................30
4.5.1.
Modelowania tzw. ekonomii lub anty-ekonomii skali w pracach informatycznych......................................30
4.5.2.
Określenie skali prac w Cocomo i Ada Cocomo ...........................................................................................31
4.5.3.
Skalowanie prac w Cocomo2.........................................................................................................................32
4.6.
Czynniki wpływające na koszt: Dodatkowe czynniki zwiększające nakład pracy ........................................33
4.6.1.
Czynniki Produktu .........................................................................................................................................34
4.6.1.1.
RELY – Wymagana Niezawodność Oprogramowania.............................................................................34
4.6.1.2.
DATA – Wielkość Bazy Danych..............................................................................................................35
4.6.1.3.
CPLX – Złożoność (trudność) Produktu...................................................................................................35
4.6.1.4.
RUSE – Wymagane ponowne użycie tworzonego oprogramowania........................................................36
4.6.1.5.
DOCU – przydatność wymaganej dokumentacji przy budowaniu oprogramowania................................36
4.6.1.6.
Czynniki Platformy ...................................................................................................................................36
4.6.1.7.
TIME – Ograniczenie Czasu Działania, STOR – Limit Dostępnej Pamięci.............................................38
4.6.1.8.
PVOL – Zmienność Platformy..................................................................................................................38
4.6.1.9.
TURN – Czas Kompilacji (Computer Turnaround Time) ........................................................................38
4.6.2.
Czynniki Kadrowe .........................................................................................................................................38
4.6.2.1.
ACAP – Umiejętności Analityków, PCAP – Umiejętności Programistów...............................................38
4.6.2.2.
AEXP – Doświadczenie z aplikacjami, PEXP – Doświadczenie z platformami, LTEX – Doświadczenie z
językiem programowania i narzędziami .......................................................................................................................39
4.6.2.3.
PCON – Stabilność personelu..................................................................................................................40
4.6.3.
Czynniki Procesu Produkcji...........................................................................................................................40
4.6.3.1.
MODP – Wykorzystanie nowoczesnych metod tworzenia oprogramowania ...........................................40
4.6.3.2.
TOOL – Stosowanie narzędzi software’owych.........................................................................................40
4.6.3.3.
SITE – Rozproszenie tworzenia oprogramowania....................................................................................41
4.6.3.4.
SCED – Wymaganie dotyczące harmonogramu prac ...............................................................................41
4.6.3.5.
SECU – Oprogramowanie utajnione.........................................................................................................41
4.7.
Dodatkowe możliwości metody Cocomo2 ....................................................................................................41
4.7.1.
Szacunki Punktów Funkcyjnych w modelach Projektu Wstępnego i Późnych Faz Projektowych................41
Czynniki w modelu .......................................................................................................................................................42
Projektu Wstępnego......................................................................................................................................................42
4.7.2.
Szacunki harmonogramu prac........................................................................................................................43
4.7.3.
Przedziały wyników obliczeń ........................................................................................................................43
5.
Podsumowanie ........................................................................................................................................................44
6.
Wyjaśnienie skrótów użytych w tekście..................................................................................................................45
COCOMO 2, grudzień 2004
3
Spis tabel
Tabela 1. Procentowy udział kosztu w poszczególnych procesach i fazach cyklu życia oprogramowania......................10
Tabela 2. Porównanie Cocomo, Ada Cocomo i Cocomo2................................................................................................17
Tabela 3. Typy Funkcji Użytkowych w FPA....................................................................................................................24
Tabela 4. Wartości wskaźnika Zrozumiałości Oprogramowania (SU) w zależności od jakości kodu..............................28
Tabela 5. Skala wartości Współczynnika AA...................................................................................................................29
Tabela 6. Wartości stopnia automatycznego przerabiania kodu .......................................................................................29
Tabela 7. Oceny składników wykładnika skali projektu...................................................................................................33
Tabela 8. Skale szacowania czynników wzrostu kosztów w modelu Post-Architekturowym ..........................................34
Tabela 9. Wyznaczanie trudności dla różnych typów modułów.......................................................................................37
Tabela 10. Czynniki wzrostu kosztów w modelach Projektu Wstępnego i Późnych Faz Projektowych ..........................42
COCOMO 2, grudzień 2004
4
Spis rysunków
Rysunek 1. Przewidywana struktura rynku informatycznego USA w roku 2005...............................................................6
Rysunek 2. Typowe niedokładności szacowania kosztu przedsięwzięcia informatycznego w poszczególnych fazach
cyklu wytwórczego. ........................................................................................................................................9
Rysunek 3.Udział poszczególnych faz cyklu życia oprogramowania w koszcie przedsięwzięcia informatycznego........12
Rysunek 4. Podział kosztów na procesy cyklu wytwórczego oprogramowania. ..............................................................12
Rysunek 5. Udział kosztów składowych procesu wytwórczego w poszczególnych fazach cyklu życia
oprogramowania............................................................................................................................................13
Rysunek 6. Szkielet procedury zliczania punktów obiektowych ......................................................................................20
Rysunek 7. Lista-Definicja do Naliczania LOC ...............................................................................................................22
Rysunek 8. Procedura naliczania punktów funkcyjnych ..................................................................................................25
Rysunek 9. Nieliniowe koszty dostosowywania istniejącego oprogramowania ...............................................................27
Rysunek 10. Liczba testów interfejsów między-modułowych jako funkcja ilości zmian.................................................27
COCOMO 2, grudzień 2004
5
1. Wprowadzenie
Zakres materiału obejmuje zaproponowanie albo wskazanie efektywnej metody szacowania
kosztu przedsięwzięć informatycznych wraz z opisem uwarunkowań omawianego zagadnienia.
Po pierwsze należy zauważyć, że szacowanie kosztu przedsięwzięć informatycznych jest
zadaniem niezwykle trudnym i od wielu lat nie wypracowano jednak, ogólnie przyjętej metodzie,
dzięki której możnaby jednoznacznie powiedzieć, że koszt wytworzenia jakiegoś konkretnego
systemu informatycznego powinien wynosić X, a koszt wytworzenia innego systemu powinien
wynosić Y. Zawsze pracuje się tutaj w warunkach wiedzy niepełnej o potencjalnym koszcie
ostatecznym i koszcie rzeczywistym wytworzenia systemu informatycznego. Nie oznacza to jednak,
że współczesny dorobek inżynierii oprogramowania nie pomaga w tej kwestii. Ważne jest jednak,
aby mieć na względzie to, że cały czas poruszamy się tutaj w obszarze szacowania kosztu, a każdy
szacunek jest jedynie pewnym przybliżeniem rzeczywistej wartości, która podlega szacowaniu.
W czasie opracowywania tego materiału przeanalizowano własne doświadczenia, dotyczące
wytwarzania systemów informatycznych. Z doświadczeń tych wynika, że dominującymi obecnie
metodami szacowania kosztu przedsięwzięć informatycznych są dwie metody:
– metoda analizy punktów funkcyjnych pochodząca z firmy IBM (ang. Function Point
Analisys – FPA), zaproponowana przez A.J.Albrecht’a w roku 1979 i potem
rozwijana
1
. Zasadniczą miarą kosztu w tej metodzie jest „punkt funkcyjny”.
Zasadniczą wadą tej metody jest jednak to, że nie do końca wiadomo, jaka jest miara
kosztu punktu funkcyjnego.
– metoda Cocomo2 zaproponowana przez SEI
2
(ang. Software Engineering Institute)
umożliwiająca efektywne szacowanie kosztu produkcji i wdrażania oprogramowania.
Według opinii autora najlepszą obecnie metodą jest Cocomo2. Wynika to z tego, że jej właściwości
dają w naszej opinii właściwy aparat analityczny dla osób odpowiedzialnych za budżet
poszczególnych przedsięwzięć informatycznych, a równocześnie uwzględnia ona własności metody
FPA, równie ważnej dla oceny kosztu przedsięwzięć informatycznych.
1
Metoda FPA jest opisywana na stronie: www.ifpug.org
2
W tej ekspertyzie zostanie wykorzystany materiał źródłowy opisujący wersję drugą metody Constructive Cost Model,
nazywanej w skrócie Cocomo2, przedstawiony przez autorów tej metody, którymi są: Barry Boehm, Bradford Clark,
Ellis Horowitz, Chris Westland z USC Center for Software Engineering, Ray Madachy z USC Center for Software
Engineering and Litton Data Systems i Richard Shelby zUC Irvine and Amadeus Software Research.
COCOMO 2, grudzień 2004
6
2. Uwarunkowania oceny kosztu procesu wytwórczego oprogramowania
Szacowanie kosztu procesu wytwórczego oprogramowania jest realizowane w warunkach
wiedzy niepełnej i niepewnej. Według twórców metody Cocomo2 bardzo istotny i ciągły spadek
cen sprzętu komputerowego i dominująca tendencja do informatycznego wspomagania zarządzania
przedsiębiorstwami wymuszają intensywne prace nad obniżeniem kosztów tworzenia systemów
informatycznych. W takiej sytuacji dużego znaczenia nabierają metody analizy zysków i strat, na
podstawie których będzie można dobrać właściwy model cyklu wytwórczego oprogramowania
3
.
Pojawia się też potrzeba jednoczesnej kontroli jakości produktu i procesu produkcji
oprogramowania i bieżącej analizy kosztów i jakości oprogramowania.
Nowa generacja produktów i metod projektowych spowodowała istotne zmiany w procesie
tworzenia oprogramowania. Przykładem mogą być tutaj metody zarządzania ryzykiem, czy
współzależnościami w procesie wytwórczym, użycie języki czwartej generacji (4GL) i czy coraz
bardziej powszechne wykorzystanie generatorów aplikacji. Ważne w tym miejscu są również
kwestie ponownego użycia wcześniejszych osiągnięć innych przedsięwzięć informatycznych.
Kolejną istotną kwestią jest przewidywana struktura rynku informatycznego. Rysunek 1 jest
ilustracją przewidywań rynku informatycznego w najbliższej przyszłości, na których bazuje metoda
Cocomo2. Największy udział w prognozowanym rynku mają programiści końcowi, których liczba
jest szacowana na około 55 mln programistów (w Stanach Zjednoczonych do roku 2005). Dolny
sektor infrastruktury rynku przejmie prawdopodobnie do 0.75 mln osób. Sektor pośredni będzie
można podzielić na trzy równoległe części: opracowywanie generatorów aplikacji i narzędzi
wspomagających tworzenie oprogramowania (ok. 0.6 mln osób), tworzenie systemów przez
łączenie aplikacji (0.7 mln osób) i integrowanie złożonych (w tym wbudowanych) systemów
informatycznych do zadań specjalistycznych (0.7 mln osób).
Programiści i Użytkownicy Końcowi
(55 mln w Stanach Zjednoczonych)
Generatory Aplikacji i
Wspomaganie Wytwarzania
Oprogramowania
(0.6 mln)
Wytwarzanie Aplikacji
dla warstwy pośredniej
(0.7 mln)
Integratorzy Systemów
(0.7 mln)
Infrastruktura informatyczna
(0.75 mln)
Rysunek 1.
Przewidywana struktura rynku informatycznego USA w roku 2005.
3
Zagadnienia doboru cyklu modelu cyklu wytwórczego oprogramowania pozostają poza zakresem opracowania.
COCOMO 2, grudzień 2004
7
Bodźcem do szybkiego rozwoju sektora programistów i użytkowników końcowych jest ciągłe
upowszechnianie wiedzy informatycznej w społeczeństwie, a także fakt, że jedynie firmy stosujące
najlepsze rozwiązania informatyczne pozostaną konkurencyjne na rynku. W takiej sytuacji coraz
większa część rynku informatycznego przypadnie na samych użytkowników, którzy własnoręcznie
będą tworzyć większość potrzebnych im aplikacji np. przy pomocy generatorów aplikacji.
Przykładem pomocnych tu generatorów aplikacji są arkusze kalkulacyjne, podręczne bazy danych
oraz wyspecjalizowane narzędzia zarządzania przedsiębiorstwami. Przy pomocy stosownych opcji,
parametrów i prostych reguł użytkownicy są w stanie wykorzystać generatory aplikacji do
tworzenia narzędzi informatycznych o pożądanych cechach. Praktycznie wszystkie firmy – od
najbogatszych firm do sektora MŚP
4
, a także na przykład instutycje rządowe będą miały swój
udział w tym sektorze rynku informatycznego.
Typowymi przykładami oprogramowania zaliczanego do infrastruktury informatycznej są
systemy operacyjne, systemy baz danych, systemy zarządzania interfejsem użytkownika, czy też
systemy sieciowe. Sektor infrastruktury będzie coraz bardziej zaangażowany w tworzenie
rozwiązań dla architektury trójwarstwowej do zadań takich jak przetwarzanie rozproszone i
przetwarzanie transakcyjne. Największymi firmami zajmującymi się infrastrukturą informatyczną
są teraz między innymi: Microsoft, NeXT, Oracle, SyBase, Novell i największe firmy
rozprowadzające sprzęt komputerowy. Należy pamiętać o tym, że programiści i użytkownicy
końcowi będą doskonale zorientowani w tworzeniu potrzebnego im specjalistycznego
oprogramowania, nie będą natomiast mieli szczególnie dobrego pojęcia o komputerach czy
informatyce jako takiej. Z kolei producenci infrastruktury będą specjalistami z zakresu informatyki
i inżynierii komputerowej, nie będą zaś wiedzieć zbyt wiele o programach czysto użytkowych.
Tworzenie infrastruktury informatycznej będzie wymagało od programistów nadążania za nowymi
technologiami komputerowymi (nowe procesory, pamięci, technologie multimedialne i
komunikacyjne) i stąd tylko część modułów oprogramowania będzie mogła być ponownie użyta.
Pozostała część będzie musiała być stworzona od zera.
Sektor generatorów aplikacji będzie źródłem gotowych pakietów umożliwiających
„programowanie końcowe”. Obecnie tą część rynku zajmują firmy takie jak Microsoft, IBM -
Lotus, Novell, Borland (ostatnio mniej widoczny na rynku), a także producenci oprogramowania
menedżerskiego (np. pakiety IBM-Rational), inżynierskiego (np. pakiety IBM-Rational, Oracle),
4
Małe i średnie przedsiębiorstwa
COCOMO 2, grudzień 2004
8
przemysłowego (np. systemy klasy ERP), systemów klasy workflow (np. polski Rodan Systems,
amerykański IBM-Lotus Domino) i systemów analizy finansowej (w Europie wiodący jest
niemiecki SAP). W wielu przypadkach oprogramowanie to będzie tworzone z gotowych (lub nieco
zmodyfikowanych) podzespołów, niemniej zawsze będzie też istniała konieczność budowy
pakietów od podstaw. Wspomaganie wytwarzania oprogramowania będzie rozbudowywane
zarówno przez wyżej wymienione firmy, jak również przez inwestycje rozwojowe w sektorze
narzędzi wspomagających wytwarzanie oprogramowania dla warstwy pośredniej. Sektor ten skupi
się na zadaniach na tyle różnorodnych i specjalistycznych, że nie sposób będzie produkować ich w
postaci wielkonakładowych, gotowych pakietów. Z drugiej zaś strony programy te będą na tyle
proste, że będzie można błyskawicznie stworzyć je z kilku gotowych już podzespołów. Takimi
gotowymi komponentami będą zwykle: generatory Graficznego Interfejsu Użytkownika (GUI)
wraz z doskonałymi generatorami firmy Microsoft czy też firmy Borland, menadżery obiektów i
baz danych, „middleware” do przetwarzania rozproszonego i przetwarzania transakcyjnego,
oprogramowanie multimedialne, hurtownie danych oraz oprogramowanie specjalizowane, np.:
medyczne, finansowe, kontroli produkcji itp.
Integrowanie systemów będzie związane z wielkimi, najczęściej wbudowanymi systemami.
Po części programy te będą mogły powstawać przy wykorzystaniu metod wytwarzania
oprogramowania dla warstwy pośredniej, niemniej ich specyfika spowoduje, że znacząca ilość prac
przypadnie na projektowanie całkowicie nowych systemów i tworzenie oprogramowania
dostosowanego do indywidualnych potrzeb. Przykładami firm obracających się w tym sektorze są
producenci sprzętu lotniczego (np. oprogramowanie sterowania samoloty F22 ma ponad miliard
linii kodu), samochodowego, elektronicznego, firmy telekomunikacyjne i finansowe, a także
przedsiębiorstwa budujące wielkoskalowe systemy informacyjne i kontroli produkcji.
Menedżerowie planujący koszt przedsięwzięć informatycznych oprócz znajomości zasad gry
rynkowej i prognozy rozwoju tego rynku pracują w kolejnych, niezwykle restryktywnych
uwarunkowaniach. Przede wszystkim pracują oni w warunkach ciągłego stresu wynikającego z
zachodzenia zmian w projektach informatycznych.
Na potwierdzenie powyższej tezy można przytoczyć wyniki badania amerykańskiego rynku
informatycznego, w których skoncentrowano się na szacunkach kosztów przedsięwzięć
informatycznych (patrz: Rysunek 2). Z doświadczeń tych wynika jednoznacznie, że dopiero na
etapie eksploatacji systemu informatycznego jesteśmy w stanie prawie idealnie oszacować koszt
przedsięwzięcia informatycnego. Na etapie definicji systemu możemy popełnić nawet 400%-towy
COCOMO 2, grudzień 2004
9
błąd przeszacowania lub niedoszacowania kosztu. Z tego też powodu należy dać możliwość
osobom prowadzącym czynności związane z zarządzaniem budżetem weryfikacji swoich prognoz,
jeżeli chodzi o koszt konkretnego przedsięwzięcia informatycznego. Pozycja wyjściowa do
szacowania kosztu przedsięwzięć informatycznych jest często jeszcze bardziej niekorzystna.
Wynika to z faktu, że bardzo często istnieje konieczność oszacowania kosztu przedsięwzięć
informatycznych jeszcze przez fazą definicji wymagań, co wynika z cyklu planowania budżetu
państwa. Taka procedura może wprowadzać błąd szacowania jeszcze większy niż prognozowane
400%.
Rysunek 2. Typowe niedokładności szacowania kosztu przedsięwzięcia informatycznego w poszczególnych fazach
cyklu wytwórczego.
3. Podział kosztu procesu wytwórczego na poszczególne etapy cyklu życia
oprogramowania
Faza Definicji
Faza
Implementacji
Faza
Projektowania
Faza Analizy
Faza eksploatacji
Koszt
rzeczywisty
2-krotne
przeszacowanie
4-krotne
przeszacowanie
2-krotne
niedoszacowanie
4-krotne
niedoszacowanie
COCOMO 2, grudzień 2004
10
Podział kosztu procesu wytwórczego na poszczególne etapy cyklu życia oprogramowania
zostanie przedstawiony na podstawie wyników badań przeprowadzonych przez firmę Oracle
Corporation. Badania te dotyczyły około 5 tysięcy projektów informatycznych o różnej skali i
wydaje się, że są one wiarygodne i adekwatne również dla polskiego rynku informatycznego.
Tabela 1 stanowi syntezę przeprowadzonych i cytowanych w tym miejscu wyników bada
firmy Oracle Corp. Proces wytwórczy został tutaj podzielony na 6 zasadniczych faz cyklu życia
oprogramowania, tj. na:
1. definicję systemu,
2. analizę systemu,
3. projekt systemu,
4. budowę (implementację) systemu,
5. wdrażanie systemu,
6. eksploatację systemu.
W ramach poszczególnych faz cyklu życia oprogramowania w różnym stopniu realizowane są
poszczególne procesy cyklu wytwórczego oprogramowania. Procesami tymi są:
1. definicja wymagań na system,
2. analiza istniejących systemów,
3. opracowanie architektury technicznej systemu,
4. projekt i budowa bazy danych,
5. projekt i budowa modułów systemu,
6. konwersja danych,
7. utworzenie dokumentacji systemu,
8. testowanie systemu,
9. szkolenie użytkowników,
10. wdrożenie systemu,
11. asysta po wdrożeniu,
12. zarządzanie projektem.
Tabela 1. Procentowy udział kosztu w poszczególnych procesach i fazach cyklu życia
oprogramowania
COCOMO 2, grudzień 2004
11
PROCES
Udzia
ł %
P
roc
es
u
DEFINICJA
ANALIZA
P
R
OJE
K
TOWANIE
BUDOWA
W
DRA
Ż
ANIE
E
K
SPLOA
T
ACJ
A
NAZWA PROCESU
% A B C D E F
Definicja Wymagań
8,5 %
3,9 %
4,6 %
Analiza Istniejących
Systemów
2,6 %
1,0 %
1,6 %
Architektura Techniczna
2,1 %
0,3 %
1,5 %
0,3 %
Projekt i Budowa Bazy
Danych
1,3 %
0,9 %
0,4 %
Projekt i Budowa Modułów
37,3 %
17,5 % 19,8 %
Konwersja Danych
7,3 %
0,4 %
1,2 %
1,8 %
3,2 % 0,7 %
Dokumentacja
4,2 %
0,1 %
0,1 %
2,2 %
1,8 %
Testowanie
16,3 %
0,1 %
1,8 % 13,6 % 0,8 %
Szkolenie
1,9 %
0,3 %
0,4 %
0,6 % 0,6 %
Wdrożenie
0,9 %
0,1 %
0,1 %
0,2 % 0,5 %
Asysta po Wdrożeniu
3,4 %
3,4
%
Zarządzanie Projektem
14,2 %
0,8 %
1,7 %
4,1 %
6,6 % 0,4 % 0,6 %
UDZIAŁ % FAZ
100 % 6,6 % 11,1 % 29,1 % 46,2 %
3 %
4 %
Dokładny podział procentowy poszczególnych składników kosztów został przedstawiony w tabeli
wyżej. Ilustrację procentu udziału poszczególnych faz cyklu życia oprogramowania przedstawia
Rysunek 3, a podział kosztu cyklu wytwórczego - Rysunek 4.
COCOMO 2, grudzień 2004
12
Koszt poszczególnych faz cyklu życia oprogramowania
6,6
11,1
29,1
46,2
3
4
0
5
10
15
20
25
30
35
40
45
50
de
fin
ic
ja
an
al
iz
a
pr
oj
ek
to
w
an
ie
bu
do
w
a
w
dr
aż
an
ie
ek
sp
lo
at
ac
ja
nazwa fazy
%
udz
ia
łu
Rysunek 3.Udział poszczególnych faz cyklu życia oprogramowania w koszcie przedsięwzięcia informatycznego
Podział kosztów w cyklu wytwórczym oprogramowania
8,5
2,6
2,1
1,3
37,3
7,3
4,2
16,3
1,9
0,9
3,4
14,2
0
5
10
15
20
25
30
35
40
De
fin
icj
a W
ym
aga
ń
Anali
za I
st
nie
ją
cy
ch S
ys
tem
ów
Ar
chi
tek
tur
a T
ec
hn
icz
na
Pr
oj
ek
t i
B
udow
a B
az
y
Dany
ch
Pr
oj
ek
t i
B
ud
ow
a M
od
uł
ów
Konw
er
sja
Dany
ch
Do
ku
m
en
ta
cja
Te
sto
wa
ni
e
Sz
ko
leni
e
W
dr
oż
en
ie
As
yst
a p
o W
dro
że
ni
u
Za
rz
ąd
za
ni
e
Pr
oj
ek
te
m
Nazwa procesu
%
udz
ia
łu
Rysunek 4. Podział kosztów na procesy cyklu wytwórczego oprogramowania.
W podsumowaniu analizy udziału kosztów, przedstawiono Rysunek 5, na którym przedstawiono
zależności kosztowe pomiędzy procesem wytwórczym i cykle życia oprogramowania.
COCOMO 2, grudzień 2004
13
Udział procesów cyklu w ytw órczego w fazach cyklu życia
oprogramow ania
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
de
fin
icja
an
al
iza
pr
oje
kto
wani
e
bud
ow
a
wdr
aż
an
ie
eks
pl
oat
ac
ja
fazy cyklu życia
sk
ła
dow
e pr
oc
es
u w
ytw
ór
cz
eg
o
Definicja Wymagań
Analiza Istniejących Systemów
Architektura Techniczna
Projekt i Budowa Bazy Danych
Projekt i Budowa Modułów
Konwersja Danych
Dokumentacja
Testowanie
Szkolenie
Wdrożenie
Asysta po Wdrożeniu
Zarządzanie Projektem
Rysunek 5. Udział kosztów składowych procesu wytwórczego w poszczególnych fazach cyklu życia oprogramowania
COCOMO 2, grudzień 2004
14
4. COCOMO 2
Metoda COCOMO 2 została opracowana po to, aby umożliwić odpowiednie planowanie
harmonogramu prac, organizowanie zespołów ludzkich, szacowanie czasu zakończenia projektu,
przygotowywanie i przeplanowywanie prac, śledzenie postępów prac, negocjowania kontraktów,
oceny ofert przetargowych, decyzji o zgodzie na warunki kontraktu.
4.1. Cele Cocomo2
Cele metody Cocomo2 są następujące:
• zapewnienie łatwości zrozumienia metody,
• dostosowanie możliwości metody do przewidywanej struktury rynku
informatycznego,
• dostosowanie wartości wejściowych i wyjściowych podmodeli Cocomo2 do
przewidywanej rozległości i różnorodności informacji o przedsięwzięciu
informatycznym,
• umożliwienie uniwersalnego wykorzystania podmodeli Cocomo2 przy różnych
strategiach projektowo-wdrożeniowych.
W Cocomo2 wszystkie algorytmy są w pełni dostępne publicznie. Podobnie wszystkie
interfejsy są zaprojektowane tak, aby były powszechnie zrozumiałe, dokładnie zdefiniowane i
sparametryzowane, dzięki czemu umożliwiają one łatwą implementację pre-szacunków (modele
szacowania wielkości projektów) i post-szcunków (narzędzia planowania i kontroli procesu
produkcji, analizy poziomów ryzyka) wynikających z kolejnych algorytmów metody Cocomo2.
4.2. Modele Cocomo2
Model Cocomo2 opisujący sektor wytwarzania aplikacji dla warstwy pośredniej bazuje na
metodzie Analizy Punktów Obiektowych. Punkty Obiektowe są zliczane na podstawie liczby
modułów napisanych w językach trzeciej generacji oraz ilości ekranów i raportów stworzonych na
potrzeby danej aplikacji. Każdy z nicj jest ważony współczynnikiem poziomu trudności (łatwy,
średni, trudny) [Banker 1994, Kauffman i Kumar 1993]. Takie podejście dobrze odzwierciedla
ilość informacji na temat komponowanej aplikacji dostępnej zwykle na wstępnym etapie prac.
Zapewnia ono dokładność wystarczającą do adekwatnego oszacowania kosztów (projekty w tym
COCOMO 2, grudzień 2004
15
sektorze tworzone są zwykle przez kilkuosobowe grupy programistów w czasie kilku tygodni,
miesięcy).
Szacowanie złożoności generatorów aplikacji, integracji systemów i kosztu infrastruktury
opiera się w metodzie Cocomo2 na uniwersalnym połączeniu modelu dla komponowania aplikacji i
dwóch modeli szacunkowych o wzrastającej dokładności – opracowanych dla kolejnych etapów
cyklu życia oprogramowania.
4.3. Charakterystyka modeli Cocomo2
Uzasadnienie dla uniwersalnego zestawu modeli Cocomo2 bazuje się na trzech
wymienionych niżej przesłankach:
Pierwsza: Inaczej niż w późnych latach siedemdziesiątych, kiedy powszechnie
preferowano tylko jeden model cyklu życia oprogramowania (tzw. model
kaskadowy), obecnie stosuje się różne modele procesów produkcyjnych,
dostosowane do konkretnych sytuacji. O wyborze właściwej metody decydują
teraz: możliwość wykorzystania COTS (gotowych pakietów),
użycie/dostosowanie istniejącego kodu, poziom znajomości wymagań
i architektury projektowanego systemu, ograniczenia dla harmonogramu prac,
wielkość programu, wymagana niezawodność.
Druga:
Możliwy błąd oszacowania kosztów (patrz: Rysunek 2) w danej metodzie musi
być zgodny z poziomem szczegółowości informacji dostępnych na każdym
etapie produkcji. We wczesnych stadiach programu mamy najczęściej niewiele
wiadomości o wielkości programu, docelowej platformie, ilości i jakości
personelu zaangażowanego w tworzenie oprogramowania, czy o szczegółach
stosowanego procesu tworzenia oprogramowania.
Trzecia: Z powyższego wynika, że Cocomo2 umożliwia wykorzystanie zgrubnych
informacji we wczesnych fazach projektowych, a jednocześnie pozwala na
doszlifowanie szacunków wraz z napływem dokładniejszych danych
z postępujących prac. Cocomo2 nie daje więc punktowych szacunków kosztów
i rozmiarów oprogramowania, a raczej przedziały możliwych wartości –
właściwie dla ilości dostępnych danych. Za podstawę do wyznaczania tych
COCOMO 2, grudzień 2004
16
przedziałów szacunkowych przyjęto przedziały niepewności i niepełności
wiedzy, który ilustrację stanowi Rysunek 2.
W dalszych rozważaniach przypadki generatorów aplikacji, integracji systemów
i infrastruktury informatycznej będą rozważane przy pomocy zestawu trzech modeli procesów.
Właściwe połączenie tych modeli będzie zależało od czynników rynkowych oraz od stopnia
zrozumienia projektu. Poniżej zamieszczono krótki opis tych trzech modeli.
Model komponowania aplikacji umożliwia opis kosztów prace prototypowych mających
na celu rozpoznanie zagadnień o potencjalnie zwiększonym ryzyku, takich jak interfejs
użytkownika, interakcja oprogramowanie-system, wydajność, dojrzałość technologii.
Model wczesnych faz projektu dotyczy rozpoznawania różnych alternatyw architektury
systemu informatycznego i wypracowywania koncepcji jego działania. W takim stadium na ogół
niewiele jeszcze wiadomo i nie sposób przeprowadzać dokładne szacowania kosztów. Możliwości
Ccocomo2 w tym zakresie obejmują zastosowanie punktów funkcyjnych i kilku dodatkowych
metod opisu źródeł kosztów (cost drivers).
Model późnych faz projektu obejmuje właściwe prace nad budową i pielęgnowaniem
oprogramowania. Model ten jest adekwatny do sytuacji, w których architektura systemu jest już
zaprojektowana i zatwierdzona jako podstawa do dalszych prac produkcyjnych. Ten model
w metodzie Cocomo2 obejmuje metryki linii kodu i/lub punkty funkcyjne z uwzględnieniem
wykorzystania kodu już istniejącego. Zdefiniowano tutaj zestaw 17-stu współczynników źródeł
kosztów oraz 5-ciu czynników wyznaczających wykładnik skali projektu.
Podsumowując, metoda Cocomo2 zawiera następujące 3 szczeble umożliwiające
szacowanie złożoności systemów w sektorach generatorów aplikacji, integracji systemów i
infrastruktury informatycznej:
1. Początkowe stadia spiralnego cyklu tworzenia oprogramowania generalnie nie
obejdą się bez tworzenia prototypów w wykorzystaniem narzędzi Komponowania
Aplikacji. Prace takie, a także dalsze prototypowanie w późniejszych fazach
produkcji są uwzględnione w Cocomo2 w modelu komponowania aplikacji.
2. W następnych stadiach rozważane są zwykle różne alternatywy architektury
systemu, a także strategie etapowej budowy produktu. Cocomo2 wspiera te stadia
modelem wczesnego szacowania, który stosuje punkty funkcyjne do oceny kosztu
projektu i 5-ciu zgrubnych wyznaczników źródeł kosztów (np. 2 współczynniki
COCOMO 2, grudzień 2004
17
opisujące wykwalifikowanie personelu, jego umiejętności, doświadczenie itp.). Jak
wspomniano wcześniej, dokładność szacunków jest tu zależna od ilości informacji
dostępnej na tym etapie.
3. Gdy zakończą się prace czysto projektowe, przyszły produkt ma już stabilnie
nakreśloną architekturę. Dostępne są wtedy znacznie bogatsze dane na temat
przyszłych źródeł kosztów i można znacznie dokładniej szacować wymogi czasowe,
robocze czy finansowe. Ten etap rozwoju jest opisany w C2 przy pomocy modelu
punktów funkcyjnych lub źródłowych LOC i 17-tu współczynników źródeł kosztów.
Metoda Cocomo2 stanowi kolejną wersję pierwotnej metody Cocomo z lat 70-tych i jej
następczyni zwanej Ada Cocomo. Tabela 2 stanowi syntetyczne porównanie tych metod
5
.
Tabela 2. Porównanie Cocomo, Ada Cocomo i Cocomo2
Cocomo
Ada Cocomo
Cocomo2:
Etap 1
Cocomo2:
Etap 2
Cocomo2:
Etap 3
Rozmiar (R)
(Dostarczone)
Instrukcje
Źródłowe (DSI)
lub Źródłowe
LOC (SLOC)
DSI lub SLOC
Punkty Obiektowe Punkty Funkcyjne
(FP) i Język
Programowania
FP i Język
Programowania
lub SLOC
Użycie kodu
istniejącego
Równoważne
SLOC = liniowa
funkcja
f(DM,CM,IM)
Równoważne
SLOC = liniowa
funkcja
f(DM,CM,IM)
domyślne w tym
modelu
Błędne
zatrzymania
wartość RVOL
wartość RVOL
domyślne w tym
modelu
%błędnych zatrzy-
mań: BRAK
BRAK
Pielęgnacja Roczny
Poziom
Zmian (ACT) =
%dodany +
%zmieniony
ACT Model
Ponownego
Użycia Punktów
Obiektowych
Model Ponownego
Użycia
Model Ponownego
Użycia
Skalowanie
(wartość b) w
MM
NOM
= a(R)
b
Organiczne: 1.05
Wpółodcięty: 1.12
Wbudowany: 1.20
Wbudowany: 1.04
– 1.24 zależnie od:
• poziomu
wczesnej
eliminacji ryzyka
• solidności
architektury
• stabilności
wymagań
• dojrzałości
procesu
produkcji
1.0
1.01 – 1.26
zależnie od:
• oryginalności
• wygody
użytkowania
• stabilności
wymagań
• zgrania zaspołu
• dojrzałości
procesu
produkcji (SEI)
Źródła kosztów
wynikające z cech
RELY, DATA,
CPLX
RELY*, DATA*,
CPLX*, RUSE
brak RCPX*+,
RUSE*+
RELY, DATA,
DOCU*+,
5
W tabeli tej użyto wielu skrótów sklasyfikowanych w wykazie skrótów zamieszczonych w zakończeniu ekspertyzy.
COCOMO 2, grudzień 2004
18
Cocomo
Ada Cocomo
Cocomo2:
Etap 1
Cocomo2:
Etap 2
Cocomo2:
Etap 3
produktu
CPLX+, RUSE*+
Źródła kosztów
wynikające z cech
platformy
TIME, STOR,
VIRT, TURN
TIME, STOR,
VMVH, VMVT,
TURN
brak Złożoność
platformy:
PDIF*+
TIME, STOR,
PVOL (=VIRT)
Źródła kosztów
wynikające z cech
personelu
ACAP, AEXP,
PCAP, VEXP,
LEXP
ACAP*, AEXP,
PCAP*, VEXP,
LEXP*
brak kwalifikacje
personelu i
doświadczenie:
PERS*+, PREX*+
ACAP*, AEXP+,
PCAP*, PEXP*+,
LTEX*+,
PCON*+
Źródła kosztów
wynikające z
praktyk
produkcyjnych
MODP, TOOL,
SCED
MODP*, TOOL*,
SECD, SECU
brak
SCED, FCIL*+
TOOL*+, SCED,
SITE*+
* odmienny
mnożnik
+ odmienna skala ocen
4.4. Czynniki wpływające na koszt: Rozmiar
W tej części przedstawione będą definicje i uzasadnienia dla trzech wielkości w Cocomo2
użytych do opisu rozmiaru produktu: punktów obiektowych, nieznormalizowanych punktów
funkcyjnych i źródłowych LOC. Następnie opisane będą parametry, które w szacunkach rozmiaru
uwzględniają użycie gotowego kodu, przeprojektowywanie istniejącego systemu, dostosowywanie
i pielęgnację oprogramowania.
4.4.1. Komponowanie Aplikacji: Punkty Obiektowe
Punkty obiektowe są nowością wśród metryk wielkości oprogramowania, niemniej bardzo
dobrze nadają się do opisu sytuacji spotykanych w obszarze Komponowania Aplikacji. Oddają one
koszty prac prototypowych przy błyskawicznym komponowaniu aplikacji przy pomocy narzędzi
typu ICASE (Integrated Computer Aided Software Environment), zawierających kreatory
graficznego interfejsu użytkownika, narzędzia tworzenia oprogramowania i pokaźne biblioteki
gotowych komponentów aplikacji. W tych obszarach punkty obiektowe zostały wykorzystane na
pokaźnym, choć nadal mocno ograniczonym zbiorze aplikacji i okazały się metryką nie gorszą od
punktów funkcyjnych.
Opracowanie porównujące szacunki oparte na punktach funkcyjnych z analogicznymi
opartymi na punktach obiektowych [Banker et al. 1994] przeanalizowało 19 różnych przykładów
oprogramowania inwestycyjno-bankowego, stworzonego przy użyciu ICASE i o wymaganym
nakładzie pracy od 4.7 do 71.9 roboczo-miesięcy. W wyniku badań okazało się, że wyniki metody
COCOMO 2, grudzień 2004
19
punktów obiektowych mieściły się w 73% zaś wyniki metody punktów funkcyjnych w 76%
w takim samym przedziale ufności przyjętym dla przeprowadzonych badań.
Następnie przeprowadzono eksperyment w sposób umożliwiający przeprowadzenie
analizy statystycznej [Kaufman i Kumar 1993], w którym czterech doświadczonych menedżerów
projektu szacowało przy pomocy Punktów Funkcyjnych i Punktów Obiektowych koszt prac
wymaganych do wykonania dwóch zakończonych już programów (stworzenie pierwszego zajęło
3.5 roboczo-miesięcy, drugiego – 6 r-mcy). W wyniku eksperymentu okazało się, że wyniki
szacunków Punktami Obiektowymi i Punktami Funkcyjnymi były tak samo dokładne (P.O.
uzyskały minimalnie większą dokładność, ale mniejszą niż wyniósł margines błędu eksperymentu).
Z kolei czas potrzebny na opracowanie szacunków metodą Punktów Obiektowych wyniósł około
47% (ponad 2 razy mniej) czasu potrzebnego przy Punktach Funkcyjnych. Wszyscy uczestnicy
eksperymentu uznali też, że metoda Punktów Obiektowych była prostsza w użyciu.
Powyższe wyniki nie były jeszcze potwierdzone w szerszych badaniach, niemniej w
zakresie Komponowania Aplikacji wydają się być dostatecznie obiecujące, aby uzasadnić wybór
metryki Punktów Obiektowych jako podstawowego modelu szacunkowego Komponowania
Aplikacji w metodzie Cocomo2.
4.4.1.1. Procedura szacowania kosztu metodą Punktów Obiektowych wykorzystana w
Cocomo2
Rysunek 6 przedstawia szkielet procedury szacowania kosztu prac metodą Punktów
Obiektowych, stosowaną dla komponowania aplikacji i prac prototypowych. Jest to syntetyczny
skrót metody opisanej w dodatku B3 w [Kaufman i Kumar 1993] i opisów produktywności z grupy
19-stu metryk z [Banker et al. 1994].
Wartości produktywności opracowano na podstawie danych z 2 kolejnych lat prac nad
różnym oprogramowaniem [Banker et al. 1994]. Podczas pierwszego roku narzędzie CASE nie
było jeszcze w pełni gotowe, a jego użytkownicy dopiero uczyli się zasad jego obsługi. W takiej
sytuacji średnią produktywność (wynoszącą 7 NOP/roboczo-miesiąc) w 12 cyklach produkcyjnych
podczas tego pierwszego roku uznano (na skali ocen „dojrzałość i wydajność ICASE
i pracowników) za niską. Z kolei w pracach nad siedmioma innymi programami podczas kolejnego
roku wydajność tak ICASE jak i personelu była zdecydowanie wyższa. Osiągnięty wtedy poziom
25 NOP/roboczo-miesiąc uznano (na w/w skali) za wysoki.
COCOMO 2, grudzień 2004
20
Rysunek 6. Szkielet procedury zliczania punktów obiektowych
Znaczenie pojęć użytych w rysunku wyżej:
• NOP: Nowe Punkty Obiektowe (liczba P.O. uwzględniająca zastosowanie
gotowego kodu ponownie użytego)
• srvr: ilość tabel danych serverów (mainframe lub równoważne) użytych w
połączeniu ze SCREEN i REPORT
• clnt: ilość tabel danych „klientów” („osobiste” stacje robocze {personal
workstation}) użytych w połączeniu ze SCREEN i REPORT
Krok 1: Zliczenie obiektów: oszacować liczbę ekranów, raportów i komponentów w 3GL (ew. 4GL)
wchodzących w skład aplikacji. Założyć, że w środowisku ICASE będą one zdefiniowane
standardowo.
Krok 2: Zakwalifikować każdy z tych obiektów jako łatwy, średnio trudny lub trudny, w zależności od
wielkości opisujących ten obiekt – zgodnie z poniższą tabelą:
Dla ekranów
Dla raportów
ilość i źródła tabel danych
ilość i źródła tabel danych
Ilość
Widoków
łącznie < 4
(<2 srvr
<3 clnt)
łącznie < 8
(2/3 srvr
3-5 clnt)
łącznie < 4
(>3 srvr
>5 clnt)
Ilość
części
łącznie < 4
(<2 srvr
<3 clnt)
łącznie < 4
(<2 srvr
<3 clnt)
łącznie < 4
(<2 srvr
<3 clnt)
<3
łatwy
łatwy
średni
0 lub 1
łatwy
łatwy
średni
3 do 7
łatwy
średni
trudny
2 lub 3
łatwy
średni trudny
8 i więcej
średni
trudny
trydny
4 i więcej
średni trudny trydny
Krok 3: Wyznaczyć wagę każdego obiektu przy pomocy prostego schematu podanego poniżej. Owa waga
opisuje właściwy nakład pracy niezbędny do stworzenia takiego obiektu.
Waga obiektu
Rodzaj Obiektu
Łatwy
Średni Trudny
Ekran 1
2
3
Raport 2
5
8
Komponent w 3GL (4GL)
10
Krok 4: Wyznaczyć ilość Punktów Obiektowych: dodać wagi wszystkich obiektów w aplikacji.
Krok 5: Oszacować procentową ilość kodu ponownie użytego, (współczynnik „reuse”). Wyznaczyć Nowe
Punkty Obiektowe, NOP = (Punkty Obiektowe) (100-%reuse)/100.
Krok 6: Wyznaczyć produktywność PROD (w NOP/roboczo-miesiąc) na podstawie tabeli:
Doświadczenie i wydajność
programistów
B. Niska
Niska
Przeciętna Wysoka B.
Wysoka
dojrzałość i wydajność ICASE
B. Niska
Niska
Przeciętna Wysoka B.
Wysoka
PROD
4 7 13 25 50
Krok 7: Obliczyć liczbę roboczo-miesięcy wg. wzoru: r-m = NOP / PROD.
COCOMO 2, grudzień 2004
21
• %reuse: procent gotowych ekranów, raportów lub modułów napisanych w 3GL
(4GL) uzyskanych z wcześniej stworzonych aplikacji, z uwzględnieniem
„wprowadzania ewentualnych modyfikacji” (degree of reuse).
Odnotujmy tu jeszcze jedną uwagę: używane tu pojęcia „obiekt” i „punkty obiektowe”
rozumie się w ten sposób, że obiektami są ekrany, raporty i moduły w 3GL (4GL). Może, ale nie
musi mieć to żadnego związku z takimi własnościami „obiektów” (w językach programowania) jak
dziedziczenie, enkapsulacja, przesyłanie komunikatów. Analizą takich obiektów, zdefiniowanych
np. w programie napisanym w C++, zajmiemy się w części następnej przy „źródłowych LOC”.
4.4.2. Rozwój Aplikacji
Jak już wspomniano w metrykach projektu wstępnego i późnych faz projektu w metodzie
Cocomo2 pomiar wielkości programu odbywa się przy pomocy Punktów Funkcyjnych
i Źródłowych LOC. Nieodzowne jest ujednolicenie reguł zliczania Punktów Funkcyjnych
i Źródłowych LOC, tak aby możliwe było porównywanie szacunków dokonywanych w całej
metodzie Cocomo2.
Metoda Cocomo2 przejęła reguły zliczania P.F. i Ź.LOC dość powszechnie zaakceptowane
w środowisku informatycznym. Metryki Źródłowych LOC opracowano na podstawie listy-definicji
Instytutu Inżynierii Oprogramowania (SEI) [Park 1992]. Metryki Punktów Funkcyjnych
zaczerpnięto zaś z wytycznych Międzynarodowej Grupy Użytkowników Punktów Funkcyjnych
[IFPUG 1994] [Behrens 1983] [Kunkler 1985].
4.4.2.1.Reguły zliczania Linii Kodu
W Cocomo2 za standardową linię kodu uważa się określone wyrażenie logiczne. Różnice
w strukturze poleceń i deklaracji w różnych językach utrudniają jednoznaczną definicję Linii Kodu
(LOC). Użycie miary LOC ma na celu ocenę ilości pracy intelektualnej, potrzebnej do stworzenia
danego programu. Trudno jest jednak ustalić taką definicję Linii Kodu aby była ona jednolita dla
wielu różnych języków programowania. Na przeciw tym trudnościom wychodzi opracowana przez
SEI lista kryteriów dla źródłowych operacji logicznych – definiujących LOC. Więcej o owej liście,
a także o podobnych opracowaniach SEI można znaleźć w [Park 1992, Goethert et al. 1992].
COCOMO 2, grudzień 2004
22
Jednostka miary: Linie Kodu
Wyrażenia Logiczne
Rodzaj wyrażenia Definicja
ν
Tabela Danych
Włączyć Wyłączyć
Jeśli linia kodu lub wyrażenie zawiera więcej niż jeden typ wyrażenia –
klasyfikuj jako ten o najwyższym priorytecie
1
ν
2
ν
3
ν
4
ν
5
ν
6
ν
7
ν
8
ν
1. Uruchamialne kolejność priorytetowa
→
2. Nieuruchamialne
3. Deklaracje
4. Dyrektywy kompilatora
5. Komentarze
6. Samodzielne w wierszu
7. W jednej linii z kodem
8. Transparenty i rozdzielacze (banners and spacers)
9. Puste komentarze
10. Puste linie
11.
Sposób realizacji Definicja
ν
Tabela Danych
Włączyć Wyłączyć
ν
ν
ν
ν
ν
ν
1. Zaimplementowana ręcznie
2. Stworzona przez generator kodu
3. Przetłumaczona przy pomocy zautomatyzowanego narzędzia
4. Skopiowana i użyta ponownie bez zmian
5. Zmodyfikowana
6. Usunięta
7.
Źródło Definicja
ν
Tabela Danych
Włączyć Wyłączyć
ν
ν
ν
ν
ν
ν
ν
ν
ν
ν
ν
1. Nowy projekt
2. Prowadzono już wcześniejsze prace: projekt bazuje na
3. Poprzedniej wersji
4. Gotowych, nabytych pakietach (z wyjątkiem bibliotek)
5. Oprogramowaniu na zamówienia (z wyjątkiem bibliotek)
6. Innym, wcześniej wykonanym programie
7. Bibliotece dostarczonej z językiem programowania (bez modyfikacji)
8. Elementach nabytego systemu operacyjnego lub programu użytkowego (j.w.)
9. Zmodyfikowanych bibliotekach języka lub elementach systemu operacyjnego
10. Innych bibliotekach dostępnych na rynku
11. Bibliotekach zaprojektowanych jako oprogramowanie do ponownego użytku
12. Innych komponentach, bibliotekach
13.
Rysunek 7
.
Lista-Definicja do Naliczania LOC
Rysunek 7 przedstawia część w/w listy-definicji w formie, w jakiej włącza się ją do
metody Cocomo2. Każdy check-mark w kolumnie Włączyć oznacza rodzaj wyrażenia lub jego
przymiot, który jest włączany do zliczanych LOC (i odwrotnie w kolumnie Wyłącz). Nie zostały
pokazane na rysunku wyżej części definicji opisujące parametry użycia, funkcjonalności, replikacji
i statusu rozwojowego. W definicji znajdują się też dodatkowe wskazówki dla specyficznych
COCOMO 2, grudzień 2004
23
wyrażeń z różnych języków programowania (Ada, C, C++, CMS-2, COBOL, FORTRAN, JOVIAL
i Pascal).
Definicja LOC w Cocomo2 odbiega nieco od tej opisanej w [Park 1992]. Główną różnicą
jest pominięcie tych kategorii oprogramowania, które w ramach prac implementacyjnych nie
wymagają dużych nakładów pracy. Z definicji usunięto więc gotowe pakiety zakupione na rynku,
oprogramowanie wykonane na zamówienie, gotowe biblioteki (dostępne w ramach języków
programowania, systemów operacyjnych itp.) Kod wygenerowany automatycznie nie jest wliczany
do miary LOC, niemniej dla pełniejszej analizy ilościowej pomiary wielkości oprogramowania będą
się odbywać zarówno z uwzględnieniem jak i z wyłączeniem kodu wygenerowanego
automatycznie.
„Linie Kodu wg. Cocomo2” zliczane są automatycznie przy pomocy narzędzia Amadeus
umożliwiającego obliczanie wartości metryk [Amadeus 1994] [Selby et al. 1991]. Narzędzie to
zapewnia jednolite i konsekwentne pozyskiwanie danych do późniejszej analizy w ramach projektu
Cocomo2. Autorzy niniejszego artykułu stworzyli zestaw wzorców dla Amadeus’a zgodnych z
definicjami zawartymi w Cocomo2. Stosowanie tych pakietów przez wszystkie organizacje
rozwijające Cocomo2 umożliwi sprawniejszą i bardziej jednolitą kolekcję danych liczbowych.
Amadeus umożliwia automatyczne zliczanie następujących metryk: całkowita ilość linii
kodu, komentarze, wyrażenia wykonywalne, deklaracje, interfejsy komponentów, zagnieżdżenia
i inne. Narzędzie to dostarcza bogaty wachlarz metryk, w tym metryki obiektowe opisane w
[Chidamber i Kemerer 1994]. Definicja metryk liczbowych w Cocomo2 będzie dalej
dostosowywana wraz z rozwojem próbki statystycznej pozyskanych wartości metryk z grupy LOC.
4.4.2.2.Reguły naliczania Punktów Funkcyjnych
Szacowanie kosztów oprogramowania przy pomocy punktów funkcyjnych opiera się na
mierze funkcjonalności (ilości i trudności zadań jakie program ma wykonać) i kilku czynnikach
ustalonych dla danego programu [Behrens 1983] [Kunkler 1985] [IFPUG 1994]. Punkty funkcyjne
są szczególnie przydatne z tej racji, że ich kalkulacja opiera się na informacjach dostępnych we
wczesnych fazach prac projektowych. Poniżej przedstawiono krótki opis zastosowania i naliczania
punktów funkcyjnych w metodzie Cocomo2.
COCOMO 2, grudzień 2004
24
Tabela 3. Typy Funkcji Użytkowych w FPA
Wejście Zewnętrzne (Wejścia) Policzyć wszystkie typy różnych danych lub decyzji wprowadzanych
przez użytkownika, które (i) przekraczają zewnętrzną granicę badanego
systemu informatycznego i (ii) powodują zmianę w danych w
wewnętrznych plikach logicznych.
Wyjście Zewnętrzne (Wyjścia) Policzyć wszystkie typy danych, które opuszczają zewnętrzne granice
mierzonego oprogramowania.
Wewnętrzny Plik Logiczny (Pliki)
Policzyć wszystkie główne logiczne grupy informacji na temat danych
lub decyzji wprowadzonych przez użytkownika. Dotyczy to wszystkich
plików logicznych (czyli wszystkich logicznych grup danych)
tworzonych, używanych i zachowywanych przez system.
Plik Zewnętrznego Interfejsu (Interfejsy)
Do Plików Zewnętrznego Interfejsu zaliczyć wszystkie pliki używane
wspólnie przez różne systemy informatyczne (lub przekazywane między
systemami).
Zewnętrzne Zapytanie (Pytania)
Policzyć wszystkie kombinacje wejście-wyjście w których jakaś dana
wejściowa powoduje natychmiastowe wygenerowanie danych
wyjściowych.
Punkty funkcyjne opisują funkcjonalność programu poprzez miarę przetwarzanych
informacji z zewnętrznych źródeł danych i przekazywanych na wyjście (ekran, pliki). Przy metryce
punktów funkcyjnych używa się pięciu typów funkcji użytkowych – opisanych powyżej.
Dla wszystkich elementów programu z pięciu typów funkcji użytkowych wyznaczane są
ich poziomy trudności (wagi), które następnie dodane do siebie dają sumę nieznormalizowanych
Punktów Funkcyjnych. Zazwyczaj następnym krokiem procedury naliczania Punktów Funkcyjnych
jest oszacowanie poziomu, w jakim 14-cie różnych czynników ma wpływ na tworzony program.
Wartości każdego z tych czynników wahają się od 0.0 do 0.65 i po dodaniu ich wszystkich (i
ewentualnym powiększeniu tej sumy tak, aby była nie mniejsza niż 0.65) dają współczynnik
poprawki z przedziału od 0.65 do 1.35.
Każdy z tych 14 czynników uwzględniających funkcje rozproszone, wydajność, użycie
gotowego kodu i inne, mógł mieć do 5% przyczynku do całości szacowanego nakładu prac.
Doświadczenia metody Cocomo zanegowały poprawność takiego modelu. W związku z tym w
Cocomo2 do szacowania wielkości używa się wyłącznie nieznormalizowanych Punktów
Funkcyjnych, które następnie mnoży się przez współczynniki wykorzystania gotowego kodu,
współczynniki źródeł kosztów i wykładnicze mnożniki skali. Rysunek 8 ukazuje procedurę
naliczania nieznormalizowanych punktów funkcyjnych w metodzie Cocomo2.
COCOMO 2, grudzień 2004
25
Rysunek 8. Procedura naliczania punktów funkcyjnych
4.4.3. Ponowne Użycie istniejącego kodu i Reinżynieria
4.4.3.1.Nieliniowe Koszty Ponownego Użycia istniejącego kodu
Podejście do reinżynierii i używania kodu istniejącego w metodzie Cocomo2 jest w sposób
istotny odmienne od reguł w jej poprzednikach. Nowinką w Cocomo2 jest to, że w tym przypadku
stosuje model nieliniowy. W pierwotnej metodzie Cocomo koszt stosowania istniejącego
oprogramowania był praktycznie liniową funkcją ilości zmian, jakie należy w nim wprowadzić.
Wymagało to oszacowania rozmiaru dopasowywanego oprogramowania, ASLOC i trzech
parametrów wielkości zmian: DM (% zmian projektowych), CM (% wymiany kodu) i IM (koszt
złożenia zmodyfikowanego kodu w całość, jako % wartości pierwotnych nakładów integracji
systemu).
Krok 1: Zliczyć punkty funkcyjne według typów funkcji. Opracowane na podstawie danych o wymaganiach i
projekcie oprogramowania, przez wiodącego członka zespołu projektowego. Każdy z pięciu typów funkcji
użytkowych (Wewnętrzny Plik Logiczny* (ILF), Plik Zewnętrznego Interfejsu (EIF), Wejście Zewnętrzne
(EI), Wyjście Zewnętrzne (EO) Zewnętrzne Zapytanie (EQ)) musi być znany.
Krok 2: Wyznaczyć poziomy trudności tych elementów. Poziom trudności może mieć wartości: Niski, Średni lub
Wysoki, zależnie od liczby zawartych typów danych i liczby plików różnych typów weń użytych. Do
oceny stosuje się następujące kryteria:
Dla ILF i EIF
Dla EO i EQ
Dla EI
Elementy Danych
Elementy Danych
Elementy Danych
Elementy
rekordu
1-19 20-50 >50
Typy
plików
1-5 6-19 >19
Typy
plików
1-4 5-15 >15
1 N N Ś
0 lub 1
N
N
Ś 0
lub
1 N N Ś
2-5 N Ś W 2-3 N Ś W 2-3 N Ś W
>5
Ś W W >3 Ś W W >3 Ś W W
Krok 3: Wyznaczyć wagę każdego elementu przy pomocy prostego schematu niżej:
Trudność - Waga
Typy
Funkcji
Niska
Średnia Wysoka
ILF 7
10
15
EIF 5
7
10
EI 3
4
6
EO 4
5
7
EQ 3
4
6
Krok 4: Wyznaczyć ilość nieznormalizowanych Punktów Funkcyjnych: dodać wagi wszystkich elementów w
programie.
____________
*
Uwaga: słowo plik oznacza tu grupę powiązanych za sobą danych, a nie fizyczną implementację takiej grupy.
COCOMO 2, grudzień 2004
26
Oto formuła, według której Cocomo obliczał ekwiwalent ilości nowego kodu w sensie
rozmiaru używanego ponownie oprogramowania istniejącego:
100
)
3
.
0
3
.
0
4
.
0
(
IM
CM
DM
ASLOC
ESLOC
×
+
×
+
×
×
=
( 1 )
Jak widać oprogramowanie użyte bez zmian spowoduje zerowy wzrost nakładów
(kosztów). W przeciwnym razie wzrost szacowanej wielkości programu będzie liniową funkcją
DM, CM i IM. Okazuje się jednak, jak udowadnia analiza kosztów wdrażania istniejącego
oprogramowania w [Selby 1988] opracowana na podstawie doświadczeń Laboratorium Inżynierii
Oprogramowania NASA z prawie 3000 ponownie użytych modułów oprogramowania, że koszty
ponownego użycia oprogramowania odbiegają od modelu liniowego w dwojaki sposób:
• funkcja kosztów nie przebiega przez początek układu współrzędnych. Na ogół
mniej-więcej 5cio procentowy koszt przypada na samo przejrzenie, wybranie i
zrozumienie przydatnych komponentów.
• nieznaczne zmiany pociągają za sobą nieproporcjonalnie duże koszty.
Spowodowane jest to głównie potrzebą wcześniejszego dobrego zrozumienia
istniejącego oprogramowania oraz względnym kosztem sprawdzenia interfejsów.
Model dostosowywania istniejącego oprogramowania użyty w Cocomo2 uwzględnia te
nieliniowości.
4.4.3.2.Model Dostosowywania istniejącego kodu użyty w Cocomo2
Według [Parikh i Zvegintzov 1983] aż 47% kosztów pielęgnacji istniejącego
oprogramowania przypada na poznawanie i przyswajanie oprogramowania poddawanego
modyfikacjom. W takiej sytuacji przejście z używania kodu bez zmian (black-box) na kod
dostosowywany do potrzeb istniejącego oprogramowania (white-box) pociąga za sobą skokowy
wzrost kosztów. Ponadto konieczność ponownego przetestowania interfejsów międzymodułowych
pociąga za sobą dodatkowe nakłady pracy. W [Gerlich i Denskat 1994] pokazano, że zmiany w k z
m modułów wymagają wykonania N testów, gdzie N = k*(m-k) + k*(k-1)/2.
Rysunek 9 pokazuje zależność między ilością zmodyfikowanych modułów k i liczbą
testów potrzebnych do sprawdzenia poprawnego działania interfejsów. Kształt krzywej będzie też
podobny dla innych wartości parametru m (całkowita liczba modułów). Widać więc, ze nakłady
COCOMO 2, grudzień 2004
27
prac podczas projektowania, tworzenia, integrowania i testowania zmodyfikowanego kodu nie są
liniową funkcją ilości dokonanych zmian.
Rysunek 9. Nieliniowe koszty dostosowywania istniejącego oprogramowania
Rysunek 10. Liczba testów interfejsów między-modułowych jako funkcja ilości zmian
Koszty przyswajania i testowania oprogramowania można ograniczać poprzez tworzenie
kodu o właściwej strukturze. Pisanie oprogramowania o strukturze modularnej i hierarchicznej
może ograniczyć ilość niezbędnych testów interfejsów [Gerlich i Denskat 1994], a w dodatku taka
budowa systemu informatycznego powinna ułatwiać jego szybsze przyswajanie. Prawdy te są
odzwierciedlone w Cocomo2 w szacunkach nakładu pracy przy wykorzystywaniu istniejącego
COCOMO 2, grudzień 2004
28
oprogramowania. Zmodyfikowana formuła obliczania zależności liczby linii nowego kodu i
rozmiaru ponownie użytego oprogramowania jest następująca:
100
)
3
.
0
3
.
0
4
.
0
(
IM
CM
DM
SU
AA
ASLOC
ESLOC
×
+
×
+
×
+
+
×
=
( 2 )
Wartość SU – nakładu pracy na przyswajanie oprogramowania – otrzymuje się z tabeli 4.
Wyznaczane tam wartości SU mogą się wahać od 10% przyrostu pracy dla oprogramowania
napisanego w sposób przejrzysty, intuicyjny, o dobrej strukturze i ze stosowną liczbą komentarzy,
do 50% dla kodu trudno przyswajalnego.
Drugi zaś nowy współczynnik we wzorze (2), tj. AA (Oceny i włączania) – symbolizuje
prace konieczne do sporządzenia oceny przydatności istniejącego oprogramowania w tworzeniu
nowej aplikacji, oraz do włączenia dokumentacji tego oprogramowania do całości dokumentacji
programu. Tabela 4. podaje wartości parametru AA w zależności od sytuacji. W ocenie kosztów
przeróbek oprogramowania czynnik AA stanowi rozwinięcie opisanego w [Boehm 1981, str. 558]
tzw. Współczynnika Planowania Zmian.
Tabela 4. Wartości wskaźnika Zrozumiałości Oprogramowania (SU) w zależności od jakości kodu
Bardzo niska
Niska
Przeciętna
Wysoka
B. wysoka
Ustruktu-
ralnienie
Bardzo słabe
pogrupowanie
kodu, wysoki
„coupling”,
poplątany kod.
słabe
pogrupowanie,
wysoki
„coupling”
(sprzężenie)
dość dobra
struktura, ale z
kilkoma słabymi
punktami
dobre
pogrupowanie,
niski „coupling”
Modułowość,
informacje
ukryte w
strukturach
danych
Przejrzystość Brak powiązania
między punktem
widzenia
programisty i
użytkownika
Słaba korelacja
między punktem
widzenia
programisty i
użytkownika
Średnia korelacja
między strukturą
kodu a
działaniem
programu
Dobra korelacja
kod-aplikacja
Oczywiste
powiązanie kodu
z działaniem
aplikacji (od str.
użytkownika)
Zrozumiałość
kodu
Kod niejasny.
Dokumentacja
wybrakowana,
zagmatwana i
przestarzała
Nieznaczna ilości
komentarzy i
nagłówków.
Część dokumen-
tacji użyteczna.
Średni poziom
komentarzy,
dokumentacji i
nagłówków.
Dobra dokumen-
tacja, nagłówki i
komentarze, ale z
paroma słabymi
punktami.
Zrozumiały kod,
aktualna
dokumentacja,
uwzględniające
uzasadnienia
wartość wspł.
SU
50 40 30 20 10
COCOMO 2, grudzień 2004
29
Tabela 5. Skala wartości Współczynnika AA.
Wartość współczynnika AA
Prace nad ocena i włączeniem oprogramowania
0 Brak
2 Proste
wyszukiwanie
modułów i dokumentacji
4 Nieznaczna
ilość testów/ocen modułów; dokumentacja
6 Znacząca ilość testów/ocen modułów; dokumentacja
8 Szczegółowe testowanie i ocena modułów, dokumentacja
4.4.3.3.Szacowanie kosztów reinżynierii i konwersji oprogramowania
Model stosowania istniejącego oprogramowania wymaga dalszych uściśleń
uwzględniających reinżynierię i konwersję oprogramowania. Wydajność współczesnych
zautomatyzowanych narzędzi do przerabiania/konwersji oprogramowania jest tak wysoka, iż nawet
bardzo znaczące zmiany w oprogramowaniu (tzn. o wysokiej wartości parametru CM – procentu
wymiany kodu) wykonywane są stosunkowo małym nakładem pracy. Przykładowo, w jednej z
prac w NIST 80% kodu (13 131 wyrażeń w COCOLu) było zmienione przy pomocy
zautomatyzowanego narzędzia i wymagało nakładu pracy wynoszącego 35 roboczo-miesięcy.
Estymacja wykonana metodą Cocomo oszacowała ten nakład pracy na 152 roboczo-miesiące
(ponad 4 razy więcej) [Ruhl i Gunn 1991].
Wobec powyższego Cocomo2 wprowadza następny parametr AT, oznaczający procent
kodu przetwarzanego przez automatyczne translatory. Na podstawie danych doświadczalnych
wyznaczono pracochłonność automatycznej translacji i wynosi ona 2400 wyrażeń kodu źródłowego
/ roboczo-miesiąc. Opisany wcześniej model wykorzystania istniejącego oprogramowania stosuje
się dla pozostałego kodu, nie translowanego automatycznie.
Tabela 6. Wartości stopnia automatycznego przerabiania kodu
proces reinżynierii
AT (% automatycznego przerabiania)
plikami wsadowymi
96%
plikami wsadowymi + SORT
90%
plikami wsadowymi + DBMS
88%
pliki wsadowe, SORT i DBMS
82%
Interaktywne 50%
Szacunkowe wartości parametru AT wyznaczono w dużej mierze na podstawie danych z
prac NIST i pokazano je w tabeli wyżej. Współczynnik AT okazuje się być pewnym rodzajem
funkcji granicznej (np.: wykorzystania pakietów COTS, przejścia z operacji wykonywanych
COCOMO 2, grudzień 2004
30
plikami wsadowymi na interaktywne) umożliwiającej ocenę w granicy kosztu oprogramowania
wytworzonego niezmienionym i przetranslowanym kodem.
4.4.4. Występowanie Usterek
W Cocomo2 zastąpiono występujące w Cocomo i Ada Cocomo współczynnik zmienności
wymagań poprzez procentowy wskaźnik występowania usterek: BRAK. Powoduje on w podobny
sposób regulowanie efektywnej wielkości programu. Przykładowo załóżmy, że gotowy produkt
może zawierać 100 000 wyrażeń. Miara ta nie uwzględnia dodatkowych 20 000 wyrażeń które
musiały być zmienione w celu poprawienia programu. Wartość wskaźnika BRAK w takim
programie wynosiłaby 20, a efektywny rozmiar programu w szacunkach Cocomo2 wyniósłby
łącznie 120 000 wyrażeń. W modelu Komponowania Aplikacji nie stosuje się czynnika BRAK,
gdyż jest on tam domyślny.
4.4.5. Pielęgnacja oprogramowania
Główną miarą nakładów pracy na pielęgnację oprogramowania używaną w pierwotnej
metodzie Cocomo był Roczny Przepływ Zmian (ACT), czyli procent oprogramowania które było
poprawione/dodane w ciągu roku. Miara ta nie zdała egzaminu, albowiem była ograniczona do
rocznych przedziałów czasu, a także kłóciła się z wynikami zastosowania modelu ponownego
użycia istniejącego oprogramowania. By uniknąć podobnych problemów w metodzie Cocomo2,
użyto modelu dostosowania istniejącego kodu także do zagadnień pielęgnacji oprogramowania.
4.5. Czynniki wpływające na koszt: Skala Programu
4.5.1. Modelowania tzw. ekonomii lub anty-ekonomii skali w pracach informatycznych
Ekonomią skali nazywa się zjawisko zmniejszenia kosztów jednostkowych wytwarzania
spowodowane wyłącznie poprzez wzrost wielkości produkcji. Anty-ekonomią skali będzie
natomiast wzrost kosztów przy wzroście wielkości. Zjawiska te w procesie produkcji
oprogramowania modelowanie są w Cocomo2 przy pomocy wykładniczej funkcji wielkości
programu. Czynnik ekonomii bądź anty-ekonomii skali oznaczony jest jako B w poniższym
wzorze:
B
Wielkosc
A
Naklady
)
(
×
=
( 3 )
COCOMO 2, grudzień 2004
31
W przypadku gdy B < 1.0, mamy do czynienia z ekonomią skali. Dwukrotne
powiększenie rozmiaru programu powoduje wzrost kosztów o czynnik mniejszy niż 2. Wydajność
produkcji wzrasta więc ze wzrostem wielkości samego programu. Ekonomię skali można czasem
uzyskać poprzez stosowanie w procesie wytwórczym stosownych narzędzi (symulacji, platform do
testowania), na ogół jednak ekonomia skali jest rzadkością. W przypadku małych produkcji stałe
koszty początkowe (rozpoczęcie produkcji, zakupienie i przygotowanie narzędzi, prace
administracyjne) są źródłem ekonomii skali.
Jeśli B = 1.0 to zjawiska ekonomii i anty-ekonomii skali równoważą się wzajemnie. Przy
szacowaniu kosztów niewielkich projektów często posługuje się takim modelem liniowym. W
metodzie Cocomo2 model taki stosuje się dla Komponowaniu Aplikacji.
Przypadek B > 1.0 oznacza anty-ekonomię skali. Dzieje się tak zwykle z dwu głównych
przyczyn: większej ilości czasu potrzebnego na przekazywanie informacji w zespołach ludzkich
i dodatkowych prac wymaganych do integracji systemu. Większa liczba ludzi zaangażowanych
w tworzenie pokaźnego programu w oczywisty sposób oznacza większą ilość kontaktów
międzyludzkich (przekazywanie informacji, dopracowywanie złożonych pomysłów itp.) które
konsumują czas pracy. Ponadto włączanie mniejszej części oprogramowania do większej całości
wymaga nie tylko stworzenia samego modułu, ale także zaprojektowania, doglądania, integrowania
i testowania interfejsów między tą częścią a resztą produktu.
Wstępna wartość parametru A została w Cocomo2 ustalona na 3.0. Pierwsze przymiarki
tego modelu do danych liczbowych z Cocomo [Boehm 1981, str. 496-97] wskazują, że jest to
całkiem rozsądny punkt wyjściowy.
4.5.2. Określenie skali prac w Cocomo i Ada Cocomo
Analiza danych liczbowych przy pracach nad metodą Cocomo wykazała, że większość
programów cechowała anty-ekonomia skali. Systemy informatyczne podzielono w tej metodzie na
trzy główne grupy (Organiczna, Wpół-Odłączona i Wbudowana), dla których wartości parametru B
wynosiły odpowiednio 1.05, 1.12 i 1.20. Przyczyny tych różnic leżały głównie w szczegółach
realizacji produktu: systemy wbudowane są generalnie najbardziej bezprecedensowe, wymagają
większego przepływu informacji między zespołami programistów i sprawiają więcej trudności
podczas integracji całego systemu. Jednocześnie wymagania sprzętowe i czasowe są bardziej
COCOMO 2, grudzień 2004
32
restryktywne – wszelkie problemy projektowe trzeba rozwiązać w ograniczonym czasie i budżecie,
przy restryktywnych wymaganiach sprzętowych i nie dopuszczającym zmian opisie interfejsów.
Zmiany wprowadzone w metodzie Ada Cocomo miały na celu uwzględnienie faktu, iż
zmiana parametrów procesu produkcji może ograniczyć efekt anty-ekonomii skali. Wymagany
przepływ informacji i nakłady na integrację systemu obniżony będzie przez m.in.: wczesną redukcję
ryzyka i błędów; stosowanie dokładnych i sprawdzonych specyfikacji architektury; uściślenie
wymagań; itp. W Ada Cocomo wartość parametru B zależała od stosowania tych praktyk
w realizacji programu [Boehm i Royce 1989, Royce 1990].
Taki model zastosowano w Ada Cocomo tylko w odniesieniu do oprogramowania
systemów wbudowanych, gdzie w miejsce pojedynczej wartości współczynnika B (= 1.20)
umożliwiono wahania tej wartości między 1.04 a 1.24. Zależy to od stopnia stabilności wymagań i
architektury, redukcji ryzyka dojrzałości procesu produkcji oraz innych czynników redukujących
anty-ekonomię skali.
4.5.3. Skalowanie prac w Cocomo2
Cocomo2 łączy w sobie modele obu swoich poprzedników. Do metody Ada Cocomo jest
podobna w tym, że stosuje zestaw składników, których suma daje wartość B. Część z tych
składników pozostała bez zmian, choć współczynniki architektury i ryzyka połączono w jedną
wartość, a wyznacznik dojrzałości procesu stosowany w Ada Cocomo zastąpiono podobną
wielkością zdefiniowaną przez Instytut Inżynierii Oprogramowania (SEI). (Szczegóły tej definicji
są obecnie dopracowywane przez SEI.) Z kolei w spadku po pierwotnej metodzie Cocomo,
w wersji 2.0 znalazły się składniki opisujące „bezprecedensowość” (precedentness) i elastyczność
wymagań programu które zastąpiły wcześniejszy podział oprogramowania na 3 grupy (organiczna,
współzależna i wbudowana z Cocomo). Nowością w Cocomo2 jest ocena zgrania personelu, która
uwzględnia wpływ słabej koordynacji prac na nasilenie anty-ekonomii skali. Usunięto natomiast
czynnik zmienności wymagań (z Ada Cocomo) – zwiększenie kosztu produktu końcowego jest
teraz zamknięte we współczynniku „występowania usterek” (Breakage).
W tabeli 7 podano wartości składników do wykładnika skali programu. Oceny z każdej
kategorii, W
i
, są do siebie dodane i dają wartość współczynnika B wg. wzoru (4).
COCOMO 2, grudzień 2004
33
∑
+
=
i
W
B
01
.
0
01
.
1
( 4 )
Tabela 7. Oceny składników wykładnika skali projektu.
(W
i
) Elementy
współczynnika skali
B. Niska
(5)
Niska
(4)
Normalna
(3)
Wysoka
(2)
B. Wysoka
(1)
Wybitnie
Wysoka (0)
bezprecedensowość
problemu / zadania
Całkowicie
bez preced.
większość bez
precedensu.
częściowo
bez preced.
generalnie
nieobcy
większość
nieobca
Całkowicie
znany
elastyczność
wymagań
Rygorystycz
-ne
możliwe małe
odstępstwa
możliwe
odstępstwa
średnia
elastyczność
duża
elastyczność
znane tylko
ogólne cele
Architektura /
usunięcie ryzyka *
małe (20%)
średnie (40%)
ponad pół
(60%)
większość
(75%)
prawie pełne
(90%)
Pełne
(100%)
zgranie zespołu Bardzo
utrudnione
kontakty
utrudnione
kontakty
średnio
dobre
kontakty
dość dobre
kontakty
bardzo dobre
kontakty
Idealny
przepływ
informacji
Dojrzałość procesu +
Średnia ważona odpowiedzi twierdzących na kwestionariusz CMM
* % zakończenia specyfikacji interfejsów między głównymi modułami; % wykonania prac eliminacji ryzyka;
+ kwestionariusz Modelu Dojrzałości Produkcyjnej (CMM od Capability Maturity Model) jest opracowywany z udziałem SEI.
Dojrzałość procesu produkcji będzie średnią ważoną odpowiedzi na pytania dotyczące 18 kluczowych aspektów procesu
produkcji w CMM [Paulk et al. 1993]. Wagi poszczególnych odpowiedzi nie są jeszcze ustalone
Przykładowo, program o wielkości 100K Źródłowych LOC, który otrzymał wyjątkowo
wysokie (=0) noty we wszystkich elementach skali programu, będzie miał wykładnik skali B = 1.01
(bo sumaW=0) i wyskalowany nakład pracy wzrośnie do 105 roboczo-miesięcy. Z kolej
otrzymanie samych bardzo niskich (=5) ocen da w wyniku wartość B = 1.26 (sumaW=25) i wzrost
nakładu pracy do 331 roboczo-miesięcy. Jest to bardzo duży skok, choć trzeba zauważyć, że mała
zmiana (o 1) jednego tylko parametru spowoduje tylko 4.7 procentową zmianę szacowanych
kosztów. W ten sposób Cocomo2 zapobiega aż 40% zmianom szacowanego nakładu prac
spowodowanym odmienną interpretacją charakteru prac w modelu skalowania metody Cocomo.
4.6. Czynniki wpływające na koszt: Dodatkowe czynniki zwiększające nakład pracy
Podobnie jak w Cocomo i Ada Cocomo w metodzie Cocomo2 używa się zestawu
współczynników regulujących końcową wartość szacunków w roboczo-miesiącach. Wartości
otrzymane po uwzględnieniu wykładniczej skali projektu, mnożone są następnie przez dodatkowe
czynniki zwiększające nakład pracy:
∏
×
=
i
i
e
a
no
poprawione
EM
PM
PM
)
(
ln
min
( 5 )
Głównymi kryteriami doboru współczynników EM były w Cocomo2:
COCOMO 2, grudzień 2004
34
• ciągłość: z wyjątkiem uzasadnionych przypadków, sposób naliczania nakładu
prac pozostawiono taki sam, jak w poprzednikach – Cocomo i Ada Cocomo.
• oszczędność: współczynniki przyrostu kosztów zostały umieszczone w
Cocomo2 wyłącznie w przypadkach, gdy samodzielnie i adekwatnie opisują
znaczący czynnik wpływające na zmianę nakładu pracy.
4.6.1. Czynniki Produktu
4.6.1.1.RELY – Wymagana Niezawodność Oprogramowania
Skala ocen i waga współczynnika RELY zostały w Cocomo2 zachowane po pierwotnej
Cocomo. Z kolei w metodzie Ada Cocomo zawężono zbiór możliwych wartości tego
współczynnika dla wyższych poziomów wymaganej niezawodności, uważano bowiem, że
rygorystyczne przestrzeganie typów zmiennych, wbudowana wielozadaniowość, wyjątki i inne
atrybuty języka programowania Ada ułatwią tworzenie niezawodnego oprogramowania. Analiza
danych liczbowych tez tych nie potwierdziła, wobec czego W Cocomo2 powrócono do opisu RELY
z pierwotnej Cocomo.
Tabela 8. Skale szacowania czynników wzrostu kosztów w modelu Post-Architekturowym
B. Niski
Niski
Normalny
Wysoki
B. Wysoki
Wyj. Wysoki
RELY minimalna
niewygoda
Niska, łatwo
naprawialne
średnio-łatwo
naprawialne
duze straty
finansowe
ryzyko dla
życia ludzi
DATA
DB
bytes/Pgm
SLOC < 10
10
≤ D/B <100 100 ≤ D/B <
1000
D/P
≥ 1000
CPLX
patrz Tabela 8.
RUSE
Brak
w
danym
podzespole
w całym
programie
w całej linii
produkcyjnej
wielu liniach
produkcyjnych
DOCU Wiele
potrzeb
niezaspokoj.
Część potrzeb
niezaspokoj.
Stosowna do
potrzeb
zbyt obszerna
zdecydowanie
zbyt obszerna
TIME
≤ 50% dostęp.
czasu pracy
70% 85% 95%
STOR
≤ 50% dostęp-
nej pamięci
70% 85% 95%
PVOL
duże zmiany
co 12 m-cy;
małe co 1 m-c
duże: 6 m-cy;
małe: 2 tyg.
duże: 2 m-ce;
małe: tydzień
duże: 2 tyg.;
małe: 2 dni
ACAP
kwantyl 15 rz. kwantyl 30 rz. kwantyl 55 rz. kwantyl 75 rz. kwantyl 90 rz.
PCAP
kwantyl 15 rz. kwantyl 30 rz. kwantyl 55 rz. kwantyl 75 rz. kwantyl 90 rz.
PCON
48% / rok
24% / rok
12% / rok
6% / rok
3% / rok
AEXP
≤ 2 miesiące
6 miesięcy
1 rok
3 lata
6 lat
PEXP
≤ 2 miesiące
6 miesięcy
1 rok
3 lata
6 lat
LTEX
≤ 2 miesiące
6 miesięcy
1 rok
3 lata
6 lat
TOOL
edycja, debug
proste, począt-
kowe i końco-
podstawowe
narzędzia
dobry,
dojrzały zes-
dobre, dojrzałe
i postępowe
COCOMO 2, grudzień 2004
35
B. Niski
Niski
Normalny
Wysoki
B. Wysoki
Wyj. Wysoki
we CASE,
nieznaczna
integracja
cyklu prod.,
średnio
zintegrowane
taw narzędzi,
średnio
zintegrowane
narzędzia
zintegrowane
z metodami
produkcji i
wielokrotnym
użyciem kodu
SITE:
Bliskość
międzynaro-
dowe
Różne miasta i
różne firmy
różne miasta
albo firmy
obszar miasta
(metropolii)
budynek lub
kompleks
w jednym
miejscu
SITE:
Tele-
komunikacja
poczta, kilka
telefonów
FAX, każdy
ma telefon
zwykły e-mail pojemne łącza
elektroniczne
pojemne łącza
elektroniczne
+ okazyjne
telekonferenc.
interaktywne,
multimedialne
SCED 75%
nominalnego
85% 100% 130% 160%
4.6.1.2.DATA – Wielkość Bazy Danych
Podobnie jak w przypadku RELY, analiza danych liczbowych nie wykazała potrzeby
zmian ocen i wartości współczynników. Zachowując kryterium ciągłości współczynnik DATA w
Cocomo2 pozostał bez zmian.
4.6.1.3.CPLX – Złożoność (trudność) Produktu
Tabela 8 przedstawia nową skalę not dla CPLX w Cocomo2. Zmiany, które miały
miejsce, odzwierciedlają postęp w technologii komputerowej i tworzeniu oprogramowania.
Polegały one na dodaniu skali dla Operacji Zarządzania Interfejsem Użytkownika, uwzględnieniu
wpływu przetwarzania rozproszonego i równoległego, oraz uwzględnieniu postępu w technologii
warstwy pośredniej i obiektów baz danych.
Zbiór wartości współczynnika CPLX w Ada Cocomo był zmniejszony dla bardziej
złożonych programów. Uważano, że mechanizmy w języku Ada (wielozadaniowość, wyjątki,
enkapsulacja i inne) ułatwią rozwiązywanie dotychczas trudnych problemów. W Tabeli 8 widzimy
jednak dodatkowy, Wyjątkowo Wysoki poziom trudności oprogramowania dla dziedzin takich, jak
przetwarzanie równoległe, rozproszone sterowanie w warunkach silnego uwarunkowania czasem
rzeczywistym (hard real time) i wirtualna rzeczywistość, które akurat w Ada (czy innych nowych
językach programowania) nie są szczególnie ułatwione. Zdaje się, że wzrost wymagań na
oprogramowanie rozwiązujące złożone problemy bez trudu nadąża za postępem w techikach
COCOMO 2, grudzień 2004
36
rozwiązywania tych problemów. W takiej sytuacji zachowanie skali dla CPLX z pierwotnej
metody Cocomo wydaje się być jak najbardziej na miejscu.
4.6.1.4.RUSE – Wymagane ponowne użycie tworzonego oprogramowania
Ten współczynnik wzrostu kosztów dodano w metodzie Ada Cocomo, aby uwzględnić
wzrost nakładów pracy na stworzenie kodu dostosowanego do późniejszego wielokrotnego użycia
w różnych programach. Współczynnik miał cztery kategorie ocen i przybierał wartości między 1.0
a 1.5. Późniejsze doświadczenia wykazały, że konieczne było rozszerzenie ilości kategorii i
zakresu wartości. Przykładowo doświadczenia AT&T (American Telephone & Telegraph), w
których tworzenie kodu do późniejszego wielokrotnego użytku spowodowało 2.25-krotny wzrost
kosztów. Co prawda wymagania odnośnie wielokrotnego użycia korespondowały też ze zwiększoną
niezawodnością oprogramowania, zatem właściwy współczynnik wzrostu kosztów wyniósłby w
Ada Cocomo (1.5)(1.4) = 2.10, a nie 1.5. Zmiana wprowadzone w Cocomo2 rozszerza zakres
wartości RUSE do 1.75, co w efekcie połączenia RUSE*RELY może dać wartości do (1.75)(1.5) =
2.45.
4.6.1.5.DOCU – przydatność wymaganej dokumentacji przy budowaniu oprogramowania
Część modeli szacowania kosztów oprogramowania zawiera odpowiednik wartości DOCU
zależny od rozmiarów wymaganej dokumentacji. W Cocomo2 natomiast skala ocen tego
współczynnika opisana jest przydatnością wymaganej dokumentacji do potrzeb cyklu produkcji.
Noty zaczynają się na poziomie Bardzo Niskim (potrzeby produkcyjne niezaspokojone) a kończą na
Bardzo Wysokim (nadmiar dokumentacji z punktu widzenia potrzeb producentów). Zakresu (iloraz
wartości największej przez najmniejszą) współczynnika DOCU wynosi 1.35.
4.6.1.6.Czynniki Platformy
Określenie „platforma” odnosi się do docelowego zastawu sprzętu i oprogramowania, z
którymi dany program ma pracować (dawniej: „maszyna wirtualna”). Czynniki platformy zostały
częściowo zmodyfikowane w porównaniu z poprzednimi wersjami metody – szczegóły tych zmian
są opisane poniżej. Niektóre z rozważanych czynników usunięto (np.: rozproszenie, stopień
COCOMO 2, grudzień 2004
37
wbudowania, wymagania czasu rzeczywistego) gdyż zagadnienia te są już uwzględnione w
Złożoności Produktu (CPLX).
Tabela 9.
Wyznaczanie trudności dla różnych typów modułów
B. Niski
Niski
Normalny
Wysoki
B. Wysoki
Wyb. Wysoki
Operacje
sterujące
Szereg prostych,
nie zagnieżdżo-
nych operacji:
DO, CASE,
IFTHENELSE.
Prosta kompozyc-
ja modułowa z
wywołaniami
procedur i
„skryptami”.
Proste zagnież-
dżenie struktur
programu.
Przewaga
prostych
„predykatów”.
Przeważnie proste
zagnieżdżanie.
Przypadki stero-
wania między-
modułowego.
Tabele decyzyjne,
proste „callbacks”
lub przekazywa-
nie wiadomości.
Przetwarzanie
rozproszone przy
udziale warstwy
pośredniej.
Wysoce
zagnieżdżone
operacje o wielu
złożonych
„predykatach”.
Nadzorowanie
kolejek i stert.
Jednolite przetwa-
rzanie rozproszo-
ne. Pojedynczy
procesor pracuje
w warunkach
„miękkiego”
czasu
rzeczywistego.
Rekurencja i
wielokrotne
uruchamianie.
Obsługa przerwań
o bez zmian ich
priorytetów.
Synchronizacja
procesów, złożone
callbacks,
Przetwarzanie
rozproszone.
Pojedynczy
proce-sor
realizujący
zadania
„twardego czasu
rzeczywistego
Koordynacja
zasobów o
zmiennych
priorytetach.
Sterowanie na
poziomie mikro-
kodu. Praca
układu wielo-
procesorowego w
warunkach
„twardego” czasu
rzeczywistego.
Operacje
obliczenio-
we
Obliczanie pros-
tych wyrażeń, n.p.
A=B+C*(D-E)
Obliczanie śred-
nio trudnych
wyrażeń, n.p:
D=Sqrt(B**2-
4*A*C)
Wykorzystanie
standardowych
operacji matema-
tycznych i statys-
tycznych. Podsta-
wowe operacje na
macierzach i
wektorach.
Podstawy analizy:
interpolacja
„wielu zmiennych
zwykłe równania
różniczkowe.
Podwyższona
waga zaokrąglania
Złożona analiza
numeryczna:
równania z macie-
rzami niemal-
jednostkowymi,
cząstkowe równa-
nia różniczkowe.
Prosta paraleliza-
cja obliczeń.
Złożona i „nie-
strukturalna” ana-
liza numeryczna:
dyża dokładność
brzy danych
stochastycznych z
szumem. Złożona
paralelizacja
obliczeń
Operacje
specyficzne
dla urządze-
nia
Proste komendy
odczytu i zapisu.
Wyrażenia o
przejrzystym
formacie.
Zbędna wiedza na
temat danego
procesora czy
urządzenia I/O.
Wejście/wyjście
na poziomie
operacji GET i
PUT.
Przetwarzanie I/O
zawiera wybór
urządzenia,
sprawdzenie
statusu i obsługę
błędów.
Operacje na fizy-
cznym poziomie
I/O (przeliczanie
adresów fizycz-
nych; szukanie,
czytanie danych)
Zoptymalizowane
operacje I/O.
Operacje obsługi,
diagnozowania i
ukrywania przer-
wań. Obsługa
linii komunikacyj-
nych. Systemy
wbudowane o
dużej szybkości
działania.
Działanie zsyn-
chronizowane z
pracą urządzenia,
część programu w
mikro-kodzie.
Systemy
wbudowane o
wyśrubowanych
osiągach.
Operacje
zarządzania
danymi
Proste tablice w
pamięci. Proste
zapytania i
zmiany w bazie
danych COTS
Pojedynczy plik z
pojedynczym ty-
pem danych, bez
zmian w pliku,
bez pośrednich
plików. Średnio
zaawansowane
operacje w bazie
danych COTS.
Dane wejściowe z
wielu plików,
wyjściowe do
jednego. Niewiel-
kie zmiany ich
struktury.
Złożone operacje
w bazie danych
COTS.
Proste „odpalacze
(triggers)
uruchamiane
przez zawartośc
strumienia danych
Złożone manipu-
lacje na struktu-
rach danych.
Koordynacja
rozproszonej bazy
danych. Złożone
„odpalacze”.
Optymizacja
przeszukiwania
danych.
Wysoce sprzężo-
ne, dynamiczne
struktury
obiektów i relacji.
Zarządzanie
danymi w
językach
naturalnych (a.
ludzkich)
Operacje
interfejsu
użytkow-
nika
Proste formy do
danych wejścio-
wych, generatory
raportów
Proste kreatory
graficznego inter-
fejsu użytkownika
(GUI)
Zwykłe zastoso-
wanie zestawu
widgetów (?)
Rozwinięcie zes-
tawu widgetów,
proste I/O multi-
medialne (głos)
Średnio złożone
2D/3D, dynamicz-
na grafika, multi-
media
Skomplikowane
multimedia,
wirtualna
rzeczywistość
COCOMO 2, grudzień 2004
38
4.6.1.7.TIME – Ograniczenie Czasu Działania, STOR – Limit Dostępnej Pamięci
W świetle zadziwiającego wręcz postępu technicznego w dziedzinie szybkości procesorów
i wielkości pamięci (operacyjnej, dyskowej) można by się zastanawiać, czy ograniczenia czasu
wykonywania programu lub ilości dostępnej pamięci mają nadal znaczenie. Okazuje się jednak, że
coraz to nowe aplikacje w pełni wykorzystują zasoby szybkości i pamięci sprzętu komputerowego,
a ograniczenia TIME/STOR są wiążące. Zgodnie z kryterium ciągłości i w świetle wyników analiz
danych liczbowych, skale i wartości tych czynników pozostały bez zmian w Cocomo2.
4.6.1.8.PVOL – Zmienność Platformy
W Cocomo wartość ta nosiła nazwę Zmienności Maszyny Wirtualnej (VIRT – Virtual
Machine Volatility), natomiast w Ada Cocomo była rozdzielona na Zmienność Hosta i Zmienność
Maszyny Docelowej – odzwierciedlając dominujący wówczas trend „tworzenie oprogramowania
host-maszyna docelowa w Ada” (Ada host-target software development approach). Obecnie
podąża się raczej w kierunku rozproszonego tworzenia oprogramowania, a podział między hostem a
maszyną docelową jest bardziej rozmyty. W takiej sytuacji Cocomo2 powraca do pojedynczego
czynnika Zmienności Platformy, zgodnie z kryterium oszczędności. Skala i wartości współczynnika
także zostały zachowane z opisu czynnika VIRT w Cocomo. „Platformę” definiuje się tu
identycznie do dawnej „Maszyny wirtualnej”: połączenie sprzęt-oprogramowanie (OS, DBMS)
wykorzystywane przez dany program do wykonania swoich zadań.
4.6.1.9.TURN – Czas Kompilacji (Computer Turnaround Time)
Czynnik ten miał zdecydowanie większe znaczenie w okresie wprowadzania pierwotnej
metody Cocomo (lata 70-te), kiedy to programiści pracowali zwykle na sprzęcie wykonującym
zadania wsadowe. Obecnie większość oprogramowania tworzy się w środowiskach interaktywnych
i tendencja ta tylko się umacnia. W rezultacie czynnik TURN utracił niemal całkowicie swoje
znaczenie i został usunięty z Cocomo2.
4.6.2. Czynniki Kadrowe
4.6.2.1.ACAP – Umiejętności Analityków, PCAP – Umiejętności Programistów
Zarówno w Cocomo jak i Ada COCOCMO łączny zakres wartości (iloraz wartości
największej do najmniejszej) tych dwóch współczynników wynosił nieco ponad 4, odzwierciedlając
COCOMO 2, grudzień 2004
39
w ten sposób duży wpływ, jaki umiejętności personelu mają na wydajność tworzenia
oprogramowania. Pierwotnie, w Cocomo, założono mniej-więcej równe wartości obu czynników:
ACAP=2.06 i PCAP=2.03. Z kolei w Ada Cocomo założono sytuację, w której zwarty sztab
wysoce wykwalifikowanych analityków kreował dokładne specyfikacje oprogramowania – do
wcielenia w życie przez może mniej zdolnych programistów. Zakresy wartości zmieniły się zatem
na ACAP=2.57 i PCAP=1.62.
Dzisiaj także podkreśla się wagę umiejętności analityków, ale wzrasta też znaczenie
kwalifikacji samych programistów. Spowodowane jest to w dużej mierze zwiększonym
wykorzystaniem złożonych pakietów COTS, z którymi tylko dobrze wyszkoleni programiści będą
w stanie sprawnie sobie radzić.
Dla powyższych przyczyn współczynniki ACAP i PCAP łącznie zachowują podobny
zakres wartości (4), natomiast rozważane oddzielnie znajdują się w punkcie pośrednim między
Cocomo i Ada Cocomo. W rezultacie zakresy współczynników w Cocomo2 wynoszą: 2.24 dla
ACAP i 1.85 dla PCAP.
4.6.2.2.AEXP – Doświadczenie z aplikacjami, PEXP – Doświadczenie z platformami,
LTEX – Doświadczenie z językiem programowania i narzędziami
W metodzie Cocomo2 dokonano trzech zasadniczych zmian w powyższych czynnikach
wzrostu kosztów:
• przeniesiono je na jedną wspólną skalę dla uniknięcia wcześniejszych
nieporozumień;
• powiększono zakres wartości PEXP, ponieważ dogłębne zrozumienie możliwości
wykorzystania najnowszego sprzętu nabrało ostatnio na znaczeniu (np.: sprzętowe
wspomaganie dla graficznego interfejsu użytkownika, baz danych, sieci
komputerowych, wykorzystanie możliwości middleware);
• rozszerzono doświadczenie w języku programowania o umiejętności używania
narzędzi i metod projektowych.
Powyższe współczynniki w Cocomo2, w porównaniu do Cocomo i Ada Cocomo, mają
następujące zakresy wartości:
• AEXP : 1.54 w Cocomo2; 1.57 w Cocomo i Ada Cocomo;
• PEXP : 1.58 w Cocomo2; 1.34 w Cocomo i Ada Cocomo (VEXP);
COCOMO 2, grudzień 2004
40
• LTEX : 1.51 w Cocomo2; 1.20 w Cocomo i Ada Cocomo (LEXP);
4.6.2.3.PCON – Stabilność personelu
Przy kolekcji i analizie danych liczbowych pierwotnej metody Cocomo rozważano
zastosowanie współczynnika PCON. Wyniki analizy nie były jednak jednoznaczne i ostatecznie
nie umieszczono tej wartości wśród czynników zwiększających nakład pracy [Boehm 1981, str.
486-487]. W Cocomo2 skalę szacowania wartości PCON opisuje procentowa wartość wymiany
personelu w ciągu roku: od 3 do 48 procent. Zakres wartości wynosi 1.52.
4.6.3. Czynniki Procesu Produkcji
4.6.3.1.MODP – Wykorzystanie nowoczesnych metod tworzenia oprogramowania
Pojęcie „nowoczesne metody tworzenia oprogramowania” ewoluuje w stronę jeszcze
szerszego określenia: „dojrzałe metody inżynierii oprogramowania” użytego w CMM (Capability
maturity Model – wspomniany wyżej) Instytutu Inżynierii Oprogramowania (SEI) [Paulk et al.
1993] i innych podobnych modelach (ISO 9000-3, SPICE). Wpływ zastosowania takich metod
w tworzeniu oprogramowania opisany jest w Cocomo2 jako składnik Dojrzałości Procesu Produkcji
wśród wykładniczych współczynników skali. Współczynnik źródeł kosztów MODP nie jest zatem
potrzebny w Cocomo2.
4.6.3.2.TOOL – Stosowanie narzędzi software’owych
Od czasu kalibracji pierwotnej metody Cocomo, czyli lat 70-tych, narzędzia informatyczne
były znacząco usprawniane. W Ada Cocomo dodano więc dwa nowe poziomy ocen wychodzące
naprzeciw oczekiwanemu rozwojowi możliwości tych narzędzi w późnych latach 80-tych i
początku 90-tych. Od tego czasu programy otrzymujące noty „B. Niska” i „Niska” na skali TOOL
zaczęły być rzadkością. Wobec tego w Cocomo2 przesunięto całą skalę TOOL eliminując
najniższe (B. Niska i Niska) wartości i zmieniając nieco pozostałe pięć poziomów ocen z Ada
Cocomo. Usunięcie dwóch ocen ze skali zmniejszyło zakres wartości współczynnika TOOL z 2.00
do 1.61.
COCOMO 2, grudzień 2004
41
4.6.3.3.SITE – Rozproszenie tworzenia oprogramowania
Dwie przesłanki – upowszechnienie rozproszonego tworzenia oprogramowania oraz głosy
producentów oprogramowania stwierdzające, że taki tryb pracy ma znaczący wpływ na nakład
pracy – spowodowały dodanie czynnika SITE do metody Cocomo2. Jego szacowana wartości jest
średnią dwu czynników: fizycznej bliskości (od pracy w jednym miejscu po rozmieszczenie w
różnych krajach) i możliwości infrastruktury telekomunikacyjnej (od zwykłej poczty i połączeń
telefonicznych po interaktywny kontakt multimedialny). Zakres wartości wynosi 1.57.
4.6.3.4.SCED – Wymaganie dotyczące harmonogramu prac
Analiza danych liczbowych nie wykazała, aby zmiana dotychczasowych wartości
współczynnika SCED była potrzebna. Wobec tego pozostają one bez zmian w Cocomo2, zgodnie z
kryterium ciągłości.
4.6.3.5.SECU – Oprogramowanie utajnione
W Ada Cocomo współczynnik SECU zwiększał szacunkowy nakład prac o 1.10 w
przypadku produktów poufnych/utajnionych. Znakomita większość oprogramowania nie jest
klasyfikowana na żadnym poziomie tajności, w związku z czym zgodnie z postulatem
oszczędności, współczynnik SECU usunięto z metody Cocomo2
4.7.Dodatkowe możliwości metody Cocomo2
W tej części uszczegółowione będą zagadnienia związane z zastosowaniem wspomnianych
wcześniej narzędzi w Cocomo2: modele szacunkowe Projektu Wstępnego i Późnych Faz
Projektowych używające Punktów Funkcyjnych, estymacja harmonogramu prac, przedziały
dokładności szacunków. W następnych artykułach opisane będą dalsze możliwości metody
Cocomo2, w tym ocena wpływu wykorzystania gotowego kodu i zastosowania komponowania
aplikacji na koszt i harmonogram prac.
4.7.1. Szacunki Punktów Funkcyjnych w modelach Projektu Wstępnego i Późnych Faz
Projektowych
Po wyznaczeniu liczby Punktów Funkcyjnych programu, zgodnie z opisem
przedstawionym wcześniej, należy uwzględnić poziom języka programowania (asembler, języki
COCOMO 2, grudzień 2004
42
wysokiego poziomu, języki czwartej generacji), w którym program ma być napisany. Na tej
podstawie określi się proporcję punktów funkcyjnych do faktycznych Źródłowych LOC.
Przeliczanie punktów funkcyjnych na SLOC kodu odbywa się w Cocomo2 przy pomocy
odpowiednich tabel (m.in. tabel stworzonych przez Badania Wydajności Informatycznej (Software
Productivity Research - SPR) [SPR 1993]); zarówno dla modelu Projektu Wstępnego jak i Późnych
Faz Projektu.
Dalsze obliczenia w modelu Późnych Faz Projektu przebiegają identycznie do obliczeń
bazowanych na SLOC. Co więcej, metoda Cocomo2 umożliwia zastosowanie punktów
funkcyjnych do niektórych modułów program i SLOC do pozostałych (np. w sytuacji, gdy punkty
funkcyjne nie są miarą adekwatną, jak przy systemach czasu rzeczywistego czy obliczeniach
naukowych).
W przypadku modelu Projektu Wstępnego szacowanie przy pomocy punktów
funkcyjnych, przeliczanie ich na SLOC i skalowanie opisane w rozdziale 5 odbywają się tak samo
jak w modelu Późnych Faz Projektowych. Jedyną różnicą jest użycie mniejszej ilości czynników
przyrostu nakładu pracy. Współczynniki te otrzymuje się poprzez łączenie ich odpowiedników z
modelu Późnych Faz Projektu; zgodnie z opisem w tabeli 10.
Po połączeniu tym otrzymujemy siedem głównych czynników kosztów. Ich wartości
można oszacować już we wczesnych stadiach prac nad programem, znacznie łatwiej niż wartości
odpowiadających im 17 współczynników z modelu Późnych Faz Projektowych. Z racji pokaźnych
zakresów wartości tych czynników (do 5.45 w przypadku PERS i 5.21 przy RCPX) zwiększył się
zakres możliwych wartości końcowych. W takiej sytuacji większy jest także możliwy błąd
oszacowania i w związku z tym wynikowi w modelu Projektu Wstępnego przypisuje się
odpowiednio większą wartość odchylenia standardowego (niż w Późnych Faz Projektowych).
Tabela 10. Czynniki wzrostu kosztów w modelach Projektu Wstępnego i Późnych Faz Projektowych
Czynniki w modelu
Projektu Wstępnego
Odpowiedniki w modelu
Późnych Faz Projektowych
RCPX
RELY, DATA, CPLX, DOCU
RUSE RUSE
PDIF TIME,
STOR,
PVOL
PERS ACAP,
PCAP,
PCON
PREX
AEXP, PEXP, LTEX
FCIL TOOL,
SITE
SCED SCED
COCOMO 2, grudzień 2004
43
4.7.2. Szacunki harmonogramu prac
Pierwsza wersja metody Cocomo2 zawiera prosty model szacunkowy dla harmonogramu
prac projektowych i produkcyjnych, podobny do analogicznych modeli w Cocomo i Ada Cocomo.
Równanie stosowane we wszystkich trzech podmodelach Cocomo2 jest następujące:
100
%
]
)
(
0
.
3
[
)
01
.
1
(
2
.
0
33
.
0
(
SCED
PM
TDEV
b
×
×
=
−
×
+
( 6 )
gdzie TDEV oznacza czas w miesiącach między dostarczeniem pierwotnych wymagań do momentu
zatwierdzenia produktu, jako spełniającego wymagania programowe. PM jest ilością roboczo-
miesięcy wymaganą do zakończenia prac wyznaczoną z uwzględnieniem wszystkich wskaźników z
wyjątkiem SCED. Występujące w równanie %SCED jest natomiast procentową wartością
współczynnika skomasowania/rozluźnienia harmonogramu prac opisanego w Tab. 7.
4.7.3. Przedziały wyników obliczeń
Niektórzy użytkownicy metody Cocomo wyrazili opinię, iż bardziej celowe byłoby
otrzymanie wyników w postaci przedziałów, a nie pojedynczych wartości. W metodzie Cocomo2
jest to możliwe przy pomocy opisu dokładności szacunków (Rysunek 2). Po wyznaczeniu
najbardziej prawdopodobnej wartości nakładu pracy E (w każdym z trzech modeli: Komponowania
Aplikacji, Projektu Wstępnego i Późnych Faz Projektowych) można znaleźć wartości dla
optymistycznej i pesymistycznej wersji szacunku – odległą o około jedno odchylenie standardowe
od E. Oblicza się je w następujący sposób:
Model
Wersja Optymistyczna
Wersja Pesymistyczna
Komponowanie Aplikacji
0.50 E
2.0 E
Projekt Wstępny
0.67 E
1.5 E
Późne Fazy Projektowe
0.80 E
1.25 E
Tak obliczone wartości można też użyć do wyznaczenia przedziału czasu potrzebnego na
stworzenie programu (we wzorze 6.)
COCOMO 2, grudzień 2004
44
5. Podsumowanie
Z przedstawionego powyżej materiału widać wyraźnie, że jakkolwiek szacowanie kosztu
produkcji oprogramowania – szczególnie w początkowych fazach jego cyklu życia – jest możliwe,
ale równocześnie jest bardzo trudne. Błąd szacunku może wynieść nawet 400%, co w przypadku
budżetów projektów rządowych może oznaczać ogromne kwoty. Dlatego też wydaje się, że każdy
menedżer projektu musi przewidzieć odpowiednie służby, które będą odpowiedzialne wyłącznie za
zarządzanie kosztem przedsięwzięć i za szacowanie pracochłonności procesu wytwórczego
oprogramowania. Należy tutaj również rozważyć możliwość odpowiedniego oprzyrządowania
koniecznego dla komputerowego wspomagania zespołu szacującego koszty przedsięwzięć
informatycznych. Należy również pamiętać o tym, że Cocomo2 podaje koszt produkcji
oprogramowania w osobogodzinach. Na tej podstawie będzie możliwe przeliczanie szacunku
Cocomo2 na wartości pieniężne, o ile znamy stawkę godzinową w firmie, dla której wykonywane
są szacunki kosztu wytwarzania oprogramowania.
COCOMO 2, grudzień 2004
45
6. Wyjaśnienie skrótów użytych w tekście
3GL Język Programowania 3ciej Generacji
AA %nakładu prac przy ponownym użyciu kodu pochłonięta na przejrzenie i ocenę kodu
ACAP Umiejętności Analityków
ACT Roczny
Przepływ Zmian
ASLOC Dostosowane
Źródłowe Linie Kodu
AEXP Doświadczenie z Aplikacjami
AT Zautomatyzowane
Tłumaczenie
BRAK Występowanie Usterek
CASE Inżynieria Programowania Wspomagana Komputerowo
CM
% Kodu zmodyfikowanego dla potrzeb ponownego jego użycia
CMM Model
Dojrzałości Produkcyjnej
Cocomo Model
Kosztów
Konstrukcji
Oprogramowania
COTS
pakiety informatyczne zakupione jako całość – do użycia we własnym programie
CPLX Złożoność Produktu
CSTB
Naczelna Rada Informatyki i Telekomunikacji
DATA
Rozmiar Bazy Danych
DBMS System
Zarządzania Bazami Danych
DI Poziom
Wpływu
DM
% projektu zmodyfikowanego dla potrzeb ponownego jego użycia
DOCU przydatność wymaganej dokumentacji do potrzeb produkcji
EDS
Elektroniczne Systemy Danych
ESLOC Równoważne Źródłowe Linie Kodu
FCIL Zaplecze
FP Punkty
Funkcyjne
GFS
Oprogramowanie na Zamówienie (Rządowe)
GUI
Graficzny Interfejs Użytkownika
ICASE
Komputerowo Wspomagane Zintegrowane Środowiska Programowania
IM
%prac integracyjnych powtórzonych przy ponownym użyciu kodu
KSLOC Tysiąc Źródłowych Linii Kodu
LEXP Doświadczenie z Językiem Programowania
LTEX Doświadczenie z Językiem i Narzędziami Programowania
MODP Współczesne Metody Tworzenia Oprogramowania
COCOMO 2, grudzień 2004
46
NIST
Krajowy Instytut Norm i Technologii
NOP
Nowe Punkty Obiektowe
OS Systemy
Operacyjne
PCAP Umiejętności Programistów
PCON Ciągłość Personelu
PDIF Złożoność Sprzętu
PERS Umiejętności Załogi
PEXP Doświadczenie z Platformą
PL Linia
Produkcyjna
PM Roboczo-miesiąc
PREX Doświadczenie Załogi
PROD Współczynnik Wydajności Produkcji
PVOL Zmienność Platformy
RCPX Niezawodność i Złożoność Produktu
RELY Wymagana
Niezawodność Oprogramowania
RUSE
Wymaganie tworzenia kodu do ponownego wykorzystania
RVOL Zmienność wymagań
SCED Wymagany
harmonogram
prac
SECU Tajne
Aplikacje
SEI Instytut
Inżynierii Oprogramowania
SITE równoległa praca w wielu różnych miejscach
SLOC
Źródłowe Linie Kodu
STOR Ograniczenie
Dostępnej Pamięci
T&E
Testy i Ocena Działania
SU %nakładu prac przy ponownym użyciu kodu pochłonięta na przyswajanie kodu
TIME Ograniczenie
Czasu
Działania
TOOL Wykorzystanie
Narzędzi Informatycznych
TURN Czas
Kompilacji
USAF/ESD Oddział Systemów Elektronicznych Sił Powietrznych Stanów Zjednoczonych
VEXP Doświadczenie z „Maszyną Wirtualną”
VIRT Zmienność Maszyny Wirtualnej
VMVH Zmienność Maszyny Wirtualnej: Hosta
VMVT Zmienność Maszyny Wirtualnej: Wyniku