Про правові питання, пов'язані з базою даних IT-системи

При вивченні правових питань, пов’язаних з IT-системами, вимагається систематичні знання законодавства, але водночас важливо знати про складові IT-систем. У цій статті ми розглянемо, з яких компонентів складається IT-система, як ці компоненти взаємодіють між собою, а також проаналізуємо правові питання, які тісно пов’язані з базами даних, які часто непомітні для користувача.

IT-системи складаються з “екрану” та “логіки”

Що таке “екран” в IT-системах

Коли ми намагаємося зрозуміти структуру IT-системи, найбільш помітним є зовнішній вигляд екрану. Дійсно, в загальному процесі розробки системи, після “визначення вимог”, де відбувається виявлення функцій, зазвичай відбувається “дизайн екрану” та організація “переходів між екранами”. Цей зовнішній вигляд на екрані – це область, яка, безумовно, помітна для користувача, який замовляє розробку системи, а також область, де комунікація між користувачем та вендором найчастіше відбувається. У статті нижче пояснюється “обов’язок співпраці”, який користувач повинен виконувати для досягнення цілей проекту на всіх етапах розробки системи.

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

У цій статті, ми головним чином пояснюємо, що користувач має обов’язок співпрацювати з вендором на етапах, таких як базовий дизайн (тобто екран).

“Екран” в IT-системах зазвичай описується за правилами мов програмування, таких як HTML та CSS. Розмови про “екран” IT-системи включають різні назви, такі як “фронтенд”, “UI (інтерфейс користувача)”, але головними питаннями є “зручність використання”, “читабельність” та ін.

Що таке “логіка” в IT-системах

Однак, якщо IT-система базується на “екрані”, то вона є лише “екраном”, який не має жодного “руху” або “зміни”. Навіть якщо прийом вводу від користувача та відображення виводу відбувається на “екрані”, в цьому процесі є “обчислювальна обробка”.

Складні обчислення та контроль виконуються за допомогою компонентів, які не видно користувачу, які можна назвати “задньою стороною системи”. Обробка, така як пошук даних з екрану, зміна даних, додавання або видалення, можлива тільки завдяки попередньо створеній базі даних. Різні обробки інформації в базі даних зазвичай виконуються мовою програмування, відомою як SQL.

Створення шляху від кнопки, розміщеної на екрані, до виконання необхідного SQL-запиту, завершує створення загальної картини системи з рухом та змінами.

Варто зазначити, що розмови, пов’язані з побудовою різних логік, які не видно з “екрану”, часто називають “бекендом”.

Ризиком є обговорення системи лише з точки зору “зовнішнього вигляду” екрану

Досі наведені пояснення становлять основу структури IT-системи (з урахуванням її роботи в Інтернеті). Розуміння цих питань має велике значення для обговорення законодавства, запобігання конфліктів у проектах, управління кризами тощо. Конкретно, можливі непорозуміння в комунікації між користувачами, які зосереджуються лише на “зовнішньому вигляді” екрану, та вендорами, які виконують важливі завдання на “логічному” рівні, який не видно оку.

Різниця в точках зору користувачів та вендорів може стати ризиком

Наприклад, користувачі, які обговорюють IT-системи, зосереджуючись на “екрані”, часто не звертають увагу на складність внутрішньої структури. Саме тому вони можуть не розуміти, наскільки великий вплив можуть мати такі здається незначні зміни, як “додавання невеликої функції” або “невелика зміна специфікації”. Наприклад, в наступній статті ми розглядаємо юридичні проблеми, які часто виникають при ліквідації існуючої системи, яка в даний час використовується, в рамках проекту розробки нової системи.

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

Тут ми пояснюємо, що при ліквідації старої системи часто виникають проблеми з перенесенням даних до нової системи. Тобто, складність внутрішніх обчислень та механізмів контролю, яку важко уявити зовні, може стати несподіваним джерелом проблем для користувачів. Крім того, незрозумілість “почуттів вендора, який створює систему” може призвести до ситуації, коли зміни вносяться поступово після завершення проекту.

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

У випадках, коли після завершення проекту вимагаються зміни специфікацій або додавання функцій, може виникнути серйозне питання про можливість збільшення винагороди.

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

Ризик недбалого ставлення користувачів до “логіки” на задньому плані

Крім того, часто проблеми, які не можуть бути спостережені користувачами, можуть перетворитися на великі інциденти, коли вони виявляються. Нижче наведено декілька прикладів таких ситуацій.

Ризик виникнення проблем з підтримкою та безпекою

Це може стосуватися ситуацій, коли неможливо реалізувати додаткові функції, або коли система поступово стає повільнішою в процесі використання і в кінцевому результаті перестає працювати.

Також, через недоліки в коді, реалізованому на стороні екрану, можуть відбуватися атаки на безпеку, такі як “SQL Injection”, які використовуються для витягування персональної та конфіденційної інформації, яка не повинна відображатися на екрані. Детальніше про випадки, коли це стало причиною серйозних конфліктів, описано в наступній статті.

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

Головна тема цієї статті – ризики, пов’язані з використанням фреймворків та бібліотек, але приклади судових рішень, які тут наведено, стосуються випадків атак на вразливості за допомогою SQL Injection.

Ризик втрати контролю над роботою оператора

Недбале ставлення користувачів IT-систем до “логіки” на задньому плані може призвести до проблем з контролем над роботою оператора IT-систем. У статті нижче ми розглядаємо важливість роботи з базами даних на прикладі теми “Втрата даних через недбалість оператора”.

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

Ризик помилки в логіці, навіть якщо система працює правильно на поверхні

Те, що розмова про систему не обмежується “екраном”, означає, що навіть якщо система здається правильною на поверхні, її “логіка” може бути помилковою. Це може стати очевидним несподівано під час нерегулярних операцій, таких як “один раз на півроку” або “один раз на рік”, навіть якщо це не стало очевидним у повсякденних основних операціях.

У таких випадках, це стає проблемою відповідальності за дефекти, а не за невиконання зобов’язань, з точки зору закону, щодо системи, яка була доставлена, але пізніше виявилися недоліки.

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

Якщо після прийому виявляється дефект, ми детально пояснюємо процес в наступній статті.

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

Підсумки

Систематичне розуміння розробки систем та юридичних питань

Юридичні проблеми, пов’язані з розробкою систем, вимагають не тільки визначення юридичних аспектів, але й розуміння того, які компоненти IT-системи викликали ці проблеми. Це важливо як для юридичних питань, так і для проблем IT-систем. У конфліктах, що виникають під час проектів розробки систем, особливо важливо не втратити з виду загальну картину та докласти всіх зусиль для співпраці між різними галузями.