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.
Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże "zabetonowanie" architektury biznesowej firmy.
Tak więc stagnacja szkodzi, są to krótkotrwałe zyski, podobne do niezapłacenia rachunku za energie elektryczną: za miesiąc będzie dwukrotnie wyższy plus odsetki. Bieżące, dobrze zaplanowane "aktualizacje" (oprogramowania, dokumentacji projektowej, analizy i planowania, itp.) to relatywnie małe koszty, a dla firmy istotne są nie tyle kwotowe chwilowe wydatki (oszczędności) co płynność finansowa i długoterminowa rentowność. Dlatego permanentni dłużnicy zawsze płaca więcej a czasami bankrutują.
Tak na prawdę integracja taka polega nie na samym zainstalowaniu ESB i "podłączeniu" komponentów, to samo z siebie nic nie wnosi i nie jest łatwe. Integracja z użyciem ESB, to po pierwsze stworzenie (lub użycie jeżeli istnieje) dla każdego komponentu odpowiedniego adaptera i API, po drugie zaprojektowanie schematu komunikacji.
Książka ta (Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java) leży na mojej półce niemalże od daty jej wydania w 2011 roku. Po jej przeczytaniu nadal zaglądam do niej od czasu. Jest to pozycja, którą gorąco polecam jako kompendium wiedzy a metodach analizy i projektowania zorientowanych obiektowo. Napisana jest jako podręcznik akademicki, co powinno bardzo pomóc początkującym w tej dziedzinie. Zawiera dość bogate Wprowadzenie do inżynierii oprogramowania. Opisuje na podstawowym, na początku wystarczającym poziomie, notację UML oraz organizację projektu analitycznego. Kolejna część, zatytułowana Zmagania ze złożonością, to bardzo…
(ź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 w umowach wdrożeniowych" Pana Marcina Maruty (Kancelaria Radców Prawnych Maruta i Wspólnicy). Pan Maruta wskazuje, jako kluczową przyczynę wielu problemów z wdrożeniami (a konkretnie z kontraktami na ich realizację) jest źle sformułowany, a nie raz po prostu brak, przedmiot umowy. Przyznam, że banan przy moim uśmiechu na twarzy to pikuś, jak pomyślałem, co myślą zwolennicy "zwinnych metod" czytając to (cytat…
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 kluczowych jest zbyt szybkie "ładowanie się" w szczegóły, w toku analizy od ogółu do szczegółu jako pierwszy powstaje model kontekstowy, powstaje z użyciem diagramu przypadków użycia. Bardzo często na tym etapie tworzone są w projektach bardzo szczegółowe diagramy z dziesiątkami przypadków użycia, praca z taka ilością szczegółów niszczy skuteczność pracy na tym poziomie. Przypadki użycia na etapie analizy kontekstu mają…
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ą.
Na rynku pojawiło się ciekawe rozwiązanie: WOOXO. System mamy "u siebie", więc mamy do dyspozycji własną administrację i brak ograniczenia na przepustowość łączą (nie płacimy dodatkowo za usługę, mamy do dyspozycji pasmo sieci lokalnej). Warto także pamiętać, że wykonywanie kopii zapasowych lokalnie uwalnia od wielu problemów prawnych (np. dane osobowe) jak i czysto strategicznych (dostęp do danych stanowiących tajemnice przedsiębiorstwa).
Legalny, niestety, lobbing (lobbing: wywieranie wpływu na organy władzy państwowej w interesie określonych grup politycznych, gospodarczych lub społecznych; źr. sł. j. polskiego PWN) to nic innego jak manipulacja urzędnikami, wpływaniem na treść ustaw. Lobbyści producentów i dostawców technologii będą czynili starania, by w prawie znalazła się technologia, bo tak korporacje "tworzą rynek" na swoje produkty. Dobre prawo powinno być jednak zbiorem reguł a nie zbiorem rozwiązań. Te ostatnie powinny być przedmiotem analiz i projektów inżynierskich a nie prawem, jak widać np. po ustawie o podpisie elektronicznym, bardzo ułomnym.
Jak widać, z zupełnie z innej strony "odkryliśmy" coś co nazywamy architekturą korporacyjną. Skoro każda analiza wymagań w istniejącej organizacji, to każdorazowa analiza od poziomu motywacji biznesowej projektu, przez wymagane usługi aplikacyjne, integracje aż do platform sprzętowo-systemowych, to mamy nic innego, jak projekt dokumentowania architektury korporacyjnej. I na koniec bardzo ważna moja uwaga: za jakość wymagań odpowiada i ponosi konsekwencje w 100% kupujący, nigdy dostawca!
