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

Введение

Государственные учреждения, муниципальные предприятия, министерства и ведомства ежегодно заключают тысячи контрактов на разработку, внедрение и сопровождение программного обеспечения. Согласно Федеральному закону № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд», заказчики обязаны принимать результаты работ и несут ответственность за их качество. Однако на практике нередки ситуации, когда разработанное ПО не соответствует техническому заданию, имеет критические дефекты, не готово к эксплуатации или содержит заимствованный код.

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

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

Что представляет собой экспертиза программ для ЭВМ

Экспертиза программ для ЭВМ (программно-компьютерная экспертиза) — это комплексное исследование программного обеспечения, направленное на установление его фактического состояния, соответствия требованиям заказчика и выявление дефектов, препятствующих нормальной эксплуатации.

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

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

Типичные объекты экспертизы программ:

• Информационные системы государственных органов (порталы, реестры, базы данных)
• Ведомственные автоматизированные системы управления и документооборота
• Системы автоматизации закупок и бюджетного учёта
• Веб-приложения и порталы государственных услуг
• Мобильные приложения для государственных сервисов
• ERP/CRM-системы муниципальных предприятий
• Системы безопасности и защиты информации

Когда необходима экспертиза программ

Приёмка результатов работ по государственному контракту. Если ИТ-подрядчик сдаёт работу, но у заказчика есть сомнения в её полноте или качестве, экспертиза позволяет установить фактическое соответствие результата требованиям технического задания.

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

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

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

Споры о стоимости выполненных работ. Экспертиза определяет объём фактически выполненных работ и их рыночную стоимость.

Оценка качества работы по созданию сайта или веб-приложения. Экспертиза устанавливает соответствие результата требованиям ТЗ, ГОСТам и нормам юзабилити.

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

Объекты экспертизы программ для ЭВМ

1. Исходный код

Исходный код программы является основным объектом экспертизы. Анализируется его структура, качество, наличие заимствований, соответствие стандартам разработки. Экспертиза исходного кода может проводиться для программ на различных языках: C++, Java, Python, PHP и других.

2. Исполняемые файлы и сборки

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

3. Базы данных и структуры данных

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

4. Документация

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

5. Интерфейсы и пользовательский опыт

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

6. Архитектура системы

Анализируется архитектурные решения: монолит vs микросервисы, использование фреймворков, масштабируемость, безопасность.

7. Репозитории и история разработки

Изучается история коммитов, ветвление, слияния, активность разработчиков.

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

Предварительный этап

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

Сбор и анализ исходной документации. Изучаются:

• Техническое задание и его приложения

• Государственный контракт и дополнительные соглашения

• Проектная документация

• Акты приёмки промежуточных этапов

• Переписка сторон

• Протоколы испытаний

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

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

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

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

Анализ базы данных. Проверяется схема БД, целостность, соответствие требованиям.

Функциональное тестирование. Проверяется работоспособность системы в соответствии с требованиями ТЗ. Выявляются дефекты и несоответствия.

Анализ документации. Оценивается полнота и качество документации, её соответствие фактическому состоянию системы.

Этап оценки степени готовности

Определение функциональной полноты. Оценивается, какие функции реализованы полностью, какие частично, какие отсутствуют.

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

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

Заключительный этап

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

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

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

Специфика государственных контрактов

Государственные заказчики действуют в рамках Федерального закона № 44-ФЗ и подзаконных актов. Это накладывает отпечаток на процедуру экспертизы:

• Формальные требования к приёмке. Результаты работ принимаются в строгом соответствии с условиями контракта и технического задания.

• Обязательность экспертизы в определённых случаях. Закон № 44-ФЗ предусматривает обязательное проведение экспертизы при приёмке результатов в ряде случаев.

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

Роль ФАС России

Федеральная антимонопольная служба (ФАС России) осуществляет контроль за соблюдением законодательства о контрактной системе. При возникновении споров с подрядчиками заказчик может обратиться в ФАС с жалобой на действия подрядчика, если они нарушают условия контракта или законодательство о закупках.

