o modelowaniu procesów i systemów 

MANEA jest to dodatek (plugin) do MANTIS BUG TRUCKER, który pozwala na dwukierunkową synchronizację wybranych wpisów z systemu MANTIS BT z repozytorium wymagań znajdujących się w Enterprise Architect firmy Sparx.

MANEA cechy:

• mapowanie, za pomocą Enterprise Architecta, wpisów i zgłoszeń na konkretne artefakty modelu aplikacji
• prowadzenie w systemie MANTIS dyskusji nad wymaganiami zapisanymi w Enterprise Architect
• umożliwienie szerokiemu gronu osób zgłaszania propozycji wymagań – tylko administrator wstawiając odpowiedni wskaźnik – tag EA-MANTIS może zezwolić na integracje wpisu z Enterprise Architectem
• możliwość zarządzania zgłoszeniami o błędach w oparciu o model wykonany w języku uml
• łatwość instalacji w systemie MANTIS gdyż MANEA to standardowy plugin,
• wsparcie dla repozytoriów błędów i modeli gromadzonych za pomocą bazy danych mysql

Wersja demo jest do pobrania ze strony www.manea.info

Wybór narzędzia CASE wspomagającego proces akwizycji i zarządzania wymaganiami jest trudny. Poniżej zamieszczam link do zestawienia cech wybranych narzędzi.

Zestawienie to jest tłumaczeniem badań jakie zostały opublikowane przez The International Council on Systems Engineering (INCOSE). Na stronach tej organizacji można znaleźć oryginał z bogatszą listą produktów.

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą diagramów WPA (Wysokiego Poziomu Abstrakcji)

Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu.

Co pewien czas warto także dokonywać refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.

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.

?Złote reguły? to nic innego jak wykaz punktów, które zazwyczaj kontroluję podczas tworzenia przypadków użycia. Gdy mam już narysowany przypadek użycia sprawdzam czy:

• przypadek użycia zapewnia wartość aktorom,
• krótki opis zwięźle opisuje cel przypadku użycia,
• przypadek użycia jest kompletny i sensowny,
• wydarzenie rozpoczynające przypadek użycia jest jasne,
• sposób i czas zakończenia przypadku użycia jest jasny,
• stosowana terminologia jest jasna, a istotne terminy zdefiniowane w słowniczku lub podobnym,
• rozpoczęcie i zakończenie przepływu alternatywnego
  jest jasne a każdy przepływ alternatywny posiada jasne
  odniesienie do sposobu, w jaki się zaczyna i dokąd zawrócona jest kontrola po tym jak zostanie wykonany,
• przypadek użycia jest możliwy do zweryfikowania,
• wszystkie kroki są indywidualnie ponumerowane,
• aby uprościć długie i złożone przepływy zdarzeń, wykorzystywane są podprzepływy w postaci dekompozycji aktywności

