Zapraszam wszystkich, którzy szukają pomocy, wiedzy oraz wsparcia w swoich projektach informatyzacji. Działam od 1991 roku, mój Blog działa nieprzerwanie od 1998 roku.
Inżynier systemów biznesowych i projektant oprogramowania. Jestem pomostem między biznesem a deweloperem.
Wprowadzenie Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas...). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako "zbioru możliwych kliknięć" co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji ? podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją…
Często spotykam się z różnymi metodami uwzględniania prawa w dokumentacji wymagań. Jakim wymaganiem jest zgodność z obowiązującym prawem? I trudniejsze pytanie: czy zmiana prawa to zmiana wymagań? Inny aspekt problemu to analiza i definicja (opis) tej zgodności z prawem. Spotkać można się z metodą polegającą na traktowaniu każdego (mającego wpływ na system) paragrafu np. ustawy jako wymagania. Problem zgodności oprogramowania z prawem ma dwa aspekty. Zgodność oprogramowania z prawem polega na tym, że ??oprogramowanie nie może ograniczać stosowania prawa to jest nie może wymuszać swoimi ograniczeniami działań niezgodnych z prawem?. Ja osobiście rekomenduję rozciągnięcie tej definicji na ??ani nie powinno pozwalać na łamanie prawa?. Tu jednak wielu uważa, że ??zamawiam narzędzie i używam jak chcę, na swoja odpowiedzialność?. Coś w tym jest, warto jednak zostawić ??włącznik?. (źr.: Prawo a wymagania … )
Dzisiaj czytam:
To administrator odpowiada za zabezpieczenia systemów, a więc także za to, że pracownik zdołał skopiować dane osobowe na zewnętrzny nośnik. […] W ocenie WSA w toku postępowania PUODO prawidłowo ustalił, iż w SGGW dopuszczono się licznych uchybień, w szczególności nie przeprowadzono właściwej analizy ryzyka i oceny zagrożeń już na etapie projektowania systemów (privacy by design) oraz nie wdrożono odpowiednich środków zapewniających bezpieczeństwo danych, w tym przed możliwością wyeksportowania danych z systemu na zewnątrz.(źr.: Odpowiedzialność administratora za naruszenie zasady privacy by design)
Rzecz w tym, że administrator, w rozumieniu prawa, to także podmiot zlecający powstanie oprogramowania, które go wspiera w realizacji jego obowiązków, a jednym z tych obowiązków jest egzekwowanie ustalonych zasad. Dzisiaj o tym, że zbieranie “podpisów pod oświadczeniami” to nie jest bezpieczeństwo.
W artykule o aplikacjach webowych, ponad rok temu, pisałem:
Generalnie kluczową cechą micro-serwisów, czyniącą z nich tak zwaną zwinną architekturę, jest całkowita wzajemna niezależność implementacji poszczególnych usług aplikacyjnych. (źr.: Aplikacje webowe i mikroserwisy czyli architektura systemów webowych).
Przy innej okazji pisałem o wzorcach:
Wzorce projektowe to bardzo ważna część ??zawodu? analityka i architekta oprogramowania. […] Generalnie wzorce są to skatalogowane standardy i dobre praktyki . (Obiektowe wzorce projektowe )
Szkolenia dla analityków poprzedzam ankietami przed szkoleniowymi, jak do tej pory żadna nie zawierała pytań o wzorce projektowe: ani tego że są używane ani tego, że są celem szkolenia, niemalże każdy deklaruje albo, że używa UML lub, że chce zacząć używać UML, nawet gdy są to programiści. Zauważyłem, że wzorce projektowe w świadomości analizy biznesowej i projektowania (OOAD) “nie istnieją”. Wśród programistów, jeżeli jest spotykana, to wiedza o wzorcach przydatnych w tworzeniu bibliotek i narzędzi, często też powielane są wyuczone stare i złe praktyki programistyczne rodem z lat 60-tych (np. praktyki SmallTalk, patrz dalej).
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).
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.
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…
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…
Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego. Nieco ponad pięć lat temu w artykule Diagram obiektów czyli bottom-up pisałem o pojęciu instancji obiektu i diagramie obiektów. Wtedy skupiłem się na jednym tylko wątku, jakim jest analiza zmierzająca do opracowania ... no właśnie, czego? Z reguły autorzy dokumentów zawierających "diagramy klas" mówią, że tworzą modele. Czy zawsze są to modele? Wprowadzenie Jednym z bardzo niedocenianych typów diagramów UML są diagram obiektów i diagram wdrożenia (który jest rodzajem diagramu…
(źr. Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978-3-319-39417-6, str. 405)
Wprowadzenie Ostatnio pojawiła się w prasie i mediach internetowych dyskusja na temat tego czym jest faktura, niestety bardzo wiele z tych opinii jest pozbawiona podstaw merytorycznych i prawnych, są niejednokrotnie po prostu nieprawdziwe. Biorąc pod uwagę fakt, że wiele tych opinii to opinie wygłaszane przez przedsiębiorców, wyłania się smutny obraz jakości informacji zbieranej metodą wywiadów w toku analiz biznesowych. Studiowanie literatury, cudzych opracowań w roli audytora, analiza pytań i uwag moich klientów to ogromne doświadczenie. Rok temu w artykule Mit o notacji BPMN pisałem o szkodliwości nadmiaru szczegółów na modelach. To…
Wstęp Powodem napisania tego artykułu była publikacja: "Wdrożenie zintegrowanych elektronicznych usług, informacyjnych na przykładzie poradników przedsiębiorcy, udostępnianych poprzez Punkt Kontaktowy w Polsce". Autorzy Mgr Szymon Mamrot, doktorant na Wydziale Informatyki i Gospodarki Elektronicznej Uniwersytetu Ekonomicznego w Poznaniu, główny specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e-mail: szymon.mamrot@ilim.poznan.pl). Mgr Magdalena Stachowicz, absolwentka studiów doktoranckich na Wydziale Politologii Uniwersytetu Marii Curie-Skłodowskiej w Lublinie, starszy specjalista w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e-mail: magdalena.stachowicz@ilim.poznan.pl). Artykuł był recenzowany. Autorzy cytują między innymi mój artykuł, a konkretnie definicję procesu biznesowego, piszą także o modelowaniu…
Architektura reprezentuje ważną decyzję projektową, która wpływa na kształt systemu, przy czym waga decyzji mierzona jest kosztami zmian, które wprowadza. — Grady Booch Jeśli myślisz, że dobra architektura jest droga, spróbuj złej Foote, B., & Yoder, J. (2003). Big Ball of Mud . https://www.researchgate.net/publication/2938621_Big_Ball_of_Mud Wprowadzenie Tym razem troszkę cięższy kaliber, czyli dywagacje o tym co powszechnie jest określane jako metody obiektowe i o tym skąd "konflikty i nieporozumienia" między programistami i analitykami projektantami.?*? Literatura przedmiotu zawiera wiele różnych sposobów grupowania metod programowania w paradygmaty. Autorzy z reguły skupiają się na tym, czym są…
W dwóch ubiegłorocznych artykułach pisałem o modelach pojęciowych oraz o związkach w UML. Opisałem je od strony notacyjnej. Dzisiaj o ich zastosowaniu. Generalnie zagadnienia modeli pojęciowych, abstrakcji i metamodeli oraz związków między nimi są dość trudne (wbrew pozorom, większość ludzi ma problem z abstrakcyjnym myśleniem), jako narzędzia są bardzo przydatne w analizie i projektowaniu. Rzecz w tym, że systemy analizowane istnieją, co znaczy ni mniej ni więcej tylko to, że "są dobre bo są i działają". Gorzej jest gdy system, nie raz nietrywialny, jest na etapie projektowania. Wtedy o tym jest "dobry"…
O notacji tej mówi się od kilku już lat. Początkowo spotkać można było opinie, że będzie częścią BPMN, a także że będzie jej konkurencją itp.. Pojawiały się nawet tezy (wróżby lub groźby ;) ), że będzie to dobre narzędzie do "rozrysowywania" złożonych przepływów w procesach (nadzieja dla zwolenników algorytmizacji firm...). Jednak nie. Walka z "kilerem" projektów, jakim jest "utrata panowania nad złożonością diagramów", z tworzeniem monstrualnych diagramów ocierających się o próby algorytmizowania organizacji trwa. Niedawno napisałem: Modele analityczne, jak sama nazwa wskazuje, to modele których celem jest stworzenie abstrakcji,…