Судебная экспертиза качества исходного кода

При экспертизе код не оценивают словами «хорошо» или «плохо». Конкретную версию проверяют по заранее определённому критерию: требованию договора или технического задания, согласованному стандарту разработки, архитектурному ограничению либо конкретному свойству — собираемости, анализируемости, модифицируемости, тестируемости. Без такого основания спор о качестве сводится к непроверяемым мнениям.

Исследование строится на воспроизводимых наблюдениях. В заключении указывают, какой репозиторий и какой коммит изучены, что входило в состав объекта, в какой среде выполнялась сборка, какие правила и пороги применялись, где именно обнаружен каждый дефект и как проверялось его влияние. Число предупреждений анализатора само по себе выводом не является: каждое существенное срабатывание проверяют по коду, конфигурации и сценарию использования.

Качество кода — один из вопросов, которые можно исследовать в рамках экспертизы процесса разработки программного обеспечения. Он возникает в споре заказчика и исполнителя, при приёмке переданного репозитория, при разборе причин отказа и при проверке уже подготовленного заключения. Авторство, стоимость работ, готовность всей системы и её защищённость требуют других объектов и другой методики.

Сначала определяют, что именно считать качеством

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

Работа начинается с карты критериев. Каждое спорное требование разбирают по пяти пунктам:

1. Источник. Пункт договора, технического задания, регламент заказчика, названный стандарт либо прямо согласованная сторонами методика.
2. Проверяемое свойство. Например, возможность собрать релиз из переданных исходников, отсутствие циклической зависимости между заданными модулями, наличие автоматических тестов для критического расчёта.
3. Способ проверки. Анализ структуры проекта, воспроизведение сборки, статический анализ, испытание на стенде, трассировка выполнения или ручная проверка выбранных участков.
4. Условие результата. Какое наблюдение означает соответствие, какое — несоответствие и когда данных недостаточно. Порог нельзя подбирать после того, как результат уже известен.
5. Граница вывода. Вся кодовая база, перечисленные модули, конкретная версия, выборка файлов или только сценарии, которые удалось воспроизвести.

Если стороны сослались на стандарт без конкретизации, эксперт сначала выясняет, какая редакция действовала в спорный период и какие её положения относятся к объекту. Например, ISO/IEC 25010:2023 задаёт модель качества продукта, а ISO/IEC 25023:2016 — меры для количественной оценки характеристик. Это не готовая шкала, по которой любому репозиторию автоматически выставляют балл. Из модели выбирают относящиеся к вопросу свойства и связывают их с измеримыми признаками именно этого проекта.

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

Что можно установить по исходному коду

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

• какие языки, модули, сторонние компоненты и автоматически созданные файлы входят в представленную кодовую базу;
• соответствует ли её структура прямо названным архитектурным и технологическим требованиям;
• воспроизводится ли предусмотренная проектом сборка, какие стадии она проходит и по какой причине останавливается;
• имеются ли конкретные дефекты: недостижимый код, необработанные состояния, ошибки управления ресурсами, нарушения согласованных правил работы с данными;
• каковы измеренные значения выбранных показателей — сложности, связанности, дублирования, покрытия тестами — и что именно они характеризуют;
• можно ли анализировать, изменять и проверять код в пределах заданного критерия;
• связан ли воспроизведённый отказ с найденным участком кода либо наблюдаемое поведение объясняется настройками, данными, внешним сервисом или другой причиной;
• достаточно ли переданного комплекта для сопровождения и сборки той версии, которая указана в вопросе.

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

Чего экспертиза качества кода не доказывает

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

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

Особенно осторожно формулируют вывод об отсутствии дефектов. Если анализатор не нашёл ошибок определённого класса, это означает лишь, что при названных правилах, версии инструмента и охваченном коде соответствующих срабатываний не получено. Формулировка «ошибок в программе нет» выходит за пределы фактических данных и потому недопустима.

Когда исследование действительно нужно

Экспертиза полезна, когда спор касается конкретной версии кода и разрешается проверкой технических признаков. Чаще всего обращаются в следующих ситуациях:

• заказчик получил репозиторий, но проект не собирается по переданной инструкции или собранная версия отличается от принятой;
• в договоре закреплены требования к архитектуре, тестам, документированию или правилам разработки, а стороны расходятся в оценке их выполнения;
• после передачи проекта новая команда не может безопасно вносить изменения и нужно установить техническую причину, а не просто описать неудобство;
• одно и то же исправление вызывает дефекты в несвязанных частях системы, и спор касается модульности либо чрезмерной связанности;
• программа отказывает на определённых данных или под нагрузкой, а стороны по-разному объясняют причину;
• часть функциональности закрыта собранными компонентами, отсутствуют схемы, миграции, зависимости или инструкции, необходимые для работы с кодом;
• в уже выполненной экспертизе качество оценено по числу строк, предупреждений или комментариев без связи с договорным критерием;
• нужно зафиксировать техническое состояние кода до расторжения договора, передачи проекта другой команде или существенной переработки.

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

Экспертиза, аудит и рецензия решают разные задачи

Аудит кода нужен для будущих изменений. Его цель — найти зоны риска и предложить команде, что изменить: разделить модуль, обновить зависимость, добавить тесты, переписать запрос. Объект аудита может меняться по ходу работы, а рекомендации зависят от бюджета, планов продукта и допустимого риска.

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

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

Как фиксируют объект исследования

Слово «репозиторий» ещё не определяет объект. В нём одновременно существуют ветки, теги, незакоммиченные изменения, удалённые файлы, подключённые подмодули и большие файлы, которые хранятся отдельно. Рабочая программа на сервере могла быть собрана из другого состояния или дополнена компонентом, которого в репозитории нет. Поэтому сначала точно определяют, что именно предстоит исследовать.

В опись включают:

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

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

Если спор уже возник, не «приводите проект в порядок» поверх спорного состояния. Не переписывайте историю, не удаляйте ветки и старые сборки, не обновляйте зависимости в единственной копии, не запускайте автоформатирование всего проекта. Сначала сделайте зеркальную копию репозитория и отдельно сохраните журналы CI/CD, реестр пакетов, хранилище артефактов и сведения из системы задач. Дальше работайте только с копией.

Какие материалы потребуются

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

Для полного исследования обычно нужны:

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

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

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

Как проводится исследование качества кода

Состав исследования зависит от вопросов, но порядок один: фиксируют объект и критерий, проводят проверку, записывают результаты и рассматривают альтернативные объяснения.

1. Инвентаризация и проверка комплектности

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

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

2. Воспроизведение сборки

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

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

3. Автоматизированный анализ

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

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

4. Ручная проверка архитектуры и критических участков

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

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

5. Динамическая проверка и контрольные изменения

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

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

6. Сопоставление с требованиями и проверка альтернатив

Каждое существенное наблюдение сопоставляют с картой критериев. Эксперт проверяет, не объясняется ли оно особенностью языка, выбранной платформы, сгенерированным кодом, прямо согласованным компромиссом или ограничением представленных материалов. Только после этого делают вывод о соответствии или несоответствии.

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

Почему метрики не дают готовой оценки

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

• Количество строк. Показывает размер текста при конкретном правиле подсчёта. Оно не измеряет ни трудоёмкость, ни полезность, ни качество: одна и та же функция может быть записана короче или длиннее.
• Цикломатическая сложность. Характеризует число независимых путей в участке управляющей логики и помогает планировать проверку. Высокое значение указывает, где анализ и тестирование труднее, но не делает функцию дефектной автоматически.
• Дублирование. Может повышать цену согласованных изменений, если копии приходится исправлять вместе. Но совпадающий порождённый код, декларативные схемы и независимые адаптеры требуют отдельного разбора.
• Связанность. Значима, когда изменение одного компонента вынужденно затрагивает другие. Простое число импортов без анализа направления и назначения зависимостей такой вывод не подтверждает.
• Покрытие тестами. Показывает, какой код выполнялся при запуске набора тестов. Оно не говорит, проверялись ли правильные результаты, граничные условия и отказоустойчивость. Стопроцентное покрытие возможно при тестах без содержательных проверок.
• Количество предупреждений. Зависит от набора правил, версии средства, конфигурации и состава включённых файлов. Сравнимы только результаты, полученные в одинаковых условиях.
• Комментарии и документация. Их наличие не гарантирует понятности; устаревший комментарий способен мешать сильнее, чем его отсутствие. Проверяют, не расходятся ли комментарии с кодом и хватает ли документации для названной операции.

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

Как оценивают значение найденного дефекта

