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.
(źr. COMPUTERWORLD 7/2014) Tym razem króciutki wpis. Pragnę polecić numer 7/2014 COMPUTERWORLD a w nim (głównie, cały numer warto poznać ;)). Numer ten zawiera bardzo wartościowy artykuł "Pięć typowych błędów…
Autonomiczne, duże systemy ERP? Nie wróżę im kariery, w obecnej postaci mega-aplikacje umrą, odwlekanie tej śmierci z pomocą perswazyjnych reklam i kampanii dużych korporacji i ich sprzedawców, to tylko sztuczne przedłużanie życia inwestycji w duże ERP, przez producentów tych rozwiązań, dawanie sobie czasu na (mam nadzieję) ich refaktoring. Mamy np. takie kolosy jak Google czy Amazon, które pokazują, że chmurowe, wysoce skalowalne architektury zasobowe mają sens. Systemy ERP oparte na relacyjnych bazach danych i ich wewnętrzna integracja poprzez współdzielenie danych, nie mają nawet szansy z tego skorzystać.
Na zakończenie mogę powiedzieć, że dokładnie takie same błędy widzę w projektach informatycznych. Wymagania są definiowane jako dziesiątki i setki "spotkanych w życiu przykładów i doświadczeń". Lista wymagań, powstała jako efekt wywiadów, prototypów, sesji burz mózgów, bardzo często wygląda jak taki właśnie okręt, którego poszycie składa się w 100% z chaotycznie przybitych łat. To jak by wymagania na okręt spisywali marynarze, kierując się najlepszą swoją wiedzą z rejsów, które odbyli, dodatkowo lobbujący - każdy z nich - na rzecz swojej kajuty i wyposażenia.
Wprowadzenie Ostatnio napisałem dwa artykuły: o architekturze i o integracji. Pewnym ich podsumowaniem będzie dzisiejsza recenzja książki Jeff Garland i Richard Anthony . Kilka sugestii zawartych w książce. Jedną z…
Jak wspomniałem, wielu dostawców oprogramowania jak Rejtan, broni się przed ujawnianiem architektury, swoich produktów. Głównym powodem jest zapobieganie przedwczesnego wyjawienia opisanych wyżej wad systemów z grubym klientem (znacznie rzadziej spektakularny pomysł, w końcu mamy jednak jakieś standardy). Przypadki, w których zakup systemu był relatywnie niski ale koszt utrzymania, rozwoju i dostosowania nie raz wręcz ogromny, to z reguły właśnie zakup systemu w tej kosztownej architekturze. Jak starać się tego unikać? Na etapie definiowania wymagań poza-funkcjonalnych, żądać takich cech jak opisane powyżej czyli własnie: dostęp do całości przez przeglądarkę WWW, niskie wymagania na łącza przy zdalnej pracy i pracy w sieci rozproszonej terytorialnie, oddzielenie komponentu z własną dedykowaną logiką biznesową.