o modelowaniu procesów i systemów 

Wiele mówi się o tym co dają przypadki użycia dla wymagań na system. Warto jest tez wiedzieć iż przypadki użycia pozwalają, zwłaszcza w projektach agile, na określenie celu  i zakresu projektu.

Zasadniczo bez przypadków użycia:

1. Projektanci nie mają pojęcia, jaki cel ma użytkownik.
2. Zespół nie zostaje poinformowany odpowiednio wcześnie o zakresie projektu.
3. Różne zachowania użytkowników nie są zdefiniowane przed zobowiązaniem do dostarczenia.

Zastosowanie przypadków użycia pozwala na zapanowanie na tymi ?bolączkami? po przez określenie kontekstu i zakresu.

Kontekst

Nawet w projektach agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Cele te widać w każdym ustrukturyzowanym podejściu.  Takim podejściem, są przepadki użycia, które dostarczają także kontekst ? czyli cel determinujący powstanie aplikacji.

Zasada jest taką, że każdy cel ma przypisany minimum jeden przypadek użycia. W ten oto sposób można się odnieść do tych celów za pomocą scenariuszy i/lub user stories.

Zakres

Z politycznego punktu widzenia największym problemem z uruchomieniem projektu agile w organizacjach typu waterfall są niewłaściwe ustalenie oczekiwań. Ustalenie oczekiwań i w ten sposób zabezpieczenie zarówno finansowania jak i wsparcia dla projektu może być ważniejsze niż samo wykonanie.

Aby ustalić, jakie są oczekiwania trzeba koniecznie zidentyfikować zakres projektu. Ustalanie zakresu polega ogólnie na zarządzaniu stronami zainteresowanymi oraz ustalaniu priorytetów celów osób zainteresowanych.

Kluczem jest tutaj dokonanie wpierw przeglądu zakresu, a potem jego dokładne zrozumienie poprzez przeprowadzanie iteracji.

Specyfikacja wymagań na system to trudny moment przede wszystkim dla osób, które muszą je wyspecyfikować. Nie zawsze wiadomo w jaki sposób narzędzia informatyki będą mogły pomóc. Często mówimy tylko o funkcjonalności i o tym w jaki sposób system ma realizować procesy biznesowe.  Powstaje pytanie jak skutecznie uzupełnić wymagania także o takie szczegóły jak rozmieszczenie przycisków, format raportu, pola edycji systemu. Po prostu ludziom trudno jest stworzyć krok po kroku opis systemu, którego nigdy nie widzieli. Z tego też powodu jestem zwolennikiem by przypadki użycia wraz z diagramem klas i aktywności opowiadały o systemie skupiając się przede wszystkim  na jego funkcjach.

Do uszczegółowienia wielu  aspektów system, które do specyfikacji są żmudne i czasochłonne polecam prototyp.

Wytworzenie wczesnego prototypu opartego o przypadki użycia może powołać system do życia, co sprawia, że znacznie łatwiej jest gromadzić informacje zwrotne wymagane do ukończenia specyfikacji przypadków użycia. Takie podejście powoduje iż dokumentacja w UML nie jest zbyt złożona co wpisuje się nurt zwinnego modelowania.

W trakcie szkicowania procesów biznesowych należy zdefiniować wspólne słownictwo, przy użyciu najpopularniejszych terminów i wyrażeń w zakresie problemu. Następnie należy konsekwentnie wykorzystywać wspólne słownictwo we wszystkich tekstowych opisach biznesu. W ten sposób, utrzymują Państwo spójne opisy tekstowe i unika się nieporozumień wśród członków projektu dot. stosowania i znaczenia terminów. Słownictwo powinno mieć formę słownika.

Aby znaleźć wspólne terminy w zakresie problemu, należy uwzględnić terminy stosowane w trakcie rozmowy, o co chodzi w biznesie. Warto skupić się na terminach opisujących następujące koncepcje:

• Obiekty biznesowe reprezentujące koncepcje stosowane w codziennej pracy organizacji. W wielu przypadkach, już istnieje wykaz tego rodzaju koncepcji.
• Obiekty świata rzeczywistego, których istnienia przedsiębiorstwo musi być świadome. Te obiekty występują w naturalny sposób i obejmują takie rzeczy jak: samochód, psa, butelkę, samolot, pasażera, rezerwację, bądź fakturę.

Każdym termin jest na ogół opisywany jako rzeczownik wraz z definicją. Terminy powinny być podane w liczbie pojedynczej, "zamówienie" oraz "zadanie", a nie "zamówienia" czy "zadania".

I na koniec oczywiste i najważniejsze: wszystkie zainteresowane strony powinny porozumieć się co do zdefiniowania terminów.

W zeszłym tygodniu na jednym ze spotkań dotyczącego projektu o dość sporej wartości dostałem pytanie: Dlaczego do większych projektów do zarządzania wymaganiami rekomenduję IBM Rational RequisitePro? Oponent argumentował, że to drogi produkt a wejście w niego ?spycha? w dość kosztowną platformę Rational. Pozornie miał rację. Otóż w przypadku małych firm i niewielkich projektów wystarczą narzędzia konkrecyjne takiej jak choćby plug-in do jednego z najbardziej popularnych narzędzi CASE Enterprise Architecta o nazwie RaQuest. Niestety wydajność i możliwości wspomnianego tandemu (EA i RaQuest) są dość ograniczone (co wiem z praktyki).

Osobiście lubię stosować RequistePro zwłaszcza przy większych projektach gdyż pozwala on na :

• zbieranie wymagań w Word, szybką ich akwizycję w repozytorium opartym na bazie danych (wizardy, pełna integracja z Word),
• możliwość pracy grupowej dzięki składowaniu wymagań w bazie danych (IBM DB2, Oracle, MS SQL Server),
• nadawanie priorytetów i powiązań pomiędzy wymaganiami,
• nadawanie atrybutów takich jak priorytet, status, stopień trudności, odpowiedzialność,
• poprawienie wymagań w Word (nawet przez osoby, które nie mają zainstalowanego narzędzia), które wymusza  podczas synchronizacji wymagań (już na jednoste z dostępem do RequistePro) do obligatoryjnego wersjonowania zmian,
• filtrowanie, sortowanie i porządkowanie wymagań,
• pełną integrację z narzędziami do modelowania (np.: Rational Software Modeler, Rational Software Architect) bez konieczności przełączania się pomiędzy narzędziami,
• szybkie i wydajne raportowanie (czasem z potrzebne jest narzędzie do raportowania: Rational SODA),
• zarządzanie wymaganiami także za pomocą interfejsu WWW (łącznie z raportowaniem),
• integrację z ClearQuest co pozwala na jeszcze bardzie skuteczne wersjonowanie wymagań (także tych które powinny znaleźć się w kolejnej wersji produktu) – co jest istotne z punktu widzenia kierowników projektu
• integrację z narzędziami do testowania takimi jak Rational TestManager – co jest istotne z punktu widzenia testerów
• i chyba jedno z ważniejszych: wsparcie techniczne i merytoryczne IBM lub jej partnerów ? co pozwala zaoszczędzić czas

Oczywiście narzędzie może nie jest tanie, ale daje tyle wartości dodanej i pomaga uniknąć tylu trudności, że wydane pieniądze zwracają się wielokrotnie. Zdaje się, że wyszła mi przesłodzona laurka. Na szczęście dla mnie to prawdziwe cechy aplikacji (sprawdzone osobiście w projektach). Jeśli ktoś chciałby się przekonać w praktyce ?na własne oczy? proszę o kontakt ? mogę zrobić prezentację możliwości narzędzia lub szkolenie.

Na jednym ze spotkań z klientem otrzymałem pytanie: Czy przypadki użycia są jedyną formą specyfikacji systemu? Moja odpowiedź była jasna: NIE. Przypadki użycia są niewątpliwie pożyteczne dla specyfikowania systemów, ale nie pozwalają w pełni opisać wymagań. Przypadki użycia stanowią swoiste agregaty dla wymagań, pozwalają dokonać pewnej dekompozycji wymagań na poszczególne funkcje systemu. Niestety ich rola jest ograniczona wskazania roli jakie podejmą aktorzy w systemie a przecież bardzo często  wymagania pochodzą od ludzi, którzy nie zbliżą się do granic systemu. Co więcej wymagania poza funkcjonalnością obejmują aspekty techniczne (np.: interfejsy). Z moich doświadczeń wynika, że często aby w pełni wyspecyfikować funkcjonalność systemu trzeba poznać proces biznesowy czyli zbudować model biznesowych przypadków użycia za pomocą techniki odmiennej, ale zgodnej z modelem przypadków użycia. Oznacza to, że poza modelem przypadków użycia powstają inne artefakty (dokumenty) przede wszystkim takie jak wspomniany model lub inna dokumentacja procesów biznesowych oraz obligatoryjnie specyfikacja wymagań funkcjonalnych i niefunkcjonalnych.

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold opisuje nowe cechy  IBM Rational Software Architect for WebSphere Software 7.5, dotyczące modelowania i transformacji http://www.ibm.com/developerworks/rational/library/08/0926_arnold/index.html.

Natomiast mi, być może z uwagi na specyfikę projektu, którym się teraz zajmuje, najbardziej podobał się artykuł pt. „Handling Requirements Effectively on Agile Projects” (http://www.ibm.com/developerworks/rational/library/edge/08/oct08/rivera1/index.html), w którym można  przeczytać o tym jak efektywnie zarządzać wymaganiami w projektach bazujących na Agile. Zapraszam do lektury.

Jakiś czas temu napotkałem ciekawe wyniki badań, które zostały opracowane w Polsce. Instytut Informatyki Politechniki Poznańskiej wykonał badania, w których  celem było znalezienie odpowiedzi na pytanie: jaka reprezentacja wymagań: tekstowa, czy graficzna, jest lepsza z punktu widzenia stopnia zrozumienia przez osoby je czytające?
Jako reprezentanta podejścia tekstowego wybrano przypadki użycia. Natomiast dla notacji graficznej wybrano zapis BPMN,  który przypomina UML, lecz jest tworzony z zamiarem opisu modeli biznesowych. Uczestnikami eksperymentu byli studenci 4-tego roku Inżynierii Oprogramowania oraz Gospodarki Elektronicznej.

przeczytaj pozostałą część »