o modelowaniu procesów i systemów 

Co zrobić w sytuacji gdy do wykonania danej funkcji, opisanej przez przypadek użycia, potrzeba w tym samym momencie więcej niż jednego aktora? Czy można pokazać to na diagramie przypadków użycia? Otóż nie.

Diagram przypadków użycia nie definiuje nam tego kto w jakiej sytuacji, w jakim momencie korzysta z danej funkcji. Relacja aktor – przypadek użycia mówi jedynie o tym kto korzysta z funkcjonalności dostarczanej przez dany PU. W sytuacji gdy do realizacji fragmentu bądź całego scenariusza potrzeba dwóch aktorów to na diagramie PU wskazujemy na działanie obu aktorów poprzez asocjację.

Natomiast ich jednoczesne działanie procentujemy na diagramie aktywności zaznaczmy stosując tory (partycje)  pionowe i poziome.

Dzięki zastosowaniu partycji pionowych i poziomych i zmapowaniu ich na aktorów można wskazać na te fragmenty scenariusza, które są realizowane przez obu aktorów równocześnie. Technika ta może być przydatna zarówno przy modelowaniu procesów biznesowych jak i projektowaniu systemów informatycznych.

Budowa modelu architektury biznesowej w dużym uproszczeniu polega na następujących etapach:

1. Określenie strategicznych celów organizacji
2. Budowa modelu biznesu na wysokim poziomie abstrakcji
3. Znalezienie ram strukturalnych organizacji
4. Budowa modelu procesu biznesowego

IMHO powyższe punkty zasadniczo nie odbiegają od standardowej ścieżki budowy modeli procesów biznesowych a czasem wymagań na system. Różnica polega na tym, że architektura korporacyjna swoim zasięgiem obejmuje więcej, szerszy kontekst działania organizacji, niż tradycyjny model biznesowy.

W zeszłym roku pisałem w tekście pt. Architektura korporacyjna bardzo ogólnie o architekturze korporacyjnej. Teraz postaram się w kilku słowach napisać o jej zaletach.

• Architektura korporacyjna pozwala na uporządkowanie portfela posiadanych systemów informatycznych i rozwiązań technologicznych.
• Znajomość zasobów aktualnych zasobów IT i procesów biznesowych z nich korzystających (as-is) pozwala zaplanować rozwiązania do celowe (as-will).
• Dzięki architekturze korporacyjnej łatwiej jest przedstawić działanie poszczególnych systemów informatycznych przekłada się na funkcjonowanie procesów biznesowych.
• IMHO najważniejsze: Architektura korporacyjna ułatwia rozbudowę i optymalizację funkcjonalności informatycznych, gdyż przedstawia aplikacje, systemy i platformy, które są powiązane złożoną siecią wzajemnych zależności.

Innymi słowy każda organizacja powinna budować taką architekturę, gdyż to daje jej możliwość elastycznego rozwoju. Co więcej budowa ?tradycyjnych modeli biznesowych jest podstawą do budowy architektury korporacyjnej.

Pojęcie architektury korporacyjnej (ang. enterprise architecture )  zaczyna funkcjonować w świadomości co raz to większej liczby firm. Firmy te dostrzegły potrzebę opisania struktury i współpracy na poziomie komponentów. Tymi komponentami mogą być pracownicy firmy, działy firm, systemy informatyczne.

Koncepcją, która może pomóc zmienić postrzeganie informatyki w urzędzie ? z roli czysto technicznej, na mającą istotne znaczenie dla funkcjonowania jednostki ? jest architektura korporacyjna (enterprise architecture). W literaturze definiuje się ją jako opis struktury i funkcji komponentów jednostki (komponentami są np. ludzie, procesy biznesowe, struktury organizacyjne jak również systemy informatyczne), wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Czyli mówimy tutaj nie tylko o modelach, ale także o sposobie działania.

Dla mnie architektura korporacyjna jest modelem biznesowym na wysokim poziomie abstrakcji. Znamiennym jest iż budując architekturę korporacyjną można skorzystać z modele koncepcyjnych (EA Framework) takich jak:

• Zachman Framework
• FEAF (Federal Enterprise Architecture Framework)
• DoDAF (Department of Defense Architecture Framework)
• TOGAF (Open Group Architecture Framework)
• Meta Group (obecnie Gartner)

Moją ulubioną ?strategią? budowania architektury korporacyjnej jest TOGAF (The Open Group Architecture Framework) nie tylko, ze najlepiej go z nam, ale także dlatego, że jest to podejście rekomendowane przez UE.

W tym miejscu pozwolę sobie zebrać kilka cech, które świadczą o tym, że mamy do czynienia z dobrym modelem biznesowych przypadków użycia. Oto one:

• Biznesowe przypadki użycia są zrównane ze strategią firmy ? wspierają cele organizacji.
• Przypadki użycia są zgodne z organizacją, którą opisują.
• Wszystkie przypadki użycia są znalezione. Po zebraniu, przypadki użycia wykonują wszystkie zadania w ramach organizacji.
• Każde zadanie w ramach organizacji jest ujęte w przynajmniej jednym Przypadku Użycia.
• Istnieje równowaga między liczbą przypadków użycia a ich wielkością:
• Model zawiera kilka przypadków użycia  – przez co jest łatwiejszy do zrozumienia.
• Przypadek użycia opisuje pełen przepływ informacji, który produkuje coś wartościowego dla klienta.
• Każdy przypadek użycia jest unikatowy. Jeżeli przepływ informacji jest taki sam lub podobne do innego przypadku użycia, trudno będzie utrzymać je później w zsynchronizowaniu. Należy uwzględnić scalenie je w pojedynczy przypadek użycia.

Ile z podanych cech spełniają Twoje modele?

Budowanie modeli biznesowych coraz częściej znajduje uznanie wśród projektantów systemów. Wiąże się to z faktem, że modele biznesowe stanowią podstawę całego przedsięwzięcia bowiem pozostałe dyscypliny inżynierii oprogramowania (bazując teraz na dyscyplinach RUP )czerpią z niej w następujący sposób:

• Dyscyplina Wymagania wykorzystuje biznesowe modele jako istotne dane wejściowe dla zrozumienia wymagań systemu.
• Dyscyplina Analiza i Projekt wykorzystuje biznesowe modele jako dane wejściowe dla określenia systemów oprogramowania, które płynnie pasują do organizacji.
• Dyscyplina Wdrożenia wykorzystuje biznesowe modele jako pomoc w planowaniu zastosowaniu systemu oprogramowania.

Co więcej modelowanie biznesu jest procesem iteracyjnym, który zaczynając kawałek po kawałku, w każdej iteracji, pozwala nam na na lepsze poznanie organizacji a tym samym dostarczenia istotnych treści dla procesu wytwórczego oprogramowania.

Celem modelowania biznesu jest:

• Zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia.
• cena wpływu zmiany organizacyjnej.
• Zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób.
• Wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację.
• Zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasuje się w organizację.

Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji.

Dla mnie to bardzo ważne  gdyż tylko dzięki widokom z różnych perspektyw (statycznej i dynamicznej) jestem wstanie poprawnie zaprezentować na modelu jak nowy system będzie wspierał organizację.

Aby przewidzieć wymogi dla aplikacji biznesowej można rozważyć stworzenie następujących modeli:

• Schemat proceduralny interfejsu użytkownika. Dostarcza on przeglądu ekranów i raportów oraz to, jak w jaki sposób są one wzajemnie powiązane. Na chwilę obecną potrzebujesz jedynie głównych ekranów i raportów. 
• Diagram WPA (Wysokiego Poziomu Abstrakcji). Diagram procesu wysokiego poziomy, plus kilka diagramów dających podgląd kilku krytycznych procesów, są zazwyczaj potrzebne do zrozumienia przepływu biznesowego.
• Diagramy przypadków użycia. Zamiast diagramów procesu wysokiego poziomu (WPA) możesz zrobić diagram przypadków użycia wysokiego poziomu. Jest to kwestia tego preferencji, ja prawdopodobnie nie robiłbym tego diagramu, gdyż WPA jest dla mnie wystarczający.
• Diagram klas. Wskazuje na nim ważne dane, które są przetwarzane w organizacji.
• Diagram procesu. Czyli popularny diagram aktywności.  Warto na nim zamieścić obiekty.
• Definicje słownikowe. Być może będziesz chciał zacząć od zidentyfikowania kluczowych terminów biznesowych. Widziałem zbyt wiele zespołów uziemionych przez ?paraliż analizy? ponieważ próbowali zdefiniować dokładną terminologię przed przejściem do następnych etapów. Nie wpadnij w tę pułapkę.

Podane punkty stanowią składową wielu aplikacji biznesowych, ale w zależności od specyfiki biznesu i procesu niektóre z nich mogą być opcjonalne.

Największym kapitałem każdej organizacji są zachodzące w niej procesy. Aby procesy te mogły być efektywnie doskonalone należy je w odpowiedni sposób odwzorować w systemie informatycznym. Zanim przystąpi się do budowy systemu informatycznego warto dobrze poznać te procesy budując ich modele. Dziś przyszłość stanowią metodyki zwinne (Agile) w tym także te, które wykorzystują modele. Właśnie tej tematyce  – zwinnemu modelowaniu procesów biznesowych poświęcone było dwudniowe szkolenie, jakie miałem przyjemność poprowadzić 23-24 lipca w Warszawie.

Jedna z warszawskich firm w tym nurcie będzie modelować procesy biznesowe celem dostarczania klientom dedykowanych rozwiązań, które opierają się na otwartym kodzie tworzonej aplikacji. Pozwala to by aplikacja ta była w przyszłości rozwijana i modyfikowana przez dowolny podmiot, nie wyłączając oczywiście samego użytkownika.

Szkolenie przebiegło w bardzo dobrej, twórczej atmosferze. Otrzymałem tylko dobre i bardzo dobre noty a w komentarzach w pozycji Co najbardziej podobało Ci się na szkoleniu można przeczytać między innymi: ?skupienie się prowadzącego na sednie sprawy?, ?praktyczne przedstawienie złożonego tematu??. Dziękuję

?Zwinne modelowanie wymagań biznesowych w wytwarzaniu oprogramowania? to temat artykułu, który pozytywnie został oceniony przez recenzentów  XI Krajowej Konferencji Inżynierii Oprogramowania (KKIO’09).

W artykule tym wskazałem, że  zwinne metodyki zwinne unikają budowy modeli a jednocześnie odczuwalna jest potrzeba dokumentowania decyzji projektowych.  Wskazałem na podstawowe czynności związane ze zwinnym modelowaniem wymagań biznesowych w wytwarzaniu oprogramowania. W poszczególnych podrozdziałach zaprezentowałem  rozszerzoną notację UML oraz produkty jakie powstać powinny w ramach tej fazy.

 Kilka dni temu pisałem (patrz Modelowanie Procesów Biznesowych ? BPM 2009), o moim wystąpieniu na konferencji BPM w trakcie, którego proponowałem podejście do modelowania procesów biznesowych w języku UML. Moja propozycja ukierunkowana była na nurt Agile i zalety jakie on niesie dla biznesu. Nie chodzi tu o legendarny brak dokumentacji i inne stereotypy dotyczące nurtu Agile (patrz m.in. Zwinne modelownie ? mity i fakty). W moim rozumieniu modelowanie Agile to przede wszystkim rozważne modelowanie procesów biznesowych w trakcie którego, będąc ukierunkowanym na zmiany i potrzeby klienta, nie traci się zalet, jakie niesie wizualizacja procesu biznesowego w języku UML.   Moje poglądy podziela  Jacek Kołodziejak Dyrektor ds. Rozwoju w firmie Intertrading Systems Technology Sp. z o.o, który na konferencji Gigacon ISI 2009 (2 czerwca 2009) mówił o zaletach platformy JBoss Enterprise Middleware. Wygląda na to, że obaj zgadzamy się, iż zastosowanie metodyk zwinnych w modelowania biznesowym, pozwalają na zwiększenie elastyczności biznesowej a tym samym szybsze reagowanie na potrzeby biznesu co w konsekwencji pozwala na doskonalenie procesu biznesowego i zwiększanie wartości dodanej firmy.   Co więcej zastosowanie wizualizacji procesów biznesowych za pomocą języka UML pozwala na identyfikację zbioru wzajemnie przeplatających się procesów. Innymi słowy:

podejście Agile + modelowanie w UML = zwiększenie elastyczności biznesowej

Na koniec dziękuję za wymienienie mojej osoby w trakcie prezentacji. Cała prezentacja jest dostępna pod adresem http://www.rejestracja.software.com.pl/download/6853.html

Konferencja Modelowanie Procesów Biznesowych 2009 to kolejna a już VII edycja seminarium poświęconemu modelowaniu i doskonaleniu procesów biznesowych organizowana przez Software-Konferencje. Po raz drugi miałem przyjemność wziąć udział jako prelegent w tym przedsięwzięciu. Jako jeden z nielicznych reprezentowałem nurt modelowania procesów biznesowych w UML a moja prezentacja na temat zwinnego modelowanie procesów biznesowych w języku UML spotkała się z dobrym przyjęciem o czym świadczą ankiety, w których otrzymałem 94% opinii dobrych i bardzo dobrych.

Pod hasłem WMB gromadzić będę zestawy wskazówek pozwalające na dokumentację procesów biznesowych. Celem WMB nie jest tylko ułatwienie budowy modeli biznesowych, ale także rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli.

WMB to:

• aktywności ? jako wskazówki do działania ? zestawy czynności warunkujące osiągnięcie poprawnego modelu
• role  – jako zakres kompetencji dla osób wykonujących model biznesowy,
• notacja UML ? jako rozszerzenie notacji UML o stereotypy, które pozwalają na budowę bardziej jednoznacznych modeli,
• rozszerzenia narzędzi CASE -  jako profile pozwalające na budowę modeli biznesowych z wykorzystaniem notacji WMB

przeczytaj pozostałą część »