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 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!
Mam w ręku książkę Guide to Enterprise IT Architecture (Springer Professional Computing, autorzy Col Perks, Tony Beveridge). Co prawda wydana w 2003 roku jednak, autorzy skupili się na pryncypiach dzięki czemu uzyskali pewna "ponadczasowość". Co prawda autorzy powołują się dość często na TOGAF, ale książka jest nie o TOGAF'ie (jest tu traktowany jako przykład ram) a o tym czym jest (jak postrzegać) architekturę korporacyjną, zwracają uwagę, że chodzi o cel a nie o dokumentację. Nie jest to absolutnie żaden podręcznik, jest to książka ukierunkowana na pokazanie czym jest architektura korporacyjna, jakie…
obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy "świata" i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie - obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).
Tak więc proponuję praktykom uważającym, że strategia jest już zbędna, podziękować. Podobnie proponuję podziękować także konsultantom, którzy uważają, że strategia to szczegółowy plan na wiele lat. Nie ma sensu re-definiowanie tych pojęć na chwilowe potrzeby "mody" czy nawet demagogicznego uzasadniania sensu jakiegoś projektu. To i tak na nie zadziała w dalszym horyzoncie działań. Strategia to deklaracja na długi okres, w konsekwencji nie ma sensu by była "szczegółowa", ona ma być ogólna ale musi być "konkretna", musi pozwalać na stwierdzenie w dowolnym momencie, czy to co robimy lub planujemy zrobić (taktyka i podejmowane zadania) jest zgodne z naszą strategią czy nie. W przeciwnym wypadku mamy problem albo ze strategią, albo z planowanymi działaniami, albo z jednym i drugim :) czyli z zarządzaniem w ogóle.
W literaturze można spotkać różne "definicje" studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Wydaje się, że intencje sponsorów tych analiz są z nią zbieżne: celem jest podjęcie decyzji o najmniejszym ryzyku w świetle posiadanej na dany temat wiedzy. Definicje bazujące na technicznej i finansowej wykonalności danego projektu, są spotykane dość często i w literaturze i na stronach wielu instytucji. Metoda prowadzenia takich analiz, bazująca na modelowaniu czyli na analizie systemowej, wydaje się być najwłaściwszą.
Poszukiwanie Świętego Graala realizacji celów osobistych albo projektów trwa. Od czasu do czasu pojawiają się "magiczne" metody na sukces. Jedna z regularnie odgrzewanych jest SMART i jej odmiany. Poniżej kolejna próba ożywienia tego tematu i mój komentarz. Model ZOOM mówi o tym, że każdy cel, który sobie wyznaczasz musi być: (Wyznaczaj cele w modelu ZOOM). Moim zdaniem, nie ma znaczenia jaki wymyślimy "fajny" akronim SMART, ZOOM itp...każdy cel w swoim opisie ma trzy kluczowe parametry: to co chcemy osiągnąć, stworzyć itp., to kiedy planujemy to osiągnąć, to jak stwierdzimy, że…
Oprogramowanie workflow, w tak zwanej chmurze, ma wiele zalet, jednak ma także poważną wadę: kłopotliwa integracja z lokalnymi systemami (np. ERP) wynikająca z tego, że dokumenty pokonują zawsze podwójną drogę od naszej lokalizacji do usługodawcy i z powrotem. W przypadku małych firm (mała ilość danych) z reguły nie stanowi to problemu. Dla dużych firm może to być nawet bariera nie do pokonania, dlatego tak zwana "chmura prywatna" czyli lokalna instalacja może być jedynym wyjściem.
Na koniec: zanim zawrzecie Państwo umowę na taką usługę warto się skonsultować z prawnikiem wyspecjalizowanym w tego typu usługach.
