Wprowadzenie Najczęściej w toku analiz posługujemy się pojęciem model, rzadziej mechanizm. Rzecz w tym, że pojęcie mechanizm pojawia się gdy chcemy coś wyjaśnić, np. "mechanizm generowania upustu na fakturze". Ale tu uwaga! Model (schematy blokowe, wzory itp.) to dokumentacja, opis chroniony prawem autorskim. Mechanizm to to, co zrozumieliśmy czytając te dokumentację (model), bo mechanizm to chronione know-how. Treść wniosku do Urzędu Patentowego to model (opis), ale to co patentujemy to wymyślony/opracowany mechanizm. Mechanizm a model Mechanizm i model w nauce to bliskie sobie pojęcia, np. tak opisywane: Modelowanie polega na…
Wprowadzenie Bardzo często na szkoleniach, a także na zajęciach laboratoryjnych z przedmiotu Inżynieria oprogramowania, jestem pytany o przypadki użycia i ich scenariusze. Szczególnie często pada pytanie czy przypadek użycie reprezentuje tylko jeden scenariusz. Przypadki użycia w UML to "dzieło" Ivara Jacobsona . Pierwotnie było to narzędzie do opisu zewnętrznych cech (zachowań) systemu, rozumianych jako jego oczekiwane zachowania, czyli wymagania wobec systemu. Był to tak zwany "opis czarnej skrzynki". Problemem było to, że "czarna skrzynka" mówi CO ale nie mówi JAK. Jacobson opisywał przypadki użycia z pomocą warunków (stanów początkowego i…
Wprowadzenie Wzorzec ten budzi wiele kontrowersji co do tego czym są te trzy komponenty. Popatrzmy do anglojęzycznej WIKI: Model - Centralny komponent wzorca. Jest to dynamiczna struktura danych aplikacji, niezależna od interfejsu użytkownika. Bezpośrednio zarządza danymi, logiką i regułami aplikacji. W Smalltalk-80, model jest całkowicie pozostawiony programiście. W WebObjects, Rails i Django, model zazwyczaj reprezentuje tabelę w bazie danych aplikacji. https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Jest to dominująca definicja w literaturze, zaś spory o to czym jest Model w architekturze MVC jak widać mają jedno główne źródło: jakiego frameworka używa osoba wchodząca w takie…
Jaroslaw Zelinski. Stajnia Augiasza w wersji digital. Biuletyn Konsultant 2024, 1 (70), 38–42. Wydanie PDF do pobrania: bk70_01_2024Pobierz
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.
Wstęp
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.
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…)
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…