Metoda punktów funkcyjnych

Początki Use Case Points sięgają innej znanej metody służącej do szacowania rozmiaru oprogramowania, a mianowicie metody punktów funkcyjnych. Metoda ta zaproponowana przez Allana Albrechta (IBM) w 1979 bazowała na projektach ekranów oraz architekturze systemu. Była to próba przezwyciężenia problemów związanych z użyciem liczby linii kodu (która nie jest znana na etapie definicji wymagań a była podstawą do estymacji) jako miary wielkości oprogramowania i jednocześnie próba opracowania metody przewidzenia wysiłku związanego z produkcją oprogramowania. W metodzie tej występowało pięć głównych klas atrybutów produktywności, które charakteryzowały system:

• zewnętrzne wejścia (ang. External Inputs)
• zewnętrzne wyjścia (ang. External Outputs)
• zewnętrzne zapytania (ang. External Inquires)
• pliki wewnętrzne (ang. Internal Logical Files)
• pliki zewnętrzne (ang. External Interface Files)

Dla każdej kategorii zdefiniowane były trzy stopnie złożoności: prosty, średni i złożony. Z kolei z każdym stopniem złożoności były związane ustalone wartości wag.

Tabela 1. Poziomy złożoności elementów przetwarzania

W metodzie punktów funkcyjnych należało zidentyfikować wszystkie wskazane komponenty systemu i zakwalifikować je do jednaj z klas złożoności. Następnie wyliczano globalną wartość nieskorygowanych punktów funkcyjnych wg formuły:

gdzie: NFP – nieskorygowane punkty funkcyjne, w – wartość współczynnika wagi, n – liczna elementów w projekcie, i – numer elementu przetwarzania, j – numer poziomu złożoności.

Następnie przeprowadzało się korekcję wyliczonych wartości punktów funkcyjnych w związku z warunkami realizacji systemu. Określało się uwarunkowania realizacyjne konkretnego systemu, podając wpływ 14 czynników. Każdy z czynników oceniany był w skali od 0 do 5, gdzie 0 oznaczał brak wpływu, a 5 bardzo duży wpływ. Wyróżniano współczynniki korygujące poprzez próbę odpowiedzi na następujące pytania:

1. Czy jest wymagane przesyłanie danych?
2. Czy są funkcje przetwarzania rozproszonego?
3. Czy wydajność ma kluczowe znaczenie?
4. Czy system ma działać w mocno obciążonym środowisku operacyjnym?
5. Czy system wymaga wprowadzania danych on-line?
6. Czy wewnętrzne przetwarzanie jest złożone?
7. Czy kod ma być re-używalny?
8. Czy wejścia, wyjścia, pliki i zapytania są złożone?
9. Czy wprowadzanie danych on-line wymaga transakcji obejmujących wiele ekranów lub operacji?
10. Czy pliki główne są aktualizowane on-line?
11. Czy system ma mieć automatyczne konwersje i instalacje?
12. Czy system wymaga mechanizmu kopii zapasowych i odtwarzania?
13. Czy system jest projektowany dla wielu instalacji w różnych organizacjach?
14. Czy aplikacja jest projektowana, aby wspomagać zmiany i być łatwą w użyciu przez użytkownika?

Następnie należało wyliczyć kompleksowy współczynnik korygujący na podstawie poniższej formuły:

gdzie: FP – kompleksowa wartość skorygowanych punktów funkcyjnych, NFP – nieskorygowana wartość punktów funkcyjnych, k – wartość współczynnika korygującego. Wielkości 0,65 i 0,01 to stałe współczynniki, ustalone na podstawie doświadczeń i badań statystycznych wykonywanych systemów.

Ostatnim krokiem było wyznaczenie pracochłonności, które polegało na odczytaniu wartości pracochłonności w zależności od wyliczonej wartości skorygowanego punktu funkcyjnego FP.

Rysunek 1. Punkty funkcyjne a pracochłonność. Opracowanie na podstawie: (Szyjewski: Zarządzanie projektami informatycznymi. Metodyka tworzenia systemów informatycznych, Wydawnictwo Placet 2001).

Więcej na temat szacowania można znaleźć:

• Metoda punktów funkcyjnych

• Metoda punktów przypadków użycia

• Szacowanie projektu w Enterprise Architect cz. 1

• Szacowanie projektu w Enterprise Architect cz. 2

Reklama