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.
Na zakończenie dodam coś do manifestu: ludzie, szanujmy na wzajem swoje kompetencje bo bez tego nie da się współpracować. Po drugie, nie tylko w kontekście owych modeli, których kolega nie doświadczył: to że ktoś nigdy nie widział czarnego łabędzie nie stanowi żadnego dowodu na jego nieistnienie. Dodam od siebie: to że ktoś czegoś nie potrafi nie znaczy, ze to nie możliwe. By nie budzić zbędnych emocji: obecnie nie potrafię już dobrze programować (co by to nie miało znaczyć) ale w swym rozsądku nie neguję istnienia oprogramowania.
Koszt analizy i opracowania to ok. 20% wartości implementacji i mieści się nie raz nawet w kwocie nie wymagające przetargu (co istotnie skraca czas całości). Po drugie mając projekt, wycena implementacji nie jest już wróżeniem z fusów z narzutem 200-500% na wszelkie niewiadome (powszechna praktyka wielu firm developerskich, z bożej łaski integratorów). Zlecenie całości (analiza, projektowanie, wykonanie) jednej firmie nie raz kończy się tak:
Wykonawca został wybrany w trybie zamówienia z wolnej ręki, ze względu na ochronę praw wyłącznych firmy Sygnity SA. Wykonawca został wybrany zgodnie z prawem polskim, natomiast zastrzeżenia Komisji wynikają z faktu, że w owym czasie polskie prawo nie było dostosowane do unijnego
Autor artykułu porównuje obie te specyfikacje i pokazuje, że są praktycznie zgodne w 100%, nie licząc metody prezentacji i perspektywy. W obu przypadkach ma miejsce analiza, porównanie i specyfikacja celów biznesowych oraz przyporządkowanie ich do narzędzi (głównie ale nie tylko IT) wspierających realizację tego celu. Jeżeli uznać, że specyfikacja coś opisuje, to zależnie od fazy projektu jest specyfikacją potrzeb a potem specyfikacją tego co się posiada (jak uda się zakup ;)).
Bardzo często tak właśnie definiuje się produkt analizy wymagań: wymagania funkcjonalne opisują to co ma system robić. W dyskusjach (ile mam ich za sobą :)) z programistami przebija się teza, że analityk specyfikuje to "co" system ma robić, a oni już załatwia sprawę tego "jak" ma to robić. W czym problem? W tym, że funkcjonalności to test rozwiązania a nie wymagania! [...] Przypadki użycia stanowią bardzo mierne przybliżenie rzeczywistości. [...] Tak więc dokument wymagań to nie tylko przypadki użycia. Te są raczej testem poprawności rozwiązania, czy model jest poprawny (przypominam, że przypadki użycia, poza ich scenariuszami, zawierają stan początkowy i stan końcowy akcji użytkownika). [...] Programiści, proszę, nie udawajcie, że znacie się na zarządzaniu, marketingu, biznesie, sprzedaży, rynku, produkcji itp. bo to (poza pewnie istniejącymi wyjątkami) nie prawda, a projektowanie na zasadzie "wydaje mi się że rozumiem" to droga do porażki. [...] System ERP można wybrać na bazie projektu na wyższym poziomie abstrakcji. Analizy firmy także polega tu na opracowaniu modeli procesów. Jednak w tym wypadku ich celem jest stworzenie raczej "modelu filozofii działania" firmy a nie projektowanie systemu od zera.
Co mogę poradzić małym i średnim firmom? To, że jak już raz ustalą cenę by jej nie zmieniały bez mocnego uzasadnienia. Promocja to nie prosta obniżka ceny a wymiana ustępstw pomiędzy dostawcą a kupującym. Jeżeli jest to wprowadzanie nowego produktu na rynek, to obniżka ceny jest rekompensatą za ryzyko kupowania czegoś nowego czego się nie zna. Często można usłyszeć o promocji na np. jogurty, sprzedawane są po obniżonej cenie produkty, którym kończy się termin przydatności do spożycia ale to nazwał bym raczej wyprzedażą. W obu jednak przypadkach obniżona cena ma uzasadnienie i powrót do poprzedniej wyżej ceny jest możliwy bez psucia sobie wizerunku. Klient, który coś kupi taniej a później znowu widzi wyższą (np. poprzednią cenę) czuje się oszukany.
