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.
Zapewne nie odtworzy się oryginałów ale poświadczone, elektroniczne kopie można posiadać. Dlatego urzędom, i nie tylko, sugeruje rozważenie: zamiast walczyć z wdrażaniem mało tu skutecznych, kosztownych i długotrwałych we wdrożeniu, systemów obiegu dokumentów, wdrożyć porządne repozytorium dokumentów, archiwów elektronicznych. Łatwiej jej wdrożyć, są w znacznej części gotowe wymagania dostępne na stronach Archiwum Państwowego. Zarządzanie procesem przepływu dokumentów jest trudniejsze bo po pierwsze, wymaga powyżej wykonanej analizy, po drugie system workflow i tak wymaga dobrego repozytorium dokumentów.
Mając dobre archiwum zabezpieczymy lekko licząc 90% związanych z zarządzaniem dokumentami potrzeb bo:
mamy ich kopie w repozytorium
możliwe jest automatyczne monitowanie terminów właściwym osobom,
możliwe jest więc dekretowanie,
niemożliwe jest ukrycie tego, na jakim etapie (u kogo) jest dana sprawa i jak długo jest załatwiana.
Tak więc można ... Czy ktoś chce mnie może przekonać, że w firmach dokumenty nie giną? Giną i to znacznie częściej niż w urzędach, więc pokory proszę w ocenie urzędów ...
Po co nam CASE?
Bo
Dzięki narzędziom CASE projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze. (wiecej: http://www.eioba.pl)
Tak więc gorąco polecam stosowanie narzędzi (lista narzędzi CASE).
Z zasady nie reklamuje oprogramowania. Uważam, że jego sprzedawanie to inna kompetencja. Jednak nie da się ukryć jestem użytkownikiem "czegoś". Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgrade i... mamy burzę mózgów :):
Do tego, ów kapitalizm, to jak pokazuje autor Korporacji (gorąco polecam tę książkę i film). Rozpoczynając czytanie tej książki traktowałem ją z początku jak kolejny efekt "spiskowej teorii dziejów", jednak z każda stroną zmieniałem zdanie gdyż z dużymi firmami mam do czynienia regularnie a tak zwane afery opisywane w prasie stanowią niejako naturalną ilustracje tej książki.
Jedną z kluczowych tez autora tej książki jest to, że kluczem do zysków korporacji są wyzysk pracowników i przerzucanie swoich kosztów na klientów (nabywców ich towarów i usług). Nie będę tu się rozpisywał na ten temat, wystarczy poczytać w prasie i na forach dyskusyjnych jak wygląda realizacja niejednego projektu IT. Najpierw jest przetarg na podstawie wątpliwej jakości opisu potrzeb, potem dostawca - zatrudniając najtańszych pracowników na rynku - próbuje zrealizować swoje zobowiązanie rutynowo (czyli niskim kosztem) przerzucając koszty każdego ryzyka na zamawiającego. W efekcie otrzymujemy niskiej jakości i bardzo kosztowny produkt.
Autor, w swoim artykule, wymienia także Państwo jako wyzyskiwacza. I tak to wygląda na prawdę: wszystkie koszty złego (kosztownego) funkcjonowania Państwa są przerzucane na podatnika, ten zaś jako usługobiorca (Państwo świadczy usługi dla obywateli) jest dokładnie w takiej samej sytuacji jak w przypadku brania kredytu w banku czy kupowania pasty do zębów w supermarkecie.
Na koniec coś optymistycznego: osobiście widzę światełko w tunelu: przybywa ludzi oczekujących jakości od tego co dostaje. Pojawiły się nieco zdrowsze sałatki w sieciach fast-food, nabiera wartości na rynku dobre rękodzieło, nawet piwo z regionalnych browarów (droższe nie raz dwukrotnie od produkowanego masowo) dało się we znaki gigantom browarnictwa (każdy ma ambicję na piwo niepasteryzowane itp.) odbierając im część rynku. Oby tylko to światełko nie pozostałą niszą...
Nie jestem wrogiem Agile, jestem zwolennikiem innego autorytetu: Yourdona, który napisał w swojej książce o modelowaniu UML: bez planów można z marszu zbudować z desek np. budę dla psa bo jest mało skomplikowana i ogarnia ją wyobraźnia przeciętnego człowieka, ale dlaczego tak wielu ludzi próbuje tą metodą budować wielkie biurowce...Ciesze się, gdy pojawiają się polemiki z moimi artykułami, to znaczy, ze ktoś to czyta i budzą one emocje. Czytamy na pewnym blogu (który gorąco polecam jako całość):
Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: ?[...] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora [...]?. A dzisiaj czytam, jak autor krytykuje praktyki Agile ? czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. (źr. Zwinna analiza ? TouK).
Cóż, problem w tym, że Agile jest głównie na społecznych stronach definiowane więc nie miałem wielkiego wyboru: społeczna metodyka to i społeczna wiedza o niej.... (wiem czym jest i wiki i wikipedia, nie sądzę by tu tkwił problem).
Jeśli coś jest skomplikowane, złożone, możliwym rozwiązaniem jest dodanie zasobów i właściwych procedur. Jednak jeśli coś jest trudne, potrzebny jest po protu ktoś, kto potrafi. Czemu o tym piszę? A bo właśnie mam przed sobą kolejny dokument o nazwie SIWZ, wykonany podobną techniką (w obszarze wymagania), jakimś kosztem (czas pracowników albo koszt konsultanta pracującego tą właśnie metoda) opracowano tę specyfikację wymagań a teraz zamawiający sam przyznaje (po rozstrzygnięciu przetargu), że analiza wymagań jest potrzebna bo ów SIWZ jest "niespójny, ma braki i wymaga korekty i uzupełnień". Z tego powodu także nie ma pewności, że w ogóle dobrze opisano Przedmiot Zamówienia".
Niestety wiele projektów programistycznych to odkrywanie wymagań "w trakcie" dostarczania produktu. Po dostarczeniu jakiegoś fragmentu (lub nie raz prototypu całości) beneficjent stwierdza: "to jest dokładnie to czego chcieliśmy ale zupełnie nie to co jest nam potrzebne"...
