Przypadki użycia – przykład

 

W jednym ze wcześniejszych wpisów 1, przedstawiłem moje uwagi dt. przypadków użycia. Na końcu obiecałem, że dodam jeszcze trochę praktycznych przykładów. I właśnie tym chciałbym się dziś zająć. Chciałem, aby przedstawione przykłady były „wzięte z życia”, dlatego są oparte na pewnym projekcie, który realizowałem. Przedstawię w skrócie problem, tak aby można było uchwycić o co w nim chodzi, a jednocześnie opis nie był zbyt angażujący. W oparciu o te informacje, przeprowadzę skróconą wersję analizy wymagań, efektem której będzie przypadek użycia, zapisany w formie szkicu Czytaj dalej Przypadki użycia – przykład

  1. Poniższy wpis przeleżał dłuższy czas w poczekalni na ostateczny szlif, dlatego pojawia się dopiero teraz. Spodziewajcie się dalszych wpisów wyciągniętych z archiwum. Trochę się tego zebrało.

Lista życzeń

Projekty informatyczne, przynajmniej te prowadzone w naszym kraju, cierpią często na trudną przypadłość którą określam jako „lista życzeń”. Dotyczy to przede wszystkim projektów, które mają być realizowane przez zewnętrznych dostawców a przez to muszą mieć zdefiniowany w sposób formalny zakres. W założeniu – tego typu oficjalny opis powinien definiować przedmiot zamówienia w sposób ścisły i na tyle szczegółowy, że możliwe będzie oszacowanie pracochłonności i kosztów. To w teorii. Niestety w praktyce, często tego rodzaju dokumenty pt. Opis Przedmiotu Zamówienia nie są zbyt szczegółowe, a nawet więcej – ich forma i treść są problematyczne.

Czytaj dalej Lista życzeń

Ilustrowana instrukcja oddychania w 10 krokach

Znacie to? Dostajecie do zapoznania się Bardzo Ważną Dokumentację ver. 20 Kluczowego Systemu. Otwieracie dokument, patrzycie się na ilość stron jakie zostały wyprodukowane („no, no… 150 stron, to musi być masa informacji”) . Więc z zapałem zabieracie się do czytania. I..? I porażka – okazuje się, że dokument jest tak naprawdę pusty – połowa „treści” to rysunki, które nic nie wnoszą, reszta to wygenerowany z automatu opis tych rysunków, najczęściej całkowicie pusty lub też zaprezentowane diagramy są banalne, informacje się powtarzają. Nie dość że nie ma z nich żadnego pożytku to jeszcze wprowadzają chaos informacyjny: zaciemniają inne, potencjalnie ważne dane, powodują że w masie nieistotnych danych ginie to co jest kluczowe.

Czyli tym razem będzie o jakości dokumentacji. O tym co można zrobić źle pisząc dokumentację, ze wskazaniem na możliwe przegięcia – tak co za dużo to niezdrowo. I o tym jak sobie poradzić z tym tematem.

Czytaj dalej Ilustrowana instrukcja oddychania w 10 krokach

Węgierski diagram

Zdarzyło mi się uczestniczyć ostatnio w dyskusji o kierunkach rozwoju zawodowego analityka. Dyskusja, jak to dyskusja na forum internetowym, nie doprowadziła do żadnych sensownych wniosków, tylko swobodnie odpłynęła. Jednym z kierunków, którym podążyli dyskutanci, były rozważania o wyższości BPMNa nad UML (a właściwie nad czymkolwiek innym). BPMN jest ostatnio w modzie, więc szybko ujawniła się grupa wiernych fanów i kibiców, rzucająca całą litanią zalet tego języka. Dziwnym trafiem prawie wszystkie brzmiały bardzo podobnie do marketingowych haseł, reklamujących BPMNa w różnego rodzaju whitepaperach. W szczególności spodobała mi się takie hasło:

BPMN jest łatwy, prosty i intuicyjny. Każdy go rozumie.

Czyli bierzemy pierwszego lepszego człowieka z ulicy (dobra, niech będzie – dowolnego klienta dla którego robimy system informatyczny), rzucamy mu dowolny diagram BPMNa z procesami, a on na to: „Aha – tak o to chodzi, ten proces idealnie obrazuje wszystkie niuanse naszego sposobu pracy”. BPMN odwalił za nas całą robotę – narysowaliśmy diagramik i wszystko już dla każdego jest jasne i oczywiste: doskonałe zrozumienie wymagań i oczekiwań klienta, doskonałe i pełne zrozumienie produktu który wykonawca dostarczy. Analityczna nirvana.

Czytaj dalej Węgierski diagram

Biznesowe przypadki użycia

Przez książki, tutoriale, blogi dotyczące inżynierii oprogramowania przewijają się różne epitety 1, określające przypadki użycia. W szczególności dwa określenia pojawiają się często – systemowe lub biznesowe przypadki użycia. Przeważnie jednak, autorzy używający tych sformułowań nie wspominają co właściwie przez nie rozumieją. Niestety, podobnie jak w przypadku wielu innych pojęć IT, tak i tu każda osoba używająca tego określenia może mieć coś innego na myśli. Jak więc odróżnić systemowy od biznesowego i kiedy ma sens stosowanie takich określeń? Czytaj dalej Biznesowe przypadki użycia

  1. w znaczeniu przymiotnik opisujący cechę

Przypadki użycia

Kilka postów wcześniej wspomniałem o tym, że nie cierpię diagramów przypadków użycia. Skrytykowałem to narzędzie m.in. za, ukrywanie tego czym przypadki użycia naprawdę są. Nie wspomniałem jednak czym właściwie są te przypadki użycia. Pojęcie jest znane od przynajmniej kilkunastu lat (1994?), czy jednak wszyscy używający tego pomysłu wiedzą o co chodzi? Postaram się w skrócie opowiedzieć jak ja posługuję się przypadkami użycia. Dziś skupię się raczej na tym jak zastosować przypadki użycia, jak je rozumieć. Do tego jak je opisać wrócę, mam nadzieję, w którymś z kolejnych wpisów. Czytaj dalej Przypadki użycia

Mam problem z przypadkami

użycia, a właściwie z UML-owym diagramem przypadków użycia.

Na początek małe zastrzeżenie: mówię o diagramach przypadków użycia a nie przypadkach użycia. Przypadki użycia to całkiem niezłe narzędzie, któremu poświęcę trochę uwagi dalej. Zwracam też uwagę, że mówię tu o czystym UMLu, bez wchodzenia w tematykę metodologii, frameworków modeli itp. Wracając do naszych dzisiejszych bohaterów – sądzę, że diagramy przypadków to bardzo niebezpieczne narzędzie, które może łatwo wyrządzić więcej szkód niż przynieść pożytków. Czytaj dalej Mam problem z przypadkami