Metoda punktów przypadków użycia

Metoda punktów przypadków użycia (ang. Use Case Points ) w skrócie UCP posiada podobny mechanizm do tego jaki zastosowano w metodzie punktów funkcyjnych (Metoda punktów funkcyjnych), jednak zrezygnowano z wykorzystania ekranów i architektury. Dlaczego pominięto ekrany i architekturę? Otóż wyobraźmy sobie sytuację, w której klient zadaje pytanie o czas realizacji projektu na etapie specyfikowania wymagań. Jak się okazuje w tej sytuacji metoda punktów funkcyjnych jest nieużyteczna, gdyż nie posiadamy jeszcze zdefiniowanej architektury, czy też propozycji ekranów. Należy więc zastanowić się czy wymagania systemu mogą być podstawą do estymacji pracochłonności realizacji systemu informatycznego. Twierdząco na tak postawione pytanie odpowiedział w 1993r. Gustaw Karner – twórca metody punktów przypadków użycia. Wymienił on architekturę i ekrany na specyfikację wymagań zapisaną w postaci specyfikacji przypadków użycia. Ponadto zasugerował, że należy zwrócić uwagę na tak zwane czynniki złożoności środowiska opisujące w dużej mierze organizację, która wytwarza oprogramowanie, czynniki złożoności technicznej opisujące własności produktu oraz przyszłych aktorów systemu.

Klasyfikacja przypadków użycia jest w metodzie UCP jest podstawą estymacji pracochłonności w wytwarzaniu systemów informatycznych. Tu identyfikujemy wszystkie przypadki użycia, a dokładniej mówiąc specyfikacje przypadków użycia, ponieważ do szacowania potrzebny nam będzie opis scenariusza podstawowego i model klas analitycznych (identyfikacja klas zaangażowanych w realizacje danego przypadku użycia). Na tym etapie należy określić poziom złożoności dla każdego przypadku użycia. Metoda wskazuje trzy typy złożoności.

Tabela 1. Klasyfikacja złożoności przypadków użycia

Następnie obliczamy nieskorygowaną wagę przypadków użycia w skrócie oznaczoną UUCW (ang . Unadjusted Use Cases Weight). W tym celu zliczamy liczbę przypadków użycia zakwalifikowanych do każdej ze wskazanych kategorii (prosty, średnio złożony, złożony). Następnie liczbę przypadków użycia w danej kategorii wymnażamy przez wartość wagi dla danej kategorii złożoności przypadku użycia. Wartość nieskorygowanej wagi przypadków użycia stanowić będzie suma wcześniej zdefiniowanych iloczynów po każdej kategorii złożoności przypadku użycia. Podsumowując, formuła obliczania nieskorygowanej wagi przypadków użycia jest następująca:

gdzie: n – liczba przypadków użycia zakwalifikowanych do i-tej kategorii złożoności przypadku użycia, w – wartość wagi dla i-tej kategorii złożoności przypadku użycia.

Czynniki złożoności środowiska (ang. Environmental Complexity Factors ) charakteryzują dostawcę oprogramowania. Metoda wskazuje osiem czynników złożoności środowiska i każdemu z nich przypisuje wagę, która mówi jak bardzo dany czynnik wpływa na ostateczny wynik estymacji. Im waga czynnika jest większa tym czynnik ma większy wpływ na zmniejszenie pracochłonności wytworzenia systemu informatycznego. Warto zwrócić uwagę, że większość czynników posiada dodatnie wagi. Oznacza to, że wzrost ich wpływu redukuje pracochłonność. Z kolei wzrost wpływu czynników z ujemnymi wagami spowoduje zwiększenie wartości estymacji pracochłonności wytworzenia systemu informatycznego.

Tabela 2. Czynniki złożoności środowiska

Przyjrzyjmy się bliżej czynnikom złożoności środowiska:

• E1 – mówi czy zespół jest zna dziedzinę problemu i techniczne aspekty rozwiązania problemu klienta. Zwraca się uwagę na znajomość metodyki w ramach której realizowany jest projekt np. RUP (ang. Rational Unified Process) jak również znajomość języków modelowania systemu np. UML (ang. Unified Modeling Language).
• E2 – ogólnie rozumiane doświadczenie zespołu w wytwarzaniu oprogramowania.
• E3 – doświadczenie w projektowaniu aplikacji zorientowanych obiektowo związane z umiejętnością projektowania aplikacji obiektowych, oraz umiejętność wykorzystania wspierających narzędzi do projektowania systemów informatycznych.
• E4 – określa zdolność analityka do właściwego pozyskiwania wymagań od klienta oraz posiadanie wiedzy z dziedziny rozwiązywanego problemu.
• E5 – ocenia zdolność do zaangażowania się zespołu w powierzone im zadania.
• E6 – definiuje czy wymagania nie są narażone na częste zmiany.
• E7 – określa, czy wśród zespołu znajduje się duża liczba pracowników pracujących w niepełnym wymiarze czasu (np. stażyści, studenci)
• E8 – uściśla jak trudny do opanowania jest język programowania, w którym implementowany będzie przyszły system informatyczny.

W metodzie punktów przypadków użycia wpływ każdego czynnika oceniamy w skali od 0 do 5 (zakres liczb naturalnych), przy czym:

• 0 ? oznacza, że czynnik jest nieistotny dla projektu
• 3 ? oznacza średni wpływ
• 5 ? oznacza silny wpływ

