Table of Contents

Понимание проверки и проверки

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

Например, в автомобильном проекте ADAS (Advanced Driver-Assistance Systems) проверка может включать в себя тестирование того, что алгоритм синтеза датчиков производит правильный выход с учетом конкретных входов, в то время как проверка будет включать в себя тестирование вождения транспортного средства в реальных условиях движения, чтобы гарантировать, что система безопасно избегает препятствий.

Почему важен надежный V&V план

Слабый или неполный план V&V может привести к перерасходу средств, задержкам в графике и даже катастрофическим сбоям. Согласно Справочнику по разработке систем INCOSE, дефекты, обнаруженные позже в жизненном цикле разработки, могут стоить в 10-100 раз больше, чем обнаруженные на ранней стадии. Надежный план помогает выявить проблемы на самой ранней стадии, снижает переработку и обеспечивает объективное доказательство качества системы. Он также поддерживает соблюдение нормативных требований в таких отраслях, как аэрокосмическая промышленность, медицинские устройства и оборона, где валидация критически важных для безопасности функций является обязательной.

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

Ключевые компоненты V&V-плана

Комплексный план V&V обычно включает следующие элементы, каждый из которых мы рассмотрим в следующих разделах:

  • Область применения и цели: Определение того, какие части системы должны быть проверены/проверены, и общие цели.
  • Требование матрицы прослеживаемости (RTM): Связывает каждое требование с конкретными действиями V&V и тестовыми случаями.
  • Тестовая стратегия: Очерчивает методы (например, инспекция, анализ, демонстрация, испытание) и уровень строгости.
  • Испытываемые случаи и процедуры: Подробные шаги, входы, ожидаемые результаты и критерии прохождения / отказа.
  • Распределение ресурсов: Персонал, инструменты, среда тестирования и бюджет.
  • Расписание и основные моменты: Фазы V&V согласуются с планом развития.
  • Управление рисками: Идентификация критических рисков и соответствующий акцент V&V.
  • Управление данными и документация: Как будут записываться, храниться и сообщаться результаты.
  • Критерии принятия: Формальные критерии «года/него» для каждого основного обзорного окна.

Пошаговый процесс разработки надежного V&V-плана

1.Определить четкие цели

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

2. Собрать и проанализировать требования

Соберите все системные требования из спецификаций, включая функциональные, эксплуатационные, интерфейсные, требования безопасности, безопасности, нормативные и экологические требования. Именно здесь матрица прослеживаемости требований (RTM) становится бесценной. Каждое требование должно быть однозначно идентифицировано и затем связано с одним или несколькими действиями V & V. Например, требование «Система должна реагировать на пользовательский ввод в течение 100 мс» будет связано с тестами проверки производительности. Кроме того, учитывайте ожидания заинтересованных сторон, которые не могут быть официально документированы - эти часто приводят сценарии проверки.

3. Разработка стратегий тестирования V&V

В зависимости от типа требования выберите подходящие методы. Общими методами являются:

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

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

4.Проектирование детальных тестовых случаев

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

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

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

5.Эффективное распределение ресурсов

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

6. Расписание мероприятий V&V

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

7. Определить критерии принятия и показатели успеха

Для каждого вида деятельности V&V определите, что представляет собой пропуск или отказ. Эти критерии должны быть объективными и однозначными. Примеры: «Все этапы испытаний выполнены без ошибок; измеренное время повышения < 5 ms; no safety violations observed.” Also define system-level acceptance criteria for formal delivery, such as “All high-priority verification items passed; all critical validation scenarios successful; no open anomalies with severity > 2». Метрики отслеживания, такие как прогресс проверки (% проверенных требований), плотность дефектов и среднее время между отказами для проверки.

Лучшие практики для надежного планирования V & V

Вовлекать заинтересованных лиц рано и часто

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

Сохраняйте прослеживаемость на протяжении всего

Матрица прослеживаемости требований (RTM) имеет важное значение. Но отслеживаемость должна выходить за рамки связывания требований к тестовым случаям - она также должна быть связана со спецификациями, проектными документами, оценками рисков и даже отчетами о дефектах. Это позволяет быстро оценить влияние изменения и доказать, что каждое требование было проверено. Используйте такие инструменты, как IBM DOORS, Jama Connect или Polarion, для автоматического поддержания прослеживаемости.

Автоматизация там, где это возможно

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

Документировать тщательно и правильно

Все мероприятия по V&V должны быть задокументированы с достаточной детализацией для поддержки аудитов и будущего технического обслуживания. Это включает в себя планы испытаний, процедуры испытаний, результаты испытаний (с доказательствами прохождения / отказа), отчеты об аномалиях и матрицы прослеживаемости. Используйте контроль версий для всей документации. В регулируемых отраслях (например, FDA 21 CFR Part 820, ISO 13485) документация должна следовать формализованным процедурам контроля изменений и выписки.

Обновление и повторный анализ плана

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

Обычные подводные камни, чтобы избежать

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

Реальное применение: тематическое исследование

Рассмотрим проект по разработке новой системы управления полетом беспилотного летательного аппарата (БПЛА). План V&V может включать:

  • Проверка программного обеспечения автопилота с использованием моделирования «модель в цикле» (метод анализа) для подтверждения соответствия законов управления пределам стабильности.
  • Интеграционное тестирование интерфейса аппаратно-программного обеспечения с использованием аппаратных средств в цикле тестирования (метод тестирования).
  • Проверка полетов в контролируемом воздушном пространстве с пилотом безопасности (демонстрация + испытание).
  • Проверка кода на соответствие целям DO-178C.

План будет отслеживать каждое требование (например, «БПЛА должен поддерживать высоту в пределах ± 10 футов при устойчивых ветрах в 20 узлов») к конкретным тестовым случаям в имитационных и фактических летных испытаниях. Расписание позволит провести многочисленные итерации: сначала проверка в имитационном моделировании, затем испытания на земле, затем ограниченные полеты и, наконец, полная проверка. Придерживаясь надежного плана, команда снижает риск аварии из-за необнаруженной ошибки программного обеспечения.

Инструменты и технологии для современного V&V

Инструменты с использованием рычагов могут значительно повысить эффективность V&V. Некоторые широко используемые инструменты включают:

  • Управление требованиями: IBM DOORS, Jama Connect, Siemens Polarion
  • Управление испытаниями: Micro Focus ALM, Jira with Zephyr, TestRail
  • Автоматизированное тестирование: Селен, Аппиум, Робот Рамка, Дженкинс (CI/CD)
  • Симуляция и анализ: MATLAB/Simulink, Ansys, Modelica
  • Отслеживаемость: Модельер систем Cameo, архитектор предприятия

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

Интеграция V&V с Agile и DevOps

Традиционные планы V&V часто связаны с разработкой водопадов, но они одинаково важны в Agile и DevOps. В Agile проверка выполняется непрерывно через автоматизированные единичные тесты и интеграционные тесты в каждом спринте. Валидация происходит в конце каждого спринта через обзоры спринта или демонстрации заинтересованным сторонам. План V&V должен быть живым документом, который определяет для каждой функции требуемые действия по проверке и валидации. В DevOps план должен касаться непрерывной интеграции (CI) и непрерывной доставки (CD) трубопроводов, гарантируя, что автоматизированные тесты блокируют продвижение к производству, если происходят сбои. Регрессионные наборы тестов становятся критическими. План также должен касаться мониторинга и валидации в производстве (например, канарейки выпуски, A/B тестирование) для подтверждения того, что система соответствует ожиданиям в реальных условиях.

Вывод: путь к надежным системам

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

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

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