Согласно методическим рекомендациям ФАС, при рассмотрении жалоб контролирующий орган проводит внеплановую проверку, по результатам которой выносит решение. Жалоба рассматривается в течение 5 рабочих дней по 44-ФЗ или 7 рабочих дней по 223-ФЗ.

Судебная практика

Судебная практика по спорам, связанным с разработкой ПО для государственных нужд, показывает, что суды активно используют результаты экспертиз. Например, в деле о муниципальном контракте на изготовление и монтаж малых архитектурных форм (дело № А32-12206/2025) апелляционный суд на основании строительно-технической экспертизы установил, что просрочка вызвана действиями самого заказчика, и признал незаконным односторонний отказ от контракта.

В деле о споре между администрацией и подрядчиком по монтажу ледового хоккейного корта (дело № А80-658/2024) суды установили, что подрядчик не мог выполнить работы по причинам, не зависящим от него, поскольку заказчик не обеспечил необходимые условия. Верховный Суд РФ подтвердил, что односторонний отказ заказчика был неправомерным.

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

Методика выполнения экспертизы программ

1. Подготовительный этап

1.1. Изучение поставленной задачи

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

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

• Какова степень готовности программного обеспечения?

• Имеются ли в программном обеспечении заимствования из других источников?

• Соответствует ли стоимость выполненных работ рыночной?

1.2. Сбор и анализ исходной документации

Изучаются:

• Техническое задание (ТЗ)

• Государственный контракт

• Акты приёмки

• Переписка сторон

• Репозитории с исходным кодом

• Документация на систему

1.3. Составление программы экспертизы

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

2. Этап анализа программного обеспечения

2.1. Статический анализ кода

Проводится анализ исходного кода на предмет:

• Соответствия стандартам кодирования

• Наличия заимствований

• Качества архитектуры

• Наличия уязвимостей

Используются инструменты: SonarQube, Checkstyle, PMD, специализированные инструменты для поиска плагиата.

2.2. Динамический анализ

Проводится тестирование системы:

• Функциональное тестирование

• Нагрузочное тестирование

• Тестирование безопасности

2.3. Анализ архитектуры

Оценивается:

• Соответствие архитектуры требованиям ТЗ

• Масштабируемость

• Безопасность

• Поддерживаемость

2.4. Анализ базы данных

Проверяется:

• Схема БД

• Целостность данных

• Корректность миграций

3. Этап оценки степени готовности

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

Оценка готовности включает:

• Компетенцию и комплектность — проверка наличия всех необходимых компонентов

• Техническую готовность — возможность сборки и развёртывания

• Функциональную полноту — реализация всех требуемых функций

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

4. Заключительный этап

4.1. Оформление результатов

Составляется заключение, содержащее:

• Вводную часть (объект, заказчик, вопросы)

• Исследовательскую часть (методы, результаты)

• Синтезирующую часть (обоснование выводов)

• Выводы

• Приложения

4.2. Согласование и защита результатов

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

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

1. Инструменты анализа исходного кода

Статические анализаторы:

• SonarQube — комплексный анализ качества кода

• Checkstyle, PMD, FindBugs — анализ соответствия стандартам

• ESLint (JavaScript), Pylint (Python) — линтеры

Инструменты поиска плагиата:

• MOSS (Measure of Software Similarity)

• JPlag

• Специализированные инструменты для сравнения кода

Инструменты анализа зависимостей:

• OWASP Dependency-Check

• Snyk

• npm audit, pip-audit

2. Инструменты динамического анализа

• JUnit, TestNG — фреймворки для модульного тестирования

• Selenium, Cypress — автоматизированное тестирование веб-приложений

• JMeter, LoadRunner — нагрузочное тестирование

• OWASP ZAP, Burp Suite — тестирование безопасности

3. Инструменты анализа баз данных

• SQL-клиенты — для анализа схем и данных

• Инструменты сравнения схем — для выявления различий

• Инструменты профилирования — для анализа производительности

4. Инструменты анализа документации

• Сравнение версий — для выявления изменений в документации

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

5. Специализированное оборудование

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

• Изолированные стенды для тестирования

• Средства восстановления данных для анализа удалённых файлов

• Криминалистические инструменты для анализа носителей

Судебная или независимая экспертиза — все за и против

1. Судебная экспертиза

Особенности: Назначается определением суда, регулируется Федеральным законом № 73-ФЗ и процессуальными кодексами.

Плюсы:

• Максимальная доказательная сила

• Эксперт предупреждается об уголовной ответственности

• Процессуальная защищённость

Минусы:

• Высокая стоимость

• Длительные сроки (от 30 до 60 рабочих дней)

• Ограниченный выбор экспертов

2. Независимая (внесудебная) экспертиза

Особенности: Проводится по инициативе заинтересованной стороны на основании договора.

Плюсы:

• Свобода выбора эксперта

• Оперативность

• Гибкость в постановке задач

• Более низкая стоимость

• Возможность досудебного урегулирования

Минусы:

• Более низкая доказательная сила в суде

• Риск недоверия со стороны оппонента

• Отсутствие уголовной ответственности эксперта

3. Сравнительная таблица

Процедура извещения сторон и осмотра объекта

1. Обязательность извещения

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

2. Последствия неизвещения

Неизвещение сторон является безусловным основанием для отмены судебного акта (пункт 2 части 4 статьи 270 АПК РФ). Нарушение принципа равенства и состязательности лишает сторону возможности наблюдать за ходом исследования и фиксировать нарушения.

3. Особенности для экспертизы программ

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

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

1. Вопросы о соответствии требованиям

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

• Реализованы ли все функции, предусмотренные ТЗ?

• Соответствует ли пользовательский интерфейс требованиям ТЗ?

2. Вопросы о степени готовности

• Какова степень готовности программного обеспечения?

• Может ли система быть развёрнута и запущена в эксплуатацию?

• Какие компоненты отсутствуют или не завершены?

3. Вопросы о качестве

• Имеются ли в программном обеспечении критические дефекты?

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

• Имеются ли уязвимости информационной безопасности?

4. Вопросы о заимствованиях

• Содержит ли исходный код заимствования из других программ?

• Является ли программа производной от другой программы?

• Имеются ли признаки переработки исходного кода?

5. Вопросы о стоимости

• Какова рыночная стоимость выполненных работ?

• Соответствует ли стоимость работ их объёму и качеству?

Рецензирование экспертизы программ

1. Правовая природа

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

2. Что проверяется

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

• Компетентность эксперта

• Достаточность исходных данных

• Методическая корректность

• Логическая связь выводов с исследовательской частью

3. Типичные ошибки

4. Ограничения рецензирования по копии

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

Стоимость проведения экспертизы программ

1. Факторы ценообразования

• Сложность объекта — объём кода, количество модулей, сложность архитектуры

• Объём вопросов — чем больше вопросов, тем выше стоимость

• Необходимость специальных методов — анализ кода, тестирование, экспертиза баз данных

• Срочность — ускоренное выполнение увеличивает стоимость

2. Ориентировочные цены

• Экспертиза исходного кода на C++ — от 100 000 ₽, срок от 10 рабочих дней

• Экспертиза кода на Java (корпоративные системы и ERP) — стоимость определяется после анализа материалов

• Стандартная экспертиза программы для ЭВМ — 15-30 календарных дней

• Тендер на услуги по анализу и экспертизе ПО — от 30 000 ₽ (пример из практики государственных закупок)

3. Стоимость рецензирования

Рецензирование заключения стоит дешевле полноценной экспертизы, поскольку не включает повторное исследование. Диапазон: от 30 000 до 50 000 ₽.

Последние кейсы из практики экспертизы программ для ЭВМ

Кейс 1. Спор о степени готовности информационной системы министерства

Тип объекта: Информационная система министерства (реестр, портал).

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

Вывод: Оценка готовности не сводится к проценту выполненных работ по договору.

Кейс 2. Спор о заимствовании кода в государственном проекте

Тип объекта: Программное обеспечение для государственного органа.

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

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

Кейс 3. Экспертиза 1С для государственного учреждения

Тип объекта: База данных 1С бухгалтерского учёта.

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

Вывод: Экспертиза баз данных 1С позволяет выявить несанкционированные изменения.

Кейс 4. Оценка качества веб-приложения для государственных услуг

Тип объекта: Портал государственных услуг.

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

Вывод: Экспертиза сайта устанавливает соответствие результата требованиям ТЗ, ГОСТам и нормам юзабилити.

Кейс 5. Восстановление удалённого исходного кода

Тип объекта: Исходный код программы, удалённый разработчиками.

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

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

Кейс 6. Спор о работоспособности ERP-системы муниципального предприятия

Тип объекта: ERP-система муниципального предприятия.

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

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

Кейс 7. Экспертиза в споре с Росатомом

Тип объекта: 12 программ для ЭВМ для дочернего предприятия Росатома.

Суть: АО «КОНСИСТ-ОС» (дочернее предприятие Росатома) провело тендер на экспертизу 12 программ для ЭВМ. Экспертиза проводилась для целей, связанных с подтверждением прав и качества.

Вывод: Крупные государственные корпорации активно используют экспертизу программ.

Кейс 8. Подтверждение идентичности информации в программе (игре)

Тип объекта: Программа (игра), ресурсный файл.

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

Вывод: Экспертное заключение может стать ключевым доказательством в суде.

Кейс 9. Экспертиза безопасности информационной системы

Тип объекта: Информационная система государственного органа.

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

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

Кейс 10. Рецензия на заключение конкурента

Тип объекта: Заключение экспертизы, проведённой другой организацией.

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

Вывод: Рецензирование позволяет оспорить некачественные экспертные заключения.

Глоссарий

Адаптация программы — внесение изменений в программу исключительно для её функционирования на конкретных технических средствах; не является переработкой и допускается без согласия правообладателя (ст. 1270 ГК РФ).

Внесудебная экспертиза — исследование, проводимое по договору со стороной, без назначения судом.

Государственный контракт — договор между заказчиком (государственным органом) и подрядчиком на выполнение работ для государственных нужд.

Динамический анализ — тестирование программы в процессе выполнения.

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

Компьютерно-техническая экспертиза — исследование аппаратного обеспечения и носителей информации.

Мета-экспертиза — см. Рецензирование.

Независимая экспертиза — экспертиза, проводимая по инициативе заинтересованной стороны.

Плагиат в программировании — использование чужого кода без указания авторства или разрешения.

Программно-компьютерная экспертиза — исследование программного обеспечения, алгоритмов, баз данных.

Производная программа — программа, созданная путём переработки другой программы.

Рецензирование — проверка обоснованности и достоверности выводов первичного эксперта.

Статический анализ — анализ кода без его выполнения.

Степень готовности — показатель того, насколько программное обеспечение готово к эксплуатации.

Судебная экспертиза — экспертиза, назначаемая определением суда.

Техническое задание (ТЗ) — документ, определяющий требования к программному обеспечению.

ФАС России — Федеральная антимонопольная служба, контролирующая закупки.

Экспертиза кода — анализ исходного кода программы.

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

ERP-система — система планирования ресурсов предприятия.

MOSS (Measure of Software Similarity) — инструмент для выявления плагиата в коде.

Заключение

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

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

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

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

Стоимость экспертизы программ зависит от сложности объекта, объёма вопросов и необходимости специальных методов. Ориентировочные цены начинаются от 30 000 ₽ для несложных исследований и достигают 100 000 ₽ и более для комплексного анализа исходного кода.

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