Czy warto jest modelować w UML lub BPMN?

Od pewnego czasu widoczna jest dyskusja dotycząca wartości modelowania. Zwolennicy podejścia zwinnego niezbyt chętnie widzą modele, argumentując, że w dynamicznie zmieniającym się środowisku pracy szybkie dostosowanie się do zmian jest ważniejsze niż szczegółowe planowanie. Z kolei konserwatyści preferujący klasyczne podejście do procesu wytwórczego oprogramowania wskazują na znaczenie modelowania dla dokładności i przewidywalności procesów. Ponadto szerzą się głosy, że UML albo BPMN jest za trudny. W poniższej publikacji pozwolę sobie zabrać głos w tej dyskusji.

Modelowanie kosztuje. Narzędzia zazwyczaj niewiele, natomiast ludzie (analitycy, projektanci, architekci) już sporo. Nie da się ukryć, że korzystanie z UML wydłuża proces budowy oprogramowania. Czy to czas stracony? Przy nadmiarowym modelowaniu zapewne tak. Jednak przy rozsądnym dobraniu technik i odpowiedniej metodyce pracy zespołu wytwórczego uzyskujemy zysk w trakcie rozwoju systemu, jego rozbudowy i bieżących zmian. Dodatkowym argumentem za jest fakt, że modelowanie sprzyja lepszemu zrozumieniu problemu przez zespół, co z kolei może prowadzić do szybszego rozwiązywania problemów i innowacji.

Jestem zwolennikiem ostrożnego dobierania modeli. W moim odczuciu ich nadmiar powoduje spore obciążenie zespołu. Nie mniej jednak, budowanie modeli ma ogromną wartość. Dokumentacja projektu przypomina trochę projekt domu. Budynku większego niż garaż raczej nie buduje się bez projektu. (Pomijam fakt, że budując dom wymagana jest dokumentacja projektowa, a do budowy systemu informatycznego, wielokrotnie droższego od niejednego domu, to sprawa opcjonalna.) Warto również podkreślić, że modelowanie umożliwia lepszą współpracę między zespołami oraz ułatwia nowym członkom zespołu szybkie zrozumienie struktury i funkcji systemu.

Dokumentacja opisująca działanie systemu, architekturę oraz dane to moim zdaniem takie minimum. Dokumentacja w UML pozwala na świadome i mniej ryzykowną rozbudowę systemu.

Kiedy warto jest budować modele?

• pozwala na odkrycie nowych wymagań,
• zwiększa efektywność opisu systemu,
• pomaga nadać odpowiednie priorytety wymaganiom,
• umożliwia lepsze zarządzanie ryzykiem projektu poprzez wczesne identyfikowanie potencjalnych problemów.

Innymi słowy, niezależnie od tego, czy budujemy nowy system czy też rozbudowujemy stary, mając model, jesteśmy w stanie lepiej zarządzać wymaganiami a tym samym całym przedsięwzięciem, gdyż unikamy większej ilości przypadkowych czynności, które mogłyby doprowadzić do porażki.

Z drugiej strony, przy małej zmianie w systemie, rysowanie wielkich diagramów jest mało sensowne. Odnotowanie zmiany na już istniejących modelach UML to dobra droga. Jednakże, nadmierna poleganie na modelowaniu może prowadzić do zaniedbania kluczowego aspektu – komunikacji w zespole. Skomplikowane modele mogą być trudne do zrozumienia dla osób niebędących ekspertami, co utrudnia współpracę i wymianę wiedzy.

Czy modelowanie jest łatwe?

No i tu pojawia się najważniejszy punkt, otóż modelowanie nie jest łatwe i rozumiem opory w jego uczeniu się zwłaszcza w środowisku programistów. Po pierwsze gdy ktoś kończy jakieś kierunek informatyczny to najpierw uczy się programować, a potem jest przedmiot „Inżynieria oprogramowania”, gdzie jest nauka procesu wytwórczego oprogramowania i notacji UML. Rozumiem, że w takiej sytuacji niektórzy mogą postrzegać BPMN i UML jako narzędzia teoretyczne, które nie przynoszą bezpośrednich korzyści praktycznym aspektom ich pracy. Inny czynnik to złożoność narzędzi do modelowania. Wiem, że narysowanie planów czasem jest bardziej pracochłonne niż implementacja. To oczywiście tylko dwa argumenty, wierzchołek góry lodowej.

Kiedy warto jest modelować w UML?

• dla dużych systemów (dla mniejszych też, ale tutaj czasem agile wystarczy),
• dla systemów, które przetwarzają dane osobowe, wrażliwe lub wspomagają ratowanie życia (niezależnie od wielkości),
• gdy chcemy zapanować nad złożonością systemu,
• gdy chcemy opisać, jak systemy informatyczne wspierają poszczególne kroki procesów biznesowych,
• gdy planujemy integrację systemów (szczególnie nacisk należy położyć na modele opisujące architekturę i przetwarzane, w integrowanych systemach dane),
• gdy chcemy precyzyjnie opisać problem (wymagania), rozwiązanie (projekt) oraz kontekst (architektura) działania systemu.

Kiedy warto jest modelować w BPMN?

• dla złożonych procesów biznesowych: gdy mamy do czynienia z procesami, które są złożone i mają wiele warunków lub decyzji, modelowanie w BPMN pomaga w ich usystematyzowaniu i zrozumieniu. Może to ułatwić identyfikację wąskich gardeł i potencjalnych usprawnień.
• w przypadku integracji systemów: integracja różnych systemów informatycznych wymaga precyzyjnego zrozumienia, jak procesy biznesowe przebiegają między nimi. BPMN może pomóc wizualizować te przepływy, ułatwiając projektowanie integracji.
• Dla poprawy komunikacji między zespołami: BPMN tworzy jednolity język dla osób z działów biznesowych i technicznych. Umożliwia to lepsze zrozumienie potrzeb biznesowych przez zespół IT i odwrotnie, co prowadzi do bardziej skutecznej współpracy.

Modelowanie w BPMN jest szczególnie wartościowe, kiedy chcemy nie tylko zrozumieć i usprawnić istniejące procesy, ale również gdy planujemy wprowadzić nowe inicjatywy biznesowe lub dokonać zmian w systemach informatycznych. Większość osób zaangażowana w proces wytwórczy powinna umieć je czytać. Osoby wytwarzające kod powinny umieć czytać diagramy aktywności, komponentów, sekwencji i być może diagram klas. W sumie to aż i tylko 5 diagramów. Dlaczego piszę o umiejętności czytania? Otóż diagramy tworzą analitycy, architekci. To oni powinni umieć je rysować i publikować w troche bardziej przyjaznym dla odbiorcy środowisku takim choćby jak Confluence. To oni muszą poznać narzędzia takie jak Enterprise Architect czy Visual Paradigm. Co więcej dobrze zarządzane repozytorium modeli to nie tylko informacja o nadchodzących zmianach. To baza do skrócenia czasu w czasie kolejnych zmian, kolejnych iteracji.

I na koniec, gdy planujemy budowę domu, kompletujemy dokumenty w tym jego projekt. W trakcie budowy domu bazujemy na jego projekcie. Oczywiście są pewne zmiany (przestawiamy ścianki, zmieniamy wysokość okna itd.), ale nikt nie burzy wszystkiego i nie zaczyna od nowa. Murarze co do zasady powinni i posiadają umiejętność czytania planów architektonicznych. Przy implementacji aplikacji bez dokumentacji, często bywa tak, że albo oddajemy źle napisany komponent (o ile w miarę działa), albo piszemy od nowa (by w miarę działał). Co więcej problemy nie wychodzą od razu a dopiero po kilku iteracjach. Budowanie modeli w UML, zwiększa prawdopodobieństwo, że zminimalizujemy straty czasu związane z poprawianiem (lub pisaniem od nowa) źle funkcjonujących funkcji aplikacji.