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.
Właśnie otzrymałem mail: Szanowni Państwo, w imieniu Konsorcjum Koordynującego Narodowy Program Foresight Polska 2020 pragnę serdecznie podziękować za zainteresowanie Programem i wypełnienie ankiety rekrutacyjnej do Zespołu Ekspertów Zewnętrznych Narodowego Programu…
Jeden z pracowników moich klientów, duży developer powiedział, że firma i to co się w niej dzieje jest tak skomplikowana, że nie wyobraża sobie bo można to było opisać lub narysować. Powiedziałem, że można, należy jednak po pierwsze przyjąć pewien poziom szczegółowości opisu sensowny z perspektywy człowieka (model to uproszczenie) oraz podzielić problem na kawałki... dyskusja nie miała końca. Mój projekt dobiegł końca i okazało się, że udało się opisać nie małą firmę w ciągu miesiąca, modelem na kilkudziesięciu stronach. Jak?
A jednak jak to mówią "nigdy nie mów nigdy". Postanowiłem napisać o SaaS (Software as a Service, ang. Oprogramowanie jako Usługa) mimo wcześniejszych deklaracji, że nie będę tego tematu poruszał, ale tu w nieco innym kontekście. Dlaczego? Bo jednak nie potrafię słuchać tłumaczenia: "SaaS jest dobre dla firm bo jest dobre". Ja oczywiście zawsze jestem uciążliwy i pytam "Dlaczego dla mnie jest dobre"? Tłumaczenie, że "Dzierżawione jest lepsze i tańsze" od razu nasuwa mi pytanie "To dlaczego dostawcy SaaS nie są jeszcze milionerami?" A jak chcę skopać leżącego to pytam jeszcze o rentowność (dla mnie, nie dla niego).
Artykuł opisuje drugi, po przypadkach użycia i modelu dziedziny systemu, aspekt opisu wymagań: zachowania systemu. Nie jest to proste biorąc pod uwagę różnorodność problemów: obiekty stanowe (np. dokumenty, ludzie), współbieżność i transakcyjność i wiele innych. Opisanie tekstem w sposób jednoznaczny tych elementów wymagań jest praktycznie nie możliwe. Za pomocą diagramów: sekwencji, komunikacji, aktywności, maszyny stanów, czy przebiegów czasowych możliwe jest przekazanie opisu budowy systemu np. programistom będąc niemalże pewnym, że napiszą kod taki jaki chciał projektant mimo, tego, że nie będzie go w tym procesie kodowania.
Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi.