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.
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
pytanie o diagram klas jako reprezentacja [relacyjnej] bazy danych to świadectwo kompletnego niezrozumienia analizy i projektowania zorientowanego obiektowo (żeby nie powiedzieć ignorancji). Jest to także świadectwo braku znajomości literatury, bo faktycznie, jak zauważa autor powyższych słów, nie ma oficjalnych materiałów (organizacja standaryzująca) mówiących o modelowaniu danych diagramami klas notacji UML. Do modelowania danych używamy notacji ERD (ang. [[Entity Relationship Diagram]], diagram związków encji).
Z cyklu mity OpenSource: Kwietniowa awaria OpenSSL, w wyniku której serwery dosłownie ?krwawiły? poufnymi danymi (stąd w języku angielskim błąd ten nazwano ?heartbleed?), jest niezaprzeczalnym dowodem na to, że otwarte kody źródłowe nie są ani analizowane ani testowane mimo wielu możliwości weryfikacji otwartego oprogramowania w celach bezpieczeństwa. Dlaczego open source nie jest tak bezpieczny, jak powinien? - Computerworld.
Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to "komplikowanie" każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.
Bardzo ciekawa książka, przydatna każdemu kto zajmuje się nie tylko inżynierią oprogramowania (ale tą także). Analiza systemowa, projektowanie systemów, to szersza dziedzina niż tylko IT. O ogólnej teorii systemów następna książka. Modern Methods of Systems Enginieering to rodzaj podręcznika. Kolejne rozdziały opisują metody i narzędzia stosowane w projektach z obszaru szeroko pojętej inżynierii systemów. Można tu znaleźć opis procesów analizy systemowej, spis treści kluczowych dokumentów w kolejnych etapach prac. Co nieco o notacji SysML (Systems Modeling Language). Opisana tu metoda i narzędzia pracy są zgodne (kompatybilne) z [[DoD Systems Engineering Fundamentals]], [[NASA Systems Engineering…
zbieranie wymagań tylko metodą spisywania oczekiwań czy wręcz żądań, użytkowników, jest jedną z najgorszych metod pozyskiwania wymagań! Praktycznie zawsze prowadzi do powstawania specyfikacji bardzo złej jakości (niespójne i niekompletne) oraz niekontrolowanego rozrastania się harmonogramu i budżetu projektu. Dostawcy oprogramowania, godzący się na taki styl prowadzenia projektu, świadomie lub nie, działają na szkodę swoich klientów. Analiza systemowa organizacji jako sposób pozyskania wymagań, który chroni przed takimi zjawiskami.
Swego czasu miałem na jednej z konferencji o "big data" referat na temat problemu złożoności i jej analizy. Generalnie problem złożoności ładnie opisał Karl Popper, w swoim dziele Wiedza Obiektywna metaforą "o chmurach i zegarach". To co obserwujemy, system, może być tak złożone, że ilość obiektów i ich wzajemnych oddziaływań jest zbyt duża by możliwe było stworzenie modelu (teoria wyjaśniająca zachowanie) takiego systemu, pozwalającego na przewidywanie zachowania takiej złożoności. Są jednak systemy, których natura na to pozwala, ich model jest możliwy do stworzenia, takie systemy są przewidywalne. Metaforą systemu nieprzewidywalnego jest tu chmura, a przewidywalnego zegar. Oczywiście jest nieskończenie wiele systemów o naturze gdzieś pomiędzy chmurami i zegarami.
