Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Modelując jakąkolwiek firmę jakąkolwiek notacją warto projekt modelowania uzupełnić o jego pragmatykę, to jest o specyfikację wszelkich warunków tworzenia modeli. Opracowanie takiej dokumentacji wymaga ustalenia tych zasad, a także zdefiniowania słownika, skończonej przestrzeni nazw i definicji, która pozwoli jednoznacznie zaklasyfikować każde pojęcie z życia firmy do właściwego, i tylko jednego, elementu modelu. Projekt modelowania procesów to nie jest proste rysowanie tego co się dzieje. Tak powstają najczęściej nieprzydatne i kosztowne zarazem dokumenty.
Projekt modelowania procesów biznesowych to wnikliwa analiza całej organizacji, sposobu zarządzania nią i udokumentowania tego jak faktycznie powstaje w niej wartość dla klienta. Nie raz niestety odnoszę wrażenie, że w wielu projektach tego rodzaju duża wartość analizy i modeli biznesowych zostaje zastąpiona skomplikowanymi i nic nie wartymi diagramami.
proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.
Co to znaczy, że wymagania są zweryfikowane? To znaczy, że z powodzeniem przeprowadzono test polegający na wykonaniu wszystkich czynności modelu procesu biznesowego. Skąd to wiemy? Bo na wejściu modelu procesu "podano" prawdziwe dokumenty, udało się na modelu wskazać wszystkie czynności wymagane do obsłużenia tego dokumentu i nie było innych zbędnych, otrzymaliśmy taki sam rezultat (wynikowy dokument i jego stan) jak w naturze oraz na liście przypadków użycia są wszystkie te i tylko te, które były potrzebne by ten proces bez błędu przeszedł do końca. Jak to się robi? Przeczytaj o tym tu.
Jeżeli dokument wymagań nie spełnia tych kryteriów, to jak sam Hume twierdzi, jest on bezwartościowy, nie niesie żadnej wiedzy gdyż poszczególne wymagania są: albo niezrozumiałe, albo zrozumiałe lecz nie uzasadnione, albo zrozumiałe i zasadne lecz banalne (np. mają być Sprecyzowane). Tak więc wiemy co to znaczy FURPS i SMART (powyższe skróty). Odbierając dokumenty analiz zadawajcie pytanie: a skąd wiemy, że te wymagania (które ktoś spisał) są FURPS i SMART i co to oznacza?
Tak więc na zakończenie zwrócę uwagę: analiza wymagań i projekt oprogramowania jest złożona, niezależnie od tego ilu użytkowników go będzie używało. Jednak koszt wdrożenia oprogramowania w firmie 10 osobowej będzie nieporównywalnie mniejszy niż w korporacji zatrudniającej 1000 osób. Tu jednak problemy leżą już gdzie indziej.
Ale ktoś powie: duży ERP wymaga przewidzenia wielu ról w systemie i w związku z tym obsługi wielu etapów jakie pokonują tam dokumenty. Owszem, dlatego uważam, że należy osobno wybrać system, który wchłonie te dokumenty (np. finanse itp.) i osobno system, które je tam doprowadzi czyli "jakiś workflow". To dużo bezpieczniejsze i mniej ryzykowne. (na diagramie poniżej (dan z IBM) wdrożenie to etap instalacji i oddania do użytku.
Dlatego dobrą praktyką jest raczej oddzielenie projektowania od wykonania. Zlecenie analizy i opracowania rozwiązania i przejęcie praw majątkowych do opracowania (projektu systemu) i na tej podstawie dopiero wskazanie wykonawcy daje gwarancje, że dostawca oprogramowania nie nabędzie żadnych praw do Państwa pomysłu. Daje gwarancję, że Wasz unikalny pomysł nie stanie się "modelem referencyjnym dla branży..." lub co gorsza "gotowym produktem z pudełka"...
Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat.
Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy... tak jak to napisano na początku.
Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.
