Narzędzia oparte na modelu cocomo ii Model COCOMO I I

W ostatnich latach powstało wiele narzędzi wspomagających zarządzanie działaniami zmierzającymi do konstrukcji projektu systemu informatycznego opartych na modelu COCOMO II. Model ten, w wersji II, stanowi modyfikację oryginalnego modelu COCOMO (ang. Constructive COst MOdel) stworzonego przez B. Boehm'a na początku lat 80 (por. 19]). Celem koncepcji oryginalnej była analiza i estymacja kosztów projektowania zgodna z zaproponowaną przez autora zależnością, odzwierciedlającą praktyki projektowe z końca lat 70. Ponieważ jednak od tamtej pory w technikach projektowania SI nastąpiło wiele zasadniczyc

zmian, model COCOMO przestał być rozwiązaniem aktualnym. W celu jego dostosowania do praktyk projektowych przełomu wieków w 1994 roku na University o f Southern California stworzono model COCOMO //. Orygina ny model nazwano zaś COCOMO 81.

COCOMO II stanowi zatem rozwiązanie teoretyczne ułatwiające kontrolę i planowanie projektu SI, pozwalające na estymację kosztów i stworzenie harmonogramu prac projektowych. Dla realizacji tych zadań opisywany mo e wykorzystuje następujące moduły:

r Applications Com position: ,

Moduł Applications Composition stworzono z myślą o projektach budowanyc w oparciu o nowoczesne narzędzia konstrukcji GUI. W celu wyprowa zenia szacunków nakładów pracy niezbędnych do budowy SI mo u en wykorzystuje tzw. punkty obiektowe, które stanowią miarę wielkości systemu

Por. U R L : http://www.cosmicon.com/, http://www.totalmetrics.com por. U R L : http://www.hmaster.com

97

zbliżoną do punktów funkcyjnych. Ponieważ Applications Composition zakłada wykorzystanie zintegrowanych narzędzi typu CASE w celu stworzenia prototypu SI, obiekty obejm ują ekrany, raporty oraz moduły w językach program owania trzeciej generacji. Oceny estymacyjne wyprowadzane są zatem z uwzględnieniem liczby obiektów oraz złożoności każdego z nich. Parametry te stanow ią podstawę wyznaczenia ważonej liczby punktów obiektowych decydującej o rozmiarze SI - analogicznie, jak w przypadku metody punktów funkcyjnych. Kolejno określa się szacunkową produktywność działań projektowych. Po wyznaczeniu wielkości systemu i przewidywanej produktywności możliwe staje się uzyskanie ocen estym acyjnych dla nakładów pracy.

> Early Design:

M oduł Early Design wykorzystuje się do wyprowadzenia wstępnych szacunków dla kosztów i czasu trwania działań projektowych jeszcze przed stworzeniem całej architektury systemu. W tym czasie niewiele wiadomo tak na temat rozmiaru projektu, jak i w odniesieniu do jego obsługi personalnej.

Oceny estymacyjne wyznaczane są zatem na podstawie nieostatecznej liczby PF (tzw. rozmiaru funkcjonalnego), stanowiącej wejście do opisywanego modułu, za pom ocą której ju ż we wstępnych fazach projektowania można oszacować wielkość systemu. W ielkość ta jest następnie przekształcana na odpow iadającą jej w danym języku program owania liczbę linii kodu źródłowego. Uzyskany w ten sposób rozm iar aplikacji stanowi wyjście modelu Early Design.

> Post-architecture:

M oduł Post-architecture stanowi najbardziej szczegółow ą część modelu COCOMO II. Dlatego jest on wykorzystywany ju ż po zaprojektowaniu całej architektury systemu. Najczęściej właśnie on stanowi podstawę działania narzędzi wspomagających zarządzanie projektem w oparciu o koncepcję COCOMO II. W ejściem do tego modułu jest wielkość aplikacji w liczbie linii kodu źródłowego. Jednak uwzględnia on również inne czynniki, tzw. c z y n n ik i

