В условиях стремительной цифровой трансформации экономики и государственного управления программное обеспечение (ПО) приобретает статус стратегического ресурса, от качества и надежности которого зависят эффективность бизнес-процессов, сохранность данных и выполнение критически важных функций. Разработка сложных программных комплексов, автоматизированных систем управления, информационных порталов и мобильных приложений требует значительных финансовых вложений и интеллектуальных ресурсов. Однако практика реализации IT-проектов свидетельствует о высокой конфликтогенности данной сферы: несовпадение ожиданий заказчика и результата работы разработчика, неоднозначное толкование требований, скрытые дефекты и ошибки проектирования приводят к многочисленным спорам, разрешение которых невозможно без применения специальных знаний.

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

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

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

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

1. 1. Определение и концептуальные основы

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

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

1. 2. Соотношение со смежными видами экспертиз

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

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

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

1. 3. Объективная необходимость проведения экспертизы

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

• Нематериальный характер объекта. В отличие от результатов работ в строительстве или производстве, качество программного обеспечения невозможно оценить визуально или с помощью простых измерительных инструментов. Функциональность и свойства программы проявляются только в процессе ее исполнения, а многие характеристики (архитектура, качество кода, сопровождаемость) вообще не поддаются непосредственному наблюдению.
• Высокая сложность и многоаспектность. Современные программные системы представляют собой иерархические структуры, включающие множество компонентов, взаимодействующих между собой и с внешней средой. Оценка их соответствия требованиям требует применения системного подхода и глубоких технических знаний.
• Асимметрия информации. Заказчик, как правило, не обладает достаточной квалификацией для объективной оценки результатов работы разработчика, что создает предпосылки для оппортунистического поведения последнего.
• Правовая неопределенность критериев качества. Гражданское законодательство не содержит детализированных требований к качеству программного обеспечения, отсылая к условиям договора и обычно предъявляемым требованиям. Экспертное заключение позволяет конкретизировать эти критерии применительно к конкретному спору.

Раздел 2. Правовые основания и нормативное регулирование

2. 1. Процессуально-правовая основа

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

• Арбитражный процессуальный кодекс Российской Федерации. Статья 82 АПК РФ устанавливает порядок назначения экспертизы, статья 86 определяет содержание заключения эксперта, статья 87 регламентирует проведение дополнительной и повторной экспертизы.
• Гражданский процессуальный кодекс Российской Федерации. Статьи 79-87 ГПК РФ содержат аналогичные нормы применительно к гражданскому судопроизводству.
• Кодекс административного судопроизводства Российской Федерации. Статьи 77-83 КАС РФ регулируют назначение и проведение экспертизы по административным делам.
• Уголовно-процессуальный кодекс Российской Федерации. Статьи 195-207 УПК РФ определяют порядок производства судебной экспертизы по уголовным делам, в том числе связанным с преступлениями в сфере компьютерной информации.

2. 2. Федеральный закон № 73-ФЗ как методологическая основа

Федеральный закон от 31. 05. 2001 № 73-ФЗ «О государственной судебно-экспертной деятельности в Российской Федерации» закладывает принципиальные основы экспертной деятельности, имеющие значение для всех видов экспертиз:

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

2. 3. Материально-правовая основа для оценки соответствия техническому заданию

Оценка соответствия программного обеспечения техническому заданию базируется на нормах Гражданского кодекса Российской Федерации:

• Статья 721 ГК РФ «Качество работы». Устанавливает, что качество выполненной работы должно соответствовать условиям договора, а при отсутствии или неполноте условий договора — требованиям, обычно предъявляемым к работам соответствующего рода. Если иное не предусмотрено законом, иными правовыми актами или договором, результат выполненной работы должен в момент передачи заказчику обладать свойствами, указанными в договоре или определенными обычно предъявляемыми требованиями, и в пределах разумного срока быть пригодным для установленного договором использования.
• Статья 722 ГК РФ «Гарантия качества работы». Определяет, что в случае, когда законом, иным правовым актом, договором подряда или обычаями делового оборота предусмотрен для результата работы гарантийный срок, результат работы должен соответствовать условиям договора о качестве в течение всего гарантийного срока.
• Статья 723 ГК РФ «Ответственность подрядчика за ненадлежащее качество работы». Предусматривает, что в случаях, когда работа выполнена подрядчиком с отступлениями от договора подряда, ухудшившими результат работы, или с иными недостатками, которые делают его не пригодным для предусмотренного в договоре использования либо при отсутствии в договоре соответствующего условия непригодности для обычного использования, заказчик вправе потребовать безвозмездного устранения недостатков, соразмерного уменьшения установленной за работу цены, возмещения своих расходов на устранение недостатков.
• Статья 724 ГК РФ «Сроки обнаружения ненадлежащего качества результата работы». Устанавливает, что заказчик вправе предъявить требования, связанные с ненадлежащим качеством результата работы, при условии, что оно выявлено в сроки, установленные законом или договором.

