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

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

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

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

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

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

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

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

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

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

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

На результат влияют:

• Версии библиотек фиксируют с разной точностью. requirements.txt или pyproject.toml описывает зависимости и ограничения, а файл блокировки (poetry.lock, Pipfile.lock, uv.lock) сохраняет разрешённый инструментом набор версий с учётом условий платформы. Для воспроизведения нужны также реализация и сборка интерпретатора, ОС и архитектура, источники и хеши пакетов, системные и нативные зависимости. Наиболее надёжен проверенный образ окружения; lock-файл и список пакетов рассматривают как самостоятельные источники с собственными ограничениями.
• Проверка типов не обязательна. Проект может использовать аннотации и запускать mypy при сборке, но интерпретатор сам по себе такую проверку не выполняет. Поэтому выясняют, какие проверки действительно входили в процесс разработки и сборки.
• Секреты могут попасть в проект. Пароли к базе и ключи внешних сервисов иногда сохраняют в настройках рядом с кодом или в истории репозитория. Это учитывают при подготовке материалов.

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

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

Для трёх распространённых групп споров нужны разные материалы и методы.

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

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

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

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

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

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

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

При достаточных материалах предметом исследования могут быть:

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

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

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

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

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

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

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

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

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

Методика включает два сравнения. Они отвечают на разные вопросы, и причины расхождений в них различаются:

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

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

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

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

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

Возможны три ситуации:

• Кеш байт-кода. Интерпретатор может сохранять файлы .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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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