б) планы верификации технологий завершены;
в) выявлены и оценены критические технологии для людей, продуктов и технологических решений;
г) риски идентифицируются и количественно оцениваются, предусмотрены меры по снижению рисков;
д) был определен общесистемный подход к удовлетворению требований (включая интерфейсы) для основных системных функций.
Критический анализ проекта должен подтвердить, что детальный проект всей системы завершен, соответствует требованиям, и вся система готова к производству и кодированию. А именно:
• решены плановые вопросы по системе, функциональным областям и подсистемам;
• полностью определены требования к проектированию системы, в том числе по стоимости, графику, производительности и риску для жизненного цикла, а физическая архитектура системы представляет интегрированный детальный проект для удовлетворения требований, включая функциональную совместимость и интерфейсы;
• установлена совместимость дизайна системы с внешними интерфейсами;
• план управления рисками уточнен для следующего этапа работ;
• готовность планов производства и обслуживания;
• актуализированы планы приобретения и развертывания системы;
• критические вехи, критерии успеха и показатели действительны для продолжения технических усилий.
Изменения в конструкции, как правило, увеличивают стоимость проекта. На стадии разработки проведение изменений обычно намного дешевле, чем устранение обнаруженных проблем на этапах производства и эксплуатации. Так как стадия проектирования не может продолжаться бесконечно, руководство проекта устанавливает дату «заморозки» результатов, после которой никакие изменения конструкции системы не допускаются.
Менеджер проекта НИОКР должен проводить регулярные текущие проверки постановки и исполнения задач в соответствии с плановыми сроками. При каждом рассмотрении исполнители должны:
1) иметь возможность объяснить компромиссные решения техническими деталями и соответствующим обоснованием;
2) обеспечить надлежащее участие в дискуссии, в том числе субподрядчиков, продавцов и поставщиков;
3) предоставить отчетную информацию и элементы, необходимые для демонстрации и подтверждения того, что плановые вехи, связанные с проверкой, были достигнуты;
4) документировать ход разбирательства, включая ключевые моменты, решения и вопросы с соответствующим обоснованием; открытые и нерешенные вопросы с их требованиями по закрытию и указанием ответственных лиц.
Исполнители должны проводить обзоры подсистем, чтобы гарантировать, что требования, включая требования к интерфейсу (глава 3.6), для подсистем определены, сбалансированы по сегментам и интерфейсам, задокументированы и выполнены. Эти обзоры должны подтвердить решение проблем и оценить прогресс разработки каждой подсистемы в контексте жизненного цикла. Анализ подсистемы должен учитывать воздействие на другие элементы системы, а также взаимодействие с ними, документацию, риски и, если применимо, готовность к верификации и документацию. Как правило, проверка подсистемы должна подтвердить, что при рассмотрении требований к подсистеме требования, выделенные для КЭ, полны и включены в спецификацию, соответствующая документация по управлению интерфейсом установлена, требования, выделенные для КЭ, являются реализуемыми, разработаны необходимые спецификации процессов и материалов.
Вы ознакомились с фрагментом книги.
Приобретайте полный текст книги у нашего партнера: