Uwagi końcowe

Ostateczna liczba punktów funkcyjnych stanowi miarę wielkości i funkcjonalności produktu pracy projektantów. Wyżej zaprezentowane sposoby jej kalkulacji wskazują, iż istotą opisywanego rozwiązania są funkcje użytkownika, których realizację ma wspomagać wprowadzany SI. Rozmiar funkcjonalny, wyrażony poprzez nieostateczną liczbę PF, jest bowiem otrzymywany z analizy i oceny typów funkcji, a więc obiektów mających kluczowe znaczenie z punktu widzenia funkcjonalności systemu informatycznego. Tak otrzymany rezultat jest poddawany wpływowi czynnika korygującego, którego wartość zależy od oceny parametrów wpływu wyprowadzonej przez użytkownika SI. W ten sposób otrzymuje się wielkość systemu w punktach funkcyjnych, dzięki której istnieje możliwość prawidłowego przeprowadzenia zarówno procesu pomiaru, jak i estymacji innych kluczowych charakterystyk systemu informatycznego: kosztów, czasu i produktywności działań projektowych. Rozwój miary opartej na punktach funkcyjnych oraz ustalenie obowiązujących jej standardów wskazują ponadto na możliwość dodatkowego jej wykorzystania do analizy, oceny i porównań wielu parametrów prac projektowych w różnych kontekstach. Metoda ta bowiem wraz ze swoją ew olucją zyskuje coraz większą obiektywność, dzięki czemu staje się ona miarą o coraz większej użyteczności i coraz lepiej dostosowaną (acz nie w pełni) do potrzeb uczestników procesu projektowania. Wszystkie wersje opublikowane przez IFPUG (por. tablica 1) objaśniają reguły, sposób postępowania i kryteria stosowane w omawianej analizie, choć nie wprowadzają żadnych zmian do samej struktury procesu pomiaru m etodą PF.

Nie ulega wątpliwości, iż wersji 4.1 Counting Practices Manuał jest nieco bliżej do doskonałości niż wersjom poprzednim. Ów dystans weryfikuje oczywiście praktyka. W skazuje ona, iż w tych instytucjach, w których wykorzystuje się metodę punktów funkcyjnych do analizy i estymacji systemów wspomagających zarządzanie zgodnie ze standardami ustalonymi przez IFPUG, a ich znajomość potwierdza się specjalnymi egzaminami, jej skuteczność jest wysoka. Odchylenie w otrzymywanych wynikach, jeszcze przy zastosowaniu wersji 4.0 CPM, mieści się bowiem w granicach 10% [JONE98]. Problem jednak w tym, że tych instytucji jest zdecydowanie za mało — do końca 1998 rokuje yme ok. 1% istniejących SI było ocenianych przy wykorzystaniu PF. Należy również pamiętać, iż punkty funkcyjne nie mogą być prawidłowo^ zastosowane do wszystkich klas SI (np. systemów czasu rzeczywistego, programów naukowych) ze

ad. 9.

81

względu na niewystarczające odzwierciedlenie wysokiej złożoności wewnętrznej systemu. Nie bez znaczenia dla prawidłowych pomiarów jest również pracochłonność owej metody, jak też praktyka w jej wykorzystaniu. Dlatego niektórzy postulują jej stosowanie tylko przy dużych projektach, związanych z poważnymi nakładami finansowymi. Owszem, w takich przypadkach warto się nawet zastanowić nad stworzeniem zespołu odpowiedzialnego za kontrolę i planowanie projektu. Ale czy warto narażać się na jakiekolw iek straty, nawet przy mniej poważnych nakładach ? Zawsze można przecież wypróbować mniej kosztowne rozwiązanie polegające na zakupie jednego z pakietów programowych wspomagających pomiar i szacowanie projektu w oparciu o punkty funkcyjne.

Niektóre z nich są certyfikowane i polecane przez IFPUG.

Do dziś stosowanie miar SI ciągle zawiera spore ryzyko niepowodzenia.

Dlatego konieczne jest stymulowanie dalszych teoretycznych badań w celu udoskonalenia procesu pomiaru i estymacji SI. Jeżeli idzie o rozm iar funkcjonalny takie badania są obecnie intensywnie prowadzone nie tylko przez IFPUG, ale również przez organizację COSMIC (ang. Common Software M easurement International Consortium), stanow iącą m iędzynarodową grupę ekspertów mających na celu rozwinięcie i wprowadzenie na rynek następnej generacji metody pomiaru SI, mianowicie metody tzw. pełnych punktów funkcyjnych (ang. Fuli Function Points M ethod). Jej zadaniem miałby być pom iar wszystkich rodzajów systemów informatycznych (nie tylko tych wspomagających zarządzanie) zgodny z wymaganiami stawianymi w tym względzie przez ISO. Udostępnienie owego rozwiązania zapowiada się na ten lub przyszły rok, o ile oczywiście jego obecne testowanie przyniesie pozytywne rezultaty 10.

Literatura

1. [ABRA96] Abran A., Robillard P.N., Function Points Analysis: A n Empirical Study o f its M easurement Processes', IEEE Transactions on Software Engineering, Vol. 22, no. 12, pp. 895-909, Dec. 1996.

2. [ALBR79] Albrecht A.J., M easuring Application D evelopm ent Productivity, Proceedings IBM Application Development Symposium, M onterey, CA., Oct

14-17, 1979.

3. [DESH96] Deshamais J.M, M orris P., Post M easurem ent Validation Procedure fo r Function Point Counts, Forum on Software Engineerong Standard Issues SES’96, M ontreal, October 1996.

4. [FUNC01] Lista adresowa: function.point.list@ crim .ca

10 Pierwsza wersja m etody opartej na pełnych punktach funkcyjnych została opublikowana w 1997 roku, ale ta, której rozwojem zajmuje się obecnie CO SM IC ma się od niej znacznie różnić.

5. [IFPU94] IFPUG Function Point Counting Practices: M anual Release 4.0, IFPUG W esterville, OH, 1994.

6. [IFPU99] IFPUG Function Point Counting Practices: Manual Release 4.1, IFPUG W esterville, OH, January 1999.

7. [JONE98] Jones Capers, Sizing Up Software, Scientific American, December 1998.

8. [ST-P97] St-Pierre D., Maya M., Abran A., Deshamais J.M., Adapting Function Point to Real-Time Software, IFPUG Fall Conference, 1997.

Beata Czamacka-Chrobot Szkoła Główna Handlowa

Katedra Informatyki Gospodarczej Al. Niepodległości 162

02-554 W arszawa

e-mail: bczarn@sgh.waw.pl

83

N A R Z Ę D Z IA W S P O M A G A J Ą C E P O M IA R I S Z A C O W A N IE P R O J E K T Ó W IN F O R M A T Y C Z N Y C H

Beata CZARNACKA-CHROBOT

"W praktyce sukces osiągają organizacje projektujące posiadające na tyle dojrzałe standardy zarządzania, że dają się one częściowo zautom atyzować.”

Capers Jones, Am erican Programmer, IY 1996 Streszczenie: jak twierdzi autor powyższego cytatu: “Gdybyśmy budowali domy tak jak budujemy systemy informatyczne, to nie potrafilibyśmy wybudować domu wyższego niż 50 pięter, zaś ponad połowa wieżowców o wysokości większej niż 20 pięter waliłaby się zaraz po zbudowaniu." Poszukując przyczyn tego stanu rzeczy Capers Jones, autorytet na skalę międzynarodową w kwestii pomiarów i estymacji projektów systemów informatycznych, zauważa interesujący fenomen: wiele projektów przekraczających czas i/lub zaplanowany koszt realizacji jest tworzonych przy niedbałych i optymistycznych, zwykle sporządzanych ręcznie, przewidywaniach. Projekty, które wykorzystują formalne narzędzia estymacji, oparte na powszechnie przyjętych standardach oraz danych historycznych, charakteryzują się lepszymi osiągnięciami: zwykle mieszczą się w budżecie i nie mają zbyt dużych i częstych opóźnień. Niniejszy artykuł traktuje właśnie o tego typu narzędziach. Po krótkiej charakterystyce znaczenia, rodzajów, funkcji i rozwoju owych pakietów wspomagających zarządzanie projektem, przedstawiono dwie klasy takich rozwiązań. Najpierw zaprezentowano przykłady narzędzi opartych na jednostkach umownych, następnie zaś - systemów wspomagających analizę i estymację projektu bazujących na modelu COCOMO II. W końcowej części publikacji zwrócono uwagę na problemy związane z wykorzystaniem obydwu rodzajów pakietów.

