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

В суде спор о корпоративной системе почти всегда сводится к одному вопросу: соответствует ли сделанное техническому заданию и договору. Сбои под нагрузкой, потерянные документы, испорченные данные обычно всплывают внутри этого же спора как доводы сторон о том, принят результат или нет. Одним чтением кода на него не ответишь. Java редко встречается в чистом виде: учётная или ERP-система, биллинг, портал, торговая платформа состоят из собственного кода, готовых платформ вроде Spring и Hibernate, десятков сторонних библиотек, базы данных, очередей сообщений, обмена с другими системами и настроек той среды, где всё это работает. Поставляют систему обычно не исходными текстами, а собранными архивами с байт-кодом — промежуточным представлением программы, понятным виртуальной машине Java. Поэтому пункт задания проверяется на конкретной версии и в воспроизведённой среде, а не по описанию. Экспертиза исходного кода на Java — специализированное направление экспертизы процесса разработки программного обеспечения. На выходе вы получаете заключение, которое можно представить в суд или использовать в переговорах.

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

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

Когда нужна экспертиза системы на Java

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

Исследование помогает в таких случаях:

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

Если ваш вопрос звучит иначе, точнее начать с соседнего исследования: о качестве кода — экспертиза качества исходного кода, о заимствовании — сравнение исходного кода, о деньгах и объёме — экспертиза объёма и стоимости выполненных работ. Если спорная система написана на другом языке, начните с экспертизы исходного кода на Python; если спор о браузерной части сайта или о сервере на Node.js — с экспертизы исходного кода на JavaScript.

Чем это отличается от аудита кода и от общей компьютерной экспертизы

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

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

Из чего состоит корпоративная система на Java

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

В типичной системе исследуют такие слои:

• Прикладной каркас — чаще всего Spring и Spring Boot, реже Jakarta EE на сервере приложений Tomcat или WildFly. Значительная часть поведения задаётся не строками кода, а конфигурацией: профилями окружений, файлами настроек, признаками включения отдельных механизмов. Одна и та же сборка на двух стендах — то есть на двух отдельных площадках, где система развёрнута, — может работать по-разному, поэтому конфигурацию исследуют вместе с кодом.
• Работа с базой данных — Hibernate или другая реализация JPA, отображающая объекты программы на таблицы, и пул соединений вроде HikariCP. Часть дефектов видна уже при чтении отображений и на небольшом стенде: лишние обращения к базе при обходе связанных объектов, неверные границы транзакций, каскадные удаления, расхождение схемы и отображения. На промышленных объёмах меняются последствия — то, что незаметно на сотне записей, останавливает работу на миллионах.
• Изменения структуры базы данных — сценарии миграций Liquibase или Flyway и служебная таблица, в которой инструмент отмечает применённое: DATABASECHANGELOG или flyway_schema_history. По ним восстанавливают, что и когда меняли в схеме.
• Обмен сообщениями — Kafka, RabbitMQ и подобные. Исследуют устройство очередей, потребителей и смещения — отметки о том, до какого места потребитель дочитал поток сообщений, — а также повторные обработки и очередь недоставленных сообщений — отдельное место, куда складывают то, что обработать не удалось, если такая очередь предусмотрена.
• Обмен с другими системами — бухгалтерскими, банковскими, государственными, партнёрскими. Проверяют соответствие фактического обмена описанному контракту, обработку повторов и ошибок, согласование версий.
• Среда выполнения — сервер приложений или контейнеры Docker под управлением Kubernetes, ограничения по памяти и процессору, параметры виртуальной машины Java. Несогласованность ограничений среды и настроек виртуальной машины — обычная причина перезапусков, которую ошибочно приписывают коду.
• Наблюдаемость — журналы приложения через Logback или Log4j, измеряемые показатели работы, сквозные идентификаторы запросов, журналы сборки мусора, записи Java Flight Recorder, дампы потоков и кучи. Это основной материал для вопросов о сбоях и деградации.

