o modelowaniu procesów i systemów 

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ęść »