O právních problémech spojených s databází IT systémů

Při poznávání právních problémů souvisejících s IT systémy je vyžadována systematická znalost práva, ale zároveň je důležité znát také složky IT systémů. V tomto článku se zabýváme tím, jak jsou IT systémy složeny z různých komponent a jak tyto komponenty spolupracují, aby systém fungoval. Zároveň vysvětlujeme právní problémy, které jsou zvláště spojeny s databázemi, které jsou pro uživatele obtížně viditelné.

IT systémy se skládají z “obrazovky” a “logiky”

Co je “obrazovka” v IT systému

Když se snažíme pochopit strukturu IT systému, to, co nás nejvíce zaujme, je pravděpodobně vzhled obrazovky. Skutečně, v běžném procesu vývoje systému, po “definici požadavků”, kde se provádí identifikace funkcí atd., následuje obvykle “návrh obrazovky” a organizace “přechodů obrazovky”. Tento vzhled na obrazovce je oblastí, která je samozřejmě viditelná pro uživatele, kteří objednávají vývoj systému, a je také oblastí, kde je komunikace mezi uživatelem a dodavatelem nejčastěji prováděna. Následující článek vysvětluje “povinnost spolupráce”, kterou uživatelé nesou vůči dodavateli v celém procesu vývoje systému, s cílem dosáhnout úspěchu projektu.

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

Tento článek vysvětluje, že uživatelé mají povinnost spolupracovat při vývoji systému, zejména v fázích jako je základní návrh (tj. obrazovka), kde je třeba spolupracovat s dodavatelem.

“Obrazovka” v IT systému je obvykle popsána podle pravidel počítačových jazyků jako je HTML a CSS. Hovoříme-li o “obrazovce” IT systému, používají se různé názvy, jako je “frontend”, “UI (User Interface)”, ale hlavními tématy jsou “pohodlí ovládání” a “čitelnost” z pohledu uživatele.

Co je “logika” v IT systému

Avšak, pokud by IT systém byl založen pouze na “obrazovce”, byla by to jen “obrazovka”, která nemá žádný “pohyb” nebo “změnu”. I když se přijímání vstupů od uživatele a zobrazení výstupů provádí na “obrazovce”, v tomto procesu existuje “výpočetní zpracování”.

Toto složité výpočty a řízení jsou prováděny pomocí komponent, které nejsou viditelné uživateli, a které bychom mohli nazvat “zadní stranou systému”. Zpracování, jako je vyhledávání dat z obrazovky, přepisování dat, přidávání nebo mazání, je možné díky předem vytvořené databázi. Různé zpracování informací v databázi se obvykle provádí v počítačovém jazyce zvaném SQL.

Vytvoření cesty od tlačítka umístěného na obrazovce k provedení potřebného SQL příkazu, toto vytváří celkový obraz systému s pohybem a změnou.

Je třeba poznamenat, že diskuse o sestavení různých logik, které nejsou viditelné z “obrazovky”, jsou často označovány jako “backend”.

Riziko spočívá v tom, že se o systému diskutuje pouze z hlediska “vzhledu” na obrazovce

Dosavadní výklad tvoří základ pro strukturu IT systému (předpokládá se, že bude fungovat na webu). Porozumění těmto záležitostem má velký význam i z hlediska právních diskusí, prevence konfliktů v projektech, krizového řízení atd. Konkrétně může dojít k nedorozuměním v komunikaci mezi uživateli, kteří se zaměřují pouze na “vzhled” na obrazovce, a dodavateli, kteří se starají o důležité úkoly na straně “logiky”, která není vidět.

Riziko spočívá v tom, že uživatelé a dodavatelé mají zcela odlišné obavy

Například uživatelé, kteří se při diskusi o IT systémech soustředí především na “obrazovku”, často nevěnují pozornost složitosti vnitřní struktury systému. Právě proto nemusí být schopni pochopit, jak mohou zdánlivě malé přídavky funkcí nebo drobné změny specifikací ovlivnit mnoho procesů. Například v následujícím článku se zabýváme právními problémy, které často vznikají při likvidaci stávajících systémů v rámci projektu vývoje nového systému.

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

Zde vysvětlujeme, že při přechodu dat z původního systému do nového často dochází k problémům. Jinými slovy, složitost vnitřních výpočtů a kontrolních mechanismů, kterou si uživatelé nemohou představit, může vést k neočekávaným problémům. Navíc, pokud uživatelé nerozumí “pocitům dodavatelů, kteří systém vytvářejí”, mohou se objevit situace, kdy se postupně objevují změny po dokončení projektu.

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

V případech, kdy jsou po dokončení projektu nařízeny změny specifikací nebo přidání funkcí, může se stát závažným problémem, zda je možné zvýšit odměnu po dokončení projektu.

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

Riziko nevědomosti uživatelů o “logice” na pozadí

Navíc, části, které nejsou viditelné uživateli, mohou v případě vzniku problémů vést k velkým incidentům. Následující jsou příklady takových situací.

Riziko vzniku problémů v oblasti údržby a bezpečnosti

Toto se týká situací, kdy nelze implementovat další funkce, postupně se zpomaluje provoz a nakonec se systém zastaví.

Dále, v případě nedostatků v kódu implementovaném na straně obrazovky, existují metody bezpečnostních útoků, které se nazývají “SQL Injection”, které odebírají osobní a důvěrné informace, které by neměly být zobrazeny na obrazovce. Podrobnosti o případech, které se staly vážnými spory kvůli tomuto, jsou podrobně popsány v následujícím článku.

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

Hlavním tématem tohoto článku je riziko spojené s používáním frameworků a knihoven, ale uvedené soudní případy se týkají případů útoků na zranitelnosti pomocí SQL Injection.

Riziko, že správa nebude schopna dosáhnout práce správce systému

Skutečnost, že uživatelé IT systému jsou lhostejní k “logice” na pozadí, vede k problému, že správa se stává obtížnější v práci správce IT systému. V souvislosti s tímto obsahem je v následujícím článku vysvětlena důležitost práce s databázemi na téma “ztráta dat kvůli nedbalosti správce”.

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

Riziko, že i když systém správně funguje na povrchu, logika může být chybná

Skutečnost, že diskuse o systému nepřesahuje “obrazovku”, znamená, že i když systém na povrchu správně funguje, jeho “logika” může být chybná. To může být náhle odhaleno v nepravidelných operacích, jako je “jednou za půl roku” nebo “jednou ročně”, i když to nebylo zřejmé v každodenních základních operacích.

V takových případech se jedná o “případy, kdy byly po dokončení dodání systému zjištěny nedostatky”, a z právního hlediska se jedná o problém záruky za vady, nikoli o nesplnění závazků.

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

Jako opatření pro případ, že by po přijetí byly zjištěny chyby, je postup podrobně vysvětlen v následujícím článku.

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

Shrnutí

Systémový vývoj a právní záležitosti, systematické pochopení obou

Právní problémy související s vývojem systémů jsou důležité pro pochopení, která součást IT systému je zdrojem problému, a to ještě před identifikací právních otázek. Ať už jde o právní problémy nebo problémy IT systému, v konfliktech vznikajících v projektech vývoje systémů je důležité neztratit z očí celkový obrázek a věnovat zvláštní úsilí spolupráci mezi různými obory.