О правовых проблемах, связанных с базой данных 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-инъекции”, которые используются для извлечения личной и конфиденциальной информации, которая не должна отображаться на экране, из-за недостатков в коде, реализованном на стороне экрана. Подробнее об этом и о случаях, когда это стало причиной серьезных споров, мы рассказываем в следующей статье.

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

Хотя основная тема этой статьи – риски, связанные с использованием фреймворков и библиотек, приведенные примеры судебных дел касаются атак на уязвимости с использованием SQL-инъекций.

Риск отсутствия контроля над работой операторов

Невнимательность пользователей 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-системой, в конфликтах, возникающих в проектах по разработке систем, особенно важно не терять общую картину и прилагать все усилия для сотрудничества между различными отраслями.