o modelowaniu procesów i systemów 

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

User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie

Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel].

W ten sam sposób można pisać scenariusze przypadków użycia, przy których należy uwzględnić, że scenariusz może obejmować kilka user story. Takie podejście pozwala także na zastosowanie modelowania w języku UML w SCRUM i tym samym wpisuje sie w nurt agile modeling – zwinnego modelowania.

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.

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.

Zwinne modelowanie polega miedzy innymi na tym, że budowana dokumentacja do projektu nie jest nadwymiarowa. Innymi słowy jest jej tyle ile potrzeba i nie mniej ani nie więcej. Jak na tym zapanować. Ja osobiście lubię stosować scenariusze (w SCRUM opowiadania klienta), które pozwalają mi na zbudowanie zwinnych przypadków użycia. Natomiast przypadki użycia pomagają mi efektywnie:

• planować iteracje
• szacować złożoność projektu
• komunikować się z klientem
• weryfikować wymagania klienta
• planować testy
• lepiej integrować systemy

Czym jest więc przypadek użycia? W moim rozumieniu przypadek użycia to agregat scenariuszy dostarczający konkretnych wartości. Dlatego też w moich modelach scenariusze odgrywają ważną rolę, a modele opierają się o przypadki użycia.

Wikipedii nikomu nie trzeba przedstawiać. Pewną ciekawostką, zwłaszcza dla zwolenników BMPN, jest wpis dot. modelowania procesów biznesowych. Pod hasłem Business Process Modeling w rozdziale Modeling and simulation można przeczytać, że diagramami do modelowania procesów biznesowych są: diagram przypadków użycia i diagram aktywności (dowód na rysunku poniżej)

Na szczęści twórca tego wpisu nie zapomniał o technikach modelowania procesów biznesowych, gdzie można znaleźć pozostałe diagramy

Od kilku dni jest dostępne wiosenne wydanie The Rational Edge.

http://www.ibm.com/developerworks/rational/rationaledge/?S_TACT=105AGX15&S_CMP=EDGE

Jak zwykle garść dość ciekawych artykułów. Tym razem wydanie zostało poświęcone szacowaniu projektów. Wskazuje na to artykuł Colin O’Neill’a, w którym można znaleźć kompletne wzory i techniki pozwalające wyliczyć ROI projektu oraz (bardziej mnie) interesujący tekst dotyczący szacowania złożoności oprogramowania w oparciu o punkty funkcyjne. Wyliczanie złożoności i kosztów w oparciu o punkty funkcyjne jest o tyle istotne, że ROI jest złudne, o czym warto pamiętać. Ponadto czasem buduje się soft z ROI bliskim zera lub ujemnym co wynika np.: z wymogów prawa. Natomiast szacowanie oprogramowania w oparciu o punkty funkcyjne przypadków użycia pozwala na oszacowania nie tylko kosztów ale także złożoności. Może to być także klucz do planu iteracji. Po trzecie ja ten artykuł zaciekawił mnie szczególnie bo sam używam tej metody.

Nie mniej jednak oba teksty będą na pewno przydatne wszystkim osobom, które w “jakiś magiczny sposób” muszą oszacować oprogramowanie pod względem opłacalności.

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.

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