Обзор проекта (правительство США)

В интегрированном жизненном цикле закупок вооруженных сил США ^{[1] [2]} Технический раздел содержит несколько «Технических обзоров» закупок. ^[3] Технические обзоры и аудиты помогают закупкам, а их количество и типы подбираются в соответствии с закупками. ^[4] Общие указания вытекают из главы 4 Руководства по закупкам в сфере обороны ^[5] с местными подробностями, дополнительно определяемыми организациями, проводящими проверки. ^{[6] [7] [8] [9]} Типичные рассматриваемые темы включают адекватность показателей программы/контракта, надлежащее кадровое обеспечение, риски, бюджет и график.

В жизненном цикле инженерного проектирования НАСА обзоры проектов проводятся для технической и программной отчетности , а также для разрешения выделения финансирования на проект. ^[10] Обзор проекта обеспечивает углубленную оценку независимой группой экспертов и менеджеров дисциплины, подтверждающую, что проект (или концепция) является реалистичным и достижимым с программной и технической точки зрения.

Обзор проекта также требуется от разработчиков медицинских устройств как часть системы контроля проекта , описанной в регулирующих положениях Управления по контролю за продуктами и лекарствами США в 21CFR820. В 21CFR820.3(h) обзор проекта описывается как «документированное, всестороннее, систематическое изучение проекта для оценки адекватности требований к проекту, оценки способности проекта соответствовать этим требованиям и выявления проблем». FDA также указывает, что обзор проекта должен включать независимого рецензента .

Список обзоров, выполненных усилием, а также содержание, характер, процесс и цели, которые использует любой обзор, значительно различаются в зависимости от вовлеченной организации и конкретной ситуации усилия. Например, даже в Министерстве обороны США случаи обзора системных требований включают, например, (1) 5-дневное прочтение каждого отдельного требования или (2) 2-дневное обсуждение документов плана разработки, разрешенное только после утверждения системных требований и рассмотрения документов разработки с обязательными формальными пунктами действий или (3) полудневный PowerPoint с содержанием, определенным менеджером проекта, с участием, ограниченным высокоуровневыми (нетехническими) заинтересованными сторонами без какого-либо результата, кроме возможности PM заявить «SRR выполнено».

Некоторые из обзоров, которые могут быть сделаны по результатам работы, включают:

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

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

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

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

PDR демонстрирует, что предварительный проект соответствует всем системным требованиям с приемлемым риском и в рамках ограничений по стоимости и графику, а также устанавливает основу для продолжения детального проектирования. Он покажет, что были выбраны правильные варианты проектирования, были определены интерфейсы и были описаны методы проверки. ^{[11] [12]}

Ниже приведены типичные цели PDR:

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

CDR показывает, что зрелость проекта соответствует требованиям для продолжения полномасштабного изготовления, сборки, интеграции и испытаний. CDR определяет, что технические усилия идут по графику для завершения разработки полетных и наземных систем и операций миссии, удовлетворяя требованиям к производительности миссии в рамках определенных ограничений по стоимости и графику. ^[13]

Ниже приведены типичные цели CDR:

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

PRR проводится для проектов Flight System и Ground Support, разрабатывающих или приобретающих несколько или похожих систем, больше трех или как определено проектом. PRR определяет готовность разработчиков систем эффективно производить требуемое количество систем. Он гарантирует, что производственные планы; изготовление, сборка и интеграция, обеспечивающие продукты; и персонал на месте и готовы начать производство.

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

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

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

Ниже приведены типичные цели ORR:

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

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

Ниже приведены типичные цели ^{[ необходима ссылка ]} FRR:

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

• Метод критического пути
• Процесс проектирования
• Жизненный цикл разработки систем
• Техническая экспертная оценка