BPMN – Page 17 – JZ IT Consulting Ltd

Miejsce BPMN w odniesieniu do UML

Post author:Jaroslaw Zelinski
Post published:29 June 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

To, że UML jest obcy większości analityków biznesowych to przykra prawda, dzisiaj raczej źle świadcząca o tej większości (patrz model kompetencji analityka biznesowego IIBA). Używanie UML do modelowania procesów biznesowych jest ograniczaniem możliwości tych modeli gdyż UML reprezentuje paradygmat obiektowy a BPMN procesowy a to dwa odrębne światy (to, że powstały i są wykorzystywane równolegle te dwie, różniące się od siebie, notacje notacje także o tym świadczy). Trudno także mówić o "podejściu" do modelowania procesów w UML bo to tak, jak by mówić że "łodzie reprezentują zupełnie odmienne podejście do poruszania się po drogach publicznych". Niestety są żeglarze, którzy nie uznają innej prawdy niż ta, że łodzią można wszędzie, trzeba się tylko postarać. Faktem jest, trzeba się dobrze postarać. [...] Co do wymagań samych narzędzi UML nie podejmuję się dyskusji bo narzędzia są rożne i każdy sam sobie je dobiera. Co do samej ścieżki analizy to raczej w pierwszej kolejności modelujemy biznes (modele BPMN) a potem dopiero zastanawiamy się i projektujemy narzędzie, oprogramowanie dla tego biznesu czyli pora na UML. Odwrotną kolejność sugerują dostawcy gotowego oprogramowania ale ten wątek był na tym blogu już nie raz poruszany.

RACI, SIPOC i inne czyli modelowanie organizacji c.d.

Post author:Jaroslaw Zelinski
Post published:7 June 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Modelując jakąkolwiek firmę jakąkolwiek notacją warto projekt modelowania uzupełnić o jego pragmatykę, to jest o specyfikację wszelkich warunków tworzenia modeli. Opracowanie takiej dokumentacji wymaga ustalenia tych zasad, a także zdefiniowania słownika, skończonej przestrzeni nazw i definicji, która pozwoli jednoznacznie zaklasyfikować każde pojęcie z życia firmy do właściwego, i tylko jednego, elementu modelu. Projekt modelowania procesów to nie jest proste rysowanie tego co się dzieje. Tak powstają najczęściej nieprzydatne i kosztowne zarazem dokumenty. Projekt modelowania procesów biznesowych to wnikliwa analiza całej organizacji, sposobu zarządzania nią i udokumentowania tego jak faktycznie powstaje w niej wartość dla klienta. Nie raz niestety odnoszę wrażenie, że w wielu projektach tego rodzaju duża wartość analizy i modeli biznesowych zostaje zastąpiona skomplikowanymi i nic nie wartymi diagramami.

Ach ten wstrętny, wścibski analityk

Post author:Jaroslaw Zelinski
Post published:24 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat. Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy... tak jak to napisano na początku. Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

Czy wymagania opisują tylko to “co” system ma robić?

Post author:Jaroslaw Zelinski
Post published:21 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to "co" system ma robić, a oni już załatwia sprawę tego "jak" ma to robić. W czym problem? W tym, że funkcjonalności to test rozwiązania a nie wymagania! [...] Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości. [...] Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). [...] Programiści, proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie "wydaje mi się że rozumiem" to droga do porażki. [...] System ERP można wybrać na bazie projektu na wyższym poziomie abstrakcji. Analizy firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej "modelu filozofii działania" firmy a nie projektowanie systemu od zera.

Czego moglibyśmy się nauczyć od naukowców?

Post author:Jaroslaw Zelinski
Post published:19 May 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

I tu zaczynają się schody. Bo jeżeli rozumiem programistów, że lubią się bawić, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu... Jak mam sobie wyobrazić tworzenie samolotu w postaci podstawianych na lotnisko pasażerskie kolejnych prototypów? Czy każdy projekt IT to samoloty? Tak! Tam pracują ludzie, płacą za to i cierpi ich biznes jak oprogramowanie nie zadziała jak trzeba! Co mogę po tym powiedzieć? Państwo sami zdecydujcie co wolicie w swoich projektach: 200% narzutu na swobodne podejście dostawców oprogaramowania czy 20% na dobrego analityka projektanta...