Tag: analiza biznesowa

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ę ↩

Celem naszym jest dumnie kroczyć do przodu

Zacznę od cytatu z pewnego dokumentu, dotyczącego bardzo ważnego państwowego projektu informatycznego1:

Istotą postępu w budowie społeczeństwa informacyjnego jest konsekwentne rozszerzanie zbioru zadań publicznych udostępnianych drogą elektroniczną.

Czyli, według autorów, celem tzw. budowy społeczeństwa informacyjnego (czy w tym wypadku informatyzacji administracji publicznej) jest po prostu przerobienie każdej usługi do postaci elektronicznej i dzięki temu wszyscy będą szczęśliwi. Niestety nie jest tak łatwo – przerabianie wszystkiego na „postać elektroniczną” nie jest istotą postępu. Czytaj dalej Celem naszym jest dumnie kroczyć do przodu