Punkt funkcyjny
Punkt funkcyjny jest „jednostką miary” wyrażającą ilość funkcjonalności biznesowych, jakie system informacyjny (jako produkt) zapewnia użytkownikowi. Punkty funkcyjne są używane do obliczania pomiaru rozmiaru funkcjonalnego (FSM) oprogramowania. Koszt (w dolarach lub godzinach) pojedynczej jednostki jest obliczany na podstawie wcześniejszych projektów.
Normy
Istnieje kilka uznanych standardów i/lub publicznych specyfikacji dotyczących wymiarowania oprogramowania w oparciu o punkt funkcyjny.
1. Normy ISO
- FiSMA: ISO/IEC 29881:2010 Informatyka – Inżynieria systemów i oprogramowania – Metoda pomiaru rozmiaru funkcjonalnego FiSMA 1.1.
- IFPUG : ISO/IEC 20926:2009 Inżynieria oprogramowania i systemów – Pomiar oprogramowania – Metoda pomiaru wielkości funkcjonalnej IFPUG.
- Mark-II: ISO / IEC 20968: 2002 Inżynieria oprogramowania - Analiza punktów funkcyjnych Ml II - Podręcznik praktyk liczenia
- Nesma: ISO / IEC 24570: 2018 Inżynieria oprogramowania - Metoda pomiaru rozmiaru funkcjonalnego Nesma wersja 2.3 - Definicje i wytyczne dotyczące liczenia do zastosowania analizy punktów funkcyjnych
- COSMIC : ISO/IEC 19761:2011 Inżynieria oprogramowania. Funkcjonalna metoda pomiaru wielkości.
- OMG : ISO/IEC 19515:2019 Technologia informacyjna — Grupa zarządzania obiektami Automatyczne punkty funkcyjne (AFP), 1.0
Pierwsze pięć standardów to implementacje nadrzędnego standardu pomiaru rozmiaru funkcjonalnego ISO/IEC 14143. Specyfikacja OMG Automated Function Point (AFP), kierowana przez Consortium for IT Software Quality , zapewnia standard automatyzacji liczenia punktów funkcyjnych zgodnie z zgodnie z wytycznymi Międzynarodowej Grupy Użytkowników Punktów Funkcyjnych ( IFPUG ). Jednak obecne implementacje tego standardu mają ograniczenie w możliwości odróżnienia wyjścia zewnętrznego (EO) od zapytań zewnętrznych (EQ) po wyjęciu z pudełka, bez wstępnej konfiguracji.
Wstęp
Punkty funkcyjne zostały zdefiniowane w 1979 roku w Measuring Application Development Productivity przez Allana Albrechta z IBM . Funkcjonalne wymagania użytkownika oprogramowania są identyfikowane, a każdy z nich jest klasyfikowany do jednego z pięciu typów: wyjścia, zapytania, dane wejściowe, pliki wewnętrzne i interfejsy zewnętrzne. Gdy funkcja zostanie zidentyfikowana i sklasyfikowana w typ, jest następnie oceniana pod kątem złożoności i przypisywana jest liczba punktów funkcyjnych. Każde z tych funkcjonalnych wymagań użytkownika jest odwzorowywane na funkcję biznesową użytkownika końcowego, taką jak wprowadzanie danych dla danych wejściowych lub zapytanie użytkownika dotyczące zapytania. To rozróżnienie jest ważne, ponieważ powoduje, że funkcje mierzone w punktach funkcyjnych łatwo odwzorowuje na wymagania zorientowane na użytkownika, ale ma również tendencję do ukrywania funkcji wewnętrznych (np. algorytmów), których wdrożenie również wymaga zasobów.
Obecnie nie ma uznanej przez ISO metody FSM, która uwzględnia złożoność algorytmu w wyniku wymiarowania. Ostatnio zaproponowano różne podejścia do radzenia sobie z tą postrzeganą słabością, zaimplementowane w kilku komercyjnych produktach oprogramowania. Odmiany metody IFPUG opartej na Albrechcie, zaprojektowane w celu zrekompensowania tego (i innych słabości), obejmują:
- Wczesne i łatwe punkty funkcyjne – koryguje złożoność problemu i danych za pomocą dwóch pytań, które dają nieco subiektywny pomiar złożoności; upraszcza pomiar, eliminując konieczność liczenia elementów danych.
- Punkty funkcji inżynierskich – Zliczane są elementy (nazwy zmiennych) i operatory (np. arytmetyka, równość/nierówność, boolean). Ta odmiana podkreśla funkcję obliczeniową. Intencja jest podobna do miar złożoności Halsteada opartych na operatorze/argumencie .
- Miara Bang – definiuje metrykę funkcji opartą na dwunastu prymitywnych (prostych) zliczeniach, które wpływają na Bang lub pokazują go, zdefiniowaną jako „miara prawdziwej funkcji, która ma być dostarczona, tak jak jest postrzegana przez użytkownika”. Miara Bang może być pomocna w ocenie wartości jednostki oprogramowania pod względem tego, ile użytecznych funkcji zapewnia, chociaż w literaturze jest niewiele dowodów na takie zastosowanie. Użycie miary Bang może mieć zastosowanie, gdy rozważana jest przebudowa (całkowita lub fragmentaryczna), jak omówiono w Konserwacja systemów operacyjnych — przegląd.
- Punkty funkcji — dodaje zmiany w celu poprawy możliwości zastosowania w systemach o znacznym przetwarzaniu wewnętrznym (np. systemy operacyjne, systemy komunikacyjne). Pozwala to na uwzględnienie funkcji, które nie są łatwo dostrzegalne przez użytkownika, ale są niezbędne do prawidłowego działania.
- Weighted Micro Function Points – jeden z nowszych modeli (2009), który dopasowuje punkty funkcyjne za pomocą wag pochodzących ze złożoności przepływu programu, słownictwa operandów i operatorów, użycia obiektów i algorytmu.
- Rozmyte punkty funkcyjne — proponuje rozmyte i stopniowe przejście między niskimi średnimi a średnimi x wysokimi złożonościami
Kontrast
Użycie punktów funkcyjnych na rzecz linii kodu ma na celu rozwiązanie kilku dodatkowych problemów:
- Ryzyko „zawyżenia” tworzonych linii kodu, a tym samym zmniejszenia wartości systemu pomiarowego, jeśli programiści będą zachęcani do większej produktywności. Zwolennicy FP nazywają to pomiarem rozmiaru rozwiązania zamiast rozmiaru problemu.
- Linie kodu ( LOC ) wynagradzają języki niskiego poziomu, ponieważ potrzeba więcej linii kodu, aby zapewnić podobną funkcjonalność do języka wyższego poziomu. C. Jones oferuje w swojej pracy metodę naprawienia tego.
- Miary LOC nie są przydatne we wczesnych fazach projektu, gdzie oszacowanie liczby wierszy kodu, które zostaną dostarczone, jest trudne. Jednak Punkty Funkcyjne można wyprowadzić z wymagań i dlatego są przydatne w metodach takich jak szacowanie przez zastępstwo.
Krytyka
Albrecht zauważył w swoich badaniach, że Punkty Funkcyjne były silnie skorelowane z liniami kodu, co spowodowało zakwestionowanie wartości takiej miary, jeśli dostępna jest bardziej obiektywna miara, a mianowicie zliczanie linii kodu. Ponadto podjęto wiele prób zaradzenia dostrzeganym niedociągnięciom za pomocą tego środka poprzez rozszerzenie schematu liczenia. Inni oferowali rozwiązania umożliwiające obejście wyzwań poprzez opracowanie alternatywnych metod, które tworzą wskaźnik zastępczy dla ilości dostarczanej funkcjonalności.
Zobacz też
- COCOMO (konstruktywny model kosztów)
- Porównanie oprogramowania do szacowania rozwoju
- Metoda Marka II
- Punkt obiektu
- Szacowanie pracochłonności tworzenia oprogramowania
- Rozmiar oprogramowania
- Linie źródłowe kodu
- Wykorzystaj punkty przypadku
- Metoda prostych punktów funkcyjnych