O problemach prawnych związanych z bazą danych systemu IT

Podczas zgłębiania problemów prawnych związanych z systemami IT, wymagana jest systematyczna wiedza prawnicza, ale równocześnie ważne jest również zrozumienie elementów składowych systemu IT. W tym artykule omówimy, z jakich części składa się system IT, jak te części współdziałają ze sobą, a także omówimy problemy prawne, które są szczególnie związane z bazami danych, które są trudne do zauważenia dla użytkowników.

Systemy IT składają się z “ekranu” i “logiki”

Czym jest “ekran” w systemie IT

Kiedy próbujemy zrozumieć strukturę systemu IT, najbardziej rzucającym się w oczy elementem jest wygląd ekranu. Rzeczywiście, w typowym procesie tworzenia systemu, po zdefiniowaniu wymagań, takich jak identyfikacja funkcji, zwykle następuje “projektowanie ekranu” i organizacja “przejść między ekranami”. Wygląd na ekranie jest oczywiście obszarem, który jest łatwo zauważalny dla użytkowników zamawiających rozwój systemu, a także obszarem, w którym komunikacja między użytkownikami a dostawcami jest najbardziej intensywna. Poniższy artykuł wyjaśnia “obowiązek współpracy”, który użytkownik musi ponieść wobec dostawcy w celu osiągnięcia celów projektu na wszystkich etapach rozwoju systemu.

https://monolith.law/corporate/user-obligatory-cooporation[ja]

W tym artykule wyjaśniamy, że jako obowiązek współpracy, który użytkownik musi ponieść wobec rozwoju systemu, jest konieczność współpracy z dostawcą, głównie na etapie projektowania podstawowego (czyli ekranu).

“Ekran” w systemie IT jest zwykle opisany zgodnie z regułami języków komputerowych, takich jak HTML i CSS. Mówiąc o “ekranie” systemu IT, używane są różne terminy, takie jak “frontend”, “UI (User Interface)”, ale głównymi punktami dyskusji są “łatwość obsługi” i “czytelność” z punktu widzenia użytkownika.

Czym jest “logika” w systemie IT

Jednakże, jeśli system IT jest oparty na “ekranie”, to jest tylko “ekranem”, który nie ma żadnego “ruchu” ani “zmiany”. Nawet jeśli przyjmujemy wejście od użytkownika i wyświetlamy wyjście na “ekranie”, proces ten obejmuje “obliczenia”.

Kompleksowe obliczenia i sterowanie są realizowane za pomocą komponentów, które są niewidoczne dla użytkownika, można by powiedzieć, że są “z tyłu systemu”. Procesy takie jak wyszukiwanie danych z ekranu, modyfikowanie danych, dodawanie lub usuwanie, są możliwe dzięki prekonfigurowanej bazie danych. Różne operacje na informacjach w bazie danych są zwykle wykonywane za pomocą języka komputerowego zwanego SQL.

Tworzenie ścieżki od przycisków umieszczonych na ekranie do wykonania potrzebnego zapytania SQL, to właśnie dzięki temu powstaje pełny obraz systemu z ruchem i zmianami.

Warto zauważyć, że rozmowy dotyczące budowy różnych logik niewidocznych z “ekranu” są często nazywane “backendem”.

Dyskusje na temat systemu oparte wyłącznie na “wyglądzie” interfejsu mogą stanowić ryzyko

Dotychczasowe wyjaśnienia stanowią podstawę struktury systemu IT (zakładając, że działa on w sieci). Zrozumienie tych kwestii ma duże znaczenie również w kontekście dyskusji prawnych, zapobiegania konfliktom w projektach, zarządzania kryzysowego itp. Konkretnie, między użytkownikami skupiającymi się wyłącznie na “wyglądzie” interfejsu, a dostawcami, którzy mają wiele ważnych zadań po stronie niewidocznej “logiki”, mogą wystąpić nieporozumienia w komunikacji.

Różnice w punktach zainteresowania użytkowników i dostawców mogą stanowić ryzyko

Na przykład, użytkownicy rozmawiający o systemie IT głównie w kontekście “interfejsu”, często nie zwracają uwagi na złożoność jego wewnętrznej struktury. Dlatego też, mogą nie zdawać sobie sprawy, jak duży wpływ na wiele procesów mogą mieć zmiany, które na pierwszy rzut oka wydają się być “drobnym dodatkiem funkcji” lub “niewielką modyfikacją specyfikacji”. Poniższy artykuł omawia typowe problemy prawne, które mogą wystąpić podczas wycofywania istniejącego systemu w trakcie rozwoju nowego systemu.

