PRACA SEMESTRALNA Inżynieria Oprogramowania

Transkrypt

1 WYŻSZA SZKOŁA ZARZĄDZANIA I BANKOWOŚCI W KRAKOWIE WYDZIAŁ INFORMATYKI PRACA SEMESTRALNA Inżynieria Oprogramowania Mirosław Potaczek Mirosław Rożek Narzędzia wspomagające modelowanie biznesowe Kraków 2006

2 CZĘŚĆ I Wstęp... 3 CZĘŚĆ II Modelowanie biznesowe... 5 CZĘŚĆ III Model biznesowy Co to jest model biznesowy Model procesów biznesowych i mapa przebiegu (łańcucha) czynności CZĘŚĆ IV Techniki modelowania Podstawowe techniki modelowania IDEF UML BPMN CZĘŚĆ V Przykładowe aplikacje do modelowania CZĘŚĆ VI Zakończenie CZĘŚĆ VII Bibliografia

3 CZĘŚĆ I WSTĘP 3

4 Podstawowym przedmiotem niniejszej pracy jest przedstawienie modelowania biznesowego oraz narzędzi, które temu służą. Rozdział pierwszy poświęcony jest ogółowi modelowania biznesowego. W rozdziale kolejnym swoją uwagę skupiliśmy na modelu biznesowym czym on jest, jak wygląda. W rozdziale następnym przedstawiliśmy różne techniki modelowania biznesowego. A teraz zapraszamy do bliższego zapoznania się z treścią naszej pracy. 4

5 CZĘŚĆ II MODELOWANIE BIZNESOWE 5

6 W dzisiejszych czasach sytuacja rynkowa jest bardzo niestabilna, zwłaszcza z punktu widzenia niedużych przedsiębiorstw. Managerowie robią wszystko, aby usprawnić działanie swoich firm, nie tyle w sferze kontaktów z klientami czy dostawcami, co w sferze wewnętrznego ich funkcjonowania. Niestety, dbanie o zachowanie prawidłowej struktury organizacji bądź odpowiedni przepływ informacji jest trudne i często kłopotliwe, choć konieczne. W wyniku działań mających na celu usprawnienie procesów czy też polepszenie zarządzania wiedzą w przedsiębiorstwie pojawiły się różne metody, których zadaniem jest uzdrowienie i ulepszenie organizmu, jakim jest firma. Jedną z nich jest modelowanie procesów biznesowych. Modelowanie biznesowe (z ang. Business Modeling) jest praktyką stosowaną z powodzeniem przez wiele współczesnych przedsiębiorstw, ale mimo wszystko niezbyt znaną. Model biznesowy pozwala nam zrozumieć czym zajmuje się nasza firma, czemu akurat tym i czemu akurat w taki sposób. Pozwala ponadto stwierdzić za co odpowiedzialne są konkretne osoby w naszej firmie, jaka jest ich rola czy też zakres współpracy z innymi pracownikami. Należy jednakże pamiętać o tym, by opisać każdy, nawet najmniejszy fragment naszej rzeczywistości biznesowej i określić dokładnie jego miejsce w hierarchii oraz związki z innymi elementami. To bowiem pozwoli uzyskać model kompletny i spójny, a co najważniejsze - wiarygodny. Jest to ważne ze względu na integracje. Wdrażając nowy system informacyjny czy też usprawniając działanie starego, musimy upewnić się, że "pasuje" on do tego, co się w naszej firmie dzieje. Mam/y tu na myśli nie tyle integrację aplikacji czy integrację systemową. W dzisiejszych czasach coraz częściej wspomina się o tzw. integracji biznesowej, dotyczącej w dużej mierze procesów biznesowych powiązanych z daną jednostką. Jest ona możliwa do osiągnięcia, ale wymaga precyzyjnego określenia reguł operacyjnych biznesu oraz zrozumienia zasad jego działania - głównie poprzez integrację samych procesów z wspomagającymi je systemami informacji. 6

7 CZĘŚĆ III MODEL BIZNESOWY 7