2. 4. Роль стандартизации в оценке соответствия

При отсутствии в техническом задании детализированных требований к качеству программного обеспечения эксперты руководствуются положениями национальных и международных стандартов, которые могут рассматриваться как «обычно предъявляемые требования» в контексте статьи 721 ГК РФ:

• ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств». Данный стандарт определяет структуру процессов жизненного цикла программного обеспечения и может использоваться для оценки полноты и качества выполнения работ на различных этапах разработки.
• ГОСТ Р ИСО/МЭК 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению». Содержит классификацию характеристик качества программного обеспечения: функциональность, надежность, практичность, эффективность, сопровождаемость, переносимость. Каждая характеристика детализируется на субхарактеристики, что позволяет проводить многоаспектную оценку.
• ГОСТ 19. XXX (Единая система программной документации). Устанавливает требования к составу и содержанию программной документации, включая техническое задание, программу и методику испытаний, руководство оператора, руководство системного программиста и другие документы.
• ГОСТ Р 53622-2009 «Информационные технологии. Информационно-вычислительные системы. Стадии и этапы жизненного цикла, виды и полнота документов». Определяет стадии и этапы создания информационных систем, а также требования к составу разрабатываемой документации.

Раздел 3. Техническое задание как объект экспертного исследования

3. 1. Понятие и правовой статус технического задания

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

С правовой точки зрения техническое задание является неотъемлемой частью договора на создание программного обеспечения (если иное прямо не предусмотрено договором). В соответствии со статьей 432 ГК РФ, договор считается заключенным, если между сторонами достигнуто соглашение по всем существенным условиям. Для договора подряда на создание программного обеспечения существенным условием является предмет договора, который конкретизируется именно в техническом задании. Таким образом, отсутствие утвержденного сторонами технического задания может свидетельствовать о незаключенности договора либо о невозможности определения предмета обязательства.

3. 2. Классификация требований, содержащихся в техническом задании

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

По содержанию:

• Функциональные требования. Описывают действия, которые должна выполнять программа, и реакции системы на входные воздействия. Например: «система должна обеспечивать ввод, хранение и редактирование данных о клиентах», «система должна формировать отчет о продажах за выбранный период».
• Требования к выходным данным. Определяют форму, содержание и периодичность формирования выходных документов (отчетов, файлов, экранных форм).
• Требования к производительности. Задают количественные характеристики функционирования: время отклика, количество одновременно обслуживаемых пользователей, пропускную способность каналов связи.
• Требования к надежности. Определяют способность программы сохранять работоспособность в течение заданного времени, допустимую наработку на отказ, порядок восстановления после сбоев.
• Требования к безопасности. Включают требования к разграничению доступа, защите от несанкционированного проникновения, шифрованию данных.
• Требования к информационной и программной совместимости. Устанавливают необходимость взаимодействия с другими программными системами, форматы обмена данными.
• Требования к интерфейсу. Описывают внешний вид программы, расположение элементов управления, эргономические характеристики.
• Требования к программной документации. Определяют состав, содержание и оформление документов, передаваемых заказчику вместе с программой.
• Требования к составу и содержанию работ по вводу в действие. Описывают мероприятия по внедрению, обучению персонала, конвертации данных.

По степени формализации:

