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

c) планы тестирования (от ранней до поздней стадии). Желательно продемонстрировать функциональные связи (т.е. небольшие последовательные подфункции), которые при сквозном объединении раскрывают системную функцию.

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

Примерная последовательность шагов интеграции включает несколько этапов.

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

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

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

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

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

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

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

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

Входными данными для процесса интеграции системы являются следующие:

• концепция операций, которая определяет, как система должна работать и будет помогать в проверке и интеграции;

• утвержденные требования к системе и подсистемам;

• архитектура проекта высокого уровня, где определены интеграционные операции;

• материалы детального конструирования, которые содержат конструктивные ограничения для подсистем и систем;

• стратегия интеграции, где определено, когда и где подсистемы должны быть сгруппированы и развернуты;

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

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

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

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

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

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

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

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

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

8. Требования к интерфейсу. Применимые интерфейсы и требования к тестированию должны быть определены и согласованы по всем направлениям по мере необходимости.

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

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

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

Процесс интеграции продукта применяется не только к аппаратным и программным системам, но также к сервис-ориентированным решениям, спецификациям, планам и концепциям.

2.7. Верификация и валидация

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

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

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

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

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

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

• в процессе разработки;

• чтобы убедиться, что утвержденные требования будут выполнены;

• как правило, в лабораторных условиях (не натурных);

• верификация ориентирована на компоненты и подсистемы.

Аналогом в РФ выступают компонентные испытания и проверки на моделирующих стендах.

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

Валидация выполняется:

a) в процессе или после процедуры интеграции системы;

b) обычно в реальных или смоделированных условиях эксплуатации;

c) для проверки ожиданий заинтересованных сторон;

d) желательно в составе полномасштабного варианта системы.

Аналогом в РФ являются сертификация, государственные или межведомственные испытания.

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

Основные задачи верификации при разработке перечислены ниже.

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

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

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

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

Валидация может охватывать следующие действия.

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

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

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

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

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

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

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

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

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

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

При планировании испытаний требуется:

• разработать подробные квалификационные требования к испытаниям;

• определить подробные архитектуры компонентов для тестовых ресурсов (выявить, какие специальные установки, измерительные приспособления и тестовые заглушки необходимы);

• инициировать разработку и изготовление необходимых стендов;

• сформировать матрицы испытаний (выделить производные требования к функциональным и физическим архитектурам);

• написать детальные планы квалификации для каждого компонента с учетом ресурсов;

• создать сценарии тестирования с учетом нормативной документации;

• определить необходимые данные мотивации для каждого вида деятельности;

• написать программы испытаний и процедуры анализа результатов;

• определить графики по срокам испытаний и анализа.

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

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

Таблица 2

Легенда: А-анализ, Д-демонстрация, Т-тест, И-инспекция.

Для испытаний сложной техники широко применяют наземные стенды систем и компонентов, в том числе прочностные, где проводят статические и ресурсные испытания. Статические испытания определяют способность конструкции выдерживать высокие однократные нагрузки. Ресурсные испытания позволяют спрогнозировать поведение конструкции при повторяющихся нагрузках, характерных для типовой эксплуатации. В авиации, например, используют стенды для специальных испытаний, где проводят климатические тесты, а также испытания на внешние воздействия (попадание птиц, молниестойкость, пожаростойкость и др.). Полный набор базовых требований к испытаниям компонентов авиационной техники изложен в стандарте КТ-160 (DO-160G) «Условия окружающей среды и процедуры испытаний для бортового авиационного оборудования», содержащем 26 разделов. При работах по указанному стандарту используемые стенды должны быть предварительно сертифицированы на соответствие этим требованиям.

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

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

1) обеспечения правильной постановки задач моделирования (например, пользователи не могут вводить в расчет параметры, выходящие за пределы заданного диапазона режимов);

2) разработки процессов верификации и валидации инструментов, сертификации расчетных моделей на основе эксплуатационных данных и типовых экспериментов;

3) разработки и идентификации отраслевых стандартов для документации, управления конфигурацией и обеспечения качества моделирования;

4) разработки стандартного метода оценки достоверности результатов моделирования, представляемого уполномоченному органу, принимающему решения.

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

a) легко проверяемые требования;

b) пошаговые руководства по планированию, проведению и обработке испытаний;

c) модели и виртуальное моделирование;

d) надежная конструкция для изменения параметров компонента, процесса изготовления;

e) стандартизация процессов и документов;

f) применение ускоренных эквивалентно-циклических испытаний;

g) доступность испытательного оборудования (стендов) и измерительных систем;

h) независимость компонентов системы;

i) эмулятор оборудования для непроверенного программного обеспечения;

j) проверенное программное обеспечение для непроверенного оборудования;

k) модульное, «восходящее» (снизу-вверх) тестирование;

l) готовый план испытаний и процедуры тестирования, контроль критического пути графика работ.

В качестве примера важности верификации в космической программе рассмотрим происшествие с аппаратом Genesis в 2004 г. Он был запущен NASA в 2001 г. для сбора и анализа заряженных частиц, выдуваемых из короны Солнца (солнечного ветра). По плану возвращения на Землю, после входа в атмосферу капсула должна была выпустить первичный парашют, который бы замедлил и стабилизировал падение. Затем должен был раскрыться основной парашют для совершения мягкой посадки. Оба парашюта не сработали при приземлении, аппарат разбился о землю на скорости 350 км/час. Два разных комплекта контрольных датчиков (срабатывавших по величине ускорения торможения и по росту температуры) были включены наоборот (сравнительно со спецификациями). После работы аварийной комиссии выявлены причины происшествия:

1) схема использования датчиков для выпуска парашютов скопирована с предыдущей успешной модели;

2) верификационные требования расплывчаты, наземный тест срабатывания на центрифуге не затребован;

3) конструктор проверил срабатывание датчиков (открыто-закрыто), при этом не была проведена верификация ориентации датчиков;

4) электрик-монтажник некорректно провел верификацию ориентации по чертежу;

5) проверяющие вынесли решение, что проект системы выполнен правильно, так как скопирован с удачного аналога;

6) инженер, готовивший аппарат к полету, не замкнул обратную связь с проектантом, т.к. не потребовал обсудить результаты испытаний.

В результате аварии виновными признаны конструктор (не проведен обзор проекта) и испытатель (не выполнена верификация системы выпуска из-за копирования предыдущего решения).

2.8. Риски и возможности

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