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

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

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

АНО «СЗЭПЦ» проводит экспертизы с 1990 года и относится к первым негосударственным экспертным организациям на территории Российской Федерации. АНО «СЗЭПЦ» — некоммерческое судебное экспертное учреждение, зарегистрировано Министерством юстиции Российской Федерации под учетным номером 7814053482. Заключения АНО принимают арбитражные суды и суды общей юрисдикции более чем в сорока регионах. Ниже описано, что устанавливает экспертиза процесса программного обеспечения, как восстанавливается хронология разработки по репозиторию и задачам, как исследуется использование программ в организации, как проходит проведение экспертизы программного обеспечения и какие вопросы ставить суду.

Что такое экспертиза процесса программного обеспечения

Процесс создания и сопровождения программы состоит из стадий, которые описывает ГОСТ Р ИСО/МЭК 12207-2010 о процессах жизненного цикла программных средств: определение требований, проектирование, конструирование, интеграция, тестирование, передача, сопровождение, а также поддерживающие процессы — управление конфигурацией, документирование, обеспечение качества, верификация и валидация. Каждая стадия оставляет следы: документы, записи в системах, версии кода, протоколы.

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

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

Отличие от экспертизы результата

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

Что устанавливает экспертиза процесса разработки

Круг задач зависит от спора. Типовые обстоятельства:

последовательность и сроки работ по этапам, фактическая дата готовности каждой функции;

состав исполнителей по учетным записям в системе контроля версий и в системе управления задачами, участие лиц, не указанных в договоре;

соблюдение согласованной методологии: этапы, приемка, демонстрации, отчетность;

проведение тестирования, код-ревью, автоматических проверок и их результаты;

управление требованиями: когда и по чьей инициативе требования менялись, как это отражалось на плане;

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

трудозатраты по данным систем учета времени и по объему изменений в коде;

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

Эксперт устанавливает факты процесса. Вывод о том, чья вина в срыве сроков в правовом смысле и нарушен ли договор, делает суд.

Следы процесса разработки

Процесс разработки оставляет больше объективных следов, чем кажется сторонам спора. Их сочетание позволяет восстановить картину без опоры на показания участников.

Система контроля версий

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

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

Система управления задачами

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

Сборки и автоматические проверки

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

Документы процесса

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

Методология разработки и ее соблюдение

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

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

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

Процесс тестирования

Стандарты серии ГОСТ Р 56920 описывают процессы тестирования программного обеспечения. Договор может ссылаться на них или содержать собственные требования: доля покрытия кода тестами, обязательное регрессионное тестирование перед выпуском, приемочные испытания по программе и методике.

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

Безопасная разработка

Для систем, к которым предъявляются требования по защите информации, договор может предусматривать процессы безопасной разработки по стандарту ГОСТ Р 56939 о разработке безопасного программного обеспечения: анализ угроз, проверка кода на уязвимости, контроль сторонних компонентов. Эксперт устанавливает, выполнялись ли эти процессы, по документам и следам в системах разработки.

Хронология разработки и трудозатраты

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

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

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

Скрытый субподряд

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

Передача проекта и смена команды

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

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

Вторая половина предмета экспертизы — использование программы после создания или приобретения. Здесь вопросы ставят правообладатели, налоговые органы, работодатели и сами организации.

Объем использования и лицензии

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

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

Инвентаризация программных активов

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

Применение программы в деятельности организации

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

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

Использование программ работниками

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

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

Какая версия программы действовала на дату события

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

Программа как инструмент создания документа

Когда спорный документ или расчет сформирован программой, вопрос о его достоверности часто сводится к тому, какая программа и в какой версии его создала и какими данными она пользовалась. Экспертиза устанавливает, какой программой сформирован файл, соответствует ли это заявленному порядку работы организации, применялась ли программа в спорный период. Подробная методика по отдельным файлам описана на странице об экспертизе обстоятельств создания и использования файлов и баз данных, а для систем на платформе «1С» — на странице экспертизы 1С.

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

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

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

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

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

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

Независимая экспертиза программного обеспечения

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

Техническая экспертиза программного обеспечения

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

Судебная экспертиза программное обеспечение и процесс его создания

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

Выпуск исправлений и управление версиями

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

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

Облачные сервисы по подписке

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

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

Реальные данные в тестовой среде

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

Экспертиза процесса программного обеспечения устанавливает, какие данные передавались исполнителю, когда и каким способом, где они хранились, использовались ли средства обезличивания, предусматривал ли договор или регламент порядок работы с тестовыми данными и соблюдался ли он. Источники — переписка, журналы передачи файлов, конфигурации тестовых стендов, история репозитория, где иногда оказываются файлы с данными. Правовая оценка обработки персональных данных по Федеральному закону от 27 июля 2006 года № 152-ФЗ остается за судом и уполномоченным органом.

Смежные исследования

Экспертиза процесса программного обеспечения нередко сочетается с другими исследованиями.

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

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

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

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

Нормативная база

Процессуальный порядок: Федеральный закон от 31 мая 2001 года № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации», положения которого по статье 41 распространяются на негосударственных экспертов; статьи 79–87 Гражданского процессуального кодекса Российской Федерации; статьи 82–87 Арбитражного процессуального кодекса Российской Федерации. Большинство споров о разработке и использовании программ рассматривают арбитражные суды, в том числе Суд по интеллектуальным правам, поэтому применяются разъяснения постановления Пленума Высшего Арбитражного Суда Российской Федерации от 4 апреля 2014 года № 23 и постановления Пленума Верховного Суда Российской Федерации от 23 апреля 2019 года № 10.

Договорные отношения: глава 37 Гражданского кодекса Российской Федерации о подряде, в том числе статьи 708 о сроках выполнения работ, 716 о приостановлении работ при обстоятельствах, зависящих от заказчика, 718 о содействии заказчика; глава 38 о научно-исследовательских и опытно-конструкторских работах; глава 39 об оказании услуг; статья 431.2 о заверениях об обстоятельствах.

Права на программы: статьи 1259, 1261 Гражданского кодекса об охране программ; статья 1286 о лицензионном договоре; статьи 1295 и 1296 о служебных программах и программах, созданных по заказу; статья 1301 о компенсации.

Налоговые нормы: подпункт 26 пункта 1 статьи 264 Налогового кодекса Российской Федерации о расходах на приобретение права использования программ; подпункт 26 пункта 2 статьи 149 о передаче прав на программы из единого реестра.

Стандарты: ГОСТ Р ИСО/МЭК 12207-2010 о процессах жизненного цикла программных средств; стандарты серии ГОСТ Р 56920 о тестировании программного обеспечения; ГОСТ Р 56939 о разработке безопасного программного обеспечения; ГОСТ 34.602-2020 о техническом задании на автоматизированную систему; ГОСТ Р ИСО/МЭК 27037-2014 о сборе и сохранении цифровых свидетельств; ГОСТ Р 34.11-2012 о функции хэширования.

Содействие заказчика и срыв сроков

Статья 718 Гражданского кодекса обязывает заказчика содействовать подрядчику, а статья 716 обязывает подрядчика предупредить заказчика и приостановить работу, если выполнение зависит от обстоятельств на стороне заказчика. В разработке программ это означает: предоставление требований, доступов, тестовых данных, ответы на вопросы, участие в демонстрациях и приемке.

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

Назначение экспертизы в суде

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

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

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

обязать стороны сохранить эти данные в неизменном виде до окончания экспертизы;

истребовать сведения у облачных сервисов, если системы размещались там и стороны не могут выгрузить их сами;

предоставить эксперту доступ к устройствам и серверам, на которых использовалась программа, и к журналам серверов лицензий;

определить порядок обращения с исходным кодом и внутренней перепиской как с конфиденциальными сведениями.

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

Вопросы эксперту

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

Вопросы о процессе разработки

Какова последовательность и фактические сроки выполнения работ по этапам по данным системы контроля версий, системы управления задачами и системы сборки?

Под какими учетными записями вносились изменения в исходный код в указанный период? Относятся ли они к лицам, указанным в договоре?

Проводились ли демонстрации результатов, испытания этапов и тестирование в порядке, предусмотренном договором и согласованной методологией?

Вносились ли изменения в историю репозитория после определенной даты?

Вопросы о трудозатратах и содействии

Соответствуют ли объем изменений в коде и закрытые задачи трудозатратам, указанным в актах за соответствующие периоды?

Какие задачи ожидали ответа, решения или доступа со стороны заказчика и какова продолжительность ожидания?

Сколько раз и когда изменялись требования к указанным функциям, по инициативе какой стороны?

Вопросы об использовании программного обеспечения

На каких устройствах и в какие периоды была установлена и использовалась программа? Каково число одновременных пользователей?

Какие редакции и модули программы применялись? Соответствует ли фактическое использование условиям лицензионного договора?

Выполнялись ли в программе операции по формированию документов и учету в указанный период? Каков их объем?

Какая версия программы действовала на указанную дату и какие изменения в ней были по сравнению с предыдущей?

Вопросы о вине, нарушении договора и правомерности расходов эксперту не ставятся.

Проведение экспертизы программного обеспечения

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

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

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

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

Как оценить готовое заключение

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

Категории дел

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

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

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

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

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

Налоговые споры о расходах на приобретение прав использования программ и о передаче прав.

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

Корпоративные конфликты вокруг программного продукта как актива компании.

Споры о передаче проекта от одного исполнителя другому.

Досудебное исследование

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

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

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

Распределенные команды и аутсорсинг

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

