Punkty funkcyjne COSMIC – mniej popularna metryka

Truizmem jest stwierdzenie, że znaczna część projektów IT realizowana jest w metodykach zwinnych, a dominującą w nich miarą estymacji są tzw. Story Pointy – czyli, punkty przypisywane Historyjkom Użytkownika 🙂 Choć to podejście jest powszechne i mocno ugruntowane, warto od czasu do czasu spojrzeć szerzej i poznać także inne metryki stosowane do estymacji pracochłonności wymagań. Często stanowią one ciekawe źródło inspiracji lub punkt odniesienia, nawet jeśli nie są stosowane wprost. Warto zatem poznać punkty funkcyjne COSMIC.

Punkty funkcyjne – co to takiego?

Jednym z popularnych sposobów szacowania złożoności oprogramowania są punkty funkcyjne (ang. Function Points). W uproszczeniu jest to metryka, która pozwala określić rozmiar systemu na podstawie wymagań funkcjonalnych i wynikających z nich operacji na danych. Zgodnie z międzynarodową normą ISO/IEC 14143-1 oraz podejściem rozwijanym przez organizację COSMIC, tzw. rozmiar funkcyjny wynika bezpośrednio z kwantyfikacji funkcjonalnych wymagań użytkownika. W metodzie COSMIC jest on wyrażany w jednostkach CFP (COSMIC Function Points). Każdy CFP odpowiada pojedynczej operacji na danych (ang. data mement) w systemie. Może to być:

  • wprowadzenie danych do procesu (ang. Entry)
  • odczyt danych z procesu (ang. Exit)
  • zapis danych (ang. Write)
  • odczyt danych (ang. Read)

Aby obliczyć rozmiar funkcyjny oprogramowania w COSMIC należy zatem dokładnie przeanalizować wymagania funkcjonalne i określić ile operacji na danych o wymienionych wyżej typach, jest niezbędnych w celu zrealizowania tychże wymagań. Co ważne, pod uwagę brane są grupy danych, a nie pojedyncze dane. Zatem jeśli cały formularz jest zapisywany jednorazowo, traktuje się to jako jeden ruch danych, liczony jako 1 CFP, mimo że może on składać się z wielu pojedynczych pól.

Bardzo podobną koncepcję przedstawia metoda punktów funkcyjnych rozwijana przez organizację IFPUG (International Function Point Users Group). W obu przypadkach kluczowe jest jedno założenie: liczy się to, co system robi z danymi, a nie to, jak jest zaimplementowany.

Zalety punktów funkcyjnych

Dużą zaletą punktów funkcyjnych jest ich niezależność od technologii. Dzięki temu można porównywać rozmiar systemów napisanych w różnych językach, opartych na różnych architekturach czy frameworkach. Co więcej, estymacja opiera się na jasno zdefiniowanych zasadach, co zwiększa jej obiektywność oraz powtarzalność.

Wady punktów funkcyjnych

Punkty funkcyjne nie uwzględniają złożoności algorytmów ani logiki biznesowej. Skupiają się wyłącznie na operacjach na danych, przez co mogą nie oddawać rzeczywistego nakładu pracy niezbędnego do zrealizowania systemów o nietypowej logice, intensywnym przetwarzaniu danych czy zaawansowanych obliczeniach. W takich przypadkach estymacje oparte wyłącznie na FP mogą być po zwyczajnie błędne.

Kolejnym problemem jest pracochłonność samej estymacji. Rzetelne wyznaczenie punktów funkcyjnych wymaga szczegółowej analizy wszystkich wymagań funkcjonalnych i wynikających z nich operacji na danych. Oznacza to, iż obliczenie rozmiaru funkcyjnego możliwe jest dopiero gdy znane i udokumentowane są szczegółowe wymagania. Do tego dochodzi konieczność posiadania specjalistycznej wiedzy i doświadczenia, co często oznacza zaangażowanie dodatkowych specjalistów. Z tego powodu punkty funkcyjne bywają trudne do zastosowania w projektach realizowanych w metodykach zwinnych. Istotna jest w nich szybka, iteracyjna estymacja, często na podstawie wymagań o niskim stopniu szczegółowości. Co więcej, w tego rodzaju podejściach dokumentacja jest celowo utrzymywana na minimalnym poziomie, co zwykle wyklucza możliwość dokładnego określenia wszystkich operacji na danych.

Gdzie wykorzystywane są punkty funkcyjne COSMIC?

Punkty funkcyjne COSMIC wykorzystuje się zwykle w projektach o wysokim stopniu formalizacji. W Polsce znajdują zastosowanie gównie w projektach realizowanych dla administracji publicznej.

Źródła

A. J. Albrecht, “Measuring application development productivity,” in Proceedings of the IBM Applications Development Symposium, Monterey, CA, USA, 1979.

[31] ISO/IEC 14143-1:2007 – Information technology — Software measurement — Functional size measurement — Part 1: Definition of concepts, International Organization for Standardization, Geneva, Switzerland, 2007.

Radek Grębski

Analityk biznesowy, Product Owner, trener