• Функциональное тестирование, которое проверяет, могут ли указанные функции выполняться системой с требуемым уровнем производительности в определенных условиях.
• Тестирование интерфейса, обеспечивающее правильную работу внешнего и внутреннего интерфейсов.
• Экологические испытания, при которых система помещается в ряд сред для обеспечения приемлемой работы во всех заданных условиях. Экологические испытания обычно включают испытания в условиях различной температуры, влажности, рельефа местности и количества осадков, на влияние пыли, вибрации, стресса и т. д.
• Технологические испытания, на соответствие продукта требованиям модульности, взаимозаменяемости и доступности.
• Проверку качества, включающая удобство использования, надежность, ремонтопригодность и доступность.
Валидационные испытания отличаются тем, что их проводят для конечного продукта в натурных или смоделированных условиях эксплуатации. Согласованы программа и методика оценки результатов данных испытаний. Близким аналогом являются сертификационные испытания. На них требуется подтвердить соответствие декларируемого уровня безопасности и потребительских качеств товара или системы.
Развиваются численные методы модельных испытаний объектов. Для этого используют цифровые двойники (ЦД) и виртуальное моделирование динамических сценариев работы системы. Следует стремиться к замене существенной части натурных испытаний системы (как правило, длительных и дорогостоящих) результатами моделирования статических и динамических режимов эксплуатации, а также нерасчетных случаев, включая частичные отказы узлов и агрегатов, нештатные условия применения, и др.
Для сокращения плановых сроков процессов интеграции и испытаний системы используют:
a) математические модели, ЦД и виртуальное моделирование;
b) проведение ускоренных эквивалентно-циклических испытаний;
c) эмулятор аппаратного оборудования для непроверенного программного обеспечения, или проверенное программное обеспечение для непроверенного оборудования; и др.
Пример выбора необходимого количества испытаний. Во время эксплуатации на серийном изделии произошла авария с разрушением вращающейся части конструкции газотурбинного двигателя. Был собран совет экспертов отрасли для установления причин разрушения конструкции и выработки мер по искоренению дефекта на изделии. В ходе обсуждения один из приглашенных экспертов высказал мнение, что имеющиеся данные по измерениям напряжений и термометрированию изделия неполны, и нужно повторить эксперимент. Затратный процесс термометрирования газовой турбины (измерение максимальных температур деталей по внутреннему тракту двигателя) совместно с тензометрированием (измерение максимальных рабочих напряжений в ответственных деталях) на рабочих режимах проводится на наземном испытательном стенде один раз в истории изделия для верификации использованных в проекте максимальных расчетных температур и напряжений их действительным значениям. Все ответственные детали неподвижной и вращающейся частей изделия препарируют термопарами и тензодатчиками. Сверлят множество отверстий в деталях для прокладки проводов от датчиков. Используют специальное устройство для вывода сигналов от датчиков с вращающихся деталей на пульт управления. В труднодоступных местах наносят специальные термокраски, меняющие цвет в зависимости от температуры детали. Затраты включают, кроме стоимости натурного изделия, датчиков и времени работы стенда по программе испытаний, также оплату усилий по препарированию объекта (по срокам иногда от полугода до года) и последующей расшифровке экспериментальных данных. Все это сложилось в вопрос «Давайте представим, что прошел год с лишним, все работы завершены, уточненные данные получены. Какие выводы по причинам обсуждаемой аварии мы сможем тогда сделать?» Эксперт после небольшой паузы чистосердечно ответил: «Будем думать!» Вопрос по дополнительным испытаниям был снят с повестки.
Первый экземпляр системы, произведенный серийным процессом, проходит полное тестирование. Если производится более одной системы, каждая последующая единица продукции должна быть протестирована так, чтобы убедиться, что производство и технологические процессы продолжают оставаться эффективными. Часто этот процесс называют приемо-сдаточными испытаниями, чтобы принять систему как отвечающую первоначальным требованиям.
Периодическое наблюдение за продуктом продолжается на этапе эксплуатации и преследует две основные цели. Во-первых, защитить от непредвиденных, но неизбежных возникающих последствий разрушительного характера, во-вторых, обеспечить непрерывный поток информации в семейство моделей, лежащих в основе структуры, чтобы обеспечить постоянные улучшения системы и информировать проектировщиков. Для продукции, выпускаемой большим тиражом, регулярно проводятся испытания случайно выбранного изделия для проверки стабильности качества изготовления.
?
2.7 Проведение технических обзоров проекта
Фазы жизненного цикла (ЖЦ) проекта или программы разделены, что позволяет команде разработчиков пошагово оценивать прогресс, характеристики системы и проекта, планировать следующий этап работ, облегчает принятие решений руководителям проекта. Структура управления ЖЦ включает все работы для выполнения программы или проекта в различных фазах, разделенных контрольными рубежами (КР). Для контроля хода проекта и утверждения решений на каждом КР проводят технический обзор, который включает критический разбор результатов участниками работ, планирование и реализацию корректирующих действий перед переходом к следующему этапу проекта. На обзоре рассматривают доказательства соответствия результатов проведенного этапа выставленным критериям. Промежуточные результаты проектирования просматриваются, тестируются и оцениваются, чтобы уточнить текущий статус работ и принять решения о дальнейших действиях.
КР являются основными вехами, на которых лицо, принимающее решение, определяет готовность проекта к переходу на следующий этап жизненного цикла. Для каждого КР программы устанавливаются входные критерии, необходимые до начала обзора, и выходные критерии успешного завершения обзора. Процесс обзора проекта должен подтвердить:
• обеспечение планового выполнения технических работ;
• функциональную интеграцию;
• обеспечение решения проблем в кратчайшие сроки и до самых низких уровней;
• поддержку решений на основе событий;
• сроки и бюджет проекта;
• готовность к исполнению следующего этапа;
• контроль рисков.
При прохождении контрольного рубежа имеется набор вариантов решения:
1. Принято: можно переходить к следующей стадии проекта.
2. Принято с оговорками: переходить и выполнить затребованные действия, устранив замечания, причем проверка исполнения замечаний проводится, как правило, на следующем КР.
3. Не принято: не переходить, дополнить работы этапа и повторить КР по готовности.
4. Не принято: вернуться на предыдущую стадию.
5. Не принято: заморозить (временно остановить) мероприятия проекта.
6. Невосстановимо: закрыть проект.
Количество требуемых обзоров и их соответствующий объем зависят от сложности и размера рассматриваемой системы. Технический риск, связанный с системой, также влияет на количество запланированных проверок. Например, система, в которой широко используется покупаемое оборудование ПКИ, может рассматриваться как проект с низким уровнем риска по сравнению с проектом, разработанным заново. Ожидается, что для системы с большим процентом ПКИ будет проведено меньше обзоров на более низком уровне, чем для оригинального проекта развития.
На рис. 3 показаны основные обзоры в ключевых точках проекта, привязанные по срокам и фазам жизненного цикла коммерческого самолета.
Рис. 3. Набор обзоров программы ЖЦ самолета
На этапе разработки системы минимальный набор обзоров должен включать обзор системных требований, анализ эскизного проекта, критический анализ технического проекта, анализ готовности к интеграционным испытаниям, обзор готовности производства, анализ эксплуатационной готовности, обзор возможностей эксплуатации, а также обзор вывода из эксплуатации и утилизации.
Эти обзоры отражают основные этапы разработки системы, должны иметь четко определенные критерии входа и выхода. Аудит физической конфигурации системы должен использовать ту же концепцию определения достижений и критериев успеха. Каждый обзор на соответствующем КР содержит новую, актуализированную базовую версию системы. Она включает согласованный набор требований, проектов или документов, относящихся к системе или продукту.
Последовательное прохождение системы технических обзоров является важным элементом верификации результатов разработки проекта системы. Формальные обзоры проекта запланированы на всех ключевых этапах ЖЦ системы. Иногда в них участвуют приглашенные внешние эксперты, чтобы гарантировать, что функциональный дизайн удовлетворяет требованиям, срокам и бюджету проекта. На этапе проектирования могут потребоваться изменения ранее принятых решений из-за появления новых технологий, технических проблем или добавленных требований заинтересованных лиц. Руководитель проекта несет ответственность за мониторинг изменений, определение их воздействия на планы, графики, бюджеты проекта и процесс рассмотрения и утверждения изменений.
Обзор системных требований должен демонстрировать прогресс в достижении жизнеспособных, прослеживаемых системных требований, сбалансированных по стоимости, срокам и рискам, путем подтверждения того, что:
а) требования клиентов (включая среду, режимы использования и другие соответствующие факторы) проанализированы и переведены в функциональные требования, в том числе, к производительности, для конкретной системы;
б) планы верификации технологий завершены;
в) выявлены и оценены критические технологии для людей, продуктов и технологических решений;
г) риски идентифицируются и количественно оцениваются, предусмотрены меры по снижению рисков;
д) был определен общесистемный подход к удовлетворению требований (включая интерфейсы) для основных системных функций.
Критический анализ проекта должен подтвердить, что детальный проект всей системы завершен, соответствует требованиям, и вся система готова к производству и кодированию. А именно:
• решены плановые вопросы по системе, функциональным областям и подсистемам;
• полностью определены требования к проектированию системы, в том числе по стоимости, графику, производительности и риску для жизненного цикла, а физическая архитектура системы представляет интегрированный детальный проект для удовлетворения требований, включая функциональную совместимость и интерфейсы;
• установлена совместимость дизайна системы с внешними интерфейсами;
• план управления рисками уточнен для следующего этапа работ;
• готовность планов производства и обслуживания;
• актуализированы планы приобретения и развертывания системы;
• критические вехи, критерии успеха и показатели действительны для продолжения технических усилий.
Изменения в конструкции, как правило, увеличивают стоимость проекта. На стадии разработки проведение изменений обычно намного дешевле, чем устранение обнаруженных проблем на этапах производства и эксплуатации. Так как стадия проектирования не может продолжаться бесконечно, руководство проекта устанавливает дату «заморозки» результатов, после которой никакие изменения конструкции системы не допускаются.
Менеджер проекта НИОКР должен проводить регулярные текущие проверки постановки и исполнения задач в соответствии с плановыми сроками. При каждом рассмотрении исполнители должны:
1) иметь возможность объяснить компромиссные решения техническими деталями и соответствующим обоснованием;
2) обеспечить надлежащее участие в дискуссии, в том числе субподрядчиков, продавцов и поставщиков;
3) предоставить отчетную информацию и элементы, необходимые для демонстрации и подтверждения того, что плановые вехи, связанные с проверкой, были достигнуты;
4) документировать ход разбирательства, включая ключевые моменты, решения и вопросы с соответствующим обоснованием; открытые и нерешенные вопросы с их требованиями по закрытию и указанием ответственных лиц.
Исполнители должны проводить обзоры подсистем, чтобы гарантировать, что требования, включая требования к интерфейсу (глава 3.6), для подсистем определены, сбалансированы по сегментам и интерфейсам, задокументированы и выполнены. Эти обзоры должны подтвердить решение проблем и оценить прогресс разработки каждой подсистемы в контексте жизненного цикла. Анализ подсистемы должен учитывать воздействие на другие элементы системы, а также взаимодействие с ними, документацию, риски и, если применимо, готовность к верификации и документацию. Как правило, проверка подсистемы должна подтвердить, что при рассмотрении требований к подсистеме требования, выделенные для КЭ, полны и включены в спецификацию, соответствующая документация по управлению интерфейсом установлена, требования, выделенные для КЭ, являются реализуемыми, разработаны необходимые спецификации процессов и материалов.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/chitat-onlayn/?art=70354237&lfrom=174836202&ffile=1) на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
QFD: Разработка продукции и технологических процессов на основе требований и ожиданий потребителей, Ю. А. Вашуков, А. Я. Дмитриев, Т. А. Митрошкина. – Самара: Изд-во Самарского гос. аэрокосм. ун-та, 2012. – 32 с.
