Analiza procesowa, a obiektowa czyli niedopasowanie oporu
Swego czasu w artykule o Wścipskim Analityku uzasadniałem potrzebę panowania nad wymaganiami od momentu pojawienia się potrzeby biznesowej aż do implementacji. Nie znaczy to absolutnie, że analityk ma programować, znaczy to jednak, że analityk powinien dokumentować to czego żąda w wymaganiach.
| REKLAMA |
 |
Developerzy uzurpują sobie prawa do wszystkiego co wiąże się z implementacją. Z jednej strony często żądają szczegółowych danych np. o danych z drugiej strony sami chcą opisać ich logikę biznesową (tak, bo dane biznesowe to logika biznesowa a nie technologia). Do tego bardzo wielu developerów stosuje metody pracy rodem z przed kilkunastu lat… We wspomnianym wyżej artykule napisałem między innymi o tak zwanym paradygmacie obiektowym i wiedzy o nim u developerów, szukam hasła „analiza procesowa” i „paradygmat obiektowy”:
Jak można radzić sobie z tym „niedopasowaniem”. Pomagają w tym zasady SOLID (w szczególności zasada otwartości na rozszerzenia i zamknięcia na modyfikacje oraz projektowanie zorientowane na zobowiązania klas) oraz wzorce DDD w analizie i projektowaniu.
To co tu opiszę nie jest „prostym algorytmem modelowania”, z pracy myślowej nikogo tu nie zwolnię. Moim celem jest uzupełnienie artykułu o szachownicy i artykułu o zbyt Niskim poziomie analizy o wskazanie, że model dziedziny jest bardziej elementem analizy i modelowania biznesowego niż projektowania i implementacji. Model ten to jedno z kluczowych wymagań: system ma realizować logikę opisaną w modelu dziedziny.
Jeżeli uznamy, że można (taki) model dziedziny implementować to jego opracowanie to także projektowanie. Nadal uważam, że nie jest to robota dla programisty, bo na jakiej podstawie on miał by taki model opracować?
Jak wygląda więc praca analityka biznesowego zgodnie z modelem kompetencyjnym IIBA (IIBA competency model). Kluczowym elementem pracy Analityka Biznesowego (w konwencji IIBA) jest prowadzenie (analiza) wymagań od momentu określenia potrzeby biznesowej aż do implementacji uzyskania właściwego rozwiązania. Jednak uzyskanie to nie to samo co własnoręczne wykonanie. Znowu analogia do budownictwa: architekt na bazie biznesowych celów swojego klienta opracowuje nie tylko wizualizację budynku ale także jego konstrukcję, do takiego poziomu by developer miał jednoznacznie postawione wymagania, nie blokuje to jednak developerowi „realizacji” wszelkich poza-funkcjonalnych wymagań.
Więc po kolei, opracowujemy.
Model procesu biznesowego
Tradycyjnie idziemy do WIKI:Tak właśnie jest: analiza obiektowa i modelowanie obiektowe to nie programowanie. Programowanie (wraz z projektowaniem elementów czysto technicznych) to implementacja modelu.
Przepraszamy, ale nie ma jeszcze artykułu „Analiza procesowa” w Wikipedii. (24 Maj 2011)
No cóż, szukamy dalej:
Process analysis presents a chronological sequence of steps that explain how something is done, how something happens, or how readers can do something. (źr. http://www.tcc.edu/students/resources/writcent/handouts/writing/process.htm).
Coś mamy: analiza procesowa prezentuje w postaci chronologicznej sekwencji kroków, to jak coś powstaje, co się wydarza lub jak można coś zrobić. Piękna definicja. Ta prezentacja to, w kontekście biznesowym, model (mapa) procesów biznesowych.
Mamy wiec uporządkowaną wiedzę o firmie (organizacji) zamawiającego oprogramowanie. Tu także powstaje opis tego po co i gdzie tego oprogramowania chcemy używać: model procesowy.
Tak zwane niedopasowanie oporu
Tak jest nazywana w literaturze różnica pomiędzy paradygmatem procesowym a obiektowym. Paradygmat procesowy operuje takimi pojęciami jak: proces, wejście procesu, wyjście procesu, zdarzenie, wykonawca procesu (zasoby), czynność (lub ich sekwencja). Paradygmat obiektowy to wspomniane obiekty czyli struktury łączące dane i metody ich przetwarzania. W czym problem? W przejściu z modelu procesowego na obiektowy. Czy to łatwe? Nie. Jak to zrobić? Hm… usiąść i popracować nad tym.
Należy przeprowadzić analizę obiektową i wykonać model obiektowy. Czego? Kodu? Nie! Organizacji zamawiającego!
Jak można radzić sobie z tym „niedopasowaniem”. Pomagają w tym zasady SOLID (w szczególności zasada otwartości na rozszerzenia i zamknięcia na modyfikacje oraz projektowanie zorientowane na zobowiązania klas) oraz wzorce DDD w analizie i projektowaniu.
To co tu opiszę nie jest „prostym algorytmem modelowania”, z pracy myślowej nikogo tu nie zwolnię. Moim celem jest uzupełnienie artykułu o szachownicy i artykułu o zbyt Niskim poziomie analizy o wskazanie, że model dziedziny jest bardziej elementem analizy i modelowania biznesowego niż projektowania i implementacji. Model ten to jedno z kluczowych wymagań: system ma realizować logikę opisaną w modelu dziedziny.
Jeżeli uznamy, że można (taki) model dziedziny implementować to jego opracowanie to także projektowanie. Nadal uważam, że nie jest to robota dla programisty, bo na jakiej podstawie on miał by taki model opracować?
Jak wygląda więc praca analityka biznesowego zgodnie z modelem kompetencyjnym IIBA (IIBA competency model). Kluczowym elementem pracy Analityka Biznesowego (w konwencji IIBA) jest prowadzenie (analiza) wymagań od momentu określenia potrzeby biznesowej aż do implementacji uzyskania właściwego rozwiązania. Jednak uzyskanie to nie to samo co własnoręczne wykonanie. Znowu analogia do budownictwa: architekt na bazie biznesowych celów swojego klienta opracowuje nie tylko wizualizację budynku ale także jego konstrukcję, do takiego poziomu by developer miał jednoznacznie postawione wymagania, nie blokuje to jednak developerowi „realizacji” wszelkich poza-funkcjonalnych wymagań.
Więc po kolei, opracowujemy.
Model procesu biznesowego
Mamy tu proces składający się z dwóch elementarnych procesów biznesowych (czynności). Każda czynności, zgodnie z definicją procesu biznesowego, ma dane wejściowe i dane wyjściowe. Dokument 2 i Dokument 3 powstają w tych procesach. Mamy także Procedury tworzenia dokumentów, czyli jakąś logikę ich tworzenia. Pojawia się także reguła biznesowa. Jest to to element z poza notacji BPMN (notacja ta zawiera jednak możliwość oznaczania czynności wymagających użycia takiej reguły). Na diagramie pokazano, regułę biznesową oraz jej powiązanie z konkretną czynnością.
Czas zacząć analizować czyli projektować nasz System. Założenie: wymagane jest by System (oprogramowanie) wspierało oba procesy: 1 i 2 (przypomnę, że proces biznesowy to jedna czynność lub ich sekwencja, więc jedną czynność mającą wejście i wyjście także z definicji, utożsamiany z procesem biznesowym).
Usługi systemu
Usługi systemu to korzeń analizy obiektowej. Stanowią szkielet całego obiektowego projektu. tworzymy bardzo ważny diagram: diagram przypadków użycia.
Czas zacząć analizować czyli projektować nasz System. Założenie: wymagane jest by System (oprogramowanie) wspierało oba procesy: 1 i 2 (przypomnę, że proces biznesowy to jedna czynność lub ich sekwencja, więc jedną czynność mającą wejście i wyjście także z definicji, utożsamiany z procesem biznesowym).
Usługi systemu
Usługi systemu to korzeń analizy obiektowej. Stanowią szkielet całego obiektowego projektu. tworzymy bardzo ważny diagram: diagram przypadków użycia.
Często słyszę, że ten diagram nic nie wnosi do projektu. To nie prawda. Wnosi kluczową informację: wyznacza granice Systemu i wskazuje ewentualne powiązania z innymi systemami. Ale też nie prawdą jest, że służy do pokazania czegokolwiek ponad to, np. kolejności korzystania z usług czy struktury wewnętrznej. To ostatnie robimy w postaci modelu dziedziny.
Na powyższym diagramie udokumentowano:
- System oferuje użytkownikowi dwie usługi (to wymaganie by Czynność 1 i Czynność 2 procesu były wspierane przez System).
- System będzie korzystał z danych innego oprogramowania (Zewnętrznego źródła danych), wymagana jest więc integracja.
- Usługa 2 jest realizowana w całości przez inny, zewnętrzny system, wymagane jest od systemu więc by obsługiwał przekierowanie na inny system (np. realizacja płatności na stronie Banku).
Zakres projektu to wyłącznie to „co w środku”, albo lepiej: wszystko to co jest poza prostokątem System jest poza zakresem projektu. Nie dostarczamy ani Zewnętrznego źródła danych ani Systemu Zewnętrznego usługodawcy ale musimy na liście wymagań zapisać, że integracja z nimi jest wymagana i jaka ona ma być.
Logika działania Systemu – model dziedziny
Zabawa zaczyna się tu: zamieniamy „scenariusze” na „narzędzia i materiały”:
Celowo zachowałem nazwy tak by możliwe było „śladowanie” co z czego powstało. Kilka komentarzy, czyli dobre praktyki, wzorce i styl projektowania.
Każda usługa ma swoją dedykowaną klasę, zmiany realizacji jednej nie przeniosą się na inne. Usługi są więc od siebie niezależne. Oddzielono tworzenie dokumentów od ich przechowywania, dzięki czemu łatwo w przyszłości zmienić metody ich tworzenia bez potrzeby ingerencji w repozytorium. Wszelkie reguły biznesowe (w tym validacji) są „zamknięte” w tak zwanych złożonych typach danych (valueObject, sytuacja idealna to całkowity brak typów prostych (typy proste, primitives) w projekcie, wyłącznie typy złożone). W zasadzie zastąpienie wszystkich typów prostych na złożone w obszarze modelu dziedziny, otwiera w przyszłości drogę do ich rozbudowy bez potrzeby wprowadzania innych zmian w programie. Realnie pomiędzy Aktorem a usługą istnieją klasy widoku (GUI, View w MVC), tu nie umieszczone, bo klasy te nie realizują (nie powinny) żadnej logiki biznesowej.
Powyższy model:
Spełnia zasady SOLID (w szczególności System jest łatwy w rozszerzaniu i nie wymaga w tym celu zmian) Jest zgodny z DDD czyli struktura modelu odwzorowuje strukturę i pojęcia biznesowe.
Co zyskujemy? Niskie koszty dalszego rozwoju, łatwość wyceny projektu przez developera (zna architekturę). Powstanie takiego projektu daje mi gwarancję, że panuje nad nim. Owszem mogę założyć, że developer także taki model opracuje, jednak życie pokazuje, że prawie na pewno nie…
Powyższe z oczywistych powodów (mało miejsca i uogólnienie) nie zawiera szczegółów, ale te należy zawsze w projekcie odkładać na sam koniec. Dzięki temu możemy skupić się na rzeczach na prawdę ważnych (ważne jest by zrozumieć cel tworzenia dokumentu a nie spisać jego zawartość, ta ostatnia wynika z tego do czego służy).
Ostatni wpis na blogu, o Niskim poziomie analizy zawiera akapit:
Istnieje niestety także bardzo duże ryzyko, którego źródłem jest stosowanie starych, strukturalnych metod wytwarzania oprogramowania czyli „rozbiór” (i projekt) systemu na bazę danych i procedury. Ta praktyka (metoda) niestety daje jako efekt oprogramowanie bardzo kosztowne w projektowaniu i rozwoju. Od metod strukturalnych znacznie lepsze są metody obiektowe, niestety samo deklarowanie korzystania z .NET czy Java albo notacji UML nie czyni stosowanych metod obiektowymi.Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.
A gdzie baza danych? Nie tu! Implementacja przechowywania danych to praca developera, nie wolno mu jedynie znormalizować powyższego modelu. Zaprojektowanie relacyjnego modelu i użycie mapowania obiektowo-relacyjnego zniszczy wszystkie zalety tego projektu a dodatkowo strasznie skomplikuje całość.
Na zakończenie, poniższy „potwór” (przykładów nie tylko w sieci, na pęczki) nie ma nic wspólnego z obiektowym paradygmatem, to typowy przykład strukturalnego (a nie obiektowego) projektowania w UML (użycie notacji UML bez błędów składni nie czyni tego projektu obiektowym, to bardzo zły projekt obiektowy, być może poprawny diagram UML):
Źródło: IT-Consulting
Autor: Jarosław Zieliński
Najnowsze wiadomości
Customer-specific AI: dlaczego w 2026 roku to ona przesądza o realnym wpływie AI na biznes
W 2026 roku sztuczna inteligencja przestaje być ciekawostką technologiczną, a zaczyna być rozliczana z realnego wpływu na biznes. Organizacje oczekują dziś decyzji, którym można zaufać, procesów działających przewidywalnie oraz doświadczeń klientów, które są spójne w skali. W tym kontekście coraz większe znaczenie zyskuje customer-specific AI - podejście, w którym inteligencja jest osadzona w danych, procesach i regułach konkretnej firmy, a nie oparta na generycznych, uśrednionych modelach.
PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems
PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.
SkyAlyne stawia na IFS dla utrzymania floty RCAF
SkyAlyne, główny wykonawca programu Future Aircrew Training (FAcT), wybrał IFS Cloud for Aviation Maintenance jako cyfrową platformę do obsługi technicznej lotnictwa i zarządzania majątkiem. Wdrożenie ma zapewnić wgląd w czasie rzeczywistym w utrzymanie floty, zasoby i zgodność, ograniczyć przestoje oraz zwiększyć dostępność samolotów szkoleniowych RCAF w skali całego kraju. To ważny krok w modernizacji kanadyjskiego systemu szkolenia załóg lotniczych.
Wykorzystanie AI w firmach rośnie, ale wolniej, niż oczekiwano. Towarzyszy temu sporo rozczarowań
Wykorzystanie sztucznej inteligencji w firmach rośnie, ale tempo realnych wdrożeń pozostaje znacznie wolniejsze od wcześniejszych oczekiwań rynku. Dane pokazują, że z rozwiązań AI korzysta dziś wciąż niewiele przedsiębiorstw, a menedżerowie coraz częściej wskazują na bariery regulacyjne, koszty oraz brak powtarzalnych efektów biznesowych. W praktyce technologia jest testowana głównie w wybranych obszarach, a kluczowe decyzje nadal pozostają po stronie człowieka. Również w firmach, które wdrożyły AI, nierzadko towarzyszą temu rozczarowania.
Europejski przemysł cyfryzuje się zbyt wolno – ERP, chmura i AI stają się koniecznością
Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.
Europejski przemysł średniej wielkości wie, że cyfryzacja jest koniecznością, ale wciąż nie nadąża za tempem zmian. Ponad 60% firm ocenia swoje postępy w transformacji cyfrowej jako zbyt wolne, mimo rosnącej presji konkurencyjnej, regulacyjnej i kosztowej. Raport Forterro pokazuje wyraźną lukę między świadomością potrzeby inwestycji w chmurę, ERP i AI a realną zdolnością do ich wdrożenia – ograniczaną przez braki kompetencyjne, budżety i gotowość organizacyjną.
Najnowsze artykuły
5 pułapek zarządzania zmianą, które mogą wykoleić transformację cyfrową i wdrożenie ERP
Dlaczego jedne wdrożenia ERP dowożą korzyści, a inne kończą się frustracją, obejściami w Excelu i spadkiem zaufania do systemu? Najczęściej decyduje nie technologia, lecz to, jak organizacja prowadzi zmianę: czy liderzy biorą odpowiedzialność za decyzje czy tempo jest dopasowane do zdolności absorpcji oraz czy ludzie dostają klarowność ról i realne kompetencje. Do tego dochodzi pytanie: co po go-live - stabilizacja czy chaos w firmie? Poniżej znajdziesz 5 pułapek, które najczęściej wykolejają transformację i praktyczne sposoby, jak im zapobiec.
SAP vs Oracle vs Microsoft: jak naprawdę wygląda chmura i sztuczna inteligencja w ERP
Wybór systemu ERP w erze chmury i sztucznej inteligencji to decyzja, która determinuje sposób działania organizacji na lata — a często także jej zdolność do skalowania, adaptacji i realnej transformacji cyfrowej. SAP, Oracle i Microsoft oferują dziś rozwiązania, które na pierwszy rzut oka wyglądają podobnie, lecz w praktyce reprezentują zupełnie odmienne podejścia do chmury, AI i zarządzania zmianą. Ten artykuł pokazuje, gdzie kończą się deklaracje, a zaczynają realne konsekwencje biznesowe wyboru ERP.
Transformacja cyfrowa z perspektywy CFO: 5 rzeczy, które przesądzają o sukcesie (albo o kosztownej porażce)
Transformacja cyfrowa w finansach często zaczyna się od pytania o ERP, ale w praktyce rzadko sprowadza się wyłącznie do wyboru systemu. Dla CFO kluczowe jest nie tylko „czy robimy pełną wymianę ERP”, lecz także jak policzyć ryzyko operacyjne po uruchomieniu, ocenić wpływ modelu chmurowego na koszty OPEX oraz utrzymać audytowalność i kontrolę wewnętrzną w nowym modelu działania firmy.
Agentic AI rewolucjonizuje HR i doświadczenia pracowników
Agentic AI zmienia HR: zamiast odpowiadać na pytania, samodzielnie realizuje zadania, koordynuje procesy i podejmuje decyzje zgodnie z polityką firmy. To przełom porównywalny z transformacją CRM – teraz dotyczy doświadczenia pracownika. Zyskują HR managerowie, CIO i CEO: mniej operacji, więcej strategii. W artykule wyjaśniamy, jak ta technologia redefiniuje rolę HR i daje organizacjom przewagę, której nie da się łatwo nadrobić.
Composable ERP: Przewodnik po nowoczesnej architekturze biznesowej
Czy Twój system ERP nadąża za tempem zmian rynkowych, czy stał się cyfrową kotwicą hamującą rozwój? W dobie nieciągłości biznesowej tradycyjne monolity ustępują miejsca elastycznej architekturze Composable ERP. To rewolucyjne podejście pozwala budować środowisko IT z niezależnych modułów (PBC) niczym z klocków, zapewniając zwinność nieosiągalną dla systemów z przeszłości. W tym raporcie odkryjesz, jak uniknąć pułapki długu technologicznego, poznasz strategie liderów rynku (od SAP po MACH Alliance) i wyciągniesz lekcje z kosztownych błędów gigantów takich jak Ulta Beauty. To Twój strategiczny przewodnik po transformacji z cyfrowego "betonu" w adaptacyjną "plastelinę".
Jak zarządzanie zmianą decyduje o sukcesie transformacji ERP i AI?
Zarządzanie zmianą decyduje dziś o tym, czy transformacja ERP lub wdrożenie AI przyniesie realną wa… / Czytaj więcej
Niezastąpiony partner w IT: rola Delivery Managementu w projektach outsourcingowych
W świecie, w którym technologia i stawki dostawców IT coraz częściej się wyrównują, prawdziwą przew… / Czytaj więcej
Cyfrowa autonomia w praktyce: nowy mandat CIO od rady nadzorczej
W raporcie McKinsey suwerenność technologiczna jest opisana jako zdolność do rozwijania i kont… / Czytaj więcej
Strategiczna przewaga czy kosztowny mit? Kto wygrywa dzięki chmurze?
Chmura miała być odpowiedzią na wyzwania sektora finansowego: przestarzałą infrastrukturę, rozprosz… / Czytaj więcej
Jak zminimalizować ryzyko strat w biznesie i zwiększyć rentowność klientów?
Prowadzenie biznesu w dynamicznie zmieniającym się środowisku gospodarczym wiąże się z wieloma wyzw… / Czytaj więcej
Nowe narzędzie, nowe możliwości – Adrian Guzy z CTDI o innowacyjności, kulturze pracy z danymi i analityce w Microsoft Fabric
W nowej siedzibie CTDI w Sękocinie Starym pod Warszawą tafle szkła odbijają poranne słońce, a wnętr… / Czytaj więcej
