Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00338 007736 18454778 na godz. na dobę w sumie
Procesy biznesowe w praktyce. Projektowanie, testowanie i optymalizacja - książka
Procesy biznesowe w praktyce. Projektowanie, testowanie i optymalizacja - książka
Autor: Liczba stron: 376
Wydawca: Onepress Język publikacji: polski
ISBN: 978-83-246-7120-5 Data wydania:
Lektor:
Kategoria: ebooki >> poradniki >> e-biznes
Porównaj ceny (książka, ebook, audiobook).

Biznes procesowo uporządkowany

W tej książce, napisanej przez specjalistę informatyka od piętnastu lat zajmującego się procesami biznesowymi, poznasz zagadnienia dotyczące tych procesów z perspektywy praktycznej. Może ona okazać się tym cenniejsza, że autor opisuje, jak to wszystko działa w polskich warunkach, a ponadto omawia zagadnienia dotyczące zarówno przedsiębiorstw komercyjnych, jak i urzędów publicznych. Dlatego właśnie należy spodziewać się raczej porad praktycznych niż wykładu o charakterze akademickim. Miejsce naukowych definicji zajmuje praktyka zdobyta dzięki latom doświadczeń i... popełnionym przez autora błędom, na których teraz możesz się uczyć.

Marek Piotrowski skupia się na czterech blokach zagadnień. Rozdziały od 2. do 5. traktują o formalnych aspektach projektowania procesów, o procesie w ogóle, o używanych notacjach i rodzajach obiegów. Następna część zawiera omówienie praktycznych zagadnień związanych z procesami biznesowymi, najczęściej popełnianymi błędami, rozwiązaniami typowych problemów spotykanych w warunkach polskich przedsiębiorstw i optymalizacją. Część trzecia mówi o testowaniu i pomiarach procesów. Ostatni, 12. rozdział mówi o tym, jakie zmiany w organizacji implikuje wprowadzenie struktury zorientowanej na procesy.

