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.
?Wszystko powinno być tak proste jak jest to możliwe, ale nie prostsze.? (Albert Einstein) Stosunkowo niedawno (piałem o tym już) Roger Burlton (Chairman, Board of Advisors, BPTrends) opublikował na stronie Business Process Trends Manifest Procesu Biznesowego. Podejrzewam, że to efekt lekkiej" konkurencji z [[Business Rules Group]] i Ronaldem G. Rossem ;) ale dobrze bo taka konkurencja jest twórcza a ich (głównie Ronald G. Ross BRGroup oraz Paul Harmon z BPTrends) obecne ich polemiki na stronach LinkedIn są bardzo pouczające i myślę, że obie strony na tym zyskują, że nie wspomną o pozostałych…
We wtorek miałem referat na warsztatach zorganizowanych przez MMC Polska: KPI ? Zarządzanie wskaźnikami w praktyce. Mój referat i warsztat zarazem był zatytułowany: KPI a system zarządzania przez cele. Nie będę streszczał 1,5 godzinnego warsztatu, raczej zapraszam na następne. Tu zwrócę uwagę na kilka ciekawych i ważnym moim zdaniem kwestii. Niestety w literaturze i w sieci jest wiele dziwnych, moim zdaniem tez, np. Punktem wyjścia do doboru wskaźników powinna być strategia organizacji. Dlaczego strategia? Wskaźnik opisuje jakiś parametr obszaru działania organizacji, z reguły jest miernikiem wskazującym to czy zrealizowano jakieś zadanie. Strategii nie…
Jeżeli uznamy, że modelowanie zachowania organizacji w postaci modelu procesów polega wyłącznie na tworzeniu diagramów zawierających kolejno wykonywane detaliczne czynności, to znaczy że wszelkie powyżej opisane zachowania znajdą się jako "równoprawne" aktywności na tych diagramach. Powstają monstrualne nieczytelne schematy blokowe, zawierające setki detali, trudne do interpretacji, trudne i kosztowne w utrzymaniu (aktualizacja), i przede wszystkim nie pozwalające na wyprowadzenie wprost z nich wymagań na oprogramowanie. Można w zasadzie zaryzykować tezę, że tak tworzone modele, w których cała wiedza o organizacji została zapisana jako łańcuchy detalicznie zobrazowanych czynności, tak na prawdę do niczego nie są przydatne. [...] Czemu więc służą żmudne wywiady, warsztaty, burze mózgów w toku analiz firm? Zaryzykuję, tezę, że niczemu nie służą.
źr. http://www.modernanalyst.com/Resources/BusinessAnalystHumor/tabid/218/Default.aspx?ArticleType=ArticleView&ArticleID=2471
Cztery lata temu, pisałem o regułach biznesowych jako elemencie modelu biznesowego i ich roli w zarządzaniu: Na czym więc polega skuteczne zarządzanie? Na zrozumieniu, posiadaniu planu działania i przemyślanym tworzeniu ograniczeń.Robi tak każda większa firma: powstają zakresy obowiązków, wewnętrzne zarządzenia i procedury. To wszystko to nic innego jak ograniczenia.Opracowanie modelu organizacji więc, to nie tylko opisanie procesów bo te są jedynie efektem istniejących ograniczeń. Pełny model organizacji, dający zrozumienie tego jak ona działa, to kompletny model pojęciowy ? nazwy i definicje podstawowych pojęć opisujących jej działanie (co to jest klient, produkt, kontrahent, ?), specyfikacja wszelkich…
Wprowadzenie Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa Lato 2015 firmowanym przez Warszawski oddział IIBA. Pozwolę sobie na pewną polemikę z przedstawionym tam procesem transformacji modelu procesów biznesowych BPMN na Przypadki Użycia notacji UML. Autor powołuje się na OMG.org i specyfikacje BPMN i UML. Dlatego dla porządku przytoczę kluczowe definicje. 10.3 ActivitiesAn Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic(compound). The types…
Co prawda formalna publikacja wersji 2.5 UML to 1 marzec 2015 r. ale co ma wisieć nie utonie (spokojne przebrnięcie tych 794 stron wymaga czasu i cierpliwości), czyli wzmianka i kilka słów z pierwszych wrażeń. Specyfikacja do pobrania tu: Documents Associated With Unified Modeling Language (UML) Version 2.5 (Źródło: UML 2.5) Zdaję sobie sprawę z tego, że poniższe nie wszystkim z Was wszystko wyjaśni ale ten akurat wpis adresuję dla tych z Was, którzy korzystają już z UML, nawet w bardzo prosty sposób. Wersja 2.5 UML to wersja chyba przełomowa, bo: zrezygnowano w…
Pół roku temu artykuł o roli Product Ownera kończyłem słowami: Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak ?bycie product ownerem? w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i…
Dzisiaj bardzo krótko. Bardzo lubię termin "inżynieria wymagań" dlaczego? Po kolei. Z wiedzy o semantyce i semiotyce wiemy, że zastąpienie pojęcia jego definicją nie może zmienić (nie może, jeżeli definicje są poprawne) znaczenia całości. Więc zastąpmy w zwrocie "inżynieria wymagań" oba słowa ich definicjami (definicje ze słownika j.polskiego PWN): inżynieria ?projektowanie i konstruowanie obiektów oraz urządzeń technicznych? wymaganie ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać? Po podstawieniu otrzymamy zwrot mówiący, że "inżyniera wymagań" to: ?projektowanie i konstruowanie? ?warunków, którym ktoś lub coś musi odpowiadać? Więc nie jest to…
Napisałem ten artykuł jako zapowiedź tego, że będę pisał od czasu do czasu o ekonomii bo przedsiębiorstwa, organizacje, my wszyscy, tkwimy w jakimś systemie ekonomicznym. Systemy informatyczne i systemy informacyjne to fascynująca dziedzina, systemy te są częścią systemu ekonomicznego w jakim funkcjonują, lub będą funkcjonowały jako planowane do wdrożenia. To powoduje, że planowanie takich wdrożeń powinno być - dla zminimalizowania ryzyka porażki - robione świadomie i ze zrozumieniem. Ekonomia zawsze stanowi kontekst wdrażanych systemów ERP i innych, skoro tak nie można nie brać jej pod uwagę w toku analiz z nimi związanych. Do tej pory nie poruszałem tej wiedzy w swoich postach ale przyszła pora i na to.
Szperałem w sieci szukając informacji o architekturze i microservisach, a wpadłem na to: ... communication between two different software modules is proportional to the communication between the designers and developers of these modules. Conway?s law exposes the vulnerability in monoliths as they grow in size. Micro-services may not be the best, but better than monoliths for the contemporary web based applications. (Źródło: Micro-Services: A comparison with Monoliths | My Blog) To "prawo" wyjaśnia dlaczego powstają złe interfejsy a nawet zła architektura: z reguły dlatego, że to - architektura - jest lepszym lub…
W efekcie systemy nazywane nadal ERP to raczej już tylko jądro zarządzania (nadal bardzo ważne) integrowane z dziedzinowymi podsystemami (np. wymienionymi wyżej) innych producentów, aniżeli wielki zintegrowany, kosztowny i we wdrożeniu i w utrzymaniu moloch. ERP w reklamowanej jako "system do wszystkiego" ma raczej sens w małej firmie o nieskomplikowanej działalności, większe firmy wymagają jednak większej podatności ma zmiany czego ERP w "jednym kawałku" nigdy nie da, a duży jednorazowy koszt jest zbyt wielkim ryzykiem.
Najpierw przypomnę moją tezę z artykułu napisanego w 2011 roku: Zaryzykuje tezę: ?Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty?.Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani. (Źródło: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych! | Jarosław Żeliński IT-Consulting) Mam nadzieję, że to - ta krótka recenzja - będzie skutecznym początkiem zachęcania do czytania tego co powszechnie nazywa się filozofią. Ta pozycja to zbiór pism, wykładów Fregego, ja jednak polecam tę…