Этим разделением эксперт и работает. Оно позволяет показать, что медленный отчёт вызван обращениями к базе в цикле, а не «слабым сервером»: сначала это видно в коде и на стенде, а затем подтверждается измерениями на реальных данных — планами выполнения запросов, журналом медленных запросов, сведениями о блокировках и о состоянии пула соединений. Оговорка обычная: подтверждают только те источники, которые в этой системе действительно велись, поэтому сначала выясняют, что и как долго она записывала. Так же разбирают и потерю документа: он может исчезнуть не в коде, а на стороне смежной системы, вернувшей ошибку, которую обработчик проигнорировал.

Что может установить эксперт

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

Задачи обычно распадаются на три группы:

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

Есть вопросы, где нужна особая осторожность. «Система работает медленно» — не техническое утверждение, пока не назван измеримый критерий: какая операция, при каком объёме данных, за какое время и по какому пункту требований. Гарантия доставки сообщений в очередях обычно означает «не менее одного раза», поэтому повторная обработка одного и того же сообщения — штатное поведение, а не дефект; дефект — отсутствие защиты от повторов там, где она требовалась. И отсутствие записи в журнале не означает, что события не было: сначала эксперт выясняет, что именно эта система записывала в тот период, и настройка протоколирования сама становится объектом исследования.

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

Как проверяют соответствие техническому заданию

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

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

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

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

Если исходный код вам не передали или он неполон

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

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

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

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

Какие объекты исследуются

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

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

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

Исследуются такие материалы:

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

Сборка, артефакты и байт-код

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

К этой группе относятся:

• файлы описания сборки для Maven или Gradle — pom.xml и build.gradle, — включая многомодульные проекты и общее управление версиями библиотек через BOM;
• архивы JAR, WAR, EAR, служебные записи внутри них, образы контейнеров и установочные комплекты;
• class-файлы и их разбор штатной утилитой javap: по номеру формата видно, для какой версии платформы предназначен каждый класс;
• отладочная информация — таблицы номеров строк и имён переменных, от которых зависит, насколько подробно читается восстановленный текст;
• сведения внутреннего хранилища артефактов — Nexus или Artifactory: что и когда публиковалось и загружалось.

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

Конфигурация, база данных и данные

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

Сюда входят:

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

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

Журналы, сообщения, показатели и дампы

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

Сюда входят:

• журналы приложения и сервера, сообщения об ошибках вместе с цепочкой вызовов, сквозные идентификаторы запросов;
• выгрузки сообщений, сведения о смещениях потребителей и об очереди недоставленных сообщений, если она настроена;
• измеряемые показатели работы, записи сквозной трассировки — прослеживания запроса через все сервисы, — и журналы сборки мусора;
• дамп потоков, снятый через jstack, — снимок того, чем были заняты потоки программы, и дамп кучи из jmap — снимок объектов, которые программа держала в памяти;
• отчёты тестов JUnit и интеграционных прогонов на Testcontainers, данные об охвате кода из JaCoCo, отчёты анализаторов — SonarQube, Checkstyle, SpotBugs, PMD, Error Prone — и результаты нагрузочных испытаний;
• журналы сборочной системы, отметки о развёртывании и результаты приёмочных проверок.

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

Как сохранить материалы для исследования

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

До передачи материалов эксперту сделайте следующее:

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

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

Что передавать и как защитить данные

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

Когда до передачи дойдёт, подготовьте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Форматы работы

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

Доступны такие форматы:

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

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

Что вы получите и как использовать результат

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

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

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

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

При первом обращении файлы присылать не нужно. Опишите спор, наметьте вопросы и перечислите, что у вас есть: репозитории, сборки, настройки стендов, журналы, договор и техническое задание. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — мы проверим, относится ли задача к нашей компетенции, предложим безопасный порядок передачи материалов и скажем, каких данных не хватает для расчёта.