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.

Webhook – zwrotne wywołania API

Wprowadzenie Swego czasu opisywałem wzorce projektowe i API (Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy). Kluczowym wzorcem jest wzorzec SAGA, czyli sterowanie sekwencją wymiany danych z jednego miejsca. Wzorzec ten to typowy system klient-serwer (usługobiorca-usługodawca) i sprawdza się doskonale, gdy sterowanie z jednego miejsca rozwiązuje wszystkie problemy integracji. Pewnym problem jest tu jednak to, że serwer musi zostać odpytany by klient poznał jego stan. Opis problemu Wyobraźmy sobie, że mamy system WMS (ang. Warehouse Managements System, zarządzanie magazynami) oraz zintegrowany system ERP, rozliczający operacje magazynowe.…

Czytaj dalejWebhook – zwrotne wywołania API

Kto zjadł cały budżet przed czasem, gdzie jest projektant i czy leci z nami pilot?

Wprowadzenie Na LinkedIn rozgorzało kilka dyskusji na temat ról w projektach na etapie zawierania umowy i trakcie jej realizacji (tu jedna z nich). Cały czas jednak moim celem jest szukanie przyczyn poniższego stanu rzeczy: Jak widać, ponad 90% projektów średnich i większych, to projekty problematyczne (w tym ok. w ćwierci to projekty zarzucone przed ukończeniem). Projekty problematyczne to przekroczony budżet i niedotrzymany termin. Standardową przyczyną przerwania prac jest wyczerpanie planowanego (dostępnego) budżetu . Nieskromnie napiszę, że od lat jestem w zielonej kolumnie. Bywam też biegłym i ekspertem audytującym dokumenty projektowe,…

Czytaj dalejKto zjadł cały budżet przed czasem, gdzie jest projektant i czy leci z nami pilot?

Dokumentowanie projektu

Wprowadzenie Artykuł Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania napisany w 2017 roku, kończyłem słowami: Nie chodzi więc o to by podzielić oprogramowanie na “składowe, które łączą w sobie możliwość przechowywania danych oraz wykonywania operacji”. Chodzi o to by mechanizm, o dowiedzionej poprawności, zaimplementować w określonej wybranej technologii. https://it-consulting.pl/2017/07/15/architektura-kodu-aplikacji-jako-pierwszy-etap-tworzenia-oprogramowania/ Dokumentowanie i dokumentacja w projektach inżynierii oprogramowania to temat wielu i sporów i nieporozumień. Jednak kluczowymi błędami są najczęściej: teza, że dokumentację tworzymy po zakończeniu prac, teza, że jest to "jedna dokumentacja". ad.1. Niestety to najgorsza forma, bo etap rozwiązywania…

Czytaj dalejDokumentowanie projektu

Początek dobry a potem coraz gorzej czyli MVP

Wprowadzenie Od kilku już lat jestem, jako ekspert, angażowany jako rzeczoznawca do sporządzania opinii na zlecenie sądów (opinia biegłego) lub jednej ze stron sporu (opinia prywatna). Są to spory dotyczące nieudanych dostaw i wdrożeń oprogramowania, nie tylko ERP, bardzo często także dedykowanego. Po tych latach wyłania się pewien wspólny mianownik, łączący te porażki scenariusz: firma dostaje ofertę na dostarczenie i wdrożenie oprogramowania, ma miejsce prezentacja pomysłu, jakieś makiety, jakaś działająca funkcjonalność, przedmiotem oferty jest prezentowane istniejące oprogramowanie z obietnicą jego dostosowania (kastomizacji), lub oferta wykonania dedykowanego oprogramowania, projekt przyjmuje formę…

Czytaj dalejPoczątek dobry a potem coraz gorzej czyli MVP
Model systemu służy do określenia składników systemu.
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

Czy drzewo kompozycji i dziedziczenie to na pewno jest model aplikacji? Czy model pojęciowy jest modelem systemu? Nie.

Wprowadzenie Wśród wielu stron WWW jest także ta: Modeling Languages (źródło poniżej). Tym razem autorka w tekście "On comparing modelling languages", porównuje kilka wybranych, jak je nazwała, "języków modelowania". Autorka nazywa modelem urządzenia diagramy map myśli i modele pojęciowe, co jest moim zdaniem złym podejściem. Teza, że ontologia to projekt oprogramowania też nie wytrzymuje prostych testów. Modelowanie Najpierw sprawdźmy co oznaczają w literaturze pojęcia model i modelowanie: modelować coś, aby stworzyć kopię lub opis działania, sytuacji itp., aby móc je przeanalizować przed przystąpieniem do prawdziwego działania. https://www.oxfordlearnersdictionaries.com/definition/english/model_2?q=modeling W poprzednim artykule…

Czytaj dalejCzy drzewo kompozycji i dziedziczenie to na pewno jest model aplikacji? Czy model pojęciowy jest modelem systemu? Nie.

Mechanizm działania vs model systemu vs diagram

Wprowadzenie Najczęściej w toku analiz posługujemy się pojęciem model, rzadziej mechanizm. Rzecz w tym, że pojęcie mechanizm pojawia się gdy chcemy coś wyjaśnić, np. "mechanizm generowania upustu na fakturze". Ale tu uwaga! Model (schematy blokowe, wzory itp.) to dokumentacja, opis chroniony prawem autorskim. Mechanizm to to, co zrozumieliśmy czytając te dokumentację (model), bo mechanizm to chronione know-how. Treść wniosku do Urzędu Patentowego to model (opis), ale to co patentujemy to wymyślony/opracowany mechanizm. Mechanizm a model Mechanizm i model w nauce to bliskie sobie pojęcia, np. tak opisywane: Modelowanie polega na…

Czytaj dalejMechanizm działania vs model systemu vs diagram

Ile scenariuszy ma Use Case i dlaczego nie jeden?

Wprowadzenie Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz. Przypadki użycia w UML to "dzieło" Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany "opis czarnej skrzynki". Problemem było to, że "czarna skrzynka" mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i…

Czytaj dalejIle scenariuszy ma Use Case i dlaczego nie jeden?

Wzorzec MVC – dyskusja c.d.

Wprowadzenie Wzorzec ten budzi wiele kontrowersji co do tego czym są te trzy komponenty. Popatrzmy do anglojęzycznej WIKI: Model - Centralny komponent wzorca. Jest to dynamiczna struktura danych aplikacji, niezależna od interfejsu użytkownika. Bezpośrednio zarządza danymi, logiką i regułami aplikacji. W Smalltalk-80, model jest całkowicie pozostawiony programiście. W WebObjects, Rails i Django, model zazwyczaj reprezentuje tabelę w bazie danych aplikacji. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Jest to dominująca definicja w literaturze, zaś spory o to czym jest Model w architekturze MVC jak widać mają jedno główne źródło: jakiego frameworka używa osoba wchodząca w takie…

Czytaj dalejWzorzec MVC – dyskusja c.d.

Prawo autorskie a produkty AI

Lawinowo pojawiają się pomysły prawnego regulowania AI, a nawet upodmiotowienia AI (patrz: Sztuczna inteligencja jest sztuczna, co jest już moim zdaniem kuriozalne). Ale po kolei. Prawo autorskie W ustawie z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych czytamy: Przedmiot prawa autorskiego Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór). 2. W szczególności przedmiotem prawa autorskiego są utwory: 1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi (literackie, publicystyczne, naukowe, kartograficzne…

Czytaj dalejPrawo autorskie a produkty AI

Przed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

Wprowadzenie W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany "Wzorcowe klauzule w umowach IT". Czytam tam między innymi: Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT. (źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it) Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne…

Czytaj dalejPrzed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

Analityk czyli kto?

Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka. O co chodzi Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny zasób z ćwiczeniami UML oraz BPMN? Jest z tym problem bo jest mało literatury i często są to płatne publikacje naukowe. Powód jest dość prozaiczny: 1. komercyjne projektty są chronione tajemnica przedsiębiorstwa, 2. napisanie takich ćwiczeń i przykładów jest pracochłonne i mało kto to robi. Mogę polecić swoją książkę i mojego bloga ;), na blogu pod wpisami zawsze podaje wykorzystaną…

Czytaj dalejAnalityk czyli kto?

Koniec treści

Nie ma więcej stron do załadowania