Czy stosujesz odpowiednie diagramy?

3 sierpnia 2016

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]?

PerspektywaPokazujeDiagramy / Techniki
StrukturalnaCzęści problemu/systemu i ich związkiModel dziedziny
Glosariusz
Diagram klas UML
Diagram komponentów UML
Diagram wdrożenia UML
Diagram ERD (baz danych)
BehawioralnaZachowania – procesy, zadania, sekwencjeDiagram 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)
KontrolnaDecyzje, zasady kierowaniaReguły biznesowe (SBVR)
Tablice decyzyjne
DynamicznaZmiana elementów w czasieDiagram 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].

PerspektywaDiagramy / Techniki
Ludzie i role
 
Diagram organizacji
Macierz ról i uprawnień
Lista, mapa interesariuszy, persony
PowodyBusiness Motivation Model
Modelowanie decyzji
Modelowanie zakresu
Business Model Canvas
Analiza przyczyn źródłowych
Analiza reguł biznesowych
Przepływ aktywnościModelowanie 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

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Komentarze - 5

  1. Michał Wolski

    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. Hania Wesołowska

    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. Małgorzata

    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 🙁

    1. Hania Wesołowska

      Czyli brakuje ułożenia krok po kroku? Zapraszam w takim razie na szkolenie, które zaczyna się za tydzień (https://analizait.pl/szkolenie-analiza-biznesowa-podstawie-babok-guide-v-3/). Na pewno poukłada wszystkie elementy 🙂

  4. Małgorzata

    Bardzo chętnie. Proszę tylko o podanie innego terminu, bo w tym nie dam rady.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Może zaciekawi Cię także:

www.analizait.pl by ProjectUP (C) 2020