Identyfikowanie przypadków użycia poprzez cele użytkowników

Pewien zespół analityczny w ciągu miesiąca musiał zrealizować jeden z etapów projektu polegający na opisie funkcjonalności aplikacji przedsiębiorstwa z użyciem przypadków użycia. Wyniki prac tego etapu były konieczne do realizacji kolejnego etapu projektu. Projekt był realizowany w dużym przedsiębiorstwie państwowym o niepowtarzalnym charakterze działalności w skali kraju. Liczba aplikacji podlegająca opisowi była bardzo duża. Część zespołu analitycznego przed przystąpieniem do prac pracowała już na rzecz tego przedsiębiorstwa, dlatego znana im była działalność przedsiębiorstwa oraz ogólne funkcjonalności aplikacji podlegających opisowi.

Mimo to, miesiąc czasu i nowe zadanie, jakie postawiono przed zespołem wywoływało niepokój zwłaszcza, że do tej pory nikt z członków zespołu nie realizował analizy w kontekście opisu stanu zastanego, w takim rygorze czasowym a przede wszystkim w tak dużej skali.

Krótka charakterystyka przedsięwzięcia przedstawiała się następująco:

• blisko 100 aplikacji w ramach których należało wykonać analizę funkcjonalności systemów,
• funkcjonalności miały być spisane w formie przypadków użycia – bez określenia rozumienia pojęcia przypadku użycia przez klienta i poziomu opisu tych przypadków,
• krótki termin realizacji: miesiąc,
• kilka autonomicznych ale wzajemnie powiązanych obszarów biznesowych,
• zespół 6-osobowy w tym 3. analityków – czyli tylko połowa zespołu miała doświadczenie w realizacji tego typu przedsięwzięć (tj. identyfikowaniu przypadków użycia i pisaniu scenariuszy przypadków użycia),
• prace wykonywane równolegle i indywidualnie przez każdego członka zespołu – ze względu na ograniczenia czasowe brak możliwości organizowania spotkań statusowych,
• analitycy mieli dostęp telefoniczny do ekspertów klienta jak również mogli organizować spotkania z ekspertami,
• analitycy mieli dostęp do dokumentacji części aplikacji,
• analiza funkcjonalności poprzez przypadki użycia miała stanowić podstawę do finalnego opracowania zintegrowanej architektury (SOA) oraz konsolidacji danych (głównym zadaniem była identyfikacja powielających się funkcjonalności oraz wskazanie punktów krytycznych aplikacji – a docelowo ich eliminacja).

Zostałem poproszony o pomoc w wyborze podejścia do realizacji zdania. Od razu odrzuciłem sugestię o konieczności natychmiastowego rozpoczęcia modelowania przypadków w narzędziu do modelowania UML. To co zaproponowałem oparte było na zapewne mniej spektakularnym podejściu a mianowicie prostej tabeli, której wypełnienie za pomocą metody wyszukiwania przypadków poprzez cele dało szybko odpowiedź z jaką skalą problemu mamy do czynienia. Pozwoliło kontrolować odpowiedni poziom opisu oraz zapewniło kierownikowi projektu możliwość nadzoru postępu prac.

Treścią tego artykułu będzie identyfikowanie przypadków użycia poprzez wyszukiwanie celów realizowanych przez użytkowników systemu. W artykule tym nie będę opisywać sposobów opisywania szczegółów przypadków użycia a samo ich identyfikowanie. W celu głębszej analizy tematu zachęcam do zapoznania się według mnie z klasyczną i obowiązkową lekturą na temat analizy przypadków użycia [1].

Zanim przystąpię do opisu napiszę również, że pracę zespołu projektowego udało się wykonać i choć zapewne pewna refaktoryzacja zidentyfikowanych i opisanych przypadków po tak krótkim czasie byłaby wskazana tym nie mniej cel został osiągnięty a klient i zespół analityczny był zadowolony, choć bardzo zmęczony po wykonanej pracy.

Czym jest przypadek użycia?

Według mnie najkrótszą i najwięcej mówiącą definicją przypadku użycia w odniesieniu do warstwy aplikacji jest nazwany zestaw czynności, jaki aktor wykonuje w interakcji z systemem w ramach tzw. jednego posiedzenia (np. podejście do komputera; wykonanie czynności wynikających z celu zadania; odejście od komputera).

Dla przypadku użycia słuszne są stwierdzenia:

• Przypadek użycia inicjowany jest przez aktora.
• Przypadek użycia służy realizacji celu aktora.
• Przypadek użycia realizowany jest na rzecz aktora i w ramach interakcji z aktorem.
• Przypadek użycia kończy rezultatem pozytywnym lub negatywnym – osiągnięcie celu lub brak osiągnięcia postawionego celu.

Podejście, które zostanie wykorzystane do opisu identyfikacji przypadków poprzez cele jest zgodne z tą definicją i według [1] jest to opis na tzw. poziomie morza. Czyli poziomie neutralnym, odnoszącym się do klasycznego rozumienia przypadku użycia. Inne poziomy to poziom chmur czy poziom pod powierzchnią morza. Pierwszy dotyczy długotrwałych operacji realizowanych w interakcji aktor – system,  np. realizacja pełnej obsługi zamówienia, która może rozciągać się na wiele dni i wiele sesji aktora z systemem. Drugi to poziom pod powierzchnią morza (poziom funkcji). Przykładem takich przypadków są funkcje pomocnicze, których istnienie samodzielne nie wnosi wiele do realizacji celu użytkownika, np. uwierzytelnianie (logowanie), czy wyszukanie klienta.

Jak identyfikować przypadki użycia poprzez cele?

Zastosowane w projekcie, o którym napisałem we wstępie, podejście mające zastosowanie ogólne opiera się na wykonaniu następujących czynności:

1. Zidentyfikuj zakres opisywanego systemu.
2. Zidentyfikuj aktorów.
3. Określ cele aktorów względem systemu.
4. Przygotuj szkice przypadków użycia.

Ad 1. Zakres to zasięg opisu systemu. Najczęściej będzie to jedna aplikacja. Mogą to być jednak dwie i więcej aplikacji. W zakresie systemu mogą być również ludzie pracujący w obszarze tego systemu. Precyzyjne określenie granic systemu (zakresu) jest kluczem do poprawnej identyfikacji przypadków użycia.

Dwa zakresy zasięgu opisu przedstawia rysunek – zakresem opisu objęta jest Aplikacja 1 a w drugim przypadku zakresem objęta jest Aplikacja 1 i Aplikacja 2, jak również wszystko, co dotyczy wymiany informacji pomiędzy tymi aplikacjami.

Rysunek 1 Rozmiary zakresów opisu systemu