kosztów, wpływające na oceny estymacyjne dla nakładów pracy i czasu niezbędnego do stworzenia projektu SI.

Czynniki kosztów w modelu COCOM O I I

O wielkościach szacunkowych dla produktywności, kosztów oraz czasu trwania działań projektowych decydują, oprócz rozmiaru ^{S I,} atrybuty ^podzielone na następujące kategorie:

> C zynniki produktu:

Dla aplikacji o identycznych rozmiarach m ogą wystąpić poważne różnice w ich wartościach wynikające z czynników nie uwzględnionych w wielkości systemu. N ależą do nich:

C Precedensowość - stanowi “miarą doświadczenia” danej organizacji

projektującej w tworzeniu podobnych SI;

■A Elastyczność - będąca swego rodzaju “miarą możliwości w pływ u” danej organizacji projektującej na wymagania wobec SI;

S W ymagana niezawodność systemu;

S Ponowne wykorzystanie oprogramowania - daje oszczędności w rozmiarze aplikacji;

'S W ymagana dokumentacja projektowa — stanowi niezbędną część dostarczanego produktu.

^ Czynniki syrzetowe:

Są one związane z trudnościami, które mogą się pojawić w wyniku wykorzystywania platformy sprzętowej o ograniczonych zasobach, co powoduje zwykle wzrost kosztów. Do czynników tych należy:

S Ograniczenie czasu realizacji - w modelu COCOMO 81 czynnik ten może zwiększyć nakłady pracy na projektowanie nawet o kilkadziesiąt procent (do 66%);

'C Ograniczenie pamięci operacyjnej - w modelu COCOMO 81 czynnik ten może zwiększyć nakłady pracy również o kilkadziesiąt procent (do 56%);

'C Stabilność sprzętu i oprogramowania wykorzystywanego przez daną aplikację (kompilatory, systemy zarządzania bazą danych, itp) - atrybut ten może zmniejszyć nakłady pracy nawet o 13%, częsta zmienność środowiska może zaś wywołać nawet 30% wzrost nakładów pracy.

* Czynniki personalne:

Ta grupa czynników związana jest z jakością pracy zespołów ludzkich mającą zasadniczy wpływ na koszty projektowania. Atrybuty te to:

^ S pójność zespołu w pracy zespołow ej;

'C Ciągłość zatrudnienia (normę stanowi 12% zmiana w roku);

^ D ośw iadczenie w analizie i program ow aniu - stanowi m iarę uczestnictw a w projektach inform atycznych w ogóle;

^ D ośw iadczenie aplikacyjne - stanow i m iarę znajom ości dziedziny problem u, dla której tw orzony je st system;

^ D ośw iadczenie w pracy z daną platform ą sprzętową, językam i program ow ania i narzędziam i.

^ Czynniki projektowe:

17% czasu projektowania przeznacza się na stworzenie architektury;

^ Istnienie planów zarządzania ryzykiem;

^ D ojrzałość procesu - teoretycznie rzecz ujm ując, im bardziej dojrzała organizacja, tym proces projektow ania je st efektywniejszy;

^ U łatw ienia przyjęte w procesie projektow ania - z podziałem na w ykorzystanie narzędzi program ow ych oraz projektow anie rozproszone w sensie geograficznym ;

^ W ym agany harm onogram prac - odzw ierciedla działanie tzw. praw a Brooksa (por. [2]).

99

P rzykład y narzędzi

C O STAR:

System ten stanowi narzędzie kontroli i estymacji kosztów projektowania stworzone przez firmę Softstar Systems. Obecnie występuje w wersji 6.0, zgodnej z modelem COCOMO 11.2000, najnowszej opcji modelu B. Boehm 'a7. Jest on przeznaczony do pracy w środowisku MS-W indows (począwszy od wersji Windows'95, poprzez Windows NT, a więc również w środowisku sieciowym) i współpracuje z podstawowymi programami tego środowiska. Podstaw ą jego działania są zarówno różne wersje modelu COCOMO, ja k i m etoda punktów funkcyjnych. Obejmuje on również narzędzia pozwalające na m odyfikację modeli estymacyjnych w celu ich dostosowania do własnego środowiska projektowania.

