💎 Экспертиза процесса разработки и использования программного обеспечения

🚨 Введение: почему бизнесу нужна независимая экспертиза ПО

Споры между заказчиками и разработчиками программного обеспечения — одни из самых сложных в арбитражной практике. Причины: техническая сложность объектов спора (код, архитектура, базы данных), возможность скрытых дефектов, асимметрия информации (разработчик знает о недостатках больше, чем заказчик). Независимая экспертиза ПО позволяет объективно оценить качество продукта, процент готовности, обоснованность сроков и стоимости, а также установить факты неправомерного использования интеллектуальной собственности.
Ниже представлены ответы на частые вопросы об экспертизе процесса разработки и использования ПО.

Раздел 1. Оценка процента готовности ПО и стоимости устранения недостатков 📊

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

📌 Ответ: Да, это одна из ключевых задач экспертизы разработки ПО. Эксперт анализирует:

Техническое задание (ТЗ) – сколько функций было заказано и с какими характеристиками.
Исходный код – какие функции реализованы фактически, а какие отсутствуют или реализованы частично.
Документацию (пользовательскую, техническую) – наличие инструкций.

Методика:

Этап	Действие	Результат
1	Составление карты функций (Feature Map) по ТЗ.	Перечень из N функций с приоритетами (Критично / Важно / Желательно).
2	Анализ кода и тестирование.	Определение, какие функции работают корректно / частично / отсутствуют.
3	Расчёт процента готовности.	На основе весов (weight) функций. Если ТЗ нечисловое, эксперт использует экспертный метод.
4	Оценка стоимости устранения недостатков.	Эксперт рассчитывает трудозатраты (человеко-часы) на исправление ошибок и доработку отсутствующего функционала, умножает на рыночную ставку разработчика.

Кейс № 1. Определение процента готовности ERP-системы

Ситуация: Заказчик вложил 5 млн руб. в разработку ERP-системы. Подрядчик объявил о готовности 95%. Заказчик сомневался, так как система постоянно «падала».

Действия эксперта: Эксперт проанализировал ТЗ (200 функций) и код. Оказалось, что из 200 функций:

90 работают корректно (45%).
60 работают с ошибками (30%).
50 не реализованы (25%).
Общий процент готовности (взвешенный по сложности) – 52%. Стоимость устранения недостатков – 2,3 млн руб.

Результат: Суд снизил цену договора на сумму устранения недостатков и взыскал её с подрядчика. Экспертиза стоила 180 000 руб., окупилась в 12 раз.

Раздел 2. Классификация ошибок: критические vs мелкие недочёты ⚠️

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

Эксперт классифицирует ошибки по следующим критериям:

Уровень критичности	Определение	Пример
Critical (Критическая)	Без исправления невозможно использовать ПО для основных бизнес-целей.	Невозможно оформить заказ (кнопка не работает). Потеря данных (перезаписываются). Уязвимость, позволяющая украсть пароли (SQL-инъекция).
Major (Значительная)	Существенно затрудняет работу, но есть обходные пути.	Ошибка в отчёте (цифры не сходятся, но можно выгрузить из другой системы).
Minor (Незначительная)	Косметические дефекты, не влияющие на функционал.	Неверное выравнивание текста. Опечатка в интерфейсе.
Trivial (Косметическая)	Не влияет на работу.	Незначительная опечатка в логе.

Кейс № 2. Ошибка уровня Critical – потеря данных

Ситуация: В CRM-системе при редактировании контрагента иногда пропадал его ИНН. Подрядчик утверждал, что это «мелкий баг». Заказчик заказал экспертизу.

Действия эксперта: Эксперт обнаружил, что потеря ИНН происходила при параллельном редактировании одним пользователем двух вкладок (race condition). Это приводило к нарушению целостности данных. Уязвимость классифицирована как Critical, так как без ИНН невозможно выставить счёт, что блокирует бизнес-процесс.

Результат: Суд обязал подрядчика устранить ошибку за свой счёт, а также компенсировать убытки (штрафы контрагентам из-за задержки счетов) – 450 000 руб.

Раздел 3. Доказательство незаконного использования исходного кода 🕵️

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

📌 Ответ: Да. Экспертиза плагиата исходного кода может доказать факт копирования даже если код был изменён, переменные переименованы, структура перестроена.

Методы эксперта:

Метод	Описание
Сравнение AST (Abstract Syntax Trees – абстрактное синтаксическое дерево).	Сравнивается не текст, а структура (дерево) программы, которую гораздо сложнее изменить.
Поиск уникальных «магических чисел» (magic numbers).	Если у вас в коде есть число 3.141592653589793 (основываясь на π), и у конкурента оно встречается в том же контексте — это признак копирования.
Анализ одинаковых ошибок (багов).	Если у вас была глупая ошибка (например, if (x = 5) вместо ==), и она же присутствует у конкурента — это практически неопровержимое доказательство.

Кейс № 3. Доказательство копирования через анализ одинаковых багов

Ситуация: Бывший разработчик уволился и устроился к конкуренту. Через год конкурент выпустил ПО с функционалом, подозрительно напоминающим код компании.

Действия эксперта: Эксперт сравнил исходный код (был доступен) и бинарный файл конкурента (дизассемблировал). Обнаружена уникальная ошибка: при обработке массива индексы сдвигались на 1 из-за опечатки (писатель i+1 вместо i. Та же ошибка была в оригинале и исправлена через год. Конкурент скопировал старую версию с ошибкой.

Результат: Суд признал нарушение авторских прав, взыскал с конкурента компенсацию 1,5 млн руб. (ст. 1301 ГК РФ). Экспертиза (250 000 руб.) включена в судебные издержки.

Раздел 4. Выявление необоснованного удорожания и манипуляции со сроками 💸

Может ли независимая экспертиза разработки ПО выявить факты необоснованного удорожания проекта или манипуляции со сроками со стороны подрядчика?

Да, экспертиза может разоблачить:

Манипуляция	Как проверяется
Завышение трудозатрат (человеко-часов).	Эксперт сравнивает сложность задач с отраслевыми нормами (функциональные точки – Function Points, COCOMO II). Если подрядчик заявил 1000 часов на то, что обычно делается за 200, это необоснованно.
Сдвиг сроков без объективных причин.	Анализ истории Git-коммитов: если разработка велась вяло (редкие коммиты), а подрядчик ссылался на «высокую загрузку», это не соответствует действительности.
Двойная оплата за одни и те же работы.	Эксперт сравнивает акты выполненных работ и код — повторяются ли одни и те же модули.

Кейс № 4. Выявление завышения трудозатрат (подрядчик накрутил 300 часов)

Ситуация: Подрядчик выставил счёт на 500 часов разработки (3,5 млн руб.). Заказчик заказал экспертизу, так как проект был небольшой (мобильное приложение – то-do лист).

Действия эксперта: Эксперт проанализировал Git-репозиторий (коммиты) и оценил функциональные точки. Реальное время – 180 часов (1,26 млн руб.). Обнаружил, что подрядчик дублировал уже существующие библиотеки (из open-source) и выставил их как свою работу.

Результат: Суд удовлетворил иск о возврате 2,24 млн руб. (переплата). Подрядчик также оштрафован по ст. 159 УК РФ (мошенничество). Экспертиза (90 000 руб.) окупилась.

Раздел 5. Риски для долгосрочной поддержки и безопасности 🔒

Какие потенциальные риски для безопасности данных и долгосрочной поддержки может выявить экспертиза процесса разработки ПО, если мы планируем использовать его годы?

Экспертиза выявляет «технический долг» (technical debt) – накопленные недостатки, которые увеличат стоимость поддержки в будущем.

Риск	Пример	Как выявляется
Отсутствие документации (comment-free code).	Код не содержит комментариев, нечитаем.	Статический анализ (утилита PHPMD, SonarQube).
Нарушение архитектурных паттернов (cyber-spaghetti – «спагетти-код»).	Всё смешано: бизнес-логика, код интерфейса, SQL-запросы.	Ручной ревью (code review).
Использование устаревших библиотек с известными уязвимостями (CVE).	Библиотека log4j версии 2.14.1 (уязвимость Log4Shell).	Сканер зависимостей (OWASP Dependency Check).
Отсутствие unit-тестов.	Нет автоматических тестов, любое изменение может сломать существующий функционал.	Анализ покрытия кода тестами (coverage).

Кейс № 5. Нарушение архитектуры привело к невозможности масштабирования

Ситуация: Компания разработала интернет-магазин на кастомном фреймворке. Через 2 года бизнес вырос, нагрузка увеличилась. Магазин начал тормозить.

Действия эксперта: Эксперт выявил, что код представляет собой «монолит», где логика запросов к БД перемешана с HTML-шаблонами. Невозможно масштабировать отдельные функции. Переписывание заняло бы 2 года.

Результат: Компания признала, что ошибка была на этапе выбора подрядчика. Экспертиза (120 000 руб.) помогла осознать необходимость рефакторинга (частичной переработки) и инвестиций в новую архитектуру.

Раздел 6. Оценка производительности и чрезмерного потребления ресурсов 🐢

Как экспертная оценка ПО помогает доказать низкую производительность программного обеспечения или чрезмерное потребление ресурсов, если это не влияет на основной функционал, но тормозит бизнес-процессы?

Низкая производительность (медленные отчёты, загрузка страниц) не является «критической ошибкой», но приводит к снижению производительности труда (продавцы ждут по 10 секунд).

Что измеряет эксперт:

Параметр	Инструмент	Норма
Время загрузки страницы (First Contentful Paint – время до первого отображения контента).	Lighthouse (DevTools).	Не более 2,5 с.
Время выполнения отчёта (в БД).	Slow Query Log.	Не более 5-10 с (зависит от объёма данных).
Потребление оперативной памяти (RAM) и центрального процессора (CPU).	Windows Task Manager / top / htop.	Не более 80% в пик.

Кейс № 6. Медленный отчёт о продажах (занимал 3 минуты)

Ситуация: Внедрена CRM, но отчёт о продажах за месяц формировался 3 минуты (вместо обещанных 5 секунд). Подрядчик не признавал проблему.

Действия эксперта: Эксперт выявил в логах медленных запросов (slow query log) ошибку: отсутствовал индекс по полю date. Добавление индекса сократило время до 0,2 секунды.

Результат: Суд снизил стоимость внедрения на 250 000 руб. (пропорционально). Экспертиза (65 000 руб.) окупилась.

Раздел 7. Сбои из-за несовместимости сторонних модулей 🔌

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

Интеграции (с 1С, сайтом, телефонией, платёжными шлюзами) — частое узкое место.

Методика:

Шаг	Действие
1	Эксперт анализирует версии ПО (например, модуль интеграции с 1С).
2	Тестирует интеграцию в изолированной среде, меняя конфигурацию.
3	Смотрит логи ошибок (например, «Version mismatch: expected 8.3, got 8.2»).
4	Делает вывод: несовместимость по вине разработчика (не протестировал) или заказчика (сам обновил 1С без уведомления).

Кейс № 7. Интеграция с 1С перестала работать после обновления

Ситуация: Интернет-магазин обновил 1С с версии 8.3.10 до 8.3.22. Выгрузка заказов перестала работать. Подрядчик сказал, что «виноват заказчик».

Действия эксперта: Эксперт проанализировал API-модуль интеграции. Обнаружил, что код содержал недокументированные вызовы устаревших методов. При обновлении 1С эти методы были удалены.

Результат: Суд признал вину подрядчика (код не должен был использовать deprecated API). Подрядчик обязан исправить интеграцию бесплатно.

Раздел 8. Установление авторства модулей при работе нескольких разработчиков 👥

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

В спорах о том, кто создал интеллектуальную собственность, помогает анализ:

Источник	Данные
Git-коммиты (система контроля версий).	Автор, дата, изменённые строки кода.
Стиль кодирования (именование переменных, форматирование, структура комментариев).	Эксперт-лингвист может сравнить «почерк» программиста.
Метаданные файлов (дата создания, автор в свойствах).	В .csproj, .java, *.py может быть указан пользователь.

Кейс № 8. Спор о праве на модуль оплаты (бывший сотрудник требовал признать себя автором)

Ситуация: Бывший сотрудник подал иск о признании авторства на модуль оплаты, созданный в компании.

Действия эксперта: Эксперт изучил Git-коммиты. Установил, что модуль оплаты был написан тремя разработчиками, включая истца, но истец внёс лишь 20% строк, а ключевые алгоритмы — другими.

Результат: Суд признал соавторство, но без выплаты компенсации (так как алгоритмы были служебным заданием). Экспертиза (80 000 руб.) оплачена из средств истца.

Заключение 🎯

Независимая экспертиза процесса разработки и использования ПО помогает: