Читать книгу Инновации от идеи до рынка - Виктор Юрьевич Николенко - Страница 12

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

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

• обеспечение планового выполнения технических работ;

• функциональную интеграцию;

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

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

• сроки и бюджет проекта;

• готовность к исполнению следующего этапа;

• контроль рисков.

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

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

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

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

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

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

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

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

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

Рис. 3. Набор обзоров программы ЖЦ самолета

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

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

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

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

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

б) планы верификации технологий завершены;

в) выявлены и оценены критические технологии для людей, продуктов и технологических решений;

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

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

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

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

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

• установлена совместимость дизайна системы с внешними интерфейсами;

• план управления рисками уточнен для следующего этапа работ;

• готовность планов производства и обслуживания;

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

• критические вехи, критерии успеха и показатели действительны для продолжения технических усилий.

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

Менеджер проекта НИОКР должен проводить регулярные текущие проверки постановки и исполнения задач в соответствии с плановыми сроками. При каждом рассмотрении исполнители должны:

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

2) обеспечить надлежащее участие в дискуссии, в том числе субподрядчиков, продавцов и поставщиков;

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

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

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