Prawo autorskie a produkty AI

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…

Czytaj dalejPrawo autorskie a produkty AI

Przed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

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…

Czytaj dalejPrzed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników

Analityk czyli kto?

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ą…

Czytaj dalejAnalityk czyli kto?

Utwór vs. projekt a własność intelektualna w inżynierii

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ą…

Czytaj dalejUtwór vs. projekt a własność intelektualna w inżynierii

Czym jest dług informacyjny

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.

Czytaj dalejCzym jest dług informacyjny

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

Wstęp

Siedem lat temu (2015) arty­kuł o wyma­ga­niach i śla­do­wa­niu 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 śla­do­wa­nie wyma­gań jest istot­ne w pro­jek­cie? – Jarosław Żeliński IT-Consulting

Nadal poja­wia­ją się publi­ka­cje o wyma­ga­niach, zarzą­dza­niu nimi i reali­zo­wa­niu ich. Na ryn­ku są dostęp­ne apli­ka­cje pozwa­la­ją­ce je kolek­cjo­no­wać i zarzą­dzać taką kolek­cją. I sta­le mamy do czy­nie­nia z ich – wyma­gań – nie­jed­no­znacz­no­ścią . Okazuje się, że ich zna­cze­nie sta­je sie klu­czo­we dla pro­jek­tów, tak­że z per­spek­ty­wy pra­wa (PZP i zde­fi­nio­wa­ne w zale­ce­niach UZP poję­cie potrze­ba). Tym razem sku­pię się na poję­ciach «wyma­ga­nie» i «potrze­ba» w odnie­sie­niu do pro­jek­tu 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

Architektura informacji, system informacyjny a system informatyczny w organizacji

"Jeśli myślisz, że dobra architektura jest droga, spróbuj złej" Wstęp W roku 2008 pisałem (Forbs): W wie­lu fir­mach decy­zja o wdro­że­niu sys­te­mu infor­ma­tycz­ne­go bar­dzo czę­sto nie jest poprze­dzo­na żad­ny­mi przy­go­to­wa­nia­mi w rodza­ju oce­ny struk­tu­ry orga­ni­za­cji, jej zdol­no­ści do zmian czy też upo­rząd­ko­wa­niem obie­gu infor­ma­cji. Częstym grze­chem jest pró­ba ?wtło­cze­nia? w sys­tem infor­ma­tycz­ny ?sta­re­go? porząd­ku. Drugi grzech to brak opi­sa­ne­go sys­te­mu infor­ma­cyj­ne­go. W efek­cie nastę­pu­je zde­rze­nie rygo­rów papie­ro­we­go obie­gu infor­ma­cji z obie­giem danych w sys­te­mie infor­ma­tycz­nym. Rezygnacja z wie­lu czyn­no­ści (np. sta­wia­nie pie­czą­tek i pod­pi­sów) lub zamia­ny ich na inne sta­je się klu­czo­wym, bro­nio­nym jak nie­pod­le­gło­ści przez wie­lu kie­row­ni­ków…

Czytaj dalejArchitektura informacji, system informacyjny a system informatyczny w organizacji

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

Value-stream mapping czyli strumień wartości jaki wytwarza firma tworząc swój produkt

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…

Czytaj dalejValue-stream mapping czyli strumień wartości jaki wytwarza firma tworząc swój produkt

Czym są testy oraz kto i co testuje

Robię to zawsze a najrzadziej o tym pisze, bo to "takie oczywiste", a co to takiego? TESTY. Dobrze opracowane testy to ciekawa i wyrafinowana forma sprawdzania tego czy dostajemy to co chcemy dostać, to za co płacimy (nie raz słono). Czym są (powinny być) kryteria akceptacji? To właśnie wymagania, pozostaje pytanie: Które? Jeżeli to będą pierwotne wymagania biznesowe jest źle (patrz: Przypadki użycia to nie wymagania). Wiec co? Wymaganiem jest model: zamawiana konstrukcja, mechanizm działania. V-model czyli wprowadzenie Ogólnym, najczęściej przytaczanym modelem opisującym cykl wytwarzania w inżynierii jest tak zwany…

Czytaj dalejCzym są testy oraz kto i co testuje

User Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

O user sto­ry pisa­łem nie raz od ponad deka­dy, i w zasa­dzie zawsze powo­dem jest to samo: kolej­ny rato­wa­ny pro­jekt, gdzie powo­dem dra­ma­tu było sto­so­wa­nie user sto­ry jako wyma­gań. Kiedy user sto­ry jest sto­so­wa­ne jako wyma­ga­nie? W zasa­dzie zawsze tam, gdzie pomi­nię­to etap ana­li­zy i pro­jek­to­wa­nia. Jakie są skut­ki? Kilkukrotnie wyż­sza pra­co­chłon­ność, czy­li znacz­nie wyż­sze kosz­ty i dłuż­szy ter­min dostar­cze­nia opro­gra­mo­wa­nia. Niestety, nie raz, tak reali­zo­wa­ne pro­jek­ty koń­czą się wstrzy­ma­niem prac zanim powsta­nie peł­na funk­cjo­nal­ność apli­ka­cji, z powo­du znacz­ne­go prze­kro­cze­nia budże­tu i ter­mi­nu. Co jest przyczyną?

(wię­cej…)

Czytaj dalejUser Story to wymaganie biznesowe, to opis problemu do rozwiązania, a nie funkcjonalność do implementacji!

Koniec treści

Nie ma więcej stron do załadowania