📌 Введение
- В современном мире программное обеспечение (ПО) является критически важным активом для любого бизнеса. Споры между заказчиками и разработчиками, подозрения в недобросовестной конкуренции, вопросы качества и безопасности кода требуют объективной оценки, которую может предоставить только независимая экспертиза. Данный вид экспертизы относится к области компьютерно-технических исследований и направлен на анализ процесса создания, функциональности, безопасности и соответствия программного продукта заявленным требованиям.
- Настоящая консультация подготовлена экспертами нашей организации. В статье приведены ответы на наиболее частые вопросы заказчиков, а также 10 практических кейсов из нашей экспертной деятельности.
Вопрос 1. Наша компания заказала разработку ПО, но подрядчик не выполнил свои обязательства в полном объеме. Может ли независимая экспертиза определить реальный процент готовности продукта, объем недоработок и примерную стоимость их устранения?
✅ Да, экспертиза процесса разработки программного обеспечения может определить реальный процент готовности продукта, перечислить отсутствующие или некорректно работающие функции, а также оценить стоимость их доработки. Для этого эксперт проводит сравнение фактически реализованного функционала с требованиями технического задания (ТЗ) и иной проектной документации.
Что делает эксперт:
| Этап | Действие | Результат |
| 1. Анализ документации | Изучает ТЗ, спецификации, диаграммы, макеты, протоколы испытаний (если есть). | Понимание того, что должно быть реализовано. |
| 2. Инвентаризация функций | Составляет список функций, которые должны быть в продукте по ТЗ. | Базовый перечень для сравнения. |
| 3. Тестирование реализованного ПО | Проверяет каждую функцию: работает ли она согласно ТЗ, есть ли отклонения (баги), не работает ли она вообще. | Выявление реализованных, частично реализованных и отсутствующих функций. |
| 4. Расчет процента готовности | Процент готовности = (количество полностью реализованных функций / общее количество функций по ТЗ) × 100%. | Объективный процент готовности. |
| 5. Оценка стоимости доработки | На основе трудоемкости (человеко-часы) и стоимости часа работы разработчика (рыночной, либо по договору). | Сумма в рублях для устранения недоработок. |
Результат экспертизы: Заключение, в котором указано: «Из 150 функций, предусмотренных ТЗ, реализовано полностью 90 (60%), частично — 30 (20%), не реализовано — 30 (20%). Стоимость доработки до состояния, соответствующего ТЗ, составляет 1 200 000 рублей». Это заключение может быть использовано для требования соразмерного уменьшения цены (ст. 475 ГК РФ) либо расторжения договора (ст. 450 ГК РФ).
🔹 Кейс № 1. Спор о готовности ERP-модуля для производственной компании
Обстоятельства: ООО «ПромТех» заказало разработку модуля «Управление производством» для 1С:ERP. Договор — 3,5 млн руб., срок — 6 месяцев. Подрядчик сдал работу с задержкой на 2 месяца. При приемке заказчик обнаружил, что модуль не рассчитывает себестоимость продукции (ошибки в формулах), не формирует производственные отчеты, не ведет складской учет полуфабрикатов. Подрядчик утверждал, что «все работает, нужно просто обучить сотрудников». Заказчик обратился к нам для экспертизы.
Проведенная экспертиза:
Эксперт проанализировал ТЗ (120 страниц), исходный код доработок и провел функциональное тестирование в тестовом контуре. Выявлено:
Из 45 функций, указанных в ТЗ, полностью реализовано 20 (44%).
Частично реализовано (с ошибками) — 10 функций (22%).
Не реализовано — 15 функций (33%), в том числе расчет себестоимости и производственные отчеты.
Эксперт также провел оценку стоимости доработки (по рыночным ценам на разработку 1С в регионе): 950 000 руб. и 2,5 месяца.
Результат: Заказчик расторг договор (существенное нарушение — ст. 450, 475 ГК РФ) и взыскал с подрядчика уплаченные 2 млн руб. (аванс), а также убытки в размере 250 000 руб. (простой производства). Ссылались на экспертное заключение.
Вопрос 2. Как эксперт может установить, что обнаруженные в программном обеспечении ошибки или уязвимости являются критическими, угрожают безопасности данных или нарушают ключевой функционал, а не относятся к мелким недочётам?
🔐 Экспертиза безопасности ПО (в том числе и в рамках экспертизы процесса разработки) классифицирует ошибки и уязвимости по степени критичности. Для этого используются общепринятые стандарты (CVSS — Common Vulnerability Scoring System, OWASP Top 10 для веб-приложений) и классификация по влиянию на бизнес-процессы.
Классификация дефектов по степени критичности:
| Уровень критичности | Описание | Примеры | Правовые последствия |
| Критический (Critical) | Ошибка делает невозможным использование ключевого функционала, приводит к потере данных, утечке конфиденциальной информации, нарушению работы системы в целом. | Невозможность создать заказ (ошибка валидации, падение сервера). Возможность SQL-инъекции (доступ к базе данных клиентов). Утеря финансовых данных. | Существенное нарушение договора (ст. 475 ГК РФ). Расторжение, взыскание убытков. |
| Высокий (High) | Существенно снижает удобство использования (user experience) или производительность, но есть обходной путь (workaround). Исправление требуется в кратчайшие сроки. | Отчет формируется 5 минут вместо 10 секунд. Периодические зависания при работе с большими объемами данных (1000+ записей). | Подрядчик обязан исправить за свой счет. Может быть основанием для требования соразмерного уменьшения цены. |
| Средний (Medium) | Ухудшает пользовательский опыт, но не препятствует выполнению основных задач. Есть обходной путь. | Не обновляется статистика на дашборде в реальном времени (нужно обновлять страницу вручную). Некорректная сортировка данных. | Основание для требования исправления в течение разумного срока. |
| Низкий (Low) | Косметические дефекты, не влияющие на функционал и безопасность. | Несовпадение шрифтов, неверное выравнивание кнопок, грамматические ошибки в тексте. | Не являются основанием для расторжения договора или уменьшения цены (если иное не оговорено в ТЗ). |
Эксперт не просто констатирует, что ошибка существует, но и обосновывает, почему она является критической (ссылаясь на ТЗ, требования безопасности, нормативные документы).
🔹 Кейс № 2. Обнаружение критической уязвимости в интернет-банке (SQL-инъекция)
Обстоятельства: Банк заказал разработку системы интернет-банкинга (frontend + backend). Подрядчик сдал систему, все тесты прошли успешно (функциональные тесты). Через месяц после запуска система была взломана (злоумышленник получил доступ к счетам 20 клиентов). Предварительное расследование показало, что взлом произошел из-за SQL-инъекции в форме ввода номера счета. Подрядчик отказывался признавать вину, утверждая, что «взлом произошел из-за слабых паролей клиентов». Банк заказал экспертизу исходного кода.
Проведенная экспертиза:
Эксперт проанализировал исходный код backend-части (Java + Spring). Обнаружил, что в 5 местах кода используются конкатенации строк для формирования SQL-запросов, без использования параметризованных запросов (PreparedStatement). В форме ввода номера счета не было проверки на специальные символы (экранирование). Эксперт продемонстрировал (на тестовом стенде), как с помощью простого ввода 100′ OR ‘1’=’1 можно получить доступ к данным всех счетов. Эксперт классифицировал уязвимость как критическую (CVSS Score 9.8) и указал, что она является прямой причиной взлома.
Результат: Банк расторг договор, взыскал с подрядчика компенсацию клиентам (1,2 млн руб.) и штраф ЦБ РФ (500 000 руб.). Экспертное заключение стало ключевым доказательством.
Вопрос 3. Мы подозреваем, что бывший сотрудник или конкурент незаконно использует исходный код разработанного нами программного обеспечения. Может ли экспертиза предоставить доказательства такого неправомерного использования?
🕵️ Да, экспертиза программного обеспечения на предмет плагиата (или исследования авторских прав) может установить факт незаконного использования кода. Эксперт проводит сравнение вашего исходного кода (или скомпилированного приложения) с кодом конкурента (если он доступен).
Методы выявления заимствования:
| Метод | Описание | Что доказывает |
| Сравнение исходного кода (Source code comparison) | Построчное сравнение (diff), вычисление процента совпадения, анализ структуры файлов. | Прямое копирование (плагиат). Косвенное заимствование (переименование переменных, изменение порядка строк, добавление комментариев). |
| Анализ синтаксических деревьев (AST — Abstract Syntax Tree) | Сравнение не текста, а семантической структуры кода (деревья разбора). | Обнаружение заимствования, даже если переменные переименованы, порядок строк изменен, код был обфусцирован. |
| Анализ байт-кода (для Java,.NET) или дизассемблирование (для C++). | Если исходный код недоступен, эксперт анализирует скомпилированные файлы (бинарники), восстанавливая структуру. | Подтверждение заимствования даже при отсутствии исходного кода ответчика. |
| Поиск «водяных знаков» (copyright notices, уникальных сообщений об ошибках). | Если вы внедрили в код уникальные строки (например, сообщение об ошибке «Ошибка в модуле MyCompanySuperHash v3.4»). | Обнаружение этих строк в коде конкурента — прямое доказательство копирования. |
Если исходный код ответчика недоступен, можно провести сравнение пользовательских интерфейсов (UI) и функциональности (сравнение «черного ящика») — но это менее надежно, так как одинаковую функцию можно реализовать разными способами.
🔹 Кейс № 3. Плагиат мобильного приложения для доставки еды
Обстоятельства: Компания «Доставка-13» разработала мобильное приложение для заказа еды (iOS, Android). Через полгода на рынке появилось приложение «ЕдаМаркет» с идентичным функционалом (та же логика заказа, те же экраны, даже макеты похожи). У разработчика «ЕдаМаркет» был бывший сотрудник ООО «Доставка-13» — разработчик, который уволился за месяц до выхода нового приложения. Заказчик заподозрил кражу исходного кода.
Проведенная экспертиза:
Эксперт получил исходный код приложения «Доставка-13» и провел анализ байт-кода APK (Android) приложения «ЕдаМаркет» (доступного в Google Play). Обнаружено:
75% совпадения на уровне байт-кода (переименованы имена классов, но структура и алгоритмическая логика идентичны).
Уникальная функция расчета стоимости доставки с весовыми коэффициентами (разработанная специально для «Доставка-13») присутствовала в байт-коде «ЕдаМаркет».
В коде обнаружена строка с комментарием на русском языке «исправлено по просьбе Иванова 15.05.2025» (имя разработчика, который работал в «Доставка-13» и затем перешел в «ЕдаМаркет»).
Заключение эксперта: «Приложение „ЕдаМаркет“ создано на основе исходного кода приложения „Доставка-13“ (плагиат). Объем заимствования — 75%».
Результат: «ЕдаМаркет» удалила приложение, выплатила компенсацию 2 млн руб. по ст. 1301 ГК РФ.
Вопрос 4. Может ли независимая экспертиза разработки ПО выявить факты необоснованного удорожания проекта или манипуляции со сроками со стороны подрядчика?
💰 Да, экспертиза может выявить необоснованное удорожание и затягивание сроков, если подрядчик:
Включает в смету работы, не предусмотренные ТЗ;
Завышает трудозатраты (указывает больше часов, чем реально требовалось для реализации);
Меняет сроки без объективных причин.
Что анализирует эксперт:
| Направление | Что проверяет | Как доказывает необоснованность |
| Анализ изменений в ТЗ | Сравнивает изначальное ТЗ с дополнительными соглашениями. Оценивает, были ли изменения действительно необходимы, или подрядчик искусственно создавал «дополнительные работы». | Если изменения не связаны с новыми требованиями заказчика, а являются исправлением ошибок подрядчика (недоделок) — такие работы должны выполняться за счет подрядчика. |
| Анализ трудозатрат | Проверяет отчеты подрядчика (человеко-часы). Эксперт оценивает, сколько часов реально требовалось на реализацию каждой функции (benchmarking по типовым проектам). | Если подрядчик заявляет 100 часов на задачу, которая обычно занимает 20 часов, эксперт делает вывод о завышении. |
| Анализ причин задержек | Изучает переписку, акты, протоколы. Оценивает, были ли задержки вызваны действиями заказчика (позднее предоставление данных) или ошибками подрядчика. | Вывод о том, что задержка произошла по вине подрядчика (некачественный код, переделки). |
🔹 Кейс № 4. Необоснованное удорожание разработки CRM на 3 млн руб.
Обстоятельства: Заказчик (компания по продаже мебели) заключил договор на разработку CRM (системы управления взаимоотношениями с клиентами) за 3 млн руб. В процессе разработки подрядчик 4 раза увеличивал смету, ссылаясь на «непредвиденные сложности» и «дополнительные функции, которые заказчик запросил устно». Итоговая стоимость выросла до 6 млн руб. Заказчик отказался платить, подрядчик подал в суд.
Проведенная экспертиза: Эксперт проанализировал переписку (email, чаты), ТЗ и акты. Выявлено:
Из 4 дополнительных соглашений 2 касались функций, которые были в изначальном ТЗ (то есть подрядчик просто не сделал их в срок, а затем выставил как «дополнительные работы»).
В одном из дополнительных соглашений подрядчик заложил 250 часов на интеграцию с соцсетями (OK, VK). Эксперт оценил рыночную стоимость интеграции — 40 часов.
Причины задержек: в 70% случаев — ошибки в коде подрядчика (неудачная архитектура, переделки).
Заключение эксперта: «Фактическая стоимость работ, которые подрядчик должен был выполнить в рамках изначального ТЗ, составляет 3,8 млн руб., а не 6 млн руб. Работы на сумму 2,2 млн руб. признаны избыточными».
Результат: Суд взыскал с заказчика 3,8 млн руб. (вместо 6 млн руб.).
Вопрос 5. Какие потенциальные риски для безопасности данных и долгосрочной поддержки может выявить независимая экспертиза процесса разработки ПО, если мы планируем использовать его годы?
🔮 Экспертиза качества ПО (экспертиза архитектуры и кода) выявляет риски, которые могут привести к проблемам в будущем: уязвимости, технический долг, сложность поддержки.
Риски, выявляемые экспертизой:
| Риск | Описание | Последствия для бизнеса |
| Уязвимости безопасности (OWASP Top 10, SQL-инъекции, XSS, инъекции команд, инъекции LDAP, небезопасная десериализация, уязвимости аутентификации). | Ошибки в коде, которые могут привести к взлому, утечке данных, несанкционированному доступу. | Штрафы (152-ФЗ до 1,5 млн руб.), потеря репутации, отток клиентов. |
| Технический долг (запутанная архитектура, «спагетти-код», дублирование кода, отсутствие документации, неиспользуемый код, «мертвый код»). | Код, который сложно поддерживать и развивать. Каждое изменение требует много времени и может привести к появлению новых ошибок. | Высокая стоимость доработок (в 3-5 раз выше, чем при качественном коде). Необходимость переписывания с нуля через 1-2 года. |
| Отсутствие покрытия тестами (unit-тесты, integration tests). | Ошибки не обнаруживаются на этапе разработки, попадают в промышленную среду (production). | Частые сбои, простои, потеря данных. |
| Зависимость от конкретного разработчика (undocumented features, «магия» в коде, отсутствие комментариев). | Если уйдет разработчик, никто не сможет сопровождать код. | Невозможность доработок, поиск нового разработчика займет месяцы. |
| Использование устаревших или неподдерживаемых библиотек (libraries с истекшим сроком поддержки, с известными и исправленными уязвимостями). | Библиотеки с известными уязвимостями (CVE). | Взлом, утечка данных. |
🔹 Кейс № 5. Технический долг в 2 млн руб. в системе лояльности
Обстоятельства: Компания разработала систему лояльности для сети кофеен (мобильное приложение + backend). Через год после запуска потребовалось добавить новый тип бонусов (подарочные сертификаты). Разработчик (фактически автор) запросил за доработку 1,5 млн руб. Заказчик удивился («почему так дорого?»). Сторонний IT-специалист (независимый эксперт) провел аудит кода.
Проведенная экспертиза: Эксперт обнаружил:
Архитектура не была документирована; модули сильно связаны (tight coupling). Добавление нового типа бонусов требовало изменения 17 файлов (вместо 2-3 при нормальной архитектуре).
40% кода — дублирование (один и тот же фрагмент логики скопирован в 10 местах). Это увеличивает трудоемкость изменений.
Отсутствие unit-тестов. Каждое изменение приходится тестировать вручную (риск регрессий — старые ошибки возвращаются).
Эксперт оценил стоимость доработки при качественном коде в 300 000 руб. (а не 1,5 млн руб.).
Результат: Заказчик оплатил доработку за 300 000 руб. (по рыночной цене). Разработчик (который писал спагетти-код) был уволен.
Вопрос 6. Как экспертная оценка ПО помогает доказать низкую производительность программного обеспечения или чрезмерное потребление ресурсов, если это не влияет на основной функционал, но тормозит бизнес-процессы?
🐌 Экспертиза производительности ПО (Performance Testing) позволяет измерить:
Время отклика (response time) системы (загрузка страницы, выполнение API-запроса).
Потребление ресурсов (CPU, RAM, дисковая подсистема, сеть).
Максимальную нагрузку (при каком количестве пользователей система «падает»).
Что делать, если производительность низкая, но функционал работает?
Эксперт проводит нагрузочное тестирование (load testing) и сравнивает результаты с ожидаемыми показателями (SLA, если они оговорены, либо с негласными отраслевыми стандартами — например, время загрузки страницы не более 2 секунд). Если время отклика в 5 раз выше нормативного — это может служить основанием для предъявления претензий.
🔹 Кейс № 6. Тормозящая CRM в компании на 500 менеджеров
Обстоятельства: В компании (500 менеджеров по продажам) внедрили CRM на базе самописного ПО. CRM работала, но каждый раз при открытии карточки клиента приходилось ждать 10-15 секунд. Менеджеры жаловались, производительность упала (вместо 50 звонков в день — 35). Поставщик CRM утверждал, что «это нормально для такого объема данных (500 тыс. клиентов)». Заказчик заказал экспертизу производительности.
Проведенная экспертиза: Эксперт провел нагрузочное тестирование на тестовом стенде, имитировал работу 500 пользователей. Выявлено:
Основная причина тормозов — неоптимальный SQL-запрос (вместо SELECT * FROM clients WHERE id=? без индекса выполнялся полный перебор всей таблицы).
Время выполнения запроса — 12 секунд. После оптимизации (создания индекса) — 0,2 секунды.
Эксперт также замерил потребление RAM: сервер использовал 90% RAM из-за ошибки в кэшировании.
Заключение эксперта: «Производительность CRM не соответствует отраслевым стандартам (ожидаемое время отклика — не более 2 секунд). Причина — дефекты SQL-запроса и архитектуры кэширования. Устранение дефектов не потребует переписывания всей системы, но требует доработки кода».
Результат: Поставщик CRM исправил ошибки за свой счет. Производительность восстановлена.
Вопрос 7. Как экспертиза использования ПО может установить, что сбои в работе системы вызваны несовместимостью сторонних модулей или некорректной интеграцией?
🔄 Экспертиза использования ПО может выявить, что сбои вызваны не дефектами в коде, а проблемами на стыке систем — несовместимостью версий, неправильной настройкой API, расхождением форматов данных.
Как эксперт выявляет интеграционные проблемы:
| Метод | Описание | Признак проблемы |
| Анализ логов обмена данными (API logs, системные журналы, error logs). | Эксперт смотрит, какие запросы отправлялись от модуля А к модулю Б, какие ответы получались (ошибки 4xx, 5xx, таймауты). | Модуль А отправляет данные в формате JSON, а модуль Б ожидает XML (ошибка парсинга). |
| Тестирование интеграции (модуль А + модуль Б в изоляции). | Эксперт запускает модуль А (сам по себе — работает) и модуль Б (работает). Запускает их вместе — падают. | Проблема в интерфейсе между ними (API). |
| Анализ версий (версии библиотек, API, драйверов). | Модуль А требует библиотеку версии 2.0, модуль Б — версии 1.5 (несовместимость). | Ошибки на этапе загрузки (linker error), непредсказуемое поведение. |
🔹 Кейс № 7. Сбой при интеграции CRM с телефонией
Обстоятельства: Компания интегрировала CRM (самописную) с IP-телефонией. Система работала месяц, затем начала «падать» (периодические зависания) при входящем звонке. Администратор не мог понять причину. Заказчик подозревал, что проблема в CRM. Разработчик CRM утверждал, что «в CRM нет ошибок, проблема в телефонии». Заказчик заказал экспертизу интеграции.
Проведенная экспертиза: Эксперт проанализировал логи CRM и телефонии. Выявил:
CRM корректно отвечала на запросы телефонии, но через некоторое время переставала отвечать.
Телефония открывала соединение с CRM и не закрывала его (утечка соединений — connection leak). Через 1000 звонков CRM зависала.
В CRM не было ограничения на количество одновременных соединений (рекомендовано настроить pool connections).
Заключение эксперта: «Причина сбоев — ошибка в интеграции со стороны поставщика телефонии (не закрывал соединения). CRM работает корректно».
Результат: Поставщик телефонии исправил ошибку.
Вопрос 8. Что нужно для судебной экспертизы программного обеспечения, чтобы подтвердить авторство конкретных модулей или функций, если несколько разработчиков работали над проектом?
📜 Для подтверждения авторства конкретных модулей (кто написал какой код) в судебной экспертизе используются данные системы контроля версий (Git, SVN, Mercurial). Эти системы фиксируют:
Кто (логин разработчика, email) сделал коммит (commit).
Когда (дата, время).
Какой код был добавлен, изменен или удален (diff).
Сообщение коммита (commit message — часто содержит номер задачи, описание).
Что нужно предоставить эксперту:
| № | Материал | Зачем нужен |
| 1 | Репозиторий исходного кода (Git, SVN, Mercurial) с полной историей коммитов. | Эксперт анализирует историю изменений, определяет автора каждого фрагмента. |
| 2 | Документы, подтверждающие, кто имел доступ к репозиторию (список разработчиков, их логины). | Для сопоставления логина из коммита с реальным ФИО. |
| 3 | Журналы системы управления задачами (Jira, Trello, Asana) — какие задачи закреплены за разработчиками. | Для подтверждения, что разработчик работал над конкретным модулем. |
🔹 Кейс № 8. Спор об авторстве модуля крипто-шифрования
Обстоятельства: Два разработчика (А и Б) работали над проектом (система крипто-шифрования). Разработчик А утверждал, что модуль шифрования RSA полностью написан им. Разработчик Б утверждал, что это его код. Дело дошло до суда (спор о выплате бонуса за создание ключевого модуля). Заказчик (компания) предоставил репозиторий Git.
Проведенная экспертиза: Эксперт проанализировал историю коммитов (git log). Выявлено:
Модуль шифрования (файл rsa.py) был создан разработчиком А 15.01.2025 (первый коммит).
Затем разработчик Б 20.02.2025 изменил одну функцию (исправил баг). То есть 99% кода принадлежит А.
Сообщения коммитов подтверждают авторство: «Add RSA encryption module (A)», «Fix padding error (Б)».
Заключение эксперта: «Автором модуля шифрования RSA является разработчик А. Разработчику Б принадлежит 1% кода (исправление ошибки)».
Результат: Суд удовлетворил иск разработчика А о выплате бонуса.
📌 Заключение
Независимая экспертиза процесса разработки и использования ПО позволяет:
✅ Определить реальный процент готовности и стоимость доработки для споров с подрядчиком.
✅ Классифицировать ошибки (критические, высокие, средние, низкие), доказать, что они делают систему непригодной к использованию или угрожают безопасности данных.
✅ Доказать факт плагиата или незаконного использования кода (в т.ч. бывшими сотрудниками, конкурентами).
✅ Выявить необоснованное удорожание (накрутка часов, «лишние работы») и манипуляции со сроками.
✅ Оценить риски для долгосрочной поддержки (технический долг, устаревшие библиотеки, отсутствие тестов, зависимость от конкретного разработчика).
✅ Доказать низкую производительность или чрезмерное потребление ресурсов.
✅ Установить, что сбои вызваны несовместимостью интеграций, а не дефектами в коде.
✅ Подтвердить авторство конкретных модулей / функций с помощью систем контроля версий.
Все виды работ проводятся в строгом соответствии с Федеральным законом № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации».
👉 Единственная ссылка: https://gemmex.ru/ 👈
Задавайте любые вопросы