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.
Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć... Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice…
Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization?s business profile, and the architect?s professional practices. The authors also have greatly expanded their treatment of quality…
Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje:
- sama struktura to nie model,
- tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury,
- dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]),
- bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).
Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...
SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu: Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR (Źródło: SBVR) A dzisiaj kilka słów na temat aneksu: Annex F - The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty): Pierwszoplanowe, a nie wtórne, wymagania 1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część. Oddzielone od procesów, a nie…
Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy, ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?). (w uproszczeniu: zdalnie prowadzona analiza to kluczowa przyszła kompetencja analityków, warto przestać torturować ludzi wielogodzinnymi nudnymi spotkaniami, znajdź…
Wprowadzenie Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie elementów procesu biznesowego, z tym jaka "praca myślowa" wykonawcy ma być w danym procesie (aktywności) wykonana. Drugi błąd to mieszanie poziomów abstrakcji: proces biznesowy to dość duży poziom ogólności (uogólnienia), jego celem jest pokazanie celowości łańcucha pracy (procesy biznesowe to aktywności tworzące produkty) a nie tego, jak jest w detalach wykonywana: wnętrze tych aktywności - ich szczegóły - na…
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…
Cóż, kolejny raz odkrywam, że jestem zwinny :). A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80'tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie "wodospadowe" złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie "rezygnacja z pracochłonnej dokumentacji" (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie…
Od 2005 roku jestem użytkownikiem pakietu CASE Visual-Paradigm (poprzednia nazwa Agilian). Od tamtej pory nie zmieniłem narzędzia mimo, że na warsztatach, które prowadzę, mam przegląd chyba wszystkiego co mamy na rynku, a co przynoszą ze sobą na notebookach uczestnicy tych warsztatów. Whats new in 12.1 - strona o tym tytule powitała mnie dzisiaj z rana gdy sprawdzałem pocztę. Rozszerzony generator raportów. Nowy typ raportu generujący dokumenty wynikowe z szablonów word.Nowa wersja narzędzia to tworzenia mock-up'ów, dodano także możliwość korzystania z istniejących WWW przy dokumentowaniu zmian.Ulepszona Postmania (strony dla recenzentów diagramów).Integracja Vpository z…
Rola architektury danych znalazła także odzwierciedlenie w zarobkach architektów danych. Diagram 3 przedstawia średnie zarobki roczne architektów różnych specjalności w tysiącach USD (dla porównania dodano także inne specjalności z obszaru IT). Widać wyraźnie, że architekci danych są wśród najwyżej opłacanych specjalistów. (źr. Architekt danych ? zawód przyszłości?). ja obserwuje coś "obok", otóż dane są wtórne w stosunku do faktów, obecne systemy raczej odchodzą od "jednolitych współdzielonych baz danych", i nie dlatego, że RDBMS są "niemodne", a dlatego, że same dane pozbawione kontekstu, są mało wartościowe (do tego normalizacja modeli danych to proces…
Od czasu do czasu jestem pytany o różne "frameworki" i metodyki dotyczące "całościowego opisu firmy". Można spotkać wiele różnych, lepszych lub gorszych modeli i szablonów, ram (frameworków), jednak moim zdaniem, podejście minimalistyczne jest najlepsze. Zmusza do zrozumienia istoty rzeczy, bez maskowania niewiedzy nowymi i, nie raz, sztucznymi pojęciami. Drugim powodem, który moim zdaniem leży u podstaw pomysłów na "nowe modele", jest prawo autorskie. Opracowanie unikalnego "frameworka" czyni z autora takiego dzieła "właściciela metody", za którą ma prawo pobierać opłaty licencyjne (przykładem jest np. TOGAF i notacja ArchiMate chronione prawem autorskim przez…
