ГОСТ Р 58607-2019 Системная и программная инженерия. Управление жизненным циклом. Часть 4. Планирование системной инженерии

ГОСТ Р 58607-2019/ISO/IEC/IEEE 24748-4:2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системная и программная инженерия

УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ

Часть 4

Планирование системной инженерии

Systems and software engineering. Life cycle management. Part 4. Systems engineering planning

ОКС 35.080

Дата введения 2021-01-01

Предисловие

1 ПОДГОТОВЛЕН Акционерным обществом "Всероссийский научно-исследовательский институт сертификации" (АО "ВНИИС") и Обществом с ограниченной ответственностью "Информационно-аналитический вычислительный центр" (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 "Информационные технологии"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2019 г. N 1029-ст

4 Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 24748-4:2016* "Системная и программная инженерия. Управление жизненным циклом. Часть 4. Планирование системной инженерии" (ISO/IEC/IEEE 24748-4:2016 "Systems and software engineering - Life cycle management - Part 4: Systems engineering planning", IDT).

________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

ISO/IEC/IEEE 24748-4 разработан подкомитетом ПК 7 "Системная и программная инженерия" Совместного технического комитета СТК 1 "Информационные технологии" Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК) в сотрудничестве с Комитетом по стандартизации программных продуктов и систем Информационного общества IEEE в рамках соглашения о сотрудничестве в области развития партнерских стандартов между ISO и IEEE.

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

ISO/IEC/IEEE 15288 представляет общие основы процесса, охватывающего жизненный цикл искусственных систем. Представленный жизненный цикл содержит концепцию идей вплоть до выведения системы из эксплуатации. Он обеспечивает процессы приобретения и поставки систем. Дополнительно общие основы процесса предусматривают оценку и совершенствование процессов жизненного цикла. Эти основы улучшают связь и взаимодействие между сторонами, которые создают, применяют и управляют современными системами для их комплексной и согласованной работы.

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

ISO/IEC/IEEE 24748-4 заменяет ИСО/МЭК 26702:2007 (IEEE 1220:2005). При подготовке к гармонизации в ИСО/МЭК 26702 предоставлены разъяснения основных отличий между стандартами IEEE 1220 и ISO/IEC/IEEE 15288 в таких областях, как терминология и структура.

Развитие гармонизированного множества стандартов, связанных с ISO/IEC/IEEE 15288, и технических отчетов в настоящем стандарте обеспечивает подробные требования и руководящие указания по применению процессов жизненного цикла систем. Настоящий стандарт объединяет технические требования, требования по управлению и рекомендации по использованию нескольких источников для определения требований ПУПРСИ и обеспечению общего формата ПУПРСИ. Настоящий стандарт также определяет процессы ISO/IEC/IEEE 15288 для выполнения необходимых действий по планированию проекта для осуществления технических усилий и разработки ПУПРСИ. В связи с точным соответствием содержанию ИСО/МЭК 24748, ИСО/МЭК 26702 стал частью 4 стандартов серии ИСО/МЭК 24748.

Наряду с использованием ISO/IEC/IEEE 15288 и ИСО/МЭК 12207, которые можно использовать со смежными стандартами, например, по управлению услугами, и другими стандартами по процессам более низкого уровня, ИСО/МЭК 24748 предназначен для упрощения процедуры совместного использования стандартов. Таким образом, ИСО/МЭК 24748 предоставляет наиболее полное и унифицированное руководство по управлению жизненным циклом систем и программных средств. Его цель - помочь обеспечить согласованность замыслов системы и концепций жизненного цикла, моделей, стадий, процессов, применения процессов, основных точек зрения, адаптации и использования в различных областях, поскольку два международных стандарта (а также и другие) используются в комбинации. Это должно помочь в разработке модели жизненного цикла для управления ходом выполнения проекта.

ИСО/МЭК 24748 включает в себя пять частей:

- ISO/IEC TR 24748-1 "Системная и программная инженерия. Управление жизненным циклом. Часть 1. Руководство для управления жизненным циклом";

- ISO/IEC TR 24748-2 "Системная и программная инженерия. Управление жизненным циклом. Часть 2. Руководство по применению ИСО/МЭК 15288 (Процессы жизненного цикла систем)";

- ISO/IEC TR 24748-3 "Системное проектирование и разработка программного обеспечения. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств)";

- ISO/IEC/IEEE 24748-4 "Системная и программная инженерия. Управление жизненным циклом. Часть 4. Планирование системной инженерии";

- ISO/IEC/IEEE 24748-5 "Системное проектирование и разработка программного обеспечения. Управление жизненным циклом. Часть 5. Планирование разработки программных средств".

Принимая во внимание, что в ИСО/МЭК 24748-1 в общих чертах рассматривается вышеизложенная цель руководства по управлению жизненным циклом систем и программными средствами, часть 2 фокусируется и расширяет охват этих аспектов для систем. ИСО/МЭК 24748-2 в сочетании с ИСО/МЭК 24748-1 будет также способствовать определению и планированию использования процессов жизненного цикла, описанных в ISO/IEC/IEEE 15288. Соответствующее использование этих процессов будет способствовать тому, что проект будет успешно завершаться, достигая свои цели и выполняя требования для каждой стадии и для проекта в целом.

Настоящий стандарт посвящен процессам, необходимым для успешного планирования и управления системной инженерия проекта. Это приводит к разработке ПУПРСИ как основного средства планирования для применения процессов жизненного цикла систем проекта. ПУПРСИ является техническим документом высокого уровня по планированию проекта, связанного с управлением техническими процессами, устанавливаемыми с помощью трех источников (контракта или соглашения по проекту, применяемых организационных процессов и проектной команды системной инженерии) для успешного решения задач системной инженерии. В настоящем стандарте используются термины "техническое планирование" и "планирование системной инженерии", чтобы подчеркнуть или дифференцировать их технический вклад в процессы. Настоящий стандарт использует основные аспекты ИСО/МЭК 26702 (IEEE 1220) для выделения дополнительных методов и обеспечения нормативного содержания для ПУПРСИ.

1 Область применения

Настоящий стандарт:

- определяет необходимые процессы технического управления ISO/IEC/IEEE 15288 для планирования системной инженерии;

- дает рекомендации по применению необходимых процессов;

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

- представляет руководящие указания для определения формата и содержания информационного объекта;

- предоставляет нормативное определение содержания информационного объекта, который появляется в результате выполнения процессов до их завершения. В настоящем стандарте план для технического управления проектом называется планом системной инженерии (ПУПРСИ).

Настоящий стандарт применим к использованию:

- лицами, использующими или планирующими использовать ISO/IEC/IEEE 15288 в проектах, связанных с искусственными системами, включая программно-ориентированные системы, программные продукты и услуги, связанные с этими системами и продуктами;

- лицами, несущими ответственность за техническое управление проектами, связанными с системной инженерией;

- лицами, ответственными за осуществление процессов систем жизненного цикла ISO/IEC/IEEE 15288 на уровне проекта;

- организациями и лицами, предпринимающими субподрядные усилия по управлению проектами;

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

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

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

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

2 Соответствие

2.1 Возможное использование

Настоящий стандарт описывает руководящие указания по выполнению процессов ISO/IEC/IEEE 15288, требующих существенных усилий для планирования и управления проектом в области системной инженерии. Настоящий стандарт также предоставляет нормативное определение содержания и рекомендаций для формата элемента соответствующего информационного объекта, ПУПРСИ проекта.

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

В разделах 7 и 9, подразделе 6.1 и приложении C настоящего стандарта приведены требования настоящего стандарта.

2.2 Соответствие процессам

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

Требования для этих процессов приведены в 6.1.

Если пользователь настоящего стандарта следует полному соответствию требованиям ISO/IEC/IEEE 15288:2015, то косвенно пользователь может ожидать соответствия требованиям к процессам настоящего стандарта.

Примечание - Декларация о приспособленном соответствии в ISO/IEC/IEEE 15288:2015 не обязательно включает в себя соответствие процессам настоящего стандарта.

2.3 Соответствие содержанию информационного объекта

Настоящий стандарт представляет требования для информационного объекта ПУПРСИ.

Декларация о соответствии содержания информационного объекта настоящего стандарта означает следующее:

- пользователь создает требуемый информационный объект, указанный в настоящем стандарте;

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

Требования к соответствию информационного объекта настоящего стандарта указаны в разделе 7.

Требования к соответствию содержания информационного объекта в настоящем стандарте описаны в разделе 9.

Примечания

1 Если пользователь настоящего стандарта следует полному соответствию ISO/IEC/IEEE 15289, это не означает, что пользователь требует соответствие информационному объекту и содержанию информационного объекта в соответствии с настоящим стандартом. Причиной служит то, что в настоящем стандарте описаны дополнительные информационные объекты и дополнительные подробности.

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

2.4 Полное соответствие

Декларация о полном соответствии настоящего стандарта эквивалентна декларации соответствия следующему:

- процессам ISO/IEC/IEEE 15288 из подраздела 6.1;

- информационному объекту из раздела 7;

- содержанию информационного объекта из раздела 9.

2.5 Приспособленное соответствие

Декларация о приспособленном соответствии настоящего стандарта приравнивается к декларации соответствия положениям, указанных в обязательном приложении C.

3 Нормативные ссылки

В настоящем стандарте использованы следующие нормативные ссылки. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).

ISO/IEC/IEEE 15288:2015, Systems and software engineering - System life cycle processes (Системная и программная инженерия. Процессы жизненного цикла системы)

4 Термины и определения

В настоящем стандарте применены термины по ISO/IEC/IEEE 15288:2015.

Примечания

1 ISO/IEC TR 24748-1 описывает руководящие указания по применению ISO/IEC/IEEE 15288, включая определение или развитие важной организации, проекта, процесса, и понятий моделей жизненного цикла и их приспособления для успешной реализации проекта. ISO/IEC TR 24748-1 является общедоступным техническим отчетом; ИСО - Стандарты в свободном доступе: http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html.

2 ISO/IEC TR 24748-1 ссылается и использует термины и определения по ISO/IEC/IEEE 15288.

4.1

________________

Заменен на ISO/IEC/IEEE 15289:2017.

4.2

4.3

4.4

4.5

4.6

4.7

________________

Заменен на ISO/IEC/IEEE 24748-2:2018.

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

Примечание - Показатель функционирования обычно характеризует физические или функциональные атрибуты, касающиеся функционирования системы.

4.9

4.10

4.11

4.12 структура разделения системы (system breakdown structure): Системная иерархия с определенными обеспечивающими системами и персоналом, которая обычно используется для назначения команды разработчиков, поддержания технических анализов, разделения порученной работы и распределения ресурсов на все задачи, необходимые для выполнения технических задач проекта.

Примечание - Структуру разделения работ можно использовать как основание для контроля и отслеживания затрат.

4.13

4.14

4.15

________________

Заменен на ISO/IEC/IEEE 29148:2018.

4.16

5 Общие определения

5.1 Введение

В этом разделе перечислены понятия, необходимые для понимания аспектов планирования системной инженерии проекта, разработки и содержания планов системной инженерии проекта.

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

В соответствии с информацией настоящего стандарта существует несколько стандартов, детально описывающих требования и руководящие указания по использованию ISO/IEC/IEEE 15288. Некоторые из этих стандартов расширяют требования ISO/IEC/IEEE 15288 для поддержания его применения и реализации в организациях и проектах. В их содержание входят соответствующие требования и руководящие указания по разработке действий и задач систем поддержки планирования системной инженерии, по разработке ПУПРСИ проекта или по шаблонам ПУПРСИ для использования в организации.

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

Выполнение работ по планированию системной инженерии для управления техническими аспектами проекта и для разработки ПУПРСИ предполагает восприятие нескольких ключевых понятий. К ним относятся такие понятия, как: система, жизненный цикл, процесс, организация, проект, информационный объект и разработка ПУПРСИ. Основополагающий материал, объясняющий эти понятия, приведен или определен в подразделах 5.2-5.7.

5.2 Системные понятия

Системные понятия для систем, которые представляют собой комбинацию продуктов и услуг, включены в подраздел 5.2 ISO/IEC/IEEE 15288. Дополнительное описание приведено в подразделе 3.1 ISO/IEC TR 24748-1, который объясняет понятия систем, системных границ, структуры в системах и проектах.

5.3 Понятия жизненного цикла

Системные понятия жизненного цикла приведены в подразделе 5.4 ISO/IEC/IEEE 15288. Дополнительные положения описаны в подразделе 3.2 ISO/IEC TR 24748-1.

Понятия жизненного цикла проекта и применение описаны в ISO/IEC/IEEE 16326.

"Руководящие указания по системной инженерии" Международного совета по системной инженерии (INCOSE) описывает системные понятия жизненного цикла с точки зрения бизнеса, бюджета, технических аспектов и проектных циклов в терминах прохождения решений. Описания различных методов, стратегии реализации и конкретные примеры разъясняют некоторые решения, стоящие перед организациями и проектами при определении соответствующих моделей систем и жизненного цикла для их применения.

5.4 Понятия процесса

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

Понятия процесса вводятся в подразделе 5.5 ISO/IEC/IEEE 15288. Дополнительное описание для применения приведено в подразделе 3.3 в ISO/IEC TR 24748-1 и в подразделе 4.4 ISO/IEC TR 24748-2.

ISO/IEC/IEEE 15288 устанавливает архитектуру верхнего уровня жизненного цикла систем, начиная с замысла до выведения из эксплуатации. Архитектура разрабатывается с множеством процессов и взаимосвязей этих процессов.

Принципы процесса описаны в пункте 4.4.2 ISO/IEC TR 24748-2.

Категории процесса ISO/IEC/IEEE 15288 описаны в пункте 4.4.3 ISO/IEC TR 24748-2.

Рекурсивное и итеративное применения процессов описаны в пункте 4.4.4 ISO/IEC TR 24748-2.

5.5 Организационные понятия

В разделе 4 приведено определение организации в соответствии с ISO/IEC/IEEE 15288. Определенная часть организации (даже такая небольшая, как один человек) или определенная группа организаций могут рассматриваться как организация, если она имеет ответственность, полномочия и определенные отношения. Согласно ISO/IEC/IEEE 15288, если организация полностью или частично заключает соглашение, она становится одной из сторон. Организации представляют собой самостоятельные органы, но стороны могут быть как от одной организации, так и от нескольких отдельных организаций.

Концепции организации, такие как ответственность, организационные отношения и организационная структура проекта рассмотрены в подразделе 4.5 ISO/IEC TR 24748-2.

5.6 Понятия проекта

В разделе 4 приведено понятие проекта на основе адаптированного определения ISO/IEC/IEEE 15288.

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

Пункт 3.1.4 ISO/IEC TR 24748-1 описывает структуру системы и значение в проектах.

Пункт 3.1.5 ISO/IEC TR 24748-1 описывает вспомогательные системы с точки зрения интересующей системы и ее операционной среды.

Подраздел 4.6 ISO/IEC TR 24748-2 описывает понятия проекта, связи между проектами, связи проекта с обеспечивающими системами и иерархию проектов.

Руководство IEEE 1490 предоставляет больше информации о проектах и управлении проектами.

ISO/IEC/IEEE 16326 предоставляет больше информации об управлении проектами, информационном объекте, плане управления проектом (ПУПРП).

5.7 Понятия информационного объекта

В разделе 4 приведены определения информационного объекта и связанных с ним терминов, принятых на основе определений ISO/IEC/IEEE 15289.

ISO/IEC/IEEE 15289 подробно описывает информационные объекты (информационные элементы) и определяет, как данные жизненного цикла управляются на уровне информационных объектов.

Подраздел 6.1 ISO/IEC/IEEE 15289 содержит требования к характеристикам данных жизненного цикла информационных объектов, выпускаемых в виде документов.

ISO/IEC/IEEE 15289 показывает, что информационный объект должен соответствовать универсальному типу информационного объекта. Основной информационный объект, указанный в настоящем стандарте, является типовым планом.

Раздел 7 ISO/IEC/IEEE 15289 определяет несколько общих типов информационных объектов и описывает общее содержание для каждого типа информационного объекта.

Подраздел 7.3 ISO/IEC/IEEE 15289 описывает общее содержание элементов для плана.

ISO/IEC/IEEE 15289 приводит различия между записями и документами (которые включают план). Каждый информационный объект, созданный в виде документа, поддерживает определенные характеристики данных жизненного цикла. Документы готовятся и передаются для использования человеком и содержат формальные элементы (такие как цель, область применения и краткое изложение), предназначенные для использования их по назначению.

Подраздел 6.4 ISO/IEC/IEEE 15289 описывает требования для управления информационными объектами посредством применения процессов ISO/IEC/IEEE 15288 и ИСО/МЭК 12207. Сюда включен процесс управления информацией и выбор действий из процесса управления знаниями.

5.8 Понятия разработки плана управления системной инженерией (ПУПРСИ)

ПУПРСИ предоставляет собой план реализации выбранных процессов жизненного цикла системы в течение всего жизненного цикла проекта. ПУПРСИ должен разрабатываться с самых ранних стадий планирования проекта. Это тесно связано с развитием и содержанием ПУПРП. Местами комбинируемый, ПУПРСИ, как правило, является подчиненным документом плана управления проектом и фокусируется на технических аспектах управления проектом.

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

ПУПРСИ является основным техническим планом управления, который объединяет усилия системной инженерии. Следующая выдержка из таблицы А.8 ISO/IEC TR 24748-2 по замечаниям по планированию процесса описывает инженерный план (упомянут в настоящем стандарте как ПУПРСИ):

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

