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

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

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

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

С чем обращаются

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

Чаще всего мы разбираем такие ситуации:

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

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

Почему для Python решает окружение

Одна и та же программа на Python на двух машинах может вести себя по-разному, и это не фигура речи. Набор установленных библиотек, версия интерпретатора, переменные окружения и настройки каркаса — Django с Django REST Framework, Flask или FastAPI — собираются в конкретную комбинацию, а код лишь опирается на неё. Поэтому вопрос «почему раньше считало правильно, а теперь нет» решается не только чтением кода — и вам стоит знать это до того, как формулировать задачу эксперту.

Сказывается это так:

• Версии библиотек фиксируют заранее — или не фиксируют. Перечень зависимостей — requirements.txt или pyproject.toml — называет, что просили поставить, а файл блокировки версий (poetry.lock, Pipfile.lock, uv.lock) закрепляет точный набор, к которому привела установка. Без него тот же проект, установленный через полгода, соберёт другие версии и поведёт себя иначе. Восстановить прежнее окружение по одному описанию проекта тогда нельзя — но можно по снимку установленных пакетов или по образу стенда, если их успели снять.
• Типы в проекте могли проверять, а могли и не проверять. Указывать типы данных в Python не обязательно; проект может добавлять аннотации типов и прогонять mypy при сборке, а может не делать ни того ни другого. Что именно выбрал ваш подрядчик — отдельный предмет исследования: там, где проверки не было, часть ошибок вылезала уже у пользователя.
• Секреты лежат на виду чаще, чем в других языках. Пароли к базе и ключи к внешним сервисам в проектах на Python часто хранятся прямо в файлах настроек рядом с кодом и попадают в историю репозитория. Это важно и для исследования, и для того, как вы будете передавать материалы.

Значит, помимо кода нам понадобятся точная версия CPython, снимок установленных пакетов (вывод pip freeze), файл блокировки версий, настройки стендов и те самые входные данные, на которых получился спорный результат. Собрать их несложно, но только пока окружение не переустановлено.

Что чаще всего оспаривают

Чаще всего спорят о трёх вещах, и материалы для каждой свои. Ниже — что мы смотрим и какой ответ получается.

Разберём их по порядку:

• Расчёты и отчёты. Расчёт обычно ведут pandas и NumPy, и предметом становится не только код, но и входные данные, и то, в каком порядке выполнялись шаги. Если расчёт вели в тетради Jupyter — интерактивном документе .ipynb, где код и результат сохраняются вперемешку, — сохранённый вывод может не соответствовать текущему коду, и это уже значимое наблюдение.
• Фоновые задачи. Отложенную работу — рассылки, выгрузки, ночные пересчёты — обычно выполняет Celery, RQ или похожая очередь задач поверх брокера сообщений: промежуточного хранилища вроде Redis или RabbitMQ, через которое программа ставит задачи сама себе. Судьбу конкретной задачи восстанавливают по журналам обработчика, состоянию очереди и хранилищу результатов, пока их не удалили по сроку хранения.
• Обмен с другими системами. Путь конкретной записи прослеживают по идентификаторам и журналам обеих сторон. Частая причина расхождений именно в Python-проектах — изменившийся формат внешнего источника при слишком широкой обработке ошибки: программа с перехватом except Exception продолжает работать, но молча пропускает часть записей.

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

Чем это отличается от аудита кода

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

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

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

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

При достаточных материалах вы получите ответ о следующем:

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

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

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

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

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

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

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

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

Как проверяют спорный расчёт

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

Сравнения такие:

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

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

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

Если передан не исходный код, а дистрибутив

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

Случаев три:

• Кеш байт-кода. Интерпретатор сохраняет рядом с исходником файлы .pyc в каталоге __pycache__ — переработанное представление программы, чтобы не разбирать текст при каждом запуске. Здесь возможны две разные операции: разбор — перечисление инструкций и констант, он выполняется штатными средствами почти всегда, — и восстановление текста, похожего на исходный, которое зависит от инструмента и его версии. Из служебной метки файла видно версию интерпретатора, которая его создала.
• Приложение, упакованное вместе с интерпретатором — например, собранное PyInstaller. Обычно удаётся извлечь тот же кеш байт-кода и работать с ним.
• Перевод в машинный код — Cython или Nuitka. Восстановление исходного текста в прежнем смысле невозможно; исследование ограничивается наблюдаемым поведением и структурой.

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

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

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

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

Код, история и окружение

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

В неё входят:

• полная зеркальная копия каждого репозитория со всеми ветками, метками и историей изменений;
• сведения о слияниях, запросах на изменение, рецензировании кода и связанных задачах;
• версия интерпретатора, описание зависимостей (requirements.txt или pyproject.toml), файл блокировки версий (poetry.lock, Pipfile.lock, uv.lock) и снимок фактически установленных пакетов — вывод pip freeze с рабочего окружения;
• описания сборки и упаковки, образы контейнеров, установочные комплекты и их контрольные суммы;
• тексты условий использования библиотек и уведомления, вошедшие в поставку.

Настройки, данные и следы работы

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

В неё входят:

• файлы настроек и переменные окружения каждого стенда, описания развёртывания — settings.py у Django, файлы Docker и параметры gunicorn или uvicorn;
• настройка протоколирования: что система записывала в спорный период, а что не записывала вовсе;
• схема базы данных, файлы миграций — пронумерованных сценариев, которыми программа сама перестраивает таблицы (у Django они лежат в каталогах migrations, у SQLAlchemy их ведёт Alembic), — и служебная таблица применённых изменений: django_migrations или alembic_version;
• резервные копии и журналы базы, планы выполнения запросов, журнал долго выполняющихся запросов, если он включён, сведения о блокировках и о состоянии пула соединений;
• входные данные спорного расчёта, полученный отчёт и документ, задающий эталон;
• журналы приложения и сервера, записи об ошибках со стеком вызовов, сведения о задачах Celery и состоянии очередей, измеряемые показатели;
• отчёты pytest, данные об охвате кода тестами из coverage.py и отчёты анализаторов — ruff, flake8, pylint, mypy, bandit.

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

Что сохранить прямо сейчас

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

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

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

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

Как передать материалы и не раскрыть лишнего

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

К передаче подготовьте:

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

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

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

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

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

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

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

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

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

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

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

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

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

Что вы получите и в каком формате

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

Формат работы выбирают по стадии спора:

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

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

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

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

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