Jak obliczyć złożoność projektu? Punkty funkcyjne w praktyce

Niedoszacowanie złożoności budowanego rozwiązania to popularna przyczyna porażek projektów IT. Określenie ile jest do zrobienia i jak długo to zajmie jest sporym wyzwaniem. Na to nakłada się częsta przypadłość kierowników projektów, którą jest przesadny optymizm i ignorowanie potencjalnych zagrożeń.

Algorytm do określania złożoności projektu – punkty funkcyjne (Function Points)

Z pomocą przychodzą techniki, które wykorzystują sprawdzone przez lata algorytmy. Dzięki temu nie trzeba zgadywać i określać czasu trwania projektu na wyczucie. Po podstawieniu wartości do wzorów otrzymuje się konkretny wynik.

Jedną z miar do szacowania złożoności projektu są punkty funkcyjne (Function Points). Technikę tę opracował w 1979 roku Allan Albrecht w ramach projektów prowadzonych w IBM.

Historia punktów funkcyjnych

Allan Albrecht przedstawił algorytm określania złożoności projektów w artykule: „Measuring Application Development Productivity”. Przedstawił tam wyniki pracy 450 osób realizujących 150-170 kontraktów jednocześnie (kontrakt to pojedyncze zadania do wykonania lub większy projekt).

W tamtym czasie projekty realizowane były oczywiście waterfallowo, więc precyzyjne określenie czasu trwania projektu było istotne w początkowej fazie realizacji. Podział projektu na poszczególne etapy wyglądał jak poniżej:

rozkład projektu w czasie
Źródło: Measuring Application Development Productivity, Allan J. Albrecht

Według Allana Albrechta projektowanie zajmowało około 20% czasu całego projektu. Pozostała część to implementacja i testowanie. W tym obszarze więc można było zyskać najwięcej.

Allan Albrecht chciał sprawdzić, które z wykorzystywanych technologii czy narzędzi programistycznych są najskuteczniejsze. Do tego potrzebował wspólnego mianownika dla wszystkich projektów. Czegoś, co pozwoli porównać projekt realizowany w technologii X z projektem pisanym w języku Y.

Tym czymś były właśnie punkty funkcyjne.

Allan Albrecht przeanalizował dane z 22 projektów realizowanych w okresie 5-ciu lat. Stosując punkty funkcyjne do oceny złożoności zauważył, że pewne technologie pozwalają na szybszą realizację niż inne. W efekcie zaczęto koncentrować się na tych najbardziej skutecznych rozwiązaniach co przełożyło się na skrócenie czasu realizacji jednego punktu funkcyjnego z około 40 godzin do 10 godzin.

Dzięki temu większość projektów realizowanych w IBM kończyła się o czasie i w budżecie.

Jak obliczać punkty funkcyjne?

Szacowanie złożoności projektu z wykorzystaniem punktów funkcyjnych jest niezależne od wykorzystywanej technologii czy wcześniejszych doświadczeń zespołu. Przygotowanie danych wymaga jednak sporo pracy. Algorytm szacowania składa się z kilku kroków.

Określenie liczby elementów przyszłego systemu

tabela do wprowadzania punktów funkcyjnych
Fragment karty to wyliczania punktów funkcyjnych, źródło: Measuring Application Development Productivity, Allan J. Albrecht

W pierwszej kolejności należy oszacować ile będzie w docelowym systemie:

  1. Zewnętrznych wejść do systemu, czyli metod do wprowadzania i zmian danych (External Inputs).
  2. Zewnętrznych wyjść, czyli metod prezentacji danych np. w formie wydruku (External Outputs).
  3. Zewnętrznych zapytań, które wyłącznie odczytują dane (External Enquiries).
  4. Logicznych wewnętrznych obiektów, obecnie interpretowanych głównie jako np. tabela przechowująca dane (Internal Logical Files).
  5. Zewnętrznych interfejsów, czyli wymiany danych z innymi systemami (External Interface Files).

Parametry te powstały ponad 40 lat temu i wpasowanie ich we współczesne rozwiązania nie jest oczywiste. Na przykład niektóre źródła przypisują GUI do kategorii EO inne do EE.

Aby uniknąć nieporozumień warto sięgnąć po sprawdzony standard przygotowany przez International Function Point User Group (ISO/IEC 20926:2009).

Każdy z tych elementów trzeba potem przypisać do jednej z grup złożoności – niska, średnia lub wysoka, a następnie przypisać mu liczbę punktów (wagę) korzystając z tabeli:

KategoriaZłożoność
niskaśredniawysoka
Zewnętrzne wejścia (EI)346
Zewnętrzne wyjścia (EO)457
Logiczne wewnętrzne typy plików (ILF)71015
Zewnętrzne typy interfejsów (EIF)5710
Zewnętrzne typy zapytań (EE)356
Źródło: “Function Point Based Estimation of Effort and Cost in Agile Software Development.”, Anupam Yadava, Ashish Sharma.

Jeżeli więc przykładowy system zawiera:

  • 2 x EI o niskiej złożności (2*3 = 6)
  • 2 x EO o niskiej złożności i 3 x EO o wysokiej złożności (2*4 + 3*7 = 29)
  • 5 x ILF o średniej złożności (5*10 = 50)
  • 4 x EIF o niskiej złożności (4*5 = 20)
  • 1 x EE o niskiej złożności i 2 x EE o średniej złożności (1*3 + 2*5 = 13)

UFP = 6 + 29 + 50 + 20 + 13 = 118

Suma wag przypisanych do każdego elementu systemu jest oznaczana jako UFP (Unadjusted Functional Points).

Określenie wpływu czynników projektowych

To jeszcze nie koniec. Następnie trzeba oszacować wpływ czternastu czynników, takich jak np. wydajność czy reużywalność komponentów systemu. Każdemu z tych elementów przypisuje się wagę od 0 (bez wpływu) do 5 (krytyczny wpływ).

Pełna lista zawiera:

  • Data communications
  • Distributed data processing
  • Performance
  • Heavily used configuration
  • Transaction rate
  • On-Line data entry
  • End-user efficiency
  • On-Line update
  • Complex processing
  • Reusability
  • Installation ease
  • Operational ease
  • Facilitate change
  • Multiple sites

Suma punktów przypisanych do każdej z czternastu kategorii to TDI (Total Degree of Influence).

Ostateczny wynik, czyli Adjusted Function Points oblicza się jako:

AFP = UFP * (TDI * 0,01 + 0,65)

Przykładowo, jeżeli każdy z czynników został wyceniony na 3 punkty, to TDI = 14*3 = 42.
Dla wcześniejszego przykładu, w którym UFP = 118:

AFP = 118*(42*0,01 + 0,65) = 118*1,07 = 126,26.

Szacowanie czasochłonności na podstawie punktów funkcyjnych

Co dalej zrobić z tą wartością? Tu właśnie zaczynają się problemy. W zależności od umiejętności zespołu czy zastosowanej technologii, czasochłonność jednego punktu może być różna.

Potrzebne będa więc dane historyczne, lub dodatkowe obliczenia. W Internecie można znaleźć przeliczniki punktów funkcyjnych na godziny pracy lub linie kodu (np. https://www.qsm.com/resources/function-point-languages-table lub w tym artykule). Z tej tabeli wynika, że np. 1 AFP to średnio 54 linie kodu w C#.

Wyniki te należy traktować z dystansem, gdyż dynamiczne zmiany w stosowanych technologiach znacząco wpływają na efektywnośc pracy, przez co wyniki aktualne jeszcze jakiś czas temu mogą być zupełnie nieadekwatne współcześnie.

Zastosowanie punktów funkcyjnych

Według mnie punkty funkcyjne są interesującą metodą do opisywania złożoności systemów, a następnie szacowania ich czasochłonności. Żeby uzyskać wartościowe wyniki należy:

  • doprecyzować każdy z parametrów, tak żeby było jasne co należy w ramach niego zliczać, a co nie (lub skorzystać z wspomnianego ISO/IEC 20926:2009).
  • zweryfikować obliczenia dla kilku zakończonych projektów w ramach organizacji.

Dzięki temu możliwe będzie wypracowanie standardu obowiązującego w ramach zespołu lub firmy. A następnie przeliczanie liczby punktów funkcyjnych na czas i koszt (np. 1 punkt funkcyjny to 10 godzin pracy).

Punkty funkcyjne mogą też stanowić wejście do wyliczeń z wykorzystaniem algorytmu COCOMO II, tak jak w przykładowym kalkulatorze: http://softwarecost.org/tools/COCOMO/


W artykule Zarządzanie kosztami projektu IT – Design to Cost opisałem jak podejść do planowania projektu od drugiej strony, czyli traktując koszt i czas jako nieprzekraczalne ograniczenia.

zarządzanie kosztami projektu it - design to cost

Witaj w Project Makers!

Cześć, jestem Artur.

Uruchomiłem bloga Project Makers po to, żeby pokazywać jak przy pomocy podstawowych narzędzi i zdrowego rozsądku, każdy może w krótkim czasie osiągnąć mistrzostwo w zwinnym zarządzaniu projektami.

A wszystko zaczęło się od niezaliczonych egzaminów z programowania
(czytaj dalej…)

Potrzebujesz konsultacji?
Umów BEZPŁATNE spotkanie!

bezpłatne konsultacje zarządzanie projektami

Partnerzy Project Makers

Szukasz ciekawych treści?

Najnowsze wpisy

  • All Post
  • Definiowanie wymagań
  • Narzędzia
  • Planowanie
  • Praca z celami
  • Rekomendacje
  • Rozmowy z ekspertami
  • Zarządzanie budżetem
  • Zarządzanie jakością
  • Zarządzanie zespołem

Znajdź na blogu

Szukasz ciekawych, treści
o Zwinnym Zarządzaniu Projektami?

Zapisz się do Newslettera Project Makers!
Najnowsze trendy, ciekawostki, narzędzia.
Tylko sprawdzone treści. 

Współpracuję z:

Project Makers
u. Dworcowa 8
44-240 Żory
artur@projectmakers.pl

Copyright © 2024 Project Makers