1* Znaczenie narzędzi

Z punktu widzenia tak projektantów systemów informatycznych (SI), jak i ich użytkowników nie sposób przecenić znaczenia, jakie posiada właściwe zarządzanie działaniami projektowymi. Od sposobu realizacji funkcji kontroli i planowania zależy bowiem nie tylko czas i koszt konstrukcji systemu, ale też topień zgodności oferowanej aplikacji z potrzebami jego odbiorcy. Jak wskazują

85

rozmaite d ane1 skutki nieprawidłowego zarządzania procesem konstrukcji SI są alarmujące (por. rys. 1):

> ponad połowa tworzonych projektów inform atycznych przekracza czas i koszty realizacji,

> średnie przekroczenie kosztów waha się w granicach od 50 do 100% w zależności od wielkości projektu,

> średni roczny koszt projektu informatycznego w USA wynosi około 1,3 min dolarów,

> średnio czas realizacji SI wynosi ponad 220% czasu estymowanego,

> średnie przekroczenie czasu projektowania waha się w granicach od 6 do 12 miesięcy,

> wśród dużych projektów niecałe 10% mieści się w zaplanowanym budżecie i nie przekracza zaplanowanego czasu realizacji,

> średnie opóźnienie dla dużych systemów informatycznych wynosi 1 rok,

> średnio więcej niż 30% projektów upada,

> przyczyną upadku około 40% z nich jest brak kontroli zarządczej działań projektowych,

> jedynie średnio 16% projektów mieści się w zaplanowanym budżecie i nie przekracza zaplanowanego czasu realizacji - zwykle dodatkowo są one zgodne z pierwotnymi wymaganiami funkcjonalnymi.

□ 53%

□

%

□ 31%

□ przerwane

El przekraczające planowane koszty i czas

□ nie przekraczające planowanych kosztów i czasu

Rys. 1. Odsetek projektów informatycznych a terminowość i koszty realizacji Źródło: Opracowanie własne na podstawie [12].

Z tych właśnie powodów Capers Jones podjął się analizy dotyczącej przyczyn powodzenia i upadku projektów systemów informatycznych. Rezultaty

1 Por. Badania Capers’a Jones'a {Software P rodu ctivity R esearch ), Raport "Chaos" firmy Standish G roup z 1995 roku, publikacje Paul'a Strassmann'a i Lary'ego Putnam'a.

tych badań opublikowano w [1], Wynika z nich między innymi, że pomiędzy jakością narzędzi wykorzystywanych do wspomagania kontroli i planowania działań projektowych a powodzeniem projektu istnieje wyraźna zależność: w procesach konstrukcji SI, które zakończyły się sukcesem w większości przypadków wykorzystywano oprogramowanie wspomagające zarządzanie projektowaniem. Stąd powyżej zaprezentowany wniosek autora badań: “ W praktyce zatem sukces osiągają organizacje projektujące posiadające na tyle dojrzałe standardy zarządzania, że dają się one częściowo zautomatyzować Stopień “dojrzałości” tych standardów jest niezwykle istotny, jeżeli zważy się skalę skutków błędów w kontroli i planowaniu projektu SI.

Znaczenie narzędzi wspomagających planowanie i kontrolę projektu SI rośnie wraz z rozmiarem tego projektu. Im bowiem projekt jest większy, tym (zwykle) jest on bardziej złożony. A stopień złożoności systemu jest podstawową przyczyną niepowodzenia “manualnych” metod analizy i estymacji. W procesie projektowania SI w ystępują bowiem tysiące czynników, które determinują rezultat tego procesu, a których kombinacji nie są w stanie uwzględnić proste algorytmy właściwe dla takich metod. Właśnie kompleksowością charakterystyczną dla projektów informatycznych autor powyższych badań tłumaczy ich rezultaty.

Zautomatyzowane rozwiązania służące estymacji projektów są zdecydowanie lepsze od manualnych szacunków już dla aplikacji większych od 500 punktów funkcyjnych. Dla systemów o wielkości powyżej 5000 punktów funkcyjnych oceny manualne niemal nigdy nie są wystarczająco dokładne w zestawieniu z automatycznymi (por. [8]).