• Количественно определенные требования. Поддаются непосредственному измерению и проверке с помощью инструментальных средств (например, «время отклика не более 2 секунд», «система должна поддерживать одновременную работу 100 пользователей»).
• Качественно определенные требования. Требуют экспертной оценки и могут допускать различные интерпретации (например, «интерфейс должен быть интуитивно понятным», «система должна обладать высокой надежностью»).

По степени обязательности:

• Императивные требования. Сформулированы как обязательные к исполнению (с использованием слов «должен», «обязан», «необходимо»).
• Диспозитивные требования. Могут быть изменены или дополнены соглашением сторон в процессе разработки.
• Рекомендательные требования. Сформулированы как желательные, но не обязательные (с использованием слов «рекомендуется», «целесообразно»).

3. 3. Типичные недостатки технических заданий, затрудняющие проведение экспертизы

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

• Неполнота и фрагментарность. ТЗ описывает лишь часть требуемой функциональности, оставляя значительную область неопределенности.
• Противоречивость. Различные разделы ТЗ содержат взаимоисключающие требования.
• Избыточная обобщенность. Требования сформулированы слишком общо, без необходимой детализации, что допускает множественность интерпретаций.
• Отсутствие количественных критериев. Качественные требования («удобный интерфейс», «высокая производительность») не подкреплены измеримыми показателями.
• Неактуальность. ТЗ не отражает изменений, внесенных в процессе разработки, и не соответствует финальному согласованному объему работ.
• Отсутствие приоритезации требований. Не определено, какие требования являются критически важными, а какие могут быть реализованы во вторую очередь.

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

Раздел 4. Объекты и методы исследования при проведении компьютерной экспертизы на соответствие техническому заданию

4. 1. Объекты экспертного исследования

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

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

• Исходный код программы. Представляет собой текст на языках программирования, понятный человеку и подлежащий трансляции в машинный код. Исходный код является наиболее информативным объектом, позволяющим провести анализ архитектуры, качества кодирования, наличия скрытых функций и заимствований.
• Исполняемые модули. Представляют собой готовые к запуску файлы, содержащие машинный код. Исследование исполняемых модулей проводится методами динамического анализа и реверс-инжиниринга.
• Базы данных. Включают структуры данных (схемы, таблицы, индексы), а также тестовое или реальное наполнение.
• Конфигурационные файлы и скрипты. Содержат параметры настройки и автоматизации.

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

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

Сопутствующие материалы:

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

4. 2. Методы экспертного исследования

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

Общенаучные методы:

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

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

• Статический анализ. Исследование исходного кода или исполняемых модулей без их фактического выполнения. Позволяет выявить структурные дефекты, нарушения стандартов кодирования, потенциальные уязвимости, «мертвый» код, несоответствия архитектурным требованиям. Статический анализ может проводиться как вручную (экспертная оценка), так и с использованием специализированных инструментов (PVS-Studio, SonarQube, Coverity).
• Динамический анализ. Исследование программы в процессе ее выполнения на тестовых стендах. Включает:
  • Функциональное тестирование — проверка реализации функций в соответствии с требованиями ТЗ.
  • Нагрузочное тестирование — проверка производительности при заданных нагрузках.
  • Стресс-тестирование — проверка поведения при нагрузках, превышающих штатные.
  • Тестирование безопасности — проверка устойчивости к попыткам несанкционированного доступа.
  • Тестирование надежности — проверка способности длительно работать без сбоев.
• Реверс-инжиниринг (обратная разработка). Восстановление логики работы программы, алгоритмов и структур данных по ее исполняемому коду. Применяется при отсутствии исходного кода или для проверки соответствия реализации заявленным алгоритмам.
• Метрический анализ. Количественная оценка характеристик программного обеспечения с использованием различных метрик:
  • Метрики размера (количество строк кода, количество функций, классов).
  • Метрики сложности (цикломатическая сложность МакКейба, глубина вложенности, связанность модулей).
  • Метрики тестируемости (покрытие кода тестами).
  • Метрики сопровождаемости (индекс сопровождаемости, количество комментариев).
• Документальный анализ. Исследование проектной и эксплуатационной документации на предмет полноты, непротиворечивости и соответствия фактической реализации программы.

4. 3. Инструментальные средства экспертного исследования

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