Powyższy dekalog sprawdzanych parametrów pozwala na utrzymywanie w repozytorium projektu w miarę sensownych przypadków użycia.

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 sieci pojawił się nowy blog o wymaganiach (http://owymaganiach.pl/). Cieszy mnie ta inicjatywa, Pana Jakuba Jurkiewicza – doktoranta na Politechnice Poznańskiej, gdyż w sieci jest mało zasobów na temat inżynierii oprogramowania a te zapowiadają się sensownie.    Z pierwszych wpisów polecam teksty o przypadkach użycia. Powodzenia

W Enterprise Architect jest dedykowany do gromadzenia wymagań element zwany ?Requirement?

Jest to bardzo komfortowa sytuacja, ale co zrobić gdy nie ma takiego elementu w danym narzędziu CASE?

przeczytaj pozostałą część »

Kilka porad odnośnie przypadków użycia i aktorów.

Przypadek użycia nie dostarcza funkcjonalności aktorowi

Problem: Często oznacza to, że każdy przypadek użycia sam w sobie nie dostarcza wartości aktorowi.

Rada: Proszę połączyć fragmentaryczne przypadki użycia w kompletną sekwencję takich fragmentów, które łącznie zapewnią wartość aktorom.

Stanowiska pracy jako aktorzy

Problem: Powszechnym błędem jest tworzenie aktorów, którzy odzwierciedlają stanowiska pracy organizacji. Tworząc aktorów, którzy odzwierciedlają stanowiska pracy przypadki użycia będą kształtowane, aby wspomagać stanowiska pracy a nie pracę, którą mają wykonać jednostki.

Rada: Jeżeli aktorzy odzwierciedlają stanowiska pracy, proszę zmodyfikować aktorów, aby dostosować ich do czynności, które mają wykonać w pracy.

Urządzenia jako aktorzy

Problem: Proste urządzenia, takie jak skanery i drukarki nie pomagają zbytnio w identyfikacji przynoszących wartość przypadków użycia. Aktorzy, których należy szukać, są to ludzie oraz inne systemy, które współdziałają z systemem.

Rada: Jeżeli aktorów określono dla urządzeń, trzeba odszukać osobę, która "stoi za" urządzeniem i zasugerować ją jako aktora.

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.

Każdemu zalecam stosowanie przypadków użycia ? także a może przede wszystkim w projektach Agile.

Poniżej zamieszczam trzy podstawowe zalety, które myślę, że przekonają do używania przypadków użycia w projektach Agile

1. Dzięki przypadkom użycia zyskuje się kontekst

Nawet w projektach Agile przypadki użycia są mechanizmem umożliwiającym firmom osiąganie celów. Podejście, które wykorzystuje ustrukturyzowane wymagania dostarcza ten kontekst. Innymi słowy przypadki użycia pozwalają określić z jakimi systemami lub innymi zasobami będzie współpracował nasz system.

2. Dzięki przypadkom użycia zyskuje się informacje dot. zakresu projektu

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

Ustalanie zakresu polega przede wszystkim na ustalaniu priorytetów celów osób zamawiających produkt oraz ustaleniu ram czasowych i harmonogramów dostarczania.

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

3. Dzięki przypadkom użycia zyskuje się naturalną dekompozycję

Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody Agile to zacząć od definicji zakresu. Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane do harmonogramu projektu. Dokonujesz także refaktoryzacji przypadków użycia, w miarę potrzeb konsolidując i definiując podrzędne przypadki użycia, oraz definiując, jeśli zachodzi taka potrzeba, rozszerzeń przypadków użycia.

Obecnie znajdujemy się w dziwnej sytuacji ? są user stores (zwane w języku polskim historyjkami użytkownika) i scenariusze przypadków użycia z czego te ostatnie można podzielić na przypadki użycia formalne i nieformalne a także streszczenia przypadków użycia. Czym one się różnią, a w czym są takie same?

Przypadki użycia, scenariusze przypadków użycia i user stories dokumentują opis tego jak produkt ma być używany. Różnią się one, w kontinuum, pod względem ilości dodatkowych danych wymaganych dla stworzenia każdego z nich.

• Formalne przypadki użycia wymagają najwięcej wysiłku. Panuje w nich przepych i wiele się w nich dzieje, ale opisują wszelkie kombinacje tego, jak różne osoby wykonują tą samą czynność (lub jej odmianę).
• Nieformalne przypadki użycia są mniej więcej takie same- tyle tylko, że są mniej formalne. Wyzwaniem jest dostarczenie odpowiedniego poziomu szczegółowości, bez elementów prowadzących formalnych przypadków użycia, które mają służyć jako przypomnienie.
• Streszczenia przypadków użycia niemalże nie mają dodatkowych danych, ale zawierają takie sama wyzwania ?na ile jest to jest wystarczająco? co nieformalne przypadki użycia, tyle że w większym stopniu.
• User stories mają najmniej dodatkowych danych i dostarczają najmniejszy kontekst.

Scenariusze przypadków użycia to nieco inny przypadek. Podobnie jak user story, scenariusz przypadku użycia opisuje jedną ścieżkę przez wielościeżkowy przypadek użycia. Warto więc połączyć słabość przypadku użycia (wysoka ilość danych dodatkowych) ze słabością user story (ograniczony kontekst) co w konsekwencji da dość spójny i zwinny oraz pomocny artefakt.