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.
Tak więc modele procesów, w których pojawiają się tory reprezentujące jakiekolwiek oprogramowanie gwałcą tę podstawową zasadę: organizacja to celowe działanie ludzi, narzędzia im w tym tylko pomagają, narzędzia nie są istotą działania organizacji. Można to sprawdzić czymś co ja nazywam testem wyłączenia zasilania: czy wyłączenie automatów pozbawi organizację sensu jej istnienia? Jeżeli nie to znaczy, że automaty nie pełnią ról w procesach, a są jedynie narzędziami w rękach ludzi. Narzędzi nie umieszczamy więc w modelach procesów.
Mój niedawny referat na temat trendów w wyborze i wdrażaniu systemów workflow i zaproszenie na kolejną konferencję z tego zakresu, skłoniły mnie do przerzucenia ciężaru referatu z istoty przepływu dokumentów, na przepływ dokumentów w kontekście wdrożenia narzędzia. które w tym pomaga. Poniżej prezentacja ilustrująca referat: http://www.slideshare.net/zelinski/zarzdzanie-informacj-i-automatyzacja-procesw-biznesowych-40106919 Na koniec tego krótkiego wpisu dodam, że w swej głównej części, system obiegu dokumentów to jeden przypadek użycia. (referat był wygłoszony na konferencji EOIF GigaCon, 9 Października 2014 we Wrocławiu).
Autor prezentuje podejście, które nazywam podejściem "opartym na danych". Co mam na myśli? Otóż podejście to zakłada, że istotą "systemu" jakim jest organizacja są gromadzona i zarządzane dane (wiedza). Inne podejście, nazwę je operacyjne (lub procesowe), zakłada że istotą organizacje jest odgrywanie określonej roli na rynku (dostawca produktów, usługodawca, itp.). Innymi słowy istotne jest to co potrafię zaoferować a nie to jakimi danymi dysponuję.
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.
Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi...
Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace... a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt.
Swego czasu pisałem na temat granic systemu i o analizie systemowej (analiza systemowa). Rzecz w tym, że pojęcie "analiza systemowa" jest używane najczęściej (jak obserwuję, prawie zawsze) w znaczeniu analizy i projektowania oprogramowania (systemy IT) co jest błędem.Tak zwane "całościowe myślenie" (holistyczne) to uznanie, że system to nie tylko oprogramowanie. Literatura przedmiotu, praktyka moja i nie tylko, potwierdza jedno: wymagania biznesowe to całościowe spojrzenie na biznes i cele biznesowe, wymagania wobec oprogramowania to dopiero "wymagania wobec rozwiązania" (polecam [[BABoK]] z IIBA). Jakiś czas temu zamówiłem książkę Systems Thinking. Potwierdza, że…
Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.
Wakacje sprzyjają filozofii. Tym razem kontynuacja opisanej tu niedawno książki Kotarbińskiego: Kurs logiki. Logika bardzo pomaga w analizie. Prawie trzy lata temu pisałem o Trzech zasadach logiki, jedna z nich jest kluczem w analizie, to zasada wyłączonego środka. Brzmi ona: jeżeli p to nie q Można ją wyrazić prościej słowami: jeżeli coś jest czymś, to nie jest niczym innym. Czemu jest tak ważna? Zobaczmy najpierw znaczenie słowa analiza (źr. sł. j.polskiego PWN, pominąłem chemiczne, trzecie znaczenie): analiza 1. ?rozpatrywanie jakiegoś problemu, zjawiska z różnych stron w celu jego zrozumienia lub…
PwC przedstawiła wyniki badań statystycznych i sugestie przyczyn prezentowane przez dystrybutorów, innymi słowy zadała wiele pytań i uporządkowała odpowiedzi na nie. Znamienne jest także to, że Raport ?Analiza wpływu zjawiska piractwa treści wideo na gospodarkę w Polsce? przygotowany przez PwC przygotowano na zlecenie Stowarzyszenia Dystrybutorów Programów Telewizyjnych "Sygnał". Nie mam podstaw do oskarżania PwC o stronniczość, ale na pytanie: czy Stowarzyszenie promowało by raport uderzający w ich interesy, sami Państwo musicie sobie odpowiedzieć, ja jestem wyłącznie niezależnym analitykiem :) i na tym się skupię.
Wakacje to czas na spokojniejsze lektury i badania (które zresztą zajmują mi niemało czasu). Swego czasu pisałem o problemach jakie tworzą niejednoznaczne w swej treści dokumenty (usunąć niejednoznaczność). Zawsze powtarzam na szkoleniach, że dokumenty tworzone przez analityka to nie tylko "jego raport", te dokumenty to "wiedza przekazana" np. developerom, a wcześniej sponsorowi projektu (ma np. potwierdzić zgodność modelu organizacji z nią samą). Raporty z analiz to nie tylko modele ale także komunikacja, to nośniki przekazujące wiedzę adresatom tych dokumentów. Dokumenty, modele, specyfikacje, to nic innego jak przekaz (komunikacja), a ten…
Z racji tego, że nie wyobrażam sobie dobrego analityka nie posługującego się sprawnie logiką (także formalną, bo czymże są notacje jak nie formalnymi systemami pojęciowymi) polecam np. tę książkę.Tadeusz Kotarbiński, Kurs logiki dla prawników. Ja mam wydanie PWN z 1963 roku ale logika się nie starzeje a autor zacny. Co prawda podtytuł zawiera "dla prawników", jednak książka nie jest "prawnicza" a o logice. Nie będę się rozpisywał, sami przeczytajcie wprowadzenie a dowiecie się - zrozumiecie - dlatego wiele specyfikacji wymagań i projektów to dokumenty nieprzydatne
