Законодательные преимущества и недостатки различных моделей системной разработки

В подходе к проектам по разработке систем существуют определенные методологии. Обычно, когда изучаются юридические вопросы, связанные с разработкой систем, в книгах и других источниках, часто предполагается использование наиболее классического метода, известного как модель водопада. Однако методологии и модели для продвижения разработки систем не ограничиваются только моделью водопада. Например, в последнее время все чаще выбирают методологию, известную как модель Agile разработки.

В этой статье мы рассмотрим две модели – модель водопада и модель Agile разработки, сравнивая их с точки зрения юридических рисков и предотвращения споров.

Что такое модель разработки

Что такое модель водопада

Самым общим и классическим подходом к разработке систем является следующий:

• Определение требований: определение функций, которые должна иметь система, и необходимых спецификаций
• Базовый дизайн: дизайн интерфейса, переходы между экранами и т.д., в основном с точки зрения пользователя системы
• Детальный дизайн: связи между файлами программ и т.д., в основном с точки зрения разработчика системы
• Программирование и реализация: кодирование программы в соответствии с дизайн-документацией
• Тестирование: проверка, что система работает в соответствии со спецификациями, и запрос на подтверждение от пользователя

Этот подход к разработке, который стремится минимизировать обратные шаги и переходы от начала к концу, называется “моделью водопада”. Этот процесс не обязательно необходим для создания работающей системы. Однако, в разработке систем, которая часто становится проектом, в который вкладываются большие ресурсы и много времени, планирование становится важным. Поэтому, такие вопросы, как разделение этапов, упорядочение ролей и определение области ответственности каждого участника, также считаются важными.

Что такое модель Agile разработки

С другой стороны, подход к разработке не всегда подразумевает последовательное продвижение от “начала к концу”. Безусловно, важность планирования и прогнозирования в связи с характером работы не подлежит сомнению. Однако, в работе, связанной с созданием новых вещей или произведений, часто бывает невозможно составить идеальный план с самого начала. Если учесть эти аспекты, то должен быть подход, который не только следует установленному плану, но и легко адаптируется к последующим корректировкам и изменениям спецификаций, а также увеличивает количество итераций “попробовать и ошибиться”. Этот подход отражен в “модели Agile разработки”. В модели Agile разработки обычно стараются минимизировать время, затрачиваемое на подготовку детальных планов и дизайн-документов, и вместо этого повторно реализуют и тестируют очень маленькие программы, постепенно преобразуя их в большие программы и системы.

Изучение юридических вопросов проще на модели Waterfall

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

Большинство учебников написаны на основе модели Waterfall

Когда речь идет о изучении юридических вопросов, связанных с разработкой систем, или о получении юридических знаний, модель Waterfall обеспечивает большую простоту сбора информации. Большинство юридических книг, которые обсуждают разработку систем, написаны с учетом модели Waterfall. Поскольку классическая и общепринятая разработка систем основана на модели Waterfall, а Agile-разработка занимает дополнительное место и часто ограничивается кратким введением. Следовательно, при изучении юридических вопросов, связанных с разработкой систем, из книг, можно сказать, что процесс обучения проще с моделью Waterfall.

Модель Waterfall также имеет много прецедентов

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

Даже если закон не формализован, накопленные судебные решения могут устанавливаться как критерии суждения, подобно статьям закона. Это называется “теорией судебного прецедента”. Даже если это новый конфликт в области, где уже есть накопленная теория судебного прецедента, как в случае с разработкой систем, предсказание итогового исхода конфликта может стать относительно легким. В этом смысле разработка систем на основе модели Waterfall предлагает множество преимуществ.

Преимущества каждого метода разработки

Исходя из вышеизложенного, мы сравним и проанализируем преимущества и недостатки каждого метода. В первой половине мы сосредоточимся на преимуществах водопадной модели, а по мере продвижения вниз станет более понятно преимущество гибкой разработки.

Сравнение по планированию и прозрачности

В отношении планирования и прозрачности, можно сказать, что водопадная модель имеет преимущество. Независимо от того, насколько крупномасштабной будет система, она всегда будет разбита на множество этапов, которые идут “сверху вниз”. Если установить сроки для каждого этапа, его выполнение можно будет легко контролировать.

С другой стороны, гибкая разработка – это метод, который не требует больших затрат или усилий на предварительное планирование или общую концепцию, поэтому он может стать скорее импровизационным подходом.

Сравнение по ясности ролей и обязанностей каждого участника

В водопадной модели, благодаря детальному разделению этапов, есть преимущество в том, что можно четко определить роли каждого участника проекта.

С другой стороны, в гибкой разработке, разделение этапов часто становится неясным, поэтому в случае непредвиденных проблем, также становится неясным, кто должен нести ответственность.

Сравнение по удобству крупномасштабной разработки

Водопадная модель, которая превосходит по планированию и определению ролей, становится еще более выгодной при крупномасштабной разработке. Даже если вы организуете большое количество персонала, разделение этапов на подзадачи позволяет сократить затраты на координацию между людьми.

С другой стороны, гибкая модель разработки обычно не подходит для крупномасштабной разработки. Этот подход, который приоритизирует скорость начала работы над планированием и определением ролей, трудно применять в ситуациях, где существуют опасения относительно срыва сроков.

Сравнение по скорости и эффективности

Гибкая разработка начинается быстрее

В отношении скорости, с которой пользовательский запрос на функцию реализуется, гибкая модель разработки имеет преимущество. Это потому, что в водопадной модели обычно отдельные этапы выполняются разными людьми, что увеличивает время на внутреннее общение. Этот фактор также связан с тем, что модель слабо приспособлена к последующим запросам на изменение спецификаций.

С другой стороны, в гибкой модели разработки можно ожидать быстрого начала и выполнения работы без посредников. Это тесно связано с главным преимуществом гибкой модели разработки – легкостью внесения изменений в спецификации после начала работы. Однако, даже в гибкой модели разработки, если продолжать бездумно отвечать на запросы на изменение спецификаций и дополнительную разработку, это может привести к риску “сгорания” проекта. В этом смысле, ключом к успеху в гибкой разработке систем является управление изменениями. Подробное объяснение управления изменениями приведено в следующей статье.

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

Водопадная модель менее подвержена срыву в середине процесса

С другой стороны, при сравнении с точки зрения скорости и эффективности, важно также рассмотреть долгосрочную перспективу. Если рассматривать риск того, что проект “сгорит” на полпути и прогресс остановится, водопадная модель имеет преимущество. Главный риск, который может привести к тому, что проект остановится на полпути, – это недостаток общения между пользователем и поставщиком. Водопадная модель, которая легко определяет разделение обязанностей между обеими сторонами, имеет преимущество в этом отношении.

Гибкая разработка облегчает процесс приемки

Однако, с точки зрения легкости ведения переговоров на этапе приемки, гибкая модель разработки имеет некоторое преимущество. Это потому, что предполагается, что пользователь и поставщик будут делиться информацией на протяжении всего процесса разработки системы. Это позволяет снизить риск того, что различия в понимании между обеими сторонами внезапно проявятся при просмотре окончательного продукта. Подробное объяснение этапа приемки разработки систем и связанных с ним юридических вопросов приведено в следующей статье.

Заключение

Таким образом, сравнивая, можно увидеть, что в целом модель Waterfall способствует усилению управления, а модель Agile разработки акцентирует внимание на скорости начала и выполнения работ. Кроме того, подробно рассмотрены юридические вопросы, связанные с разработкой систем на основе модели Agile разработки, в следующей статье.

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