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.
Wstęp Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy: źr.: Marcel van Oost, LinkedIn, https://www.linkedin.com/posts/marcelvanoost_fintech-payments-paytech-activity-7085945466286153728-GEgt Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali. Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy. Stereotyp czyli typ…
Wstęp Oprogramowanie wspomagające zarzadzanie firmą stanowi sobą podsystem w systemie jakim jest organizacja, o czym pisałem niedawno: Z perspektywy organizacji i rynku, oprogramowanie wbudowane to jest to oprogramowanie, którego używa się wewnątrz firmy ale którego nie widzą, nie mają z nim kontaktu, klienci tej firmy. (https://it-consulting.pl/2023/02/27/organizacja-jako-mechanizm-czyli-slon-w-pokoju/) Organizacje to system informacyjny i system informatyczny jako jego podsystem. Mamy więc dwie odrębne architektury z perspektywy oprogramowania: architektura informacji/danych, czyli realizacja wymagań funkcjonalnych (komu i do czego ten system służy), architektura techniczna środowiska, czyli wymagania pozafunkcjonalne (jak sprawny, niezawodny i bezpieczny ma być system). Są to…
Wprowadzenie Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu analizy i modelowania jako dyscypliny, oraz dość powszechne niezrozumienie istoty ten notacji. Na to nakłada się ogromna różnica między tym co nazywamy analizą i projektowaniem obiektowym (OOAD) a obiektowo-zorientowanymi językami programowania (OOP). Notacja UML jest przez wielu ludzi błędnie traktowana jako kolejny zestaw symboli do tworzenia ilustracji. Większość znanych mi deweloperów uważa, że te diagramy im w niczym nie pomagają i generalnie mają racje, gdyż…
Wprowadzenie Skrót VSM zaczyna się od pewnego czasu pojawiać także w inżynierii oprogramowania, ma on jednak stary, ponad 30-letni rodowód. Mapowanie strumienia wartości (ang. Value-stream Mapping, VSM), znane od 30 lat, ostatnio także jako mapowanie przepływu materiałów i informacji (ang. material- and information-flow mapping). Jest to metoda mająca swoje początki w Lean Management, służąca do analizy stanu obecnego i projektowania stanu przyszłego dla serii zdarzeń, które prowadzą produkt lub usługę od zamówienia do momentu dostarczenia klientowi. Mapa strumienia wartości to graficzne podejście, które pokazuje wszystkie krytyczne kroki w określonym procesie…
O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu. Co jest przyczyną?
(więcej…)
Why is this happening? The methods of project execution by most IT vendors haven't changed in 30 years: talks, interviews, coding, expensive tools (C++, Java). We've known for 20 years that writing a program in C++/Java is twice as much work compared to an identical result achieved with scripting languages (Prechelt, 2003; 2000). The continuing popularity of C++/Java has its origin: most of the large systems in the fin/tech industry were created in the 1990s, and they are not being upgraded and only added functionality despite the fact that it is no secret how to migrate to newer technologies and architectures (Laigner, Kalinowski, Diniz, Barros, Cassino, Lemos, Arruda, Lifschitz & Zhou, 2020).
The reasons are quite mundane: as long as there is demand, technology suppliers have no interest in upgrading their products and are selling a permanent technological debt (Rosoff, 2011).
David Harel. (2001). Rzecz o istocie informatyki. Algorytmika. (Zbigniew Weiss & Piotr Carlson, Trans.; Wydanie trzecie). PWN.
Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.
The era of "sacred cows" of engineering is slowly coming to an end. Software engineering, after almost 20 years of an "agile" approach to this branch of engineering, is beginning to mature into "real engineering" with analysis, design and testing on the "drawing board" of CASE systems and MBSE approaches, which are a universal systems approach to multidisciplinary engineering (mechatronics) (Rosenberg, 2023).
Organizations are also systems and their engineering: we have business process engineering, resource engineering, financial engineering. Organizations are systems and should be treated and modeled as such (Kozminski, 1979). IT systems maintenance and development costs are already more than 8% of a company's revenue, and this value is slowly but steadily growing. The discipline of their creation, implementation and management of their costs is also growing.
Wprowadzenie Jako ludzie komunikujemy się od początku swojego istnienia (generalnie byty ożywione się komunikują). W formie utrwalonej ta komunikacja ma miejsce od pierwszych rysunków na piasku czy naskalnych, a w formie sformalizowanej od początków wojska i państwowości (formalizm: przykładanie wagi do formy, źr. Encyklopedia PWN). Bezpieczeństwo i wiarygodność komunikacji od początku naszej egzystencji jest przedmiotem zainteresowania komunikujących się stron. Warto pamiętać, że komunikacja to także samo rejestrowanie i odtwarzanie danych (treści), więc nawet zapisanie (utrwalenie gdzieś) listy sprawunków by później użyć tej listy, np. po dotarciu do sklepu, to także…
Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Głównym wyróżnikiem ICONIX jest wypełnienie luki pomiędzy analizą potrzeb a implementacją. Lukę tę wypełniamy od razu modelując mechanizm realizacji przypadków użycia. Proces ten sprawia,…
Ten artykuł jest adresowany do wszystkich. Biznes (prawnicy także) może przekonać się, że oprogramowanie można narysować i zrozumieć. Analitycy i programiści, że to możliwe, a deweloperzy, że nikt im nie odbiera pracy a raczej pomaga. Wprowadzenie W dzisiejszym świecie inżynierii największą wartość mają czas i zasoby. Czas to jak najszybsze oddanie rozwiązania (produktu) do użytku (szybka komercjalizacja), zasoby to koszt jakim się to odbędzie. Kluczem są koszty: "time to market", tu kosztem jest opóźnienie komercjalizacji (niezrealizowane przychody), kosztem jest także samo powstawania oprogramowania. Praktycznie od początku inżynierii oprogramowania zależność kosztów…
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml
Wprowadzenie Pojęcie 'system' stało się bardzo popularne, głównie za sprawą "systemów informatycznych", jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii . Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system: ?układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość? ?zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość? ?narządy lub inne części żywego organizmu pełniące razem określoną funkcję? ?uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię? ?określony sposób wykonywania jakiejś czynności lub…