ISO/IEC/IEEE 16326 дополняет процессы технического управления ISO/IEC/IEEE 15288 с помощью подробных руководящих указаний и нормативных содержательных требований, охватывая проекты программного продукта и проекты программно-ориентированных систем. ISO/IEC/IEEE 16326 отмечает, что, как правило, чтобы адресовать и собрать необходимые планы для соответствия требованиям продукции и условиям соглашения, ПУПРСИ разрабатывается на более низком уровне абстракции, чем ПУПРП (например, специализированные планы безопасности, защищенности, обучения, интеграции, передачи). Технические планы, такие как ПУПРСИ (также его обычно называют техническим планом управления или инженерным планом) должны скоординировать технические аспекты и управленческие аспекты проекта (или нескольких проектов) по одной или нескольким организациям для обеспечения успешного достижения организационных и договорных целей для проекта. ПУПРСИ обычно завершает или дополняет элементы плана, инициируемые на уровне плана управления проектом. Организационные процессы, условия соглашений и уникальные требования проекта способствуют определению ПУПРП и содержанию ПУПРСИ, а также их взаимодействию.

Справочное приложение A содержит требования содержания ISO/IEC/IEEE 16326 для основных элементов ПУПРП. Настоящий стандарт также описывает отношения требуемого содержания ПУПРСИ, приведенного в разделе 9, с информативным описанием элементов ПУПРП.

Раздел 8 содержит руководящие указания по разработке ПУПРСИ.

6 Процессы технического управления для планирования системной инженерии

6.1 Общие положения

Для планирования технических усилий и разработки ПУПРСИ проекта, проект должен реализовать процессы, определенные ISO/IEC/IEEE 15288 и перечисленные в таблице 1:

Таблица 1 - Процессы технического управления ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 16326

Соответствующие процессы, действия и задачи описаны в вышеупомянутых пунктах ISO/IEC/IEEE 15288. Описания процессов с результатами и руководящие указаниям для планирования управления проектами и разработки планов управления проектом описаны в вышеупомянутых подразделах ISO/IEC/IEEE 16326. Описания процессов с результатами и дополнительным руководящие указаниям для технического планирования и разработки ПУПРСИ проекта рассматриваются в настоящем стандарте.

Раздел 6 рассматривает восемь процессов технического управления ISO/IEC/IEEE 15288, в которых подробно обсуждаются и даются рекомендации по применению при управлении проектами, связанными с системами. Руководящие указания в разделе 8 и в Приложении B поддерживают анализ, выбор и адаптацию процессов ISO/IEC/IEEE 15288 в целях наполнения модели жизненного цикла для применения в проекте (модель предназначена для этапа жизненного цикла системы или этапа в рамках проекта). Эти скомбинированные руководящие указания предназначены для оказания помощи специалистам по проекту и техническому планированию в подготовке необходимых материалов по техническому планированию в соответствии с разделом 9, и их распределении по ПУПРСИ или по другим планам проекта, например, по ПУПРП.

Части нормативного процесса из ISO/IEC/IEEE 15288 содержатся в тексте в рамке с последующим нижеприведенным описанием и рекомендациями.

ISO/IEC/IEEE 16326 разъясняет эти процессы с точки зрения того, что руководитель проекта должен сделать для разработки плана проекта. ПУПРСИ является специализацией одного из таких планов, которая фокусируется на технических аспектах управления проектом для успешного управления и предоставления системных продуктов и услуг проекта. Несмотря на то, что многие обязанности и виды деятельности по планированию проектов и техническому планированию или планированию системной инженерии одинаковы, область применения и направленность могут существенно различаться - в зависимости от сложности проекта и организационных влияний.

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

Если проект и его системные продукты и услуги требуют отдельных планов управления проектами и технического управления, такие как создание ПУПРСИ, решения должны быть приняты в начале жизненного цикла проекта в отношении определения области применения и распределения обязанностей персонала и планов проекта. Между проектным и техническим менеджментом должна быть прямая содержательная связь. Это помогает обеспечить, чтобы основные технические заинтересованные стороны были определены с запланированными действиями и вовлечены в исполнение согласно планам.

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

________________

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

6.2 Процесс планирования проекта

Руководящие указания:

a) Следует назначить ответственных за подготовку, рассмотрение и утверждение планов, включая технические планы управления. Все документируется.

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

- вовлечение всех заинтересованных сторон в определение требований и действия по их выполнению;

- установку стратегии верификации на ранней стадии и осуществление верификации по мере изменений требований;

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

- анализ выбора процессов при изменении области применения и требований для подтверждения применимости выбранных процессов после этих изменений;

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

- установку и сопровождение требований.

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

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

e) Для поддержки области применения проекта системная инженерия обычно определяет иерархию для рассматриваемой системы и устанавливает соответствующую структуру разделения системы.

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

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

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

i) В ИСО 10006 предоставлены руководящие указания менеджерам проектов для помощи в обеспечении надлежащего качества продукции и услуг в рамках проекта.

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

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

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

l) У проекта должен быть один генеральный план. Следует объединить вспомогательные планы и согласовать с генеральным планом. Такой план обычно называют комплексный генеральный план.

m) У проекта должен быть один сводный график работ. Следует объединить вспомогательные графики и согласовывать их со сводным графиком работ. Такой график обычно называют комплексный сводный график. Часто используют технические графики для контроля усилий системной инженерии и команд.

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

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

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

q) Следует регулярно пересматривать и обновлять технические планы (т.е. ПУПРСИ и его вспомогательные планы), чтобы согласовывать их с другими планами проекта, например, планом управления проектом. Следует оценивать прослеживаемость основных разделов технических планов, т.е. техническое задание, ПУПРП, ПУПРСИ, комплексный генеральный план и комплексный сводный график. Необходимое содержание ПУПРСИ проекта описано в 9.

Примечание - См. 5.8 для дополнительных указаний по обновлению технических планов.

r) ПУПРСИ и вспомогательные планы следует поместить под управление конфигурацией в соответствии со стратегией управления информацией, определенной для проектной документации.

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

t) Если вспомогательные процессы осуществляются сторонними организациями и не подчиняются контролю руководителя проекта, важно реализовать сосуществование двух множеств отношений между:

- руководителем проекта и управлением обеспечивающих процессов;

- обеспечиваемым и обеспечивающим организационным управлением.

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

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

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

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

x) В планирование проекта следует включать планирование на случай непредвиденных обстоятельств для решения как управленческих, так и технических проблем.

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

6.3 Процесс оценки и контроля проекта

Руководящие указания:

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

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

c) Оценка системной инженерии и задачи контроля должны включать в себя:

- оценку результатов анализа продукции, действий и задач;

- соответствие между проектом и техническими планами управления, философией, методологией и технологиями;

- документацию и сопровождение технических планов и обязательств;

- удовлетворение требованиям;

- оценку готовности к продвижению к следующему процессу, действию или задаче.

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

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

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

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

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

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

j) В рамках проектного и технического управления следует осуществлять определение, документирование и управление взаимозависимостями между процессами проекта.

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

l) Следует тщательно оценить восстановление после отклонения от графика и оценить возможные отрицательные последствия на выполнение, стоимость, риск или качество проекта.

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

n) Руководству следует уточнить и усовершенствовать методы определения продвижения проекта с тем, чтобы обеспечить раннее выявление перерасход средств или нарушения графика.

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

6.4 Процесс управления решением

Руководящие указания:

a) В стратегию принятия решений следует включать определение лиц, принимающих решения, и их полномочия, категории решений и расстановку приоритетов. Стратегии решения могут включать в себя:

1) варианты реализации требований к функциональности продукта;

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

3) критерии входа и выхода для этапов жизненного цикла;

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

5) принятие решения или решение о закупке компонентов продукции или системы;

6) вопросы, влияющие на бизнес-цели организации;

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

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

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

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

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

f) В целях выявления и устранения непредвиденных последствий реализации следует осуществлять мониторинг выполнения рекомендаций по принятому решению.

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

6.5 Процесс управления рисками

Руководящие указания:

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

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

c) При планировании проектных и технических рисков следует определять анализы, необходимые для поддержки действий по управлению рисками. Анализы следует планировать так, чтобы обеспечить своевременное смягчение последствий и планирование на случай непредвиденных обстоятельств. В разделе 9 рассмотрены несколько типов анализов усилий по системной инженерии, которые применимы для поддержки управления рисками. Следует предусмотреть документирование в ПУПРСИ проекта.

Примечание - ИСО/МЭК 16085 (IEEE 16085) определяет процесс управления рисками в жизненном цикле.

6.6 Процесс управления конфигурацией

Руководящие указания:

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

b) Критерии идентификации конфигурации следует четко определить и задокументировать. Управление конфигурацией применяется к объектам конфигурации в соответствии с критериями идентификации конфигурации и стратегией процесса.

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

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

Примечание - IEEE 828, ANSI/EIA 649-B и ИСО 10007 - это стандарты детального уровня, поддерживающие планирование управления конфигурацией и выполнение.

6.7 Процесс управления информацией

Руководящие указания:

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

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

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

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

e) Если информация, предоставляемая заинтересованными сторонами или полученная во время выполнения технических усилий, является классифицируемой, в процесс управления информацией проекта следует включать необходимую защиту информации как во время хранения, так и во время использования. Следует также удостовериться, что информация доступна только для тех сотрудников проекта и заинтересованных сторон, которые имеют необходимые, документально утвержденный доступ к информации. Для записи истории доступа могут быть реализованы журналы доступа. Режим информационной безопасности регулируется законами и правилами и может быть предметом соблюдения условий договора. Аспекты информационной безопасности проекта обычно определяются на организационном уровне с учетом того, что процессы и процедуры безопасности организационные уровня будут использоваться. Управление проектом и управление системной инженерией следует документировать, и для своевременной реализации проекта необходима специальная информационная безопасность.

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

6.8 Процесс измерений

Руководящие указания:

a) Измерение поддерживает управление и улучшение процессов и продукции. Измерение - это основной инструмент для управления действиями жизненного цикла системы и программных средств путем оценки реализуемости планов проекта и контроля за соблюдением действий в соответствии с этими планами. Измерение системы и программных средств также является основной дисциплиной в оценке качества продукции и возможностей организационных процессов.

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

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

Пункты 9.8.1, 9.8.2, 9.8.8, 9.9.1 и 9.9.3 описывают необходимые и рекомендуемое содержание для ПУПРСИ в части измерений.

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

6.9 Процесс гарантии качества

Руководящие указания:

a) Процесс гарантии качества помогает обеспечивать утвержденные организационные политики процесса управления качеством; процедуры и требования реализуются в проектах с помощью проектных команд. Приобретающая сторона или заказчик могут также обсудить специфические положения управления качеством для вставки проекта в договор с поставщиком. Действия по процессу гарантии качества проекта иногда документируется в отдельный план по гарантиям качества или в ПУПРП. Виды деятельности, интегрированные с техническими усилиями, следует задокументировать или дать на них ссылку в ПУПРСИ.

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

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

7 Информационные объекты

В проекте должен быть разработан следующий информационный объект - план управления системной инженерией (ПУПРСИ). Содержание информационного объекта определено в разделе 9.

Примечание - Положения в разделе 9 касаются общих элементов содержания типового плана, как это описано в ISO/IEC/IEEE 15289.

Управление информационным объектом осуществляется с применением процесса управления информацией по ISO/IEC/IEEE 15288. Стратегию управления информацией проекта следует согласовать со стратегией управления знаниями для обеспечения любых организационных требований к ресурсам знаний.

Примечание - В ISO/IEC/IEEE 15289 предоставлено больше информации об описании информационного объекта и управлении информационными объектами и документами, как это определено в подразделе 5.7 этой части ISO/IEC/IEEE 24748.

8 Руководящие указания по информационным объектам

8.1 Введение

Раздел 8 предоставляет организации руководящие указания и общий формат ПУПРСИ для поддержания его необходимого содержания, как это определено в разделе 9. Как правило, проект устанавливает определенный проектно-ориентированный план инженерии, который определяет применимые данные для каждой системной стадии жизненного цикла в пределах проекта и использует его для введения в действия системной инженерии. Проектно-ориентированный план инженерии должен быть совместим с планами управления проектом, организационными планами, возможностями и ограничениями, ожиданиями заказчика.

Так как у каждого проекта могут быть свои уникальные размерности жизненного цикла, пределы допустимого риска и потребности в данных, ПУПРСИ следует адаптировать для каждого применения.

Примечание - ISO/IEC/IEEE 15289 дает представление об определении и планировании конкретных информационных объектов, производимых в жизненном цикле систем и программных средств.

Этот раздел уточняет потребности действий по планированию проекта для разработки ПУПРСИ.

Помимо требований процесса и руководящих указаний, приведенных в ISO/IEC/IEEE 15288 и ISO/IEC/IEEE 16326, в ISO/IEC TR 24748-1, ISO/IEC TR 24748-2 и других стандартах, упоминаемых в данном разделе, рассматриваются дополнительные подробные руководящие указания, поддерживающие планирование проекта и адаптацию ISO/IEC/IEEE 15288 для разработки ПУПРСИ.

Большая часть основополагающих действий по адаптации ISO/IEC/IEEE 15288 для развития организационных процессов или создания ПУПРП проекта должна быть осуществлена прежде или может происходить параллельно с разработкой ПУПРСИ. Поскольку выполнение этих задач способствует успешной разработке ПУПРСИ, они выделены в этом разделе со ссылками на стандарты, которые содержат подробные описания для их реализации.

ISO/IEC TR 24748-1 и ISO/IEC TR 24748-2 обеспечивают детальные руководящие указания для применения ISO/IEC/IEEE 15288 на высоком уровне, включая определение или расширение важных понятий организации, проекта, процесса, модели жизненного цикла и их адаптацию для успешной реализации проекта. ISO/IEC TR 24748-1 и ISO/IEC TR 24748-2 также определяют планы и анализы, обычно используемые по жизненному циклу систем. ISO/IEC TR 24748-2 содержит руководящие указания по применению ISO/IEC/IEEE 15288 с точки зрения стратегии, планирования, применения в организациях и в проектах. Приложение А ISO/IEC TR 24748-2 содержит информационные нотации для применения каждого из процессов ISO/IEC/IEEE 15288, в то время как подраздел А.4 ISO/IEC TR 24748-2 содержит конкретные нотации для применения процесса планирования проекта, включая перечень информационного содержания плана инженерии.

ISO/IEC/IEEE 16326 предоставляет спецификации нормативного содержания для планов управления проектами, охватывающих проекты программных средств, и проектов программно-ориентированных систем. Этот стандарт также включает в себя подробные описания и советы по применению процессов технического управления ISO/IEC/IEEE 15288 для оказания помощи в подготовке нормативного содержания планов управления проектами.

ISO/IEC/IEEE 29148 содержит руководящие указания для выполнения процессов ISO/IEC/IEEE 15288 (и ИСО/МЭК 12207), связанных с разработкой требований. ISO/IEC/IEEE 29148 определяет необходимые информационные объекты для их создания в поддержку требований процессов инженерии и предоставляет определение нормативного содержания и рекомендации по формату получаемой документации или информационной продукции. ISO/IEC/IEEE 29148 также описывает анализы, аудиты, базовые линии, измерения и другие механизмы управления требованиями по мере их возникновения.

ISO/IEC/IEEE 42010 предоставляет руководящие указания по выполнению процессов ISO/IEC/IEEE 15288, которые касаются архитектуры и проектирования. ISO/IEC/IEEE 42010 рассматривает создание, анализ и поддержание архитектуры систем с использованием описаний архитектуры. ISO/IEC/IEEE 42010 предоставляет понятия, руководящие указания и необходимое содержимое для точек зрения на архитектуру, структуру и языки описания, которое может быть использовано для поддержки архитектурного определения систем.

ISO/IEC/IEEE 15939 определяет процесс измерения, применимый к системной и программной инженерии и дисциплинам управления. Стандарт определяет действия и задачи, необходимые для успешного выявления, определения, выбора, применения и улучшения измерений в рамках общего проекта или организационной структуры измерений.

ИСО/МЭК 16085 (IEEE 16085) определяет требования и руководящие указания в непрерывном процессе систематического управления рисками на протяжении всего жизненного цикла продукции или услуг.

8.2 Адаптация ISO/IEC/IEEE 15288

Основываясь на ранее описанных понятиях в разделе 5, ISO/IEC TR 24748-1 объясняет, как применять ISO/IEC/IEEE 15288 (и ИСО/МЭК 12207) для создания моделей жизненного цикла, применимых для организации и реализации проекта. Раздел 6 ISO/IEC TR 24748-1 проводит различие между процессами приспособления и адаптации. В разделе отмечается, что приспособление является лишь одним из пяти механизмов адаптации процессов ISO/IEC/IEEE 15288 (и ИСО/МЭК 12207). Приспосабливание процессов согласно ISO/IEC/IEEE 15288 может включать в себя удаление отобранных выходных результатов, действий или задач, где адаптация также влечет за собой выбор процесса, замену процесса (процессы ISO/IEC/IEEE 15288 для процессов ИСО/МЭК 12207 объявлены как "специализации" в ISO/IEC/IEEE 15288), использование выходных результатов или использование примечаний для повышения адекватности модели жизненного цикла.

ISO/IEC TR 24748-1 также описывает шесть шагов в этой последовательности адаптации и дает дополнительные указания для их выполнения. Шаги включают в себя следующее:

a) шаг 1 - определите среду и характеристики проекта;

b) шаг 2 - запросите информацию;

c) шаг 3 - выберите соответствующие стандарты;

d) шаг 4 - выберите модель жизненного цикла;

e) шаг 5 - выберите этапы и процессы;

f) шаг 6 - документируйте решения по адаптации и их обоснования.

Раздел 5 ISO/IEC TR 24748-2 ссылается и расширяет руководящие указания ISO/IEC TR 24748-2-1 для применения ISO/IEC/IEEE 15288. Это обеспечивает подробное описание прикладной стратегии, состоящей из пяти шагов, включающих в себя следующее:

a) шаг 1 - планируйте применение;

b) шаг 2 - адаптируете ISO/IEC/IEEE 15288;

c) шаг 3 - проведите пилотный проект (проекты);

d) шаг 4 - формализуйте подход;

e) шаг 5 - узаконьте подход.

