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

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

1. Введение: Онтологический статус технического задания и его значение в системе договорных отношений

В современной экономике программное обеспечение выступает не только как объект интеллектуальной собственности, но и как результат выполнения договорных обязательств по созданию или модификации цифровых продуктов. Ключевым документом, определяющим объем и содержание таких обязательств, является техническое задание (далее — ТЗ), которое в силу статьи 432 Гражданского кодекса Российской Федерации приобретает значение существенного условия договора , конкретизируя его предмет. Именно ТЗ фиксирует функциональные, качественные, эксплуатационные и иные характеристики будущего программного продукта, становясь эталоном, с которым сравнивается фактически созданное ПО при возникновении спора между заказчиком и разработчиком.

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

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

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

2. Теоретико-методологические основания компьютерной экспертизы программного обеспечения на предмет соответствия техзаданию
3. 1. Техническое задание как объект экспертного анализа

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

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

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

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

2. 2. Эпистемологические принципы верификационного исследования

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

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

2. 3. Классификация требований к программному обеспечению

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

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

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

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

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

3. 1. Методы верификации функциональных требований

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

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

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

3. 2. Методы верификации нефункциональных требований

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

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

3. 3. Методы статического анализа кода

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

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

3. 4. Методы анализа документации

Проверка соответствия предоставленной документации требованиям ТЗ включает:

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

4. Классификация и квалификация выявленных несоответствий

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

4. 1. Классификация по степени критичности

В экспертной практике принято выделять следующие категории недостатков:

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

4. 2. Количественная оценка степени соответствия

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

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

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

5. Проблема интерпретации неоднозначных и противоречивых требований

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

5. 1. Типичные проблемы технических заданий

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

5. 2. Методология интерпретации

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

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

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

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

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

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

6. 2. Материалы, предоставляемые в распоряжение эксперта

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

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

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

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

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

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

7. Типовые экспертные ситуации и практика их разрешения

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

7. 1. Ситуация 1: Полное несоответствие или отсутствие ключевого функционала

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

7. 2. Ситуация 2: Частичное несоответствие с наличием устранимых недостатков

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

7. 3. Ситуация 3: Неоднозначность требований ТЗ

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

7. 4. Ситуация 4: Спор о производительности

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

8. Заключение

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

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

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

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