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.
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.
[toc]
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…)
Wstęp
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…
Industry 4.0 concept, smart factory with icon flow automation and data exchange in manufacturing technologies.
Miesiąc temu pisałem: Mechatronika i notacja SysML ma swoje początki w latach 90-tych. Modele w tej notacji powstawały już w firmie Boeing (Herrold, 2016). Od tamtej pory powstało wiele publikacji na ten temat, w tym także opisy dobrych praktyk jakimi są wzorce projektowe (Barbieri, Kernschmidt, Fantuzzi & Vogel-Heuser, 2014). Można spotkać coraz częściej publikacje na temat stosowania metod projektowania opartych na SysML (Van Noten, Gadeyne & Witters, 2017).Moim celem było tu zwrócenie uwagi na tę w sumie nową dziedzinę inżynierii, ważne by nie utożsamiać jej jedynie z robotyką, bo było by to ogromne uproszczenie, co mam nadzieję…
Wprowadzenie Jednym z podstawowych problemów w projektach związanych z systemami informacyjnymi, jest komunikacja z ekspertami dziedzinowymi sponsora projektu. Osoby te stanowią podstawowe źródło informacji i są także kluczowymi recenzentami powstającej dokumentacji: potwierdzają, że analityk i projektant zrozumiał dziedzinę problemu. Sformalizowane systemy notacyjne są niejednokrotnie dość bogate w symbole, te zaś dla większości ludzi są mało intuicyjne, a ich formalizm bywa niezrozumiały. W efekcie analitycy i projektanci albo prowadzą szkolenia przygotowujące zespoły projektowe do projektu albo uciekają się do stosowania łatwo przyswajalnych nieformalnych schematów blokowych. Obie drogi stwarzają ryzyko w projekcie.…
Wprowadzenie ?Problemy, w których rozwiązaniu mają pomóc budowane złożone systemy są zwykle ?problemami złośliwymi? . ?Problem złośliwy? to taki skomplikowany problem, w którym jest tak wiele powiązanych ze sobą bytów, że nie istnieje jego ostateczna specyfikacja. Prawdziwy charakter problemu objawia się dopiero w miarę opracowywania rozwiązania.? W roku 2014 w artykule Studium wykonalności produktu - czym naprawdę jest napisałem na zakończenie: W literaturze można spotkać różne ?definicje? studium wykonalności, jednak ta którą opisałem, zdaje się być najbliższa definicji, którą przytoczyłem na początku: bazującej na znaczeniu słownikowym. Praktyka pokazuje, że intencje sponsorów…