💻 Введение: когда код становится предметом судебного разбирательства
Заказчик потратил миллионы рублей на разработку программного обеспечения, а в итоге получил «сырой» продукт: постоянные ошибки, зависания, невыполнение ключевых функций, срыв сроков. Разработчик утверждает, что всё работает «согласно техническому заданию», или обвиняет заказчика в неправильной эксплуатации. 🧩 Кто прав? Обычная проверка «включилось — не включилось» здесь не работает. Нужна глубокая, технически сложная экспертиза программного обеспечения, которая проводится специалистами в области IT и права. 🖥️ Союз «Федерации судебных экспертов» представляет практическое руководство: что именно проверяет эксперт на объекте (сервере, ПК, в облаке), как анализируется код, архитектура, производительность и безопасность, и какие ошибки чаще всего допускают недобросовестные подрядчики. Вы узнаете о методах статического и динамического анализа, тестировании на соответствие техзаданию, поиске «закладок» и скрытых алгоритмов, а также о том, как правильно подготовиться к экспертизе, чтобы ваши интересы были защищены. Это руководство будет полезно заказчикам ПО, юристам, IT-менеджерам и даже разработчикам, желающим избежать споров. Погружаемся в мир байт-кода, логов и архитектурных диаграмм.
Раздел 1: 📋 Когда назначается экспертиза ПО после некачественных работ
Программное обеспечение стало неотъемлемой частью бизнеса. 📉 Споры о его качестве возникают в самых разных ситуациях:
Разработка на заказ (ERP-системы, CRM, интернет-магазины, мобильные приложения, телеграм-боты) — продукт не соответствует техническому заданию (ТЗ), имеет критические ошибки.
Поставка лицензионного ПО (коробочные решения) — оказалось, что это подделка, «пиратка» или не та версия.
Сопровождение и доработка существующего ПО — подрядчик «сломал» работавшую систему, внес недокументированные изменения.
Споры о передаче исходного кода (эскроу-счета) — переданный код неработоспособен или неполон.
Интеграция между системами — данные теряются, дублируются, искажаются.
⚖️ Экспертиза проводится как в судебном порядке (по определению суда), так и в досудебном (для претензии или оценки перспектив). Союз «Федерации судебных экспертов» имеет в штате сертифицированных экспертов в области программирования, тестирования и информационной безопасности.
Раздел 2: 🗂️ Какие документы и материалы нужно предоставить эксперту
Для качественной экспертизы необходима документальная база. 📑 Союз «Федерации судебных экспертов» рекомендует собрать:
Техническое задание (ТЗ) — основной документ, определяющий функции, характеристики, интерфейсы, производительность и условия эксплуатации ПО.
Договор разработки и все дополнительные соглашения (спецификации, протоколы согласования).
Акты приёма-передачи (если частично работы уже приняты) и переписку сторон (претензии, письма, чаты).
Исходный код (если он передавался или является предметом спора) — в репозитории (Git, SVN) или архиве.
Доступ к работающему экземпляру ПО (URL, логин/пароль, тестовый стенд, доступ к серверу).
Инструкции пользователя и администратора (если есть).
Логи ошибок (логи) — файлы журналов событий, stack trace’ы (следы исключений).
Результаты предыдущего тестирования (если заказчик проводил своё) — скриншоты ошибок, протоколы.
📌 Если подрядчик отказывается предоставить исходный код, ссылаясь на «коммерческую тайну», эксперт может сделать вывод о невозможности полного исследования, что суд может трактовать против подрядчика.
Раздел 3: 🧩 Что проверяет эксперт на объекте (общая схема)
Осмотр ПО на объекте — это не «посмотреть экран», а комплекс мероприятий. 🧰 Эксперт Союза «Федерации судебных экспертов» действует поэтапно:
Анализ документации — изучает ТЗ, договор, спецификации, чтобы понять, что должно быть.
Функциональное тестирование — проверяет каждую заявленную функцию: работает ли так, как описано? (например, кнопка «Сохранить» действительно сохраняет данные в нужную таблицу).
Тестирование граничных случаев — что происходит при нестандартных вводных (пустые поля, неверный формат, большая нагрузка).
Анализ архитектуры и кода — если есть доступ к исходному коду, проверяет его на соответствие стандартам, наличие «костылей» (заплаток), ошибок, уязвимостей.
Нагрузочное тестирование (если требуется) — сколько пользователей может одновременно работать, не упадет ли система.
Проверка безопасности — нет ли известных уязвимостей (SQL-инъекции, XSS, незакрытые порты).
Сравнение с аналогами (опционально) — соответствует ли заявленной функциональности.
🖥️ Выезд на объект может включать доступ к серверам заказчика или использование удалённого доступа (TeamViewer, RDP). Все действия фиксируются в протоколе.
Раздел 4: 🔍 Ошибки в реализации функциональных требований (соответствие ТЗ)
Самая частая причина споров — несоответствие техническому заданию. 📋 Эксперт Союза «Федерации судебных экспертов» проверяет:
Полнота реализации — все ли пункты ТЗ выполнены. Например, в ТЗ сказано «отчёт по продажам за период с выбором дат», а в системе только «отчёт за текущий месяц». Это недостаток.
Точность реализации — как именно работает функция. Пример: в ТЗ «скидка 10% от суммы заказа», а считает 10% от цены товара без учёта доставки. Это ошибка.
Соответствие входных и выходных данных — что подал, то и получил (без искажений).
Обработка ошибок — если пользователь вводит неверные данные, программа должна выдать понятное сообщение, а не «упасть» или молча сохранить не то.
Локализация (если требуется) — все надписи на русском (или нужном языке), правильно ли склоняются числа, даты.
📌 Эксперт составляет таблицу «Требование — Реализация — Комментарий», где зелёным помечает выполненные, красным — невыполненные или с ошибками. Каждая ошибка иллюстрируется скриншотом.
Раздел 5: 🐞 Ошибки производительности (тормоза, зависания, вылеты)
ПО может работать, но медленно — это тоже брак. 🐢 Эксперт Союза «Федерации судебных экспертов» проверяет:
Время отклика (response time) — сколько миллисекунд проходит от нажатия кнопки до появления результата. Нормы прописываются в ТЗ (например, «не более 1 секунды для 90% операций»). Если не прописано, эксперт использует отраслевые стандарты (2–3 секунды для обычных операций, до 10 секунд для сложных отчётов).
Нагрузка на сервер — загрузка CPU, памяти, дисковых операций при типовых сценариях.
Утечки памяти (memory leak) — если программа со временем «съедает» всё больше памяти и в конце концов падает (проверяется длительным тестом на 24–48 часов).
Количество критических ошибок (crash’ей) — вылетает ли программа сама по себе, без видимых причин. Фиксируется число ошибок на час работы.
Параллелизм (многопользовательский режим) — если два пользователя одновременно редактируют один объект, не происходит ли конфликта, потери данных.
📊 Эксперт использует инструменты нагрузочного тестирования (имитация работы 10, 50, 100 виртуальных пользователей). Если при 10 пользователях система падает, а по ТЗ должно выдерживать 200 — это явное несоответствие.
Раздел 6: 🔐 Ошибки безопасности (уязвимости и «закладки»)
Безопасность ПО часто игнорируется, но последствия могут быть катастрофическими. 🔓 Эксперт Союза «Федерации судебных экспертов» проверяет:
Аутентификация и авторизация — можно ли зайти под чужим логином? Можно ли получить доступ к функциям, не предназначенным для вашей роли (например, обычный пользователь может зайти в админку, изменив URL)?
Защита от SQL-инъекций — можно ли, введя специальный код в поле ввода, выполнить произвольный запрос к базе данных? Эксперт вводит ‘ OR ‘1’=’1 и смотрит на результат.
Защита от межсайтового скриптинга (XSS) — можно ли внедрить вредоносный скрипт в отображаемые данные?
Хранение паролей — не хранятся ли пароли в открытом виде (в базе данных, в логах)? Должны быть хэшированы (bcrypt, PBKDF2).
«Закладки» (бэкдоры) — не оставил ли разработчик скрытый вход в систему (например, пароль admin/admin, специальный URL), чтобы в любой момент получить доступ.
Обновление и исправление уязвимостей — используются ли библиотеки с известными уязвимостями (эксперт проверяет версии).
🛡️ Если эксперт находит критическую уязвимость, он фиксирует это как грубый недостаток, делающий ПО непригодным для безопасной эксплуатации.
Раздел 7: 🧩 Анализ качества исходного кода (если доступен)
Исходный код — это «внутренности» программы. 🧬 Эксперт Союза «Федерации судебных экспертов» оценивает:
Читаемость и поддерживаемость — названия переменных, функций, комментарии, структура файлов. «Код-лапша» (спагетти-код) свидетельствует о низком качестве.
Наличие дублирования — один и тот же кусок кода скопирован 10 раз вместо вынесения в функцию. Это увеличивает риск ошибок и стоимость доработок.
Следование стандартам (PSR для PHP, PEP для Python, Java Code Conventions и т.д.).
Покрытие тестами (unit tests) — если по договору должно быть не менее 70% покрытия, а фактически 5% — дефект.
Обработка ошибок (exception handling) — не «проглатываются» ли ошибки без логирования? Не падает ли программа при отсутствии интернета?
Наличие «мёртвого кода» (неиспользуемые функции, переменные) — увеличивает размер и сложность, но не является критичным само по себе, но свидетельствует о небрежности.
📌 Эксперт использует статические анализаторы кода (SonarQube, ESLint, PMD и др.) — они выдают количественные метрики (количество предупреждений на тысячу строк кода). Нормы также могут быть в договоре.
Раздел 8: 📊 Анализ логов и мониторинг работы в реальном времени
Логи — это «чёрный ящик» программы. 📜 Эксперт Союза «Федерации судебных экспертов» изучает:
Наличие критических ошибок (Exception, Error) — их частоту, контекст (при каком действии возникли).
Информативность — пишутся ли понятные сообщения, которые помогают найти причину, или только «Ошибка 500».
Отсутствие логирования конфиденциальных данных (паролей, номеров карт) — грубая ошибка безопасности.
Заполнение диска логами — если логи не ротируются (не очищаются), диск может переполниться, и программа упадёт.
Сравнение с ожидаемым поведением — например, в логах видно, что ежедневно происходит 10 падений, хотя по ТЗ допускается не более 1 падения в месяц.
📌 Эксперт может попросить заказчика запустить сценарии (бизнес-процессы) и в реальном времени смотреть логи, чтобы сопоставить действия и ошибки.
Раздел 9: ⏳ Соответствие версиям и документации (миграции, обновления)
Часто споры возникают из-за того, что подрядчик «переписал» уже работавшую систему. 🔄 Эксперт проверяет:
Управление версиями — есть ли в коде теги, метки, история изменений. Если подрядчик не использовал Git или SVN — это нарушение современной практики.
Миграции базы данных — если менялась структура БД, есть ли скрипты миграции (up/down), можно ли откатить изменения без потери данных.
Документация — инструкции администратора, разработчика, пользователя. Соответствуют ли они реальной системе? Не устарели ли?
Установка и развёртывание — сколько времени и усилий требуется, чтобы развернуть ПО на новом сервере. Если это «танец с бубном» на 2 дня — недостаток.
📌 При неполноте документации эксперт делает вывод: «ПО не может быть передан в эксплуатацию без документации», что является существенным недостатком.
Раздел 10: 🧪 Сравнительный анализ с рыночными аналогами (бенчмаркинг)
Иногда в договоре нет чётких метрик, но есть фраза «не ниже рыночного уровня». 📈 Эксперт Союза «Федерации судебных экспертов» может сравнить спорное ПО с 2–3 аналогами:
Функциональность (есть ли ключевые возможности, которые есть у всех конкурентов).
Удобство интерфейса (субъективно, но эксперт может выявить критические неудобства, например, нельзя отменить действие).
Производительность (быстрее/медленнее аналогов).
Стоимость владения (сопоставляется с ценой, если в договоре есть привязка).
📌 Однако это вспомогательный метод. Основной — соответствие ТЗ, а не «как у других».
Реальные кейсы из практики Союза «Федерации судебных экспертов»
💼 Кейс №1: Интернет-магазин падает при 10 пользователях
Заказчик оплатил разработку интернет-магазина с гарантией, что сайт выдержит 500 одновременных посетителей. После запуска при 10 посетителях сайт падал с ошибкой 500. Эксперты Союза «Федерации судебных экспертов» провели нагрузочное тестирование и выявили: неоптимальные запросы к базе данных (N+1 проблема), отсутствие кеширования, утечку памяти в модуле корзины. Суд обязал подрядчика полностью переписать архитектуру модулей или вернуть 2,8 млн руб. Экспертиза стала ключевым доказательством.
💼 Кейс №2: Отсутствие требуемой функции и «закладка»
Заказчик просил разработать CRM с функцией автоматической рассылки email по расписанию. Подрядчик сдал систему, но рассылка не работала (ошибка в коде). При дополнительном анализе эксперт нашёл в коде «бэкдор» — скрытую страницу /admin/supersecret, с которой можно было просматривать любые данные клиентов без пароля. Суд признал ПО некачественным, подрядчик выплатил компенсацию 1,5 млн руб. и уголовное дело за неправомерный доступ.
💼 Кейс №3: Нечитаемый код (спагетти) и отсутствие документации
После ухода программиста заказчик не мог вносить изменения в систему: код был написан «как попало», без комментариев, имена переменных «a,b,c,x1,y2», дублирование 70% кода. Эксперт Союза «Федерации судебных экспертов» оценил, что стоимость доработки фактически равна стоимости разработки с нуля (3,6 млн руб.). Суд взыскал с подрядчика эту сумму, так как по договору код должен быть читаемым и сопровождаемым.
💼 Кейс №4: SQL-инъекция и потеря данных клиентов
Разработчик сдал интернет-магазин, но через месяц хакеры через уязвимость SQL-инъекции выгрузили базу данных клиентов (паспорта, номера карт). Заказчик понёс репутационные потери и штраф от Роскомнадзора. Экспертиза показала, что разработчик не использовал параметризованные запросы (просто склеивал строку запроса из ввода пользователя). Суд признал это грубейшей ошибкой, подрядчик выплатил 5,2 млн руб. убытков и штрафа.
💼 Кейс №5: Расхождение с ТЗ в 30% функций
По договору разрабатывалась ERP-система с 200 функциями. Заказчик принял ПО, но при детальной проверке выяснилось, что 60 функций (30%) работают не так, как в ТЗ, либо отсутствуют. Эксперт Союза «Федерации судебных экспертов» составил подробную таблицу расхождений, провёл скриншоты. Суд снизил стоимость работ пропорционально невыполненным функциям (подрядчик вернул 2,1 млн руб. из 7 млн).
🔚 Заключение: пошаговый чек-лист для заказчика ПО
Уважаемый заказчик! 🛡️ Чтобы экспертиза программного обеспечения после некачественных работ прошла успешно, Союз «Федерации судебных экспертов» рекомендует:
📂 Сохраняйте всё ТЗ, договоры, переписку — это база для сравнения.
🖥️ Обеспечьте доступ эксперта к работающему ПО (тестовый стенд, логи, сервер). Если подрядчик заблокировал доступ — это его проблема.
📊 Зафиксируйте ошибки до начала экспертизы (скриншоты, видео, логи) своими силами.
🧠 Сформулируйте чёткие вопросы эксперту: не «работает ли программа плохо?», а «соответствует ли модуль “Отчёты” пунктам 4.2–4.5 ТЗ?».
🧑💻 Требуйте исходный код (если он ваш по договору). Если подрядчик не отдаёт — обращайтесь в суд с иском об истребовании.
⏱️ Срочность — экспертиза ПО занимает от 2 недель до 2 месяцев, закладывайте это в сроки суда.
🔐 Безопасность — если вы подозреваете «закладки», требуйте от эксперта проверки на бэкдоры.
📌 Помните: программное обеспечение — это товар, и к нему применимы требования качества. Не верьте подрядчику на слово, доказывайте с помощью науки. Союз «Федерации судебных экспертов» поможет восстановить справедливость.
Полную контактную информацию, телефон и адрес офиса, а также более подробную информацию по вашему вопросу вы можете найти на нашем официальном сайте ✅ https://krimexpert.ru
Задавайте любые вопросы