SZACUNEK ZUŻYCIA ZASOBÓW

R ealizacja projektu

Punkty fu n kcyjn e

R ealn ie zu żyte zasob y

Projekt n

W artości atryb u tów p ro d u k ty ­ w ności

Projekt 1

Id en ty fi­

kacja p rojek tu

Rys. 4. Schemat systemu wspomagającego szacowanie projektów

Źródło: [10]

> Integracja narzędzi na poziomie przedsiębiorstwa:

Zwykle systemy wspomagające zarządzanie projektami informatycznymi są ukierunkowane na specyficzne ich rodzaje. Dotyczy to zarówno narzędzi estymacji kosztów, jak i pakietów umożliwiających planowanie, wykrywanie błędów, itp. Na poziomie przedsiębiorstwa często jednak w ystępuje potrzeba wyznaczenia długoterminowych prognoz (lub pomiarów) nierzadko setek odmiennych aplikacji, których całkowity rozmiar może przekraczać 2 min punktów funkcyjnych lub 250 min linii kodu źródłowego. Dotychczas nie ma narzędzi, poza prototypami, które pozwoliłyby na predykcję np. rocznego kosztu utrzymania, rocznego kosztu udoskonalania wszystkich systemów funkcjonujących w przedsiębiorstwie łącznie.

W przedstawionych grupach narzędzi spotyka się dwie metody przekształcania liczby punktów funkcyjnych na oceny estymacyjne dla projektu:

> Pierw szą stanowi założenie pewnego poziomu produktywności wyrażonej w PF na osobomiesiąc. W arunkiem koniecznym do prawidłowego wykorzystania tego podejścia jest dysponowanie dużą bazą danych o podobnych projektach.

Proste zakwalifikowanie systemu do danej kategorii bowiem nie jest wystarczające, jako że w ramach danej kategorii mogą występować odmienne stopy produktywności ze względu na różne atrybuty projektu (np. rozmiar projektu, narzędzia wykorzystywane przy projektowaniu, itp). W związku z tym, niezbędne jest przyjęcie stopy produktywności z rzeczywiście podobnego rozwiązania.

^ Drugi sposób polega na przeliczeniu liczby punktów funkcyjnych na ekwiwalentną liczbę linii kodu źródłowego oraz wykorzystaniu modelu estymacyjnego COCOMO II. Rezultat przeliczenia punktów funkcyjnych na linie kodu źródłowego stanowi zatem wejście do owego modelu. W metodzie tej nie poprzestaje się na wyznaczeniu rozmiaru SI w PF, gdyż model COCOMO II pozwala na uwzględnienie dodatkowych czynników (oprócz wielkości systemu) mających wpływ na oceny e sty m a cy jn e ^ Po co więc w ogóle wykorzystuje się punkty funkcyjne w tego typy narzędziach ? Odpowiedź jest prosta: liczba PF może być wyprowadzona ju ż we wstępnych fazach projektowania, zanim pojawi się możliwość oszacowania liczby linii kodu, a często nawet jeszcze przed wyborem języka (języków) programowania. Opisywany sposób postępowania nie pozostaje jednak bez wątpliwości. Jedną z nich stanowi problem, czy podstawą przeliczania PF na linie kodu źródłowego ma być nieostateczna liczba PF (tzw. rozmiar funkcjonalny), czy też liczba PF po skorygowaniu (czyli ostateczna)11.

Obydwa podejścia zostały uwzględnione w [7], gdzie można znaleźć zarówno średnie stopy produktywność dla różnych rodzajów aplikacji (np.

ekonomicznych, zarządczych, m ilitarnych)12, jak i tabelę poziomów języków (ang backfiring table), określającą liczbę linii kodu źródłowego niezbędną do implementacji 1 punktu funkcyjnego w różnych językach programowania. Tabelę należy jednak traktować z dużą ostrożnością, jak zresztą zauważa sam jej twórca, między innymi z tego powodu, iż zawiera ona jedynie orientacyjne współczynniki przeliczeniowe, będące wynikiem badań, których ciągle jeszcze nie można uznać za zakończone.

7. W ykorzystanie jed n o ste k um ow nych w narzędziach

Metoda punktów funkcyjnych również pozwala na uwzględnienie dodatkowych czynników (przez tzw. parametry wpływu), ale w modelu COCOMO II przyjęto inne rozwiązania.

B. Boehm, autor różnych wersji modelu COCOMO, uznaje, iż lepsze rezultaty daje wykorzystanie rozmiaru funkcjonalnego. Tego zdania jednak nie podzielają inni praktycy.

“ IFPUG rozpoczął gromadzenie danych wzorcowych na ten temat.

105

Jak widać z powyższego opisu, nawet narzędzia oparte na modelu COCOMO II nie m ogą obejść się bez jednostek umownych i bazować jedynie na jednostkach programowych. W ykorzystywanie jednostek um ownych jest bowiem warunkiem koniecznym wyprowadzenia prawidłowych pom iarów oraz ocen estymacyjnych dla projektu informatycznego.

Od około ćwierćwiecza rozwija się metody, techniki i oparte na nich narzędzia, których celem jest zwiększenie jakości procesu tworzenia SI oraz, dzięki temu, jakości samego systemu informatycznego. W ymaganiem teraźniejszości jest przekonanie potencjalnych użytkowników tych systemów o wartości dodanej oferowanej przez owe metody i wspomagające je narzędzia. Sprzyjają one przecież osiągnięciu celów organizacji zarówno projektujących systemy informatyczne, jak i tych, dla których są one budowane. Praktyka pokazuje, że rzadko zdajemy sobie sprawę z wagi problemu oraz z możliwości jego rozwiązania, tracąc z tego powodu poważne kwoty, wydatkowane na projekty przerwane lub zrealizowane, ale przekraczające, często znacznie, planowany czas i koszty realizacji. Jeżeli zaś dostrzegamy problem, to brak nam wiary w jego skuteczne rozwiązanie lub choćby zmniejszenie jego skali. Niemal nie stosujemy bowiem żadnych metod, a tym bardziej narzędzi, które je wspomagają, albo wykorzystujemy metody niewłaściwe (tylko co setny SI jest mierzony lub estymowany przy użyciu punktów funkcyjnych), sporządzając szacunki w oparciu o, ja k twierdzi Capers Jones, manualne metody analizy, które nie są w stanie ogarnąć wszystkich czynników wpływających na przebieg procesu projektowania. Dane pokazują (por. [12]), iż w USA z powodu przerwania projektów oraz przekroczenia estym owanego czasu realizacji traci się rocznie ponad 140 miliardów dolarów, czyli ponad 50% środków wydawanych w tym czasie na projekty informatyczne ! Kwoty m ów ią same za siebie. Dlatego warto spróbować liczyć koszty SI w oparciu o sprawdzone metody i narzędzia. Jest całkiem prawdopodobne, że wtedy, o ile zrobimy to właściwie, zaoszczędzimy całkiem pokaźne sumy.

Literatura

1. American Programmer, Vol. 9, #5, kwiecień 1996.

2. Brooks Frederic P., Jr, Mityczny osobomiesiąc - eseje o inżynierii oprogramowania, W NT, W arszawa 2000.

3. Czarnacka-Chrobot Beata, Produktywność projektów informatycznych - elementy metody punktów funkcyjnych (1), Infoman 2/3/99 (5), luty/marzec

1999.

4. Czarnacka-Chrobot Beata, Produktywność projektów informatycznych - standardy metody punktów funkcyjnych (2), Infoman 4/99 (6), kwiecień 1999.

5. DeM arco T., Controlling Software Projects, New York, Yourdon Press, 1982.

6. IFPUG Function Point Counting Practices: M anual Release 4.1, IFPUG W esterville, OH, January 1999.

7. Jones Capers, Applied Software Measurement, McGraw-Hill, New York, 1996, 2nd edition.

8. Jones Capers, Software Project Management in 21st Century, American Programmer, Vol. XI, No. 2; February 1998.

9. Knoll H.D., Busse J.: Aufwandsschatzung von Software-Projekten in der Praxis, M annheim 1991.

10. Milosz Marek, Szacowanie zasobów w projektach informatycznych, Informatyka 11, 1997, 15-22.

11. Putnam L.H., W are Myers, Measures for Excellence, Yourdon Press, 1992.

12. Raport “Chaos” firmy Standish Group, 1995.

13. Yourdon Edward, M arsz ku klęsce. Poradnik dla projektanta systemów, WNT, Warszawa 2000

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

Katedra Informatyki Gospodarczej Al. Niepodległości 162

02-554 W arszawa

e-mail: bczam@ sgh.waw.pl

107

PRZEGLĄD METOD POPRAWY EFEKTYWNOŚCI