Przejdź do głównej zawartości

Szymon Drejewicz Zrozumieć BPMN Modelowanie procesów biznesowych. Wydanie 2 rozszerzone

Szymon Drejewicz – Zrozumieć BPMN Modelowanie procesów biznesowych. Wydanie 2 rozszerzone.



Dziś wypełniam kolejną zakładkę mojego bloga – książki.

Ostatnie miesiące mają jeden wspólny mianownik – literatura branżowa. Czytam głównie te pozycje, które mogą mi pomóc w pracy przy utrzymywaniu, rozwoju i tworzeniu systemów informatycznych.

Wg mnie jednym z głównych zadań analityka jest zbieranie i dokumentowanie wymagań. Należy je odpowiednio przygotować i opisać, w taki sposób, żeby były czytelne zarówno dla interesariusza, który totalnie nie ma nic wspólnego z systemową arytmetyką jak i dla programisty, którego mózg przetwarza a) kod, b) krótki, zwięzły tekst, c) rzeczowe wykresy lub diagramy.

No i tu z pomocą przychodzi BPMN, standard opracowany przez OMG (Object Managment Group), który pozwala na opisywanie rzeczywistości w takiej postaci, która będzie użyteczna dla każdej z grup zainteresowanych systemem. W łatwy i przejrzysty sposób pozwoli na ustalenie podziału prac w trakcie działania procesu jak i estymacji pracochłonności związanej z ewentualnymi zmianami zachodzącymi w trakcie życia procesów.

Niestety nauczenie się notyfikacji BPMN ze specyfikacji znajdującej się na stronie OMG jest prawie niewykonalne 😉 oczywiście można poświęcić najlepsze godziny ze swojego wieczora i czytać potwornie opasły dokument, ale to może doprowadzić do zniechęcenia i ogólnopojętego poddenerwowania😉

Dlatego zdecydowałam się na przeczytanie czegoś, co jest napisane w ludzkim języku, ma przyjemną, zwięzłą formę i w 80 % zaspokaja moje potrzeby dotyczące tej notyfikacji. Na wykładzie dotyczącym BPM  dowiedziałam się, że z polskiej literatury nie mamy zbyt dużego wyboru i tak naprawdę książka Pana Szymona Drejewicza jako jedyna jest godna polecenia (mówimy oczywiście o poznaniu samej notyfikacji).

Po skończeniu lektury postanowiłam przejść do zajęć „praktyczno - technicznych” i modelowałam różne, wymyślone przez siebie systemy i z całą pewnością mogę stwierdzić, że książka bardzo ułatwiła mi pracę w takich środowiskach jak Aris czy Enterprise Architect (EA). Już nie głowie się czym jest przepływ z kreską, kółko z kopertką w środku albo chłopek w prostokącie😉

Dlatego bardzo polecam zapoznanie się z tą lekturą każdemu, kto kiedyś widział, ba nawet modelował w EA lub innym środowisku i po omacku dobierał kształty, w celu stworzenia czegoś, co później nazywał „modelem procesu biznesowego” 😉

Komentarze

Popularne posty z tego bloga

Jak Pani przeprowadza analizę? Pytania rekrutacyjne na Analityka Biznesowego

Na moim ulubionym  blogu o analizie znajduje się post z 99 pytaniami, które mogą pojawić się na rozmowie kwalifikacyjnej na stanowisko analityka biznesowo/systemowego. Przejdź do pytań   Od dziś będę opracowywać pytania znajdujące się na tej liście, co w konsekwencji pozwoli mi na sporządzenie obszernego materiału, który ułatwi przygotowanie się do skomplikowanego procesu rekrutacyjnego.   Oczywiście zdaje sobie sprawę z tego, że ile firm tyle różnych procesów i pytań kwalifikacyjnych, ale zagadnienia znajdujące się na liście „99 pytań” są na tyle uniwersalne, że można z dużym prawdopodobieństwem założyć, że część z nich zostanie użyta w trakcie rozmów wstępnych. No to lecimy :) pytanie na dziś to     Jak Pani przeprowadza analizę? Pierwsze co mi się nasunęło na myśl: „ To zależy ” 😉 , ale żeby na tym nie kończyć, to może napiszę od czego to tak naprawdę zależy. Ostatnio miałam przyjemność być na warsztatach Przewodnik po analizie dla zdezorientowanych- J

Jakie znasz rodzaje diagramów UML – lista 99

Dziś post krótki ale treściwy! Takie podobno cieszą się największym zainteresowaniem 😊 Jakie Pani zna rodzaje diagramów UML ? No i może ktoś się zdziwi, ale wszystkich diagramów UML jest 13 😉 ale oczywiście korzystanie ze wszystkich na raz często mija się z celem, bo projekt np.: nie zakładał tworzenia diagramu rozlokowania, albo wymagane były tylko diagramy przypadków użycia, klas i sekwencji.  Ale ! ale! ale ! to nie jest do końca tak, że jak czegoś na co dzień nie używamy to jest nieistotne i mało ważne.   Bo jeśli np.: okaże się, że w ramach dokumentacji ma powstać jakiś „rysunek” obrazujący relacje pomiędzy odpowiednimi częściami systemu to nie zaczniemy tworzyć nowego typu diagramu tylko skorzystamy z diagramu Struktur Połączonych (bo na kiego grzyba koło na nowo wymyślać). A dlaczego z niego skorzystamy ? bo wiemy, że istnieje i do tego właśnie powinien zostać użyty. A gdybyśmy o nim nigdy nie słyszeli to prawdopodobnie tworzylibyśmy nowe, nikomu

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,