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

l.p. (i)

Elementy przetwarzania

Poziom złożoności elementu (j)

prosty

średni

złożony

1

zewnętrzne wejścia

3

4

6

2

zewnętrzne wyjścia

4

5

7

3

pliki wewnętrzne

7

10

15

4

pliki zewnętrzne

5

7

10

5

zewnętrzne zapytania

3

4

6

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:

clip_image002

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:

clip_image004

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.

clip_image006

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źć:

Technorati Tagi: Enterprise Architect,szacowanie oprogramowania,metoda punktów przypadków użycia

Podobne wpisy

  • Szacowanie projektu w Enterprise Architect cz. 1 Warto wiedzieć, że istnieją na rynku narzędzia CASE, które wspierają inżynierów oprogramowania nie tylko w zarządzaniu wymaganiami, modelowaniu, projektowaniu systemów informatycznych, […]
  • Szacowanie projektu w Enterprise Architect cz. 2 W tekście Szacowanie projektu w Enterprise Architect cz. 1 zdefiniowałem czynniki złożoności technicznej i środowiskowej. Teraz należy doprecyzować pozostałe parametry. Po pierwsze […]
  • Enterprise Architect 14 – pierwsze wrażenia Enterprise Architect, jak już wspominałem w kilku poprzednich wpisach, doczekał się wersji 14. Tradycyjnie firma Sparx System dokonała zmiany menu i sposobu nawigacji. Tym razem, w moim […]
  • Enterprise Architect 13 został opublikowany Zgodnie z zapowiedziami Enterprise Architect doczekał się 13 wersji. Sparx Systems dziś opublikował finalną wersję tego popularnego narzędzia. Publiczna kompilacja ma numer […]
  • Wersjonowanie w Enterprise Architect 13 Wersjonowanie w Enterprise Architect 13 zwane Time Aware Modeling (TAM) to jedna z najbardziej znaczących zmian w nowej wersji Enterprise Architect. Wersjonowanie w Enterprise Architect […]
Reklama

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *