Управление интерфейсом на этапе интеграции поддерживает процедуры сборки для обеспечения надлежащей маркировки и совместимости интерфейса со спецификациями и документом управления интерфейсом. Верификация требований к интерфейсам является критическим аспектом общей верификации системы, часто с использованием эмуляторов, которые должны соответствовать характеристикам операционной среды и требованиям проверки интерфейса.
Сбои, возникающие в процессе интеграции, имеют несколько основных причин, включая плохое управление (плохое согласование ресурсов с требуемыми задачами, плохую коммуникацию и ненадежную функциональность, связанную с тем или иным объектом), плохие навыки интеграции, инструменты или испытательное оборудование.
Входными данными для процесса интеграции системы являются следующие:
• концепция операций, которая определяет, как система должна работать и будет помогать в проверке и интеграции;
• утвержденные требования к системе и подсистемам;
• архитектура проекта высокого уровня, где определены интеграционные операции;
• материалы детального конструирования, которые содержат конструктивные ограничения для подсистем и систем;
• стратегия интеграции, где определено, когда и где подсистемы должны быть сгруппированы и развернуты;
• разработанные аппаратно-программные компоненты и подсистемы, в которых завершена интеграция на своем уровне и они готовы к следующему уровню верификации.
При создании реалистичной среды испытаний и оценки необходимо учитывать следующие факторы.
1. Выбор тестового задания. Система и ее компоненты, выбранные для испытаний, должны представлять собой проектную или производственную конфигурацию, включающую все последние утвержденные инженерные изменения.
2. Выбор испытательной площадки. Система должна быть протестирована в среде, которая будет характерна для операций пользователя; Выбранная площадка должна в максимально возможной степени имитировать условия Арктики или тропиков, равнинную или гористую местность, и др.
3. Процедуры тестирования. Выполнение задач испытаний обычно включает выполнение задач эксплуатации и технического обслуживания, которые должны следовать официально утвержденным техническим руководствам.
4. Испытательный персонал. Сюда входят лица, которые будут фактически эксплуатировать и обслуживать систему на протяжении всего испытания, вспомогательные инженеры, техники, регистраторы данных, аналитики и администраторы, которые оказывают помощь в проведении всей программы испытаний. Отобранный эксплуатационный персонал должен соответствовать требованиям с точки зрения количества и уровня квалификации.
5. Тестирование и поддержка оборудования и ПО. При использовании оборудования наземного обслуживания, испытательного оборудования, программного обеспечения следует использовать только те объекты, которые допущены к эксплуатации.
6. Снабжение испытаний. Сюда входят все запасные части, расходные материалы и вспомогательные запасы, необходимые для завершения тестирования и оценки системы. Желательна реалистичная конфигурация.
7. Испытательные мощности и ресурсы. Должны быть заранее определено и запланировано использование специальных помещений, испытательных камер, оборудования, средств экологического контроля, специальных приборов и сопутствующих ресурсов (например, тепла, воды, кондиционирования воздуха, электроэнергии, связи).
8. Требования к интерфейсу. Применимые интерфейсы и требования к тестированию должны быть определены и согласованы по всем направлениям по мере необходимости.
Во время системной интеграции дизайнеры должны быть доступны для поддержки тестирования и ввода в эксплуатацию. Они обеспечат соответствие первоначального дизайна интерфейса и разрешат изменения, требуемые при решении проблем, которые могут возникнуть во время интеграции и тестирования. В некоторых системах значительная часть системной интеграции и тестирования может быть проведена вне площадки сборки на заводе-изготовителе поставщика в качестве заводских интеграционных испытаний. Например, в процессе интеграции воздушных судов в качестве основных наземных стендов используют стенд системы электроснабжения самолета; стенд гидросистемы и механизмов с полунатурным моделированием комплексной системы управления и системой управления общесамолетным оборудованием, так называемую «железную птицу»; стенд комплексирования бортового оборудования, или «электронную птицу».
В результате процесса должен быть получен интегрированный продукт со всеми системными взаимодействиями. Оформлены документация и руководства, включая модели, данные и отчеты системного анализа, подтверждающие обоснование готовности и доступные для будущего анализа во время работы системы; отчеты по интеграции продуктов (для поддержки процесса управления техническими данными); чертежи сборки и верификации; требования к эмулятору (где приложимо); и документированные ограничения для аппаратного и программного обеспечения.
Следует отметить, что кроме технологической интеграции на этапе необходимо реализовать управленческую компоненту интеграции. Она включает интеграцию по срокам работ, затратам, ресурсам, рискам и координацию всех частей процесса интеграции в целом. Причем приоритет управленческой интеграции выше, чем технологической, из-за большего числа охвата факторов.
Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.
2.7. Верификация и валидация
Одним из основных принципов системно-инженерного подхода является пошаговая проверка результатов работ на соответствие выставленным требованиям. Для проверки результатов каждого шага разработки используются два метода: верификация и валидация.
Верификация представляет процесс подтверждения того, что требование или система соответствует входным данным. Проверка требования отвечает на вопрос: действительно ли система удовлетворяет этому определенному требованию? Верификация системы или ее компонента показывает, что синтез системы выполняется правильно, гарантирует, что система соответствует требованиям. Этот процесс выполняется на различных этапах создания системы, как правило, внутренними силами разработчика с привлечением коллег для контроля результатов. Используют четыре метода верификации: инспекцию, анализ, демонстрацию, испытания (тесты).
Каждый элемент системы проверяется на соответствие требованиям. Метод верификации для каждого требования должен начать формироваться на этапе анализа требований. Важно определить, как каждое требование будет проверяться на раннем этапе, чтобы любое оборудование для верификации или необходимое моделирование были доступны к этапу верификации.
Планы верификации должны быть рассмотрены заинтересованными сторонами проверяемого требования. Согласие заинтересованных сторон с планом верификации помогает обеспечить единообразное понимание требования с проектировщиками. Стоимость методов верификации важно учитывать, поскольку они могут сильно различаться по стоимости, но достигать одной и той же цели.
Валидация представляет процесс подтверждения того, что набор требований, проект или система соответствует предназначению заказчика, другими словами, построена потребная система. Валидация определяет правильность и полноту конечного продукта, и гарантирует, что система удовлетворит реальные потребности заинтересованных сторон в предполагаемой среде эксплуатации. Как правило, проводится с привлечением внешних инстанций (регулирующих органов, представителей заказчика, межведомственных комиссий и др.). На этапе валидации система проверяется во всех режимах работы или сценариях. Как и на этапе верификации, этап валидации необходимо планировать заранее. Причина раннего планирования валидации в том, что она предназначена для обеспечения окончательного утверждения системы заинтересованными сторонами. Также при валидации могут потребоваться компоненты инфраструктуры, которые нужно изготовить к определенному сроку.
Вкратце различия применения верификации и валидации можно изложить следующим образом. Верификация проводится:
• в процессе разработки;
• чтобы убедиться, что утвержденные требования будут выполнены;
• как правило, в лабораторных условиях (не натурных);
• верификация ориентирована на компоненты и подсистемы.
Аналогом в РФ выступают компонентные испытания и проверки на моделирующих стендах.
Верификация системы или ее компонентов и подсистем является более общим понятием, чем просто проведение испытания. Целью верификации является проверка, что верифицируемый объект соответствует требованиям к нему, реализован без лишних функций, удовлетворяет проектным спецификациям и стандартам. Как уже упоминалось, процесс верификации включает разные методы, то есть процесс испытаний является составной частью процесса верификации.
Валидация выполняется:
a) в процессе или после процедуры интеграции системы;
b) обычно в реальных или смоделированных условиях эксплуатации;
c) для проверки ожиданий заинтересованных сторон;
d) желательно в составе полномасштабного варианта системы.
Аналогом в РФ являются сертификация, государственные или межведомственные испытания.
Валидация системы служит доказательством, что в результате разработки системы достигнуты цели, которые планировали для эксплуатации. Другими словами, это проверка соответствия системы ожиданиям заказчика, гарантия ее качества. Когда экономически выгодно и гарантировано анализом, расходы программы могут быть смягчены путем объединения тестов для одновременной верификации и валидации конечного продукта или системы.
Основные задачи верификации при разработке перечислены ниже.
1. Планирование верификации конструкторских решений в соответствии с планом верификации, контрактом с заказчиком, применимой фазы жизненного цикла и до уровня структуры системы. Соответствующий уровень может варьироваться от системы и подсистемы вниз до уровня компонентов. Он может включать выбор и определение соответствующего метода для проверки проектных решений, процедуры верификации для следования выбранному методу (включая критерии определения успеха или неудачи проверки); создание и проверку влияния окружающей среды (например, климатические условия, оборудование, сооружения, измерительные приборы и т.д.), в которой будут реализованы метод и процедуры проверки.
2. Выполнение плана верификации проектных решений. Используют выбранные методы и процедуры в установленной для проверки окружающей среде, чтобы осуществить сбор и оценку результатов верификации для показа соответствия требованиям представленного физического решения, или определить отклонения (непроверяемые требования и ограничения). Отклонения должны быть документированы в отчете по несоответствиям или в интегрированной базе данных предприятия для оценки и разрешения проблем.
3. Повторение верификации в соответствии с планом, методом испытания или процедурой, когда отклонения (разброс данных) были вызваны недостаточной адаптацией к условиям окружающей среды в эксплуатации.
4. Фиксация записи результатов верификации, в том числе: корректирующих действий; уроков исправления, достигнутых результатов; компромиссов, анализа рисков, результатов испытаний; отклонений и проверенных решений проекта в хранилище данных предприятия.
Валидация может охватывать следующие действия.
• Тестирование производительности для проверки того, что продукт или система функционирует должным образом и соответствует ожиданиям клиентов.
• Испытание для подтверждения того, что изделие соответствует всем законодательным требованиям, требованиям безопасности и нормативным требованиям, включая формальные приемочные испытания.