Jak stworzyć diagram – bez ściemy

Jeden z mitów w analizie, z jakim się spotykałam, jest taki, że analityk powinien od razu, natychmiast, zrobić rozbudowany dokładny i szczegółowy diagram, w pełni odpowiadający rzeczywistym potrzebom. Taki diagram, jak to wiecie, w książkach o nim piszą – że koder go bierze, i już wszystko wie. (Jak z tego wynika z tego mitu, koder też doskonale zna język notacji, i nie ma wątpliwości jak odczytać przedstawiony przez analityka, wypasiony model. Nie mówiąc już o biznesie, który dostaje zaawansowany model wykorzystujący w pełni możliwości notacji i jest zachwycony jak to super analityk pięknie potrafi wszystko na modelu ująć..). A, no i że ten sam model powinien zarówno być bardzo zwięzły i hiper prosty, z drugiej strony przedstawiać wszystkie zależności systemu. Czyli taki jeden model do wszystkiego .

Jednak mity, jak to mity, nie są prawdziwe 😉 i daleko im do szarej rzeczywistości…

W praktyce wygląda to bardziej jako rysowanie “od ogółu do szczegółu” – najpierw zapoznanie się z analizowanym fragmentem (najlepiej, jeśli wcześniej zna się już ogólnie cały projekt, żeby mieścić się w jego granicach). Potem, jak w analizie zdania na lekcji języka polskiego – wyizolowanie osób (aktorów), rzeczowników (obiektów), czasowników (użyć) itd…

A najczęściej wygląda to tak, że analityk siedzi pół dnia gapiąc się w ekran monitora/laptopa, co jakiś czas z wypiekami na twarzy klepie w klawiaturę i bawi się myszką/touchpadem, a potem, na koniec dnia, śmie twierdzić, że się narobił, że jest niewiarygodnie zmęczony i w ogóle to głowa mu pęka.

I ktoś na niego patrzy i pyta – a co Ty takiego przez te godziny robiłeś? (Złośliwy programista pewnie by w tym momencie zripostował ile linii kodu napisał albo ile tasków z Jiry w tym czasie przerobił 😉 Żeby nie było – uwielbiam programistów – mój mąż jest programistą! dlatego piszę to z lekką nutką złośliwości, ale z ogromnymi pozdrowieniami i szacunkiem dla czytających to programistów 🙂 ).

A analityk odpowiada: “Myślałem.

Myślałem, jak ten skomplikowany, wielowymiarowy problem ująć zgrabnie na wystarczającym* diagramie ( *wystarczającym, czyli nie przeładowanym treścią, wykorzystując tylko to, co jest niezbędne, pomijając nieistotne elementy, o których jednak nie można zapomnieć, tylko należy rozpisać je na innym modelu, który powinien być logicznie powiązany z tym głównym…). Narysować to tak, żeby wszyscy rozumieli to w ten sam sposób, pilnując semantyki, ról, granic rozpatrywanego problemu, wszelkich powiązań, celu jaki ma spełniać, kierunku, w którym powinno iść. Perspektywy, dla której dany model jest tworzony. Produktów, jakie analizowany proces ma dawać. Uwzględniając wszystkie istotne powiązania (czy to z innym systemem, czy z innym procesem). “

I przykra prawda jest taka, że analityka w takiej sytuacji zrozumieć może tylko inny analityk 😉 (z pozdrowieniami dla wszystkich wspaniałych analityków 🙂 ).

Bo prawda jest taka, że dobrego modelu nie zrobi się w godzinę, dwie ani czasem nawet w kilka dni.

Modelowanie, tak samo jak kodowanie, trwa. Ogólny zarys modelu, który powstaje w pierwszej chwili, należy przetrawić (czyli po prostu: dać sobie czas, zastanowić się czy jest ok, czy idzie w oczekiwanym kierunku, czy odzwierciedla to, co się chciał napisać/narysować). Następnie kawałek po kawałku, wchodzi się w szczegóły. Czasem trzeba będzie przerobić cały utworzony do tej pory model, i to też jest ok! Czasem wystarczy, że zrobimy odniesienie do subprocesu, czasem zalinkujemy do innego procesu, którego rozrysowaniem zajmiemy się w tzw. międzyczasie.. Czasem poziom skomplikowania będzie taki, że będzie trzeba podzielić to na mniejsze modele, czasem okaże się, że ogólny model jest wystarczający i szkoda czasu na jego doszczegóławianie…

A czasem, utworzony model wywalimy używając funkcji “delete” i zaczniemy od nowa, bo zabrniemy w taki ślepy zaułek, że wyjście z niego zajęło by za dużo czasu i łatwiej będzie (czyt. szybciej) zacząć modelować od nowa.

Od czego zależy to, jak rysować model?

Od celu, jaki ma spełniać.

Inaczej modeluje się dla biznesu, inaczej dla koderów. Używa się innych technik, potrzebne są inne poziomy szczegółowości.

I tak np biznesowi z reguły wystarcza opis kroku typu “wypełnić formularz zamówienia” , gdzie w notatkach wystarczyłoby dodać ogólny opis, co ten formularz zawiera. Koderzy z kolei mogą (ale nie muszą!) potrzebować informacji “krok po kroku” całego procesu wypełniania kolejnych pól, ich walidacji, kontroli, powiązań, zachowań systemu. Dla nich, o ile w ten sposób przebiega współpraca, im bardziej szczegółowy model, tym mniej pytań na etapie implementacji. Z kolei taka ilość szczegółów byłaby zabójcza dla biznesu 🙂

Więc tu wymagane jest wyczucie, co w danym momencie, dla danego odbiorcy modelu, jest potrzebne. Jakie informacje (jak bardzo dokładne), są wymagane. Oczywiście, idealnie byłoby mieć obok siebie kogoś doświadczonego, kto podpowie jak w danej rzeczywistości, potraktować omawiany problem. Czyli po prostu, jak w tej firmie, w tym przypadku taki model należy rozpisać. Ale niestety, nie zawsze mamy obok siebie kogoś, kto potrafiłby pomóc, więc musimy bazować na swojej intuicji.

Trzeba jednak też pamiętać o tym, że im bardziej szczegółowy model, tym dłużej zajmuje jego zbudowanie. I tym bardziej kosztowne jest jego utrzymywanie. Więc jeśli jesteście proszeni o stworzenie Bardzo Szczegółowego Modelu, może warto zapytać “po co?”, ” co będzie z nim za miesiąc/dwa/po zakończeniu wdrożenia?”. Bo pisanie “dla pisania”.. czy na pewno ma sens?

Z kolei im bardziej ogólny opis, tym więcej niuansów i ważnych szczegółów można pominąć. W takiej sytuacji, model taki nie dawałby czytającemu pewności, że może na jego podstawie wystarczająco dokładnie poznać system, że w kodzie może być ukrytych dużo niezamodelowanych “ifów”..

Uff jeśli dobrnęliście do tego miejsca, to gratuluje:) Wyszedł długi wpis, mimo, że zaczynałam go pisząc o zupełnie czymś innym 😉

Ale mimo, że zaczynałam ten wpis na zupełnie inny temat, to cieszę się, że moje myśli poszły w tym kierunku. Uważam, że “tworzenie modeli” to niesamowicie ważna kwestia. Uważam, że jest wielkie niezrozumienie przez otoczenie tego, że porządne, dobre modele nie leżą na ziemi i że nie wystarczy ich podnieść i już są. Że napisanie dobrego modelu zajmuje czas. Że modele są różne, bardziej i mniej skomplikowane (zawierające mniej lub więcej detali), i że to też jest ok! Bo to, jak wygląda model zależy od tego, do czego ma być wykorzystany. I że sam proces budowania modelu to bardzo “mózgożerna” czynność , która nierzadko kończy się.. usunięciem dotychczasowych efektów i rozpoczynaniem od nowa.

Ale na szczęście efekt końcowy, jak wychodzi z naszej wytężonej pracy, wynagradza wszelkie wysiłki i problemy, które napotkaliśmy po drodze:)

Mam prośbę – jeśli dotarliście do tego momentu, dajcie mi znać o tym i proszę wpiszcie w komentarzu słowo “śliwka” ! 🙂

I podzielcie się proszę swoim doświadczeniem! Jakie modele robicie częściej – ogólne, czy może tworzycie bardzo skomplikowane diagramy? Czy spotykacie się ze zrozumieniem od waszych kolegów?

Dajcie znać w komentarzach!