Marek Piotrowski - absolwent Politechniki Gdańskiej, od dwudziestu trzech lat zajmujący się informatyką, od piętnastu - procesami biznesowymi w ramach informatyki. W 2007 roku ukazała się jego pierwsza książka: BPMN - notacja modelowania procesów biznesowych.



Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Redaktor prowadzący: Magdalena Dragon-Philipczyk Projekt okładki: Jan Paluch Fotografia na okładce została wykorzystana za zgodą Shutterstock. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: onepress@onepress.pl WWW: http://onepress.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://onepress.pl/user/opinie/probiz Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. ISBN: 978-83-246-7120-5 Copyright © Helion 2014 Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Wstęp ...................................................................................................... 11 Rozdział 1. Proces ..................................................................................................... 13 1.1. Składowe opisu procesu ......................................................................................15 1.2. Elementy określające proces ...............................................................................16 Rozdział 2. Notacja BPMN ...................................................................................... 19 2.1. Rodzaje zadań .......................................................................................................22 2.2. Rozgałęzianie procesu ..........................................................................................23 2.2.1. Bramka ALBO (XOR) ........................................................................... 23 2.2.2. Bramka LUB (OR) ................................................................................. 25 2.2.3. Bramka I (AND) .................................................................................... 25 2.2.4. Bramka złożona (COMPLEX) .............................................................. 27 2.3. Symbole zdarzeń ...................................................................................................27 2.3.1. Grubość i rodzaj obramowania okręgu, czyli symbole zdarzeń .......... 27 2.3.2. Styl linii obramowania okręgu, czyli zdarzenia przerywające i nieprzerywające .................................. 37 2.3.3. Ikona wewnątrz symbolu, czyli oznaczenie czynności ........................ 40 2.3.4. Rodzaj ikony (zdarzenie przyjęcia/zdarzenie wysłania) ..................... 40 2.4. Łączenie gałęzi procesu .......................................................................................47 2.4.1. Bramka łącząca ALBO (XOR) .............................................................. 47 2.4.2. Bramka łącząca I (AND) ....................................................................... 47 2.4.3. Bramka łącząca LUB (OR) .................................................................... 49 2.4.4. Bramka łącząca złożona (COMPLEX) ................................................. 49 2.4.5. Łączenie bez bramek .............................................................................. 53 2.5. Określanie uczestników procesu ........................................................................54 2.5.1. Przykład opisu ........................................................................................ 54 2.5.2. Dlaczego warto opisywać proces za pomocą ról, a nie nazwisk? ............ 55 Kup książkęPoleć książkę 6 (cid:126) Spis treści 2.6. Reprezentacja interakcji z podmiotami zewnętrznymi ...................................59 2.6.1. Baseny ..................................................................................................... 59 2.6.2. Procesy prywatne i publiczne ................................................................ 59 2.6.3. Kolaboracja i konwersacja .................................................................... 61 2.6.4. Podmioty wieloinstancyjne .................................................................... 66 2.7. Podprocesy ............................................................................................................68 2.7.1. Podprocesy osadzone .............................................................................. 68 2.7.2. Podprocesy zdarzeniowe ........................................................................ 73 2.7.3. Podprocesy niesekwencyjne (doraźne) .................................................. 75 2.7.4. Podproces Pętla ...................................................................................... 77 2.7.5. Podprocesy wieloinstancyjne ................................................................. 77 2.8. Pomocnicze elementy notacji .............................................................................86 2.8.1. Obiekty obrazujące dane ....................................................................... 86 2.8.2. Grupy ...................................................................................................... 91 2.8.3. Symbole prywatne .................................................................................. 91 2.8.4. Adnotacje ................................................................................................ 92 2.9. Choreografie .........................................................................................................94 2.9.1. Podstawowe pojęcia ............................................................................... 94 2.9.2. Choreografia złożona ............................................................................. 96 2.9.3. Użycie symboli zwielokratniających ..................................................... 97 2.9.4. Przykład zastosowania .......................................................................... 97 2.9.5. Sekwencje poprawne i niepoprawne ..................................................... 98 2.9.6. Użycie bramek w diagramach choreografii ........................................ 101 2.9.7. Zdarzenia w choreografiach ................................................................ 109 2.9.8. Wykorzystanie choreografii w diagramie kolaboracji (współpracy) .... 110 2.9.9. Posługiwanie się globalną choreografią lub globalnym zadaniem choreografii ................................................ 110 2.10. Dla porządku — podsumowanie ......................................................................110 Rozdział 3. Pozostałe notacje .................................................................................115 3.1. UML .....................................................................................................................116 3.1.1. Diagram czynności ............................................................................... 116 3.1.2. Diagram stanów ................................................................................... 122 Interakcje po raz pierwszy, czyli diagram sekwencji (przebiegu) ..... 124 3.1.3. Interakcje po raz drugi, czyli diagram komunikacji .......................... 129 3.1.4. Interakcje po raz trzeci, czyli diagram czasowy ................................. 130 3.1.5. 3.1.6. Interakcje po raz czwarty, czyli diagram przeglądu interakcji ......... 131 3.1.7. Diagram przypadków użycia .............................................................. 132 3.2. RAD ......................................................................................................................138 3.3. Przypadki użycia .................................................................................................139 3.4. Flowchart .............................................................................................................144 Kup książkęPoleć książkę Spis treści (cid:126) 7 3.5. Diagram przepływu danych (DFD) .................................................................147 3.6. Diagram stanów ..................................................................................................149 3.7. Diagramy księgi jakości .....................................................................................151 3.8. Service blueprint .................................................................................................152 3.9. Nierysunkowe metody zapisu ..........................................................................153 3.9.1. Macierz RACI ....................................................................................... 155 3.9.2. Macierz SIPOC ..................................................................................... 155 Rozdział 4. Tworzenie opisu procesu ...................................................................157 4.1. Identyfikacja procesów ......................................................................................157 4.1.1. Analiza dokumentacji biznesowej ...................................................... 157 4.1.2. Kwestionariusze ................................................................................... 157 4.1.3. Wywiad ................................................................................................. 159 4.1.4. User stories ............................................................................................ 159 4.1.5. Warsztaty ............................................................................................. 160 4.1.6. Obserwacja (autorejestracja bądź śledzenie) ..................................... 161 4.1.7. Praktyka (terminowanie) .................................................................... 162 4.1.8. Metoda trawnika — dekretacja .......................................................... 162 4.1.9. Przedstawiciel klienta .......................................................................... 162 4.1.10. Prototypowanie .................................................................................... 163 4.1.11. Podsumowanie ..................................................................................... 164 4.2. Sporządzenie opisu procesu ..............................................................................166 4.2.1. Metryka dokumentu ............................................................................ 166 4.2.2. Wstęp .................................................................................................... 166 4.2.3. Opis procesu „as is” .............................................................................. 167 4.2.4. Opis procesu „to be” ............................................................................. 177 4.2.5. Zdefiniowanie procesu to dopiero początek ....................................... 181 4.3. Sporządzanie schematu procesu na podstawie diagramu struktury produktów ..........................................................................................182 Rozdział 5. Rodzaje obiegów .................................................................................191 5.1. Podział ze względu na sposób definiowania ścieżki obiegu .........................191 5.1.1. Dekretacja ............................................................................................. 191 5.1.2. Sekwencje zdarzeń — już nie dekretacja, jeszcze nie workflow ........ 193 5.1.3. Obieg typu workflow ............................................................................ 199 5.1.4. Obieg stanowy ...................................................................................... 202 5.1.5. Obieg definiowany za pomocą silnika reguł ....................................... 204 5.2. Podział procesów ze względu na medium obiegu .........................................207 Rozdział 6. Najczęstsze błędy ................................................................................209 6.1. Błąd typu „Przetwarzanie gniazdowe” ............................................................209 6.2. Błąd typu „Szybka pętla” ...................................................................................210 Kup książkęPoleć książkę 8 (cid:126) Spis treści 6.3. Błąd typu „Bezkresna pętla” ..............................................................................213 6.3.1. Schemat z wykorzystaniem zdarzenia pośredniego ........................... 214 6.3.2. Schemat z rozszerzoną pętlą ................................................................ 215 6.4. Gdy „tak” spotyka się z „nie”, czyli błąd zbędnej decyzji .............................216 6.5. Drobne błędy notacyjne ....................................................................................219 6.5.1. Cancel zamiast znaku uniwersalnego ................................................ 219 6.5.2. Oczekiwanie na zdarzenie Cancel ...................................................... 219 6.5.3. Nieprawidłowe warunki bramki ALBO (XOR) ................................. 220 6.5.4. Nieszkodliwe błędy ............................................................................... 222 6.5.5. Błąd czy nie błąd? ................................................................................ 222 Rozdział 7. Typowe zagadnienia ...........................................................................225 7.1. Kanały komunikacji systemu kancelaryjnego z otoczeniem ........................225 7.2. Wpływ dokumentu papierowego .....................................................................225 7.2.1. Przypadek trywialny ............................................................................ 225 7.2.2. Przypadek trywialny z połączeniem kancelarii z archiwum ............. 229 7.2.3. Rozwiązanie ze skanerem masowym i rozproszonym opisem dokumentu .................................................... 230 7.2.4. Rozwiązanie z kodem kreskowym ....................................................... 234 7.2.5. Rozwiązanie z kodem kreskowym i archiwizacją w kartonach......... 235 7.2.6. Rozwiązanie z rejestracją przesyłek .................................................... 236 7.2.7. Przesyłki rejestrowane ......................................................................... 239 7.3. Wpływ dokumentu uzupełniającego sprawę .................................................240 7.3.1. Kojarzenie na podstawie numeru sprawy .......................................... 242 7.3.2. Kojarzenie ręczne ................................................................................. 242 7.4. Wpływ dokumentu papierowego uzupełniającego przepływ elektroniczny ......................................................................................243 7.4.1. Wersja procesu bez automatyzacji ..................................................... 244 7.4.2. Wersja z wykorzystaniem kodu kreskowego ...................................... 245 7.4.3. Wersja z kodem dwuwymiarowym .................................................... 248 7.5. Wysyłka dokumentu papierowego ....................................................................252 7.5.1. Wysyłka jednego dokumentu w jednej kopercie ................................ 252 7.5.2. Kilka dokumentów w jednej przesyłce ................................................ 254 7.6. Jeszcze o przyjmowaniu dokumentów .............................................................261 Rozdział 8. Niektóre zagadnienia optymalizacyjne ............................................263 8.1. Kształtowanie przebiegu procesu w zależności od priorytetów ..................263 8.1.1. Topologia minimalizująca czas trwania procesu .............................. 263 8.1.2. Topologia minimalizująca korespondencję ........................................ 265 8.1.3. Topologia minimalizująca nakład pracy ........................................... 265 Kup książkęPoleć książkę Spis treści (cid:126) 9 8.2. Metoda ścieżki krytycznej w wydaniu BPM ...................................................266 8.2.1. Czym jest ścieżka krytyczna i dlaczego jej wyznaczenie 8.5.1. 8.5.2. jest tak ważne? ...................................................................................... 267 8.2.2. Wyznaczanie ścieżki krytycznej .......................................................... 267 8.3. Pobieranie zadań przez wykonawców ze wspólnej puli ................................272 8.4. Przydział wykonawców do zadań przy przetwarzaniu masowym ..............274 8.5. Priorytetyzacja ....................................................................................................279 [Ważność sprawy] ................................................................................ 281 [Liczba dni zapasu] .............................................................................. 281 8.6. Zjawisko wąskiego gardła ..................................................................................282 8.7. Doskonalenie procesów .....................................................................................284 Rozdział 9. Testowanie procesów .........................................................................287 9.1. Najprościej ..........................................................................................................287 9.1.1. Opis systemu przy użyciu diagramu stanów ...................................... 287 9.1.2. Co to wszystko ma wspólnego z testami? ............................................ 289 9.1.3. Dla ciekawskich, czyli dlaczego zamieszczone diagramy nazwałem stanami uproszczonymi? ................................................... 290 9.2. Nieco trudniejszy przykład ...............................................................................292 9.3. Definiowanie kompletnego testu za pomocą schematu BPMN ..................296 9.3.1. Opis rozważanego procesu .................................................................. 296 9.3.2. Etap 1. Porządkowanie schematu ....................................................... 297 9.3.3. Etap 2. Jawne wprowadzenie działań wyzwalanych zdarzeniami ... 300 9.3.4. Etap 3. Wprowadzenie na schemat wyjść niejawnych ...................... 303 9.3.5. Etap 4. Zaznaczenie literami kroków, w których następuje rozgałęzienie ......................................................................................... 306 9.3.6. Etap 5. Zaznaczenie działań wewnętrznych w krokach .................... 308 9.3.7. Etap 6. Opisanie kryteriów powodzenia dla zdarzeń wewnętrznych .... 310 9.3.8. Etap 7. Specyfikacja rozgałęzień ......................................................... 311 9.3.9. Etap 8. Sporządzenie szkieletu tablicy kontrolnej .............................. 311 9.3.10. Etap 9. Definiowanie przebiegów testowych ...................................... 314 9.3.11. Etap 10. Sporządzenie formularza testów .......................................... 328 9.4. Przeprowadzanie testów ....................................................................................333 Rozdział 10. Pomiary ................................................................................................335 10.1. Po co definiować wskaźniki? ...........................................................................335 10.2. Cechy dobrego wskaźnika ................................................................................336 10.2.1. Cechy techniczne ................................................................................. 336 10.2.2. Merytoryczne cechy wskaźników ....................................................... 337 10.3. Wpływ pomiarów na proces ............................................................................340 Kup książkęPoleć książkę 10 (cid:126) Spis treści 10.4. Proces definiowania wskaźników ...................................................................340 10.5. Rodzaje mierników ...........................................................................................340 10.6. Mierniki niezmienne (z założenia) .................................................................343 10.7. Aspekt ludzki .....................................................................................................343 Rozdział 11. Na koniec: trochę ideologii, czyli o procesach w ogóle ..................345 11.1. Procesowa struktura przedsiębiorstwa i jej skutki, czyli po co w ogóle wdrażać procesy biznesowe ...........................................346 11.1.1. Podejście departamentowe a podejście procesowe ............................ 347 11.1.2. Firma zorientowana procesowo ......................................................... 352 11.1.3. IT — integracja istniejących w firmie systemów informatycznych . 356 11.1.4. Wymuszanie stosowania procedur jakości ....................................... 358 11.1.5. Korzyści na poziomie stanowiska pracy ............................................ 359 11.2. Model dojrzałości procesowej organizacji CMMI ........................................359 11.3. Zmiany, zmiany, zmiany… ..............................................................................360 Dodatek A ..................................................................................................................363 A.1. Rozdzielczości skanerów potrzebne do skanowania lub skutecznego fotografowania dokumentów ...........................................................................363 A.2. Zestaw symboli BPMN ......................................................................................364 A.3. Wybrane symbole UML ....................................................................................365 A.4. Wybrane symbole UML ....................................................................................366 A.5. Wybrane symbole RAD .....................................................................................366 A.6. Wybrane symbole flowchart .............................................................................367 A.7. Wybrane symbole stosowane w księgach jakości ..........................................368 A.8. Inne symbole spotykane na diagramach procesów .......................................369 Dodatek B Zalecana lektura ..................................................................................371 Kup książkęPoleć książkę Rozdział 3. Pozostałe notacje Rozdział ma na celu przegląd najpopularniejszych (poza BPMN) notacji, które są stosowane do opisu procesów biznesowych. Ich znajomość, choćby pobieżna, jest dla analityka nie- zbędna — nie tylko dlatego, że daje szerszą perspektywę, ale przede wszystkim dlatego, że nasi klienci korzystają z wielu różnych notacji (a nie byłoby dobrze, gdyby analityk pro- cesów nie potrafił zrozumieć dostarczonych materiałów…). TYLKO DLA PRYMUSÓW, CZYLI TEORETYCZNIE O NOTACJACH Aby notacja była kompletna, powinna posiadać swoją semantykę, syntaktykę i pragmatykę (razem nazywane semiotyką). Pojęcia te powstały w odniesieniu do języka. Semantyka służy do określenia znaków (wyrażeń) występują- cych w języku, syntaktyka pokazuje, jak je łączyć. A czym zajmuje się pragmatyka? Określa, „jak stosować” język w kontekście pojęć, przyzwyczajeń i sposobu myślenia jego użytkowników. Profesor Jacek Malinowski podaje przykład prostego pytania, które na gruncie semantyki i syntaktyki (bez pragmatyki) byłoby niezrozumiałe: Czy byłby pan tak miły i powiedział mi, gdzie jest najbliższy postój taksówek? „Biegła w problematyce logicznej osoba rozpozna to pytanie, jako pytanie rozstrzygnięcia. Ma ona pod ręką odpowiednią teorię pytań tego rodzaju, i wie, że pytający spodziewa się od niej odpowiedzi: »tak« bądź »nie«. Rozpozna również od razu fakt, że pytanie to ma presupozycję, iż pytany zna odpowiedź — wie, gdzie jest najbliższy postój taksówek. Jednak logiczna analiza tego pytania, nawet jeśli byłaby poprawna z punktu widzenia logiki, nie daje nam nawet cienia szansy na poprawną odpowiedź na to pytanie. Wszyscy wiemy bowiem, że pytający nie spodziewa się odpowiedzi o formie »tak« lub »nie«. Powyższy problem, pojawiający się w opisanej sytuacji, zawiera różnicę pomiędzy dosłownym znaczeniem oraz znaczeniem sugerowanym przez mówiącego. Zamierzone znaczenie jest znane wszystkim kompetentnym użytkownikom języka polskiego: »Gdzie jest najbliższy postój taksówek«”1. Jak rozumieć określenia „semantyka”, „syntaktyka” i „pragmatyka” w odniesieniu do notacji? Semantyka notacji (w uproszczeniu) mówi o symbolach, jakie są stosowane w notacji, i ich znaczeniu. Syntaktyka opisuje sposób, w jaki można tych symboli używać, jak je łączyć i budować z nich konstrukcje. Sto- sunkowo najmniej rozumiane jest pojęcie „pragmatyka notacji”. Pragmatyka opisuje, w jaki sposób stosować symbole i konstrukcje do opisu rzeczywistości. 1 J. Malinowski, Pragmatyczne interpretacje wypowiedzi, Instytut Filozofii i Socjologii PAN, cytat za: http://www.home.umk.pl/~jacekm/pragpol.pdf [dostęp: 19 maja 2013]. Kup książkęPoleć książkę 116 (cid:126) Rozdział 3. Pozostałe notacje Oczywiście, semantyka czy nawet reguły syntaktyczne są znacznie prostsze do przekazania. Można się ich po prostu nauczyć i — po nabyciu pewnej wprawy — poprawnie z nich korzystać. Pragmatyka jest trudniejsza do przekazania (a tym samym do przyswojenia). Umiejętność jej stosowania nabywa się w trakcie długoletniej praktyki. Można zaryzykować twierdzenie, że o ile semantyka i syntaktyka tworzą rzemiosło, to stosowanie pragmatyki jest sztuką. 3.1. UML Notacja UML (ang. Unified Modeling Language — zunifikowany język modelowania), choć stworzona do modelowania systemów informatycznych, zawiera kilka diagramów przydat- nych przy modelowaniu procesów2. Ponieważ nie zamierzam przeprowadzać tutaj kur- su UML, ograniczę się jedynie do omówienia tych „procesowych” diagramów (w termi- nologii UML nazywanych „diagramami zachowań”) oraz diagramu przypadków użycia. Diagramy „procesowe” UML przedstawiam, ponieważ opis procesów za pomocą UML jest wymagany przez nie- których klientów. Dodam, że robię to nieco wbrew sobie — UML nie nadaje się do tego celu, gdyż został stwo- rzony do opisu systemów w świecie obiektów, a nie do opisywania procesów biznesowych. 3.1.1. Diagram czynności Diagram czynności służy do przedstawienia dynamiki systemu, a dokładniej do zaprezen- towania następstwa czynności wykonywanych w celu realizacji zadań zleconych przez akto- rów. Jest on podobny do definicji procesu w BPMN3 — opisuje odpowiedzialność za po- szczególne fazy procesu oraz ukazuje następstwo czynności. Podstawowe symbole pokazano w tabeli 3.1. Tych kilka znaków pozwala już na narysowanie prostego, nierozgałęzionego procesu (rysunek 3.1). Następnym etapem jest zastosowanie bramek rozdzielających gałęzie procesu. Symbol (romb) i znaczenie symbolu bramki odpowiadają symbolowi i znaczeniu bramki ALBO (XOR) w BPMN (rysunek 3.2A). Łączenie procesu przed Czynnością 4 można także poprawnie narysować z zastoso- waniem bramki łączącej (patrz rysunek 3.2B). Bramce równoległej I (AND) odpowiada w UML pasek synchronizujący. Jego podsta- wowymi zadaniami są rozdzielanie procesu na gałęzie wykonywane równolegle i synchro- nizacja ich ponownego połączenia (rysunek 3.3). 2 Raport Dojrzałość procesowa polskich organizacji przygotowany przez portal procesowcy.pl ujawnił, że UML jest wykorzystywany do modelowania procesów ponad trzy razy rzadziej niż BPMN. 3 Właściwie należałoby napisać, że to BPMN wykazuje podobieństwo do diagramu czynności — notacja UML jest znacznie starsza i niewątpliwie to z niej pochodzą pewne formalne aspekty obecne podczas projekto- wania notacji BPMN. Kup książkęPoleć książkę 3.1. UML (cid:126) 117 TABELA 3.1. Podstawowe symbole diagramu czynności Początek procesu Czynność — reprezentuje funkcjonalność realizowaną w kolejnym kroku przez system Akcja — „atomowa” (niepodzielna) czynność. Tego symbolu używa się raczej rzadko, zwykle wówczas, gdy zachodzi potrzeba dokładnej dekompozycji skomplikowanej czynności Przejście — przekazanie sterowania pomiędzy czynnościami Koniec procesu RYSUNEK 3.1. Przykład prostego procesu Pasek synchronizujący, choć funkcjonalnie odpowiada BMPN-owskiej bramce równo- ległej, w UML bywa stosowany w nieco szerszym zakresie. Na przykład rysunek 3.4 przed- stawia konstrukcję oczekiwania na zdarzenie (tu zdarzenie zegarowe, symbolizowane przez stylizowaną klepsydrę). To oczekiwanie jest realizowane jako synchronizacja procesu ze zdarzeniem. W UML dostępnych jest kilka rodzajów zdarzeń (tabela 3.2). Na rysunku 3.5 zaprezentowano kilka przykładów użycia zdarzeń. Gałęzie równoległe, utworzone w wyniku użycia paska synchronizującego, nie muszą się schodzić ponownie — mogą być kończone niezależnie. Służy do tego symbol zakończenia gałęzi — okrąg z wpisanym krzyżykiem (rysunek 3.6). Formalnie schemat A z rysunku 3.6 jest równoważny schematowi B — zakończenie pro- cesu następuje po zakończeniu wszystkich gałęzi. Nie zawsze jednak równoważność jest tak oczywista, co pokazuje rysunek 3.7. Kup książkęPoleć książkę 118 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.2. Diagram czynności — zastosowanie bramki rozdzielającej Na schemacie występuje zarówno symbol zakończenia procesu, jak i symbol zakończe- nia gałęzi. Jeżeli gałąź c zostanie zakończona przed zakończeniem gałęzi a i b, system za- chowa się w sposób identyczny jak konstrukcje a i b pokazane na rysunku 3.7. Jeśli jed- nak czynności w gałęziach a i b zostaną zakończone przed zakończeniem gałęzi c, proces zostanie zakończony (bez dalszego kompletowania czynności gałęzi c). Niekiedy symbol zakończenia gałęzi może być stosowany w sposób faktycznie zastę- pujący zakończenie procesu. Przykładem takiego zastosowania jest schemat pokazany na rysunku 3.8. System sprawdza uprawnienia osoby próbującej otworzyć sejf elektroniczny — w przypadku braku uprawnień czynność Otwórz sejf nigdy nie zostanie wykonana (a więc praca4 „nie dotrze” do symbolu zakończenia procesu). Proces zostanie zakończony bez- pośrednio po stwierdzeniu braku uprawnień osoby próbującej otworzyć sejf. Następnym symbolem ciekawym dla nas z punktu widzenia procesowego jest punkt syn- chronizacji. Wskazuje on miejsce, w którym dwa równoległe strumienie czynności zostają zsynchronizowane w czasie (rysunek 3.9). Jeżeli w którejkolwiek gałęzi proces dotrze do miejsca związanego z punktem synchro- nizacji, poczeka na drugą gałąź. 4 W tym miejscu użyteczne byłoby pojęcie „token” omówione w podrozdziale „Obieg typu workflow”. Kup książkęPoleć książkę 3.1. UML (cid:126) 119 RYSUNEK 3.3. Rozdzielenie i późniejsza synchronizacja gałęzi procesu przy użyciu paska synchronizującego RYSUNEK 3.4. Proces oczekujący na zdarzenie (czasowe) TABELA 3.2. Symbole zdarzeń w diagramie czynności Zdarzenie czasowe (termin, zdarzenie cykliczne itd.) Zdarzenie mające charakter błędu (wyjątku) Dowolne zdarzenie (może oznaczać zarówno przyjęcie komunikatu, jak i wiadomość o zdarzeniu) Wysyłka komunikatu lub żądania W przytoczonych wyżej diagramach UML nie definiowano wykonawców poszczegól- nych czynności, jednak UML (podobnie jak BPMN) pozwala na zastosowanie pasów pły- wackich dla poszczególnych aktorów procesu (rysunek 3.10). Niekiedy schemat procesu staje się zbyt skomplikowany; na jego czytelność najgorzej wpływają przecięcia linii. Aby temu zaradzić, można skorzystać z symbolu łączenia — jest to okrąg z wpisaną literą. Miejsca z takim samym okręgiem można traktować tak, jakby zostały połączone linią (rysunek 3.11). Kup książkęPoleć książkę 120 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.5. Przykłady zdarzeń: A — odbiór komunikatu, B — wysyłka komunikatu i odebranie odpowiedzi, C — zdarzenie zewnętrzne awaryjnie przerywające proces RYSUNEK 3.6. Zastosowanie znaku zakończenia gałęzi i schemat równoważny Przy okazji wprowadzono nowy symbol — kartkę z zagiętym rogiem — oznaczający komentarz. W przeciwieństwie do BPMN, diagram czynności dopuszcza wprowadzanie symboli obiektów wprost na diagramie obiegu5. z obiektami linią przerywaną. 5 BPMN dopuszcza wykorzystanie takich obiektów przy użyciu symboli dodatkowych, które są połączone Kup książkęPoleć książkę 3.1. UML (cid:126) 121 RYSUNEK 3.7. Schemat z symbolem zakończenia procesu i zakończenia gałęzi RYSUNEK 3.8. Proces obsługi sejfu elektronicznego Schematy pokazane na rysunku 3.12 są równoważne; przepływ obiektu można prawi- dłowo zapisać w każdy z przedstawionych sposobów. Kup książkęPoleć książkę 122 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.9. Punkt synchronizacji — przykład użycia RYSUNEK 3.10. Proces narysowany przy użyciu pasów pływackich dla określenia aktorów poszczególnych czynności 3.1.2. Diagram stanów Kolejny diagram traktuje proces jako automat skończony — tj. układ, który może przyj- mować pewną skończoną (choć niekiedy bardzo dużą) liczbę różnych stanów. Przejścia pomiędzy niektórymi stanami są dozwolone, pomiędzy innymi nie. Diagram stanów jest w pewnym sensie rewersem diagramu czynności; tak jak tamten skupiał się na operacjach, które muszą zostać wykonane, tak diagram stanów skupia się na stanach, jakie osiągnie system w wyniku ich wywołania. Weźmy bardzo prosty schemat procesu handlowego, przedstawiony w postaci diagramu czynności na rysunku 3.13A. Czynności oznaczone są prostokątami o zaokrąglonych rogach. Celem każdej wykonanej czynności jest zmiana stanu procesu. Poszczególne stany są ozna- czone na diagramie czynności tekstem w nawiasach kwadratowych, umieszczonym przy strzałkach oznaczających przejścia pomiędzy operacjami. Po prawej stronie rysunku 3.13 (schemat B) narysowano ten sam proces w postaci dia- gramu stanów. Jak widać, jest tu odwrotnie niż na diagramie czynności — prostokąty sym- bolizują osiągnięte stany, zaś strzałki — czynności powodujące przejście pomiędzy stanami6. 6 Do tematu diagramów stanu powrócimy jeszcze przy omawianiu testowania procesów. Kup książkęPoleć książkę 3.1. UML (cid:126) 123 RYSUNEK 3.11. Upraszczanie procesu z wykorzystaniem symbolu łączenia RYSUNEK 3.12. Przepływ obiektów Kup książkęPoleć książkę 124 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.13. Prosty proces handlowy: A — diagram czynności, B — diagram stanów 3.1.3. Interakcje po raz pierwszy, czyli diagram sekwencji (przebiegu) Od razu na wstępie chciałbym zaznaczyć, że opisuję ten diagram w kontekście procesów wbrew mojemu najgłębszemu przekonaniu, iż nie nadaje się on do opisu procesów bizne- sowych. Robię to tylko dlatego, że diagram ten bywa wymieniany w specyfikacjach wyma- gań pochodzących od klientów. 3.1.3.1. Klasyfikatory Diagram sekwencji skupia się na przedstawieniu komunikatów pomiędzy instancjami klasyfikatorów. Czym są klasyfikatory? Mogą to być: Kup książkęPoleć książkę 3.1. UML (cid:126) 125 (cid:120) aktorzy, (cid:120) przypadki użycia, (cid:120) klasy (instancją jest obiekt), (cid:120) interfejsy, (cid:120) pakiety, (cid:120) komponenty. Stosowane są cztery rodzaje symboli7. Wymieniono je w tabeli 3.3. TABELA 3.3. Symbole klasyfikatorów Aktor Obiekt zewnętrzny wobec systemu. Jeżeli aktor reprezentuje większą grupę (np. w każdym procesie jest jeden klient, ale niemal za każdym razem inny), wówczas można to zaznaczyć, wpisując cięciwę w okrąg oznaczający głowę. Klasa graniczna Reprezentuje interfejs pomiędzy systemem a bytami poza nim. Obiekt klasy danych Reprezentuje dane w systemie. Obiekt klasy sterującej Steruje działaniem klas. Klasyfikatory są wyposażone w pionowe, cienkie „linie życia”. Prostokąty na tych liniach odwzorowują czas życia i działania poszczególnych klasyfikatorów. Oś czasu biegnie z góry na dół; pomiędzy klasyfikatorami przesyłane są komunikaty (rysunek 3.14). W praktyce zwykle rezygnuje się ze stosowania różnorodnych symboli, rozróżniając jedynie symbol aktora, a pozostałe symbole zastępując prostokątem. W takiej konwencji diagram z rysunku 3.14 wyglądałby jak na rysunku 3.15. Ogólny schemat opisu obiektów jest następujący: [Nazwa] [:nazwa klasy] Dozwolone jest zastosowanie części powyższej sekwencji — tak jak zrobiono to na rysunku 3.15. 7 Używanie przedstawionych symboli nie jest zbyt powszechne; duża część analityków-praktyków po- przestaje na symbolu aktora oraz uniwersalnym symbolu obiektu w postaci prostokąta z nazwą w środku (tak jak to pokazano na diagramie komunikacji na rysunku 3.19). Kup książkęPoleć książkę 126 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.14. Przykładowy diagram sekwencji — obsługa zamówienia RYSUNEK 3.15. Diagram sekwencji z zastosowaniem uproszczonego opisu obiektów Kup książkęPoleć książkę 3.1. UML (cid:126) 127 3.1.3.2. Komunikaty Wyróżniamy następujące rodzaje komunikatów: (cid:120) asynchroniczny — klasyfikator wysyłający, który nie czeka z ewentualnym dalszym działaniem na reakcję odbierającego; (cid:120) synchroniczny — wywołanie procedury; (cid:120) zwrotny — odpowiedź na wywołanie procedury; (cid:120) akcja — tworzenie lub niszczenie obiektu; (cid:120) samowywołanie — asynchroniczne lub synchroniczne. Ponadto komunikaty mogą mieć charakter wielokrotnie powtarzanych interakcji. Mogą też być warunkowe. Rodzaje komunikatów i ich symbole zostały zaprezentowane na rysunku 3.16. RYSUNEK 3.16. Rodzaje komunikatów i ich symbole Kup książkęPoleć książkę 128 (cid:126) Rozdział 3. Pozostałe notacje 3.1.3.3. Obszary wyodrębnione Obszar wyodrębniony to fragment procesu, który — w zależności od rodzaju obszaru — powinien zostać potraktowany w specjalny sposób. Symbolem jest prostokąt z oznacze- niem rodzaju obszaru w lewym górnym rogu (rysunek 3.17). RYSUNEK 3.17. Symbol obszaru wyodrębnionego Wyróżniamy następujące rodzaje obszarów wyodrębnionych: alt (alternatywa) — możliwy wybór (na podstawie warunku) tylko jednego assert (formuła) — wykonanie algorytmu; operandu fragmentu wyodrębnionego; break (przerwanie) — wykonanie obszaru wyodrębnionego przerywa wykonanie consider (istotność) — komunikaty obszaru wyodrębnionego muszą zostać innych interakcji; wykonane; critical (krytyczny) — obszar z najwyższym priorytetem wykonania; klasyfikatory uczestniczące w obszarze krytycznym nie mogą obsługiwać innych operacji (przeciwieństwo ignore); ignore (ignorowanie) — komunikaty w obszarze mają niewielki wpływ na całość interakcji (przeciwieństwo critical); loop (iteracja) — przetwarzanie wielokrotne; neg (błąd) — obsługa wyjątków; opt (opcja) — opcjonalne wykonanie operandu w obszarze wyodrębnionym; par (współbieżność) — jednoczesne wykonanie wszystkich obszarów; seq (następstwo) — operandy w obszarze muszą być wykonywane dokładnie we wskazanej kolejności (przeciwieństwo strict); strict (ściśle) — komunikaty dla różnych klasyfikatorów mogą wystąpić w dowolnej kolejności (przeciwieństwo seq). Przykład: diagram przedstawiony na rysunku 3.14 opisuje zamówienie jednopozycyjne; zapytanie jest kierowane w sprawie jednego towaru. Jeśli jednak chcemy przedstawić proces Kup książkęPoleć książkę 3.1. UML (cid:126) 129 obsługi zamówienia wielopozycyjnego, przydatne będzie zastosowanie obszaru wyodręb- nionego loop (iteracja). Każda iteracja operandów wewnątrz obszaru będzie dotyczyła jed- nej pozycji zamówienia (rysunek 3.18). RYSUNEK 3.18. Diagram z użyciem obszaru wyodrębnionego TAK SOBIE MYŚLĘ... Prawdę mówiąc, nie pojmuję, dlaczego diagram sekwencji uważa się za mechanizm przydatny do opisu proce- sów biznesowych. Ze swojej natury nadaje się on bardziej do określania konstrukcji oprogramowania niż działań o charakterze biznesowym i tylko przy naprawdę dobrej woli można go uznać za przejrzysty sposób dokumen- towania tych drugich. Oczywiście, podany na rysunku 3.18 przykład dowodzi, że można to uczynić, ale… nie polecam. 3.1.4. Interakcje po raz drugi, czyli diagram komunikacji Diagram komunikacji8 obrazuje wzajemne oddziaływanie na siebie obiektów oraz wymianę pomiędzy nimi komunikatów. Jest bardzo prosty; prostokąty oznaczają obiekty, linie — związki pomiędzy obiektami, zaś strzałki — kierunek przepływu komunikatów (rysu- nek 3.19). 8 W poprzednich wersjach UML schemat ten nazywano diagramem współpracy. Kup książkęPoleć książkę 130 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.19. Diagram komunikacji dla przykładu z obsługą zamówienia 3.1.5. Interakcje po raz trzeci, czyli diagram czasowy Diagram czasowy ma dwie postacie: linię wartości (wartości są na niej określane wyłącznie tekstowo) oraz linię stanów (prezentuje wykres z wartościami dyskretnymi). W obu przypadkach linia czasu biegnie z lewej strony do prawej (rysunek 3.20). RYSUNEK 3.20. Diagram czasowy Kup książkęPoleć książkę 3.1. UML (cid:126) 131 3.1.6. Interakcje po raz czwarty, czyli diagram przeglądu interakcji Diagram przeglądu interakcji to diagram czynności, w którym czynności i/lub akcje zastą- piono diagramami sekwencji (przykład na rysunku 3.21). RYSUNEK 3.21. Diagram przeglądu interakcji Kup książkęPoleć książkę 132 (cid:126) Rozdział 3. Pozostałe notacje Diagram ten wprowadzono w wersji 2.0 UML. TAK SOBIE MYŚLĘ Osobiście uważam — a nie jestem w tym względzie odosobniony — że wprowadzenie diagramu przeglądu interakcji do notacji UML było zbędne. Nie tylko nie łączy on zalet diagramu czynności i diagramu sekwencji, ale ma też wady obu tych schematów. 3.1.7. Diagram przypadków użycia Diagram przedstawia uczestników (aktorów), usługi świadczone im przez system (przypadki użycia) oraz związki pomiędzy nimi. Nie należy go mylić z metodą przypadków użycia przedstawioną w dalszej części rozdziału (choć w tej ostatniej używa się diagramu UML jako jednego z elementów opisu). Diagram ten nie jest notacją procesową; przedstawiam go ze względu na przydatność w trakcie tworzenia opisu procesu. 3.1.7.1. Aktorzy Symbole Diagram nadaje się do zobrazowania funkcjonalności systemu. Jego twórcy wyszli z zało- żenia, że system ma taką wartość, jaką mają świadczone przez niego usługi. A zatem aktorami w podstawowej postaci przypadków użycia są usługobiorcy — użyt- kownicy systemu. Na diagramie są oni oznaczeni stylizowaną postacią człowieka (rysu- nek 3.22). RYSUNEK 3.22. Symbol aktora osobowego Zdarza się, że system świadczy usługi na rzecz innych systemów informatycznych. Dla obsłużenia takich sytuacji zdefiniowano dwa symbole „maszynowe” — dla zewnętrznych systemów informatycznych i dla urządzeń (rysunek 3.23). Ostatni rodzaj aktora to wyzwalacz czasowy. Stosuje się go wówczas, gdy któraś z usług systemu jest uruchamiana cyklicznie lub zostaje uruchomiona w określonym terminie. Symbol takiego wyzwalacza pokazano na rysunku 3.24. W praktyce symbole z rysunków 3.23 i 3.24 są rzadko stosowane; analitycy pozostają przy symbolu aktora osobowego (rysunek 3.22), traktując go jako symbol uniwersalny. Kup książkęPoleć książkę 3.1. UML (cid:126) 133 RYSUNEK 3.23. Aktorzy „maszynowi” — system zewnętrzny (po lewej) oraz urządzenie (po prawej) RYSUNEK 3.24. Aktor — wyzwalacz czasowy Generalizacja Jak niemal wszystko w UML, aktorów można generalizować. Na przykład ogólne pojęcie „klient” może oznaczać zarówno klienta indywidualnego, jak i instytucjonalnego. Genera- lizację zapisujemy jak na rysunku 3.25. RYSUNEK 3.25. Generalizacja aktorów 3.1.7.2. Przypadki użycia Czym jest przypadek użycia? Jest to zbiór (niekiedy jednoelementowy) akcji9, które zaspo- kajają któreś z potrzeb aktora. Stosowane symbole Przypadki użycia to usługi świadczone przez system na rzecz aktorów. Mogą się one skła- dać z pojedynczej czynności lub z całej ich serii. Aby przypisać przypadek użycia do aktora, łączymy ich symbole linią ciągłą. Na rysunku 3.26 z Przypadku użycia 1 korzystają obaj aktorzy, Przypadek użycia 2 wykorzystuje Aktor 2, a Przypadek użycia 3 — Aktor 1. Niekiedy zaznacza się kierunek przepływu danych pomiędzy aktorem a przypadkiem użycia (rysunek 3.27). zycji operacji systemu. 9 Akcja jest czynnością „atomową” (niepodzielną i nieprzerywalną) — jest to najniższy poziom dekompo- Kup książkęPoleć książkę 134 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.26. Przykład diagramu przypadków użycia RYSUNEK 3.27. Zaznaczanie kierunku przepływu danych W pierwszym przypadku dane klienta są pobierane z przypadku użycia, w drugim — przypadek użycia pobiera dane, z kolei w trzecim — dane przepływają w obie strony; naj- pierw do przypadku użycia wysyłane są parametry faktury, a następnie wygenerowana fak- tura jest przesyłana do aktora. W takim przypadku aktora i przypadek użycia łączy się linią ciągłą (narzucający się symbol strzałki z grotami z obu stron nie jest stosowany). Określanie granic systemu Niekiedy może być tak, że opisujemy usługi w systemie biznesowym, a tworzony system informatyczny nie obejmuje ich wszystkich. Innymi słowy, system informatyczny nie zaspo- kaja wszystkich potrzeb biznesowych. W takim przypadku diagram przypadków użycia staje się bardzo użytecznym narzędziem do określania granic systemu informatycznego. System jest wówczas symbolizowany przez prostokąt, w którym umieszczone są reali- zowane przez niego przypadki użycia (rysunek 3.28). Wymagania reprezentowane na rysunku 3.28 przez Przypadek użycia 1 i Przypadek użycia 6 nie będą realizowane w ramach tworzonego systemu informatycznego. Kup książkęPoleć książkę 3.1. UML (cid:126) 135 RYSUNEK 3.28. Określanie granic systemu informatycznego Określanie podziału funkcjonalności systemu między moduły Warto wspomnieć o jeszcze jednym, nieco kontrowersyjnym zastosowaniu diagramu przy- padków użycia, a mianowicie o dokumentowaniu podziału funkcjonalności na moduły. Niektórzy robią to, rysując granice modułów tak jak poprzednio granice systemu informa- tycznego10. Przykład pokazano na rysunku 3.29. Wydaje się, że takie użycie diagramu, choć nie do końca zgodne z notacją, jest dość przej- rzyste i nie powinno wywoływać nieporozumień. Dla porządku jednak dobrze jest zasto- sować symbole pakietów (rysunek 3.30). Zawieranie Często zdarza się, że dwa przypadki użycia (lub większa ich liczba) mają część wspólną. W ramach przykładu załóżmy, że mamy prosty system kancelaryjny wspomagający użytkownika w: (cid:120) wysyłce umów, (cid:120) wysyłce faktur. Przykładowy diagram może wyglądać na przykład tak jak na rysunku 3.31. Każdy z tych przypadków składa się z pewnej sekwencji czynności: (cid:120) wysyłanie umów — pobranie umowy z działu klienckiego, wydrukowanie umowy, zaadresowanie przesyłki; 10 Analitycy nie są zgodni, czy takie zastosowanie diagramu jest zgodne z UML. Kup książkęPoleć książkę 136 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.29. Zastosowanie diagramu przypadków użycia do zobrazowania podziału wymagań pomiędzy moduły systemu RYSUNEK 3.30. Diagram z rysunku 3.29 z zastosowaniem symboli pakietów Kup książkęPoleć książkę 3.1. UML (cid:126) 137 RYSUNEK 3.31. Przykładowy diagram (system kancelaryjny) (cid:120) wysyłanie faktur — pobranie faktury z rachuby, opieczętowanie, zaadresowanie przesyłki. Łatwo zauważyć, że wspólną częścią w obu przypadkach jest adresowanie przesyłki. Można to pokazać na diagramie (rysunek 3.32), stosując symbol zawierania (przerywaną linię z pojedynczym grotem i słowem kluczowym include )11. RYSUNEK 3.32. Diagram systemu kancelaryjnego z wykorzystaniem zawierania Nazwa „zawieranie” wzięła się stąd, że główny przypadek użycia zawiera (jako fragment swojej listy czynności) listę czynności przypadku łączonego za pomocą relacji zawierania. Rozszerzanie O rozszerzaniu przypadku użycia mówimy wówczas, gdy lista jego czynności zostaje uzu- pełniona o dodatkowe pozycje. Na przykład przypadek użycia Wysyłanie faktur można rozbudować o dodatkową czynność dołączania do faktury druków reklamowych (rysu- nek 3.33). Rozszerzenie oznaczamy przerywaną linią z pojedynczym grotem i słowem kluczowym extend 12. 11 Przyjęło się stosować to słowo także na diagramach w języku polskim. 12 Podobnie jak include, stosuje się to słowo w oryginalnym brzmieniu nawet na polskojęzycznych dia- gramach. Kup książkęPoleć książkę 138 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.33. Rozszerzanie przypadków użycia Generalizacja Generalizacja przypadków użycia jest co do zasady identyczna z opisaną wcześniej gene- ralizacją aktorów. Przypadek uniwersalny stanowi uogólnienie przypadków szczegółowych (rysunek 3.34). RYSUNEK 3.34. Generalizacja przypadków użycia 3.2. RAD Diagram RAD (ang. Role Activity Diagram) jest częścią notacji Riva — mało u nas znanej i nieczęsto stosowanej. Może szkoda, ponieważ RAD charakteryzuje się niezwykłą prostotą i nadaje się do rozmów z klientami (no, powiedzmy, po 10-minutowym szkoleniu — w każ- dym razie ta notacja jest prostsza nawet od „starego” BPMN, czyli wersji 1.0). Niestety, na jej podstawie nie da się automatycznie tworzyć definicji procesów w systemach BPM. Kup książkęPoleć książkę 3.3. Przypadki użycia (cid:126) 139 Mimo podobieństwa angielskich nazw nie należy tej notacji mylić z diagramem aktyw- ności UML. Diagram RAD dzięki symbolowi stanu łączy pewne cechy diagramów skupiających się na czynnościach i tych opartych na zapisie stanu procesu. Muszę przyznać, że mi najbardziej podoba się symbol zygzaka, oznaczający elementy, które nie są dla nas ważne (albo, mówiąc otwarcie, takie, których nie chce nam się opi- sywać). Symbole RAD zostały przedstawione w tabeli 3.4. 3.3. PRZYPADKI UŻYCIA Jak wcześniej wspomniano, opisu z wykorzystaniem przypadków użycia nie należy mylić z diagramem przypadków użycia znanym z notacji UML. W gruncie rzeczy opis jest tek- stowy, choć bywa wspomagany diagramami BPMN lub diagramem czynności UML. Nie- rzadko też diagram przypadków użycia stanowi wstęp do opisu przypadków użycia. Ideą notacji jest opisanie systemu z punktu widzenia usług, jakie świadczy na rzecz użytkowników13. Wersji opisu za pomocą przypadków użycia jest mnóstwo — niemal tyle co używają- cych go analityków. Poniżej przedstawię wersję, której sam używam. Zawiera ona nastę- pujące elementy14: 1. Numer przypadku użycia i jego nazwa. Nie należy lekceważyć tej — pozornie nieistotnej — rubryki. Porządne ponumerowanie przypadków użycia według określonego klucza — jeśli trzeba, to nawet w sposób hierarchiczny — stanowi pierwszy krok do zachowania porządku w projekcie. Układy, sekwencje („maski”) takiego numeru mogą być przeróżne — ja używam następującej: PU-[3-literowy skrót systemu]-[2-literowy skrót modułu]-[3-cyfrowy numer przypadku]-[nazwa], na przykład dla systemu przyjmowania korespondencji i modułu skanowania pierwszy przypadek użycia wygląda następująco: PU-SPK-SK-001-Wprowadzanie dokumentu 2. Diagram przypadków użycia (UML, jak w podrozdziale „Diagram przypadków użycia”) — stosowany tylko wówczas, gdy przypadek użycia jest złożony i można w nim wyróżnić części. 13 Słowo „użytkownik” zostało tu użyte w bardzo szerokim sensie; może to być zarówno osoba (rola), jak i system informatyczny. 14 Wymienione dane często formatuje się w postaci tabeli. Kup książkęPoleć książkę 140 (cid:126) Rozdział 3. Pozostałe notacje D A R i j c a t o n e l o b m y S . . 4 3 A L E B A T d a ł k y z r P ) N M P B w k a j a n b o d o p a j c a t o n ( i l o r l o b m y S s i p O l o b m y S I S P O s e c o r p e c ą j a n y z c o p z o r e i n e z r a d Z ć ś o n n y z C n a t s y n o l ś e r k o e j u m j y z r p s e c o r p m y r ó t k w , e c s j e i M u s e c o r p e i n e z c ń o k a z e ż k a t — Kup książkęPoleć książkę 3.3. Przypadki użycia (cid:126) 141 u k t ą w e i n e z c ń o k a Z l m y n ó g e z c z s o p ą j a d a i w o p d o y t ą k j ó r t — R O a k m a r B m o j c p o i u s i p o a i n e z d w u t k n u p z e n ż a w e i n e j c a r e p O Kup książkęPoleć książkę 142 (cid:126) Rozdział 3. Pozostałe notacje y z s l a d g ą i c — D A R i j c a t o n e l o b m y S . . 4 3 A L E B A T d a ł k y z r P s i p O l o b m y S u t a k i n u m o k a i n a ł s y w e i n a d a Z u t a k i n u m o k a i n a r b e d o e i n a d a Z i l o r j e w o n e i n e z r o w t U Kup książkęPoleć książkę 3.3. Przypadki użycia (cid:126) 143 ą d ę b h c a i z ę ł a g u b o w i c ś o n n y z c — D N A a k m a r B e i n ś e z c o n d e j e n a n o k y w m e i n a d a b ę i s a c ą j u m j a z a m r i f a n d e j k o b o e i z d a ł k y z r p a n — ć ś o n b e z c i l ą j a z c a n z o l ó r i m a l o b m y s d a n y r f y c ( i l o r i c ś o n t o r k o l e i w e i n e z c a n z a Z ) w ó t n e d n o p s e r 0 2 1 o d ę t e i k n a a ł a ł s y w i i i n p o Kup książkęPoleć książkę 144 (cid:126) Rozdział 3. Pozostałe notacje 3. Diagram ukazujący wymianę danych z otoczeniem (np. taki jak w rozdziale „Tworzenie opisu procesu”, podrozdział „Proces w otoczeniu (wejścia/wyjścia)”). 4. Opis formalny. Składa się on z następujących elementów: a) Streszczenie przypadku użycia (do 5 zdań). b) Aktorzy — z wyróżnieniem głównego aktora oraz aktora inicjującego (jeśli jest różny od głównego). c) Zdarzenie inicjujące, dane oraz warunki początkowe. d) Główny scenariusz powodzenia (wraz z opisem wyniku końcowego)15. e) Scenariusze alternatywne (wraz z opisem wyników). f) Wykaz encji biorących udział w scenariuszu16 [opcjonalnie]. g) Projekt interfejsu17 [opcjonalnie]. 5. Dodatkowe informacje — diagramy procesów wewnętrznych, bliższe opisy kroków, szkice interfejsu, opisy danych [opcjonalnie]. W tabeli 3.5 pokazano przykład definicji zrealizowanej w formie przypadku użycia. 3.4. FLOWCHART Flowchart jest notacją opartą na diagramie czynności. Funkcjonalnie ma wiele wspólnego z pierwszą (lepszą!) wersją BPMN. Na rysunku 3.36 przedstawiono schemat procesu sprze- daży towaru: klient przysyła zamówienie (zostaje ono przetworzone przez proces Przyjęcie zamówienia, numer A001). Następnie zamówienie jest opiniowane i podejmowana jest decyzja. W przypadku gdy jest ona negatywna, sekretariat wysyła do klienta odmowę. W przeciwnym wypadku proces oczekuje na sygnał z banku o wpłacie od klienta; gdy nadejdzie, przelew jest księgowany i magazyn wydaje klientowi towar. Zaletą notacji jest dokładny, formalny opis zadania (rysunek 3.37), uwzględniający także możliwość wyzwalania zadań przez zdarzenia (w powyższym przykładzie takim wyzwa- laczem jest fakt wpływu pieniędzy na konto bankowe). Notacja wskazuje też wykonawcę zadania (z pewnością określenie wykonawcy nie jest tak przejrzyste jak w notacjach z pasami pływackimi, ale za to — ze względu na to, że nie ma potrzeby rozrzucania zadań po pasach — można narysować bardziej zwarte schematy). 15 Przy bardziej skomplikowanych scenariuszach można umieścić np. ich diagram BPMN (choć niektórzy rzenia projektu. analitycy uważają to za błąd w notacji). 16 Element ten właściwie nie należy do notacji; prawdę mówiąc, na etapie sporządzania opisu przypad- ków użycia encje mogą być jeszcze nieznane. Mimo to warto uzupełnić ich opis na późniejszych etapach projektowania. 17 O ile nie przyjęto opcji „projektowania przez interfejs”, część tę uzupełnia się na dalszych etapach two- Kup książkęPoleć książkę TABELA 3.5. Przykład definicji przypadku użycia Identyfikator PU PU-SYD-KA-001-Przyjęcie poczty 3.4. Flowchart (cid:126) 145 Diagram przypadków użycia System w otoczeniu OPIS FORMALNY Streszczenie Aktorzy Zdarzenie inicjujące Odbiór worków z korespondencją od listonosza, przeliczenie i potwierdzenie zawartości, rejestracja przesyłek w systemie informatycznym, przydzielenie ich konkretnym osobom w firmie. Pracownicy biura: 1. Osoba do spraw kontaktu z pocztą (dalej AKTOR1). 2. Osoba (lub osoby) rejestrujące, segregujące i roznoszące przesyłki w firmie (dalej AKTOR2). Nadejście korespondencji. Kup książkęPoleć książkę 146 (cid:126) Rozdział 3. Pozostałe notacje OPIS FORMALNY — ciąg dalszy 1. Odbiór worka z pocztą (AKTOR 1). 2. Wprowadzenie danych dostawy poczty do systemu (data, godzina) (AKTOR 1). 3. Obsługa przesyłek (AKTOR 2). Dla każdej przesyłki: a) wprowadzenie danych przesyłki do systemu, b) przypisanie adresata (w systemie), c) opatrzenie pieczęcią wpływu, d) wrzucenie do odpowiedniej szufladki segregacyjnej. 4. Wydruk listy przyjętych przesyłek i pokwitowanie jej (dla listonosza) (AKTOR 1). 5. Rozniesienie przesyłek do adresatów w firmie (AKTOR 2). 6. Wydruk raportu dla zarządu (AKTOR 1, na koniec dnia). Schematy BPMN dla scenariuszy pokazano na rysunku 3.35. SCENARIUSZ ALTERNATYWNY A W punkcie 4. okazuje się, że lista przyjętych przesyłek nie zgadza się z listą pocztową. W takim przypadku należy dołączyć dodatkową czynność: „4a. Podpisanie protokołu rozbieżności”. SCENARIUSZ ALTERNATYWNY B W trakcie operacji przypisywania adresata (3b) nie udaje się tego zrobić. W takim przypadku należy po czynności 3b dodać dwie inne: (cid:120) Przypisanie przesyłce adresata „nieznany”. (cid:120) Dołączenie w systemie danych przesyłki do zasobu „dokumenty nierozpoznane”. (cid:120) Klient; (cid:120) Przesyłka; (cid:120) Worek korespondencji. Główny scenariusz powodzenia Scenariusze alternatywne Wykorzystywane encje systemu Zwykle schemat zostaje uzupełniony tabelą podobną do tabeli 3.6. Wyzwalacz nie jest elementem koniecznym — jeśli go brak, czynność zostanie wykonana po skończeniu poprzedniej czynności na schemacie obiegu. Jeśli jednak operacja zostanie wyposażona w wyzwalacz, to — mimo zakończenia poprzedniej operacji na schemacie — nie zostanie wykonana, dopóki nie zajdzie zdarzenie symbolizowane przez ten wyzwalacz. Wyzwalaczami mogą być: (cid:120) zdarzenia zewnętrzne (np. wpływ dokumentu, telefon klienta itd.), (cid:120) zdarzenia związane z czasem (np. data upływu terminu zapłaty faktury, ostatni dzień miesiąca albo godzina 18:00), (cid:120) zdarzenia pochodzące z innych procesów (np. komunikat o wpisie do ewidencji, komunikat o kompletacji dokumentów itd.), (cid:120) zdarzenia systemowe (np. w systemie płacowo-kadrowym — przekroczenie 30 dni zwolnienia w ciągu roku, w systemie bankowym — przekroczenie limitu kwoty naliczonych odsetek za opóźnienie spłaty kredytu). Kup książkęPoleć książkę 3.5. Diagram przepływu danych (DFD) (cid:126) 147 RYSUNEK 3.35. Procesy z przykładu opisu przypadku użycia przyjęcia korespondencji Flowchart nie jest notacją zbyt dobrze zdefiniowaną. Nazwą tą określa się bardzo różne zestawy symboli — od (moim zdaniem najlepszej) przedstawionej na rysunkach 3.36 i 3.37 po zwykłe schematy blokowe (jeden z alternatywnych zestawów znaków pokazano na rysunku 3.38. 3.5. DIAGRAM PRZEPŁYWU DANYCH (DFD) Diagramy DFD (ang. Data Flow Diagram) powstały do opisu tego, w jaki sposób dane są przemieszczane i przetwarzane w dowolnych systemach informatycznych, jednak z powo- dzeniem można je zastosować do opisu procesów. W diagramie każda pojedyncza operacja jest traktowana jako proces. Dane pochodzą z zewnętrznego źródła (rysunek 3.39), skąd wpływają do systemu. Tam są przekazywane pomiędzy poszczególnymi operacjami, które je przekształcają. Przekształcone dane, do czasu kiedy będą potrzebne innemu procesowi, są przechowywane w magazynach danych. Na rysunku 3.40 pokazano prosty przykład schematu DFD opisującego firmę handlową. Zbiera ona zamówienia i przekazuje informacje do magazynu dystrybucyjnego, który roz- wozi towar do siedzib klientów. Kup książkęPoleć książkę 148 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.36. Proces w notacji Flowchart RYSUNEK 3.37. Elementy opisu zadania Kup książkęPoleć książkę 3.6. Diagram stanów (cid:126) 149 Zadania A002/01, A002/03, A002/06 Referent Kierownik A002/02 Księgowy A002/04 Magazynier A002/05 TABELA 3.6. Przykładowa tabela uzupełniająca diagram Umiejętności/cechy Wykształcenie Zasoby (cid:120) dokładność (cid:120) obsługa urządzeń biurowych (cid:120) szeroka wiedza na temat branży (cid:120) umiejętność szybkiego podejmowania decyzji (cid:120) sumienność (cid:120) znajomość finansów (cid:120) uczciwość (cid:120) dokładność średnie techniczne (cid:120) komputer (cid:120) MS Excel wyższe menedżerskie (cid:120) komputer wyższe ekonomiczne (cid:120) komputer (cid:120) program księgowy średnie RYSUNEK 3.38. Jeden z wielu alternatywnych zestawów symboli dla notacji Flowchart Źródłem danych w tym przypadku jest klient. Przekazuje on swoje Życzenia (wyma- gania) do działu kontaktów, który przekłada je na język formalny, tworząc Zamówienia. Jednocześnie aktualizowany jest inny magazyn danych — Dane klientów. Na podstawie Zamówień oraz Danych klientów dział zbytu tworzy Listy dostaw wysyłane do Magazynu dystrybucyjnego. Warto zauważyć, że diagram DFD dostarcza wprawdzie informacji o zadaniach, jakie należy wykonać, lecz w żaden sposób nie określa, kto ma być ich wykonawcą. A zatem fakt, że jedną operację wykonuje dział kontaktów, a drugą — dział zbytu, nie zostaje w żaden spo- sób zanotowany. 3.6. DIAGRAM STANÓW Diagram stanów jest stosowany dla procesów, dla których osiągane stany są ważniejsze niż sposoby ich osiągania (operacje). Zostanie on bliżej omówiony przy okazji testowania procesów. Kup książkęPoleć książkę 150 (cid:126) Rozdział 3. Pozostałe notacje RYSUNEK 3.39. Schemat DFD RYSUNEK 3.40. Praktyczny przykład opisu DFD Kup książkęPoleć książkę 3.7. Diagramy księgi jakości (cid:126) 151 3.7. DIAGRAMY KSIĘGI JAKOŚCI Dia
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Procesy biznesowe w praktyce. Projektowanie, testowanie i optymalizacja
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: