Masz czasem wrażenie, że tworzysz diagram, który nie wnosi wiele nowego? Może produkujesz wiele diagramów, ale wciąż brakuje ujęcia sedna problemu? Może dajesz upust znajomości UML, BPMN, SysML, ArchiMate, BMM, itd. jednak masz wrażenie, że bez niektórych dałoby się tym razem przeżyć? Jak dobrać odpowiednie diagramy do problemu?

Ostatnio często nachodziła nagle Anię podobna refleksja: „Chwila. Czy to, co właśnie robię ma sens?”. Nie chodziło tym razem o sens życia czy pracę w ogólności. Otrzeźwiło ją dodawanie kolejnego stanu do diagramu UML. Nowy, zatwierdzony, wycofany. I tak dla kolejnych 4 klas o podobnym zachowaniu. Z jednej strony nie kosztuje to wiele pracy, z drugiej – czy ktoś kiedyś będzie się nad tym pochylał w głębokiej zadumie? Czy tego czasu nie warto poświęcić na coś bardziej wartościowego? Podążanie za wypełnianym szablonem dokumentacji było proste, niemal relaksujące, a złamanie schematu, wymagało przemyślania na nowo działania w tej sytuacji. Przerwała, wstała i skierowała się w stronę wyjścia z pokoju. Porozmawia z kolegą – starszym analitykiem.  

Znajomość języków modelowania się chwali. Dobrze mieć pod ręką wiele specjalistycznych narzędzi. Jednak posiadanie ich to jedno. Drugie to umiejętność dobrania odpowiedniego narzędzia do odpowiedniego problemu. Skąd wiedzieć jak wybrać właściwe diagramy?

Jak z wszystkim w analizie, polecam mix wiedzy z doświadczeniem. Poznanie teorii uchroni Cię przed miesiącami czy latami dochodzenia do podobnych wniosków, które mógłbyś wyczytać z dobrych praktyk. Z kolei ćwiczenie i doświadczanie nawet tego, że dany diagram w danym przypadku nie wnosi wiele informacji znakomicie potwierdza i utrwala te wnioski w Twojej głowie. Od tej pory zamiast nikłego skojarzenia z zaleceniem z książki, zdzieli Cię siła własnego doświadczenia.

Jeśli pracujesz już jakiś czas, zauważyłeś pewnie, że projekty znacznie się od siebie różnią. Niektóre wyświetlają, zapisują i edytują dane, które mają przede wszystkim pięknie wyglądać i jeszcze skuteczniej sprzedawać. W takich projektach łatwiej na kawę wyciągnąć analityka niż UXa, grafika i frontendowca, bo przygniata ich nawał roboty. W innych sytuacja wygląda zgoła odwrotnie – projektant interfejsu określa projekt jako banał, podczas, gdy skomplikowane przeliczenia i procesy w tzw. backendzie powodują, że żeby dowieźć analizę w terminie postanawiasz zrezygnować z jedzenia i wychodzenia do toalety. Jedne mają skomplikowaną strukturę, inne zmieniają swój stan w szalonym tempie, jeszcze innymi sterują tak skomplikowane reguły, że połamało nad nimi głowę już kilka osób.

Byłoby łatwiej wybrać diagram, gdyby mieć proste reguły – masz projekt typu X, zastosuj diagram Y. Jednak jak to w życiu, nasze projekty to mieszanka różnych cech. Bądź tu mądry. Spróbujmy być mądrzy wchodząc od podstaw.

A jakie są podstawy? Ano takie, że na każdy problem/projekt można patrzeć z wielu perspektyw. Zazwyczaj spojrzenie np. na budynek z jednej strony nie daje Ci pełnego obrazu. Widzisz jedną ścianę, ale co kryje się z innych stron? Budynek może być zarówno krótki jak i ciągnąć się kilometrami. Mamy np. w Gdańsku Przymorzu tak zwany falowiec – najdłuższy blok w Polsce, 11 pięter, 16 klatek, w którym mieszka ok. 3400 osób. Specyficzny klimat. Mówią, że falowiec, to stan umysłu J Z boku wygląda jak każdy inny blok i nic nie zapowiada jego niezwykłego charakteru. Dopóki nie spojrzysz z innej strony…

Czytam czasem specyfikacje i mam wrażenie, że mimo tego, że zawierają wiele diagramów, to nie wyjaśniają najważniejszych aspektów. Może ktoś zapomniał dodać ważnej perspektywy?

Jakie perspektywy mamy do dyspozycji do patrzenia na systemy i projekty IT [1]?

Perspektywa Pokazuje Diagramy / Techniki
Strukturalna Części problemu/systemu i ich związki Model dziedziny

Glosariusz

Diagram klas UML

Diagram komponentów UML

Diagram wdrożenia UML

Diagram ERD (baz danych)

Behawioralna Zachowania – procesy, zadania, sekwencje Diagram przepływu danych (DFD)

Mapa procesów biznesowych

Proces biznesowy BPMN

Diagram przypadków użycia UML

Diagram aktywności UML

Diagram sekwencji UML

Scenariusz

Mapa związków

Diagram nawigacji interfejsu użytkownika Architektura informacji

Prototyp (makieta)

Kontrolna Decyzje, zasady kierowania Reguły biznesowe (SBVR)

Tablice decyzyjne

Dynamiczna Zmiana elementów w czasie Diagram stanów UML

Diagram przebiegów czasowych UML

 

Zastanów się, co z perspektywy Twojego projektu ma największe znaczenie? Posiada on skomplikowaną strukturę? Przygotuj diagramy z tej perspektywy. A może odznacza się złożonym zachowaniem? Skomplikowanymi regułami decyzyjnymi? Dynamicznymi zmianami?

Diagram pokazuje system z jednej perspektywy. Nie zdobędziesz pełnego obrazu problemu, dopóki nie spojrzysz na niego z wielu stron. Niektóre perspektywy mogą być w Twoim projekcie trywialne. Zastanów się, czy ich nie ograniczyć lub w ogóle pominąć? Perspektywie, która gra najważniejszą rolę, poświęć więcej uwagi.

Poza opisem systemu przydadzą Ci się także perspektywy biznesowe [2].

Perspektywa Diagramy / Techniki
Ludzie i role

 

Diagram organizacji

Macierz ról i uprawnień

Lista, mapa interesariuszy, persony

Powody Business Motivation Model

Modelowanie decyzji

Modelowanie zakresu

Business Model Canvas

Analiza przyczyn źródłowych

Analiza reguł biznesowych

Przepływ aktywności Modelowanie procesów

Przypadki użycia

Scenariusze

User stories

 

Przed rozpoczęciem pracy nad danym projektem albo w jego trakcie, kiedy lepiej go zrozumiesz, dobierz odpowiednie diagramy, które zilustrują najważniejsze aspekty analizowanego problemu.

 

Źródła:

  1. Ellen Gottesdiener „Warsztaty wymagań”
  2. IIBA BABOK Guide v 3
Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

5 KOMENTARZE

  1. Bardzo sensowne zestawienie. Praktyka pokazuje niestety, że w wielu projektach/firmach jest problem z balansem pomiędzy perspektywami. Zazwyczaj króluje modelowanie zachowania i brakuje diagramów opisujących struktury danych lub architekturę. Natomiast w innych projektach/firmach nie istnieją scenariusze zachowania systemu (przypadki użycia, user stories) lub są one robione „na sztukę”.
    Wybranie odpowiednich diagramów dla projektu to proces iteracyjny. Warto połączyć wybór diagramów z metodyką prowadzenia projektów. Kluczowe wtedy stają się odpowiedzi na pytania: „Dla kogo robię te diagramy?”, „W jaki sposób ktoś i do czego wykorzysta te diagramy?”, „Jak i po co będę zarządzał ich zmianą?”. Warto też pamiętać o tym co powiedział Ivar Jacboson o UML, co odnosi się, moim zdaniem, do innych notacji również : „UML has become complex and clumsy. For 80% of all software only 20% of UML is needed”. :-)

  2. Też często brakuje mi pełnych informacji, kiedy czytam dokumentację. Faktycznie, albo dominuje strukturalna albo perspektywa zachowania. Często, jeśli ktoś ma background techniczny mam wrażenie, że łatwiej mu się poruszać po strukturach. A osoby bardziej biznesowe częściej skupiają się na przepływie albo ekranach.
    Poza tym też często zapomina się o perspektywie ludzie i role, albo traktuje się ją bardzo pobieżnie – lista ról z dokładnością na poziomie użytkownik A, użytkownik B, administrator. A najboleśnie czuć brak tej perspektywy powodów.
    Poza różnymi perspektywami na tym samym poziomie, świetnie byłoby mieć przekrój góra dół – od rzeczy blisko biznesu (procesy, pojęcia, powody) po te blisko rozwiązania.
    Rezczywiście, warto się zastanowić dla kogo które diagramy będą najbardziej pomocne. Ale też lubię przygotowywać je sama dla siebie, żeby poukładać wszystko w głowie i umieć później odpowiedzieć na pojedyncze, szczegółowe pytania programistów czy testerów.
    Faktycznie, najczęściej wystarczają proste diagramy. I na pewno nie wszytskie rodzaje diagramów UML. Dobrze jednak, gdyby powstawało takich porządnych diagramów chociaż te 20% :)

    Dziękuję za komentarz i pozdrawiam :)

  3. czytam chłonąc każdą nawet spację. chciałabym w mojej organizacji móc pomóc stworzyć warunki do pracy analitykom.
    motam się. nie wiem od czego zacząć. wydaje mi się, że mam wizję, czasem nawet plan, by po chwili stwierdzić, że nie wiem od czego zacząć.
    w moim zespole podstawowym narzędziem jest word i głowy poszczególnych osób.
    może to brak w edukacji zwyczajnie :-(

ZOSTAW ODPOWIEDŹ