Текст книги "Секреты успешных НИОКР"

1.5 Конфигурация и технические данные системы

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

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

В процессе распределения функциональных требований по разным КЭ нужно гарантировать, что каждое требование будет выполняться, по крайней мере, одной из подсистем или КЭ. Полученные распределения отображаются в виде «матрицы прослеживаемости требований». Некоторые функциональные требования являются общей ответственностью нескольких КЭ. Например, масса автомобиля является суммой масс всех КЭ. Если масса любого из них изменяется, то изменяется и общая масса автомобиля.

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

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

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

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

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

Частным случаем управления конфигурацией является проведение изменений в проекте. Изменением называют модификацию ранее согласованных продуктов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов, и т. п. Правила внесения изменений в конструкцию изложены в ГОСТ 2.503—2013. Решения об изменениях проекта принимают, если в процессе проектирования выявлены места, где конструкция неудовлетворительна из-за невыполнения функций, сборки, обслуживания или внешнего вида. Некоторые изменения неизбежно происходят на разных этапах процесса проектирования. Причинами являются изменения требований клиентов, изменения в технологиях и ресурсах, и так далее. На более поздних фазах разработки, таких как этап рабочего проектирования, небольшое изменение в спецификации системы может оказать значительное влияние на всю систему. Следует определять причины изменений как можно раньше. Чем позже в проекте происходят изменения, тем дороже они становятся. Необходимо соблюдать надлежащую процедуру контроля изменений, чтобы свести к минимуму воздействие на всю разработанную систему. Одной из задач руководителя проекта является минимизация количества изменений конструкции для каждой подсистемы.

Общие данные программы, то есть многообразие видов используемой информации, можно разделить на технические данные, программное обеспечение, управленческую и финансовую информацию. Информацией называют организованные данные, которые имеют значение и ценность для получателя. В каждом проекте или программе должны быть определены наборы ключевых технических данных, используемых в течение жизненного цикла системы. Их основу составляют полные сведения о продукте, включая определение требований, конструирование, испытания, производство, упаковку, хранение, эксплуатацию, обслуживание, модификации и утилизацию продукта. Текущая версия конфигурации также входит в технические данные. ГОСТ Р 58675—2019 «Автоматизированная система управления данными об изделии. Общие требования» включает полезные рекомендации по составу информации.

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

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

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

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

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

• Данные о качестве, порождаемые на всех этапах контроля. Содержат сведения о степени соответствия экземпляров изделия и его компонентов заданным техническим требованиям, техническим условиям, требованиям стандартов, нормативно-технических документов системы качества.

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

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

Сегодняшний этап цифровизации (развития компьютерных технологий и связанных с этим сфер деятельности) часто называют «цифровой индустрией 4.0». Его характеризуют, например, следующими признаками (зависит от источников информации).

1. Компьютеризация для цифрового управления всеми основными компонентами производства.

2. Сетевое взаимодействие между компонентами.

3. Создание цифрового отображения или «виртуального двойника» предприятия (визуализация бизнес-процессов).

4. Прозрачность цифрового отображения аналитических систем с так называемыми «большими данными».

5. Прогнозирование.

6. Адаптивность бизнеса к изменяющимся внешним условиям.

Можно представить упрощенный вариант трехуровневой схемы иерархии информационной системы предприятия. На первом (верхнем) уровне расположен блок-интегратор бизнес-процессов, например, интеллектуальной системы управления предприятием (Intellectual Enterprise Management). На втором уровне логично расположить три обеспечивающих блока бизнес-процессов, связывающих первый (управленческий) уровень с третьим, нижерасположенным, производственным уровнем. Например, закупки и логистику, управление конфигурацией, управление знаниями. На третьем, фундаментном, уровне расположены три основных производственных направления организации: конструирование, производство и послепродажное обслуживание. Важным преимуществом построения такого «информационного дерева» является наличие на рынке альтернатив всего набора программного обеспечения для перечисленных блоков. Предложенное дерево возможно наращивать в разных направлениях, опять же в зависимости от структуры бизнес-процессов организации, их необходимой детализации, и др.

При формировании цифрового предприятия можно обратиться к сайту Министерства цифрового развития РФ. Там в дополнение к паспорту федерального проекта «Цифровые технологии» программы «Цифровая экономика» приведена дорожная карта по развитию «сквозной» цифровой структуры «Новые производственные технологии». Главной целью направления цифровизации не должны являться дорогостоящие развитие и смена версий программного обеспечения, это только часть бизнеса компании, обеспечивающая быстрое и качественное функционирование его компонентов, которая должна окупаться в процессе использования цифровых инструментов.

1.6 Верификация и валидация,
обзоры проекта

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

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

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

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

Верификация ориентирована на компоненты и подсистемы, и проводится:

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

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

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

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

