Metoda punktów funkcyjnych nie jest idealnym sposobem pomiaru pracochłonności, jakości i wartości biznesowej aplikacji, ale daje dobre przybliżenie kosztów projektu.

Mimo iż szacowanie poszczególnych elementów systemów IT jest jednym z najważniejszych zagadnień związanych z planowaniem projektów, to czynność ta nadal jest lekceważona przez wielu menedżerów IT w Polsce. Najprawdopodobniej przyczyną takiego nonszalanckiego podejścia do tego zagadnienia jest nieświadomość korzyści, jakie mogą wynikać z dobrego oszacowania. W praktyce przez szacowanie należy rozumieć określenie czasochłonności poszczególnych zadań, które należy wykonać, aby z powodzeniem zakończyć projekt IT. Nie istnieje uniwersalna metoda, która w cudowny sposób, niezależnie do wielkości i przeznaczenia, określi wszystkie parametry dla tworzonego oprogramowania, dlatego już na początku naszych rozważań należy obalić mit, zgodnie z którym na podstawie szczegółowej specyfikacji możemy określić dokładny koszt projektu i czas jego trwania. Metoda punktów funkcyjnych Istnieje kilka metod szacowania projektów IT.

Jedną z najpopularniejszych jest metoda punktów funkcyjnych FP (Function Points). Stosowana jest przede wszystkim przy szacowaniu pracochłonności i jakości oprogramowania. Podstawą mierzenia jest dokładna specyfikacja potrzeb użytkownika (planowanie funkcjonalności aplikacji) co do interfejsu, ilości gromadzonych i przetwarzanych danych, uzyskiwanych wydruków itp. Metoda FP nie jest idealnym sposobem pomiaru pracochłonności tworzenia aplikacji lub wyceny jej wartości biznesowej, jednak przy jej wykorzystaniu można uzyskać dosyć dokładne przybliżenie. Wielkość projektu, wyrażona w punktach funkcyjnych, jest swoistą miarą bezwzględną, której można użyć przy określeniu każdej z tych wartości. Wynik uzyskany metodą punktów funkcyjnych może być podstawą do:

1. Zawierania i negocjowania umów z klientami – przedstawienie oszacowania wymagań wobec zamawianego oprogramowania w jednostkach powszechnie stosowanych może być podstawą określenia wartości usługi.
2. Normalizacji innych miar – odniesienie np. liczby awarii systemu do liczby jej punktów funkcyjnych jest podstawą do określenia bezwzględnej miary jakości stosowanych rozwiązań.
3. Mierzenia wydajności pracowników – ocena wielkości przydzielanych zadań. Stosunek wydajności najlepszego i najsłabszego programisty wynosi czasem nawet 10:1. Znając wydajność różnych osób można ocenić, które z nich warto zatrzymać w firmie.
4. Określenia stopnia zaawansowania projektu – jeśli znany jest jego rozmiar i czas trwania, można to dosyć precyzyjnie określić.

Twórcą powyższej metody jest Allan Albrecht, który podczas pracy w IBM opracował metodę oceny kosztów rozwoju aplikacji niezależną od języka, w którym aplikacja ma być tworzona. Wyniki prac zaprezentowano w 1979 roku na konferencji w Monterey w Kalifornii [Albrecht A.J., Measuring Application Development Productivity in Proc. IBM Applications Development Symposium. GUIDE Int and Share Inc., IBM Corp., Monterey, CA 1979]. Allan Albrecht wyodrębnił podstawowe funkcje, jakie są istotne dla użytkownika: wejścia, wyjścia, zapytania, wewnętrzne pliki danych i zewnętrzne interfejsy.

Funkcje te są elementami modelu aplikacji – zgodnie z prezentowaną metodą, każdy system na podstawie wymagań użytkowników można rozpisać na takie elementy. Aby przeprowadzić oszacowanie systemu metodą FP na podstawie wymagań tworzonego systemu, należy zidentyfikować poszczególne elementy i przypisać je do jednej z trzech grup (proste, średnie i złożone). Szczegółowe kryteria przypisania możemy odnaleźć w literaturze. Poszczególne elementy w każdej z kategorii otrzymują pewną liczbę punktów. Aby otrzymać liczbę punktów wstępnego oszacowania, należy przemnożyć liczbę elementów danej kategorii przez liczby punktów i zsumować. Aby punkty wstępnego oszacowania (UT – Unadjusted total) przetworzyć na punkty funkcyjne (FP), należy przemnożyć je przez czynnik modyfikujący VAF (Value Adjustment Factor) obliczany zgodnie z wzorem:

VAF = 0, 65 + [ΣFi / 100]

Współczynnik modyfikujący odpowiada za uwzględnienie informacji o rodzaju realizowanego projektu i związany jest z odpowiedziami udzielonymi na poniższe pytania (odp. w skali 0 – nie istotne do 5 – bardzo ważne):

F1 Wymiana danych

F2 Rozproszone przetwarzanie danych

F3 Wymagana wydajność systemu

F4 Specjalne wymagania sprzętowe

F5 Działanie w warunkach dużego obciążenia (częstotliwość transakcji)

F6 Wprowadzanie danych w czasie działania systemu (transakcje online)

F7 Efektywność wprowadzania danych przez użytkownika

F8 Modyfikacja danych w czasie działania systemu (plików logicznych)

F9 Złożoność przetwarzania danych

F10 Możliwość ponownego/wielokrotnego wykorzystania kodu

F11 Łatwość instalacji

F12 Łatwość administracji

F13 Instalacja w wielu lokalizacjach

F14 Łatwość pielęgnacji i dostosowywania

Pozostaje wykonanie prostego mnożenia:

FP = UT x VAF

Aby uzyskać liczbę linii kodu (LOC), należy otrzymaną liczbę punktów funkcyjnych przemnożyć przez właściwy współczynnik. W tabeli 1 przedstawiono współczynniki LOC/FP dla różnych narzędzi programistycznych. Oczywiście nie możemy zakładać, że LOC przełoży się bezpośrednio na pracochłonność. Należy pamiętać, że jedną linię kodu pisze się z różną szybkością w różnych językach programowania – na przykład dużo szybciej można napisać linię kodu w asemblerze niż C+.