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

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

1. Введение: Инженерные аспекты и технологические основы компьютерной экспертизы ПО

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

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

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

2. Техническое задание как объект инженерного анализа
3. 1. Структура и содержание технического задания с инженерной точки зрения

С инженерной точки зрения, техническое задание представляет собой формализованный документ, содержащий совокупность требований к программному обеспечению. В соответствии с ГОСТ 34. 602-89 «Техническое задание на создание автоматизированной системы», ГОСТ 19. 201-78 «Техническое задание. Требования к содержанию и оформлению» и сложившейся инженерной практикой, техническое задание на разработку программного обеспечения должно включать следующие разделы:

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

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

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

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

2. 3. Инженерный анализ качества технического задания

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

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

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

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

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

• Этап 1: Анализ исходных материалов. Изучение технического задания, договора на разработку, проектной документации, протоколов совещаний, переписки сторон. Формирование матрицы требований, подлежащих проверке, с указанием для каждого требования метода проверки и ожидаемого результата.
• Этап 2: Планирование исследования. Определение методов и инструментов для проверки каждого требования, разработка тестовых сценариев и тестовых данных, подготовка тестового стенда, оценка необходимых временных и вычислительных ресурсов, составление детального плана работ.
• Этап 3: Анализ исходного кода (при наличии доступа). Статический анализ кода на соответствие архитектурным требованиям, стандартам кодирования, наличие потенциальных дефектов, уязвимостей, соответствие алгоритмическим требованиям.
• Этап 4: Функциональное тестирование. Проверка реализации всех функций, заявленных в техническом задании, с использованием методов «черного ящика» (без знания внутренней структуры) и «белого ящика» (с анализом путей выполнения кода). Документирование всех выявленных несоответствий.
• Этап 5: Нагрузочное тестирование. Проверка соответствия требованиям к производительности, стабильности, масштабируемости. Проведение тестов с различными уровнями нагрузки, измерение фактических показателей производительности, сравнение с требованиями технического задания.
• Этап 6: Анализ безопасности и надежности. Проверка механизмов защиты, устойчивости к сбоям, корректности обработки ошибок, наличия уязвимостей, соответствия требованиям к безопасности.
• Этап 7: Анализ документации. Проверка соответствия предоставленной эксплуатационной документации (руководства пользователя, администратора, программиста) реальному функционалу программы, полноты и качества документации.
• Этап 8: Обработка результатов. Систематизация выявленных несоответствий, их классификация по степени критичности, подготовка таблиц и графиков, формирование выводов.
• Этап 9: Подготовка заключения. Оформление результатов исследования в виде структурированного документа, содержащего описание методики, результаты проверки каждого требования, перечень выявленных несоответствий, классификацию недостатков и ответы на поставленные вопросы.

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

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

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

Для статического анализа используются специализированные инструменты: линтеры (ESLint для JavaScript, Pylint для Python, PHP_CodeSniffer), анализаторы кода (SonarQube, PVS-Studio, Coverity, Klocwork), средства верификации моделей.

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

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

• Модульное тестирование (unit-тестирование): проверка отдельных модулей (функций, классов, компонентов) в изоляции от остальной системы. Позволяет выявить ошибки на ранних этапах, проверить корректность реализации отдельных функций. Проводится с использованием фреймворков (JUnit для Java, NUnit для . NET, PyTest для Python, Mocha для JavaScript).
• Интеграционное тестирование: проверка взаимодействия между модулями, корректности передачи данных, синхронизации, соблюдения контрактов интерфейсов. Выявляет ошибки, возникающие при совместной работе компонентов.
• Системное тестирование: проверка системы в целом на соответствие функциональным требованиям технического задания. Проводится путем выполнения тестовых сценариев, покрывающих все функции, заявленные в ТЗ, в условиях, максимально приближенных к реальным.
• Регрессионное тестирование: повторное выполнение тестов после внесения изменений для проверки того, что существующая функциональность не нарушена. Особенно важно при оценке качества доработок и исправлений.
• Тестирование граничных значений: проверка работы программы при экстремальных значениях входных данных (минимум, максимум, значения на границах допустимых диапазонов, пустые значения, нулевые значения). Позволяет выявить ошибки, связанные с некорректной обработкой граничных случаев.
• Тестирование исключительных ситуаций: проверка корректности обработки ошибок, нештатных ситуаций (отсутствие файлов, отказ сети, недоступность базы данных, некорректные входные данные). Оценивается, насколько программа устойчива к сбоям и как восстанавливается после них.
• Исследовательское тестирование: неформализованное исследование программы с целью выявления неочевидных дефектов, проверки поведения в нестандартных ситуациях, оценки удобства использования.

3. 4. Методы нагрузочного тестирования

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

• Тестирование производительности (performance testing): измерение времени отклика и пропускной способности при заданной нагрузке. Проводится с использованием инструментов генерации нагрузки (Apache JMeter, Yandex. Tank, LoadRunner, Gatling). Результаты сравниваются с требованиями технического задания.
• Стресс-тестирование (stress testing): проверка поведения системы при нагрузке, превышающей пределы, заложенные в техническом задании. Позволяет определить точку насыщения, характер деградации производительности, поведение при перегрузках (зависание, отказ, корректное ограничение).
• Тестирование стабильности (soak testing): проверка работы системы в течение длительного времени (от нескольких часов до нескольких суток) при нормальной нагрузке. Выявляет утечки памяти, накопление ошибок, деградацию производительности со временем, проблемы с освобождением ресурсов.
• Тестирование масштабируемости (scalability testing): проверка способности системы увеличивать производительность пропорционально добавлению ресурсов (горизонтальное и вертикальное масштабирование). Оценивается эффективность использования добавляемых ресурсов.
• Объемное тестирование (volume testing): проверка работы системы с большими объемами данных. Оценивается время выполнения операций, потребление ресурсов при увеличении объема данных в базе, файловом хранилище.

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

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

3. 5. Методы анализа безопасности

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

• Анализ модели угроз: выявление потенциальных уязвимостей на основе архитектуры системы, сценариев использования, предполагаемых угроз. Оценка достаточности реализованных мер защиты.
• Статический анализ безопасности (SAST — Static Application Security Testing): поиск в исходном коде паттернов, соответствующих известным типам уязвимостей (SQL-инъекции, межсайтовый скриптинг XSS, переполнение буфера, небезопасное хранение паролей). Используются специализированные инструменты (Fortify, Checkmarx, PVS-Studio с правилами безопасности).
• Динамический анализ безопасности (DAST — Dynamic Application Security Testing): сканирование работающего приложения для выявления уязвимостей путем подачи специально сформированных запросов. Инструменты: OWASP ZAP, Burp Suite, Acunetix.
• Тестирование на проникновение (penetration testing): моделирование действий злоумышленника для проверки защищенности системы. Включает попытки обхода аутентификации, несанкционированного доступа к данным, выполнения неавторизованных операций.
• Анализ механизмов аутентификации и авторизации: проверка корректности реализации входа в систему, защиты сессий, разграничения прав доступа, проверка на возможность обхода механизмов защиты.
• Анализ шифрования: проверка использования стойких криптографических алгоритмов, корректности управления ключами, защиты ключей от компрометации, правильности реализации протоколов шифрования.
• Анализ аудита и логирования: проверка фиксации значимых событий безопасности, достаточности детализации логов, защиты логов от модификации.

4. Инструментальное обеспечение компьютерной экспертизы ПО

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

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

• SonarQube: платформа для непрерывного анализа качества кода, поддерживающая более 25 языков программирования. Предоставляет метрики сложности, дублирования, покрытия тестами, выявляет потенциальные ошибки, уязвимости, нарушения стандартов кодирования. Позволяет отслеживать динамику изменения качества, интегрируется с системами контроля версий.
• PVS-Studio: статический анализатор для языков C, C++, C#, Java, выявляющий ошибки, связанные с некорректным использованием памяти, неопределенным поведением, опечатками, уязвимостями. Предоставляет подробные пояснения к выявленным ошибкам и рекомендации по их исправлению.
• ESLint / JSHint: инструменты для статического анализа JavaScript-кода, проверяющие соответствие стандартам кодирования, выявляющие потенциальные проблемы, поддерживающие множество плагинов для расширения функциональности.
• Pylint / Flake8 / mypy: инструменты для анализа Python-кода, проверяющие стиль, наличие ошибок, соответствие рекомендациям PEP 8, а также выполняющие статическую типизацию (mypy).
• SpotBugs / FindBugs: анализаторы для Java, выявляющие паттерны, характерные для распространенных ошибок: некорректное использование коллекций, потенциальные состояния гонки, проблемы с производительностью.
• ReSharper / Rider: инструменты для анализа. NET-кода, интегрированные в среду разработки, предоставляющие широкие возможности рефакторинга, анализа качества, навигации по коду.

4. 2. Инструменты функционального тестирования

• Selenium WebDriver: фреймворк для автоматизации тестирования веб-приложений, позволяющий создавать скрипты, имитирующие действия пользователя в браузере. Поддерживает все основные браузеры, интеграцию с языками программирования (Java, Python, C#, JavaScript).
• Cypress: современный фреймворк для тестирования веб-приложений, ориентированный на разработчиков, обеспечивающий быструю обратную связь, простую отладку, автоматическое ожидание.
• JUnit / TestNG: фреймворки для модульного тестирования Java-приложений, предоставляющие аннотации для описания тестов, утверждения (assertions), механизмы параметризации, группировки тестов.
• PyTest: фреймворк для тестирования Python-приложений, поддерживающий простое написание тестов, параметризацию, фикстуры, плагины для расширения функциональности.
• Postman: инструмент для тестирования API, позволяющий создавать коллекции запросов, проверять ответы с помощью утверждений, автоматизировать выполнение тестов, генерировать отчеты.
• SoapUI: инструмент для тестирования веб-сервисов на основе SOAP и REST, поддерживающий функциональное тестирование, нагрузочное тестирование, проверку безопасности.

4. 3. Инструменты нагрузочного тестирования

• Apache JMeter: инструмент с открытым исходным кодом для нагрузочного тестирования, поддерживающий различные протоколы (HTTP, HTTPS, JDBC, FTP, SOAP, JMS), позволяющий создавать сложные профили нагрузки, анализировать результаты с помощью графиков и таблиц. Обладает гибкой системой плагинов.
• Yandex. Tank: инструмент для нагрузочного тестирования, разработанный в Яндексе, поддерживающий различные генераторы нагрузки (JMeter, Phantom, Pandora), предоставляющий удобные средства визуализации результатов в реальном времени, интеграцию с системами мониторинга.
• LoadRunner: коммерческий инструмент для нагрузочного тестирования от Micro Focus, поддерживающий широкий спектр протоколов и технологий, предоставляющий мощные средства анализа результатов, моделирования нагрузки.
• Gatling: инструмент с открытым исходным кодом для нагрузочного тестирования, основанный на Scala, обеспечивающий высокую производительность, удобные средства написания сценариев в виде кода, детальные отчеты в HTML-формате.
• k6: современный инструмент для нагрузочного тестирования, ориентированный на разработчиков, поддерживающий написание сценариев на JavaScript, интеграцию с CI/CD, облачное выполнение тестов.

4. 4. Инструменты анализа безопасности

• OWASP ZAP (Zed Attack Proxy): инструмент с открытым исходным кодом для поиска уязвимостей в веб-приложениях, включающий сканер, перехватывающий прокси-сервер, средства для ручного тестирования, API для автоматизации.
• Burp Suite: платформа для тестирования безопасности веб-приложений, включающая сканер, перехватывающий прокси, средства для анализа запросов, repeater для модификации и повторной отправки запросов, intruder для автоматизированных атак.
• Nessus: сканер уязвимостей, выявляющий проблемы конфигурации, отсутствие обновлений, известные уязвимости в программном обеспечении, сетевых сервисах.
• Metasploit: фреймворк для тестирования на проникновение, содержащий базу эксплойтов, вспомогательных модулей, payloads, позволяющий моделировать реальные атаки.
• SQLMap: инструмент для автоматизации обнаружения и эксплуатации SQL-инъекций, поддерживающий широкий спектр СУБД и техник инъекций.
• Wireshark: анализатор сетевого трафика, позволяющий перехватывать и анализировать пакеты, выявлять проблемы в сетевом взаимодействии, проверять шифрование.

5. Организация процесса компьютерной экспертизы ПО
6. 1. Подготовительный этап

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

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

Пример матрицы требований:

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

5. 2. Проведение исследования

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

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

При выявлении несоответствий эксперт фиксирует:

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

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

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

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

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

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

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

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

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

5. 4. Подготовка заключения

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

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

6. Инженерные особенности экспертизы для различных классов программного обеспечения
7. 1. Экспертиза веб-приложений

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

• Клиент-серверная архитектура: требует проверки как клиентской части (интерфейс, логика в браузере, работа с DOM, асинхронные запросы), так и серверной части (бизнес-логика, работа с данными, API).
• Многопользовательский режим: необходимо тестирование при одновременной работе многих пользователей, проверка корректности синхронизации данных, блокировок, обработки конкурентного доступа.
• Безопасность: веб-приложения особенно уязвимы для атак, требуется тщательная проверка защиты от SQL-инъекций, межсайтового скриптинга (XSS), подделки межсайтовых запросов (CSRF), включения файлов.
• Кросс-браузерность: проверка корректного отображения и функционирования в различных браузерах (Chrome, Firefox, Safari, Edge) и на различных версиях браузеров.
• Адаптивность интерфейса: проверка корректного отображения на экранах различного размера (десктопы, планшеты, смартфоны) в соответствии с требованиями к адаптивному дизайну.
• Производительность: измерение времени загрузки страниц, времени отклика API, проверка работы механизмов кэширования, сжатия данных, оптимизации запросов.
• Использование современных технологий: при использовании SPA (Single Page Application) на фреймворках (React, Angular, Vue. js) требуется проверка корректности работы маршрутизации, управления состоянием, виртуализации DOM.

6. 2. Экспертиза мобильных приложений

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

• Разнообразие платформ: iOS, Android, различные версии операционных систем, различные модели устройств с разными характеристиками требуют тестирования на каждом целевом устройстве или с использованием эмуляторов.
• Ограниченность ресурсов: необходимо проверять потребление памяти, заряда батареи, трафика, особенно для приложений, работающих в фоновом режиме.
• Использование датчиков и аппаратных возможностей: проверка работы с камерой, GPS, акселерометром, гироскопом, сканером отпечатков пальцев, другими встроенными датчиками.
• Работа в офлайн-режиме: проверка корректности работы при отсутствии сети, сохранения данных локально, синхронизации при восстановлении соединения.
• Особенности публикации: проверка соответствия требованиям магазинов приложений (App Store, Google Play, AppGallery), включая требования к иконкам, скриншотам, описанию, возрастным ограничениям.
• Прерывания: проверка поведения приложения при входящих звонках, SMS, уведомлениях, переключении между приложениями, сворачивании.
• Обновления: проверка корректности обновления приложения с сохранением данных пользователя.

6. 3. Экспертиза корпоративных информационных систем

Корпоративные системы (ERP, CRM, HRM, BPM) характеризуются:

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

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

Встраиваемые системы и ПО для оборудования (промышленные контроллеры, медицинское оборудование, автомобильные системы) имеют следующие особенности:

• Аппаратная зависимость: тестирование требует наличия целевого оборудования или точных эмуляторов, учитывающих все особенности аппаратной платформы.
• Режим реального времени: жесткие требования к времени реакции на события, необходимости проверки соблюдения временных ограничений, детерминизма.
• Ограниченность ресурсов: критически важна эффективность использования памяти (RAM, ROM), процессорного времени, энергии (для батарейных устройств).
• Надежность и безопасность: высокие требования к безотказной работе (часто требуется сертификация по стандартам IEC 61508, ISO 26262, DO-178C), необходимости длительного тестирования стабильности.
• Обновление прошивок: проверка механизмов обновления программного обеспечения на устройстве, защиты от сбоев при обновлении, возможности восстановления.
• Взаимодействие с периферией: проверка работы с датчиками, исполнительными механизмами, интерфейсами ввода-вывода (GPIO, ADC, DAC, PWM).
• Диагностика и самодиагностика: проверка встроенных средств диагностики, регистрации ошибок, оповещения о неисправностях.

7. Типовые проблемы, выявляемые при компьютерной экспертизе ПО

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

7. 1. Проблемы функциональной полноты

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

7. 2. Проблемы производительности

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

7. 3. Проблемы надежности

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

7. 4. Проблемы безопасности

• Недостаточная защита данных: конфиденциальные данные передаются по сети в открытом виде, хранятся в базе данных без шифрования, доступны для просмотра посторонним.
• Уязвимости к атакам: SQL-инъекции, межсайтовый скриптинг (XSS), подделка межсайтовых запросов (CSRF), слабые механизмы аутентификации, отсутствие защиты от перебора паролей.
• Избыточные права: пользователи имеют доступ к функциям и данным, не предусмотренным их ролями, возможно выполнение неавторизованных операций.
• Слабые механизмы аутентификации: использование слабых паролей, отсутствие двухфакторной аутентификации (если требуется), некорректное управление сессиями, отсутствие защиты от перехвата сессий.
• Недостаточное логирование: отсутствие регистрации значимых событий безопасности, что затрудняет расследование инцидентов.

7. 5. Проблемы документации

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

8. Оценка трудоемкости устранения недостатков

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

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

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

8. 2. Методы оценки трудоемкости

• Экспертная оценка: основана на опыте эксперта и разработчиков в аналогичных проектах. Может проводиться с использованием методов структурированных интервью, Дельфи.
• Оценка по аналогии: сравнение с аналогичными проектами или исправлениями, для которых известна фактическая трудоемкость.
• Метод функциональных точек: оценка размера программного продукта на основе количества и сложности функций, затем расчет трудоемкости на основе производительности.
• Метод COCOMO (COnstructive COst MOdel): модель оценки трудоемкости разработки ПО, основанная на размере программы (в строках кода или функциональных точках) и наборе поправочных коэффициентов (сложность, надежность, опыт команды).
• Декомпозиция задач: разбиение работ по устранению недостатков на отдельные задачи (анализ, проектирование, кодирование, тестирование, документирование) с оценкой каждой задачи в человеко-часах.

8. 3. Представление результатов оценки

Результаты оценки трудоемкости представляются в виде:

• Общей трудоемкости в человеко-часах или человеко-днях.
  • Распределения трудоемкости по категориям недостатков.
  • Оценки календарной продолжительности работ (при заданном количестве разработчиков).
  • Оценки стоимости работ (при известной стоимости человеко-часа).

9. Особенности документирования результатов компьютерной экспертизы ПО

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

9. 1. Требования к технической документации

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

9. 2. Состав приложений к заключению

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

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

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

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

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

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

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

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

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

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