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.
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.
Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane "walidacje" prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.
Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje... Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.
Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo wyczerpująco opisuje to, co nazywam "implementacją obiektowości". Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka programowania to mało, warto poznać na czym ta implementacja polega: czym jest obiekt, dziedziczenie czy kompozycja. Autor skupia się jednak na implementacji samej "obiektowości". Moim zdaniem książka jak najbardziej przydatna programistom, bo przykłady są ilustrowane kodem i diagramami UML. Jednak nie znajdziecie tam zbyt wiele o obiektowo zorientowanym opisie modelowanej rzeczywistości, czyli o biznesowym aspekcie programowania i projektowania. Z treści książki…
Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają "zwinną", że "nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy - tak właśnie radzimy sobie z nieprzewidywalnością wymagań". Przypomnę: wymagania to "warunki jakie coś musi spełnić aby było przydatne" (sł. j.polskiego PWN), jak mam tu rozumieć "brak wymagań na początku projektu", skoro jego - projektu - celem jest wytworzenie czegoś przydatnego? Co to znaczy "wymagania dzisiaj są nieprzewidywalne"? To…
Tak więc warto się zastanowić jak dotrzemy do wiedzy o naszej firmie, i na ile jest ona wiarygodna, nie zaciemniona nadmiarem zbędnych szczegółów i czy wiedza ta jest obiektywna. Dobra analiza konkretnej organizacji, firmy, urzędu, i jej wyniki nie może być np. polityczna (regularnie spotykam w firmach analizy, których celem jest wykazanie przydatności określonego rozwiązania!) bo to działanie polegające na oferowaniu leków przed diagnozą (reklamy leków bez recepty w TV!). Tak można sobie tylko zaszkodzić. A zdalna analiza (faktycznie zdalnie odbywa się ok. 80% pracy) pozawala po pierwsze obniżyć jej koszt, a po drugie zobiektywizować jej wyniki.
Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :). O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…
