Юридичні переваги та недоліки розробки систем відповідно до моделі розробки

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

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

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

Що таке модель “водоспаду”?

Найбільш загальний та класичний спосіб розробки системи включає наступні етапи:

• Визначення вимог: виявлення функцій, які має мати майбутня система, та необхідних специфікацій
• Базовий дизайн: дизайн інтерфейсу, переходи між екранами тощо, в основному з точки зору користувача, який буде керувати системою
• Детальний дизайн: зв’язки між програмними файлами тощо, в основному з точки зору розробника системи
• Програмування: кодування програми відповідно до дизайн-документа
• Тестування: перевірка, чи відповідає продукт специфікаціям, та залучення користувачів для перевірки

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

Що таке модель аджайл-розробки?

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

Вивчення правових питань легше з моделлю Waterfall

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

Більшість довідників написані на основі моделі Waterfall

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

Багато судових прецедентів також пов’язані з моделлю Waterfall

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

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

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

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

Порівняння за плановістю та прозорістю

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

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

Порівняння за зрозумілістю окремих ролей та областей відповідальності

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

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

Порівняння за легкістю великомасштабної розробки

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

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

Порівняння за швидкістю та ефективністю

Гнучка розробка починається швидше

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

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

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

Водограйна модель менш схильна до зупинки на середині

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

Гнучка розробка легше просувається на етапі прийому

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

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

Підсумки

Порівнюючи таким чином, можна зробити висновок, що модель Waterfall в цілому сприяє покращенню управління, а модель Agile розвитку акцентує увагу на швидкості виконання роботи від початку до кінця. Детальніше про правові питання, пов’язані з розробкою систем на основі моделі Agile, ви можете прочитати в наступній статті.

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