1. демонстрация соответствия конструкции и характеристик установленным требованиям на заданных уровнях;

2. обеспечение соответствия продукта разработанному проекту, отсутствия дефектов производства, и пригодности к применению;

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

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

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

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

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

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

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

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

Испытания являются наиболее ресурсоемкой методикой верификации. Они делятся на три группы.

1. Испытания, проводимые разработчиком, чтобы убедиться, что проект системы соответствует системным требованиям.

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

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

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

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

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

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

Методы верификации могут быть разбиты на подвиды.

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

2. Поэтапные обзоры результатов.

3. Расчетный анализ.

4. Оценка безопасности компонентов.

5. Стендовые испытания на модельном прототипе или макете.

6. Проверка регулирующими органами.

7. Моделирование динамических режимов с использованием ЦД.

8. Аттестация используемого оборудования.

9. Проверка производственных операций, и др.

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

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

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

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

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

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

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

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

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

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

2. математические модели и виртуальное моделирование;

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

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

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

Для удобства фазы жизненного цикла (ЖЦ) проекта или программы разделены, что позволяет команде разработчиков поэтапно, с проведением технических обзоров, оценивать прогресс, характеристики системы и проекта, планировать следующий этап работ, облегчает принятие решений руководителям проекта. Управление ЖЦ включает контроль выполнения работ при реализации программы или проекта на последовательных фазах, разделенных контрольными рубежами (воротами принятия решений, decision gates). Для определения готовности программы или проекта к переходу на следующий этап ЖЦ на каждом КР проводят технический обзор, который включает критический разбор результатов участниками работ, планирование и реализацию корректирующих действий. На обзоре рассматривают строгие доказательства соответствия результатов проведенного этапа критериям совещания. На каждом из КР промежуточные результаты проектирования просматриваются, тестируются и оцениваются, чтобы убедиться, что проект следует по правильному пути.

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

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

1. Обзоры на КР фиксируют поставки и результаты завершенного этапа (вовлечены эксперты по компетенциям).

2. Контролируется возможное непропорциональное увеличение затрат на устранение ошибок при продвижении проекта «вниз по течению».

3. Рассматривают варианты корректировки планов, задержек на старте этапа, между фазами.

4. Формируют и документируют актуальный базовый вариант системы для управления конфигурацией.

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

6. Проводят оценку уровня зрелости развития проекта;

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

8. Оценивают соответствие проекта требованиям верхнего уровня;

9. Выполняют учет влияния технических рисков на стоимость, график и характеристики системы.

Типичные виды деятельности, выполняемые для технических обзоров:

• определение, планирование и проведение промежуточных технических обзоров;

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

• установление состава группы экспертов по рассмотрению;

• определение и реализация пунктов действий, возникающих в результате обзора.

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

• необходимые документы разработаны и разосланы для критики;

• получены комментарии экспертов на подготовленных документах;

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

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

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

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

• на все вопросы, поднятые в ходе рассмотрения, получены ответы или сформулированы записи о коррекции, если вопросы все еще открыты;

• для всех открытых вопросов представлен план решения;

• участники совета экспертов данного обзора подписали документы о выполнении требований обзора.

При прохождении контрольного рубежа имеется набор вариантов решения:

• Принято: можно переходить к следующей стадии проекта.

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

• Не принято: не переходить, дополнить работы этапа и повторить КР по готовности.

• Не принято: вернуться на предыдущую стадию.

• Не принято: заморозить (временно остановить) мероприятия проекта.

• Невосстановимо: закрыть проект.

Формальные обзоры проекта запланированы на всех ключевых этапах ЖЦ системы. Иногда в них участвуют приглашенные внешние эксперты, чтобы гарантировать, что функциональный дизайн удовлетворяет требованиям, срокам и бюджету проекта. На этапе проектирования могут потребоваться изменения ранее принятых решений из-за появления новых технологий, технических проблем или добавленных требований заинтересованных лиц. Руководитель проекта ОКР несет ответственность за мониторинг изменений, определение их воздействия на планы, графики, бюджеты проекта и процесс рассмотрения и утверждения изменений.

На рис. 1.5 показаны основные обзоры в ключевых точках проекта самолета, привязанные по срокам и фазам жизненного цикла.

Рис. 1.5. Набор основных обзоров программы по этапам ЖЦ

Типовыми обзорами этапов программы разработки, которые в первую очередь предназначены для смягчения и снижения рисков, являются обзор системных требований (SRR), анализ предварительного проекта (PDR), критический анализ проекта (CDR), анализ готовности к испытаниям (TRR), анализ эксплуатационной готовности (ORR), обзор возможностей эксплуатации (OCR), обзоры оценки жизненного цикла (LAR), а также обзор вывода из эксплуатации и утилизации (RDR).

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

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