ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

58607—

2019/

ISO/IEC/IEEE 24748-4: 2016

Системная и программная инженерия УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ

Часть 4

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

(ISO/ IEC/IEEE 24748-4:2016, IDT)

Издание официальное

Москва

Стандартинформ

2019

Предисловие

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

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

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

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

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

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

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

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

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

© ISO, 2016 — Все права сохраняются © Стандартинформ, оформление, 2019

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

4.11_

проект (project): Усилия с определенными датами начала и окончания, предпринятые для создания продукции или услуг в соответствии с заданными ресурсами и требованиями.

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

[ISO/IEC/IEEE 15288:2015. примечание изменено]

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

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

4.13 _

заинтересованная сторона, правообладатель (stakeholder): Индивидуум или организация, имеющая право, долю, требование или интерес в системе или в обладании ее характеристиками, удовлетворяющими их потребности и ожидания.

[ISO/IEC/IEEE 15288:2015]

4.14_

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

[ISO/IEC TR 29110-5-6-2:2014, изменен для определения технических аспектов проекта]

4.15_

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

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

[ISO/IEC 29148:20114 статья 6.3.3.1]

4.16_

структура разделения работ (work breakdown stmcture (V\©S)): Иерархическое разбиение полного объема работ, осуществляемое проектной командой для выполнения задач проекта и создания необходимых результатов.

[Руководящие указания РМВОК — пятое издание]

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

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

5.1    Введение

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

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

Справочное приложение А содержит требования содержания 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.3.1 Подраздел 6 1 Оценка и контроль проекта Пункт 6 3.2 Подраздел 6 2 Управление решениями Пункт 6.3.3 Подраздел 6 3 Управление рисками Пункт 6.3.4 Подраздел 6 4 Управление конфигурацией Пункт 6 3.5 Подраздел 6 5 Управление информацией Пункт 6.3.6 Подраздел 6 6 Измерение Пункт 6.3.7 Подраздел 6.7 Гарантия качества Пункт 6.3.8 Не применяется

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

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

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

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

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

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

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

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

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

ISO/IEC/IEEE 15288

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

6.3.1.1    Цель

Цель процесса планирования проекта состоит в том. чтобы произвести и скоординировать эффективные и осуществимые планы.

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

Примечание — Определение стратегий для процессов выполняется в объединении с процессом планирования проекта

6.3.1.2    Выход (выходные результаты)

В результате успешной реализации процесса планирования проекта:

a)    определяются и регистрируются цели и планы;

b)    определяются роли, ответственности, подотчетности, полномочия.

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

d)    инициируются и поддерживаются планы относительно выполнения проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

5.1    Введение.......................................................................6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1    Введение......................................................................20

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

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

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

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

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

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

9.4    Ссылки........................................................................26

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение А (справочное) Элементы плана управления проектом (ПУПРП)...................39

Приложение В (справочное) Рассмотрение ПУПРСИ для    стадий жизненного цикла системы......46

Приложение С (обязательное) Политики приспосабливания.................................54

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам...............................................55

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

Введение

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) для выделения дополнительных методов и обеспечения нормативного содержания для ПУПРСИ.

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

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

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

Часть 4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Издание официальное

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

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

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

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

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

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

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 Приспособленное соответствие

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

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/PublictyAvailableStandards/index html

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

4.1_

документ (document): Уникально идентифицируемая единица информации для использования человеком.

Пример — Отчет, спецификация, руководящие указания или пособие, о печатной или электронной форме.

(ISO/IEC/IEEE 15289:2015’))

4.2_

дополнить [информацию] (include [information]): Информация или ссылка на информацию, содержащиеся в документе.

(ISO/IEC/IEEE 15289:2015)

4.3_

информационный объект (information item): Отдельно идентифицируемый объем информации. который производится, сохраняется и поставляется для использования человеком.

Примечания

1    Синоним информационный продукт

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

[ISO/IEC/IEEE 15289:2015)

4.4

содержание информационного объекта (information item content): Информация, включенная в информационный объект, связанная с системой, продуктом или услугой, для удовлетворения требования или потребности.

[ISO/IEC/IEEE 15289:2015)

’) Заменен на ISO/IEC/IEEE 15289 2017

4.5_

тип информационного объекта (information item type): Группа информационных объектов, соответствующих заранее подготовленному набору универсальных критериев.

Примечание —Синоним общий тип документа

Пример — «План» — тип информационного объекта для всех планов, и «отчет» — тип информационного объекта для всех отчетов.

(ISO/IEC/IEEE 15289:2015]

4.6_

интегрированное хранилище (integrated repository): Плановое и контролируемое хранение информации. относящейся к проектированию систем.

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

4.7_

показатель эффективности (measure of effectiveness МОЕ): «Эксплуатационный» показатель успешности, который напрямую связан с достижением эксплуатационных целей в намеченной эксплуатационной среде при соблюдении указанного множества условий.

(ISO/IEC TR 24748-2:2010¹) (таблица А.15 к)]

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

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

4.9 _

организация (organization): Группа лиц и необходимых средств с распределением ответственностей, полномочий и взаимоотношений.

Примечания

1    Объединение лиц организованных для некоторой конкретной цели, такое как клуб, союз, корпорация или общество, являются организацией

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

[ISO/IEC/IEEE 15288:2015]

4.10_

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

[ISO/IEC/IEEE 15289:2015]

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