Подраздел 5.3 ISO/IEC TR 24748-2 продолжает объяснение применения ISO/IEC/IEEE 15288 в организациях и вместе с подразделом 5.4 описывает применение более подробной информации по проектам. Подразделы, описывающие применение проекта, предоставляют дополнительные разъяснения о каждом процессе соглашения и техническом процессе в ISO/IEC/IEEE 15288. ISO/IEC/IEEE 16326 содержит дополнительные советы по применению процессов технического управления ISO/IEC/IEEE 15288.

Пункт 5.4.4 ISO/IEC TR 24748-2 описывает процесс применения моделей жизненного цикла и определяет организационное и инженерное представление жизненного цикла системы. Организационное представление включают в себя общее описание, типы систем, риски и возможности для различных подходов к жизненному циклу, включая каскадный, инкрементный и эволюционный. Инженерное представление описывает инженерию через жизненный цикл и применение инженерии V-модели на различных уровнях структуры системы на каждой стадии. Этот раздел также описывает два типа аудитов конфигурации и определяет общие технические анализы (например, концепции, базовой линии, проекта, испытаний) для скоординированного использования в соответствии с инженерными представлениями.

Приложение А ISO/IEC TR 24748-2 содержит примечания, которые призваны помочь в использовании действий и задач процесса ISO/IEC/IEEE 15288 для реализации выходных результатов каждого процесса. На эти примечания делаются перекрестные ссылки на соответствующие разделы ISO/IEC/IEEE 15288. В дополнение, таблица А.8 ISO/IEC TR 24748-2 содержит примечания по применению процесса планирования проекта, включая перечень содержания плана инженерии (также известного как ПУПРСИ).

При выполнении состоящей из шести шагов стратегии адаптации модели жизненного цикла, описанной ISO/IEC TR 24748-1, важно отметить расширенные руководящие указания от ISO/IEC TR 24748-2. В приложении В настоящего стандарта приведен вариант ПУПРСИ для этапов жизненного цикла системы, содержащий руководящие указания по разработке и модификации ПУПРСИ в зависимости от стадии или стадий жизненного цикла системы, определенных в проекте.

При выборе стадий и процессов модели жизненного цикла для их наполнения также следует учитывать следующий нижний уровень стандартов, непосредственно приведенных в ISO/IEC/IEEE 15288, и те стандарты, которые добавлены к согласованному множеству после последней публикации ISO/IEC/IEEE 15288. Основные стандарты, ранее отмеченные для учета, расширены по процессам, информационным объектам и руководящим указаниям ISO/IEC/IEEE 15288. Сюда относятся: ISO/IEC/IEEE 16326 для управления проектами, ИСО/МЭК 16085 (IEEE 16085) для управления рисками, ISO/IEC/IEEE 15939 для измерений и ISO/IEC/IEEE 29148 для инженерии требований. Другие стандарты могут быть добавлены для текущего рассмотрения на основе организационных или проектных потребностей (например, по цели совершенствования организационных процессов, состоянию поддерживаемой модели жизненного цикла, области применения продукции или услуг). Некоторые из них могут включать ISO/IEC/IEEE 42010 для архитектурного описания, ИСО/МЭК 15026 для информационного обеспечения, ИСО/МЭК 27001 по методам обеспечения безопасности, ИСО/МЭК 20000 для управления услугами, ИСО 9000 по управлению качеством, ISO/TR 18529 по ориентированным на человека процессам, подобным удобству использования. В проекте следует предусмотреть возможность перемещения существующих процессных активов от руководящих организационных структур для реализации существенных и часто используемых стандартов в усилиях по адаптации. Если это не удается, то проектная команда может стремиться получить подходящие стандарты для потенциальной адаптации или, возможно, разработать подходящие процессы для использования в ПУПРСИ проекта.

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

8.3 Элементы ПУПРСИ

В таблице 2 приведена аннотированная схема и пример формата ПУПРСИ. Необходимое содержание ПУПРСИ описано в разделе 9.

Примечание - Несмотря на то, что раздел 8 озаглавлен как руководящие указания, дополнительные подробности из ISO/IEC/IEEE 15289 относительно информационные объектов повторяются здесь для акцента на то, что данный раздел не предназначен для рассмотрения всех возможных вариантов содержания и указания названий информационного объекта, а также последовательности и названий разделов.

Таблица 2 - Примерная схема ПУПРСИ

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

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

Объем документа зависит от области применения проекта, его завершенности и риска. Следует охватывать общие усилия по техническому планированию для проекта и, если проект определяет, что требуется дополнительное детальное планирование, можно ссылаться на соподчиненные планы. Следует обеспечивать такой уровень подробностей, какая требуется в операционном плане, представляемом заинтересованным сторонам для технического управления проектом. Следует предоставлять достаточно подробную информацию для понимания того, кто делает что, когда, как и где и какие механизмы используются для управления всем этим. Однако, если ПУПРП для проекта не существует или содержательная информация, как указано в разделе 9 ISO/IEC/IEEE 16326 уже не существует, эти данные должны быть прописаны во время разработки проекта ПУПРСИ.

9 Содержание информационного объекта

9.1 Общие положения

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

ISO/IEC/IEEE 16326 определяет необходимое содержание и формат для планов управления проектами, охватывающих программные средства и программно-ориентированные системы. ПУПРСИ является основным планом проекта для управления техническими усилиями, и согласно подразделу 5.8 его разработка тесно связана с разработкой и содержанием ПУПРП.

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

9.2 Вступительная часть

Каждая версия ПУПРСИ должна содержать вступительную часть. Вступительная часть должна включать в себя следующее:

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

b) Раздел с утверждением(ями), который, как правило, содержит письменную или электронную подпись (подписи) заинтересованной стороны (сторон), ответственной за утверждение ПУПРСИ или другим признанным механизмом утверждения.

c) Раздел пересмотра или истории изменений, который, как правило, включает название проекта, номер версии плана, дату выпуска, показатель изменений в содержании (например, страницы, номер раздела) в текущей версии плана, краткую информацию, описывающую характер изменений в этой версии плана, и список номеров версий и дат выпуска всех предыдущих версий плана.

d) Оглавление.

e) Перечень рисунков, показанных в ПУПРСИ.

f) Перечень таблиц, представленных в ПУПРСИ.

Вступительная часть может также включать предисловие, которое кратко описывает цель, область применения и контекст ПУПРСИ и определяет его пользователей. Если такое предисловие не включено во вступительной части, данную часть следует включить во введение непосредственно в состав ПУПРСИ.

9.3 Изложение технического проекта

9.3.1 Общие положения

Сводная техническая информация проекта должна быть включена в ПУПРСИ.

9.3.2 Цель, область применения, задачи

ПУПРСИ должен определить цель, область применения и задачи проекта и продукции, поставляемой на условиях системной инженерии или технических усилий.

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

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

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

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

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

9.3.3 Допущения и ограничения

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

9.3.4 Системное описание

ПУПРСИ должен предоставить описание системы. Описание должно включать основные элементы одновременно с развитием решения.

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

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

9.3.5 График и бюджет

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

9.4 Ссылки

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

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

9.5 Определения

ПУПРСИ должен определить или предоставить ссылки на документы, содержащие определения терминов и аббревиатуры, необходимых для правильного понимания ПУПРСИ.

9.6 Организация технического проекта

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

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

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

9.7 Планирование технического определения

9.7.1 Общие положения

В управлении проектом ПУПРСИ должен описать процессы планирования и контроля, связанные с техническими усилиями.

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

В приложении А содержится краткое описание типового соответствующего основополагающего материала, который, как ожидается, может существовать на уровне ПУПРП. В ISO/IEC/IEEE 16326 приводится более подробное описание для каждого из этих планов управления проектами или элементов плана.

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

9.7.2 Определение процесса

9.7.2.1 Модель процесса проекта - техническое представление

ПУПРСИ должен содержать описание или ссылку на описание модели процесса, которая применима к конкретным техническим усилиям.

Краткое описание модели процесса проекта с акцентом на аспекты системной инженерии следует поместить в ПУПРСИ, а на детали описания модели процесса из ПУПРП, или другой документации, следует сослаться. Типовое описание модели процесса ПУПРП см. в таблице A.1.

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

9.7.2.2 Модели развития жизненного цикла

Общую модель жизненного цикла проекта следует описать в ПУПРП. В ПУПРСИ следует сослаться на описание в ПУПРП любую дополнительную информацию (с ее привязкой к контексту) о применении модели к усилиям системной инженерии.

В ПУПРСИ следует включить описание стратегии применения стандарта ISO/IEC/IEEE 15288. Следует кратко описать определение модели жизненного цикла, стадии и процессы, актуальные для данного проекта, следует определить те, которые подробно описываются в ПУПРСИ.

Примечание - Понятия для разработки информации о стадиях и процессах модели жизненного цикла описаны в разделе 5, а руководящие указания по использованию в разделе 8. Приложение B дает представление о необходимых изменениях ПУПРСИ в зависимости от стадии жизненного цикла системы или тех стадий, которые реализуются в проекте.

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

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

9.7.3 Планирование инфраструктуры

9.7.3.1 Технические воздействия

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

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

9.7.3.2 Методы, инструментальные средства и методики