https://monolith.law/corporate/the-transition-from-the-oldsystem[ja]

W tym artykule wyjaśniamy, że często występują problemy z migracją danych do nowego systemu podczas wycofywania starego systemu. Innymi słowy, złożoność wewnętrznych mechanizmów obliczeniowych i kontrolnych, które są trudne do wyobrażenia na podstawie samego wyglądu, może stanowić źródło nieoczekiwanych problemów dla użytkowników. Ponadto, niezrozumienie “poglądów dostawcy tworzącego system” może prowadzić do sytuacji, w której pojawiają się stopniowe zmiany.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

W takich przypadkach, kiedy po fakcie nakazuje się zmianę specyfikacji lub dodanie funkcji, kwestia możliwości zwiększenia wynagrodzenia po fakcie może stać się poważnym problemem.

https://monolith.law/corporate/increase-of-estimate[ja]

Ryzyko związane z ignorowaniem “logiki” przez użytkowników

Ponadto, części systemu, które nie są widoczne dla użytkownika, mogą stać się poważnym incydentem, gdy problem zostanie odkryty. Poniżej znajduje się przykład takiej sytuacji.

Ryzyko problemów związanych z utrzymaniem i bezpieczeństwem

Do tego zalicza się sytuacje, gdy system staje się coraz wolniejszy w miarę użytkowania i ostatecznie przestaje działać, lub gdy nie można dodać nowych funkcji.

W przypadku niedociągnięć w kodzie zaimplementowanym po stronie interfejsu, istnieje metoda ataku na bezpieczeństwo, zwana “SQL Injection”, która polega na wykorzystaniu błędów w kodzie do wydobycia informacji osobistych i poufnych, które nie powinny być wyświetlane na ekranie. Poniższy artykuł omawia szczegółowo przypadki, które stały się poważnymi konfliktami z powodu takiego ataku.

https://monolith.law/corporate/risks-of-libraryuse-and-measures[ja]

Głównym tematem tego artykułu są ryzyka związane z korzystaniem z frameworków i bibliotek, ale prezentowane przykłady sądowe dotyczą przypadków ataków na podatności za pomocą SQL Injection.

Ryzyko braku nadzoru nad pracą operatorów systemu

Ignorowanie “logiki” systemu przez użytkowników może prowadzić do problemów z nadzorem nad pracą operatorów systemu. Poniższy artykuł omawia ten temat, analizując znaczenie pracy z bazami danych w kontekście “utraty danych z powodu błędu operatora”.

https://monolith.law/corporate/dataloss-risk-and-measures[ja]

Ryzyko błędnej “logiki”, mimo że system działa poprawnie na pierwszy rzut oka

Fakt, że dyskusja na temat systemu nie ogranicza się do “interfejsu”, oznacza, że nawet jeśli system działa poprawnie na pierwszy rzut oka, jego “logika” może być błędna. Może to wyjść na jaw niespodziewanie podczas wykonywania zadań nieregularnych, takich jak “raz na pół roku” lub “raz w roku”.

W takich przypadkach, jeśli po dostarczeniu systemu odkryte zostaną błędy, problem prawny staje się kwestią odpowiedzialności za wady (a nie niewykonania zobowiązań).

https://monolith.law/corporate/defect-warranty-liability[ja]

Jeśli po akceptacji systemu zostaną odkryte błędy, poniższy artykuł szczegółowo omawia możliwe środki zaradcze.

https://monolith.law/corporate/system-flaw-measure-after-acceptance[ja]

Podsumowanie

Systematyczne zrozumienie zarówno rozwoju systemów, jak i prawa

Problemy prawne związane z rozwojem systemów wymagają nie tylko identyfikacji kwestii prawnych, ale także zrozumienia, który element systemu IT jest źródłem problemu. Zarówno w kwestiach prawnych, jak i problemach systemów IT, w konfliktach pojawiających się w projektach rozwoju systemów, szczególnie ważne jest, aby nie stracić ogólnego obrazu i maksymalnie wykorzystać współpracę między różnymi branżami.