Następnie obliczamy wartość czynnika złożoności środowiska w skrócie oznaczonego ECF (ang. Environmental Complexity Factors) na podstawie następującej formuły:

gdzie: w – wartość wagi i-tego czynnika, impact – ocena wpływu i-tego czynnika.

Czynniki złożoności technicznej (ang. Technical Complexity Factor) charakteryzują przyszły system informatyczny. Metoda definiuje precyzyjnie chce określić specyfikę produktu wskazując trzynaście czynników. Podobnie jak czynniki środowiskowe, każdemu z nich przypisano wagę oddającą stopień w jakim czynnik wpływa na wartość końcowej estymacji. Wzrost wpływu każdego współczynnika złożoności technicznej powoduje zawsze wzrost końcowej wartości szacowanej pracochłonności.

Tabela 3. Czynniki złożoności technicznej

Przyjrzyjmy się również czynnikom złożoności technicznej:

• T1 – mówi czy w systemie wymagane jest rozproszone przetwarzanie danych.
• T2 – określa wydajność systemu , w odniesieniu do czasu reakcji na zdarzenia, przepustowość, itp .
• T3 – definiuje wydajność dla końcowego użytkownika w kontekście jego percepcji.
• T4 – określa czy wymagane są skomplikowane operacje przetwarzania danych, korzystanie z zaawansowanych algorytmów.
• T5 – mówi czy elementy lub kod wytwarzanego systemu, będzie wykorzystywany powtórnie.
• T6 – określa sposób instalacji łatwość i przyjazność instalacji systemu, wskazuje czy wymagany będzie udział specjalistów do instalacji i konfiguracji początkowej ze strony dostawcy oprogramowania.
• T7 – określa dostosowanie interfejsu użytkownika do jego potrzeb, wygodę w korzystaniu oraz łatwość nauczenia się korzystania z systemu.
• T8 – mówi czy aplikacja powinna działać w określonych środowiskach.
• T9 – określa czy system ma być tak konstruowany, by można było go łatwo w przyszłości rozbudowywać.
• T10 – mówi czy w systemie będzie miało miejsce przetwarzanie współbieżne.
• T11 – definiuje czy system będzie wymagał wykorzystania mechanizmów związanych z zabezpieczeniem dostępu do systemu lub danych.
• T12 – określa w jakim stopniu z systemu będą korzystały inne zewnętrzne systemy lub aktorzy.
• T13 – określa potrzebę organizacji szkoleń dla użytkowników.

Analogicznie jak poprzednio wpływ każdego czynnika oceniamy w skali od 0 do 5 (zakres liczb naturalnych), przy czym:

• 0 ? oznacza, że czynnik jest nieistotny dla projektu
• 3 ? oznacza średni wpływ
• 5 ? oznacza silny wpływ

Następnie obliczamy wartość czynnika złożoności technicznej w skrócie oznaczonego TCF (ang. Technical Complexity Factor) na podstawie następującej formuły:

gdzie: w – wartość wagi i-tego czynnika, impact – ocena wpływu i-tego czynnika.

Klasyfikacja aktorów jest kolejnym etapem związanym z estymacją projektu. Tu identyfikujemy wszystkich aktorów, którzy będą wchodzić w interakcję z przyszłym systemem informatycznym. Na tym etapie należy określić poziom złożoności dla każdego typu aktora. Metoda wskazuje trzy typy złożoności.

Tabela 5. Klasyfikacja złożoności aktorów

Następnie obliczamy nieskorygowaną wagę aktorów w skrócie oznaczoną UAW (ang. Unadjusted Actors Weight). W tym celu zliczamy liczbę aktorów zakwalifikowanych do każdej ze wskazanych kategorii (prosty, średnio złożony, złożony). Następnie liczbę aktorów w danej kategorii wymnażamy przez wartość wagi dla danej kategorii. Wartość nieskorygowanej wagi aktorów stanowić będzie suma wcześniej zdefiniowanych iloczynów po każdej kategorii złożoności aktora. Podsumowując, formuła obliczania nieskorygowanej wagi aktorów jest następująca:

gdzie: n – liczba aktorów zakwalifikowanych do i-tej kategorii, w – wartość wagi dla i-tej kategorii.

Działania metody punktów przypadków użycia dobiegają powoli końca. Wyznaczyliśmy już kilka współczynników, przyszedł w końcu czas na wykorzystanie ich wartości. Po obliczeniu nieskorygowanych wag aktorów UAW i nieskorygowanych przypadków użycia UUCW, możemy obliczyć nieskorygowanie punkty przypadków użycia (ang. Unadjusted Use Case Points) w skrócie UUCP, poprzez zwykłe sumowanie dwóch powyższych wartości:

Natomiast interesujące nas szczególnie punkty przypadków użycia UCP wyznaczymy za pomocą formuły, która wykorzystuje wcześniej wyznaczone wartości czynnika złożoności technicznej TCF i czynnika złożoności środowiska ECF:

Ostatnim etapem w metodzie UCP jest przeliczenie punktów przypadków użycia na konkretne wartości pracochłonności liczone w osobogodzinach. Dokonuje się to poprzez pomnożenie UCP przez tak zwany współczynnik produktywności PF (ang. Productivity Factor). Współczynnik produktywności przekształca nam jeden punkt przypadku użycia na ilość godzin pracy człowieka. Historycznie wartość współczynnika PF wahała się od 15 do 30 roboczogodzin na jeden punkt przypadków użycia. Z badań Karnera, twórcy metody, wynika, że realizacja jednego UCP wymaga około 20 roboczogodzin.

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