Łączenie procesów biznesowych z wymaganiami oprogramowania: Studium przypadku Visual Paradigm dotyczące przejścia od BPMN do przypadków użycia

Wprowadzenie

W dzisiejszych dynamicznie się rozwijających warunkach cyfrowych organizacje stoją przed trwającym wyzwaniem: zapewnieniem, że działania związane z rozwojem oprogramowania pozostają w ścisłym związku z rzeczywistymi operacjami biznesowymi. Zbyt często zbieranie wymagań odbywa się niezależnie od modelowania procesów biznesowych, co prowadzi do systemów, które nie rozwiązują rzeczywistych przepływów pracy ani nie zapewniają oczekiwanej wartości końcowym użytkownikom. Niniejsze studium przypadku analizuje dowiedzioną metodologię łączenia tej przerwy poprzez przejście od diagramów Business Process Model and Notation (BPMN) do modeli przypadków użycia UML przy użyciu zintegrowanego środowiska modelowania Visual Paradigm.

Przykład praktyczny dotyczący firmy zajmującej się dostawą wody destylowanej pokazuje, jak analitycy biznesowi i projektanci systemów mogą wspólnie wyodrębnić istotne wymagania oprogramowania bezpośrednio z zwalidowanych procesów biznesowych. Metoda wykorzystuje funkcję Model Transitor w Visual Paradigm w celu utworzenia łączy śledzenia między zadaniami biznesowymi a przypadkami użycia systemu, zapewniając, że każda funkcja oprogramowania spełnia zdefiniowane cele biznesowe. Niezależnie od tego, czy jesteś analitykiem biznesowym, który chce skuteczniej przekazywać wymagania, czy architektem systemu, który chce tworzyć rozwiązania odpowiednie dla rzeczywistych potrzeb operacyjnych, to studium przypadku zapewnia praktyczne wskazówki dotyczące dopasowania modelowania procesów biznesowych do inżynierii wymagań oprogramowania.

Zrozumienie podstaw: diagramy BPMN i przypadków użycia

Co to są BPMN i BPD?

BPMN zapewnia analityków biznesowych zestaw notacji graficznych do modelowania procesów biznesowych. Pierwotnie został opracowany przez Inicjatywę Zarządzania Procesami Biznesowymi (BPMI) i obecnie utrzymywany jest przez Grupę Zarządzania Obiektami (OMG). Jednym z motywów tworzenia BPMN było zapewnienie wspólnego języka graficznego dla osób w różnych rolach, pochodzących z różnych krajów i/lub posługujących się różnymi językami, aby mogły rozumieć ten sam proces biznesowy bez barier.

BPD, skrót od Diagram Procesu Biznesowego, to miejsce, w którym proces biznesowy jest modelowany przy użyciu BPMN. Jest to diagram przypominający schemat przepływu, który przedstawia przepływ procesu, uczestników oraz wymianę wiadomości między nimi. Analitycy biznesowi rysują BPD, aby modelować sposób współpracy różnych uczestników w celu osiągnięcia celu biznesowego. Po zwalidowaniu zakończonego modelu biznesowego wobec końcowych użytkowników analityk systemu może rozpocząć planowanie systemu.

Poniżej znajduje się prosty BPD procesu rejestracji dla organizacji. Zawiera większość typowych notacji modelowania, które można zobaczyć. Spójrzmy na nie.

Notacja	Opis
	Pool – Reprezentuje uczestnika w procesie. W BPMN zarówno pule, jak i pasy są używane do przedstawienia uczestników. Pasek znajduje się w puli w celu modelowania podziału części rodzicielskiej puli.
	Zdarzenie startowe – początek procesu. Można zdefiniować wyzwalacze, które informują odczytujących, w jakich sytuacjach proces zostanie uruchomiony. Na przykład, gdy otrzymano e-mail, gdy jest poniedziałek rano, lub gdy wystąpił błąd.
	Zadanie – aktywność atomowa, którą mogą wykonywać wyznaczone uczestniki (zamodelowane jako pula/pas). Zadania i inne obiekty przepływu są połączone, tworząc kompletny przepływ pracy biznesowej.
	Zdarzenie końcowe – koniec procesu. Można zdefiniować wynik, który poinformuje odczytujących, co się stanie po zakończeniu procesu. Na przykład, wydać sygnał lub wygenerować błąd.

Co to jest diagram przypadków użycia?

Modelowanie przypadków użycia odnosi się do techniki zbierania wymagań użytkownika na wysokim poziomie przy użyciu diagramu przypadków użycia UML. Model przypadku użycia jest przeznaczony dla projektantów oprogramowania lub systemów, a nie dla osób biznesowych.

W diagramie przypadków użycia znajdują się trzy główne elementy.

Notacja	Opis
	Przypadek użycia – każdy przypadek użycia reprezentuje cel użytkownika, czyli cel, jaki użytkownik systemu chce osiągnąć. Zauważ, że przypadki użycia mogą być używane wyłącznie do pokazania tego, co użytkownik chce zrobić, a nie tego, co programista musi stworzyć, choć w niektórych przypadkach mogą się pokrywać. Jeśli chcesz z dokumentować lub modelować funkcje związane z przypadkiem użycia, możesz użyć narzędzia przepływu zdarzeń lub rozwinąć przypadek użycia przy użyciu diagram sekwencji/diagram aktywności. Pamiętaj tylko, że modelowanie przypadków użycia ma na celu modelowanie tego, co użytkownik chce osiągnąć.
	Aktor – użytkownik systemu. Słowo „użytkownik” nie ogranicza się tutaj tylko do ludzi. Może to być również system, który współdziała z naszym systemem w celu osiągnięcia określonego celu biznesowego.
	Łączność komunikacyjna/Asocjacja – łączy aktora z przypadkiem użycia w celu wskazania dostępu aktora do systemu. Każda łączność komunikacyjna oznacza sekwencję transakcji między aktorem a systemem.

Przejście od procesu biznesowego do wymagań systemowych

Połączenie strategiczne

Chociaż BPD i diagramy przypadków użycia nie muszą koniecznie wzajemnie się opierać, mogą być ze sobą powiązane w sposób uzupełniający. Zazwyczaj tworzymy oprogramowanie w celu automatyzacji lub optymalizacji określonych przepływów pracy w procesach biznesowych. Dzięki BPD możesz zrozumieć, jak uczestnicy współpracują ze sobą i kto jest odpowiedzialny za co, co pomaga nam zidentyfikować funkcje, które system ma wspierać. Funkcje systemu (przepływ pracy lub proces biznesowy), które użytkownik chce, mogą być modelowane za pomocą przypadków użycia i następnie opracowane przez zespół. W rezultacie możemy powiedzieć, że BPD pomaga Ci zidentyfikować przypadki użycia dla systemu w trakcie jego tworzenia.

Visual Paradigm to narzędzie modelowania wizualnego wspierające przejście od modelowania procesu biznesowego do modelowania przypadków użycia (od wymagań biznesowych do wymagań aplikacji) poprzez tworzenie łączy śledzenia między dwoma modelami za pomocą funkcji model transitor. Potrzebujemy tej śledzenia z następujących powodów:

Możemy zapewnić, że system pasuje do rzeczywistego użytkowania, badając część przepływu procesu, którą obejmuje przypadek użycia.
Aby odpowiedzieć na pytania takie jak „Dlaczego potrzebujemy tej (systemowej) funkcji?”, śledząc część procesu, z której przypadek użycia został przejęty.
Aby odpowiedzieć na pytania takie jak „Czy określona operacja została już zaimplementowana?”, śledząc od BPD do diagramu przypadków użycia.

Kluczowe różnice: BPD w porównaniu z diagramem przypadków użycia

Niektórzy ludzie mogą myśleć, że diagram przypadków użycia jest podobny do BPD, ale różnią się znacznie pod względem notacji i celów. Pamiętaj, że BPMN został zaprojektowany dla osób z branży biznesowej, podczas gdy diagram przypadków użycia służy analitykom systemów lub programistom systemów. Służą one różnym celom i patrzą na biznes z dwóch różnych perspektyw. Dlatego w poprzedniej sekcji podsumowałem relację między BPD a diagramem przypadków użycia, mówiąc: „BPD pomaga Ci zidentyfikować przypadki użycia”. BPD może jedynie podpowiedzieć podczas identyfikowania przypadków użycia. Nie ma zasady mówiącej, że każdy task istniejący w BPD jest równoważny przypadkowi użycia. Jednak możemy rozszerzyć proces biznesowy, wykorzystując przypadek użycia do automatyzacji funkcji przez system docelowy.

Studium przypadku: Firma True Aqua – Woda destylowana

Środowisko biznesowe i opis procesu

Firma True Aqua – Woda destylowana to młoda firma dostarczająca wodę destylowaną w mieście. Sprzedają wodę destylowaną do użytku komercyjnego i domowego. Poniżej znajduje się opis tekstowy ich procesu dostawy wody.

Aby zamówić wodę destylowaną, klienci albo dzwonią na hotline zamówień, albo wysyłają nam e-mail. Obecnie 90% zamówień pochodzi z połączeń telefonicznych, a 10% jest składane przez e-mail. Asystent obsługi klienta, który otrzymuje zamówienie, sprawdza, czy klient jest istniejącym klientem, czy nowym. Jeśli klient nigdy wcześniej nie zamawiał, asystent utworzy dla niego konto klienta przed przystąpieniem do dostawy wody.
Dostawa wody destylowanej odbywa się raz w tygodniu, w każdy środę. Zatem każdego poranka w środę asystent obsługi klienta przekazuje zamówienia do działu logistyki w celu dostawy. Po otrzymaniu zamówień przez menedżera w dziale logistyki, ten ustali dostawę poprzez przypisanie pracowników do różnych zamówień, drukowanie i publikowanie harmonogramu. Pracownicy otrzymują połączenia i dostarczają wodę klientom odpowiednio.

Na podstawie opisu stworzono model procesu biznesowego. Teraz proszono Cię o opracowanie systemu komputerowego w celu optymalizacji całego procesu. Pierwszą rzeczą, którą musisz zrobić, jest stworzenie modelu przypadków użycia. Korzystając z BPD, spróbuj stworzyć diagram przypadków użycia.

Krok po kroku proces przejścia

Pobierz Distilled Water Delivery.vpp. Możesz również znaleźć ten plik na końcu tego poradnika.
Otwórz pobrany plik .vpp w Visual Paradigm. Aby otworzyć projekt, wybierz Projekt > Otwórz z paska narzędzi aplikacji.
Otwórz BPD Proces zamówienia wody destylowanej. Dokładnie przeanalizuj przepływ procesu.
Proces rozpoczyna się, gdy klient składa zamówienie. Tutaj możemy rozważyć przypadek użycia – Złożenie zamówienia. Przypadek użycia pomoże zautomatyzować proces, udostępniając interfejs dla klienta, aby mógł złożyć zamówienie bez pomocy asystenta obsługi klienta, pomóc zweryfikować tożsamość klienta oraz utworzyć konto, jeśli klient nie istnieje. Kliknij prawym przyciskiem myszy na Złóż zamówienie i wybierz Powiązane elementy > Przenieś do nowego przypadku użycia… z menu podręcznego.
To powoduje wyświetlenie okna Przenieś element modeluokno, w którym możesz wybrać model, w którym umieścić przypadek użycia i aktora, oraz zmienić ich nazwy. W tym przypadku jesteśmy zadowoleni z nazw przypadku użycia i aktora. Pozostawmy je bez zmian. Kliknij OK.

Tworzy nowy diagram przypadków użycia w UeXceler.
Wróć do BPD.
Rozważmy zadanie Utwórz konto klienta. W procesie biznesowym asystent obsługi klienta musi tworzyć konto dla każdego nowego klienta. W nowym systemie może to być część przypadku użycia Złóż zamówienie lub osobnym przypadkiem użycia wywołanym ręcznie przez asystenta obsługi klienta. W rzeczywistym świecie powinieneś wyjaśnić takie wątpliwości ze stakeholderem, ponieważ niepoprawny model przypadków użycia prowadzi do tworzenia funkcji nieodpowiadających oczekiwaniom użytkownika. W tym przykładzie załóżmy, że użytkownik chce, aby zadanie Utwórz konto klienta było wykonywane przez asystenta obsługi klienta. Stwórzmy przypadek użycia na jego podstawie. Kliknij prawym przyciskiem myszy na Utwórz konto klienta i wybierz Powiązane elementy > Przenieś do nowego przypadku użycia… z menu podręcznego.
Znowu jesteśmy zadowoleni z nazwy przypadku użycia i aktora. Pozostaw wszystko w oknie Przenieś element modelu bez zmian. Kliknij OK. Diagram przypadków użycia został zaktualizowany o nowy przypadek użycia i aktora. Spójrzmy na to.
Wróć do BPD. Przejdźmy do podprocesu Zorganizuj dostawę. Menadżer działu logistyczno może używać systemu do planowania i powiadamiania pracowników o dostarczaniu wody. Dlatego też jest to również przypadek użycia systemu. Kliknij prawym przyciskiem myszy na podproces Zorganizuj dostawę i wybierz Powiązane elementy > Przejście do nowego przypadku użycia… z menu podręcznego.
Zaznacz aktora „Manager” w Element przejścia modelu oknie. Jeśli zachowamy nazwę aktora jako Manager, jest to niejasne w modelu przypadków użycia, ponieważ w firmie może być wiele działów z wieloma różnymi menedżerami. Dlatego zmień nazwę aktora na Manager działu logistycznego.
Kliknij OK. Diagram przypadków użycia został zaktualizowany.
Wróć do BPD. Ostatnia zadanie Dostarcz wodę to zadanie, które może wykonywać tylko człowiek i nie ma nic wspólnego z interakcją systemu. Dlatego nie musimy tworzyć przypadku użycia dla niego.
Załóżmy, że menedżer regionalny chce, aby system wspierał nową funkcję, która może generować raport pokazujący statystyki zamówień. Ta funkcja może pomóc mu przeanalizować i dopasować strategię marketingową. Mimo że ta funkcja nie została zamodelowana w modelu procesu biznesowego, możemy ją bezpośrednio narysować w diagramie przypadków użycia. Otwórz diagram przypadków użycia. Narysuj aktora Menedżer regionalny. Utwórz przypadek użycia Generuj raport statystyczny z niego z powiązaniem pomiędzy nimi.
Załóżmy, że klient chce pozwolić klientowi przeglądać rozliczenia i anulować zamówienia. Ponadto klient chce pozwolić menedżerowi działu logistycznego drukować raport logistyczny. Narysuj odpowiednie przypadki użycia.
Uporządkuj diagram.
Relacja przejścia pozwala śledzić model procesu biznesowego z modelu przypadków użycia (i odwrotnie). Spróbujmy. Umieść wskaźnik myszy nad przypadkiem użycia Zamówienie przypadku użycia.
Kliknij na Zasób Model Transitor zasób w prawym dolnym rogu kształtu. Wybierz Przejście z > Proces zamówienia wody destylowanej <. Złóż zamówieniez menu podręcznego.

Otwiera się BPD z zadaniem Złóż zamówieniewybranym.

Wnioski

Ten przykład pokazuje, że przejście od modeli procesów biznesowych BPMN do diagramów przypadków użycia UML nie jest jedynie zadaniem technicznym — to strategiczny sposób zapewnienia, że rozwiązania oprogramowania przynoszą rzeczywistą wartość biznesową. Korzystając z funkcji Model Transitor w Visual Paradigm, zespoły mogą zapewnić jasną śladalność między działalnościami biznesowymi a wymaganiami systemowymi, tworząc wspólne zrozumienie między stakeholderami biznesowymi a zespołami programistycznymi.

Przykład firmy True Aqua Distilled Water ilustruje kilka kluczowych zasad: nie każda działalność biznesowa wymaga odpowiedniego przypadku użycia; wyjaśnienie roli stakeholderów jest istotne podczas mapowania procesów na funkcje systemowe; nowe wymagania mogą być dodawane bezpośrednio do modeli przypadków użycia, nawet jeśli nie były obecne w pierwotnym procesie biznesowym. Najważniejsze jest to, że dwukierunkowa śladalność zapewniona przez narzędzie pozwala zespołom odpowiadać na podstawowe pytania dotyczące uzasadnienia wymagań i statusu ich realizacji w całym cyklu projektu.

Organizacje przyjmujące tę metodologię mogą liczyć na zmniejszoną niejasność wymagań, poprawioną zgodność stakeholderów oraz systemy oprogramowania, które dokładniej odzwierciedlają rzeczywistości operacyjne. W miarę jak procesy biznesowe się rozwijają, utrzymanie tej śladalności zapewnia, że ulepszenia systemu pozostają oparte na zweryfikowanych potrzebach biznesowych, a nie na spekulacyjnych żądaniach funkcjonalności. Integracja możliwości wspieranych przez sztuczną inteligencję w nowoczesnych narzędziach modelowania dodatkowo przyspiesza ten przejście, umożliwiając zespołom skupienie się na analizie strategicznej zamiast na ręcznym rysowaniu diagramów.

Bibliografia

Jak AI wspierane przez NLP rewolucjonizują generowanie BPMN z tekstu dla modelowania procesów w przedsiębiorstwach: Przedstawia, jak przetwarzanie języka naturalnego przekształca opisy biznesowe w tekście na zgodne modele BPMN do dokumentacji przepływów pracy w przedsiębiorstwach.
Opanowanie modelowania procesów biznesowych BPMN 2.0 za pomocą narzędzi AI w Visual Paradigm: Kompleksowa przeglądarka możliwości modelowania BPMN z wykorzystaniem AI do tworzenia wykonywalnych specyfikacji procesów biznesowych.
Funkcja przekształcania przypadków użycia w diagramy działań: Opisuje zautomatyzowany przepływ pracy umożliwiający rozszerzanie przypadków użycia najwyższego poziomu na szczegółowe diagramy działań do planowania wdrożenia.
Aktualizacja generatora diagramów procesów biznesowych BPMN z AI: Notatki wersji zawierające ulepszone możliwości AI do konwersji opisów narracyjnych procesów na strukturalne diagramy BPMN.
Funkcja diagramów BPMN i narzędzi: Oficjalna dokumentacja narzędzi modelowania BPMN 2.0, wsparcia notacji oraz funkcji współpracy w Visual Paradigm.
Demonstracja refaktoryzacji procesu za pomocą rozmowy: Wideo demonstrujące użycie poleceń chatbotu AI do dynamicznej modyfikacji diagramów BPMN za pomocą instrukcji w języku naturalnym.
Wydanie narzędzia do poprawy procesów biznesowych z AI: Oświadczenie o inteligentnych funkcjach analizy przepływu pracy, które sugerują możliwości optymalizacji na podstawie metryk procesu.
Funkcja diagramów BPMN i narzędzi: Przewodnik referencyjny do zaawansowanych możliwości BPMN, w tym dekompozycji podprocesów i generowania wykonywalnych modeli.
Narzędzie do doskonalenia diagramów przypadków użycia z AI: Narzędzie internetowe z AI do automatycznego doskonalenia podstawowych modeli przypadków użycia poprzez właściwe relacje include/extend oraz obsługę wyjątków.
Kompletny przewodnik po modelowaniu przypadków użycia z ekosystemem AI w Visual Paradigm: Analiza trzeciej strony technik wspomaganych przez AI do wyłaniania wymagań i specyfikacji przypadków użycia.
Od procesu biznesowego do przypadków użycia – poradnik (PDF): Pobieralny przewodnik krok po kroku przejścia modeli BPMN do diagramów przypadków użycia UML z możliwością śledzenia.
Demonstracja generowania automatycznych granic: Poradnik wideo pokazujący tworzenie za pomocą sztucznej inteligencji granic systemu, aktorów oraz kluczowych przypadków użycia na podstawie deklaracji zakresu projektu.
Demonstracja inteligentnej optymalizacji relacji: Demonstracja analizy AI, która identyfikuje i sugeruje odpowiednie relacje include/extend między przypadkami użycia.
Funkcja narzędzia do doskonalenia diagramów przypadków użycia z wykorzystaniem AI: Strona produktu opisująca możliwości automatycznej analizy i doskonalenia relacji przypadków użycia.
Demonstracja generowania przepływu pracy w dalszej kolejności: Wideo pokazujące automatyczne generowanie diagramów aktywności i sekwencji na podstawie zwalidowanych specyfikacji przypadków użycia.
Visual Paradigm na TheirStack: Profil technologiczny i wskazówki dotyczące zastosowania narzędzi modelowania Visual Paradigm w środowiskach przedsiębiorstw.
Funkcja generowania raportów diagramów przypadków użycia z wykorzystaniem AI: Narzędzie do konwersji skryptów PlantUML i modeli przypadków użycia na profesjonalną dokumentację dla stakeholderów.
Dokumentacja punktu rozszerzenia przepływu zdarzeń: Dokumentacja techniczna dotycząca dokumentowania szczegółowych scenariuszy przypadków użycia z warunkami wstępnych, warunkami końcowymi oraz alternatywnymi przepływami.
Wydanie Studio modelowania przypadków użycia z wykorzystaniem AI: Oświadczenie o wydaniu zintegrowanych możliwości AI w modelowaniu przypadków użycia, w tym analizy wymagań w języku naturalnym.