У дефекта есть как минимум четыре отдельные характеристики: условие проявления, последствия, распространённость и возможность восстановления. Одна и та же ошибка в отключённом служебном модуле и в основном сценарии обработки платежа имеет разное значение. Метка «critical», присвоенная анализатором, описывает правило инструмента, а не последствия для конкретной системы.

Для каждого существенного дефекта эксперт указывает:

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

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

Поддерживаемость проверяют на изменении, а не на впечатлении

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

Так можно по отдельности проверить:

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

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

Безопасность, персональные данные и лицензии

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

Наличие функций шифрования или удаления записей само по себе не доказывает соблюдение ФЗ-152 или GDPR. Нужно знать цели и основания обработки, состав данных, роли участников, фактические потоки, сроки хранения и организационные меры. По коду можно подтвердить отдельный технический факт — например, что поле журналируется без маскирования, — но правовой вывод о соблюдении закона остаётся за пределами исследования качества кода.

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

Если репозиторий неполон или программа не собирается

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

Эксперт разделяет вопросы на три группы:

1. те, на которые можно ответить полностью по имеющимся объектам;
2. те, на которые возможен ограниченный вывод с прямо названными границами;
3. те, для которых недостаёт необходимого материала или современная методика не позволяет получить проверяемый ответ.

Если эксперт обосновал, почему дать заключение невозможно, это нормальный процессуальный результат. Отсутствие сборочной среды нельзя компенсировать предположениями. Если нужные материалы находятся у другой стороны, до назначения экспертизы в ходатайстве об их истребовании перечисляют репозиторий, версии, журналы, пакеты и инструкции. Формулировка «вся техническая документация» недостаточно точна.

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

Предварительная оценка до начала работы

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

Предварительная оценка может быть неблагоприятной. Например, в договоре нет требований к внутреннему устройству кода, спорная версия перезаписана, а единственный вопрос требует определить «процент качества». В таком случае мы объясним, почему предложенная постановка не даст надёжного вывода, и предложим более узкий вопрос, на который можно ответить. Это экономит время до назначения судебной экспертизы и помогает вовремя запросить недостающие объекты.

Если материалы показывают, что существенных нарушений критерия не обнаружено, мы также сообщим об этом и не станем подгонять задачу под ожидаемый ответ. Цель предварительного разбора — не предсказать нужный стороне вывод, а понять, возможно ли исследование и где проходят его границы.

Примеры вопросов эксперту

В вопросе сначала точно указывают объект и основание для оценки. Вместо «качественно ли написана программа?» называют репозиторий, коммит или контрольную сумму архива, спорные модули, редакцию документа и проверяемое свойство. Иначе эксперту придётся самому выбирать стандарт качества, а стороны будут спорить уже о выбранном критерии.

Ниже — ориентиры для обсуждения с представителем стороны и профильным специалистом. Окончательный круг и редакцию вопросов судебному эксперту определяет суд; стороны вправе предложить свои формулировки. Вопросы о нарушении договора, вине, авторстве, размере убытков и допустимости доказательства являются правовыми и эксперту по коду не ставятся.

1. Каковы состав и структура исходного кода программного обеспечения [наименование] в состоянии [идентификатор]; какие части относятся к собственному, стороннему и автоматически созданному коду?
2. Достаточен ли представленный комплект исходного кода, зависимостей, конфигурации и документации для выполнения предусмотренной проектом сборки версии [идентификатор]; если нет, каких компонентов недостаёт?
3. Воспроизводится ли сборка программного обеспечения [наименование] по представленной инструкции в среде [описание]; если нет, по какой технической причине?
4. Соответствует ли структура модулей [перечень] требованиям пунктов [реквизиты] документа [название, редакция]; в чём состоят выявленные соответствия и несоответствия?
5. Имеются ли в модулях [перечень] дефекты указанных классов [перечень]; где они расположены, при каких условиях проявляются и к каким техническим последствиям приводят?
6. Соответствуют ли правила обработки ошибок, управления ресурсами и проверки входных данных требованиям [источник критерия] в исследуемой версии?
7. Какие значения получены для показателей [точно названные показатели] методом [описание] с заранее заданными порогами; какие файлы включены и исключены из измерения и почему?
8. Обеспечивают ли имеющиеся автоматические тесты обнаружение отклонений в критических функциях [перечень] при контрольных изменениях [описание]?
9. Какие зависимости возникают при внесении предусмотренного требованиями изменения [описание] в модуль [название]; ограничиваются ли они границами, установленными архитектурным требованием [реквизиты]?
10. Связан ли воспроизведённый отказ [точное описание] с участком исходного кода [если известен]; какие альтернативные технические причины проверены?
11. Вносились ли в исследуемые модули изменения между состояниями [идентификаторы], затрагивающие выявленный дефект или выбранный показатель; в чём они состоят?
12. Достаточно ли представленных материалов для ответа на каждый поставленный вопрос; какие ограничения относятся к полученным выводам?

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

