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.
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.
Lawinowo pojawiają się pomysły prawnego regulowania AI, a nawet upodmiotowienia AI (patrz: Sztuczna inteligencja jest sztuczna, co jest już moim zdaniem kuriozalne). Ale po kolei. Prawo autorskie W ustawie z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych czytamy: Przedmiot prawa autorskiego Art. 1. 1. Przedmiotem prawa autorskiego jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (utwór). 2. W szczególności przedmiotem prawa autorskiego są utwory: 1) wyrażone słowem, symbolami matematycznymi, znakami graficznymi (literackie, publicystyczne, naukowe, kartograficzne…
Wprowadzenie W roku 2017 komentowałem dokument, który Ministerstwo Cyfryzacji opublikowało (Opublikowano: 22.11.2017), zatytułowany "Wzorcowe klauzule w umowach IT". Czytam tam między innymi: Klauzule zostały opracowane na zlecenie Ministra Cyfryzacji przez zespół kancelarii MARUTA WACHTA Sp. j. pod kierownictwem mec. Marcina Maruty i mec. Bartłomieja Wachty. Wykorzystano w nich również uwagi pracowników administracji publicznej, zarówno prawników, jak i specjalistów z dziedziny IT. (źr. https://www.gov.pl/cyfryzacja/wzorcowe-klauzule-w-umowach-it) Moje uwagi umieściłem we wpisie: Wzorcowe klauzule w umowach IT. Gorąco polecam przeczytanie, opisałem tam kwestie słownika w Umowie, który jest kluczem dla brzmienia Umowy i jej późniejszej interpretacji. Te klauzule nadal są oficjalne…
Ten artykuł to zanonimizowana korespondencja, na często pojawiający sie temat: zakres pracy analityka. O co chodzi Dzień dobry, piszę z prośbą/pytaniem czy byłby Pan w stanie polecić książkę albo inny zasób z ćwiczeniami UML oraz BPMN? Jest z tym problem bo jest mało literatury i często są to płatne publikacje naukowe. Powód jest dość prozaiczny: 1. komercyjne projektty są chronione tajemnica przedsiębiorstwa, 2. napisanie takich ćwiczeń i przykładów jest pracochłonne i mało kto to robi. Mogę polecić swoją książkę i mojego bloga ;), na blogu pod wpisami zawsze podaje wykorzystaną…
Wprowadzenie Niedawno miała miejsce kolejna moja dyskusja na LinkedIn, która pokazała że prawo własności intelektualnej jest bardzo trudne do przyswojenia, głównie dlatego że – z uwagi na swoją „niematerialność” – wymyka się intuicyjnej i materialnej manierze postrzegania świata przez człowieka. Na to nakłada się przeświadczenie koderów, że z zasady są samodzielnymi twórcami, i niestety wielu prawników także tak uważa. Rzecz w tym, że koder zawsze jest twórcą, ale nie zawsze jest projektantem. Gdy koder nie jest projektantem, jego utwory (kod źródłowy) to utwory zależne od utworów pierwotnych, jakimi są projekty techniczne wyrażone np. z pomocą…
Dług informacyjny jest znacznie groźniejszy niż dług technologiczny. Same zaległości technologiczne jako takie można usunąć bez dużego ryzyka: jest to po prostu upgrade już posiadanej infrastruktury. Dług informacyjny jest znacznie bardziej niebezpieczny, bo to całkowity brak wiedzy o tym jak to zrobić bezpiecznie i co w ogóle zrobić (upgrade czy jednak wymiana systemu na nowy inny).Dług informacyjny to nie tylko nieudokumentowany system. To nieudokumentowane procesy biznesowe, procedury, reguły biznesowe, to zasoby wiedzy o organizacji jedynie w „głowach pracowników”, te zaś są najczęściej niespójne, niekompletne i bardzo często sprzeczne.
Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu kończyłem słowami:
Tak więc wymagań biznesowych może być kilkadziesiąt. Wymaganych usług systemu (przypadków użycia) w dużym projekcie także może być kilkadziesiąt. Ale setki, czy tysiące ??wymagań? to wyraz utraty panowania nad zakresem projektu? Tu zwrócę uwagę, że wymaganiem (usługa systemu) może być np. wytworzona faktura VAT zgodna z przepisami. Cechy tej faktury (lista pól) to nie osobne wymagania, to cechy (parametry, atrybuty) jednego wymagania. Żadna cecha faktury VAT nie ma sama w pojedynkę żadnej wartości, nie może więc być oddzielnym przypadkiem użycia, tak samo jak wymaganiem naszym może być samochód, ale jego kolor czy automatyczna skrzynia biegów, to cechy samochodu, nie ma sensu wymagać ??czerwonego koloru? nie oczekując samochodu (i jak uzasadnić, to że ten kolor wspiera cel biznesowy). Przypadkiem użycia samochodu jest podróż a nie włożenie kluczyka do stacyjki, bo to jest tylko jeden z elementów scenariusza rozpoczęcia podróży samochodem.
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.
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…
"Jeśli myślisz, że dobra architektura jest droga, spróbuj złej" Wstęp W roku 2008 pisałem (Forbs): W wielu firmach decyzja o wdrożeniu systemu informatycznego bardzo często nie jest poprzedzona żadnymi przygotowaniami w rodzaju oceny struktury organizacji, jej zdolności do zmian czy też uporządkowaniem obiegu informacji. Częstym grzechem jest próba ?wtłoczenia? w system informatyczny ?starego? porządku. Drugi grzech to brak opisanego systemu informacyjnego. W efekcie następuje zderzenie rygorów papierowego obiegu informacji z obiegiem danych w systemie informatycznym. Rezygnacja z wielu czynności (np. stawianie pieczątek i podpisów) lub zamiany ich na inne staje się kluczowym, bronionym jak niepodległości przez wielu kierowników…
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…
Wprowadzenie Skrót VSM zaczyna się od pewnego czasu pojawiać także w inżynierii oprogramowania, ma on jednak stary, ponad 30-letni rodowód. Mapowanie strumienia wartości (ang. Value-stream Mapping, VSM), znane od 30 lat, ostatnio także jako mapowanie przepływu materiałów i informacji (ang. material- and information-flow mapping). Jest to metoda mająca swoje początki w Lean Management, służąca do analizy stanu obecnego i projektowania stanu przyszłego dla serii zdarzeń, które prowadzą produkt lub usługę od zamówienia do momentu dostarczenia klientowi. Mapa strumienia wartości to graficzne podejście, które pokazuje wszystkie krytyczne kroki w określonym procesie…
O user story pisałem nie raz od ponad dekady, i w zasadzie zawsze powodem jest to samo: kolejny ratowany projekt, gdzie powodem dramatu było stosowanie user story jako wymagań. Kiedy user story jest stosowane jako wymaganie? W zasadzie zawsze tam, gdzie pominięto etap analizy i projektowania. Jakie są skutki? Kilkukrotnie wyższa pracochłonność, czyli znacznie wyższe koszty i dłuższy termin dostarczenia oprogramowania. Niestety, nie raz, tak realizowane projekty kończą się wstrzymaniem prac zanim powstanie pełna funkcjonalność aplikacji, z powodu znacznego przekroczenia budżetu i terminu.
Co proponuję? To co proponuję wielu doświadczonych praktyków na świecie:
Technical Description of Software, as documentation of the mechanism of its operation, requires precision because it constitutes documentation of know-how (it can also be part of patent documentation). Such documentation cannot be source code of a specific (one of many on the market) programming language, as it must be a "dry" description of the mechanism of operation, and not an example of one of many possible implementations. This is also pointed out by the author of the above-mentioned book. Therefore, the documentation of the system, it is not its example implementation ("working code"), it is the essence of its operation expressed as an abstract model.