Эксперт составляет карту участия: какие учетные записи вносили изменения в какие модули, в какие периоды, сколько задач закрыли. Отдельно устанавливается, какие изменения внесли специалисты заказчика: если заказчик сам правил код, а потом предъявил претензии к качеству, это существенное обстоятельство.

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

Инфраструктура разработки и доступы

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

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

Корпоративный конфликт вокруг программного продукта

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

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

Государственные контракты и отчетность

Контракты на разработку по Федеральному закону от 5 апреля 2013 года № 44-ФЗ содержат жесткие сроки этапов и требования к отчетной документации. Приемочная экспертиза по статье 94 закона проверяет результат этапа, а спор о просрочке нередко упирается в процесс: когда заказчик согласовал проектные решения, когда предоставил исходные данные, когда исполнитель передал результат на приемку.

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

Экспертиза разработки по договору с поэтапной оплатой

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

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

Оценка трудоемкости: методики и их пределы

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

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

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

Внедрение программы у заказчика

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

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

Настройка готовых решений и разработка

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

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

Сотрудники и сторонние открытые проекты

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

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

Что стоит фиксировать заказчику с первого дня

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

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

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

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

Предварительный анализ показывает, какие вопросы действительно повлияют на исход и какие данные нужно сохранить заранее.

Что передать для экспертизы

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

копия репозитория с полной историей всех веток и меток, а не архив текущих файлов;

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

журналы системы сборки и развертывания, результаты автоматических проверок;

договор, техническое задание, согласованная методология, планы, отчеты, акты, протоколы встреч и демонстраций;

переписка о требованиях, согласованиях и задержках;

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

сведения об учетных записях участников разработки и их принадлежности.

Главное правило: не переписывать историю репозитория, не удалять ветки и задачи, не отключать облачные сервисы до экспертизы.

Сроки

Срок зависит от длительности проекта, объема репозитория и системы задач, числа участников и вопросов. Исследование процесса тестирования и выпуска версий занимает 5–10 дней, исследование инфраструктуры разработки и передачи проекта 5–12 дней. Экспертиза процесса разработки на соответствие методологии и договору, исследование хронологии разработки и трудозатрат и исследование обстоятельств использования программного обеспечения в организации требуют 5–15 дней: нижняя граница относится к короткому проекту с одной командой, верхняя — к многолетней разработке с несколькими исполнителями. Рецензия на чужое заключение готовится за 4–9 дней. Инвентаризация установленного программного обеспечения оценивается после предварительного анализа по числу устройств. Если эксперт ждет выгрузки из облачных сервисов или данные у другой стороны, срок продлевается на время их получения.

Повторная экспертиза и рецензия

Неполное заключение восполняется дополнительной экспертизой, необоснованное — повторной по статье 87 процессуальных кодексов. Типичные дефекты процессных заключений: исследована копия текущих файлов без истории; не проверено, переписывалась ли история; вывод о трудозатратах сделан по одному источнику; не учтено расхождение часов разных систем; не указана методика оценки трудоемкости; эксперт сделал вывод о виновности стороны в срыве сроков. Эти дефекты показывает рецензия специалиста. Судебная коллегия по экономическим спорам Верховного Суда Российской Федерации в определении от 25 января 2018 года по делу № 305-ЭС17-11486 подтвердила, что рецензия образует мотивированные возражения, которые суд обязан рассмотреть.

Возражения оппонента

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

«Заказчик сам затягивал сроки». Проверяется по системе задач и переписке: время ожидания ответов, изменения требований, предоставление доступов.

«Историю репозитория никто не менял». Эксперт сопоставляет ее с внешними источниками и указывает, есть ли расхождения.

«Программа установлена, но не использовалась». Проверяется по журналам запусков, серверам лицензий и данным, созданным в программе.

Стоимость и сроки

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

Типичные ошибки сторон

Договор с оплатой по трудозатратам не требует вести учет времени в системе задач, и проверить акты не по чему.

Исполнитель ведет репозиторий на своих серверах, и заказчик не имеет к нему доступа до конфликта.

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

После начала спора репозиторий переносят на другую площадку без истории.

Заказчик подписывает акты этапов, не проверив, соответствуют ли они данным систем.

Облачные учетные записи и ключи подписи оформлены на сотрудника исполнителя.

Инвентаризацию программ проводят только после претензии правообладателя.

Вопросы о стоимости работ ставят компьютерно-техническому эксперту, а о фактических сроках — экономисту.

Распространенные заблуждения

Заблуждение первое: важен только результат, процесс суду не интересен. В спорах о сроках, трудозатратах и правах на код именно процесс решает дело.

Заблуждение второе: если работа сдана, акты подтверждают трудозатраты. Акты — заявление исполнителя. Данные репозитория и системы задач показывают, что было сделано фактически.

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

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

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