8 3.1. Co to jest model biznesowy Model biznesowy opisuje kontekst rynkowy firmy. Jest to diagram, często z dodatkowym opisem, obrazujący role firmy w łańcuchu wartości na rynku, w łańcuchu zaopatrzenia. Obrazuje także wszystkie zależności z otoczeniem rynkowym. Jest podstawowym elementem zobrazowania strategii firmy, jej roli i pozycji na rynku. Przyjmuje różne postacie. Wybór metody zobrazowania jest tu drugorzędny, ważne by diagram był czytelny, jasny i jednoznacznie określał wszystkie zależności i kanały informacyjne w jakich firma bierze udział. Jest bardzo przydatny w budowaniu planu marketingowego, także jako jego późniejsza ilustracja. Poprawny model biznesowy określa przepływ wartości dodanej i przepływ środków za oferowane na rynku wartości, przepływy informacji. Poprawny model biznesowy powinien definiować dwa podstawowe obszary: 1. przepływ wartości dodanej i przepływ środków za oferowane na rynku wartości, 2. przepływy informacji. Rys Przykład rzeczywistego modelowanie biznesowego 8

9 3.2. Model procesów biznesowych i mapa przebiegu (łańcucha) czynności Jest to opis wnętrza firmy. Zależnie od potrzeby i wymaganego stopnia dokładności diagramy tego typu opisują sposób funkcjonowania firmy. Model procesów jest niejako naturalnym rozwinięciem do wewnątrz modelu biznesowego firmy. W połączeniu z modelem biznesowym stanowi kompletny opis roli firmy na rynku oraz tego jak ta rola jest wewnątrz firmy realizowana. W najprostszej postaci może być to diagram obrazujący podstawowe funkcje jakie realizuje forma. Schemat taki służy najczęściej do zaprezentowania na wysokim poziomie abstrakcji pracownikom lub osobom z zewnątrz tego co firma tak na prawdę robi. Pozwala to szybko przekazać wiedze o specyfice firmy. Do celów reorganizacji lub dokumentowania obrazu firmy na potrzeby n. wdrożeń systemów IT wykonuje się modele dokładniejsze. Poniżej fragment mapy procesów biznesowych. Obrazuje ona podstawowe procesy w firmie i związki pomiędzy nimi. Model taki może także obrazować łańcuch procesów uwzględniając np. bezpośrednich dostawców i odbiorców. Stosowane są tu tak zwane notacje modelowania. Może to być IDEF0, ARIS/eEPC czy BPMN. IDEF0 to notacja często jeszcze wykorzystywana w dokumentowania procesów biznesowych. jej zaletą jest duża skuteczność jednak praktycznie nie jest wspierana przez organizacje związane z technologiami modelowania. ARIS to potężne narzędzie wykorzystujące jako podstawową notację eepc (ang. extend Event Driven Process Chain). Pozwala tworzyć w zespołach nawet bardzo skomplikowane modele dużych organizacji. Ostatnia, BPMN (Business Process Modeling Notation) jest coraz częściej wykorzystywana przez analityków jako narzędzie do tworzenia modeli firm. Notacja jest kompatybilna z BPEL (ang. Business Process Execution Language) co pozwala np. wykorzystać stworzony model dalej w pracach programistycznych. 9

10 CZĘŚĆ IV TECHNIKI MODELOWANIA 10

11 4.1. Podstawowe techniki modelowania Wybór techniki modelowania może stanowić problem, z uwagi na ilość dostępnych rozwiązań. Technik jest wiele, ciągle trwają prace nad ich udoskonalaniem i rozwojem, w rezultacie czego powstają zupełnie nowe koncepcje. Śledzenie tych badań jest niewątpliwie ciekawe, ale rzadko który manager może sobie pozwolić na czasochłonne rozważania na temat wyższości wybranej techniki modelowania nad innymi. Rozwiązania kompleksowe często nie sprawdzają się w obliczu specyficznych sytuacji, w jakich znajdują się przedsiębiorstwa. Standaryzacja bywa uciążliwa - każde odstępstwo od normy stanowi problem, często nie do przejścia dla szeregowego pracownika. Obecnie preferuje się techniki modelowania poszczególnych części biznesu, np. Analizę Działań (Activity Analysis), Analizę Potrzeb (Need Analysis), Analizę Przypadków Użycia (Use CASE Modeling) czy Modelowanie Pojęciowe (Conceptual Modeling). Takie podejście pozwala uniknąć problemów w przypadkach nietypowych sytuacji. Techniki te są jednak tak skonstruowane, że zastosowane razem, pozwolą na uzyskanie modelu kompletnego, o który przecież nam chodzi. Kolejną kwestią, o której należy w tym miejscu wspomnieć, jest problem niespójności modelowania. W przypadku pracy grupowej techniki modelowania mogą się różnić ( nie ma przecież najlepszej - nasz wybór jest zatem subiektywny). Nawet stosowanie tej samej techniki może być inne w przypadku różnych projektów, co może prowadzić do powielania pracy czy poważnych jej utrudnień wymagających dodatkowych nakładów czasu. Przykładowe techniki modelowania: IDEF - Integrated DEFinition Methods, UML - Unified Modeling Language (czyli Ujednolicony Język Modelowania), BPMN - Business Process Modeling Notation. 11

12 IDEF Od wielu lat prowadzone są przedsięwzięcia mające na celu standaryzację metod opisu procesów i sposobów pozyskiwania informacji potrzebnych do budowy modelu. Departament obrony USA opracował w latach 70. normę tworzenia przebiegu procesu IDEF0 (Integration DEFinition language 0). Stosowana była ona jako narzędzie tworzenia programów komputerowych wspomagających procesy produkcyjne, później przyjęła się jako narzędzie umożliwiające sporządzenie wykresów procesów w firmach usługowych i produkcyjnych. Norma IDEF0 pomóc ma ustaleniu zakresu analizy oraz zbudowaniu relacji pomiędzy analitykiem i jego klientem. IDEF0 może być pojmowane zarówno jako narzędzie komunikacji za sprawą znormalizowanych symboli graficznych, jak i jako narzędzie analizy, ukazujące jakie czynności mają być wykonane w celu prawidłowego wymodelowania procesu. Norma IDEF0 pomaga również w ustaleniu słabych i mocnych stron modelowanego systemu. Podstawowym założeniem IDEF0 jest umieszczanie poszczególnych funkcji wchodzących w skład procesu w prostokątnych ramkach, w sposób przestawiony na rysunku. Strzałki wchodzące z lewej strony oznaczają wejścia funkcji nakłady materiałowe i informacyjne, strzałki wychodzące z prawej strony reprezentują wyjście funkcji czyli materialne i niematerialne efekty jej wykonania. Strzałki wchodzące z góry symbolizują mechanizmy sterowania funkcją (np. wewnętrzna politykę firmy lub czynniki zewnętrzne), zaś strzałki wchodzące od dołu mechanizmy niezbędne do wykonania funkcji np. narzędzia, pojazdy, wykonawców. Modele zbudowane mogą być z wielu funkcji połączonych sobą za pomocą strzałek w taki sposób, że wyjścia jednej funkcji są wejściami lub mechanizmami sterowania dla innych funkcji. Norma uwzględnia również możliwość współbieżnego wykonywania dwóch lub więcej funkcji w sytuacji, gdy wyjście jednej funkcji jest wejściem dla wielu innych funkcji. Każda funkcja opisana może być przez osobny, podrzędny model. Norma IDEF0 szczegółowo i precyzyjnie opisuje sposób umieszczania funkcji, strzałek i ich opisów. Każda funkcja, strzałka i model opisane są przez nadany zgodnie z normą identyfikator. Zgodnie z normą IDEF0 model główny oznaczony jest symbolem A-0 (A minus 0) i znajduje się w nim jedna, nadrzędna funkcja A0. Opisana może być ona przez model A0, a funkcje w nim się znajdujące nosić będą oznaczenia A1, A2, A3, itd. Model podrzędny opisujący funkcję A1 nosić będzie również oznaczenie A1, a funkcje w nim się 12

13 znajdujące symbole A11, A12, A13, itd. Ten usystematyzowany sposób opisu umożliwia szybsze stworzenie spisu poszczególnych modeli i funkcji. Zależności między modelami podrzędnymi i nadrzędnymi ukazać można też graficznie za pomocą drzewa hierarchii funkcji. Norma IDEF0 ogranicza do sześciu ilość funkcji, które znajdować mogą się w modelu podrzędnym. Norma IDEF0 zawiera również szereg zaleceń dotyczących odpowiedniego sposobu tworzenia modelu, zbierania potrzebnych do jego sporządzenia danych oraz oceny zbudowanego modelu. Implementację normy IDEF0 umożliwiają różne narzędzia informatyczne - jednym z nich jest AI0 WIN firmy KBSI. Rozwinięcie i uzupełnienie normy IDEF0 stanowią kolejne normy IDEF. Norma IDEF1 umożliwia zbudowanie modelu ukazującego strukturę przepływu informacji w systemie. Norma IDEF2 ukazuje sposób zbudowania dynamicznego modelu pokazującego zależności czasowe pomiędzy funkcjami. Rozwinięciem normy IDEF1 jest norma IDEF1X, służąca do projektowania relacyjnych baz danych. Norma IDEF3 jest kompleksową metodą modelowania procesów. Została stworzona pod kątem zobrazowania łańcucha następujących po sobie działań. Zawiera opis mechanizmów, umożliwiających zebranie odpowiednich do opisu procesu informacji. Norma IDEF3 używa definicji procesu według Davenporta i Shorta, zgodnie z którą proces biznesowy to uporządkowany ciąg wydarzeń angażujących osoby, surowce, energię i wyposażenie, który to ciąg zaprojektowany jest dla osiągnięcia określonego rezultatu. Przesłankami do stworzenia normy IDEF3 były czynniki takie jak zwiększenie wydajności analizy systemów biznesowych, ułatwienie zbudowania opisu wymagań systemu, wspieranie procesu zarządzania projektami. Norma IDEF3 jest zbudowana w sposób, który umożliwia zrozumienie metody opisu przez osoby nie zajmujące się modelowaniem procesów, ma też ułatwić łatwe poznanie różnic pomiędzy różnymi, alternatywnymi wersjami procesu. Podstawowym elementem schematu procesu według normy IDEF3 jest symbol UOB (Unit of Behavior box), ukazujący pojedyncze działanie (funkcję), które przedstawiane jest za pomocą odpowiednio opisanego prostokąta. Symbole UOB łączone są za pomocą różnego typu połączeń (links), przedstawianych za pomocą strzałek. Rozgałęzienia procesu w schematach IDEF3 przedstawiają węzły (junctions), które zachowują się w sposób podobny do operatorów w programie ARIS. Występują węzły AND, rozdzielające proces na wiele równolegle przebiegających gałęzi, węzły OR (węzeł ten aktywuje jedną lub więcej gałęzi) oraz XOR (węzeł aktywuje jedną gałąź z kilku możliwych). 13

14 Dodatkowo występują węzły synchroniczne (synchronous) OR i AND, które oznaczają rozpoczęcie wielu odpowiednich dla danego węzła gałęzi w tym samym momencie (nie występuje synchroniczne XOR, gdyż po węźle aktywowana jest jedynie jedna gałąź). W symbolu okręgu umieszczane są występujące w procesie obiekty (na przykład poszczególne komponenty używane w produkcji), bądź stany tych obiektów. Norma IDEF3 ukazuje też kolejność przeprowadzania reorganizacji procesów, dzieląc ją na następujące etapy: 1. Udokumentowanie istniejącego procesu 2. Zidentyfikowanie zebrania najważniejszych dla procesu danych 3. Przeanalizowanie istniejącego procesu 4. Zaprojektowanie nowego procesu 5. Wyznaczenie alternatyw i wyboru konkretnej alternatywy 6. Opracowanie projektu biznesowego 7. Uzyskanie zgody na implementację zmian 8. Zaplanowanie i wdrożenie zmian 9. Ciągłe ulepszanie procesu Normy IDEF stanowią więc nie tylko zbiór metod opisu procesów i systemów informacyjnych, ale zawierają też sposoby zbierania danych i metody przeprowadzania zmian. Wsparte odpowiednimi narzędziami informatycznymi stanowić mogą więc podstawę dla przedsięwzięć z zakresu zmian procesów w organizacjach gospodarczych. 14

15 UML UML został właściwie wymyślony jako język, który pomaga wizualizować, specyfikować, konstruować i dokumentować zaawansowane oprogramowanie. Projektanci UML sprawili, że możliwe jest rozszerzenie języka w taki sposób, aby odnosił się on do wielu różnych dziedzin. Ta cecha umożliwiła UML zostanie językiem zarówno dla tradycyjnego modelowania biznesowego, jak również dla systemowej analizy i projektowania. UML został pomyślnie zastosowany do modelowania różnorodnych systemów tj.: q q q struktur danych do systemów czasu rzeczywistego, schematów XML (Extensible Markup Language), organizacji począwszy od małych prodzinnych firm, poprzez większe przedsiębiorstwa, a skończywszy na przedsiębiorstwach międzynarodowych. Zatem nie jest zaskoczeniem, że analitycy biznesu uważają UML za bardzo poręczny system do wizualizacji procesów w organizacji. UML jest bardzo przydatny, to najbardziej potężna, najelastyczniejsza notacja dostępna dla modelowania biznesowego w obecnych czasach. Pomaga zarządzać złożonością, zredukować czas developingu i ulepszyć jakość systemu. Istnieje sześć głównych powodów dlaczego: 1. UML dostarcza wspólnego języka dla analityków biznesu i producentów 2. UML jest wizualny, poglądowy, ilustracyjny 3. UML jest zorientowany obiektowo 4. UML opisuje procesy biznesu zarówno strukturalnie i dynamicznie 5. UML pomaga skupić się na kliencie 6. UML pomaga wyprowadzić wymagania systemowe Popatrzmy na każdy z tych powodów dokładniej. 1. UML dostarcza wspólnego języka dla analityków biznesu i producentów UML umożliwia modelowanie procesów biznesowych używając tych samych symboli, diagramów i innych form notacji, których używa grupa projektantów, by modelować systemy oraz aby utworzyć albo automatyzować te procesy. Używanie wspólnego języka umożliwia 15

16 coś, co wcześniej nie było możliwe w rozwoju oprogramowania: analitycy biznesu i projektanci mogą się porozumieć! Brzmi to dość prosto, ale zanim UML zanim został zastosowany do modelowania biznesowego, zawsze była rozłączność pomiędzy projektowaniem biznesowym i projektowaniem systemowym. UML w wielkim stopniu eliminuje przepaść pomiędzy developerami, kierownictwem i klientami. Kiedy zaczynasz z modelem bazującym na UML, kluczowe rozważania biznesowe są bardziej włączone do systemowych wymagań i to ostatecznie prowadzi do tego, że system, który służy klientom jest lepszy. 2. UML jest wizualny, poglądowy, ilustracyjny Moim zdaniem, perspektywy oferowane przez diagram przepływu i arkusze kalkulacyjne są zbyt liniowe, aby efektywnie modelować biznes. Ograniczony punkt widzenia może spowodować, że źle lub odmiennie spojrzymy na to, co prowadzi proces, gdzie jest wąskie gardło albo jak przepływa informacja. Aby w pełni modelować, potrzebna jest odpowiedź na tradycyjne pytania : jak?, kto?, co?, dlaczego? i kiedy? to ma miejsce. UML pozwala wizualizować, jak działa model. Jak?, kto?, co? są reprezentowane jako symbole i diagramy. W tym kontekście, związki, działalności i przepływy informacji, dobra i wszystkie usługi stają bardziej oczywiste. Te wizualne odwzorowania umożliwią. Zobaczenie wąskich gardeł, a także to w jaki sposób przepływa informacja (albo i nie) i określić kto co robi z twoją informacją biznesową. Na przykład, wizualny model upraszcza kiedy zbyt dużo informacji musi płynąć przez pojedynczy punkt, wskazuje na potencjalną potrzebę przekierowania przepływu do innego procesu. Dobrze zbudowany wizualny model biznesu taki, jak umożliwia UML odpowie na wszystkie fundamentalne pytania : q q q q q q q Kim są twoi wewnętrzni i zewnętrzni klienci? (kto skorzysta na tym systemie biznesowym), Gdzie system może wzbogacić wartość do twojego biznesu? Jakie zdarzenia w/albo na zewnątrz organizacji wywołują każdy proces biznesowy? Jakie końcowe produkty produkują procesy biznesowe? Jakie wewnętrzne elementy wiążą się z procesami biznesowymi? Co jest organizacyjną strukturą która wspomaga biznes? Jakie role i odpowiedzialności w obrębie tych struktur organizacyjnych powinny być częścią systemu? 16

17 3. UML jest zorientowany obiektowo Kiedy modelujesz przy użyciu UML, twoje biznesowe zainteresowania są wyraźnie naszkicowane w stosunku do odpowiednich biznesowych przedmiotów, w formie biznesowego modelu przedmiotu. Obiekty są jednostkami, które dorównują obiektom w świecie rzeczywistym : maja różne właściwości (takie jak imię i adres), powiązane w różne sposoby z innymi rzeczami otaczającymi, ukazują różne zachowania, kiedy wpływają na siebie. Obiektowo zorientowane modele mogą bardzo przybliżać obiekty biznesowe i systemowe, nawet do przedstawiania jak różne części systemu współpracują razem dynamicznie. To prawda, ponieważ obiekty, które obejmują modele UML odzwierciedlają dokładnie jednostki świata rzeczywistego. To znaczy, że obiektowo zorientowane modele są bardziej konkretne i lepiej opisane i ogólnie bardziej elastyczne i intuicyjne. Weźmy za przykład obiektowo zorientowany opis roli pracownika. Prawdopodobnie zawarłby informację o zachowaniu, taką jak odpowiedzialność za prace, szacunek do innych pracowników, opis pracy, etc. 4. UML opisuje procesy biznesu zarówno strukturalnie i dynamicznie Biznes staje się bardziej zautomatyzowany, bardziej powiązane systemy oprogramowania tworzą rdzeń biznesowej wartości, która jest dostarczana klientom. Zrozumienie jak te przeplatane systemy oddziałują wzajemnie na siebie i jak skierować ich pomyślny rozwój w odpowiedzi na zmieniający się krajobraz biznesu prowadzi do zdecydowanego sukcesu. Wartość UML w tym kontekście jest taka, że pozwala patrzeć na rzeczy wewnątrz biznesu zarówno strukturalnie, jak i dynamicznie. UML ma wiele różnych typów diagramów, które pozwalają reprezentować informację z różnych punktów widzenia, a to całkowicie opisze twój biznes i dostarczy istotnych informacji. Przypadki użycia UML (USE CASES) opisują procesy biznesowe w taki sposób w jaki aktorzy (klienci) go widzą, by osiągnąć jakiś cel. Przypadki użycia opisują kompletny proces biznesowy od jego początku do końca, od zewnętrznej perspektywy. To jest w bezpośrednim kontraście do wielu tradycyjnych metodologii modelowania biznesowego, które rozkładają albo dzielą procesy wzdłuż linii funkcjonalnych. Przy takiej dekompozycji całość nie jest potrzebna, by zsumować części. Opisy procesów stają się odizolowane od siebie i ich relacje stają się mniej oczywiste. Kiedy to się dzieje, korzyść jest mniej wymierna i ich wartość staje się bardziej subiektywna. Wartość UML staje się oczywista kiedy kierujesz modelowanie biznesowe wzorując się na problemie biznesowym. Z konwencjonalnymi metodologiami, kluczowe zagadnienia mogą 17

18 łatwo zostać źle zinterpretowane, ponieważ te metodologie często przeoczają dynamiczne związki, które wpływają na proces. UML, w kontraście, dostarcza bogatych alternatyw dla opisów dynamicznych i połączeń świata rzeczywistego, które są częścią i rozdzielają nowoczesne systemy biznesowe. Różnorakie spojrzenia UML na model naprawdę pomagają zrozumieć problem z różnych stron. Ponadto, ponieważ UML dostarcza wspólnego języka i współdzielonych podstaw dla dyskusji między sztabem rozwojowym a biznesowym, nie ma potrzeby by tłumaczyć model na słowa. 5. UML pomoże skupić się na kliencie Metodologia modelowanie biznesowego UML obraca się wokół biznesowego użycia przypadków, które podkreślają jaką biznesową wartość dostarcza się do klienta. Ta perspektywa pomaga pojmować zewnętrzny widok systemu, który tworzysz. To jest szczególnie skuteczne i użyteczne podejście w kontekście biznesowym, gdzie zewnętrzne skupienie jest bardziej decydujące o sukcesie. W UML, biznesowe użycie przypadków jest zdefiniowane jako Sekwencja zadań przedstawionych przez biznes, które uzyskują możliwy do zaobserwowania rezultat wartości dla każdego klienta biznesowego. Procesy biznesowe są jak zautomatyzowane systemy biznesowe; obejmują konkretne zachowanie organizacji. Ponieważ procesy biznesowe są środkami developingu ważnymi dla klientów, sukces organizacji zależy całkowicie na przedstawieniu jego procesu biznesowego (czy są zautomatyzowane czy nie). Biznesowe przypadki użycia UML są zbudowane na podstawie przekazania założenia jak działa system i jak klient będzie go używać. 6. UML pomoże wyprowadzić wymagania systemowe Z jego bogatymi opisami relacji pomiędzy komponentami, aktorami biznesowymi i innymi jednostkami, UML sprawia, że jest to łatwiejsze niż inne podejścia do modelowania, by zidentyfikować, gdzie system najlepiej pasuje w biznesowym kontekście. To, w rezultacie umożliwia większą czytelność walidacji wymagań systemowych. Końcowym efektem jest działający system biznesowy, który rozwiązuje specyficzne procesy biznesu. Napotykając realne potrzeby dostarcza optymalną wartość do klientów. Ponadto biznesowe modele bazujące na UML, które Twoja grupa stworzyła mogą przetrwać jako bezpośrednie wkłady do potrzebnych modeli. 18

19 The Rational Unified Process (RUP) dostarcza bezpośrednie mapowanie pomiędzy modelem biznesowym UML a analitycznymi wymaganiami modelu. 19

20 BPMN Business Process Management Initiative (BPMI) rozwinęła Business Process Modeling Notation. Specyfikacja BPMN 1.0 została wydana w Maju 2004 roku. Specyfikacja ta prezentuje ponad dwuletnia pracę BPMI Notation Working Group. Celem pracy BPMN było dostarczenie notacji, która będzie łatwa do zrozumienia przez wszystkich biznesowych użytkowników, od biznesowych analityków, którzy tworzą początkowe szkice procesów do developerów odpowiedzialnych za implementację technologii, a w końcu do ludzi, którzy będą nią zarządzać i monitorować procesy. BPMN definiuje Biznesowy Diagram Procesu (Business Process Diagram BPD), który bazuje na technice diagramów przepływu, dopasowanej do tworzenia graficznych modeli operacji procesów biznesowych. Biznesowy Diagram Procesu (BPD) więc jest siecią graficznych obiektów, które są aktywnościami/zadaniami (np. praca) i kontrolami przepływu, które definiują kolejność wykonywania. Podstawy BPMN Biznesowy Diagram Procesu (BPD) jest złożony z kompletu graficznych elementów. Te elementy umożliwiają łatwy rozwój prostych diagramów, które wyglądają znajomo dla większości analityków biznesowych. Elementy zostały tak wybrane, aby były łatwe do rozróżnienia i wykorzystywały znane już kształty, np. zadania to prostokąty, romby to decyzje. Powinno zostać podkreślone, że jednym z celów dla twórców BPMN jest stworzenie prostego mechanizmu do tworzenia modeli procesów biznesowych a jednocześnie w być wstanie radzić ze złożonością właściwą do procesów biznesu. Propozycja do podjęcia tych dwóch kolidujących wymagań było uporządkowanie graficznych aspektów notacji w określone kategorie. To dostarczyło małego kompletu kategorii notacji, wiec czytelnik BPD mógł łatwo rozpoznawać podstawowe typy elementów i rozumieć diagram. W podstawowych kategoriach elementów, dodatkowe warianty i informacje mogą być dodane by wspierać wymagania dla złożoności bez znacznego zmieniania prostego wyglądu diagramu. Czterema podstawowymi kategoriami elementów są: - obiekty przepływu, - obiekty łączące, - swimlane (z Ang.), - artefakt. 20

21 Obiekty przepływu PBD posiada mały komplet trzech rdzennych elementów, tak więc modelujący nie musi się uczyć i rozpoznawać wielkiej ilości różnych figur. Tymi trzema obiektami przepływu są: Zdarzenie Zdarzenie jest reprezentowane przez okrąg i coś co dzieję się podczas biegu procesu biznesowego. Te zdarzenia oddziaływają na przepływ procesu i zazwyczaj maja przyczynę i rezultat. Są trzy typy zdarzeń : start, etap pośredni i koniec (patrz na figury, zaczynając od lewej) Aktywność Aktywność jest reprezentowana przez prostokąt z zaokrąglonymi rogami i jest ogólnym określeniem pracy, która jest wykonywana. Aktywność może być atomowa lub nieatomowa (w tym znaczeniu złożoność). Typami aktywności są zadanie i pod-proces. Pod-proces jest dystyngowany przez znak plusa po środku dna figury. Przejście Przejście jest reprezentowane przez romb i jest używane do kontrolowania rozbieżności i zbieżności przepływu sekwencji. Do tego stopnia, że rozpoznaje tradycyjne decyzje, takie jak rozwidlenie, łączenie, dołączanie dróg. Wewnętrzne znaki wskazują na typ kontroli zachowania. 21

22 Obiekty łączące Obiekty przepływu są połączone w diagram, aby stworzyć główny szkielet struktury procesu biznesowego. Są trzy obiekty łączące które realizują tę funkcje. Te łączniki to: Kolejność przepływu Kolejność przepływu jest reprezentowana przez strzałkę z wypełnionym grotem (patrz na ilustracje po prawej) i jest używana do pokazania kolejności (sekwencji) aktywności, która będzie wykonywana w procesie. Przepływ komunikatu Przepływ komunikatu jest reprezentowany przez strzałkę rysowaną linią przerywana z niewypełnionym grotem (patrz na ilustracje po prawej) i jest używana do pokazania jak przepływają komunikaty pomiędzy dwoma oddzielnymi uczestnikami procesu, którzy je wysyłają i odbierają. W BPMN dwa oddzielne Pool (z Ang.) będą oznaczać dwóch uczestników. Asocjacja Asocjacja jest reprezentowana przez kropkowaną strzałkę i grot z lini (patrz na ilustracje po prawej), jest wykorzystywana do skojarzenia danych, tekstu i innych artefaktów z obiektami przepływu. Asocjacje są używane do pokazania wejść i wyjść w czynnościach. Dla osoby tworzącej model, która wymaga lub pragnie niskiego poziomu precyzji do stworzenia modelu procesu do dokumentacji i do celów komunikacji, rdzenne elementy oraz 22

