Cel analizy

Celem analizy funkcjonalnej jest ustalenie wymagań wobec projektowanego systemu oraz przełożenie tych wymagań na jego funkcje.

Pracę tą wykonujemy, korzystając z wcześniejszych ustaleń, wykonanych w trakcie analizy merytorycznej i zawartych we wstępnym projekcie.

Odnosząc się do metod zarządzania projektami, należy uznać, że analiza funkcjonalna rozpoczyna się od ustalenia zakresu projektu, następnie dokonujemy analizy interesariuszy i przechodzimy do ustalenia szczegółowych celów projektu.

Wśród interesariuszy należy wyróżnić aktorów, którzy będą użytkownikami tworzonego systemu. Pojęcie „aktor” ma tu jednak szersze znaczenie, gdyż obejmuje także poza-osobowe elementy systemu (moduły, programy).

Posiadając informacje o aktorach i celach, jakie im przyświecają, możemy dokonać analizy oczekiwanych funkcji.

Analiza

Zakres

Zgodnie z propozycją Cockburna [1], zakres projektu możemy ustalić poprzez stworzenie wykazu tematów (funkcji), jakie zidentyfikowaliśmy w trakcie analizy i podjęcie decyzji, które z nich zostaną ujęte w analizowanym systemie.

Tworzy się w ten sposób tabelkę opisującą zakres funkcjonalny systemu jako zestawienie w/poza:

Lp

Temat

W

POZA

Zagadnienie 1

1-1

Temat 1

X

1-2

Temat 2

X

1-3

Temat 3

X

Zagadnienie 2

2-1

...

Tabela 1. Lista W/POZA

Interesariusze

Aktorzy

Do celów analizy funkcjonalnej musimy ustalić interesariuszy, którzy będą aktywnie uczestniczyć w działaniu systemu. Nazywa się ich aktorami. Aktorów możemy zestawić w tabeli, opisującej także kluczowe potrzeby, jakie system powinien uwzględnić.

Aktor

Kluczowe potrzeby

Aktor1

Opis potrzeb ….

...

...

Tabela 2. Główni aktorzy

Pozostali interesariusze

Analiza pozostałych interesariuszy nie ma znaczenia dla samego docelowego projektu, ale jest ważnym elementem zarządzania projektami, który może decydować o jego sukcesie. Analiza taka obejmuje informacje, jakie będzie oddziaływanie projektu na interesariuszy, jaki oni mają wpływ na projekt i jaką wobec nich podjąć strategię. Na przykład zarząd firmy może nie korzystać bezpośrednio z projektowanego systemu, ale ma nań decydujący wpływ (finansowanie) i będą go dotyczyć uzyskiwane efekty. Dlatego należy przyjąć strategię polegającą na informowaniu o oczekiwanych efektach i postępach prac.

Interesariusz

Oddziaływanie projektu

Wpływ na projekt

Strategia

Tabela 3. Analiza interesariuszy

Cele szczegółowe

Główny cel postawiony przed systemem musimy poprzez analizę rozbić na cele szczegółowe, które dotyczą poszczególnych aktorów. Znów można zaproponować tabelę zawierającą listę aktor – cel:

Lp

Główny aktor

Cel

Priorytet

1

Aktor 1

Cel 1

wysoki

2

...

.

Tabela 4. Lista cel – aktor (do uzupełnienia)

Przypadki użycia (use cases)

Przypadki użycia to opisy w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu. Opis ten nie zawiera szczegółów dotyczących implementacji oraz interfejsu użytkownika.

Pomimo tego, że przypadki użycia są stosunkowo prostym narzędziem analizy systemów, istnieje wokół nich wiele kontrowersji. W niniejszym opracowaniu wykorzystano podejście Alistaira Cockburna opisane w pracy Writing Effective Use Cases(polskie tłumaczenie „Jak pisać efektywne przypadki użycia” wydało PWN [1]).

Jednak słuszną wydaje się krytyka Jarosława Żelińskiego, który zarzuca Cokburnowi zbytnie komplikowanie prostego zagadnienia. Podejście jakie tutaj zastosujemy jest czysto pragmatyczne. Wybrane zostaną z propozycji Cokburna te elementy, które ułatwiają osiągnięcie zapisanego na początku celu. Jako nieporozumienie można traktować w związku z tym opisywanie przypadków użycia jako alternatywy dla procesów biznesowych (zob. Łukasz Olek, „Wykorzystanie przypadków użycia do opisywania procesów biznesowych”).

Cockburn proponuje określenie dla każdego przypadku użycia, jaki jest jego zakres i poziom:

zakres

ang.

gospodarczy - opis zewnętrzny

enterprise

gospodarczy - szczegóły

system

systemowy - opis zewnętrzny

subsystem

systemowy - szczegóły

subsystem

komponentowy

component

Tabela 5. Oznaczenia zakresu projektowego

opis ogólny

very high summary

poziom streszczenia

summary

poziom użytkownika (niebieski)

user-goal

podfunkcje

subfunction

poziom najniższy

too low

Tabela 6. Oznaczenie nazwanych poziomów

Cele wyższego poziomu skupiają się na pytaniu: dlaczego; poziom niższy – jak.

Pomimo kontrowersji wokół potrzeby takiego szczegółowego rozróżnienia, nie sądzę, aby jego stosowanie prowadziło do zaciemnienia projektu, a niekiedy może być przydatne. Dlatego można to traktować jako opcjonalny element analizy (dodatkowe objaśnienie).

Szkice przypadków użycia

Tworzenie przypadków użycia rozpoczynamy od ich zestawienia zawierającego aktora głównego oraz szkic (będący po prostu prostym opisem w języku potocznym celu i sposobu, w jaki ten cel będzie osiągany). Możemy takie zestawienie ująć w tabeli:

ID

zakres

poziom

Aktor główny

Szkic

...

...

Tabela 7. Szkice przypadków użycia (do uzupełnienia)

Przypadki użycia

Przypadki użycia należy opisywać w postaci tekstowej, traktując schematy (UML) jako poglądową ilustrację. Zgodnie z propozycją Cockburna, przypadek użycia powinien mieć następującą strukturę:

Cel w kontekście:

Minimalna gwarancja: (co zostaje zrealizowane na pewno)

Główny scenariusz powodzenia: (jak to zostanie zrealizowane)

Rozszerzenia: (dodatkowe/alternatywne działania, wyjątki)

Warunki rozszerzeń

Obsługa rozszerzeń

1

Ponieważ niniejszy tekst zostanie zilustrowany praktycznym przypadkiem analizy, poprzestańmy tutaj na takim pobieżnym opisie.

Literatura:

[1] Alistair Cockburn „Jak pisać efektywne przypadki użycia”, WNT 2004 ( Alistair Cockburn: WRITING EFFECTIVE USE CASES Adres URL)

[2] "Identifying and Analyzing Stakeholders and Their Interests"

Ostatnia modyfikacja: sobota, 19 stycznia 2013, 06:11