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
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Reklama
MODESTO - licencje Enterprise Architect

Dodawanie komentarzy zostało zablokowane.

Scroll to Top