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:
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
W pierwszej kolejności należy oszacować ile będzie w docelowym systemie:
- Zewnętrznych wejść do systemu, czyli metod do wprowadzania i zmian danych (External Inputs).
- Zewnętrznych wyjść, czyli metod prezentacji danych np. w formie wydruku (External Outputs).
- Zewnętrznych zapytań, które wyłącznie odczytują dane (External Enquiries).
- Logicznych wewnętrznych obiektów, obecnie interpretowanych głównie jako np. tabela przechowująca dane (Internal Logical Files).
- 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:
| Kategoria | Złożoność | ||
| niska | średnia | wysoka | |
| Zewnętrzne wejścia (EI) | 3 | 4 | 6 |
| Zewnętrzne wyjścia (EO) | 4 | 5 | 7 |
| Logiczne wewnętrzne typy plików (ILF) | 7 | 10 | 15 |
| Zewnętrzne typy interfejsów (EIF) | 5 | 7 | 10 |
| Zewnętrzne typy zapytań (EE) | 3 | 5 | 6 |
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.