Заблуждение шестое: эксперт определит, кто виноват в срыве сроков. Эксперт установит, что и когда происходило, сколько ждали ответов и доступов. Вывод о вине делает суд.

Что делать, если проект сорван и назревает спор

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

Шаг второй. Соберите договор, методологию, планы, акты, отчеты, протоколы демонстраций и переписку о требованиях и сроках.

Шаг третий. Зафиксируйте, на кого оформлены инфраструктура, облачные учетные записи и ключи подписи, и запросите передачу доступов.

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

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

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

Частые вопросы

Что устанавливает экспертиза процесса программного обеспечения?

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

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

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

Можно ли проверить обоснованность часов в актах исполнителя?

Да, путем сопоставления актов с объемом изменений в коде, закрытыми задачами и учтенным временем в системе задач. Эксперт показывает соотношение заявленного и фактического.

Можно ли установить, что код писал не заявленный исполнитель?

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

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

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

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

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

Что такое проведение экспертизы программного обеспечения по процессным вопросам?

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

Нужна ли независимая экспертиза программного обеспечения до суда?

Да, если есть риск, что история репозитория, задачи или облачные сервисы будут изменены. Специалист фиксирует данные, пока они доступны.

Сколько стоит экспертиза процесса программного обеспечения?

Экспертиза процесса разработки на соответствие методологии и договору стоит от 75 000 ₽, исследование процесса тестирования и выпуска версий от 60 000 ₽, исследование инфраструктуры разработки и передачи проекта от 65 000 ₽, исследование использования программ в организации от 80 000 ₽, исследование хронологии разработки и трудозатрат от 85 000 ₽. Точная сумма фиксируется в договоре после бесплатного предварительного анализа.

Сколько стоит проверка трудозатрат исполнителя по репозиторию и задачам?

От 85 000 ₽, срок 5–15 дней. Это самая трудоемкая позиция: эксперт сопоставляет акты с историей изменений кода, закрытыми задачами и учтенным временем по каждому периоду.

Сколько стоит исследование использования программного обеспечения в организации?

От 80 000 ₽, срок 5–15 дней. В работу входит анализ сведений об установках и запусках, журналов серверов лицензий и данных, созданных в программе, с сопоставлением условиям лицензий.

Сколько стоит исследование процесса тестирования и выпуска версий?

От 60 000 ₽, срок 5–10 дней. Эксперт проверяет наличие и запуск тестов, результаты автоматических проверок, порядок согласования и развертывания версий.

Сколько стоит исследование передачи проекта новому исполнителю?

От 65 000 ₽, срок 5–12 дней. Устанавливается состояние переданного репозитория, полнота истории, передача доступов к системам сборки, облачным учетным записям и ключам подписи.

Сколько стоит рецензия на заключение экспертизы процесса программного обеспечения?

От 50 000 ₽, срок 4–9 дней. Цена зависит от объема заключения и приложений и от необходимости проверять исходные выгрузки систем.

Можно ли объединить вопросы о процессе и о результате в одной экспертизе?

Да. Один эксперт по компьютерно-технической специальности отвечает в одном заключении на вопросы о соответствии заданию, о свойствах программы и о процессе разработки.

Основные термины

Жизненный цикл программного средства: совокупность процессов от определения требований до вывода программы из эксплуатации.

Система контроля версий: система, хранящая историю изменений кода с авторами и датами.

Фиксация изменений: запись в системе контроля версий о конкретном наборе изменений кода.

Ветка: параллельная линия разработки в репозитории.

Система управления задачами: система учета задач, их исполнителей, статусов и затраченного времени.

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

Методология разработки: согласованный порядок организации работ — этапы, циклы, контрольные точки.

Регрессионное тестирование: повторная проверка ранее работавших функций после внесения изменений.

Трудозатраты: время специалистов, затраченное на выполнение работ.

Лицензия на программу: право использования программы в пределах, установленных лицензионным договором.

Инвентаризация программного обеспечения: учет установленных программ, их версий и числа установок.

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

Коротко о главном

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

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

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

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

Об АНО «СЗЭПЦ»

АНО «Северо-Западный экспертно-правовой центр» проводит экспертизы с 1990 года и относится к первым негосударственным экспертным организациям России. Головной офис расположен в Санкт-Петербурге, представительства работают в Москве, Екатеринбурге, Новосибирске, Казани, Краснодаре, Нижнем Новгороде и Ростове-на-Дону. Заключения АНО «СЗЭПЦ» принимают арбитражные суды и суды общей юрисдикции более чем в сорока регионах.

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

Направьте описание задачи на info@szexp.ru или позвоните: +7 (812) 982-86-69 (Санкт-Петербург и Москва), +7 (905) 222-86-69 (регионы Российской Федерации) — АНО «СЗЭПЦ» проведет предварительный анализ и подготовит информационное письмо для суда.

Узнать стоимость экспертизы