Как идентифицировать передаваемый релиз ПО в процедуре приёмки?

Для приёмки нужна определённая версия результата, а не только акт. Состав признаков зависит от способа поставки и процедуры проверки.

Civius, юридическая компания Софья Демидова, юрист; правовая позиция на 2026-08-17

Короткий ответ

Определите релиз так, чтобы обе стороны проверяли одну и ту же версию. В рекомендации МосЛигал от 17 августа 2026 года названы версия, ветка репозитория, среда, документация, сценарии и данные для тестов. Конкретный набор нужно адаптировать к поставке.

Один акт с фразой «программа передана» может не объяснять, какой результат заказчик должен проверять и к чему относятся замечания.

Что закрепить при передаче

Укажите название, номер или иной определённый признак версии. Если передаётся код, обозначьте ветку репозитория и состояние, относящееся к сдаче. Если передаётся сборка или облачный доступ, определите соответствующий пакет или рабочую среду.

Свяжите документацию с этой версией. Инструкция к более ранней сборке может создавать ложное впечатление дефекта или скрывать отсутствие нужной функции.

Как воспроизводить проверку

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

Эти параметры должны совпадать с порядком приёмки разработки. В замечаниях полезно сохранять связь с конкретным релизом и сценарием, а после исправления – с новой переданной версией.

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

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