Analizy biznesowa i projektowanie oprogramowania – Strona 6

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.

Diagram aktywności UML – kiedy

Post author:Jarosław Żeliński
Post published:23 lipca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:10 komentarzy
Post last modified:24 października 2024

Wstęp

Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).

Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 “przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).

Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).

Tak więc obecnie:

Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!

Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.

Nie ma czegoś takiego jak “proces systemowy”, oprogramowanie realizuje “procedury”.

Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.

(więcej…)

Czytaj dalej

SPEM czyli Software & Systems Process Engineering

Post author:Jarosław Żeliński
Post published:8 lipca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:12 listopada 2021

Tym razem artykuł adresowany do zaawansowanych analityków.

Ta specyfikacja (SPEM) jest datowana na 2008 rok. Stanowi sobą tło dla MDA oraz uzasadnia wzorce projektowane oparte na przypadkach użycia (mikroserwisy, Use Case 2.0, inne podobne). Podstawowa różnica między specyfikacją SPEM a specyfikacją UML polega na tym, że UML to profile MOF stanowiące opisy notacji i systemów pojęciowych. SPEM to metamodel procesu wytwórczego oprogramowania czyli generalne zasady budowania procesów wytwarzania i dostarczania oprogramowania.

(więcej…)

Czytaj dalej

Modele as-is i to-be, czy warto je robić?

Post author:Jarosław Żeliński
Post published:11 czerwca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:25 maja 2023

Z zamiarem napisania tego tekstu noszę się już od kilku lat i za każdym razem mówiłem sobie: "ok, jeszcze tylko skończę ten jeden projekt i zobaczymy czy faktycznie ma to sens". I tak od kilku lat. W końcu jednak udało się. Wprowadzenie Popularność podejścia do modeli procesów biznesowych, polegającego na "pokazaniu różnicy", trwa od czasów popularyzacji re-inżynierii procesów biznesowych (lata 90-te) . Umowy na usługi, zawierające w zakresie opracowanie modelu 'as-is' i 'to-be' nadal są podpisywane. Zakładam, że decyzje o zakresie projektu to indywidualne potrzeby zamawiających. Ja opiszę swoje doświadczenia…

Czytaj dalej

Be IT 2021 – po konferencji

Post author:Jarosław Żeliński
Post published:24 maja 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:13 października 2022

W Sobotę 22 maja 2021, na konferencji Be IT 2021 organizowanej przez Koło Naukowe Zarządzanie IT Politechniki Gdańskiej, poprowadziłem warsztat: Analiza i projektowanie struktury informacji. Z uwagi na tematykę: rzeczy dla uczestników nowe, takie jak chmurowe repozytoria i dokumentowe bazy danych NoSQL, poprowadziłem go jako konwersatorium omawiając przykłady repozytoriów NoSQL oferowane w chmurze publicznej oraz omawiając wcześniej przygotowany prosty przykład aplikacji dla Biblioteki, zbudowany z użyciem omówionych wzorców dla baz dokumentowych i notacji UML. Jak co roku otrzymałem ankietę i jak zawsze postanowiłem się z niej wytłumaczyć, a także przyjąć…

Czytaj dalej

Krótka historia pewnego wymagania

Post author:Jarosław Żeliński
Post published:2 maja 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:11 komentarzy
Post last modified:16 czerwca 2024

Wprowadzenie Zarówno w projektach jak i w dyskusjach np. na konferencjach czy na LinkedIn, pojawia się stale pewne nieporozumienie: "projektowanie to waterfall". Myśli tak każdy, kto wyobraża sobie, że projekt czegoś to jakaś masa wszystkich możliwych detali. Jednocześnie nie ja jeden widuję "Dokumenty analizy biznesowej" albo "Dokumenty wymagań" zawierające setki pozycji o treści "system powinien...", nie raz wykonane przez krytyków "water fall", którzy reprezentując developera deklarującego metody "agile", "zabezpieczają się" przez odpowiedzialnością za zakres projektu. Pierwsza ważna uwaga: projekt systemu to nie jest ani zestaw dziesiątków "user story" ani detaliczna…

Czytaj dalej

Kod open source, prawa do niego i jego wartość

Post author:Jarosław Żeliński
Post published:29 kwietnia 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:29 kwietnia 2021

Na stronach portalu LindekIn ukazał sie bardzo dobry artykuł autorstwa Marcina Maruty z kancelarii Maruta Wachta sp.j., na temat oprogramowania open source: Barierą technologiczną jest brak dostępu do kodu źródłowego, niezbędnego dla wprowadzania zmian i rozwoju oprogramowania. Barierą prawną jest natomiast bardzo szeroki zakres ochrony programów komputerowych, który sprawia że jakakolwiek forma korzystania z programu, w tym jego modyfikowanie, wymagają uzyskania zgody uprawnionego. Ruch Open Source, wyrósł ze sprzeciwu wobec takiego stanu rzeczy, stawia sobie za cel tworzenie i popularyzowanie programów ?otwartych?, ?wolnych?, a więc dostępnych wraz z kodem źródłowym…

Czytaj dalej

(źr. Martin Fowler, Analysis Patterns, 1997)

Koncepcja wzorca projektowego dla systemów w chmurze

Post author:Jarosław Żeliński
Post published:11 kwietnia 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:11 kwietnia 2021

Wprowadzenie W 2019 opisałem swoistą próbę rewitalizacji wzorca BCE (Boundary, Control, Entity). Po wielu latach używania tego wzorca i dwóch latach prób jego rewitalizacji uznałem jednak, że Zarzucam prace nad wzorcem BCE. Podstawowy powód to bogata literatura i utrwalone znaczenia pojęć opisujących ten wzorzec. Co do zasady redefiniowanie utrwalonych pojęć nie wnosi niczego do nauki. Moja publikacja zawierająca także opis tego wzorca bazowała na pierwotnych znaczeniach pojęć Boundary, Control, Entity. Sprawiły one jednak nieco problemu w kolejnej publikacji na temat dokumentów . Dlatego w modelu pojęciowym opisującym role komponentów przyjąłem następujące bazowe stwierdzenie:…

Czytaj dalej

Bazy NoSQL jako implementacje wzorców struktur informacji

Post author:Jarosław Żeliński
Post published:2 kwietnia 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:7 komentarzy
Post last modified:10 czerwca 2024

Dane niestrukturalne stanowią ponad 80% składowanych danych, to oznacza, że model relacyjny pozwala opisać i przetwarzać tylko ułamek posiadanej informacji (UNSTRUCTURED DATA AND THE 80 PERCENT RULE) [toc] Wstęp W podsumowaniu niedawnego artykułu o NoSQL w chmurze, napisałem: Problem projektowania struktur dokumentów, także w bazach dokumentowych, to osobne i trudne zagadnienie. Opisałem go w najnowszym artykule, który ukaże się za niedługo w wydawnictwie IGI Global: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation. (Repozytorium w chmurze - NoSQL - Jarosław Żeliński IT-Consulting - Systemy Informacyjne) Artykuł sie właśnie ukazał. We wstępie napisałem:…

Czytaj dalej

Read more about the article Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global

Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases: Business & Management Book Chapter | IGI Global

Post author:Jarosław Żeliński
Post published:29 marca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:30 marca 2021

Jaroslaw Zelinski (Independent Researcher, UK)Source Title: Emerging Challenges, Solutions, and Best Practices for Digital Enterprise Transformation Copyright: ? 2021 | Pages: 24 DOI: 10.4018/978-1-7998-8587-0.ch003 OnDemand PDF Download: Available $37.50 Current Special Offers Abstract This study presents a method for the storage of data organized in digital documents, which is proven in practice. The discussed method does not bear any disadvantages of the relational model used for data organization, such as the loss of data context and complications evoked by the lack of data redundancy. The method presented here can be used for data organization into documents…

Czytaj dalej

Repozytorium w chmurze – NoSQL

Post author:Jarosław Żeliński
Post published:23 marca 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:8 komentarzy
Post last modified:6 grudnia 2021

Wprowadzenie Coraz częściej czytamy o środowiskach "chmurowych" (nadal nie mogę się przekonać do pisania tego bez cudzysłowu). Nawet tak zaawansowane jak Amazon WS czy AZURE, są nadal bardzo często wykorzystywane tylko jako hosting aplikacji. Oba te serwisy można wykorzystywać jako sieciowy dysk, środowisko systemowe (Windows, Linux), bazę danych SQL, ale także jako bazy NoSQL. Jednym z najistotniejszych elementów systemów informacyjnych (patrz: information science) jest utrwalanie danych (pamiętajmy, że dane to zapisy, a informacja to to, co rozumie człowiek, który je czyta). Niedawno nawiązywałem do problemu utrwalania danych. Poprawna obiektowa architektura…

Czytaj dalej

Na co zwrócić uwagę przygotowując się do wyboru systemu w 2021?

Post author:Jarosław Żeliński
Post published:22 lutego 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:28 grudnia 2021

Jak dobrze przygotować się do projektu aby nie wpaść w spirale kosztów? WPROWADZENIE Każdy kolejny rok to kolejne rozpoczynane projekty wdrożeniowe, ale także i kolejne zakończone wdrożenia systemów informatycznych (system). Warto podkreślić, że zakończone wdrożenie nie zawsze oznacza zrealizowany planowany zakres wdrożenia (31% projektów tak się kończy). Zakończone wdrożenie to także bardzo często przerwane wdrożenie (19% projektów) [patrz: Henry Portman, Review Standish Group ? CHAOS 2020: Beyond Infinity, Henny Portman's Blog - On Portfolio, Programme and Project Management, 06.01. 2021]. Uważam, że właśnie te przerwane projekty powinny być podstawowym wyznacznikiem…

Czytaj dalej

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Post author:Jarosław Żeliński
Post published:9 lutego 2021
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:1 października 2024

Tym razem o czymś co potrafi zabić ;) czyli czym jest dokument oraz fakt i obiekt. Czym się różni zakup kilku produktów, w tym samym sklepie, w np. godzinnych odstępach czasu, od zakupu wszystkich razem? Poza formą udokumentowania, niczym: w sklepie to samo i tyle samo zeszło ze stanu magazynu, a my wydaliśmy w obu przypadkach tyle samo pieniędzy (o promocjach później)! W pierwszym przypadku mamy kilka faktów zakupu, w drugim, jeden, ale zawsze tyle samo obiektów (produkt). Faktura (paragon) to dokument opisjący fakt, przedmiot sprzedaży jest obiektem. Tu obiektem…

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy