Пн-Пт 8:00 — 19:00;
Сб 10:00 — 17:00
Пн-Пт 8:00 — 19:00; Сб 10:00 — 17:00

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

Почему споры о разработке программного обеспечения становятся сложнее

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

В каких случаях нужна экспертиза программного обеспечения

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

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

Как доказать, что разработчик не выполнил техническое задание

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

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

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

Что устанавливает компьютерно-техническая экспертиза

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

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

Можно ли взыскать стоимость повторной разработки

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

  1. Первоначальное техническое задание и договор.
  2. Материалы, подтверждающие недостатки результата.
  3. Претензии первоначальному исполнителю.
  4.  Документы о расходах на исправление или завершение проекта.
  5. Договор с новым подрядчиком и описание выполненных им работ.
  6. Экспертное исследование технического состояния системы и выявленных недостатков.

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

Когда проводить экспертизу: до суда или в процессе

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

Где заказать экспертизу программного обеспечения для суда

АНО «Судебно-экспертный центр Специалист» может провести предварительную оценку материалов IT-спора и определить возможность компьютерно-технического исследования в пределах компетенции экспертов.
Исследование может быть актуально при конфликтах о разработке сайтов, создании программного обеспечения, внедрении информационных систем, выполнении технического задания и устранении недостатков.
Для первичной оценки подготовьте договор, техническое задание, описание спорного функционала, переписку и доступные версии программного продукта.
Обратитесь в АНО «СЭЦ Специалист», если необходимо установить технические обстоятельства срыва IT-проекта, исследовать качество программного обеспечения или подготовить экспертные материалы для арбитражного спора.