Судебная · 2025 · № 932

Экспертиза ПО в споре с разработчиком: как проверяли соответствие договору и работоспособность для суда

Заказчик отказался принимать ПО, утверждая, что оно не соответствует договору и неработоспособно. Разработчик настаивал на выполнении обязательств.

Суть спора

Заказчик утверждал, что разработанное ПО не соответствует договору и неработоспособно. Разработчик настаивал на полном исполнении обязательств и требовал оплаты.

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

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

Объект исследования

Переданная версия программного обеспечения (веб-сервис)

Исходный код и история изменений репозитория

Договор, техническое задание и проектная документация

Логи сборки, развёртывания и тестовые данные

Тестовая среда развёртывания системы

Вопросы эксперту

Соответствует ли разработанное ПО условиям договора и техническому заданию?

Какие функции реализованы, а какие отсутствуют?

Возможно ли использование ПО по назначению в текущем виде?

Являются ли выявленные дефекты существенными?

Соответствуют ли фактические сроки и объём работ условиям договора?

Методики и инструменты

Фиксация версии и контроль целостности по хеш-суммам
Развёртывание ПО в изолированной тестовой среде
Формирование матрицы соответствия требований договора и ТЗ
Функциональное тестирование ключевых сценариев
Анализ истории изменений репозитория
Анализ логов сборки и развёртывания

Ход исследования

Этап 1 · Фиксация версии · Фиксация переданной версии ПО и исходного кода, расчёт хеш-сумм, развёртывание системы в изолированной тестовой среде без изменения данных.

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

Этап 3 · Функциональное тестирование · Поэтапная проверка ключевых сценариев, фиксация дефектов и оценка их влияния на возможность эксплуатации, с приложением снимков экрана.

Этап 4 · История изменений и сроки · Анализ истории изменений репозитория и логов сборки для оценки фактических сроков и объёма выполненных работ относительно дат сдачи.

Этап 5 · Сведение и заключение · Сведение результатов по каждому требованию, оценка существенности дефектов и оформление заключения с выводами и приложениями.

Что установили

Соответствие ТЗ

Часть функций реализована, отдельные обязательные требования договора не выполнены.

Существенные дефекты

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

Работоспособность

В текущем виде ПО не обеспечивает выполнение заявленных операций без доработки.

Выводы эксперта

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

«Спор перестал быть спором о словах: по каждому требованию договора зафиксировано, реализовано оно или нет и насколько дефект мешает эксплуатации.»

Эксперт по программному обеспечению

Результат для клиента

Заключение легло в основу правовой позиции заказчика: проверяемо зафиксированы несоответствия и существенные дефекты, что стало основанием для требований об устранении недостатков и пересмотра расчётов по договору.

Как работали по этому делу

Как считали

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

Что не получилось с первого раза

Изначально считали по актам, которые стороны подписывали помесячно, но результат не сошёлся с фактическим состоянием продукта. Проверка показала, что часть актов подписана авансом, до фактической сдачи работ. Мы перестроили расчёт от реального состояния кода и продукта на дату спора, а расхождение с актами вынесли отдельным разделом: это оказалось важным обстоятельством для суда.

Из чего сложился срок

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

Чем мерили результат

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

Досье дела и эксперты

№ 932 · 2025

Карточка экспертизы

Тип	Судебная экспертиза
Суд	Арбитражный суд
Дело	№ дела по запросу
Стороны	Заказчик / разработчик, анонимизировано
Объект	Программное обеспечение (веб-сервис), исходный код, проектная документация
Срок	20 рабочих дней
Стоимость	По договору, не раскрывается (NDA)
Год	2025