Экспертиза процесса разработки и сопровождения программного обеспечения нужна, когда спор нельзя разрешить только договором, актами и объяснениями сторон: требуется сопоставить требования с конкретными версиями продукта, восстановить последовательность технических событий и проверить материалы жизненного цикла. Это общее направление программно-компьютерной экспертизы, внутри которого одиннадцать самостоятельных исследований: каждое отвечает на свой практический вопрос и работает со своим набором объектов. Исследование может быть судебным или внесудебным.
Результат исследования не предрешает спор. Эксперт устанавливает технические обстоятельства в пределах специальных знаний, а суд или стороны оценивают договор, ответственность и правовые последствия. Если судебная экспертиза уже назначена, эксперт не принимает файлы напрямую от одной стороны и не даёт ей частный прогноз: вопросы и дополнительные материалы направляются через суд или другой назначивший орган.
Предварительный разбор задачи проводится без оплаты. Файлы для него присылать не нужно: достаточно описать ситуацию и перечислить, что у вас есть. На этом шаге мы определяем и то, с чего обычно начинается затруднение, — какое из одиннадцати направлений отвечает на ваш вопрос.
Когда исследование помогает разрешить спор о разработке ПО
Обратитесь за исследованием, если разногласия относятся к проверяемому состоянию продукта или документированному процессу его создания, а не только к юридическому толкованию договора. Заранее определите дату, версию, среду и конкретные обстоятельства, которые нужно исследовать.
Чаще всего поводом становятся такие ситуации:
- заказчик и исполнитель по-разному оценивают выполненный объём и комплектность результата;
- условия и техническое задание менялись во время проекта;
- сроки сдвигались, а причины и последовательность событий оспариваются;
- переданный продукт не собирается, не запускается или не выполняет часть функций;
- нужно определить стадию готовности перед сменой подрядчика;
- данные системы обработки заявок и мониторинга расходятся с отчётами о сопровождении;
- стороны спорят о качестве или происхождении исходного кода;
- нужно проверить уже подготовленное заключение другого эксперта.
Как выбрать направление под вашу ситуацию
Направления разделены не по технологиям, а по вопросу, на который нужно ответить. Поэтому выбор начинается не с того, на чём написана система, а с того, о чём именно спор. Ниже — четыре типовые формулировки клиента и направления, которые им отвечают; разделение не мешает назначить комплексное исследование, если в одном деле спорят одновременно, например, о техническом объёме и его стоимости.
«Сделано не то, что заказывали»
Спор о содержании результата: что предусматривал договор и что фактически получено. Здесь работают три направления, и различаются они точкой отсчёта:
- Соответствие работ техническому заданию — когда есть письменные требования и нужно проверить их по пунктам: что реализовано, что реализовано иначе, что не работает в описанных условиях.
- Степень готовности программного обеспечения — когда работы прерваны и нужно установить, на какой стадии остановился продукт: собирается ли, проходит ли испытания, пригоден ли к передаче или эксплуатации.
- Объём и стоимость выполненных работ — когда спор о деньгах: какой перечень договорных результатов подтверждён техническими материалами и как он соотносится с оплаченным.
«Сделано плохо»
Спор не о наличии результата, а о его свойствах. Ключевая трудность здесь в критерии: без названного требования «плохо» остаётся оценкой, а не техническим фактом. Подходят два направления:
- Качество исходного кода — когда есть на что опереться: требования договора, согласованный стандарт, измеримые характеристики сборки, тестов и дефектов.
- Сопровождение и соблюдение SLA — когда продукт сдан, но спор идёт о поддержке: заявки, время реакции и восстановления, доступность, повторяющиеся инциденты.
«Сделано не тогда и не теми»
Спор о ходе работ и о происхождении кода — то есть о событиях и их источниках, а не о качестве результата. Таких направлений два:
- Сроки и хронология разработки — последовательность изменений, задержек и технических зависимостей по репозиторию, системе задач и журналам сборки.
- Экспертиза плагиата исходного кода — вопреки названию, устанавливает не плагиат, а технический характер совпадений между двумя кодовыми базами и признаки переработки; вывод о нарушении прав делает суд.
«Заключение уже есть, и оно вызывает сомнения»
Отдельный случай: исследовать нужно не продукт, а документ. Этим занимается одно направление:
- Рецензия на заключение эксперта о процессе разработки программного обеспечения — проверка объектов, методов, ограничений и связи выводов с полученными данными в уже подготовленном заключении.
Если известно, на чём написана система
Семь направлений собраны не по вопросу, а по платформе. Они не заменяют перечисленные выше, а дополняют их: предмет спора остаётся прежним — чаще всего соответствие сделанного техническому заданию, — но объекты, следы и пределы выводов у каждой платформы свои, и это меняет то, что вообще можно установить.
Выбирайте по языку спорной системы:
- Экспертиза исходного кода на Java — корпоративные системы: доработки типовых решений, причины сбоев и потерь документов при обмене, полнота переданного кода, состав библиотек и совпадения кодовых баз.
- Экспертиза исходного кода на Python — сервисы, обработка данных и отчётность: воспроизводимость спорного расчёта и зафиксированность версий библиотек, от которых результат зависит не меньше, чем от самого кода.
- Экспертиза исходного кода на JavaScript — приложения в браузере и на сервере: ошибки интерфейса в конкретных браузерах, расхождения в суммах, разбор собранной сборки, когда исходных текстов нет.
- Экспертиза исходного кода на PHP — сайты и интернет-магазины на «1С-Битрикс», WordPress, Laravel: отделение собственного кода подрядчика от коробочной системы и модулей, объём работ, посторонние вставки, датировка без репозитория.
- Экспертиза исходного кода на C++ — промышленная автоматика, прошивки, расчётные и настольные программы: передан ли исходный код и собирается ли из него спорная программа, причины аварийных завершений и утечек памяти, состав вкомпилированных библиотек.
- Экспертиза исходного кода на C# — учётные системы, настольные программы и веб-сервисы на платформе .NET: восстановление кода из сборок, обфускация, повторяемость сборки, состав пакетов и спор о переносе с прежней платформы.
- Экспертиза исходного кода на Delphi — учётные и отраслевые системы, работающие на предприятиях десятилетиями: что передано заказчику, почему исходники не собираются, что содержат экранные формы и база данных, когда исполнителя уже не найти.
Не знаете язык — это нормально и выяснять его самостоятельно не обязательно. Язык обычно назван в техническом задании или в актах, его знает подрядчик, а если спор о сайте, серверная часть чаще всего написана на PHP, браузерная — на JavaScript; программы для оборудования и расчётов обычно пишут на C++, а корпоративные учётные системы под Windows — на C#. Если ясности нет, направление определим на предварительном разборе по описанию спора: для выбора между «сделано не то» и «сделано плохо» язык вообще не важен.
Отдельный случай — когда спор целиком о сайте: что было опубликовано по адресу, работает ли ресурс, сколько стоила его разработка. Тогда точнее начать с экспертизы веб-сайтов: там свои шесть направлений и своя срочность, потому что спорная версия страницы исчезает при ближайшем обновлении.
Объекты исследования и сохранение цифрового состояния
Исследуется не абстрактный «проект», а индивидуализированный объект: версия, сборка, репозиторий, выгрузка системы задач или набор журналов за определённый период. Состояние нужно зафиксировать так, чтобы другой специалист мог понять происхождение данных и повторить существенные операции.
Технические объекты
Состав зависит от вопроса и архитектуры продукта. В одном исследовании может использоваться несколько взаимосвязанных объектов, но для каждого указываются версия, источник и роль.
В группу входят:
- исходный код и полный экспорт репозитория с ветками, тегами и историей;
- дистрибутивы, контейнеры, образы, пакеты и контрольные суммы сборок;
- среды разработки, тестирования и эксплуатации с конфигурацией;
- базы данных, схемы, миграции, программные интерфейсы и компоненты обмена;
- системы задач, средства автоматической сборки и развёртывания (CI/CD), тестовые отчёты, журналы и мониторинг.
Документы и контекст
Документы задают критерии сопоставления, но эксперт отдельно проверяет, какие редакции действовали и можно ли связать их с исследуемым техническим состоянием.
В эту группу входят:
- договор, техническое задание, спецификации и критерии приёмки;
- календарный план, перечень запланированных работ, ведомость этапов и согласованные изменения;
- акты, отчёты, протоколы испытаний, заявки и соглашение об уровне обслуживания (SLA);
- переписка и протоколы встреч, относящиеся к изменению требований;
- определение суда или постановление о назначении экспертизы.
Предпочтителен штатный экспорт системы, а не выборочные снимки экрана. Для файлов фиксируют имя, размер, контрольную сумму и способ получения; для журналов — источник времени, часовой пояс, период и признаки возможного редактирования. Отбор только выгодных сообщений или записей истории без контекста может исказить картину.
Сразу о том, чего стоит копия, снятая своими силами. Она доказывает меньше, чем кажется: происхождение подтверждается вашими словами, и вторая сторона заявит, что файлы могли быть изменены. Делать её всё равно нужно — она задаёт то состояние, с которым потом сверяются, — но если объект ключевой для спора, до обращения в суд доступно нотариальное обеспечение доказательств, а после возбуждения дела материалы получают через суд.
Действовать здесь стоит раньше, чем начнётся переписка: доступы к системам отзывают, журналы вытесняются по мере накопления, а среды перенастраивают под текущие задачи. Фиксируйте то, что принадлежит вам или к чему у вас есть законное право доступа; материалы, находящиеся у другой стороны, получают через суд по ходатайству об истребовании. В ходатайстве придётся обосновать, почему получить их самостоятельно невозможно, — иначе в нём откажут, — и назвать материалы конкретно: репозиторий, ветку, период журналов, версию сборки. Если сторона их так и не представит, эксперт исследует то, что поступило, и прямо указывает, на какие вопросы ответить невозможно; при недостаточности материалов он направляет назначившему органу сообщение о невозможности дать заключение. Вывод в таком случае не появляется, но и молчаливого «эксперт не нашёл» тоже не будет.
Само по себе уклонение от передачи материалов тоже не проходит бесследно. Процессуальные кодексы предусматривают последствия для стороны, которая удерживает у себя необходимые для экспертизы объекты и не представляет их по требованию суда: суд вправе разрешить вопрос без этих материалов и оценить поведение стороны при исследовании доказательств. Как именно это применить в вашем деле, решают суд и ваш представитель, но рассчитывать, что «нет материалов — нет спора», другой стороне не стоит.
И главное — ничего не «прибирайте» в проекте перед передачей. Необратимого здесь больше, чем кажется, и восстановить потом не удастся ничего из перечисленного:
- операции с историей репозитория — хранилища исходных текстов, где сохраняется каждая правка: перезапись ветки поверх прежней, склейка и переписывание правок, удаление веток и меток, пересборка выпуска поверх спорного архива;
- журналы серверов и приложений: они не хранятся вечно и вытесняются новыми записями по мере накопления;
- заявки, задачи и переписка в рабочих системах, удалённые при «наведении порядка» или при закрытии проекта;
- переустановка зависимостей и перенос репозитория к другому поставщику: часть служебных сведений при этом не переносится.
Поэтому порядок один: сначала полная копия, потом любые работы с проектом. После того как состояние зафиксировано, систему можно обслуживать штатно, включая обновления безопасности.
Конфиденциальность и объём передаваемого
Здесь клиент чаще всего и останавливается: отдавать исходный код и выгрузки систем страшно, особенно если спор с бывшим подрядчиком, который остаётся на рынке. Порядок обращения с материалами согласуют до передачи: защищённый канал, ограниченный круг допущенных лиц, срок хранения и подтверждаемое удаление после работ.
Два обстоятельства стоит знать заранее. Первое: объём передаваемого определяется вопросом, а не «на всякий случай» — для спора о сроках нужна история изменений, а не рабочие базы с персональными данными клиентов, и лишнее лучше не передавать вовсе. Второе: соглашение о конфиденциальности связывает эксперта, но не участников дела — материалы, поступившие в суд, и само заключение становятся доступны другой стороне. При назначенной судом экспертизе объекты идут через назначивший орган, и их дальнейшую судьбу определяет он.
Предварительный прогноз до полного исследования
Организационная проверка отвечает, относится ли задача к компетенции специалистов и читаются ли файлы. Содержательный прогноз начинается позже — после изучения достаточной выборки требований, версий и технических материалов. Эксперт может указать вероятный тип вывода, ожидаемую степень определённости и данные, способные изменить оценку.
Прогноз может быть благоприятным, неблагоприятным или показывать, что определённый ответ невозможен. Он помогает уточнить вопросы, дополнить комплект либо не заказывать полную работу вслепую, но не является заключением, гарантией нужного результата или обещанием исхода дела. Условия и формат такой работы согласуются до передачи материалов.
Вопросы эксперту о процессе разработки программного обеспечения
При судебной экспертизе окончательный круг вопросов определяет суд, а в иных предусмотренных законом процедурах — орган или лицо, назначившие экспертизу. Эксперт отвечает в пределах специальных знаний и представленных материалов и не изменяет поставленные вопросы по своей инициативе; при их неясности, выходе за пределы компетенции или недостаточности материалов он сообщает об этом назначившему органу в установленном порядке.
До назначения стороны вправе предложить свои формулировки, и от их точности зависят полнота и определённость ответа. Правило одно и простое: вопрос называет объект — версию, сборку, репозиторий, период, — называет проверяемый критерий и решает одну задачу. Вопросы о нарушении договора, виновности, размере ответственности и о том, какое решение принять суду, эксперту не адресуют. Подробные перечни под каждую задачу собраны на страницах направлений, а здесь — три примера, показывающие саму форму:
- Какие результаты этапа, предусмотренного приложением №… к договору, фактически представлены в репозитории и сборках по состоянию на … (дата, часовой пояс)?
- Соответствует ли сборка с контрольной суммой … требованиям пунктов … технического задания в редакции от …?
- Достаточен ли переданный комплект для самостоятельной сборки и запуска продукта версии … без обращения к исполнителю и чего в нём не хватает?
Сравните их с формулировкой «какие характеристики качества кода установлены»: в ней нет ни объекта, ни критерия, ни даты, и ответить на неё проверяемо нельзя. Именно поэтому вопросы под конкретную задачу лучше брать на странице соответствующего направления, где названы и объекты, и критерии.
Эксперт отдельно оценивает, достаточно ли представленных материалов для ответа на каждый вопрос, и указывает ограничения исследования в заключении. Это оценка пригодности объектов для исследования, а не оценка достаточности доказательств по делу.
Техническая хронология и состояние продукта не отвечают на вопросы о виновности подрядчика, его мотивах, намерении затянуть работу или юридической существенности недостатков. Эти обстоятельства суд или орган расследования устанавливает по совокупности доказательств, а эксперт ограничивается специальными знаниями о разработке ПО. Если он выходит за эту границу, заключение не утрачивает силу автоматически, но появляются основания проверять компетентность и оспаривать относимость, допустимость, достоверность и обоснованность выводов. В зависимости от значения ошибки можно просить допрос, дополнительную или повторную экспертизу, а при существенном процессуальном нарушении — ставить вопрос о недопустимости заключения по правилам соответствующего процесса.
Методы, стандарты и проверяемость вывода
Метод выбирают под вопрос и объект: документальное сопоставление, воспроизводимая сборка, функциональное тестирование, исследование репозитория, анализ журналов, статический или динамический анализ. Автоматический инструмент даёт измерение или наблюдение, но не заменяет объяснение исходных данных, ограничений и альтернатив.
Стандарты жизненного цикла и качества применяются, если они включены в договор, задание, обязательные требования либо выбраны как обоснованный ориентир: это могут быть национальные стандарты серии ГОСТ Р на процессы жизненного цикла и на судебную компьютерно-техническую экспертизу, международные стандарты качества программного обеспечения, отраслевые методики. Само по себе упоминание гибких или последовательных моделей разработки, национального или международного стандарта качество процесса не доказывает. В заключении должно быть понятно, почему выбран критерий, к какой версии объекта он применён и можно ли проверить результат.
Отдельно проверяют альтернативные объяснения. Отказ продукта может быть следствием дефекта кода, настройки среды, объёма данных, действий пользователя или изменения смежной системы, и заключение, в котором рассмотрена одна версия, слабее того, где остальные названы и отклонены с обоснованием.
Границы специальных знаний и комплексная экспертиза
IT-эксперт описывает технические факты, но не подменяет суд, юриста, оценщика или специалиста по расследованию инцидентов. Разделение компетенций защищает вывод от правовых предпосылок, которые не были исследованы специальными методами.
Граница проходит так:
- нарушение договора, виновность, недобросовестность и правовые последствия оценивает суд;
- рыночную стоимость и убытки исследует специалист соответствующей оценочной или экономической компетенции;
- сходство кода само по себе не означает нарушение авторского права;
- процент готовности допустим только при объяснённой декомпозиции и критериях;
- отсутствие найденной уязвимости не гарантирует отсутствие всех уязвимостей;
- причина инцидента может потребовать отдельной цифровой криминалистики.
Когда вопросы дела не помещаются в одну компетенцию, назначают комплексное исследование: каждый эксперт отвечает в своих пределах, а выводы соотносятся между собой. Планируют и считают такую работу отдельно.
Формат результата и подготовка обращения
Консультация помогает выбрать направление и вопросы, внесудебное исследование оформляет самостоятельный технический анализ, судебная экспертиза проводится по определению или постановлению, а рецензия проверяет уже существующее заключение. Эти форматы не взаимозаменяемы и согласуются с процессуальной задачей. Заранее установленной силы у заключения нет: суд оценивает его наравне с другими доказательствами.
Между судебной экспертизой и внесудебным исследованием есть различие, которое стороны часто упускают: при судебной эксперт предупреждается об уголовной ответственности за заведомо ложное заключение, во внесудебном исследовании такого предупреждения нет вовсе. Содержание работы при этом совпадает — те же объекты, методы и требования к проверяемости, — но при оценке документа это различие учитывают.
С этим связано то, о чём лучше знать заранее. Если специалист до назначения выполнял для одной из сторон разбор, консультацию или внесудебное исследование, это раскрывают при рассмотрении его кандидатуры, и другая сторона вправе заявить отвод. Само по себе такое участие эксперта не порочит, а решение о назначении и об отводе принимает суд, но планировать работу стоит с учётом этого обстоятельства.
До начала работы полезно подготовить следующее:
- хронологию проекта: когда что согласовывалось, передавалось и оспаривалось;
- перечень версий и сред с указанием, какая из них спорная;
- таблицу «требование — ожидаемый результат — фактический объект — источник данных»;
- перечень пробелов: чего у вас нет и у кого это находится.
Не изменяйте спорную среду без фиксации и сохраните полный экспорт систем. После изучения комплекта специалист определит компетенцию, предложит вопросы и скажет, возможен ли содержательный предварительный прогноз. Позвоните по номеру 8 (800) 333-24-09 или оставьте заявку — разбор задачи проводится без оплаты, и файлы для него присылать не нужно.
Проведение экспертизы по уголовному делу
Судебная экспертиза по уголовному делу производится государственными судебными экспертами и иными экспертами из числа лиц, обладающих специальными знаниями.
Согласно постановлению Пленума Верховного Суда Российской Федерации от 21 декабря 2010 г. № 28 «О судебной экспертизе по уголовным делам», негосударственными судебно-экспертными учреждениями признаются некоммерческие организации, созданные на основании Гражданского кодекса Российской Федерации и Федерального закона «О некоммерческих организациях» и ведущие судебно-экспертную деятельность согласно своим уставам.
По сведениям организации, проведение судебных экспертиз предусмотрено её уставом (см. действующую редакцию в разделе «Документы организации»). Это само по себе не означает автоматического поручения любой экспертизы. Возможность поручить конкретное исследование определяет назначающий орган с учётом предмета дела, квалификации эксперта, оснований для отвода и действующего перечня экспертиз, выполняемых только государственными судебно-экспертными организациями.