В ПУПРП следует включить обзор методов, инструментальных средств и методик, которые применимы в проекте. На это следует сослаться в ПУПРСИ. В ПУПРСИ следует описать любые такие уникальные методы, инструментальные средства и методики, применимые в поддержке работ поставляемых и не подлежащих поставке продуктов наряду с деталями их применения, которые имеют отношение к техническим усилиям проекта. Типовое описание методов, инструментальных средств и методик в ПУПРП приведено в таблице А.1.

9.7.4 Техническое планирование проекта

9.7.4.1 Общие положения

Описание высокого уровня приводится для планирования каждой из следующих областей инициирования работ проекта: оценки, укомплектования штатов, приобретения ресурсов, обучения, рабочих действий, распределения по графикам, распределения ресурсов, бюджету и закупкам. Ниже перечислены дополнительные замечания по такому описанию в ПУПРСИ. См. таблицу A.2 для типового описания содержания плана ПУПРП.

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

9.7.4.2 Планирование ресурса

В планирование ресурсов следует включить:

a) План оценки: масштабы проекта, стоимость и график проведения проекта.

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

c) План приобретения ресурсов: план приобретения ресурсов в дополнение к персоналу, необходимый для успешного завершения проекта.

d) План обучения персонала: обучение, необходимое для того, чтобы удостовериться, что обеспечен необходимый уровень квалификации для успешного осуществления проекта.

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

9.7.4.3 Техническая оценка стоимости и графика

Техническая оценка стоимости и графика включает в себя следующее:

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

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

b) Распределение по графику: обеспечение планирования отношений между рабочими действиями таким образом, чтобы отразить ограничения во временной последовательности работ и учесть возможности для параллельных рабочих действий.

Примечания

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

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

Если ПУПРСИ включает в себя соподчиненные технические графики, следует использовать методологию критического пути и критерии для событий перехода, которая применяется для получения сводного графика и графиков системной инженерии обеспечивающих систем и их структур. Методология включает описание подхода и методов, которые планируется обновлять и поддерживать как сводный график, так и подробные графики.

c) Распределение ресурсов: предоставляет подробную детализацию ресурсов, выделенных для каждого основного вида действий в структуре разделения работ проекта. В описание ПУПРСИ по распределению ресурсов следует включить метод распределения ресурсов по техническим задачам, в том числе: определение потребностей в ресурсах, процедуры контроля и перераспределения ресурсов.

d) Бюджет: содержит подробное распределение необходимых бюджетов по каждому из основных элементов структуры разделения работ.

e) Закупки: перечисляет товары и услуги, которые будут приобретены для проекта и как они будут получены.

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

9.7.4.4 Объединение технических усилий

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

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

b) Состав групп, организованных для поддержки конкретного элемента структуры разделения системы.

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

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

9.8 Осуществление и контроль технического проекта

9.8.1 Оценка и контроль выполнения

В ПУПРСИ следует описать процессы оценки и контроля, которые применимы в усилиях системной инженерии.

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

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

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

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

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

Описание высокого уровня приводится для каждого из следующих планов, которые поддерживают оценку и контроль проекта: измерение, обеспечение качества, управление субподрядчиками, анализы и аудиты, контроль изменения области применения, контроль графиков, бюджетный контроль и закрытие проекта. Дополнительные комментарии по реализации ПУПРСИ приводятся после плана. Типовое описание содержание плана ПУПРП приведено в таблицах A.3 и A.5.

9.8.2 Измерение

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

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

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

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

9.8.3 Гарантия качества

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

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

9.8.4 Анализы и аудиты

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

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

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

Примечания

1 Руководящие указания по проведению анализов и аудитов доступны из множественных источников. Многие повторяются, а некоторые, как указано в ISO/IEC TR 24748-1, носят общий характер без необходимости какого-либо специального обзора.

2 ISO/IEC/IEEE 29148 предоставляет информацию по анализу для требований валидации.

3 Приложение В ISO/IEC TR 24748-1 дает представление о совместных анализах и обосновании (например, по решению открытых вопросов или достижению других решений или соглашения). Некоторые из этих анализов включают: план проекта, план тестирования, эксплуатационную концепцию системы, требования и проект системы и программных средств, критические требования, готовность к испытаниям, удобство использования и сопровождение.

4 Подпункт 5.4.4.3.2 ISO/IEC TR 24748-2 предоставляет расширенный перечень руководящих указаний и обоснований по восьми техническим анализам. Перечисленные обоснования показывают значимое применение на различных уровнях в структуре системы или возможности для удовлетворения потребности в конкретной точке в эволюции системы. Подпункт 5.4.4.3.3 содержит руководящие указания по двум типам аудита конфигурации: функциональной и физической.

5 IEEE 15288.2 содержит руководящие указания по военно-техническому анализу и аудиту оборонных программ.

9.8.5 Управление субподрядчиками

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

9.8.6 Контроли в управлении проектом

В ПУПРСИ следует ссылаться и быть последовательными согласно следующим планам контроля в ПУПРП:

a) Плану контроля изменений области применения: описывает, как обнаружить действия вне области применения проекта и действия, которые должны быть приняты, если они будут обнаружены или востребованы.

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

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

9.8.7 Закрытие технического проекта

План закрытия проекта: содержит необходимые планы для помощи в обеспечении организованного закрытия проекта.

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

9.8.8 Управление технической базовой линией

9.8.8.1 Общие положения

Для каждого из следующих планов, поддерживающих управление техническими базовыми условиями, приведено описание высокого уровня: управление требованиями, управление конфигурацией, управление информацией и управление данными документации. Дополнительные комментарии по реализации ПУПРСИ перечисляются после плана. Типовое описание содержания плана ПУПРП приведено в таблицах А.3 и А.5.

9.8.8.2 Управление требованиями

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

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

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

Примечания

1 Подраздел 6.5 ISO/IEC/IEEE 29148 содержит руководящие указания по управлению требованиями, включая описание управления изменениями и оценки требований. Этот подраздел также определяет общую базовую линию для управления требованиями, включая такие, как функциональные базовые линии, их размещение, базовые линии разработки и продукции.

2 Аналогичным образом в пункте 5.4.4.3 ISO/IEC TR 24748-2 описываются базовые линии требований в свете инженерного представления процессов в модели жизненного цикла.

9.8.8.3 Управление конфигурацией

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

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

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

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

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

9.8.8.4 Управление информацией

9.8.8.4.1 Интегрированное хранилище

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

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

В руководящих указаниях по содержанию интегрированного хранилища следует реализовать следующее:

a) Предоставить описание реализации хранилища информации проекта, в т.ч. как информацию собирают, отслеживают и сопровождают.

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

9.8.8.4.2 Управление документами и данными

Планы по управлению документами и данными включают планы по созданию и управлению не подлежащими поставке и поставляемыми рабочими продуктами.

Примечание - ISO/IEC/IEEE 15289 описывает содержание для жизненного цикла большого количества данных и информационных объектов и содержит условия для управления документами и данными.

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

Следует определить технические характеристики, которые должны быть обеспечены при разработке и поддерживаться в проекте. В ПУПРСИ следует включить описание взаимосвязей между разрабатываемыми техническими документами.

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

В ПУПРСИ следует предоставить или сделать ссылки на обзор иерархии документации для проекта с указанием порядка очередности (например, из проектного отчета о работе, через ПУПРП и вниз через основные не подлежащие поставке технические рабочие продукты).

Примечания

1 ISO/IEC/IEEE 29148 и INCOSE TP 2003 002 03.2.2 определяют руководящие указания об обычно требуемых технических документах и подходах к документации, которые можно включить в описание ПУПРСИ для управления информацией, интегрированного хранилища и планов документации.

2 ISO/IEC/IEEE 29148 определяет требуемые информационные объекты и их содержание для поддержки процессов ISO/IEC/IEEE 15288, которые включают инженерию требований. Раздел 7 ISO/IEC/IEEE 29148 требует разработки проекта спецификаций требований, включая документ спецификации требований заинтересованных сторон (StRS), документ спецификации системных требований (SyRS) и документ спецификации требований к программному обеспечению (SRS), придерживаясь ИСО/МЭК 12207. Раздел 8 ISO/IEC/IEEE 29148 содержит руководящие указания и предложенные схемы для каждого из информационных объектов, в то время как раздел 9 ISO/ IEC/IEEE 29148 определяет нормативное содержание этих информационных объектов.

3 Приложение А ISO/IEC/IEEE 29148 предоставляет содержание для другого обычно требуемого информационного объекта - эксплуатационной концепции системы (OpsCon) - пользовательского документа, описывающего особенности системы с точки зрения пользователя. Приложение В ISO/IEC/IEEE 29148 обеспечивает содержание для концепции функционирования (ConOps), которая на организационном уровне ссылается на предполагаемый способ руководства работой организации.

4 "Руководящие указания по системной инженерии" Международного совета по системной инженерии (INCOSE) содержат детальное описание по разработке общих технических спецификаций, отображаемых на соответствующем общем дереве спецификаций.

9.9 Планы поддержки процесса

9.9.1 Общие положения

