Punkt funkcyjny – metryka złożoności oprogramowania podawana jako liczba bezwymiarowa określająca efektywną względną miarę wartości funkcji oferowanej przez program użytkownikowi. Najczęściej jest podstawą do oszacowania m.in. pracochłonności wytworzenia danego oprogramowania. Pojęcie to zaproponował w 1979 r. A. J. Albrecht z firmy IBM[1].

Wstęp

Metoda punktów funkcyjnych jest aktualnie jednym z popularnych sposobów szacowania miary zastosowania programów. System został stworzony przez pracownika IBM, który zdefiniował go i opracował wraz z kolegami w latach siedemdziesiątych. IBM zrzekł się wyłączności, dzięki czemu dostęp do niego został umożliwiony dla każdego. W wyniku tego działania powołano w USA organizację zwaną the International Function Point Users Group – IFPUG, która zajmuje się rozwojem, rozpowszechnianiem i standaryzacją systemu FPA[2]. Zasada działania metody punktów funkcyjnych polega na wydzieleniu w programie pięciu typów: wejściowego, wyjściowego, logicznego typu wejściowego, zewnętrznego typu interfejsów oraz zewnętrznego typu zapytań- następnie na przydzielaniu im złożoności oraz przypisaniu odpowiedniej liczby punktów funkcyjnych. FPA umożliwia szacowanie wartości funkcyjnej programu niezależnie od stosowanego języka oprogramowania w którym aplikacja została napisana. Pozwala to na efektywne zarządzanie projektami programistycznymi oraz związanymi z nimi kosztami. Punkty funkcyjne liczy się dla trzech różnych typów:

  1. Dla projektów w fazie planowania- wszelkich ocen dokonuje się na podstawie wymagań przedstawionych przez użytkownika.
  2. Dla zmian w istniejącym programie- uaktualnienia, nowe wersje, wszelkich modyfikacji zmieniających funkcjonalność.
  3. Dla gotowego programu.

Analiza punktów funkcyjnych

Pierwszym krokiem jest ograniczenie zakresu dokonywanej analizy, czyli oszacowywanej funkcjonalności, według trzech poniższych reguł sugerowanych przez IFPUG.

  1. Granice powinien określać użytkownik w oparciu o swój punkt widzenia i zapotrzebowanie.
  2. Ograniczenia technologiczne nie powinny być brane pod uwagę podczas określania granic między współpracującymi systemami. Należy kierować się przy tym ich funkcjonalnością.
  3. Zmiana zakresu analizy nie powinna wpływać na ustalone pierwotnie granice. Zmiana taka może zachodzić jedynie z powodu dodawania lub usuwania funkcjonalności bezpośrednio wpływających na granicę.

Podstawowym założeniem metody punktów funkcyjnych jest podzielenie oprogramowania na pięć składowych[3].

  1. Zewnętrzne typy wejścia to metody dokonywania zmian w wewnętrznych danych systemu.
  2. Zewnętrzne typy wyjścia to metody reprezentacji danych przechowywanych przez system. Przykładem są wydruki komputerowe. Dane wyświetlane na ekranie nie należą do tej kategorii, są kwalifikowane jako opisane poniżej zewnętrzne typy zapytań.
  3. Logiczne wewnętrzne typy plików to pliki używane wewnętrznie przez system. We współczesnej informatyce pojęcie pliku zmieniło swoje znaczenie. Składową tą możemy interpretować jako zbiór danych opisujących obiekty danego typu, na przykład tabelę w relacyjnej bazie danych.
  4. Zewnętrzne typy interfejsów plików to metody wymiany danych między innymi systemami informatycznymi. Przykładem może być interfejs umożliwiający pobieranie danych z aplikacji internetowej w formacie JSON lub pliki współdzielone między różnymi aplikacjami.
  5. Zewnętrzne typy zapytań to metody odczytu danych z systemu nie powodujące ich modyfikacji. Przykładem jest zapytanie SELECT z języka SQL.

Następnym krokiem analizy jest znalezienie wszystkich elementów analizowanego systemu informatycznego, które należą do opisanych powyżej kategorii. Następnie każdemu z nich przypisuje się stopień złożoności: łatwy, średni lub trudny. Kolejnym krokiem jest przypisanie każdemu elementowi liczby punktów odpowiadających jego kategorii i złożoności. Wartości przedstawia poniższa tabela.

Kategoria Złożoność
niska średnia wysoka
Zewnętrzne typy wejścia 346
Zewnętrzne typy wyjścia 457
Logiczne wewnętrzne typy plików 71015
Zewnętrzne typy interfejsów plików 5710
Zewnętrzne typy zapytań 356

Suma otrzymanych wartości jest równa liczbie punktów funkcyjnych dla analizowanego systemu.

Dzięki stosowaniu tej miary można między innymi:

  • szacować wielkość projektu informatycznego, szacować potrzebne zasoby
  • określać wydajność produkcji oprogramowania – na przykład poprzez mierzenie liczby punktów funkcyjnych wytworzonych podczas tygodnia
  • szacować koszty potrzebne do zmiany wprowadzanej do istniejącego systemu informatycznego
  • porównywać oprogramowanie pod względem wielkości/złożoności.

Przykładowo można szacować, że 1 PF to około 8 godzin pracy w technologii 3GL lub 1,5 godziny w technologii 4GL[4] lub według innych danych – odpowiednio 17 i 11 godzin[5].

Analizę punktów funkcyjnych można również stosować jako metodę ustalania kosztu testowania systemu informatycznego. Według Capersa[6] liczba wymaganych przypadków testowych jest równa sumie punktów funkcyjnych podniesionej do potęgi 1,2.

Wady i krytyka metody

Mimo że metoda jest najbardziej dopracowaną i najpopularniejszą metodą szacowania wartości funkcji ocenianego programu, to nie pozostaje ona bez wad. Jedną z nich, wskazaną już przez Albrechta, jest subiektywność wartościowania złożoności typu jako niskiej, średniej lub dużej. Istotność tej wady obecnie jest niwelowana opracowaną przez IFPUG metodyką oceny złożoności (file type complexity).

Kolejnym problemem jest czasochłonność (koszt) procesu wyliczania punktów funkcyjnych, gdyż z powodu nieznanej dokładności takich wyliczeń, nie jest stosowana automatyzacja tego procesu.

Innym mankamentem jest to, że wyniki metody w przypadku małych systemów mogą być mało dokładne.

Metoda punktów funkcyjnych nie bierze również pod uwagę złożoności implementacji algorytmów działających wewnątrz systemu.

Mark II

Jest to metoda rekomendowana przez CCTA(Central Computer and Telecommunications Agency), która ustala standardy dla projektów rządowych Wielkiej Brytanii. Miała ona być lepszą wersją metody Albrechta. Jednak po udoskonaleniu i znalezieniu wielu nowych rozwiązań w metodzie Albrechta, Mark II pozostał w użyciu jedynie w Wielkiej Brytanii.

Podsumowanie

Metoda punktów funkcyjnych nie jest popularna w Polsce. Jednak na świecie stosowana jest powszechnie- jest metodą sprawdzoną, skuteczną i ciągle rozwijaną. Ułatwia oszacowanie czasu i kosztów potrzebnych do realizacji projektu.

Przypisy

  1. ↑ A. J. Albrecht, Measuring Application Development Productivity, Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14–17, IBM Corporation (1979), s. 83–92.
  2. ↑ Ewa Magiera, “Zastosowanie metody punktów funkcyjnych – wady i zalety”, Uniwersytet Śląski.
  3. ↑ M. Cotterell, B. Hughes, Software Project Management, second edition, McGraw-Hill Publishing Company, 1999.
  4. ↑ Beata Czarnacka-Chrobot, Pomiar rozmiaru funkcjonalnego systemu informatycznego – sposób na „chaos permanens”, PTI, Mrągowo, 2004, dostępne w Internecie, dostęp 2008-06-25, 18:12:12.
  5. ↑ Capers Jones, Programming Languages Table, release 8.2, Software Productivity Research, Inc., 1996.
  6. ↑ Estimating Software Costs – T. Capers Jones.

Linki zewnętrzne

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.