Costar 6.0, jako narzędzie analizy i szacowania projektów, oferuje m. in.:

> automatyczne obliczanie podstawowych parametrów w celach orientacyjnych;

> wyprowadzanie ocen estymacyjnych dla wszystkich stadiów projektowania;

> analizę w ariantową pozwalającą na ustalenie różnych scenariuszy rozwiązań oraz porównywanie różnych planów dla projektu;

> możliwość zdefiniowania przez użytkownika czynników kosztów (32 własne plus dodatkowo możliwość zdefiniowania czynników przez użytkownika);

> możliwość obliczania rozmiaru systemu w punktach funkcyjnych;

> ogólnodostępny (niezastrzeżony prawnie) model postępow ania (COCOMO), a w jego ramach możliwość wyboru różnych wariantów (Intermediate COCOMO, D etailed COCOMO, Standard COCOMO, Ada COCOMO, Incremental COCOMO, COCOMO //);

> możliwość dostosowania modelu COCOMO do specyficznego środowiska projektowania za pom ocą programów DBedit i Calico;

> szeroką gamę raportów i wykresów dotyczących harmonogramu prac, obsady personalnej, kosztów, zadań i czynności projektowych, podsumowań, itp;

> możliwość wyboru stopnia szczegółowości opisu struktury projektu (system, podsystemy, moduły, itp).

Najistotniejszymi elementami systemu COSTAR są oceny estymacyjne, którym przyporządkowanych jest szereg atrybutów. Do atrybutów tych zalicza się między innymi: nazwę oceny, jej identyfikator, krótki opis, pow iązaną z nią bazę danych, tryb obliczeń stosowany w odniesieniu do niej (np. pośredni, szczegółowy) oraz listę komponentów wchodzących w jej skład (jeden lub więcej). W danej chwili jed n a z ocen, wybrana z menu przez użytkownika, stanowi tzw. ocenę bieżącą. Jest ona wówczas przedmiotem działania wszystkich komend opisywanego narzędzia. W spółpraca z systemem Costar polega głównie n3 tworzeniu i modyfikowaniu komponentów ocen estymacyjnych. Czynności te obejm ują przede wszystkim definiowanie podkomponentów, przypisywanie im wartości czynników kosztów oraz szacowanie rozmiaru każdego składniki

7 Por. URL: http://www.softstarsystems.com

Komponent może składać się z mniejszych części. W momencie tworzenia nowego składnika staje się on podkomponentem komponentu bieżącego, dziedzicząc z niego wartości dla wszystkich swoich atrybutów (np. wartości czynników kosztów, koszt w przeliczeniu na osobomiesiąc, itp). Jeżeli ocena estymacyjna składa się tylko z jednego komponentu, jej ostateczna wartość jest oczywiście identyczna z wartością komponentu. Jeśli zaś posiada ona podkomponenty, to jej ostateczna wartość jest w odpowiedni sposób wyprowadzana z wartości składników. Costar pozwala na wyznaczenie ostatecznej wartości danej oceny estymacyjnej w jeden z trzech następujących sposobów:

J poprzez wykorzystanie Adaptation Worksheet, S poprzez wykorzystanie Function Point Worksheet, S poprzez wprowadzenie określonej wartości.

Obecnie pakiet Costar jest wykorzystywany na całym swiecie przez niemal 2 miliony licencjonowanych użytkowników.

ESTIM ATE Professional:

Jest to system wspomagający planowanie projektów, poprzez szacowanie czasu i kosztów projektowania SI, stworzony przez firmę Software Productivity C e n t r e Podstaw ą jego działania są trzy teoretyczne podejścia, w tym dwa modele estymacyjne oraz metoda statystyczna Monte Carlo:

> Metoda P u tn a m 'a , znana jako SLIM (ang. Software Life cycle Management) i rozwijana od początku lat 70. Opiera się ona na poglądzie, że efektywnie prowadzone projekty SI naśladują dobrze zdefiniowane wzorce, które mogą być modelowane za pom ocą pewnego zestawu wykładniczych zależności.

Równania te stanow ią podstawę określenia kosztów, harmonogramu prac oraz wielkości zatrudnienia dla opisywanego narzędzia. Równanie uzależniające od siebie rozmiar produktu, nakłady pracy, czas projektowania oraz produktywność, znane jako Software Equation, stanowi podstawową część metody Putnam'a (por. [11]). Model SLIM wymaga zdecydowanie mniej parametrów niezbędnych do wygenerowania ocen estymacyjnych w porównaniu z modelem COCOM O II.

> Model COCOMO I I . stanowiący dla ESTIMATE Professional uzupełnienie metody Putnam'a. W ykorzystuje się go, gdy oceny estymacyjne wyznaczane są przy zastosowaniu czynników kosztów. Podstawę dla okres enia produktywności stanow ią parametry typu projektu. Czynnik produktywności jest następnie korygowany poprzez produktywność obliczoną zgo me z

danymi i algorytmami modelu COCOMO II. .

> Symulacja M onte Carlo, wykorzystywana w opisywanym narzędziu do modelowania złożonych współzależności wobec niepewności ocen estymacyjnych. ESTIM ATE Professional symuluje setki możliwych wyników dla szacowanego projektu bazując na jego rozmiarze, produktywności, lezącej fazie projektowania oraz innych parametrach. Kolejno szacuje się prawdopodobieństwo osiągnięcia określonych rezultatów, a różnym opcjo 8 Por. URL: http://www.spc.ca

101

planowania przypisywane są poziomy ryzyka. W sytuacjach szczególnie złożonych, o dużej dozie niepewności, podejście to pozwala na wyprowadzenie prawdopodobnych ocen estymacyjnych, których osiągnięcie nie jest możliwe bez zastosowania tego typu symulacji.

Jako że teoretyczne modele estymacji są tym bardziej skuteczne, im lepiej są one dostosowane do specyficznego środowiska projektowania, ESTIMATE Professional udostępnia trzy metody ich adaptacji, uwzględniające odpowiednio:

'A Typ projektu:

Stanowi najłatw iejszą i najmniej dokładną metodę dostosow ania polegającą na wybraniu typu projektu, który podlega szacowaniu z listy typowych rodzajów projektów, wyróżnionych ze względu na dziedzinę zastosowania (np. systemy ekonomiczne, systemy lotnicze, itp). Narzędzie wyprowadza oceny estymacyjne poprzez wykorzystanie bazy danych zawierającej informacje o produktywności projektu danego typu. Ponieważ dane te pochodzą z doświadczenia przy tworzeniu projektów dla całej dziedziny (np. lotnictwa), oceny estymacyjne utworzone na ich podstawie nie są szczególnie dokładne.

■/ Czynniki kosztów:

Bardziej szczegółową metodę dostosowania modelu do specyfiki projektów stanowi opis zarówno typu projektu, jak i pewnych dodatkowych jego parametrów. Te dodatkowe parametry obejm ują atrybuty projektu (np. czy zespół projektowy będzie pracował w jednym miejscu, czy konieczna będzie współpraca pomiędzy geograficznie rozproszonymi ośrodkami), atrybuty produktu (np. czy produkt jest dobrze znany, czy po raz pierwszy tworzony) oraz atrybuty personelu (np. czy zespół projektowy jest doświadczony). Przy wykorzystaniu tej metody opisywane narzędzie używa swojej bazy danych o produktywności dla określonych typów projektów w kom binacji z czynnikami dostosowawczymi uzyskanymi dzięki modelowi C O C O M O II.

'A Projekty historyczne:

N ajdokładniejszą metodę dostosow aw czą stanowi wykorzystanie danych pochodzących z podobnych projektów, które zrealizowano w przeszłości w danej organizacji projektującej. Przy tym podejściu unika się szacowania wielu parametrów wpływających na produktywność (np. złożoności produktu, jakości personelu, efektywności organizacyjnej, itp). W przeciwnym razie każdy z tych czynników musi być estymowany, wprowadzając w każdym kroku dodatkowe niedokładności. W ykorzystanie danych pochodzących z projektów zrealizowanych stanowi zatem metodę dostarczającą dokładnych ocen estymacyjnych przy niewielkim nakładzie pracy, pod warunkiem, oczywiście, że dane historyczne są dostępne.

O przydatności ESTIM ATE Professional świadczy chociażby fakt, iż pakiet ten zdobył w 1998 roku głów ną nagrodę dziewiątej edycji konkursu magazynu Software Developm ent w kategorii Productivity Award.

6. P ro b lem y w stosow aniu narzędzi

Kończąc prezentację przykładowych narzędzi wspomagających analizę i estymację projektów informatycznych należy zwrócić uwagę na związane z ich wykorzystaniem problemy:

^ Konieczność gromadzenia danych historycznych:

Pakiety wspomagające działają zawsze w oparciu o pewien model teoretyczny.

Jednak, jak twierdzi jeden z autorytetów w tej dziedzinie - Tom DeMarco,

“...nie ma przenośnych modeli kosztów..." (por. [5]). Model taki bowiem w każdym przypadku musi być dostosowany do odmiennych warunków i środowisk projektowych, jako że działania projektowe zależą od dostępu do zasobów, wsparcia technologicznego, doświadczenia projektujących, otoczenia systemu, itd. Dlatego konieczne jest gromadzenie wszelkich danych na temat zrealizowanych i tworzonych systemów, tak aby można je było wykorzystać w narzędziach wspomagających wyznaczanie ocen estymacyjnych dla nowych projektów. Narzędzia te bowiem będą skuteczne, o ile oprócz modeli teoretycznych udostępni się im bazę z danymi historycznymi o przedsięwzięciach zrealizowanych w danej organizacji projektującej (por. rys.

4).

^ Integracja ocen estymacyjnych w ramach różnych składników produktów systemowych:

Systemy informatyczne stanowią zwykle konstrukcje hybrydowe, na które składają się różne komponenty: począwszy od sprzętu, poprzez oprogramowanie, bazy danych, a skończywszy na usługach manualnych dotyczących wspomagania i naprawy. Każdy z tych elementów powinien być wyceniony. M imo iż istnieją narzędzia wspomagające szacowanie kosztów każdego z tych składników SI oddzielnie, ciągle trudno jest wyprowadzić zagregowane oceny estymacyjne dla wszystkich komponentów razem. O proponowanych rozwiązaniach w tym zakresie pisze C. Jones w [8]^.

Capers Jones uważa, iż pierwszym stadium integracji metod estymacji kosztów dla różnych składników produktów systemowych powinno być uzgodnienie wspólnych interfejsów, które um ożliw ią agregację elementów kosztów. Powiązane miary (ich rodzina) mogą uwzględniać:

• Punkty funkcyjne dla komponentu jakim jest aplikacja;

• Punkty danych dla komponentu jakim jest baza danych;

• Punkty sprzętowe dla komponentów mechanicznych i elektronicznych;

• Punkty serw isow e dla działalności manualnej (wspomaganie i naprawy).

Wtedy produkty hybrydowe, dzięki takim kompatybilnym metodom, będą łatwiejsze do Pomiaru rozmiaru i estymacji kosztów. Autor proponuje, aby celem stało się stwierdzenie, te dany projekt może obejmować np. “ 1000 punktów funkcyjnych, 2000 punktów danych, 1500 punktów sprzętowych i będzie wymagał 3500 punktów serwisowych na rok .

Z u życie z asob ów na p un kt

Nowy projekt

Id en ty fi­

kacja projek tu

W artości Punkty

atryb u tów p rod u k ty­

w ności

W fu n kcyjn e

D A N Y C H

SZACUNEK