В ПУПРСИ следует определить и рассмотреть планы поддержки проекта относительно процессов, которые связаны с техническими усилиями проекта. Это включает в себя определение области применения, такой, как управление решением и управление рисками.

Описание высокого уровня приведено для каждого из следующих планов: управления решениями, управления рисками, связи, верификации и валидации. Дополнительные комментарии для реализации ПУПРСИ перечисляются после плана. Типовое описание содержания уровня ПУПРП см. в таблице A.5.

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

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

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

Примечание - Планы поддержки специальных процессов инженерии описаны в 9.10.

9.9.2 Управление решениями

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

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

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

Анализ системы по критериям эффективность - стоимость: В ПУПРСИ следует включить описание системы и исследования по критериям эффективность - стоимость, используемые для поддержки разработки сбалансированных продуктов и процессов по жизненному циклу и поддержки управления рисками. В ПУПРСИ следует описать показатели эффективности, их взаимосвязи, критерии выбора критических показателей эффективности для поддержки развивающихся определений системы и ее верификации. Сюда следует включить описание общего подхода для анализа системы по критериям эффективность - стоимость или других исследований (например, производственного анализа), верификационные анализы, анализы распределений; эксплуатационные анализы; анализы по эргономическому проектированию, возможностям человека, персонала и обучения; анализы по удобству использования; анализ сопровождаемости; безопасности, угрозам для здоровья и анализ среды; анализ затрат по жизненному циклу. Следует включить объяснение того, как аналитические результаты будут интегрироваться.

Анализ рисков: описание анализа рисков для поддержки программы технического риска см. 9.9.3.

9.9.3 Управление рисками

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

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

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

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

9.9.4 Связь

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

В ПУПРСИ следует указать технические заинтересованные стороны, описать способы основных технических коммуникаций и дать ссылки на планы уровня проекта по связи.

9.9.5 Верификация и валидация

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

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

Примечание - ISO/IEC/IEEE 29148 представляет руководящие указания по планированию верификации и валидации для требований инженерии. ISO/IEC/IEEE 29148 описывает четыре стандартных метода верификации в получении объективных данных для подтверждения выполнения требований: инспекция, анализ или моделирование, демонстрация и испытания.

9.10 Действия и планы специальной инженерии

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

Например, планы приемки и поставки продукции и установки являются планами общей технической поддержки, которые дополняют ПУПРСИ или написаны со значительным техническим содействием в поддержку ПУПРП. Описание типового содержания плана принятия продукта ПУПРП и плана поставки продукта приведено в таблицах А.1 и А.4.

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

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

Таблица 3 определяет дополнительные действия системной инженерии, которые обычно приводят в дополнительных планах или описаниях планирования в ПУПРСИ.

Таблица 3 - Дополнительное планирование системной инженерии

Примечания

1 ISO/IEC/IEEE 29148 описывает требования, действия инженерии и задачи, обычно относящиеся к специализированным действиям инженерии и анализам, которые могут быть использованы для поддержки концептуального определения системы или требований валидации. Например, это могут быть требования к качеству, связанные с транспортабельностью, живучестью, гибкостью, переносимостью, повторным использованием, надежностью, ремонтопригодностью и безопасностью; или требования со стороны человеческого фактора, связанные с взаимодействием с людьми-пользователями (и другими заинтересованными сторонами, затронутыми использованием) с точки зрения безопасности, производительности, результативности, эффективности, надежности, ремонтопригодности, здоровья, благополучия и удовлетворенности. Анализы могут также быть выполнены для того, чтобы получить такие характеристики, как показатели практичности, включая результативность, эффективность и удовлетворенность; надежность человека; свободу от неблагоприятных эффектов для здоровья.

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

Приложение A
(справочное)

Элементы плана управления проектом (ПУПРП)

Связь между содержанием ISO/IEC/IEEE 24748-4 ПУПРСИ и содержанием ПУПРП по ISO/IEC/IEEE 16326

Пять приведенных ниже таблиц обобщают требуемое содержание ПУПРП из раздела 5 ISO/IEC/IEEE 16326. Эти таблицы включают в себя описание большинства требуемых элементов ПУПРП по ISO/IEC/IEEE 16326: планы контекста проекта, материалы по планированию проекта, планы оценки и контроля проекта, план поставки продукта и планы поддержки проекта.

Хотя ISO/IEC/IEEE 16326 не является нормативной ссылкой для настоящего стандарта, и пользователи, которые отвечают требованиям настоящего стандарта, не должны соответствовать ISO/IEC/IEEE 16326, положение о требованиях к содержанию ПУПРСИ в разделе 9 предполагает, что ПУПРП разработан аналогично описанному в ISO/IEC/IEEE 16326. Большинство требований из раздела 9 указывает, что можно ссылаться на ПУПРП в части содержания, которое используется на протяжении всего проекта и предполагается, что разработка ПУПРСИ осуществляется на основе существующего материала управления проектами при управлении и выполнении технического действия проекта. Например, ПУПРП (или соответствующая документация), такая как план управления рисками, который направляется процессом управления рисками проекта, действиями, задачами, инструментальным средствами и т.д. для реакции на риски и управления возможностями, предположительно, содержит подобное описание подобно разделу 5 ISO/IEC/IEEE 16326. Тогда положения проекта по управлению рисками ПУПРСИ ссылаются на этот материал в качестве основы и описывают любые существенные изменения и расширение задач, специальных исследований или анализов и т.д., имеющих важное значение для программы технического риска проекта.

Если во время разработки ПУПРСИ, основополагающий материал, связанный с ПУПРП еще не существует, как минимум, необходимы основные описания для поддержания технической программы проекта, должны быть задокументированы в ПУПРСИ или в любой другой проектной документации, на которую затем могут ссылаться соответствующие положения по условиям ПУПРСИ. Таблица A.1 представляет планы контекста проекта.

Таблица A.1 - Планы контекста проекта

Таблица A.2 содержит большинство элементов плана ISO/IEC/IEEE 16326 в ПУПРП с учетом потребностей для открытия проекта и начала работы.

Таблица A.2 - Планы инициации проекта и начала работ

Таблица A.3 содержит планы оценки и контроля проекта, т.е. элементы плана ISO/IEC/IEEE 16326 в ПУПРП с учетом потребностей для оценки и контроля требований к продукту, области применения проекта, графика, бюджета и ресурсов, и т.д.

Таблица A.3 - Оценка и контроль проекта

Таблица A.4 содержит план осуществления проекта, т.е. элементы плана ISO/IEC/IEEE 16326 в ПУПРП с учетом потребностей для планов поставки продукции (продуктов) проекта.

Таблица A.4 - План поставки продукции

Таблица A.5 содержит планы поддержки проекта, т.е. элементы плана ISO/IEC/IEEE 16326 в ПУПРП с учетом потребностей для поддерживающих процессов, охватывающих продолжительность проекта.

Таблица A.5 - Планы поддержки проекта

Приложение B
(справочное)

Рассмотрения ПУПРСИ для стадий жизненного цикла системы

B.1 Введение

Данный раздел дает руководящие указания, как следует изменить ПУПРСИ, в зависимости от стадии жизненного цикла системы или стадий, которые проект охватывает. Для каждой стадии это приложение демонстрирует результаты цели и пример выходных результатов, которые раздел 4 ISO/IEC TR 24748-1 предусматривает для данной стадии. Данное приложение кратко описывает два произвольно отобранных процесса в контексте определенного этапа.

Область применения проекта может охватить только часть этапа жизненного цикла системы, или одну ступень во множестве стадий. В каждом случае будет составлен ПУПРСИ для проекта, чтобы соответствовать области применения. Настоящий стандарт, а также подраздел 4.1 ISO/IEC TR 24748-1 подчеркивают, что:

"Каждый процесс жизненного цикла ИСО/МЭК 12207 и ИСО/МЭК 15288 может запущен в любой точке на всем протяжении жизненного цикла... Порядок и последовательность, в которой реализуются процессы, и когда они запускаются, проводятся с помощью требований проекта и контекста: нет никакого уникального порядка и временной последовательности для их использования в пределах одной стадии или через несколько стадий".

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

В таблице B.1 приведены примеры процессов, которые можно использовать на одной стадии (стадии замысла). Обратите внимание, что выходные результаты примера приводятся только в качестве иллюстрации для данного проекта и его поддержки с помощью ПУПРСИ. Фактические используемые процессы, а также результаты, могут отличаться. Таблицу B.1 можно использовать в качестве отправной точки для рассмотрения специальной ситуации.

Таблица B.1 - Пример использования процесса на стадии замысла

Если процесс активируется больше, чем на одной стадии жизненного цикла системы, в результате может быть получено одно или несколько новых значений, или обновления одного или нескольких результатов от предыдущих стадий, или их объединение. Данный пример продемонстрирован таблицей B.2 для трех произвольно отобранных процессов, показывая примерные выходные результаты для каждой стадии жизненного цикла системы.

Таблица B.2 - Пример выходных результатов процесса в зависимости от стадии

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

В данном разделе информация предоставляется с целью рассмотрения того, что следует использовать в ПУПРСИ, основываясь на стадиях жизненного цикла или стадиях, охватываемых проектом. Дополнительная информация приведена в разделе 4 и приложении А ISO/IEC TR 24748-2.

