Niedoszacowanie złożoności oprogramowania często prowadzi do porażek lub niskiej rentowności projektów IT. Większość sposobów szacowania nie pozwala precyzyjnie określić rozmiaru systemu, co utrudnia kontrolę kosztów i ryzyka. Istnieje jednak sprawdzona metoda - punkty funkcyjne. Umożliwiają one obiektywną ocenę rozmiaru oprogramowania, a tym samym trafną wycenę, lepsze planowanie i zwiększanie rentowności. Czym są punkty funkcyjne i jak określić ich wartość?



<h2 id="10_1">Co to są punkty funkcyjne?</h2>

Punkty funkcyjne to obecnie najbardziej precyzyjna i obiektywna metoda określania rozmiaru oprogramowania. Choć powstała w latach 70. i zdobyła wielu zwolenników na świecie, w Polsce wciąż nie jest powszechnie stosowana. Polega ona na opisaniu zakresu projektu IT poprzez zidentyfikowanie funkcjonalności, które mają zostać dostarczone użytkownikowi. Każdej funkcjonalności przypisuje się określoną wagę (liczbę punktów funkcyjnych), która odzwierciedla jej złożoność. W rezultacie cały zakres projektu można przedstawić jako jedną liczbę, która ułatwia dalsze oszacowanie czasu i kosztów realizacji.

Co ważne, punkty funkcyjne skupiają się na mierzeniu efektu końcowego, czyli dostarczanych funkcjonalności. Są niezależne od użytych technologii, języków programowania, metodyk czy architektury tworzonego systemu. Punkty funkcyjne można też wykorzystywać na <a href="https://21prim.com/blog/from-estimation-to-implementation-the-place-and-role-of-sizing-in-the-project-lifecycle/pl">wszystkich etapach projektu</a> - zarówno podczas podejmowania decyzji, realizacji, jak i podsumowania prac.

Wartość punktów funkcyjnych w projekcie można określić korzystając z różnych standardów. Do najpopularniejszych należą metodyki IFPUG i COSMIC, które definiują własne zasady pomiaru punktów funkcyjnych.

Określenie wartości punktów funkcyjnych pozwala m.in. na:

<ul>
<li>
oszacowanie wielkości projektu IT oraz zasobów potrzebnych do jego realizacji,
</li>
<li>
określenie wydajności produkcji oprogramowania poprzez mierzenie liczby punktów funkcyjnych wytwarzanych w określonym czasie lub z użyciem konkretnej technologii,
</li>
<li>
szacowanie kosztów i czasu potrzebnych na wprowadzenie zmian wynikających z modyfikacji zakresu projektu w trakcie realizacji,
</li>
<li>
obiektywne porównywanie wytwarzanego oprogramowania z oprogramowaniem wytworzonym w przeszłości pod kątem złożoności, technologii, czasu realizacji oraz innych czynników,
</li>
<li>
lepszą wycenę projektu oraz trafniejsze podejmowanie strategicznych decyzji dotyczących przyjmowania projektów, wyboru technologii czy metodyk pracy.
</li>
</ul>

W praktyce IFPUG jest częściej stosowany w dużych projektach korporacyjnych, gdzie liczy się stabilność i porównywalność z innymi projektami, podczas gdy COSMIC lepiej sprawdza się w systemach czasu rzeczywistego i aplikacjach o dużej liczbie integracji.

<h2 id="10_2">Ocena liczby punktów funkcyjnych - od czego zacząć?</h2>

Ogólna zasada mierzenia punktów funkcyjnych opiera się na podzieleniu oprogramowania na części składowe. Niektóre z nich mają wpływ na kryteria funkcjonalne (determinujące liczbę punktów funkcyjnych w projekcie), a niektóre na kryteria jakościowe (mające jedynie wpływ na koszt pojedynczego punktu funkcyjnego, bez zmian dla funkcjonalności).