Что будет в заключении

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

Исследовательская часть обычно содержит:

• опись кодовой базы и схему её компонентов;
• протокол сборки и испытаний с командами, версиями и результатами;
• матрицу требований и проверяемых признаков;
• перечень настроек автоматизированных средств и исходные отчёты;
• реестр проверенных дефектов с расположением, условием проявления и последствиями;
• расчёт показателей вместе с правилами включения и исключения файлов;
• результаты положительных и отрицательных контролей;
• проверенные альтернативные объяснения и границы, в которых действуют выводы.

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

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

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

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

До назначения экспертизы результат предварительного исследования помогает:

• отделить технические обстоятельства от правовых доводов;
• сформулировать вопросы без неопределённых слов;
• описать объекты, которые следует истребовать и передать эксперту;
• оценить, нужна ли комплексная работа программиста, специалиста по безопасности или оценщика;
• проверить, не требует ли вопрос исследования рабочей среды, а не только репозитория.

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

Этапы работы

Порядок зависит от того, назначена ли экспертиза судом или проводится по договору. В обоих случаях сначала определяют, на какой вопрос можно ответить, и фиксируют объект; порядок получения материалов и передачи результата при этом различается.

1. Разбор задачи. Вы описываете спор, версию программы, требуемый технический факт и материалы. Мы проверяем, относится ли задача к нашей компетенции и можно ли на неё ответить.
2. Определение объекта и критерия. Согласуем, какой репозиторий, состояние, модули и документы войдут в исследование; фиксируем ограничения.
3. Расчёт срока и стоимости. После просмотра состава материалов оцениваем объём инвентаризации, сборки, автоматизированной и ручной проверки.
4. Получение и фиксация материалов. Объекты принимаются по описи, для файлов рассчитываются контрольные суммы, а работа с ними ведётся в согласованном режиме.
5. Исследование. Эксперт выполняет предусмотренные программой действия, сохраняет промежуточные результаты, проверяет срабатывания и альтернативные причины.
6. Подготовка заключения. Наблюдения, методы, ограничения и выводы излагают отдельно; приложения позволяют проверить расчёты и расположение дефектов.
7. Разъяснение результата. Специалист отвечает на вопросы по проведённому исследованию в допустимой процессуальной форме, не подгоняя выводы под позицию стороны.

Если экспертиза назначена судом, порядок получения материалов, взаимодействия и разъяснений определяет суд. Частное обращение до процесса не даёт специалисту полномочий судебного эксперта, но помогает точно описать техническую сторону ходатайства и сохранить объект.

Конфиденциальность исходного кода

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

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

Абсолютное обещание «код никто не увидит» было бы неверным: в судебном процессе с материалами знакомятся в порядке, установленном законом и судом, а заключение может содержать необходимые фрагменты. Поэтому заранее определяют минимальный объём цитирования, используют идентификаторы файлов и строк, не цитируют секреты без необходимости и просят суд установить режим доступа к материалам.

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

От чего зависят стоимость и срок

Ориентировочная стоимость — от 100 000 ₽, срок — от 10 рабочих дней. Отсчёт начинается после проверки и принятия полного комплекта материалов. Точная оценка зависит не только от числа строк, но и от числа языков и репозиториев, глубины истории и числа веток, воспроизводимости среды, количества требований, числа исследуемых дефектов и необходимости строить испытательный стенд.

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

Чтобы получить предварительную оценку, позвоните по номеру 8 (800) 333-24-09 или опишите задачу в форме на сайте. Кратко опишите предмет спора, технологический стек и примерный состав репозитория; назовите точную версию кода и документ, в котором закреплены требования к нему. Этого достаточно, чтобы определить следующий шаг; исходный код при первом обращении не требуется.