Microsoft Word - IO - szacowanie wielkoœci przedsiêwziêcia

COCOMO 2, grudzień 2004

Spis treści

Wprowadzenie...........................................................................................................................................................5

Uwarunkowania oceny kosztu procesu wytwórczego oprogramowania ...................................................................6

Podział kosztu procesu wytwórczego na poszczególne etapy cyklu życia oprogramowania ....................................9

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

Podsumowanie ........................................................................................................................................................44

Wyjaśnienie skrótów użytych w tekście..................................................................................................................45

COCOMO 2, grudzień 2004

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

. 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

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

Metoda FPA jest opisywana na stronie: www.ifpug.org

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

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

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.

Zagadnienia doboru cyklu modelu cyklu wytwórczego oprogramowania pozostają poza zakresem opracowania.

COCOMO 2, grudzień 2004

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

, 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),

Małe i średnie przedsiębiorstwa

COCOMO 2, grudzień 2004

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

PROCES

Udzia

ł %

roc

DEFINICJA

ANALIZA

OJE

TOWANIE

BUDOWA

DRA

ANIE

SPLOA

ACJ

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 %

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

Koszt poszczególnych faz cyklu życia oprogramowania

6,6

11,1

29,1

46,2

fin

aż

nazwa fazy

udz

ł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

fin

icj

a W

aga

Anali

za I

nie

ją

ch S

tem

ów

chi

tek

tur

a T

icz

t i

udow

a B

Dany

t i

a M

uł

ów

Konw

sja

Dany

cja

sto

leni

oż

yst

a p

o W

dro

że

ąd

Nazwa procesu

udz

ł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

Udział procesów cyklu w ytw órczego w fazach cyklu życia

oprogramow ania

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

fin

icja

iza

oje

kto

wani

bud

wdr

aż

eks

oat

fazy cyklu życia

ła

dow

e pr

u w

ytw

ór

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

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

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

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

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

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)

domyślne w tym
modelu

Błędne
zatrzymania

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

Skalowanie
(wartość b) w
MM

NOM

= a(R)

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*+,

W tabeli tej użyto wielu skrótów sklasyfikowanych w wykazie skrótów zamieszczonych w zakończeniu ekspertyzy.

COCOMO 2, grudzień 2004

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

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

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

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)

łatwy

średni

0 lub 1

ł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

Raport 2

Komponent w 3GL (4GL)

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

• %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

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

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

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

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

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

Ś 0

lub

1 N N Ś

2-5 N Ś W 2-3 N Ś W 2-3 N Ś W

Ś 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

EIF 5

EI 3

EO 4

EQ 3

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

Oto formuła, według której Cocomo obliczał ekwiwalent ilości nowego kodu w sensie

rozmiaru używanego ponownie oprogramowania istniejącego:

100

)

(

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

oprogramowania. Zmodyfikowana formuła obliczania zależności liczby linii nowego kodu i

rozmiaru ponownie użytego oprogramowania jest następująca:

100

)

(

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

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

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:

Wielkosc

Naklady

)

(

( 3 )

COCOMO 2, grudzień 2004

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

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

, są do siebie dodane i dają wartość współczynnika B wg. wzoru (4).

COCOMO 2, grudzień 2004

∑

( 4 )

Tabela 7. Oceny składników wykładnika skali projektu.

) 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

ś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:

∏

poprawione

)

(

min

( 5 )

Głównymi kryteriami doboru współczynników EM były w Cocomo2:

COCOMO 2, grudzień 2004

• 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

bytes/Pgm

SLOC < 10

≤ D/B <100 100 ≤ D/B <

1000

D/P

≥ 1000

CPLX

patrz Tabela 8.

RUSE

Brak

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

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

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

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

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

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

• 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

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

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

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

]

)

(

[

)

(

SCED

TDEV

−

( 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

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

% 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

% 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

%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

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