<h3>Liczba punktów funkcyjnych a koszt punktu funkcyjnego – kluczowe różnice</h3>

<img alt="" src="/images/blog/9/tabela.png" loading="lazy" />

Rozróżnienie liczby i kosztu PF to dopiero pierwszy krok. Aby poprawnie wycenić projekt, trzeba jeszcze zrozumieć, jakie elementy systemu składają się na liczbę punktów funkcyjnych.

Główne komponenty oprogramowania to:

<ol>
<li>
Zewnętrzne typy wejścia (EI)
Są to sposoby wprowadzania danych do aplikacji. Mogą być nimi np. szablony, podpowiedzi, czy wybór opcji z rozwijanej listy. O ile sama funkcjonalność jest wyrażana w punktach funkcyjnych, tak jej typ stanowi jedynie kryterium jakościowe, czyli jest punktem wyjścia do obliczenia kosztu punktu funkcyjnego.
</li>
<li>
Zewnętrzne typy wyjścia (EO)
Są to metody prezentacji danych, np. możliwość wygenerowania raportu, tabeli czy wykresu. Fakt generowania prezentacji stanowi kryterium funkcjonalne, ale już forma (sposób) prezentacji jest kryterium jakościowym.
</li>
<li>
Logiczne wewnętrzne typy plików (ILF)
W metodyce COSMIC typy plików i zbiory danych używane jedynie wewnętrznie przez system nie są brane pod uwagę i nie mają wpływu na koszt punktu funkcyjnego.
</li>
<li>
Zewnętrzne typy interfejsów plików (EIF)
Są to metody wymiany danych między systemami Również są pomijane w metodyce wymiarowania COSMIC i nie wpływają na koszt punktu funkcyjnego, a jedynie na liczbę punktów w projekcie.
</li>
<li>
Zewnętrzne typy zapytań (EQ)
Są to sposoby odczytu danych z systemu bez ich modyfikacji. Mogą być to zapytania wewnętrzne różnego typu, a każdą z takich metod da się zwymiarować funkcjonalnie. Nie mają jednak wpływu na koszt punktu (nie stanowią kryterium jakościowego).
</li>
</ol>

W pierwszym kroku, na drodze analizy oprogramowania pod kątem tych kryteriów, określa się więc liczbę punktów funkcyjnych w projekcie. Na kolejnym etapie należy przyjrzeć się bliżej kryteriom funkcjonalnym, aby możliwie trafnie określić koszt pojedynczego punktu.

<h2 id="10_3">Co wpływa na koszt punktu funkcyjnego?</h2>

Po określeniu liczby punktów funkcyjnych czas dokładniej przyjrzeć się kryteriom jakościowym. Jest to niezbędne do tego, by skutecznie wykorzystać punkty funkcyjne do <a href="https://21prim.com/blog/why-is-it-worth-implementing-project-estimation-practices-and-what-consequences-might-we-face-if-we-dont/pl">szacowania kosztów projektów IT</a>. Ponieważ sama metoda jest niezależna od technologii, języków programowania czy doświadczenia zespołu, kryteria, jakie przyjmuje się do wyceny punktu, to m.in.:

<ul>
<li>
stawki zespołu projektowego - koszty pracy programistów, analityków, testerów i innych specjalistów zaangażowanych w projekt,
</li>
<li>
stosowane technologie i narzędzia - choć metoda punktów funkcyjnych jest niezależna od technologii, różne technologie mogą generować różne koszty implementacji tych samych funkcjonalności,
</li>
<li>
złożoność domeny biznesowej - projekty w bardziej wymagających branżach (np. fintech, medtech) mogą wymagać większego nakładu pracy na analizę, testy i walidację,
</li>
<li>
wymagany poziom jakości i niezawodności - im wyższe wymagania jakościowe (np. SLA, bezpieczeństwo, dostępność), tym wyższy koszt realizacji funkcjonalności,
</li>
<li>
doświadczenie i efektywność zespołu - zespoły bardziej doświadczone mogą dostarczać więcej punktów funkcyjnych w jednostce czasu, co wpływa na jednostkowy koszt punktu,
</li>
<li>
model realizacji projektu - sposób pracy (np. outsourcing, nearshoring, praca wewnętrzna) może znacząco wpłynąć na koszty osobowe i operacyjne,
</li>
<li>
skala i złożoność integracji - funkcje wymagające wielu interfejsów lub pracy z rozproszonymi systemami mogą być droższe w implementacji mimo takiej samej liczby punktów.
</li>
</ul>

<h2 id="10_4">Wpływ cech systemu na koszt punktu funkcyjnego - metodyka IFPUG</h2>

Przyglądając się bliżej czynnikom wpływającym na koszt punktu funkcyjnego stosując metodykę IFPUG widzimy, że w tym podejściu również zależy on przede wszystkim od cech ogólnych systemu i wymagań niefunkcjonalnych.

Cechy ogólne systemu (General System Characteristic) zdefiniowane w metodyce IFPUG to czynniki, które nie zwiększają samej liczby punktów funkcyjnych, ale wpływają na złożoność techniczną realizacji - a tym samym na koszt ich dostarczenia. Takimi cechami są m.in.:

<ul>
<li>przetwarzanie rozproszone (Distributed Data Processing)</li>
<li>wymagania dotyczące komunikacji danych (Data Communications)</li>
<li>wydajność systemu (Performance)</li>
<li>intensywność transakcyjna (Transaction Rate)</li>
<li>złożoność logiki przetwarzania (Complex Processing)</li>
<li>łatwość instalacji i obsługi (Installation Ease, Operational Ease)</li>
<li>liczba lokalizacji (Multiple Sites)</li>
<li>możliwość aktualizacji i zmiany (Facilitate Change).</li>
<li>tryb pracy systemu (np. On-Line Data Entry czy On-Line Update)</li>
<li>możliwość ponownego użycia komponentów (Reusability)</li>
<li>czynniki wpływające na doświadczenie użytkownika (End-User Efficiency).</li>
</ul>

W praktyce oznacza to, że niezależnie od stosowanego standardu wymiarowania, dwa projekty o identycznej liczbie punktów funkcyjnych mogą znacząco różnić się kosztowo, jeśli różni je poziom technicznej złożoności lub oczekiwań niefunkcjonalnych.

<h2 id="10_5">Jak precyzyjnie oszacować koszt punktu funkcyjnego?</h2>

Jak więc krok po kroku i precyzyjnie określić koszt punktu funkcyjnego?

<ol>
<li>
Określ zakres projektu, czyli samą liczbę punktów funkcyjnych na podstawie zidentyfikowanych funkcjonalności.
</li>
<li>
Określ wymagania niefunkcjonalne, czyli kryteria jakościowe wpływające na poziom trudności realizacji funkcjonalności. 
</li>
<li>
Przeanalizuj czynniki projektowe z uwzględnieniem cech systemu takich jak skomplikowanie logiki biznesowej, liczba użytkowników, poziom automatyzacji, łatwość instalacji i utrzymania itd.
</li>
<li>
Przeanalizuj środowisko wykonawcze, a w szczególności to, jak użyte technologie, narzędzia oraz architektura wpływają na koszt dostarczenia danej funkcjonalności. Przykładowo, wymagany nakład pracy przy wykorzystaniu dwóch różnych technologii może być zupełnie inny.
</li>
<li>
Ustal bazową stawkę kosztu punktu funkcyjnego na podstawie danych historycznych pochodzących z realizacji poprzednich projektów czy benchmarków rynkowych.
</li>
<li>
Dostosuj stawkę do specyfiki danego projektu z uwzględnieniem kryteriów jakościowych i wymagań niefunkcjonalnych.
</li>
<li>
Oblicz całkowity koszt projektu, czyli przemnóż liczbę otrzymanych punktów funkcyjnych przez skorygowaną stawkę kosztu jednego punktu.
</li>
</ol>

