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.
Od czasu do czasu "nawołuję" do formalizowania projektów. Jak nie raz wspominałem, jest to podstawowa metoda uczynienia projektu (jego dokumentacji) przejrzystym. Drugą ważną korzyścią z formalizacji jest tak zwana [[interoperacyjność]], która oznacza możliwość współdziałania technologii różnych dostawców (producentów).
Jak nie trudno się domyśleć, problem dotyczy w szczególności każdej większej organizacji, niejako skazanej na posiadanie rozwiązań z różnych źródeł. Klasycznym przykładem jest administracja publiczna (z interoperacyjnością, a raczej jej brakiem, w Polsce walczymy).
Tak więc polecam osobom związanym z administracja publiczną i instytucjami publicznymi, zapoznanie się z tą inicjatywą. Moim zdaniem bardzo ważna, dobrze że podjęto ten temat gdyż kwestie integracyjne stanowią nie raz istotny koszt projektów IT a bywa, że brak interoperacyjności powoduje wręcz niemożność ich realizacji (np. w Polsce integracja rejestrów Państwowych).
Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły.
I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów?
Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać.
Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu:
analiza biznesowa
zdefiniowanie celu
zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]]
zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe,
dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania.
wybrać rozwiązania.
Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!
W 2009 roku udzielając wywiadu Gazecie zwróciłem uwagę na fakt, że: - Patologiczne są przetargi, w których wykonawca systemu sam sobie robi analizę wymagań. Z całym szacunkiem, nie widziałem jeszcze wykonawcy, który by w…
Jednym z głównych problemów wielu projektów analitycznych (i nie tylko) jest komunikacja i dokumentowanie działań. Projekty analityczne mają to do siebie, że opisują organizację beneficjenta projektu. Tworzenie jej modeli wymaga "sprzężenia…
Kolejnym problemem jest niestety jakość projektowania:
Według firmy analitycznej Gartner około 60 proc. wdrożeń wielkich systemów informatycznych kończy się klęską. Przyczyną jest m.in. nieumiejętność przełożenia procesów działających w firmie na działanie systemu informatycznego, brak dostatecznego wsparcia ze strony pracowników i kierownictwa firmy (czasem nawet jawny opór), złe przygotowanie wdrożenia lub jego prowadzenie. (za Serwis Nauka w Polsce - PAP SA).
Jak widać, jakość projektowania jest kluczem, zresztą nie tylko w przypadków dużych systemów ale w każdym przypadku. Różnica jest taka, że jeżeli niejedna firma świadomie ryzykuje kilkaset tysięcy rezygnując z etapu niezależnej analizy i projektowania wartej ok. 10-20% tej kwoty, to podobne podejście projekty warte milionów jest już raczej nieracjonalne...