B.2 Стадия замысла

По стандарту ISO/IEC TR 24748-1 цель стадии замысла состоит в обращении к новым деловым возможностям и разработке предварительных системных требований и облика выполнимого проектного решения.

Пример выходных результатов ISO/IEC TR 24748-1 для стадии замысла:

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

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

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

d) Уточнение выходных результатов и оценок стоимости для стадий модели жизненного цикла системы.

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

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

g) Замыслы для выполнения последующих стадий.

h) Планы и критерии выхода на стадию разработки.

i) Разработка и соответствие критериям выхода из стадии.

j) Утверждение перехода к стадии разработки.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, а также руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии замысла:

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

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

B.3 Стадия разработки

В соответствии с ISO/IEC TR 24748-1 цель стадии разработки состоит в разработке рассматриваемой системы, которая отвечает требованиям заинтересованной стороны, и она может быть произведена, проверена, оценена, применима в эксплуатации, поддерживаема и выведена из эксплуатации.

Примеры выходных результатов ISO/IEC TR 24748-1, которые служат основанием для стадии разработки:

a) Техническая информация согласно базовой линии, включающая оцененные и уточненные системные требования и:

- схемы оборудования, рисунки и модели;

- конструкторскую документация на программное обеспечение;

- спецификации по взаимодействию;

- производственные планы;

- инструкции по эксплуатации;

- руководства по обучению операторов;

- процедуры сопровождения;

- особенности изъятия и списания.

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

c) Структура рассматриваемой системы, состоящая из аппаратных элементов, элементов программного обеспечения, персонала и взаимодействий (внутренних и внешних) всех таких элементов;

d) Верификация и валидация документации;

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

f) Уточненные и поддерживаемые базовой линией требования для обеспечивающих систем;

g) Прототип или завершенная рассматриваемая система;

h) Уточненные выходные результаты и стоимостные оценки для стадий производства, применения, поддержки, изъятия и списания;

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

j) Планы и критерии выхода на стадию производства;

k) Определение текущих рисков и реакции на них;

l) Соответствие критериям выхода из стадии;

m) Утверждение для перехода к стадии производства.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, и руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии разработки:

- процесс управления рисками: В больших проектах ПУПРП будет содержать раздел по управлению рисками и рассмотрению плана управления рисками, а также будут выделены определенные области, где управление рисками будет применено к проекту. План управления рисками наряду с другими аспектами будет описывать цель, обязанности, процессы и выходные результаты усилий по управлению рисками проекта. ПУПРСИ будет ссылаться на оба плана, которые будут предоставлять подробности того, где управления рисками используется наряду с технической работой. В качестве возможных примеров, ПУПРСИ мог бы требовать, чтобы были проведены оценки степени риска для всех основных оптимизационных исследований, как часть анализа принимаемых решений, как часть анализа соответствия требованиям, где разрабатываются планы интеграции, верификации и передачи системы. Если размер проекта не допускает отдельные планы, в ПУПРСИ следует, по крайней мере, прояснить, где и как использовать управление рисками во многих технических действиях в сердцевине стадии разработки;

- процесс определения системных требований: как и в случае с управлением рисками, процесс определения системных требований должен быть в центре усилий на стадии разработки. Даже на самом малом проекте строгое выполнение описанных в ISO/IEC/IEEE 15288 действий и задач приведет к определенным последствиям, которые повлияют на другие стадии жизненного цикла системы, гораздо позже после завершения разработки проекта.

B.4 Стадия производства

В соответствии с ISO/IEC TR 24748-1, цель стадии производства состоит в производстве или изготовлении рассматриваемой системы, ее испытании и по мере необходимости в производстве соответствующих поддерживающих и обеспечивающих систем.

В качестве примера приведены выходные результаты ISO/IEC TR 24748-1 стадии производства:

a) Квалификация возможностей производства;

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

c) Система производится в соответствии с утвержденной и квалифицированной для производства информацией;

d) Передача укомплектованных продуктов по каналам распределения или приобретающим сторонам;

e) Планы и критерии выхода на стадию применения и стадию поддержки;

f) Обновление замыслов для выполнения всех последующих стадий;

g) Определение текущих рисков и действий по их смягчению;

h) Принятие приобретающей стороной рассматриваемой системы с гарантией качества;

i) Соответствие критериям выхода из стадии;

j) Утверждение для перехода на стадию применения;

k) Утверждение для перехода на стадию поддержки.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, а также руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии производства:

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

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

B.5 Стадия применения

В соответствии с ISO/IEC TR 24748-1, цель стадии применения состоит в эксплуатации продукта или предоставлении услуги в намеченной среде и обеспечении эксплуатационной эффективности.

В качестве примера приведены результаты ISO/IEC TR 24748-1 для стадии применения:

a) опытный персонал с компетенцией оператора в рассматриваемой системе и предоставлении эксплуатационных услуг;

b) установленная рассматриваемая система, способная к эксплуатации и предоставлению стабильных эксплуатационных услуг;

c) мониторинг и оценка эффективности и стоимости для подтверждения соответствия целям эксплуатации;

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

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

f) планы и критерии выхода на стадию выведения из эксплуатации;

g) соответствие критериям выхода из стадии;

h) утверждение для перехода на стадию выведения из эксплуатации.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, а также руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии применения:

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

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

B.6 Стадия поддержки

В соответствии с ISO/IEC TR 24748-1 цель стадии поддержки состоит в обеспечении служб логистики, сопровождения и поддержки, которые обеспечивают непрерывную эксплуатацию рассматриваемой системы и устойчивые услуги.

В качестве примера выходными результатами, представленными ISO/IEC TR 24748-1 для стадии поддержки, являются:

a) обученный персонал по сопровождению системы и обеспечения услуг по поддержке;

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

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

d) сопровождение продукта и услуг и исправление проектных недостатков;

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

f) определены текущие риски и смягчающие их действия;

g) соглашение об окончании услуг поддержки;

h) соответствие критериям выхода из стадии.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, а также руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии поддержки:

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

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

B.7 Стадия выведения из эксплуатации

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

В качестве примера выходными результатами, представленными ISO/IEC TR 24748-1 для стадии выведения из эксплуатации являются:

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

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

c) планы и процедуры передачи предоставления услуг к новой рассматриваемой системе, если это применимо;

d) удаление отходов;

e) окружающая среда возвращается в исходное или согласованное состояние;

f) заархивированные элементы;

g) эксплуатационный штат переведен на другую работу;

h) соответствие критериям выхода из стадии.

Два примера выходных результатов описаны ниже, чтобы еще раз подчеркнуть, что для каждого процесса на каждом этапе может быть несколько выходных результатов, которые зависят от специфических особенностей проекта и потребностей клиента, управляющего проектом. Необходимо тщательно продумать каждую ситуацию для абсолютной уверенности, что полезно и необходимо, прежде чем продолжать. Следует рассмотреть и подробно оценить ISO/IEC/IEEE 15288, ISO/IEC TR 24748-1, ISO/IEC TR 24748-2, а также руководящие указания системной инженерии INCOSE для определения правильных процессов и выходных результатов в ПУПРСИ для стадии выведения из эксплуатации:

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

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

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

Приложение C
(обязательное)

Политики приспосабливания

C.1 Введение

Данное приложение представляет требования для приспосабливания содержания информационного объекта в настоящем стандарте. Приспосабливание не является обязательным требованием соответствия к настоящему стандарту. Приспосабливание недопустимо, если задекларировано наличие "полного соответствия". Процесс приспосабливания применяется, лишь если декларируется "приспособленное соответствие".

C.2 Процесс приспосабливания информационного объекта

C.2.1 Цель

Цель процесса приспосабливания состоит в том, чтобы садаптировать содержание информационного объекта настоящего стандарта для соответствия специфическим обстоятельствам или факторам, которые:

a) окружают организацию, использующую настоящий стандарт в соглашении;

b) влияют на проект, который должен удовлетворять соглашению, содержащему ссылку на настоящий стандарт;

c) отражают потребности организации в порядке поставки продукции или услуг.

C.2.2 Результаты

В результате успешной реализации процесса приспосабливания определяется измененное или новое содержание информационного объекта для достижения выполнения цели документа ПУПРСИ, описанного в настоящем стандарте.

C.2.3 Действия и задачи

Если настоящий стандарт приспосабливается, то организация или проект должны осуществить следующие действия:

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

1) стабильность и разнообразие в эксплуатационной среде;

2) новизну, масштабы и сложность;

3) начало и продолжительность эксплуатации;

4) появляющиеся возможности технологий;

5) профиль бюджета и доступные организационные ресурсы;

6) пригодность услуг от обеспечивающих систем;

7) потребность соответствия другим стандартам.

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

1) заинтересованные стороны системы;

2) заинтересованные стороны к соглашениям, осуществляемым организацией;

3) соответствующие организационные функции;

c) Выбрать содержание информационного объекта, которое требуется приспособить и удалите его.

Примечания

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

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

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Библиография

Электронный текст документа
и сверен по:

, 2019