<h2 id="10_7">Koszt punktu funkcyjnego: podsumowanie</h2>
Aby precyzyjnie oszacować projekt IT, należy wziąć pod uwagę nie tylko samą liczbę punktów funkcyjnych, ale też niefunkcjonalne wymagania systemu, które określają jakość dostarczanego rozwiązania. Kryteria takie jak bezpieczeństwo, wydajność, skalowalność, dostępność czy ergonomia interfejsu użytkownika wpływają na nakład pracy potrzebny do realizacji poszczególnych funkcji, a tym samym na cenę jednostkową punktu funkcyjnego i całego projektu. W praktyce oznacza to, że ta sama funkcjonalność - np. formularz do składania zamówień - może mieć różny koszt w zależności od tego, jak wysokie są oczekiwania jakościowe wobec jej działania. Przykładowo, formularz zamówień w e-commerce z podstawową walidacją pól może kosztować 10 PF, ale jeśli musi obsługiwać integracje z płatnościami, dynamiczne rabaty i SLA dostępności na poziomie 99,9%, ten sam formularz podnosi koszt punktu nawet dwukrotnie. To pokazuje, jak ważne jest oddzielenie liczby PF od kosztu PF w analizie projektu.

Chcesz uprościć proces liczenia punktów funkcyjnych w praktyce? Sprawdź 21 prim - to rozwiązanie pozwala uniknąć ręcznego liczenia w Excelu, ułatwia sprawne opisanie dokumentacji projektu punktami funkcyjnymi i wygenerowanie kompletnej wyceny na bazie kosztu jednostkowego. Dzięki temu oszczędzisz czas, unikniesz błędów, a decyzje finansowe podejmiesz w oparciu o twarde dane, a nie szacunki.

<h2 id="10_6">FAQ</h2>

<ol>
<li>
Jakie elementy wpływają na liczbę punktów funkcyjnych?
Na liczbę punktów wpływają funkcjonalne komponenty systemu, takie jak: zewnętrzne typy wejścia (EI), zewnętrzne typy wyjścia (EO), zewnętrzne typy zapytań (EQ), logiczne wewnętrzne typy plików (ILF), zewnętrzne typy interfejsów plików (EIF).
</li>
<li>
Co wpływa na koszt pojedynczego punktu funkcyjnego?
Koszt punktu funkcyjnego zależy od czynników jakościowych, takich jak: wymagania niefunkcjonalne, stawki zespołu, użyte technologie, złożoność domeny, efektywność i model realizacji.
</li>
<li>
Co to są wymagania niefunkcjonalne i jakie mają znaczenie?
Wymagania niefunkcjonalne (np. wydajność, bezpieczeństwo) nie zwiększają liczby punktów funkcyjnych, ale wpływają na ich koszt ze względu na to, że podnoszą techniczną złożoność projektu. Np. wymaganie, aby system obsługiwał 1000 transakcji na sekundę, nie zmienia liczby PF, ale podnosi koszt ich implementacji o dodatkowe testy i mocniejsze serwery.
</li>
<li>
Czy dwa projekty o tej samej liczbie punktów funkcyjnych mogą różnić się kosztowo?
Tak, gdyż nawet przy identycznej liczbie punktów funkcyjnych projekty mogą znacząco różnić się kosztami ze względu na różny poziom złożoności technicznej, wymagania niefunkcjonalne, użyte technologie czy sposób realizacji.
</li>
<li>
Jak oszacować koszt projektu na podstawie punktów funkcyjnych?
Najpierw należy określić liczbę punktów funkcyjnych, następnie przeanalizować wymagania niefunkcjonalne, ustalić bazową stawkę punktu, a na końcu przeliczyć całościowy koszt projektu.
</li>
</ol>