Low-code i no-code w praktyce – BPM & RPA

(streszczenie referatu na konferencji zorganizowanej 30 stycznia 2025 przez pureconferences.pl). Wprowadzenie Narzędzia zwane low-code oraz no-code (LCNC) znane są od czasów komputerów zwanych biurkowymi (np. narzędzie Clarion, 1986 rok), takim narzędziem był także arkusz kalkulacyjny VisiCalk a potem Lotus 123 (1979). Czy pomagają? Szybo się okazało, że tak zwany biznes po prostu przenosi do tych narzędzi to co i jak robi "na papierze" bez zastanawiania się czy to ma sens. Dzisiaj to zjawisko nazywamy "eksceloza" i nie przypadkiem ma to słowo charakter pejoratywny. Czy zlecanie dedykowanego oprogramowania jest lepsze czy…

Czytaj dalejLow-code i no-code w praktyce – BPM & RPA

Webhook – zwrotne wywołania API

Wprowadzenie Swego czasu opisywałem wzorce projektowe i API (Integracja systemów ERP jako źródło przewagi rynkowej. Projektowanie REST API i scenariuszy). Kluczowym wzorcem jest wzorzec SAGA, czyli sterowanie sekwencją wymiany danych z jednego miejsca. Wzorzec ten to typowy system klient-serwer (usługobiorca-usługodawca) i sprawdza się doskonale, gdy sterowanie z jednego miejsca rozwiązuje wszystkie problemy integracji. Pewnym problem jest tu jednak to, że serwer musi zostać odpytany by klient poznał jego stan, a nie zawsze jest to wystarczające. Opis problemu Wyobraźmy sobie, że mamy system WMS (ang. Warehouse Managements System, zarządzanie magazynami) oraz…

Czytaj dalejWebhook – zwrotne wywołania API

Depozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Wprowadzenie W 2021 roku, w artykule Transformacja Cyfrowa a dziedzictwo IT pisałem: Aby transformacja cyfrowa była w ogóle możliwa, musimy przenieść te dane (treści, informacje) z papieru „do komputera”, w sposób nieniszczący obecnych możliwości i pozwalający na tworzenie nowych. Trzeba też zniwelować posiadany dług technologiczny. Dług technologiczny to posiadane dziedzictwo, to zapóźnienie, to pozostawanie w tyle za trwającym postępem technologicznym. Dług taki ma bardzo wiele firm https://it-consulting.pl/2021/11/21/cyfrowa-transformacja-a-dziedzictwo-it/ W tym tekście poruszam pokrewny temat jakim jest zabezpieczenie się bo kluczowe pytanie brzmi: co zabezpieczyć mają "wszystko w wersji elektronicznej"? Bardzo często…

Czytaj dalejDepozyt kodu źródłowego czyli co naprawdę należy chronić? Archiwum!

Czym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Wstęp

Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu kończyłem słowami:

Tak więc wyma­gań biz­ne­so­wych może być kil­ka­dzie­siąt. Wymaganych usług sys­te­mu (przy­pad­ków uży­cia) w dużym pro­jek­cie tak­że może być kil­ka­dzie­siąt. Ale set­ki, czy tysią­ce ??wyma­gań? to wyraz utra­ty pano­wa­nia nad zakre­sem pro­jek­tu? Tu zwró­cę uwa­gę, że wyma­ga­niem (usłu­ga sys­te­mu) może być np. wytwo­rzo­na fak­tu­ra VAT zgod­na z prze­pi­sa­mi. Cechy tej fak­tu­ry (lista pól) to nie osob­ne wyma­ga­nia, to cechy (para­me­try, atry­bu­ty) jed­ne­go wyma­ga­nia. Żadna cecha fak­tu­ry VAT nie ma sama w poje­dyn­kę żad­nej war­to­ści, nie może więc być oddziel­nym przy­pad­kiem uży­cia, tak samo jak wyma­ga­niem naszym może być samo­chód, ale jego kolor czy auto­ma­tycz­na skrzy­nia bie­gów, to cechy samo­cho­du, nie ma sen­su wyma­gać ??czer­wo­ne­go kolo­ru? nie ocze­ku­jąc samo­cho­du (i jak uza­sad­nić, to że ten kolor wspie­ra cel biz­ne­so­wy). Przypadkiem uży­cia samo­cho­du jest podróż a nie wło­że­nie klu­czy­ka do sta­cyj­ki, bo to jest tyl­ko jeden z ele­men­tów sce­na­riu­sza roz­po­czę­cia podró­ży samochodem.

Source: Dlaczego śladowanie wymagań jest istotne w projekcie? – Jarosław Żeliński IT-Consulting

Nadal pojawiają się publikacje o wymaganiach, zarządzaniu nimi i realizowaniu ich. Na rynku są dostępne aplikacje pozwalające je kolekcjonować i zarządzać taką kolekcją. I stale mamy do czynienia z ich – wymagań – niejednoznacznością . Okazuje się, że ich znaczenie staje sie kluczowe dla projektów, także z perspektywy prawa (PZP i zdefiniowane w zaleceniach UZP pojęcie potrzeba). Tym razem skupię się na pojęciach ‘wymaganie’ i ‘potrzeba’ w odniesieniu do projektu rozwiązania.

(więcej…)

Czytaj dalejCzym sie różnią wymagania wobec rozwiązania od potrzeb użytkownika?

Model UML i stereotypy jako ikony

Wprowadzenie Modele UML są często postrzegane jako niezrozumiałe diagramy. Do napisania tego artykułu skłonił mnie pewien wpis na LinkedIn, w którym pokazano ciekawy schemat blokowy: źr.: Marcel van Oost, LinkedIn, https://www.linkedin.com/posts/marcelvanoost_fintech-payments-paytech-activity-7085945466286153728-GEgt Nie tylko moim zdaniem jest to bardzo obrazowe pokazanie tego jak działają te systemy płatności, szczególnie, że bardzo dobrze jest dobrany poziom abstrakcji: autorowi udało sią pokazać istotę mechanizmu realizacji tych płatności bez zbędnych detali. Pierwsze moje wrażenie, gdy zobaczyłem ten diagram to: to jest diagram komunikacji UML a obrazowe ikony na tym diagramie to stereotypy. Stereotyp czyli typ…

Czytaj dalejModel UML i stereotypy jako ikony

Diagramy w notacji UML

Wprowadzenie "The Unified Modeling Language User Guide" autorstwa Grady'ego Boocha, Jamesa Rumbaugha i Ivara Jacobsona (Addison-Wesley, 1998) mówi nam, że "możesz wykonać 80% modelowania za pomocą 20% UML" gdzieś po stronie 400. Zaoszczędziliby branży wiele milionów (miliardów?) dolarów i przerażających przypadków paraliżu analitycznego [?], gdyby powiedzieli to we Wstępie, ale tego nie zrobili. Aby spotęgować przestępstwo, nigdy nie mówią nam, które 20% UML jest użyteczną częścią". Diagramy UML i sposób ich użycia, od samego początku istnienia tej notacji, budzą emocje i fale sprzecznych komentarzy. Powodem jest wysoki poziom abstrakcji etapu…

Czytaj dalejDiagramy w notacji UML

Organizacja jako mechanizm czyli słoń w pokoju

The era of "sacred cows" of engineering is slowly coming to an end. Software engineering, after almost 20 years of an "agile" approach to this branch of engineering, is beginning to mature into "real engineering" with analysis, design and testing on the "drawing board" of CASE systems and MBSE approaches, which are a universal systems approach to multidisciplinary engineering (mechatronics) (Rosenberg, 2023).Organizations are also systems and their engineering: we have business process engineering, resource engineering, financial engineering. Organizations are systems and should be treated and modeled as such (Kozminski, 1979). IT systems maintenance and development costs are already more than 8% of a company's revenue, and this value is slowly but steadily growing. The discipline of their creation, implementation and management of their costs is also growing.

Czytaj dalejOrganizacja jako mechanizm czyli słoń w pokoju
Read more about the article Modelowanie systemów – organizacja jako mechanizm
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: The systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Modelowanie systemów – organizacja jako mechanizm

Wprowadzenie Pojęcie 'system' stało się bardzo popularne, głównie za sprawą "systemów informatycznych", jednak jego rodowód jest starszy i pochodzi nie od technologii a od biologii . Poza IT mamy systemy bezpieczeństwa, system ubezpieczeń, system emerytalny, system prawa, i wiele innych. Słownik języka polskiego podaje taką definicję pojęcia system: układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość zespół wielu urządzeń, dróg, przewodów itp., funkcjonujących jako całość narządy lub inne części żywego organizmu pełniące razem określoną funkcję uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię określony sposób wykonywania jakiejś czynności lub…

Czytaj dalejModelowanie systemów – organizacja jako mechanizm

Diagram Przypadków Użycia UML – aktor jako persona

Wstęp W niedawno napisanym artykule na temat przypadków użycia i ich definicji zgodnej z UML, wskazywałem między innymi, że: Przypadki uży­cia są spo­so­bem na uchwy­ce­nie [wska­za­nie] wyma­gań sta­wia­nych sys­te­mom, tzn. tego, co sys­te­my mają robić [powo­dy, dla któ­rych one powsta­ną, co będą reali­zo­wa­ły] na rzecz i na żąda­nie Aktora. źr.: Diagram Przypadków Użycia UML - Jarosław Żeliński IT-Consulting Sama specyfikacja UML o aktorze, jako elemencie wokół systemu, mówi bardzo niewiele, poza rozdziałem dotyczącym przypadków użycia: Przypadki użycia są sposobem na uchwycenie wymagań systemów, czyli tego, co systemy mają robić. Kluczowymi pojęciami…

Czytaj dalejDiagram Przypadków Użycia UML – aktor jako persona
Model systemu służy do określenia składników systemu.
Friedenthal, S., Moore, A., & Steiner, R. (2015). A practical guide to SysML: the systems modeling language (Third edition). Elsevier, MK, Morgan Kaufmann is an imprint of Elsevier. https://www.sciencedirect.com/book/9780128002025/a-practical-guide-to-sysml

Modelowanie produkcji

Nie używamy notacji BPMN do modelowania tego co się dzieje na produkcji. Skoro nie BPMN to czego używamy? Wprowadzenie Analityczne modele BPMN to łańcuchy aktywności reprezentujących procedury oraz ich produkty czyli dokumenty (dane). Na tych modelach aktywność to abstrakcja reprezentująca (całą) pracę, której efekt (wynik) jest prezentowany jako treść (DataObject), czyli aktywność kopania rowu kończy się pisemnych stwierdzeniem, że rów wykopano, z ewentualnym opisem parametrów tego rowu (patrz specyfikacja BPMN i definicja atomowej aktywności w procesach ). A gdzie dokładny opis machania łopatą albo obsługi koparki? Ten opis to procedura,…

Czytaj dalejModelowanie produkcji

Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Wprowadzenie Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to "coś nowego", ale być może mają jakieś rady dla projektantów. Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem…

Czytaj dalejInterface-Oriented Design czyli architektura systemu zorientowana na interfejsy

Notacja EPC

Wprowadzenie Notacja EPC (Event-driven Process Chain) została opracowana w 1992 roku w ramach projektu badawczo-rozwojowego z udziałem SAP AG na University of Saarland w Niemczech, a jej twórcą jest dr August-Wilhelm Scheer. Stanowi ona kluczowy element koncepcji modelowania SAP R/3 w zakresie inżynierii biznesowej i dostosowania tego systemu do potrzeb klienta, została włączona także do systemu NetWeaver firmy SAP. Ostatni duży projekt z jej użyciem realizowałem w 2008 roku dla polskiego oddziału niemieckiego banku WestLB Bank Polska SA. Później już jedynie okazjonalne wsparcie merytoryczne i audyty, nadal się zdarzają. EPC…

Czytaj dalejNotacja EPC

Koniec treści

Nie ma więcej stron do załadowania