Kilka tygodni temu napisałem tekst w którym zaprezentowałem praktyczne podejście do notacji UML i BPMN (https://wolski.pro/2024/01/bpmn-i-uml-w-praktyce/). Przygotowanych zostało kilka diagramów opisujących wymagania biznesowe, procesy biznesowe, przypadki użycia, diagramy aktywności i komponentów.
Zaprezentowane wówczas podejście wydaje się, że jest przydatne, gdy nie mamy modeli a z uwagi na stopień skomplikowania wytwarzanego oprogramowania, posiadanie modeli może być pomocne. W końcu modele służą właśnie do upraszczania złożonych aspektów tego świata. W tym wpisie postaram się wskazać jak można wykorzystać istniejące diagramy do analizy zmian w aplikacji.
Oczywiście nie zachęcam do rzucenia wszelkich prac by nagle zacząć budować modele. Bliższe jest mi podejście by w ramach realizowanych zmian, iteracyjnie dokładać do repozytorium kilka „rysunków”. Tym repozytorium może być Enterprise Architect ale również może być Confluence albo jeszcze inne miejsce przechowywania wiedzy.
Dla przypomnienia. Przedstawione w artykule, modele te mają przykładowy charakter. W każdej organizacji w zależności od: potrzeb, jej sytuacji oraz sposobu wytwarzania oprogramowania, modele mogą wyglądać trochę inaczej. W razie pytań zapraszam do kontaktu.
W naszym przekładzie z biegiem używania aplikacji pojawiło się kilka nowych wymagań biznesowych.
- Rozwiązanie powinno integrować się z systemem do wystawiania faktur
- W przypadku gdy kurs jest bezpłatny to w procesie rejestracji powinien być pobierany tylko email, imię i nazwisko.
- Aplikacja powinna obsługiwać kupony rabatowe.
Tak zidentyfikowane wymagania biznesowe zostają zapisane w repozytorium ze statusem nowe. Wcześniejsze mają status zaimplementowane.
W tym momencie celowo pomijam zagadnienie zarządzania wymaganiami. Dodam tylko, że wprowadzenie wymagania biznesowego do repozytorium nie oznacza automatycznie jego implementację. Oznacza tylko, że dane zagadnienie zostało odnotowane.
W momencie, w którym dane wymaganie biznesowe zostaje podjęte do analizy i być może implementacji w repozytorium pojawiają się element zmiany.
Elementy te, po przeanalizowaniu posiadanej dokumentacji są mapowane na te elementy, które ulegną prawdopodobnie zmianie. Mapowanie następuje też na wymagania biznesowe.
Analityk wraz z architektem przeanalizowali procesy biznesowe, funkcje aplikacji oraz architekturę i zidentyfikowali co obecnie jest w aplikacji, czego nie ma, i co wymaga zmiany. Z racji tego, że jest aktualna dokumentacja, analiza ta była dużo szybsza i łatwiejsza.
Dzięki takiemu mapowaniu, łatwiej jest określić zakres i skalę zmian w aplikacji. Dodatkowo w notce wskazane zostały wstępnie zidetyfikowane braki w funkcjach aplikacji. Jak widać na powyższym zmiany, które będą realizowane dotyczą zakresu zbieranych danych i integracji z aplikacją do wystawiania faktur.
Na tym etapie wydaje się, że zmiany dotyczą procesu biznesowego, architektury i przypadku użycia. Dodatkowo powstają nowe Przypadki użycia związane z realizacją funkcji fakturowania i integracji z aplikacja wystawiająca faktury.
Architektura rozwiązania
Zacznijmy od architektury. Wsparcie procesu wystawiania faktur wymaga integracji z nową aplikacją. Nasza obecna architektura przedstawia się następująco:
Natomiast nowa jej wersja zwiera już nowy komponent.
Procesy biznesowe
Analiza procesu biznesowego zakłada zmianę w jednej czynności oraz zostaje dodany nowy krok. Obecny kształt procesu nie obejmuje wystawiania faktury.
Natomiast nowa wersja zawiera ten krok. Na poniższym diagramie kolorami pomarańczowym zaznaczono zmianę a zielonym nowy krok. Użycie kolorów albo wersji tych elementów ułatwia identyfikację i analizę zmian.
Przypadki użycia – zmiany w funkacjach aplikacji
Integracja z nowym komponentem jak i funkcje związane z fakturowaniem generują zmiany w przypadkach użycia. Dodane zostają nowe przypadki użycia: Wystawianie faktury oraz Pobranie wystawionej faktury, gdzie nasz system pobiera link do pliku z fakturą w postaci PDF.
Dzięki mapowaniu przypadków użycia na kroki procesu zidentyfikowane są istniejące przypadki użycia, które ulegają zmianie. W tym momencie to PU Wwtępna obsługa transakcji.
Zmiana w scenariuszu przypadków użycia
Jak wspomniałem powyżej zmianie ulegają przypadki użycia. Scenariusz „starego” przypadku użycia wyglądał następująco.
W nowym dokonano zmian. Pojawiła się bramka oraz jeden krok. Oczywiście opis zmian można nanieść w istniejącym kroku. Ja wolę zrobić oddzielny by zaakcentować inny zakres danych i inny formularz.
W podanym przypadku po dodaniu kroku „Wyświetlenie skróconego formularza” następuje jego opis.
Klient wypełnia następujące pola
Imię
Nazwisko
Adres e-mail
Nazwa konta użytkownika
Utwórz hasło do konta
checkbox: Chcę otrzymać fakturę VAT na firmę (opcjonalne) nie jest wyświetlany.
Formy płatności: nie sa wyświetlaneW ten oto sposób powstać ma formularz, który użyty będzie w przypadku gdy w koszyku wartość produktów równa jest zero złotych.
Jak widać, na powyższej, dość syntetycznie przedstawionym przykładzie, gdy w organizacji jest już dokumentacja w postaci modeli UML i BPMN to nakład pracy jest dużo mniejszy niż w momencie gdy modele tworzone są modelowane od nowa.
Przygotowanie analizy i opisanie zmian to nie koniec pracy analityka i architekta. W czasie implementacji ich nadzór jest bardzo ważny o czasem trzeba wyjaśniać/doprecyzować cześć zagadnień. Po wdrożeniu natomiast trzeba zastąpić „stare” diagramy nowymi tak by przy kolejnej iteracji mieć aktualna dokumentację.
Podsumowując. Finalnie otrzymaliśmy listę elementów, które specyfikują zmienny w aplikacji. Jest nowa wersja architektury, są zmiany w procesie biznesowym, zmiany w scenariusz przypadku użycia. By zrealizować ta zmianę trzeba tez utworzyć trochę nowego kodu czyli zaimplementować nowe przypadki użycia związane z fakturowaniem i integracja.
I na koniec.
Posiadanie modeli AS-IS wymaga nakładu pracy na ich wytworzenie. Dobrze jest to zrobić właśnie przy okazji zmiany. Kolejna modyfikacja, kolejne przedsięwzięcie w danym obszarze pozwala nanieść tylko zmiany, przyśpiesza analizę problemu i oszczędza czas zarówno analityka jak i biznesu, który te zmiany wprowadza.
Świetny przykład pokazujący wagę i sens świadomie realizowanego śledzenia (tracebility) poszczególnych artefaktów względem siebie: wymaganie, proces, przypadek użycia, widok UI, przypadek testowy, komponent.
Dzień dobry.
Przeczytałam obydwa artykuły i co do pierwszego nie mam uwag. Odnośnie drugiego (czyli dokładnie z tej strony) zastanawiają mnie poniższe punkty:
1. W diagramach oraz realizacji zostało pominięte wymaganie dotyczące realizacji kuponów. Czy to „wypadek przy pracy” czy celowe działanie?
2. W części „procesy biznesowe” został opisany dodatkowy krok dotyczący fakturowania, ale w dalszej części artykułu, przy rozpisywaniu przypadków użycia, jak i diagramu aktywności ten krok został pominięty – tutaj zakładam, że to jest przeoczenie (a może jednak nie?).
Piszę ten komentarz, nie po to aby wytykać błędy, ale by podjąć dyskusję, być może to „ja czegoś nie widzę” 🙂
Pozdrawiam i dziękuję za przekazywanie swojej wiedzy.
Dzięki za wnikliwe przeczytanie tekstów. Odnośnie pytań.
1. W diagramach oraz realizacji zostało pominięte wymaganie dotyczące realizacji kuponów. Czy to „wypadek przy pracy” czy celowe działanie?
Na rysunku z wymaganiami biznesowymi jest wymaganie WB. Kupony rabatowe. To wymaganie pojawio się, ale nie zostało zakwalifikowane do realizacji – nie pojawiło się jako zmiana. W wolnej chwili przeredaguje ten akapit by właśnie to wyjaśnić, ż enie każde wymaganie biznesowe od razu doczekuje się realizacji.
2. W części „procesy biznesowe” został opisany dodatkowy krok dotyczący fakturowania, ale w dalszej części artykułu, przy rozpisywaniu przypadków użycia, jak i diagramu aktywności ten krok został pominięty – tutaj zakładam, że to jest przeoczenie (a może jednak nie?).
Istotnie z dwóch zmian pokazałem jedną. To intencjonalne było, by skupic się na zmianie już wczesniej zamodelowanych elementów i pokazać zmianę. Brakująca funkcjonalność – fakturowanie, to wytworzenie takiego samego zestawu dokumentów jak w czesci pierwszej https://wolski.pro/2024/01/bpmn-i-uml-w-praktyce/ . Nie kopiowałem by wyeksponować zmianę. Jednocześnie to idelanie wpisuje się w iteracyjne podejście do tworzenia dokumentacji. Dokładamy brakujące modele i zmieniamy te, które już wytworzyliśmy. W ten sposób dokumentacja przyrasta przy ograniczonym wysiłku.