Wprowadzenie

Ukazała się książka Prawo w IT. Praktycznie i po ludzku [zotpressInText item=”{5085975:SDYYERHD}”]. Jako, że profesjonalnie zajmuję się tak zwanym IT, a z prawem dotyczącym IT mam ogromne doświadczenia jako biegły (ale prawnikiem nie jestem), ta książka od razu po wydaniu wylądowała się na moim biurku. Jak tylko zacząłem czytać zapadła decyzja: napisze recenzję. Czytam bardzo dużo, ale recenzuję (tu na blogu) książki bardzo dobre lub bardzo szkodliwe.

Autor książki, Szymon Ciach (profil LinkedIn: “Attorney-at-law | Counsel @Osborne Clarke Poland | IT & Data”.), profil na Cybergov.pl:

Patron medialny książki ITwiz.

Szymon Ciach
Counsel, Kancelaria Osborne Clarke Poland
Prawnik specjalizujący się w obszarze technologii oraz regulacji rynku finansowego. Posiada szerokie doświadczenie w przygotowywaniu i negocjowaniu umów IT (m.in. umowy wdrożeniowe, utrzymania i rozwoju systemów informatycznych, outsourcingu IT), zarówno na rzecz zamawiających, jak i dostawców. Jest ekspertem w zakresie wdrażania usług chmury obliczeniowej oraz outsourcingu IT w sektorze finansowym. Współtworzył standard wdrażania chmury obliczeniowej w bankowości “PolishCloud 2.0”, w roli Koordynatora Grupy Prawnej przy Związku Banków Polskich. Doradza również w budowie nowych modeli biznesowych na styku finansów i technologii (FinTech), w szczególności w zakresie wykorzystania technologii rozproszonego rejestru (DLT, blockchain). Absolwent WPiA Uniwersytetu Jagiellońskiego, członek Okręgowej Izby Radców Prawnych w Warszawie. Rekomendowany prawnik w sektorze TMT w Polsce (Legal 500 EMEA 2023). (https://cybergov.pl/prelegenci/szymon-ciach/)

Kluczowe pojęcia

W rozważaniach o znaczeniach pojęć od wielu lat kluczem jest tak zwany trójkąt semiotyczny, nazywany także trójkątem Ullmanna [zotpressInText item=”{5085975:RSU5DBMZ},{5085975:ZAV7CQ6P}”]. Poniżej wersja tego trójkąta opisana w publikacji Towards a model for grounding semantic composition [zotpressInText item=”{5085975:ESXILXF4}”].

Mamy tu pojęcia Concept (ang. pojęcie, myśl, abstrakcja), Symbol (ang. symbol, znak, reprezentacja, litera oraz słowo z nich zbudowane), Thing (ang. określony przedmiot, sprawa, zdarzenie, coś a także coś do zrobienia) [zotpressInText item=”{5085975:D7RVPITQ}”].

Odnosząc się do pojęć z dziedziny information science (pojęcia informatyka czy technologie informatyczne odnoszą się nieprecyzyjnie do tego co literatura naukowa nazywa w j. ang. information science oraz information technology).

Owszem, Słownik Języka Polskiego (SJP) podaje:

informatyka: «nauka o tworzeniu i wykorzystywaniu systemów komputerowych»

informacja 1. «to, co powiedziano lub napisano o kimś lub o czymś, także zakomunikowanie czegoś», 2. «dział informacyjny urzędu, instytucji», 3. «dane przetwarzane przez komputer»

dane 1. «fakty, liczby, na których można się oprzeć w wywodach» 2. «informacje przetwarzane przez komputer»

Tak więc mamy jednak rozróżnienie, które wielu autorów dostrzega [zotpressInText item=”{5085975:S7UN3N7Y}”].

Trójkąt semiotyczny, w odniesieniu do omawianych terminów, można więc przedstawić tak:

Model pojęciowy omawianej dziedziny:

Model pojęciowy (ontologia) to model pozwalający zbudować i przetestować system pojęciowy. Cechą poprawnego modelu jest wzajemne wykluczanie się definicji pojęć oraz istnienie typów czyli specjalizacji. Definicja pojęcia to klasyfikator a rzeczy, które spełniają tę definicje to zbiór (taki jak w matematyce) [zotpressInText item=”{5085975:7FREZB72}”]. Poprawny dziedzinowy model pojęciowy (przestrzeń nazw) na diagramie Venna [zotpressInText item=”{5085975:A4TSJUQC},{5085975:XTN432ZI}”] byłby modelem, w którym zbiory obiektów (things) są styczne i żadna granica zbioru nie przecina innej. Inną wersją testu poprawności jest prawo wyłączonego środka: “jeżeli coś jest czymś, to nie jest niczym innym” [zotpressInText item=”{5085975:6LD24N2L}”]. Specjalizacja (typ) to podzbiór:

Definicje pojęć z powyższego modelu:

Na tym tle pojęcie technologie informatyczne mają sens, pojęcie technologie informacyjne w zestawieniu z tym, że informacja to jest to co zrozumiał człowiek, dotyczy wyłącznie procesów myślowych, czyli np. procesów wnioskowania czy “liczenia w pamięci”. Potocznie możemy sobie pozwalać na utożsamianie pojęć dane i informacje, ale w opracowaniach eksperckich, czy wręcz naukowych, już nie [zotpressInText item=”{5085975:S7UN3N7Y}”].

Autor pisze, że (str. 22)

“dane reprezentują fakty i same w sobie nie mają znaczenia. Natomiast informacje to dane, które przez interpretacje odbiorcy nabierają znaczenia…”.

Niestety takie podstawienie sprawy jest nielogiczne i pozbawione sensu. Ullmann i Eco [zotpressInText item=”{5085975:RSU5DBMZ},{5085975:ZAV7CQ6P}”] jasno wykazują (trójkąt semiotyczny): dane to utrwalone znakami zapisy, a informacja to jest to co człowiek zrozumiał poznając je. Tak więc fakty (opis tego co zaszło) to informacja dla człowieka i dane jako utrwalone znaki i symbole. Zwracam uwagę, że encyklopedia w języku chińskim to na pewno dane, jednak niosą one informacje wyłącznie dla ludzi znających język chiński.

Jeżeli, jak pisze autor (str. 23), w kontekście prawnym pojęcia dane i informacje są używane jako synonimy to jest kardynalny błąd tych, którzy to czynią. Co ciekawe w następnym akapicie sam autor pisze, że konieczne jest “odróżnienie informacji od danych”.

Autor wplata znienacka pojęcie przepływu danych, ale nie wyjaśnia co ma to pojęcie wspólnego z danymi, ich ochroną i przetwarzaniem. Fakt zbierania danych osobowych nie jest przepływem danych, a co najwyżej ich utrwalaniem: ktoś informacje o sobie zapisuje (utrwala) w określonym formularzu na papierze lub ekranie komputera. Dostęp (człowieka) do danych to także nie jest przepływ danych. O przepływie danych możemy mówić wyłącznie wtedy, gdy są kopiowane z jednego nośnika na innych nośnik. I nie należy tego mylić ani utożsamiać z przepływem informacji (patrz encyklopedia w języku chińskim).

Stos technologiczny

Ten aspekt systemu informatycznego opisałem w artykule Sprzęt, środowisko, aplikacja, mechanizm. Tu zwrócę jedynie uwagę na kluczowe elementy. Autor prezentuje taką tabelę:

Autor definiuje “stos technologiczny” jako

sposób na opisanie opisanie zestawu technologii i narzędzi informatycznych mających jakiś wspólny mianownik

Autor nie podaje źródła tej kuriozalnej definicji. Najczęściej spotykaną definicją jest (trudno wskazać autora, Google pokazuje dziesiątki stron na to hasło):

stos technologiczny to zestaw elementów budujących stronę internetową lub aplikację. Są to język programowania, frameworki, systemy baz danych, biblioteki front-end i back-end oraz aplikacje połączone za pośrednictwem interfejsów API.

Po pierwsze stos technologiczny to nie aplikacja, ale ona oraz jej środowisko. Generalnie ten stos to sprzęt, sterowniki i szeroko pojęte oprogramowanie:

Jednak na użytek ochrony wartości intelektualnych w postaci oprogramowania (“Software”) dzielimy je (oprogramowanie) na odrębne aplikacje (SJP, aplikacja: komputerowy program użytkowy). Dlatego to co nazywamy stosem technologicznym przyjmuje bardziej skomplikowaną postać, bo pokazany tu Software to “frameworki, systemy baz danych, biblioteki front-end i back-end oraz aplikacje połączone za pośrednictwem interfejsów API”, i nie zapominajmy o systemie operacyjnym. O potrzebie separacji kodu aplikacji pisałem też w artykule Kastomizacja…

Duża nieprawda to dane jako osobna warstwa i to że są na szczycie tego stosu, bo jest odwrotnie: dane są na nośnikach a te, to hardware. Po drugie system operacyjny, oraz każda aplikacja, zarządza swoimi danymi niezależnie, więc nie są to “jedne dane”.

Autor stawia tezę, że dane to “podstawowy zasób świata IT” a zapomniał, że to za co płacimy najwięcej to aplikacje (np. system ERP) a nie dane. Po drugie często same dane na nośnikach są niemalże bezwartościowe bez logiki (procedury i algorytmy) ich przetwarzania.

Jak widać, dane są zawsze “na dnie” i NIGDY na szczycie “stosu”. Autor na str. 29 pisze, że pojęcie aplikacja stosuje się zamiennie z pojęciem system informatyczny co jest nieprawdą (patrz wyżej, model pojęciowy i stos technologiczny).

Na stronie 44 autor pisze o “środowisku informatycznym”. Najwyraźniej zapomniał czym jest stos technologiczny: TO jest właśnie to środowisko.

Nie miałem tu ambicji i nie było moim celem punktowanie wszystkich błędów, generalnie moim zdaniem cały rozdział Wprowadzenie to pasmo nieprawdy lub złych uproszczeń. Tytuł tego rozdziału to “Świat IT okiem prawnika”, jeżeli to prawda (tak prawnik rozumie IT) to jest to dowód na to, by prawnicy pozostali przy prawie, a inne informacje pozyskiwali, tak jak Sąd: od biegłych.

Umowy IT

Autor wprowadza pojęcie “Umowy IT” i z jednej strony sam stwierdza, że to umowy których przedmiotem są “technologie informacyjne”, zapominając że sam wskazywał na różnice między systemami informacyjnymi a informatycznymi. Pamiętajmy, że “technologią informacyjną” jest także system znaków drogowych na drogach…

Nie przypadkiem na całym świecie mamy prawo karne i cywilne. Sprzęt komputerowy i oprogramowanie to jedne z wielu możliwych przedmiotów umowy cywilno-prawnej. Pamiętajmy, że prawo autorskie i tajemnica przedsiębiorstwa dotyczy szeroko-pojetej treści. To czy jest nią kod źródłowy czy treść trylogii Władca Pierścieni nie ma żadnego znaczenia. Przedmiot zamówienia to (powinna być) treść załącznika do umowy i nie jest to praca dla prawnika (za wyjątkiem umowy z prawnikiem na usługę prawniczą).

Autor pisze, że programy komputerowe podlegają ochronie jak utwory literackie. Owszem, jeżeli ten kod rozumiemy jako tekst (znaki). Niestety mamy także pojęcie “informacja”, np. o mechanizmie naliczania upustów w programie lojalnościowym, i tu ochronie (tajemnica przedsiębiorstwa) podlega mechanizm naliczania upustu, bez względu na formę jego wyrażenia (o ile jest zrozumiała dla czytelnika), a mogą to być schematy blokowe i wzory matematyczne (patrz artykuł Prawo autorskie i wartości niematerialne – analiza systemowa oraz Ochrona wartości intelektualnych i know-how w organizacji – Poradnik). Ten mechanizm można zaimplementować w dowolnym języku oprogramowania, więc będą to “różne teksty o tym samym”. Co to znaczy? To znaczy, że TREŚĆ zeznania świadka morderstwa, jest tą samą treścią bez względu na to czy została utrwalona (dane) w języku francuskim czy języku Aborygenów.

Autor wprowadza pojęcie “Umowy wdrożeniowej”. Nie mam pojęcia po co, skoro to czy dana praca jest wdrożeniem czegokolwiek czy nie jest, jest skutkiem przedmiotu pracy a nie jej nazwy.

Autor pisze o modelu kaskadowym ale opisał ten model jak za czasów komputerów mainframe z lat 70tych ubiegłego wieku: każdy etap dotyczy całego systemu, co w dobie systemów zintegrowanych i komponentowych po prostu nie jest prawdą (patrz artykuł Integracja systemów ERP jako źródło przewagi rynkowej).

W rozdziale Umowy na inne usługi IT autor napisał (str. 195), że “Umowa na usługi programistyczne to najprostsza prawna forma współpracy w zakresie wytwarzania lub rozwoju oprogramowania”. Jak to przeczytałem, to pomyślałem od razu o prawach autorskich, o których autor pisał wcześniej, o różnych formach wyrażenia oprogramowania, o tym, że mamy licencje i przekazanie praw majątkowych, o tym, że stos technologiczny to aplikacja i biblioteki. Usługi programistyczne, a szczególnie ich produkt, to – patrząc na mediacje i spory w sądach – jedna z najtrudniejszych dziedzin w IT i w prawie. Kastomizacja systemu ERP czy dedykowane oprogramowanie napisane z użyciem określonego języka programowania i jego bibliotek, to labirynt. Gdy czytam jak prawnik pisze, że to “najprostsza umowa” to krew mi zamarza.

Podsumowanie

Opisałem wybrane, “ciekawsze” w moim subiektywnym odczuciu, elementy tej książki. Jednak cała ta książka, poza treściami stricte dotyczącymi prawa (a takich jest tam bardzo mało) spowodowała, że czytając tę książkę czułem się jak bym czytał książkę dobrego aktora piszącego swoje wyobrażenia o stolarstwie, bo “scena to deski”.

Opisanie wszystkich wad tej książki zajęło by wiele czasu i stron tekstu, bo niemalże każdy jej rozdział zawiera treści wymagające skomentowania lub wręcz wadliwe. Dlatego z uwagi na charakter i objętość bloga (staram się czas potrzebny na przeczytanie jednego postu nie przekraczał 20 minut) ograniczyłem się kilku wybranych wad, które w moich czynią tę książkę nieprzydatną dla osoby poznającej branżę, a osoba mająca stosowną wiedzę zareaguje podobnie jak ja: odłoży i nie wróci do niej.

Jako osoba, która widziała niejedno nieszczęście wdrożeniowe, nie tylko jako biegły w sądzie, zawsze będę powtarzał: prawnik, który projektuje systemy IT nigdy, nie będzie odpowiadał za ich nieudane wdrożenia, bo nawet gdy na etapie negocjacji umowy ma coś do powiedzenia, to Sąd nigdy nie powoła prawnika jako biegłego w sporze o przedmiot wdrożenia IT. Szanowni Państwo, pamiętajcie o tym, bo to co ja widzę w umowach i w dokumentach sądowych to na prawdę dramat.

A moja rekomendacja? Cóż, odradzam tę książkę prawnikom, korzystając z niej zrobią krzywdę swoim klientom. Prawnikom polecam raczej  Logika dla prawników [zotpressInText item=”{5085975:KVQS3HXD}”]. Branża IT? To tym bardziej nie jest książka dla Was.

Polecam także artykuł Wzorcowe klauzule w umowach IT oraz Przed Tobą wdrożenie systemu IT czyli Polemika z poradami prawników.

Prawnicy, bądźcie prawnikami i uczcie się od sędziów: do zagadnień z poza prawa powołujcie w swoich projektach biegłych (ekspertów).

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

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 jestem pytany o to jak się zabezpieczyć kupując lub zamawiając oprogramowanie. Wielu prawników zaleca depozyt kodu źródłowego.

Zdjęcie po prawej to przykładowy fragment takiego kodu. Kto zrozumiał?

Często czytam:

Depozyt kodu źródłowego – niezawodny sposób zabezpieczenia systemu IT

https://szolajski.com/depozyt-kodu-zrodlowego-niezawodny-sposob-zabezpieczenia-systemu-it/

albo:

Depozyt kodu źródłowego (ang. software escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania.

https://pbrd.pl/#:~:text=Depozyt%20kodu%20%C5%BAr%C3%B3d%C5%82owego%20(ang.,prawn%C4%85%20i%20techniczn%C4%85%20takiego%20procesu.

albo to samo inna kancelaria (skopiowali treść cudzej strony?) :

Depozyt kodu źródłowego (ang. source code escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Takich ofert kancelarii prawnych jest wiele. Niestety bywa to kosztowne i jest to bardzo złe rozwiązanie, bo w zasadzie przed niczym nie zabezpiecza. Depozyt kodu źródłowego jest jedną najbardziej bezwartościowych metod ochrony. Dlaczego?

1. Są to tysiące lub setki tysięcy linii kodu, nie raz bardzo niskiej jakości, napisanego niechlujnie przez różnych ludzi (rotacja prcowników dewelopera).
2. Bywa że celowo utrzymywana jest jego niska zrozumiałość (by utrudnić innym jego zrozumienie).
3. Wiele aplikacji nadal jest pisanych z użyciem relacyjnych baz danych (setki połączonych tabel) i języka SQL, więc wraz z tym kodem należało by mieć także detalicznie opisaną strukturę tych tabel i zapisane (ich treść) wszystkie zapytania SQL użyte w tym kodzie, a także detaliczny opis środowiska tej bazy danych.

Zrozumienie mechanizmu działania aplikacji tylko na bazie jej kodu źródłowego, struktury tabel baz danych i zapytań SQL do tej bazy, graniczy z cudem i zajmuje nie raz lata. To pomysł na poziomie tezy, że można zrozumieć jak działa samolot rozbierając go na detale. W 2012 napisałem artykuł: Sprzedam Ci prawa do kodu czyli wielka ściema. Niedawno napisałem tekst: Mechanizm działania vs model systemu vs diagram. Tu ich kontynuacja w kontekście tego co należy chronić mówiąc o kodzie źródłowym.

Dlatego jedynym skutecznym sposobem zabezpieczenia się, jest posiadanie archiwum dokumentów, które przetwarzała ta aplikacja oraz dokumentacji opisującej mechanizm (architekturę, algorytmy, procedury) realizacji funkcjonalności tego oprogramowania.

Metoda

Standardowo stosuję idealizację i modelowanie zarówno w pracy naukowej ja i w projektach komercyjnych. Dlatego tu także opiszę model architektury systemu informatycznego, jako idealizację takiej architektury, a potem posługując sie nim, przetestuję ideę depozytu kodu źródłowego.

Czym jest system i po co go mamy czyli co to jest komputer

Jest to kluczowe pytanie na jakie trzeba sobie odpowiedzieć. Popatrzmy:

Kluczowy fakt: my jako ludzie używamy komputera a nie kodu źródłowego. To znaczy, że sam kod źródłowy to nie jest to, czego używamy. Kod źródłowy to fragment “systemu”:

Patrząc na powyższy diagram łatwo zauważyć, że sam kod źródłowy, bez pozostałych elementów, jest w zasadzie bezwartościowy. Co z tego że mamy mityczny kod źródłowy, skoro możemy mieć poważny problem z pozyskaniem pozostałych elementów wymaganych do tego, by nasz Działający Komputer odtworzyć? Czego tak na prawdę używamy używając komputera? Używamy określonego mechanizmu przetwarzania danych. Za Słownikiem Języka Polskiego: mechanizm to sposób, w jaki coś powstaje, przebiega lub działa.

Co więc tak na prawdę należy udokumentować i chronić? Opis mechanizmu działania naszego komputera. Problem w tym, że mając wyłącznie kod źródłowy jesteśmy w trudnej sytuacji bo nadal zrozumienie tego mechanizmu wymaga “inżynierii wstecznej”, jedyna różnica to ta, że materiałem źródłowych jest nie kod maszynowy a kod w określonym języku programowania, co niestety niewiele poprawia sytuację:

Kolejne kluczowe pytanie to: Co jest celem zakupu komputera? Otóż celem jest “to do czego on nam służy” a nie “on sam jako taki”.

Cała nasza działalność, do której używamy komputera, to wprowadzanie danych i uzyskiwany efekt. Bardzo często komputer to także archiwum historii naszych “dokonań” (przy okazji prosze zwrócić uwagę na to, że obecnie nie ma znaczenia gdzie on faktycznie stoi bo liczy się komunikacja).

Co faktycznie należy chronić

Kolejne ważne pytanie: czy produkty naszej pracy, nasz dorobek, który powstał z użyciem tego komputera, jest dla nas dostępny bez Tego komputera? Jeżeli nie, to brak tego komputera nie tylko powoduje, że nie mamy narzędzia pracy, to także przepadek całego dorobku jaki powstał z jego pomocą. Jeżeli ten Komputer przechowuje dane w postaci czytelnej tylko dla kodu Tego oprogramowania, to utrata Tego oprogramowania jest równoznaczna z utratą dotychczasowego dorobku (np. najgorszą formą archiwizowania danych jest relacyjna baza danych i zapytania SQL do niej, sytuacja w jakiej jest większość posiadaczy systemów ERP).

Komputer bez udokumentowanego mechanizmu działania to dla nas wyłącznie “czarna skrzynka”. Wobec tego jak się zabezpieczyć, skoro depozyt kodu to zabezpieczenie fikcyjne? Należy zabezpieczyć:

• nasz dotychczasowy dorobek (stanowiące naszą własność archiwum z dokumentami w uniwersalnym formacie, łatwym do odczytania, np. XML+PDF),
• mechanizm działania (udokumentowany np. w UML).

Poniżej idealna bezpieczna architektura: mamy komputer i mamy archiwum oraz mamy “na boku” udokumentowany mechanizm powstawania (przetwarzania) naszych danych.

Innymi słowy: nie tylko mamy archiwum dokumentów, ale mamy także wiedzę jak one powstawały, i możemy tej wiedzy użyć do zbudowania kolejnego “działającego komputera”, bez względu na to w jakiej technologii zrobimy to kolejnym razem. Poniżej zilustrowano podstawowe zalecane zasady zarzadzania danymi:

Dodam tu, że ochrona know-how to nic innego jak posiadanie ww. udokumentowanego mechanizmu. Kod źródłowy nie daje takiej ochrony.

Czym jest wiedza o produkcie?

Opis produktu powinien przedstawiać (ujawniać) go na tyle jasno i wyczerpująco, aby znawca mógł go urzeczywistnić. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli jest to rozwiązanie, które jest na tyle nowe, że stosowne opisy nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Produkt powinien nadawać się do odtworzenia (na podstawie dokumentacji) bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie produktu, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do wytworzenia produktu według tego opisu. (na podstawie Pyrża, 2006)

Na bazie poprawnie wykonanej dokumentacji technicznej (opis mechanizmu działania, opis produktu) można aplikację odtworzyć wielokrotnie niższym nakładem środków w porównaniu z analizą cudzego kodu źródłowego, którego dalszy rozwój w postaci i technologii w jakiej pierwotnie powstał, nie raz może nie mieć sensu (postęp technologii w IT jest dość szybki).

Dlatego od wielu zalecana architektura systemów ERP to także osobna zintegrowane własne hurtownia danych i archiwum dokumentów jako np. dokumentowa baza danych NoSQL:

Ważna rzecz na koniec tej części:

1. jeżeli oprogramowanie jest dedykowane to właścicielem i posiadaczem praw majątkowych do kodu i wszelkiej jego dokumentacji powinien być jego użytkownik,
2. jeżeli oprogramowanie jest licencjonowane to użytkownik powinien znać mechanizm jego działania,
3. jeżeli ktoś używa oprogramowania, którego dziania nie rozumie, to może to mieć sens tylko w przypadkach gdy użytkownik wymaga wyłącznie efektu i nie musi rozumieć tego jak powstał: np. oprogramowanie OCR czy retusz zdjęć.

Dlatego tak ważne jest posiadanie archiwum “trwałych nośników dokumentów” (Documents na powyższym schemacie):

Za trwały nośnik można uznać m.in. dokument papierowy, kartę pamięci, pendrive, wiadomość mailową lub załączony do niej plik, np. w formacie pdf. Samo hiperłącze przekierowujące na stronę internetową nie spełnia wymogów trwałego nośnika, jeżeli tego rodzaju strona internetowa nie spełnia cech trwałego nośnika. [zotpressInText item=”{5085975:7L99WLMW}”]

Co radzą prawnicy

Co to jest depozyt kodu źródłowego ?

Depozyt kodu źródłowego (ang. source code escrow) jest jednym z najlepszych środków ochrony przed skutkami upadłości producenta oprogramowania. W praktyce depozyt kodu źródłowego polega na złożeniu przez Licencjodawcę / Deponenta (firmę produkującą oprogramowanie) kodów źródłowych u depozytariusza (tzw agenta depozytu), przy równoczesnym upoważnieniu licencjobiorcy (kupca oprogramowania) do pobrania i dalszego wykorzystania kodów źródłowych w określonych w umowie depozytowej w przypadkach, takich jak np. upadłość, wrogie przejęcie, likwidacja producenta oprogramowania, zaprzestanie rozwoju aplikacji, zaprzestania świadczenia usług serwisowych i wsparcia przez licencjodawcę.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Podsumuję to tak:

1. jeżeli oprogramowanie jest dedykowane to właścicielem i posiadaczem praw majątkowych do kodu i wszelkiej jego dokumentacji powinien być jego użytkownik,
2. jeżeli oprogramowanie jest licencjonowane, to użytkownik powinien znać mechanizm jego działania, co pozwala w dowolnym momencie kupić na rynku analogiczne, lub w skrajnym przypadku zlecić napisanie.
3. jeżeli ktoś używa oprogramowania, którego dziania nie rozumie, to może to mieć sens tylko w przypadkach gdy użytkownik wymaga wyłącznie efektu i nie musi rozumieć tego jak powstał: np. oprogramowanie OCR czy retusz zdjęć.

Podczas negocjacji na temat kupna oprogramowania w pewnym momencie rozważny licencjobiorca może zapytać: Co się stanie, jeśli dostawca oprogramowania zakończy swój biznes? Zazwyczaj następuje żądanie dostępu do kodu źródłowego i wszelkich innych krytycznych materiałów używanych do utrzymania oprogramowania.

https://axteon.pl/depozyt-kodu/depozyt-kodu-%C5%BAr%C3%B3d%C5%82owego/

Co do zasady: oprogramowanie się licencjonuje (brak jakichkolwiek praw do niego) lub zleca jego wykonanie (wtedy jest się jego właścicielem, także kodu).

Umowa depozytu kodu źródłowego znana jest w Stanach Zjednoczonych od około 50 lat pod nazwą software escrow. Już wtedy była wykorzystywana do zabezpieczenia oprogramowania tworzonego przez wyspecjalizowane firmy z branży IT. Na początku XXI w. konstrukcja zaczęła upowszechniać się w Europie, ale w Polsce dla wielu przedsiębiorców nadal stanowi całkowicie obce zagadnienie. Po co deponować kod źródłowy i jak prawidłowo skonstruować taką umowę?

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

50 lat temu, miało to sens bo czasy były takie, że oprogramowanie to były relatywnie małe monolity, kodu było nie wiele, a języków programowania kilka. Obecnie stopień złożoności oprogramowania oraz mnogość technologii powoduje, że kod z zasady nie jest swoją dokumentacją.

Kod źródłowy to nic innego jak zbiór poleceń napisanych w określonym języku programowania, które pozwalają zarządzać zgromadzonymi i wprowadzanymi danymi. Aby kod źródłowy mógł działać, niezbędna jest jego kompilacja, czyli przekształcenie w kod wynikowy, który następnie może zostać zastosowany przez procesor. Efekt takiego działania użytkownik widzi na monitorze komputera. Kod źródłowy zazwyczaj ma postać pliku tekstowego i jako taki może on zostać zapisany na trwałym nośniku, np. płycie CD lub pamięci nieulotnej typu FLASH.

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

I to jest prawda, jednak problem w tym, że konkretny kod, to jedno z dziesiątek możliwych metod odwzorowania mechanizmu przetwarzania danych (co opisano wcześniej) i niestety bardzo trudne do zrozumienia przez osoby inne niż autor twego kodu.

Każdy dostawca oprogramowania w nieco inny sposób tworzy dokumentację software’u, dlatego warto zadbać o to, aby w umowie były wymienione wszystkie konieczne elementy, które znajdą się u depozytariusza. Co powinno się wśród nich znaleźć?

– aktualizowana karta wersji wraz ze wskazaniem wszystkich wprowadzonych zmian,
– opis struktur katalogów kodów źródłowych wraz ze wskazaniem standardu nazewnictwa plików źródłowych i wynikowych,
dokładny opis procedury kompilacji,
– opis środowiska kompilacyjnego i zdefiniowane biblioteki programistyczne,
– dokumentacja techniczna baz danych wraz ze wskazaniem nazw tabel i relacji między nimi oraz podaniem ewentualnych atrybutów,
– narzędzia do przygotowania wersji instalacyjnej, czyli takiej, która będzie się nadawała do wgrania na twardy dysk oraz do samej instalacji.
W ten sposób licencjobiorca ma gwarancję, że po zwolnieniu kodu będzie dysponował wszystkimi narzędziami, za pomocą których samodzielnie obsłuży otrzymany kod źródłowy.

https://rpms.pl/depozyt-kodu-zrodlowego-oprogramowania/

Niestety nie ma żadnej gwarancji, gdyż narzędzia kompilacji, w tym ich wersje, mogą być niedostępne na rynku, i nadal pozostaje kwestia tego, że nabywca “nie wie jak to działa” bo dla niego kod źródłowy jest niezrozumiały, a zlecenie innemu deweloperowi tworzy konflikt interesu i bardzo duże koszty.

A czym więc jest oprogramowanie?

Jedną z najbardziej szkodliwych działań na rynku jest lansowanie tezy, że kod źródłowy to jakieś wartości intelektualne, i wie o tym każdy kto z takim kodem został sam. Jest to nie prawda: polecam publikacje Urzędów Patentowych na świecie [zotpressInText item=”{5085975:Y86V5TMQ}”].

Kod źródłowy to co najwyżej “kołka zębate maszyny” [zotpressInText item=”{5085975:QAHTAUZ4}”]. Kod źródłowy, jako wartości intelektualne, jest bezwartościowy bez jego autora, tak samo jak bezwartościowy jest tort bez recepty na jego wykonanie. Wie o tym każdy kto został z kodem źródłowym bez dewelopera, który go napisał.

Oprogramowanie to skrypt konfigurujący komputer zas jako ludzie używamy komputera a nie “kodu źródłowego” [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Dlatego w IT raczej należy skupić się na ochronie know-how: chronimy projekt buta a nie buty, chronimy receptury dań a nie to co podamy na stół. W fabryce samochodów chronione know-how to dokumentacja techniczna samochodu, a nie samochody na parkingu.

Jako użytkownik cudzego (licencja) oprogramowania powinniśmy chronić to co z jego pomocą tworzymy. Mając swoje dedykowane oprogramowanie należy chronić opis mechanizmu jego działania, który możemy zaimplementować kiedykolwiek z pomocą dowolnego języka programowania.

Podsumowanie

Więc jak? Użytkownik oprogramowania:

1. albo licencjonuje od dostawcy oprogramowanie standardowe i nie kastomizuje go, tu wymaganie kodu źródłowego jest kuriozalne, a sytuację “awaryjną” leczy zakup analogicznego, standardowego oprogramowania od innego producenta (Finanse i księgowość, itp.).
2. albo posiada prawa majątkowe do dokumentacji i oprogramowania wykonanego specjalnie dla niego, i firma – deweloper – która to wykonała nie ma nic do gadania.

Każda inna forma to szukanie kłopotów. Więcej o kastomizacji i dlaczego jest ona poważnym błędem: Kastomizacja oprogramowania standardowego, aspekty ekonomiczne: Recenzja i rekomendacje. Samodzielne, ponowne, po kilku latach, uruchomienie “starego” kodu źródłowego graniczy z cudem.

Nie jest też możliwe by jakaś jedna aplikacja obsłużyła cała firmę. Nie ma czegoś takiego jak “jedna wspólna baza danych” jako “jedno źródło prawdy”, bo dane są zawsze kontekstowe. Dlatego system IT to raczej kilka tematycznych źródeł prawdy (dziedzinowe oprogramowanie zintegrowane w jeden system), a nie jedno centralne. Wielkie wdrożenia kastomizowanych (nieudokumentowane kastomizacje) monolitów ERP kończą sią zawsze porażką.

Jak udokumentować oprogramowanie: Analiza Biznesowa i Opis Techniczny Oprogramowania – moja rola w projekcie.

P.S.

Przykład. W powyższy sposób opracowałem i udokumentowałem logikę działania systemu Generator Ofert dla Kancelarii Senatu. Jest to oprogramowanie obsługujące dofinansowanie projektów dla polonii na całym świecie: od naboru wniosków, przez ich procesowanie, zatwierdzanie, podpisywanie umów aż do rozliczenia. Aplikacja dwa razy zmieniała firmę, która obsługiwała jej utrzymanie i rozwój, później została przepisana w nowej technologii w toku przejścia z chmury na hosting dedykowany. Dzięki temu, że zastosowano dokumentowy model danych, migracja do nowej wersji odbyła praktycznie bez kosztowo.

Czarny humor na zakończenie

Poniższy mem jest dość popularny w sieci:

Jego parafraza:

Koder: Tylko kod źródłowy jest dokumentacją oprogramowania.

Użytkownik: To oprogramowanie nie działa poprawnie, gdzie jest opis poprawnego (oczekiwanego) działania tego programu?

Koder: Opisem jest ten kod źródłowy….

(autor mema nie znany)

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

Wprowadzenie

API to skrót od Application Programming Interface, i jest to niestety bardzo myląca nazwa. Dlaczego? Bo to nie jest “coś do programowania”. API to po prostu usługa aplikacji udostępniana nie (ludzkim) użytkownikom na ekranie komputera, a innym aplikacjom.

Dwa lata temu opisywałem projektowanie API i integracji, pisałem też, dlaczego od integracji obecnie nie ma już ucieczki:

Mamy ogólnoświatową sieć Internet, aplikacje lokalne i w chmurze, aplikacje naszych kontrahentów i aplikacje centralnych urzędów. Wszystkie one współpracują i wymieniają dane, czyli są zintegrowane. Dlatego integracja stała się cechą każdego systemu informatycznego. […] Czym jest obecnie integracja? To wymiana danych a nie ich współdzielenie: dane z urzędem wymieniamy, dane z kontrahentem wymieniamy, nie współdzielimy żadnych danych z tymi podmiotami, każdy ma swoje własne, bezpieczne bazy danych, i to wszystko ładnie działa! Idea zbudowania wszystkich funkcjonalności jako zintegrowanej aplikacji na jednej współdzielonej bazie danych w czasach obecnych jest utopią. Taką samą jak hipotetyczna centralna baza danych dla wszystkich sklepów internetowych, firm kurierskich i banków, a one są jednak zintegrowane: one wymieniają dane a nie współdzielą!

https://it-consulting.pl/2022/02/21/integracja-jako-zrodlo-przewagi-rynkowej-czyli-jak-projektowac-rest-api-z-visual-paradigm/

Artykuł powyższy polecam osobom zainteresowanym stroną techniczną projektowania integracji i API. Dzisiaj odpowiem na problemy jakie zgłaszają prawnicy, czyli co jest przedmiotem umowy gdy przedmiotem tym jest mityczne API.

Aplikacja i jej API – co to takiego

API to nic innego jak przypadki użycia (każda operacja to osobny use case) tyle, że tu aktorem jest inna aplikacja a nie człowiek.

Generalnie każda aplikacja (komputerowy program użytkowy) świadczy swoim użytkownikom określone usługi, w notacji UML aplikacja to ‘system’. Użytkownikiem aplikacji jest każdy zewnętrzny byt, mający z tą aplikacją interakcje, w notacji UML jest to aktor. Aktorem jest zarówno nasz usługodawca jak i usługobiorca. Jeżeli aktorem jest człowiek, jako interfejsu używa on GUI (Graphical User Interface). Jeżeli aktorem jest aplikacja, używa ona API (Application Programming Interface). Ta nieszczęsna nazwa: programming interface, ma swój rodowód w tym, że adresatem opisu tego interfejsu jest programista/projektant, a nie ludzki użytkownik aplikacji.

Poniższy diagram (diagram przypadków użycia notacji UML) obrazuje wyżej opisane role:

Diagram ten pokazuje kontekst czyli kto jest użytkownikiem i czego, dlatego pokazane elementy różnią sie kształtem (różne ikony). Jednak powyższa architektura, pokazana na diagramie komponentów, który nie niesie informacji o kontekście “ja/ty”, wygląda tak:

Tak zwane “lizaczki” na tym diagramie to interfejsy oferowane, “klieliszki” to interfejsy wymagane. Tak więc API1 to: interfejs oferowany przez System Usługodawcy i jednocześnie interfejs wymagany przez System. API2 to interfejs oferowany przez System i jednocześnie interfejs wymagany przez System Usługobiorcy. GUI to interfejs oferowany przez System (ludzkiemu) Użytkownikowi.

Co do zasady, bez względu na to czy oferowany czy wymagany, interfejsy definiujemy jako:

• nazwa polecenia (opcja w menu użytkownika),
• jego parametry,
• odpowiedź,
• struktury parametrów i odpowiedzi (formularz ekranowy, komunikat).

Całość to zawsze dialog: wywołanie usługi z ewentualnym parametrem, odpowiedź z ewentualnym parametrem. Te parametry to dane, mogą być zebrane jako nazwany komunikat i jego struktura (zalecane). Ważne jest to, że tak na prawde nie ma znaczenia czy aktorem jest człowiek czy aplikacja, bo mechanizm generowania odpowiedzi, realizowany przez System, jest taki sam.

Widać to np. na poniższym diagramie pokazującym przykładowe wnętrze aplikacji:

To czy aplikacja będąca usługodawcą jest w naszej serwerowni czy w chmurze, nie ma żadnego znaczenia.

Prawnik zgłasza problem

Na portalu LinkedIn, pojawiają sie różne ciekawe wpisy, szczególnie ciekawe są te na styku IT i prawa. Tym razem prawniczka zgłasza problemy:

Obecnie duża część biznesów opiera się na produktach API. Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.

[LINK do źródła]

?Problem pierwszy. Jak dobrze zdefiniować czym jest API? I klucz API?

API to usługa, klucz to hasło/kod dostępu do niej,

?Problem drugi. Zakres udzielanych licencjobiorcy praw

identyczny jak dla człowieka: może korzystać albo nie, pozyskana treść może być chroniona innym prawem (np. API udostępniające eBooki),

?Problem trzeci. Zakres obowiązków dostawcy API

identyczny jak każdego innego dostawcy oprogramowania,

?Problem czwarty. Kod API informacją poufną czy nie?

nie ma żadnego “kodu API”, jest kod aplikacji (jest także mechanizm działania tej aplikacji),

?Problem piąty. Standardy bezpieczeństwa w korzystaniu z API, potrzebne?

tak samo jak dla każdej aplikacji,

?Problem szósty. Zbieranie informacji na temat korzystania z API przez licencjobiorcę, potrzebna zgoda czy nie?

tak samo jak zbieranie każdych innych statystyk, dodam, że użytkownik może sobie robić dowolne statystyki po swojej stronie i nikogo nie musi pytać o zgodę na to,

?Problem siódmy. Użytkownicy dalsi, jak oni korzystają z API?

co to za cudo Ci “Użytkownicy dalsi”?

?Problem ósmy. Czy umowę można wypowiedzieć?

a dlaczego nie? Umowa jak każda inna,

?Problem dziewiąty. Przekazywanie danych poprzez API, potrzebna zgoda użytkowników aplikacji czy nie?

nie da się używać API nie przekazując danych 🙂

?Problem dziesiąty. Gwarancja na API, dawać czy nie dawać?

tak samo jak jak na każde oprogramowanie,

?Problem jedenasty. Odpowiedzialność, ograniczać? I co z odpowiedzialnością za aplikacje wykorzystujące API?

nic, robią co chcą,

?cachowanie, logowanie ruchu i wyjątków dostępu, forward i reverse proxy na dane dostępne z API

to wewnętrzne funkcje systemu a nie cecha API (SLA)

?sandbox testowy API vs produkcyjny (mockowanie API)

to dodatkowa oferta, taka sama jak np. “testowe używanie ERP przez księgową”

?SLA + healthChecki

jak wyżej

?rozliczenie i monitorowanie płatności / subskrybcji dostępów do api + ograniczenia z tym związane: dostępu, ilości wysłanych i odebranych danych, prędkość wysyłania i odbierania danych, przetwarzanie masowe, maksymalne rozmiary wysyłanych i odbieranych danych, dopuszczalna ilość żądań/s, timeout-y

jak wyżej

?walidacja i gwarancja poprawności danych (jedno źródło prawdy)

a kto chce niepoprawne?

?wersjonowanie API, kompatybilność wsteczna z elementami “legacy API”

to jakoś systemu i jego dostawcy,

?retencja danych

to wymaganie i cecha oprogramowania a nie cecha API.

Podsumuję to tak

“Udostępnienie czy sprzedaż API nie jest dokładnie jednak taka sama jak sprzedaż produktu Software-as-a-Service lub licencjonowanego oprogramowania. “

To nie jest prawda, to jest to samo.

“Istnieją pewne specyficzne niuanse, które muszą zostać umownie określone w umowach licencyjnych API.”

to też nie jest prawda, nie istnieją takie.

To co istnieje, to oprogramowanie, które:

– oferuje usługi (funkcjonalności)

– oferuje pewien poziom jakości (SLA) i kontroli dostępu do niego.

tak jak każde oprogramowanie.

Prawnicy: nie zmyślajcie problemów na siłę.

Wprowadzenie

W 2014 roku pisałem o długu technologicznym:

Dług tech­no­lo­gicz­ny to coś o czym mało się pisze i mówi, a pra­wie każ­dy się z nim bory­ka. W dużym uprosz­cze­niu to jak zmy­wa­nie naczyń: jeże­li robi­my to regu­lar­nie po każ­dym posił­ku, to zaj­mu­je to góra kil­ka­na­ście minut a do wyko­na­nia wystar­czy ście­recz­ka. Jeżeli jed­nak uzna­my, że zmy­je­my naczy­nia dopie­ro jak ​„stat­ki” w zle­wo­zmy­wa­ku zasło­nią okno kuch­ni :), to nie tyl­ko jed­no­ra­zo­wo stra­ci­my znacz­nie wię­cej cza­su, ale dodat­ko­wo zafun­du­je­my sobie wal­kę z zaschnię­tym tłusz­czem i reszt­ka­mi jedze­nia, dla­te­go – co cie­ka­we – czas i wyma­ga­ne ​„środ­ki” potrzeb­ne na rzad­kie pozmy­wa­nie tej góry nagro­ma­dzo­nych naczyń, są zawsze więk­sze niż suma nakła­dów pra­cy na czę­ste drob­ne zmy­wa­nie. Zmywanie naczyń to nie­lu­bia­na a koniecz­na czynność. Z tech­no­lo­gią w fir­mach jest bar­dzo podob­nie: postęp tech­nicz­ny i ewo­lu­cyj­ne zmia­ny w fir­mach, są jak nara­sta­ją­ca licz­ba brud­nych naczyń: prę­dzej czy póź­niej będzie­my musie­li to upo­rząd­ko­wać (nad­ro­bić) – albo wyrzu­cić i kupić nowe. Jedno i dru­gie kosz­tu­je spo­ro. Dotyczy to w jed­na­ko­wym stop­niu aktu­ali­zo­wa­nia zakre­sów obo­wiąz­ków, doku­men­ta­cji tego jak fir­ma pra­cu­je, ana­liz i pro­jek­to­wa­nia, doku­men­ta­cji archi­tek­tu­ry IT jak i upgra­de­’ów oprogramowania.

źr.: Czym jest dług technologiczny? – Jarosław Żeliński IT-Consulting

W artykule pisałem głównie o technologii. Dług technologiczny, jak każdy dług – prędzej czy później – wymaga spłaty. Co się dzieje gdy nie spłacamy długów? Zaczyna się tak zwana spirala zadłużenia, która w wielu przypadkach kończy się krachem. W inżynierii jest tak samo: przychodzi moment, gdy dług przekroczy wartość zasobów zadłużonego. Innymi słowy koszt aktualizacji poziomu technologii do aktualnego wymaganego, może przewyższyć możliwości organizacji.

Dzisiaj powiemy co nieco o innym i gorszym długu: o długu informacyjnym (information depth).

Dług Informacyjny

Dług informacyjny, jako pojęcie, pochodzi z teorii transmisji danych:

Dług informacyjny, wprowadzony przez Martiniana, jest miarą dodatkowych symboli kodowych potrzebnych w dekoderze do zdekodowania wszystkich nieznanych symboli wiadomości.

[zotpressInText item=”{5085975:DPE2ND8L}”]

Innymi słowy poprawne odkodowanie przesłanych informacji wymaga kompletu brakujących danych w nadanym ciągu kodowym, musimy skompletować wszystkie zaległe i nieodebrane dane. Jak sie to ma inżynierii?

Długiem informacyjnym w organizacji i zarządzaniu nazywamy różnicę między posiadaną (czyli udokumentowaną) wiedzą o tym jak określony system działa, a tym jak on faktycznie działa. Najprostszą metodą zaciągania długu informacyjnego jest budowa i rozwijanie systemu bez równoległego dokumentowania podjętych decyzji na temat tego jak ma działać, a potem jak faktycznie działa. Tym systemem może być zarówno cała organizacja, jak i jakiś jej podsystem, np. informatyczny. Obrazowo wygląda to tak:

Jeżeli firma planuje wdrażanie zmian, w tym np. wdrożenie nowego systemu informatycznego, pojawia się problem niwelowania długu informacyjnego i jego koszt: musimy w krótkim czasie uzupełnić brakującą wiedzę. Nazywamy to często analizą biznesową, analizą przedwdrożeniową itp.:

Niestety bardzo często, po wykonaniu tej analizy i zakończeniu wdrożenia, w organizacji zaczyna się proces narastania długu informacyjnego. A bardzo często ten proces zaczyna się zaraz po zakończeniu tej kosztownej analizy i rozpoczęciu wdrożenia, bo dostawca systemu nie dokumentuje efektów swoich prac (a powinien).

Popatrzmy na wykresy poniżej:

Rysunek (a) pokazuje typowe dla inżynierii systemów inwestowanie w przyszłość (, polegające na projektowaniu (czyli także dokumentowaniu) poprzedzającym implementacje już na wczesnych etapach życia projektu, wtedy gdy mamy niższe skumulowane koszty. Większość przyszłych kosztów projektu zostanie poniesiona w wyniku decyzji o charakterze inżynierii systemów i będą to już relatywnie niskie koszty, gdyż “wiemy wszystko” by podejmować kolejne decyzje o rozwoju systemu. Jest to jeden z tradycyjnych argumentów za inwestycjami w inżynierię systemów na wczesnym etapie.

Rysunek (b) dodaje koncepcję długu informacyjnego, który jest jeszcze nie wygenerowaną informacją niezbędną do dostarczenia i potem utrzymania systemu. Wykres ten ilustruje trzy różne scenariusze redukcji długu informacyjnego. Istnieją efektywne koszty “odsetek” płacone przez projekty, które nie spłacają swojego długu informacyjnego wystarczająco wcześnie, a im wyższe ryzyko, tym większej “kary odsetkowej” należy się spodziewać. Scenariusz 3 na Rysunku (b) ilustruje przypadek szczególnie niepokojący dla tradycyjnych inżynierów systemów rozważających metody zwinne: Czy Manifest Agile oznacza, że projekt zakończy się z pozostałym długiem informacyjnym, pozostawiając nas z “działającym systemem”, ale długiem informacyjnym: “ciągłą “karą odsetkową” spowodowaną brakiem potrzebnych informacji?

Rysunek (c) ilustruje, że informacje dotyczące inżynierii systemów (np. wymagania, architektury projektowe, oceny ryzyka itp.) wypracowane i dokumentowane wystarczająco wcześnie w projekcie, to inwestycja zmniejszająca dług informacyjny wystarczająco wcześnie a nawet całkowicie.

Obserwowana jest obawa społeczności agile, że odgórne generowanie dokumentacji, które kojarzą z inżynierią systemów, może wiązać się z własnym ryzykiem: podważaniem “sprzedanej” idei agile, a także ryzyku polegającym na zbyt późnym odkryciu nieporozumień dotyczących potrzeb i oczekiwań interesariuszy, skuteczności podejść projektowych itp. Obie te obawy są uzasadnione i potrzebne są obiektywne środki, aby znaleźć właściwy środek – taki jest cel koncepcji długu informacyjnego. Zmusza nas to do podjęcia decyzji, jakie informacje są naprawdę wymagane w każdym kolejnym cyklu życia systemu [zotpressInText item=”{5085975:BQSPVYK2},{5085975:5GGEM7XV}”].

Podsumowanie

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.

W takiej sytuacji każda istotna decyzja wymaga ogromnego wysiłku (czas i pieniądze) by minimalizować ryzyko błędu z powodu niewiedzy. Jak wspomniano wyżej na przykładzie Lockheed Martin, od wielu lat ma miejsce rewizja sensu podejścia zwanego „agile”, które dając nie raz faktycznie szybkie pierwsze efekty, wpędza jednocześnie organizacje w ogromne koszty spłaty długu informacyjnego w przyszłości, z reguły wielokrotnie większe niż „szybkie oszczędności” uzyskane na początku.

Strategie MVP (Minimum Viable Product) czy Quick Wins (szybki sukces na początku) to sukcesy na pokaz, mszczą się długiem spłacanym z dużą nawiązką, najczęściej już po odejściu sowicie opłaconych konsultantów, którzy te strategie polecali.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]

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 V-model, prezentowany w poniższej ogólnej postaci:

V-model składa się z części: projektowanie, implementacja, testowanie, powtórzenie tego cyklu to rozwój (testy to kryteria akceptacji). Model ten stanowi fundament rozważań o testach, gdyż test to sprawdzenie, a sprawdzenie polega na porównaniu z wzorcem. Co jest wzorcem? Obietnica. A co jest tą obietnicą? Model tego co ma (miało) powstać.

Ważne pytanie: Czym jest inżynieria?

Engineering is the designing, testing and building of machines, structures and processes using maths and science.
[Inżynieria to projektowanie, testowanie i budowanie maszyn, struktur i procesów przy użyciu matematyki i nauki.]

(żr.: https://www.bath.ac.uk/campaigns/what-is-engineering/)

Tak więc mówimy o projektowaniu. Na etapie prac inżynierskich powstają: koncepcja i zakres produktu (Concept of Operations), następnie wymagania (Requirements and Architecture) i w końcu projekt (Detailed Design). Kolejny etap to implementacja czyli proces opracowania technologii wykonania i wykonanie produktu (produktem nazywamy przedmiot jaki ma powstać). Powyższe dotyczy każdego produktu inżynierii.

Powstaje więc często pytanie: Czy to co nam dostarczono jest tym co chcieliśmy dostać?

Przedmiot testowania a podmiot testujący

Kluczowe pojęcia w tym wpisie (źr.: sł. j. polskiego PWN):

test: próba, której poddaje się urządzenie, produkt, preparat itp. w celu sprawdzenia jego składu, właściwości i działania; też: to, co służy do przeprowadzenia takiej próby
scenariusz: zaplanowany lub przewidywany rozwój wydarzeń
przedmiot: rzecz, materialny element świata
podmiot:
1. ?nadrzędna część zdania nazywająca osobę, rzecz lub zjawisko, o którym się w zdaniu orzeka?
2. ?osoba aktywna, uczestnicząca w czymś?
3. filoz. ?umysł poznawczy w przeciwieństwie do przedmiotu, który jest poznawany?
4. ?osoba fizyczna lub prawna mogąca mieć prawa i obowiązki?
projekt:
1. ?plan działania?
2. ?wstępna wersja czegoś?
3. ?dokument zawierający obliczenia, rysunki itp. dotyczące wykonania jakiegoś obiektu lub urządzenia?
komputer: ?urządzenie elektroniczne automatycznie przetwarzające dane zapisane cyfrowo, służące do szybkiego wykonywania obliczeń, przechowywania, porządkowania i wyszukiwania danych oraz sterowania pracą innych urządzeń? (definicja sprawozdawcza)
komputer: urządzenie zawierające procesor, pamięć i program (definicja realna)
mechanizm:
1. ?zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę?
2. ?sposób, w jaki coś powstaje, przebiega lub działa?
wymaganie: ?warunek lub zespół warunków, którym ktoś lub coś musi odpowiadać?

Pojęcia wieloznaczne zostały pozostawione z definicjami używanymi w dziedzinie inżynierii. Dla lepszego zrozumienia i zarazem przetestowania spójności tego zestawu pojęć, tworzymy model pojęciowy w postaci diagramu opisującego pojęcia i związki między nimi (ontologia wyrażona graficznie):

Model pojęciowy jak ten powyżej, to test jednoznaczności zdań budowanych z pojęć, których spójność, kompletność i niesprzeczność chcemy wykazać. Każda para pojęć połączonych predykatem powinna tworzyć zdanie prawdziwe w analizowanej dziedzinie (taki model powinna zawierać każda analiza biznesowa i specyfikacja wymagań!)

Tak więc przedmiotem testowania jest komputer, a nie – jak sie potocznie mówi – oprogramowanie. Oprogramowanie to tekst (zestaw instrukcji dla procesora), który umieszczony w pamięci komputera, intepretowany przez procesor jako program do wykonania. To z czego korzystamy to urządzenie jakim jest komputer, ten zaś jako całość realizuje określony mechanizm (patrz artykuł Prawo autorskie w projektach IT). Nawet siedząc i czytając ten artykuł korzystasz czytelniku z komputera a nie z “oprogramowania”. Dlatego w nauce (tu information science) mówi się, że komputer to ‘uniwersalny mechanizm’ [zotpressInText item=”{5085975:ZCXJ2S7U}”].

Badanym (testowanym) przedmiotem jest więc komputer (ten zawiera oprogramowanie), który musi spełniać wymagania, a wymaganiem jest projekt mechanizmu jaki realizuje. Dlaczego wymaganiem jest projekt a nie “wymagania”? Bo V-model to także pętla zarządzania jakością, tę pętlę zamyka “strzałka w lewo”: weryfikacja i walidacja. Jest to tak zwana Pętla Cyklu Życia Oprogramowania (ang. SDLC):

Z perspektywy inżynierii Zamawiający (podmiot) zamawia produkt (przedmiot). Aby wyrazić to co zamawia, musi określić swoje wymagania. Wymagania można określić na trzy typowe sposoby:

1. potrzeba (chce przedmiot który pomoże mi w…., posłuży do…)
2. warunki (przedmiot powinien mieć wymagane cechy:…)
3. projekt (to jest opis tego jak jest zbudowany i jak ma działać przedmiot, czasami można użyć analogii: chce coś takiego jak …)

Powyższe to nic innego jak lewa strona V-modelu: to są wzorce, a testowanie to ocena zgodności tego co powstało z wzorcem tego co miało powstać, czyli z tym co zaprojektowano (z projektem). Te trzy etapy są zgodne z MDA: analiza biznesowa (CIM, Computation Independent Model), określenie zakresu produktu (przypadki użycia), opracowanie mechanizmu działania (PIM, Platform Independent Model). Model PSM (Platform Specific Model) jest pierwszym etapem implementacji [zotpressInText item=”{5085975:FX3SVDIW}”].

W projektach z zakresu inżynierii oprogramowania V-model jest często przedstawiany jak poniżej:

A jak to widzi i czuje w kieszeni klient

Bo pytanie brzmi: kto, co i kiedy, tak na prawdę testuje. Popatrzmy na to od końca, czyli od momentu gdy dostajemy gotowy produkt:
1. Dostawca oprogramowania udziela rękojmi (musi zgodnie z prawem)
2. Dostawca oprogramowania może udzielić gwarancji
3. Zamawiający oczekuje oprogramowania zgodnie z zamówieniem
4. W dniu odbioru Zamawiający dokonuje podstawowego przeglądu na zgodność z zamówieniem (taka jazda próbna przy odbiorze samochodu), podstawą odbioru jest LISTA POTRZEB.
5. Z uwagi na złożoność oprogramowania (podobnie jak i samochodu) w okresie rękojmi (i gwarancji) wady mozna zgłaszać do dostawcy przez ustalony okres czasu od dnia odbioru, tu podstawą zgłaszania wad jest dokumentacja opisująca mechanizmy i algorytmy działania (czyli co i jak powinno zostać policzone i jaki powinien pokazać się wynik).
6. Po zakończeniu okresu rękojmi i gwarancji przechodzimy do fazy utrzymania i rozwoju na własny koszt (dlatego tak ważne jest zabezpieczenie przed zjawiskiem zwanym vendor lock-in!).

Od góry (przytaczam ponownie V-model po prawej):

1. Po dokonaniu odbioru i przejścia do fazy eksploatacji systemu, weryfikowana jest (przez życie) koncepcja i cele wdrożenia.
2. Na etapie odbioru systemu weryfikujemy zgodność z wymaganiami i architekturą HLD
3. Na etapie wytwarzania weryfikujemy wewnętrzną spójność i poprawność działania.
4. Etap implementacji to cała praca nad doborem technologii, konfiguracją środowiska i napisaniem brakującego kodu (wbrew proporcjom na diagramie, jest to najkosztowniejsza część projektu).

Rękojmia i gwarancja to usuwanie wad i niezgodności odpowiednio na koszt dostawcy i producenta, po dokonaniu odbioru. Sam odbiór to testy zgodności: czego i z czym? I teraz pytanie do Zamawiającego:
a. czy masz aktualną dla projektu listę potrzeb i kto jej jej autorem?
b. czy masz dokumentacją mechanizmu działania aplikacji i kto jest jej autorem?
c. kto ma prawa majątkowe do tych dokumentów?

Testy odbiorcze to scenariusze. kto je opracował? Sprawdzany czy sprawdzający? Czy wiesz więc za co płacisz? Czy jesteś pewien że treści i liczby na generowanych z systemu dokumentach są poprawne? Czy może czytelniku dałeś sobie wmówić, że jedyna prawdziwa dokumentacja oprogramowania to działający kod? A czy TY jesteś w stanie z takiej “dokumentacji” skorzystać? Więc za co Wy płacicie? Za to, że kazali Wam zapłacić?

Kilka słów o mechanizmie

Przypomnijmy definciję:

mechanizm: 1. ?zespół współpracujących ze sobą części maszyny lub przyrządu, wykonujących jakąś pracę? 2. ?sposób, w jaki coś powstaje, przebiega lub działa?

Innymi słowy, jeżeli chcemy świadomie uzyskać określony efekt, to musimy określić mechanizm jego powstawania. Model-based System Engineering (MBSE) to metodyka podejścia do projektowania i inżynierii oparta na modelowaniu [zotpressInText item=”{5085975:RA6YBH48}”]. Poniżej często przytaczany model obrazujący związek wymagań z mechanizmem (modelem) działania systemu:

Mamy trzy ściśle powiązane perspektywy: wymagania, struktura (architektura) systemu oraz jego zachowanie. Jeżeli wyrazimy je jako modele, to powstaną trzy ścisłe z soba powiązane: model wymagań, model struktury i model zachowania. W przypadku inżynierii systemów stosujemy od lat notację SysML (jest to specjalny profil notacji UML). Te trzy modele muszą być spójne, kompletne i niesprzeczne, bez czego system, jaki na ich podstawie powstanie, będzie wykazywał błędy. Dlatego tak na prawdę model systemu to te trzy modele i ich TESTY w postaci macierzy zgodności (chodzi o kontrole tych czarnych punktów na diagramie powyżej) [zotpressInText item=”{5085975:63PW4WQU}”].

Po co nam model na etapie wymagań? Same wymagania to tak zwany opis “czarnej skrzynki”: wiemy jaki efekt obserwujemy ale nie wiemy jak powstał. Czy to groźne? Bardzo, bo np. zegar jaki obserwujemy na pulpicie komputera to może być prosty mechanizm pokazujący zmieniające się co sekundę kolejne obrazy tarczy zegara (43.200 obrazów i prosty mechanizm ich kolejnego wyświetlania) lub model opisujący mechanizm pomiaru czasu i dynamicznego generowania obrazu pokazującego aktualną godzinę (patrz artykuł o zegarze: Model dziedziny jako mechanizm). Ten pierwszy będzie tanim w wykonaniu i koszmarnie kosztownym w utrzymaniu i rozwoju systemem, drugi – mimo kosztów projektowania – będzie niewiele droższy na etapie wykonania ale będzie o całe rzędy tańszy na etapie utrzymania i rozwoju. Proste testy odbioru “czarnej skrzynki” niczego złego nie pokażą, system zostanie odebrany. Gehenna zacznie się przy próbie pierwszej zmiany np. koloru tarczy… Dlatego MBSE to podejście nazywane często: “projekt systemu jako wymaganie” (pamiętamy żarty o maszynie do obierania ziemniaków, w której był zamknięty człowiek).

Podsumowanie

Testy to sprawdzenie, a tu mamy (powinniśmy mieć) jasny podział na sprawdzającego i sprawdzanego. Typowe dla rynku IT jest wmawianie klientom, że nie mają żadnych kompetencji do analiz, testów, projektowania, że wszystko to zrobi dostawca oprogramowania. Tak więc u tego samego, jednego, dostawcy oprogramowania zamawiana jest: analiza biznesowa, analizy wymagań, projektowanie, implementacja, pisanie testów odbiorczych i testy. Podmiot jakim jest Zamawiający w zasadzie tylko patrzy, i płaci tyle ile chcą dostawcy (projekty T&M to brak kontroli). W efekcie sprawdzający i sprawdzany to ten sam podmiot. Czy to ma sens?

Ostatecznym testem jest to “jak to wszystko działa w praktyce” czyli średnio i długo terminowe efekty wdrożenia. To zaś zależy od dwóch kluczowych rzeczy:

• pierwotnej koncepcji biznesowej: wpływ wdrożonego oprogramowania na biznes, oraz
• wewnętrznej architektury oprogramowania: wpływ na koszty utrzymania i rozwoju.

Oba powyższe elementy to lewa strona V-modelu. Biorąc pod uwagę fakt, że koszty utrzymania i rozwoju to konsekwencja wewnętrznej architektury, dostawcy systemów bardzo często forsują rezygnacje z rękojmi i gwarancji (wtedy nie ponoszą finansowych skutków niskiej jakości projektu i implementacji). Co to znaczy? Że jeżeli mamy mieć faktyczny podział na sprawdzającego i sprawdzanego, analiza i projektowanie powinna mieć miejsce po stronie Zamawiającego przed wyborem dostawcy. Jak? Po prostu zatrudnić inżyniera do analiz i projektowania oraz do nadzoru, bo praktyka pokazuje, że wtedy może być znacznie szybciej i nawet 10-krotnie taniej.

A teraz pytanie: co i jak testować gdy skastomizujesz kupiony duży gotowy system z tysiącem tabel w bazie danych? Pamiętaj też, że kastomizacja kodu to utrata gwarancji producenta.

Źródła

[zotpressInTextBib style=”apa” sortby=”author” sort=”ASC”]