23 łączniki dostarczą możliwości łatwego stworzenia zrozumiałych diagramów (przykład poniżej). Rys Przykład prostego procesu biznesowego Dla osoby tworzącej model, która wymaga większego poziomu precyzji do stworzenia modelu, który będzie poddany szczegółowej analizie może dodać dodatkowe detale do rdzennych elementów i pokazać je poprzez wewnętrzne znaki. (przykład poniżej) Rys Część procesu z większą szczegółowością 23

24 Swimlane Wiele metodologii modelowania procesu wykorzystuje koncepcje swimlane jako mechanizmu do organizacji aktywności jako oddzielnych wizualnych kategorii w porządku ilustrującym różne funkcjonalne zdolności lub odpowiedzialności. BPMN wspiera dwie główne konstrukcje. Dwa typy swimlane w BPD to: Pool Pool reprezentuje uczestnika w procesie. Poza tym występuje jako graficzna otoczka dla przegrodowych zbiorów aktywności z innych Pool ow (patrz na ilustracje po prawej) Lane Lane jest pod-przegrodą w Pool u i będzie obejmować cała długość Pool a, zarówno w płaszczyźnie pionowej i poziomej (patrz na ilustracje po prawej). Lane są używane do organizowania i klasyfikowania aktywności. Pool e są używane kiedy diagram obejmuje dwie oddzielne jednostki biznesowe lub dwóch uczestników i są fizycznie oddzielone w diagramie. Aktywności w oddzielnych Pool ach są rozpatrywane w swoich otoczkach procesu. W ten sposób kolejność przepływu może nie przekraczać obszaru Pool a. Przepływ komunikatu jest zdefiniowany jako mechanizm będący do pokazania komunikacji pomiędzy dwoma uczestnikami, i w ten sposób, muszą zapewniać połączenie pomiędzy dwoma Pool ami (albo obiektami w Pool ach). 24

25 Rys Przykład BPD z użyciem Pool Lane są bardziej powiązane do tradycyjnego modelowania przy użyciu metodologii swimlane. Lane są przeważnie używane do oddzielenia aktywności powiązanej ze specyficzną funkcją lub rolą w firmie (Patrz na ilustracje poniżej). Kolejność przepływu może przekraczać obszar Lane w Pool u, ale Przepływ komunikatu może nie być użyty pomiędzy obiektami przepływu w Lane w tych samych Pool ach. Rys Segment procesu z Lane 25

26 Artefakty BPMN został stworzony, aby umożliwić modelującemu i narzędziom modelującym na pewną elastyczność w rozszerzaniu podstawowych notacji i dostarczaniu możliwości do dodatkowego kontekstu przeznaczania do specyficznych sytuacji modelowych, takich jak pion rynkowy (np. bankowość). Jakakolwiek ilość artefaktów może być dodana do diagramu jako stosowny dla kontekstu procesu biznesowego jaki jest modelowany. Obecna wersja specyfikacji BPMB predefiniuje tylko trzy typy artefaktów BPD. Są to: Obiekt Danych Obiekty danych to mechanizmy do pokazania jak dane są wymagane lub produkowane przez aktywności. Są połączone do aktywności przez asocjacje. Grupa Grupa jest reprezentowana jako prostokąt z zaokrąglonymi rogami, rysowane linią przerywaną (patrz ilustracja po prawej). Grupowanie może być używane przy dokumentowaniu lub analizowaniu celów. Nie mają wpływu na przepływ sekwencji. Adnotacja Adnotacje są po to, by zapewnić dodatkową informację tekstową dla osoby czytającej diagram BPMN (patrz ilustracja po prawej). Nazwa (Wyrażenie) Tekst Adnotacji Modelujący może stworzyć swoje typy artefaktów, dzięki czemu może oddać wecie detali o tym jak proces przebiega, dość często do pokazania wejść i wyjść aktywności w procesie. Jednakże, podstawowa struktura procesu, określana jako Aktywności, Przejście, Kolejność przepływu, nie zmieniały się w dodatku z Artefaktami w diagramu jak można to zobaczyć porównując rys i rys