• Интегрированные среды разработки (Visual Studio, Eclipse, IntelliJ IDEA) для анализа исходного кода.
  • Статические анализаторы кода (PVS-Studio, SonarQube, Coverity, Klocwork).
  • Средства динамического анализа и отладки (GDB, WinDbg, Valgrind, strace).
  • Инструменты нагрузочного тестирования (Apache JMeter, LoadRunner, Gatling, Yandex. Tank).
  • Профилировщики производительности (Intel VTune, AMD CodeAnalyst, Java Flight Recorder).
  • Средства реверс-инжиниринга (IDA Pro, Ghidra, Radare2, x64dbg).
  • Системы контроля версий (Git, Subversion, Mercurial) для анализа истории разработки.
  • Инструменты документирования и визуализации архитектуры (Enterprise Architect, StarUML, draw. io).

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

5. 1. Задачи, связанные с проверкой функциональных требований

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

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

5. 2. Задачи, связанные с проверкой нефункциональных требований

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

• Проверка требований к производительности. Установление соответствия фактического времени отклика, пропускной способности, максимального количества одновременных пользователей значениям, заданным в техническом задании. Проводится путем нагрузочного тестирования в среде, максимально приближенной к реальным условиям эксплуатации.
• Проверка требований к надежности. Оценка способности программы сохранять работоспособность в течение заданного времени, восстанавливаться после сбоев, обеспечивать целостность данных. Включает тестирование на устойчивость к отказам, анализ механизмов резервирования и восстановления.
• Проверка требований к безопасности. Оценка реализованных механизмов разграничения доступа, аутентификации, авторизации, аудита, шифрования. Включает анализ устойчивости к типовым атакам.
• Проверка требований к совместимости. Оценка способности программы взаимодействовать с другими системами в соответствии с заданными протоколами и форматами обмена данными.
• Проверка требований к эргономике и удобству использования. Оценка соответствия интерфейса требованиям технического задания, а также общепринятым стандартам юзабилити (при отсутствии детальных требований в ТЗ).

5. 3. Задачи, связанные с анализом архитектуры и качества кода

• Оценка соответствия архитектуры программного обеспечения требованиям технического задания. Проверка соблюдения заданных архитектурных стилей, паттернов, принципов организации компонентов.
• Анализ качества исходного кода. Оценка соблюдения стандартов кодирования, наличия комментариев, отсутствия «мертвого» и трудноподдерживаемого кода.
• Выявление скрытых дефектов и уязвимостей. Обнаружение ошибок, которые не проявляются при штатном функционировании, но могут привести к сбоям в особых условиях или при целенаправленных атаках.
• Анализ тестового покрытия. Оценка достаточности автоматических тестов для проверки функциональности (если такое требование было в ТЗ).

5. 4. Задачи, связанные с проверкой документации

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

5. 5. Задачи, связанные с определением стоимости и объема выполненных работ

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

Раздел 6. Процедура назначения и проведения компьютерной экспертизы на соответствие техническому заданию

6. 1. Основания и инициаторы назначения экспертизы

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

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

6. 2. Постановка вопросов эксперту

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

• Относиться к компетенции эксперта и не требовать правовой оценки (например, вопрос «является ли ответчик виновным в нарушении договора?» является правовым и не может ставиться перед экспертом).
• Быть конкретными, не допускать двоякого толкования.
• Быть разрешимыми с использованием современных научно-технических средств и методов.
• Охватывать все обстоятельства, имеющие значение для дела.

Типовые вопросы, ставящиеся перед экспертом:

• Соответствует ли программное обеспечение (наименование, версия) требованиям технического задания № ___ от. . 20__ г. , являющегося приложением к договору № ___ от. . 20__ г. ? Если не соответствует, то в чем конкретно выражаются выявленные несоответствия?
• Все ли функциональные требования, предусмотренные техническим заданием, реализованы в представленном программном обеспечении? Если нет, то какие именно функции отсутствуют или реализованы не в полном объеме?
• Имеются ли в программном обеспечении ошибки (дефекты), препятствующие его нормальной эксплуатации в соответствии с целевым назначением? Если да, то какова классификация этих ошибок по степени критичности?
• Соответствует ли фактическая производительность программного обеспечения требованиям, установленным в техническом задании?
• Соответствует ли предоставленная разработчиком техническая и эксплуатационная документация требованиям технического задания и фактической реализации программного обеспечения?
• Каковы причины возникновения выявленных дефектов и несоответствий?
• Каковы стоимость и сроки устранения выявленных недостатков и доработки программного обеспечения до требований технического задания?

