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.
Generalnie modele referencyjne mają i dobrą i złą sławę. Nie są to wzorce projektowe, czyli dobre praktyki w postaci uniwersalnych abstrakcyjnych meta-modeli, są to najczęściej narzucane gotowe architektury, pozostaje pytanie: kto narzuca?. Procesy referencyjne krytykowałem nie raz (Procesy referencyjne czyli kto żyw niech ucieka), referencyjny model ERP oznaczałby, że istnieje jakaś jedynie słuszna architektura systemu ERPII. I właśnie dostawcy wielu systemów ERPII (szczególnie ci duzi, których produkty mają wiele lat) promują model oparty o jedną wspólną relacyjną bazę danych, wokół której są osadzone dziedzinowe moduły, nazywają taki model modelem referencyjnym.…
Wprowadzenie Od czasu do czasu jestem proszony o audyty dokumentacji projektów. Ma to miejsce, albo gdy jestem angażowany do projektu będącego kolejnym podejściem do wdrożenia, albo w sporach, także przedsądowych, między dostawcą oprogramowania i zamawiającym. Bywa, że jest to już etap pisania opinii dla sądu. Tu razem kilka spostrzeżeń z tych analiz. Na marginesie. W sporach przedsądowych i sądowych wynik ekspertyzy absolutnie nie może być "zamówiony", czego niestety często oczekują, nie raz wręcz żądają pod groźbą odmowy zapłaty za tę usługę, zamawiający takie ekspertyzy. Bywa to tym bardziej żenujące, że…
Tytułowe User Story i Story Mapping miały (mają) być remedium na problemy z wymaganiami. Czy są nim? Słownik Języka polskiego: rozwiązanie: ?projekt i realizacja założeń architektonicznych, konstrukcyjnych, plastycznych itp.? Innymi słowy rozwiązanie to określone narzędzia pracy. W tym przypadku narzędziem jest aplikacja (oprogramowanie). Nadal popularne wśród developerów user story, jako narzędzie opisu wymagań pokazało swoje wady, lekarstwem na nie ma (miało) być story mapping. Kluczową wadą tego (użytkownik opisuje aplikację) podejścia jest założenie, że użytkownik ma racje (wie czego chce). Problem w tym, że nawet jeżeli użytkownika wie co robi,…
W tym roku ukazała się książka, której autorem jest Mark Wilkins: Amazon Web Services: podstawy korzystania z chmury AWS : Książka sprawia wrażenie bardzo technicznej, ale pisana jest jasnym językiem i bogato ilustrowana. Na 464 stronach opisano usługi chmurowe oferowane przez Amazon. Autor na szczęście nie miał ambicji zastąpienia swoją książką oryginalnej dokumentacji, nastawił się (moim zdaniem) na wyjaśnienie mechanizmów działania poszczególnych usług i to właśnie wzbudziło moją sympatię do autora. Jeżeli po książkę sięgną developerzy to pewnie dlatego, że ją po prostu znaleźli w toku zawodowych poszukiwań. Ja polecam…
Zarządzanie ryzykiem to proza życia kierowników projektów. Z jednej strony doświadczony kierownik projektu powinien doskonale radzić sobie z ryzykiem, z drugiej zaś strony praktyka projektów pokazuje, że efekty są niestety słabe bo ok. 90% IT na świecie ma przekrocozne budżety i terminy . Jednym z ciekawszych narzędzi zarządzania ryzykiem jest mało popularny tak zwany stożek niepewności. Ogólna zasada planowania mówi, że im bardziej w przyszłość wybiegają prognozy tym bardziej są one niepewne. Jest nie tylko intuicyjne ale i udowodnione matematycznie. Stożek niepewności to wykres pokazujący związek pomiędzy kosztami projektu a…
Profil UML i meta-model typów dokumentów jako system organizacji danych. Dokument jako kontekstowa struktura informacyjna. Streszczenie: Opisano sprawdzona w praktyce metodę składowania danych zorganizowanych w dokumenty. Opisana metoda nie ma wad relacyjnego modelu organizacji danych, jakim jest utrata kontekstu danych i komplikacje wywołane brakiem redundancji danych. W pracy tej przedstawiono metodę organizacji danych w dokumenty jako sklasyfikowane agregaty, metodę ich klasyfikacji oraz metamodel ich budowy. Opisany metamodel zakłada, że dokumenty jako struktury danych to zwarte agregaty, klasyfikowane jako opisy obiektów (object) lub wydarzeń (events) co nadaje im zawsze określony i jednoznaczny kontekst. Opisano także metodę projektowania dokumentów jako agregatów kontekstowych, co pozwala zniwelować wskazane wady modelu relacyjnego oraz zagwarantować skuteczność zarządzania informacją. Dodatkowo opisany…
Wprowadzenie Jednym z najczęściej stosowanych wzorców projektowych w warstwie dziedzinowej jest wzorzec CQRS (Command Query Responsibility Segregation) oraz często wykorzystywany razem z nim Event Sourcing. W 2012 roku pisałem o tym wzorcu w kontekście optymalizacji wydajnosci: Idea tego pomysłu na tym, by nie optymalizować wydajności systemu metodą, nie raz zgniłego, kompromisu, a podejść do problemu dzieląc go na dwa problemy: zgodność modelu z rzeczywistością i wydajność całego systemu. Pierwszy problem rozwiązujemy tworząc wierny model struktury opisującej produkty, drugi problem ? wydajności ? rozwiązujemy tworząc drugi uproszczony model produktów, do celów szybkiej realizacji kilku…
Architektura referencyjna przeglądarki internetowej i aplikacji webowych.
Wprowadzenie
Bardzo wiele problemów w toku wdrożeń IT rodzą wadliwie zaprojektowane struktury dokumentów. Dotyczy to w szczególności zarządzania dostępem do treści, a patrząc szerzej: do informacji. Ostatnie lata to między innymi problemy urzędów z udzielaniem dostępu do informacji publicznej, od dwóch lat dodatkowo problemy stwarza RODO. Źródłem problemów jest treść dokumentów, rozumiana jako pytanie: “Czy te informacje muszą być zawarte w tym dokumencie”. Najpierw opiszę mechanizm powstawania przyczyn problemów i sposób ich rozwiązania. W podsumowaniu wskażę jak i gdzie sobie z tym radzić.
(więcej…)
Wprowadzenie
Napisałem o orientacji na dokumenty w toku analiz:
Często jestem i ja pytany o to ??Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?? Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. (Wymagania na formularze czyli diagramy struktur złożonych i XML)
Dzisiaj pójdziemy dalej, omówimy to gdzie i jak zachować tę informację. Posłużę się prostym przykładem przychodni weterynaryjnej. Artykuł będzie opisem metody podejścia do analizy zorientowanej na procesy i dokumenty.
Tekst ma dwie części: pierwsza jest opisem drogi jaka prowadzi nas do zdefiniowania tego jakie dokumenty, jaką mają (mieć) zawartość i strukturę. Praktycznie jest to opis analizy i projektowania. Druga – krótka – to przykładowa architektura logiki realizacji aplikacji, pokazująca miejsce dokumentowej bazy danych w architekturze i projekcie, czyli także projektowanie.
Celem tego wpisu jest pokazanie czym może być analiza oraz jej produkt jakim jest Techniczny Projekt Oprogramowania.
(więcej…)
Industry 4.0 concept, smart factory with icon flow automation and data exchange in manufacturing technologies.
Streszczenie: W artykule opisano zastosowanie obiektowych metod modelowania i notacji UML do opisu systemów agentowo-zorientowanych. Pokazano, że systemy agentowe różnią się od obiektowych założeniem, że system o agentowej architekturze zakłada autonomiczność obiektów, stanowiących komponenty z jakich system jest zbudowany. W typowych obiektowych architekturach obiekty nie są autonomiczne, sekwencje ich współpracy są z góry ustalone. System agentowo-zorientowany zakłada, że reakcja systemu jest tworzona dynamicznie jako efekt zachowania komponentów jakimi są autonomiczne agenty. Zdaniem autora systemy agentowe od obiektowych różni tylko to założenie. Warto jednak zwrócić uwaga na to, że tak zwane ‘systemy uczące się’ to raczej systemy agentowo-zorientowane.
(więcej…)
(źr. Facebook, International Institute of Business Analysis)
Structured System Analysis tools & techniques by Chris Gane and Trish Sarson Dzisiaj nieco archeologii. Właśnie upolowałem książkę jak poniżej : Jednym z powodów był niedawny artykuł (Diagram Przepływu Danych...) na temat diagramów DFD i zobrazowaniu kluczowych funkcjonalności systemów. Książka napisana w 1977 roku, ja mam wydanie z 1989-go (!). Nie raz tu pisałem, że w branży IT jest źle, nadal: "The Standish Group report 83.9% of IT projects partially or completely fail" (83%9 projektów IT to porażki). Ale ciekawsze jest to, że tak jest od początku tej branży do…
![Read more about the article Dokument jako nośnik danych i metoda zarządzania danymi – [preprint]](https://it-consulting.pl/wp-content/uploads/2013/07/documentation.jpg){kind=small}