6. 3. Этапы проведения экспертного исследования

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

• Изучение определения суда (постановления) о назначении экспертизы или заявления заказчика.
  • Ознакомление с предоставленными материалами (договор, ТЗ, ПО, документация).
  • Оценка достаточности материалов для ответа на поставленные вопросы.
  • При недостаточности материалов — заявление ходатайства об их истребовании.
  • Разработка плана и методики исследования.

Аналитический этап:

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

Инструментальный этап:

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

Синтезирующий этап:

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

Оформительский этап:

• Составление экспертного заключения в соответствии с требованиями процессуального законодательства.
  • Подписание заключения экспертом (всеми членами комиссии).
  • Направление заключения заказчику или в суд.

6. 4. Структура и содержание экспертного заключения

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

Вводная часть:

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

Исследовательская часть:

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

Выводы:

• Краткие, четкие и однозначные ответы на каждый из поставленных вопросов.
  • Выводы должны логически вытекать из исследовательской части и не содержать противоречий.

Заключение подписывается экспертом (всеми членами комиссии) и заверяется печатью экспертной организации.

Раздел 7. Классификация и методы оценки несоответствий программного обеспечения требованиям технического задания

7. 1. Понятие и классификация несоответствий

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

Классификация несоответствий может проводиться по различным основаниям.

По характеру проявления:

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

По отношению к функциональности:

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

По влиянию на возможность использования:

• Критические несоответствия. Делают невозможным использование программы по целевому назначению. К ним относятся: отсутствие ключевых функций, неверные результаты расчетов по основным алгоритмам, потеря данных, невозможность завершения основных бизнес-процессов.
• Значительные несоответствия. Существенно затрудняют использование программы, но имеют обходные пути или проявляются не во всех режимах работы.
• Малозначительные несоответствия. Не влияют на функциональность и не препятствуют использованию программы (опечатки в интерфейсе, незначительные отклонения в оформлении).

7. 2. Методы оценки критичности несоответствий

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

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

7. 3. Документирование несоответствий

Каждое выявленное несоответствие должно быть надлежащим образом задокументировано. Документация должна включать:

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

Раздел 8. Методология оценки стоимости устранения выявленных несоответствий

8. 1. Теоретические основы стоимостной оценки

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

Основные подходы к стоимостной оценке:

• Затратный подход. Оценка производится исходя из трудозатрат, необходимых для устранения каждого несоответствия, и рыночной стоимости единицы трудозатрат (человеко-часа, человеко-дня) специалистов соответствующей квалификации.
• Сравнительный подход. Основан на сравнении с рыночной стоимостью аналогичных работ по доработке программного обеспечения.
• Экспертный подход. Используется при невозможности применения формализованных методов и базируется на профессиональном опыте эксперта.

8. 2. Методы оценки трудозатрат

Для определения трудозатрат на устранение несоответствий применяются:

• Метод декомпозиции. Каждое несоответствие или группа связанных несоответствий разбиваются на элементарные задачи, по каждой задаче оцениваются трудозатраты, затем производится суммирование.
• Метод аналогий. Трудозатраты оцениваются путем сравнения с аналогичными задачами, по которым известны фактические затраты времени.
• Метод экспертных оценок. Группа экспертов независимо оценивает трудозатраты, затем производится согласование оценок.
• Метод параметрического моделирования. Используются математические модели, связывающие трудозатраты с характеристиками программного обеспечения (объем кода, сложность, количество функций).

8. 3. Факторы, влияющие на стоимость устранения несоответствий

При проведении стоимостной оценки учитываются следующие факторы:

• Сложность и объем кода, подлежащего модификации.
  • Необходимость изменения архитектуры программы.
  • Связанность модифицируемых компонентов с другими частями системы.
  • Наличие и качество документации.
  • Необходимость регрессионного тестирования после внесения изменений.
  • Квалификация требуемых специалистов.
  • Срочность выполнения работ.

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

9. 1. Специфика исследования «черного ящика»

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

Исследование программы в условиях отсутствия исходного кода (методом «черного ящика») имеет следующие особенности:

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

9. 2. Методы исследования при отсутствии исходного кода

• Функциональное тестирование. Наиболее полная проверка всех функций, доступных через пользовательский интерфейс, на соответствие требованиям ТЗ.
• Тестирование API. Если программа предоставляет программные интерфейсы для взаимодействия с другими системами, проводится их тестирование.
• Нагрузочное тестирование. Проводится в полном объеме, так как не требует доступа к исходному коду.
• Тестирование безопасности. Проводится методами фаззинга и анализа защищенности через внешние интерфейсы.
• Реверс-инжиниринг. В ограниченных пределах может применяться для анализа логики работы программы, однако должен осуществляться в строгом соответствии с законодательством об интеллектуальной собственности.

9. 3. Ограничения и возможности выводов

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

Эксперт не может достоверно установить:
• Причины возникновения дефектов (ошибки проектирования, кодирования, неверная интерпретация требований).
• Наличие скрытых дефектов, не проявляющихся при тестировании.
• Качество архитектуры и кода, их соответствие современным стандартам.
• Наличие недекларированных возможностей («закладок»).

Раздел 10. Критерии оценки качества экспертного заключения и требования к эксперту

10. 1. Требования к эксперту, проводящему компьютерную экспертизу на соответствие техническому заданию

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

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

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

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

• Верифицируемость. Выводы эксперта должны быть проверяемы, то есть другой специалист, обладающий аналогичной квалификацией и использующий те же методы, должен иметь возможность прийти к аналогичным результатам.
• Воспроизводимость. Описание методики исследования должно быть достаточным для того, чтобы при необходимости исследование можно было воспроизвести.
• Непротиворечивость. Выводы не должны противоречить друг другу и установленным в ходе исследования фактам.
• Полнота. Исследование должно охватывать все поставленные вопросы и все значимые аспекты объекта.
• Аргументированность. Каждый вывод должен быть обоснован и вытекать из исследовательской части.

10. 3. Типичные недостатки экспертных заключений

Анализ экспертной практики позволяет выделить следующие типичные недостатки, снижающие доказательственную силу заключения:

• Выход эксперта за пределы своей компетенции (в частности, дача правовых оценок).
• Отсутствие описания примененных методов и методик.
• Неполнота исследования (отсутствие проверки существенных обстоятельств).
• Противоречивость выводов.
• Использование непроверенных или неаппробированных методов.
• Отсутствие ответов на часть поставленных вопросов.
• Необоснованность выводов (выводы не вытекают из исследовательской части).
• Нарушение структуры и требований к оформлению заключения.

Раздел 11. Особенности назначения и проведения повторных и дополнительных экспертиз

11. 1. Основания для назначения дополнительной экспертизы

Дополнительная экспертиза назначается в случаях, когда:

• Экспертное заключение является неполным (исследованы не все объекты, не даны ответы на все вопросы).
• Возникли новые вопросы в отношении ранее исследованных обстоятельств.
• Появились новые материалы, которые не были предметом исследования.

Дополнительная экспертиза поручается, как правило, тому же эксперту.

11. 2. Основания для назначения повторной экспертизы

Повторная экспертиза назначается в случаях, когда:

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

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

11. 3. Процессуальные особенности

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

Раздел 12. Практика применения компьютерной экспертизы на соответствие техническому заданию в различных категориях дел

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

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

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

12. 2. Споры между коммерческими организациями по договорам подряда

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

Типичные вопросы:
• Соответствует ли разработанное программное обеспечение требованиям технического задания?
• Все ли функциональные требования, предусмотренные техническим заданием, реализованы?
• Имеются ли в программном обеспечении дефекты, и какова их классификация по степени критичности?
• Какова стоимость устранения выявленных дефектов?

12. 3. Дела о нарушении исключительных прав на программы для ЭВМ

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

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

12. 4. Корпоративные споры, связанные с разделом активов

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

12. 5. Налоговые споры

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

Раздел 13. Заключение

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

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

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

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

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

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

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

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

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

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